|
Network Working Group Request for Comments: 1122 |
Internet Engineering Task Force R. Braden, Editor October 1989 |
IP 層は、送信する各データグラムに対して正しい次ホップを選択する。もし宛先が接続されたネットワーク上に在れば、そのデータグラムを宛先ホストに直接送信する。さもなくば、接続されたネットワーク上のゲートウェイに振り分けなければならない。
宛先が接続されたネットワーク上に在るか否かを決定するために、以下のアルゴリズムを使用しなければならない (MUST)。([IP:3] 参照)
特別なケースの宛先アドレスについては、以下のように扱われる。
ホスト IP 層は最小のネットワーク環境で、特にゲートウェイが存在しない時に、正しく動作しなければならない (MUST)。例えば、もしホストの IP 層が、初期化のために少なくとも 1 つのゲートウェイを見つけると主張したら、そのホストは単一の孤立したブロードキャストネット上で動作することができないだろう。
同じ宛先に一連のデータグラムを効率的に振り分けるために、送信元ホストは、次ホップゲートウェイへのマッビングの "経路キャッシュ" を保持しなければならない (MUST)。ホストはデータグラムを振り分けるために、このキャッシュについて以下の基本的なアルゴリズムを使用する。このアルゴリズムは、基本的なルーティング負荷をゲートウェイに置くよう設計されている [IP:11]。
宛先アドレスに対して適切なサブネットマスクは通常分からないので、ネットワークリダイレクトメッセージをホストリダイレクトメッセージと同様に扱うべきである (SHOULD)。すなわち、その宛先ホスト (のみ) のキャッシュエントリを新たなゲートウェイとして更新 (あるいは、もしそのホストのエントリが存在しなければ作成) する。
DISCUSSION:
この推奨は、ゲートウェイ要件 [INTRO:2]
に違反して、サブネット化されたネットワークでネットワークリダイレクトを誤って送信するゲートウェイに対する防御のためである。
宛先ホストアドレスの経路エントリキャッシュが存在しない (しかも宛先ホストが接続されたネットワーク上に存在しない) 時、IP 層は自分の "デフォルト" ゲートウェイのリストからゲートウェイを抽出しなければならない (MUST)。IP 層は、複数のデフォルトゲートウェイをサポートしなければならない (MUST)。
余分な機能として、ホスト IP 層は "静的経路" のテーブルを実装してもよい (MAY)。各々の静的経路は、ICMP リダイレクトによって上書きしてもよいか否かを示すフラグを含んでもよい (MAY)。
DISCUSSION:
ホストは通常、開始するために少なくとも一つのデフォルトゲートウェイを知る必要がある。この情報は設定ファイルか、さもなくば
BOOTP プロトコル等のホスト開始シーケンスから獲得できる ([INTRO:1] 参照)。
ホストは認識した新しいゲートウェイを全て記録することによって、デフォルトゲートウェイのリストを増やせることが提案されている。例えば、ホストはリダイレクトされた全てのゲートウェイを記録できる。そうした機能は、恐らく幾つかの環境では効果的であるが、他の場合には問題の原因になるかもしれず (例えば、ゲートウェイは全て等しいとは限らない)、推奨されない。
静的経路は通常、特定の宛先ホストかネットワークから特定の次ホップゲートウェイにマッピングする前設定であり、サービスタイプにも依存しているかもしれない (次のセクション参照)。静的経路は一般の自動ルーティングメカニズムを上書きし、例外的な状況を扱うためにシステム管理者によって設定される。しかし、ルーティング情報は設定変更時や装置障害時の潜在的な障害の元である。
各々の経路キャッシュエントリは、以下のフィールドを含む必要がある。
フィールド (2) は宛先ホストの完全な IP アドレスでもよいし、宛先ネットワーク番号だけでもよい (MAY)。フィールド (3) の TOS は含むべきである (SHOULD)。
このキャッシュ内のルックアップ手続きでのマルチホーム化の含意についての議論は、セクション 3.3.4.2 を参照されたい。
DISCUSSION:
経路キャッシュにサービスタイプフィールドを含み、ホスト経路アルゴリズムでそれを考慮することは、サービスタイプルーティングがインターネットで一般的に使用される将来にとって必要なメカニズムを提供する。セクション 3.2.1.6
を参照されたい。
各々のルートキュッシュエントリは、インターネットパスの終端を定義する。接続するパスは任意の方法で動的に変わるかもしれないが、パスの転送特性は、一つの一般的なホスト-ホストのトランスポートコネクションよりも、より長い間ほぼ一定のまま留まる傾向がある。従って、経路キャッシュエントリは、パス特性に基づいてデータをキュッシュに貯めるための自然な場所である。そのような性質の例としては、最大非分割データグラム長 (セクション 3.3.3 参照) や、トランスポートプロトコルによって計測されるラウンドトリップ遅延の平均値がある。このデータは通常上位層プロトコル、例えば TCP、あるいは UDP を使用するアプリケーションによって集められ、使われる。この方法でパス特性をキャッシュに貯める実験が、現在進行中である。
経路キャッシュは宛先ホストアドレスのみをキーとすべきか、ホストアドレスとネットワークアドレスの両方を許すべきかについての合意は無い。ホストアドレスのみを使用したい人は、以下を主張している。
それに対する意見は、経路キャッシュの中に宛先ホストとネットワークの混在を許すことである。
IMPLEMENTATION:
キャッシュは、同時に使用するかもしれない宛先ホストの最大個数のエントリを含むのに、十分な大きさを持つ必要がある。
経路キャッシュエントリは、置換するエントリを選択するために使用する制御情報も含むかもしれない。これは例えば、"最近使用した" ビットや使用回数、最後に使用されたタイムスタンプ等の形式である。診断目的のために、エントリの最終更新時間を含むことが推奨される。
実装体は、全ての送信データグラムに対して経路キャッシュを走査するオーバヘッドを減らしたいかもしれない。これは、走査スビードを上げるためのハッシュテーブルで実現してもよいし、コネクション型トランスポートプロトコルに適切なキャッシュエントリについての "ヒント" や一時ハンドルを与えて、各々の後続データグラムを IP 層に渡すことによって実現してもよい。
経路キャッシュやデフォルトゲートウェイの一覧や静的経路のテーブルは概念的に異なると説明したが、実際面では一つの "ルーティングテーブル" データ構造にまとめてもよい。
IP 層は、経路キャッシュに一覧化されている "次ホップ" ゲートウェイの障害を検出し、代替ゲートウェイを選択 (セクション 3.3.1.5 参照) できなければならない (MUST)。
ゲートウェイ障害検出は、RFC-816 [IP:11] で詳細についてカバーされている。幾つかの禁じられたパスや将来有望な技術はあるが、今までの経験では、全体的に満足のいく完全なアルゴリズムは作成されていない
DISCUSSION:
もし、実装体がゲートウェイ障害や再ルーティングを検出するための適切なメカニズムを含まなければ、ゲートウェイ障害によって、明らかにデータグラムが
"ブラックホール" の中に消えていく可能性がある。この障害は、ユーザに混乱を非常に招きやすく、ネットワーク部局によるデバッグが非常に困難である。
ゲートウェイ障害検出メカニズムは、ホストや第一ホップゲートウェイに受け入れられない負荷の要因になってはならない。ゲートウェイ障害検出のタイムスケジュールや受け入れられる負荷についての正確な制約は、ホストの目的の性質によって幾分変わるかもしれないが、ホストは通常、代替ゲートウェイが選択できる前にトランスポート層のコネクションが破棄されない程度の早さで、障害になった第一ホップゲートウェイを検出する必要がある。
プロトコルスタックの他の層からアドバイスを渡すことは層間のインタフェースを複雑にするが、それはゲートウェイ障害検出の望ましいアプローチである。アドバイスは IP/TCP 体系のほぼ全ての部分から来れるが、主にトランスポート層とリンク層から来ることが期待される。これは、ゲートウェイのアドバイスのためのあり得る送信元である。
受信した全てのデータグラムに対して肯定的なアドバイスを与えると、実装体に受け入れられない負荷の要因になるかもしれないことに注意されたい。
アドバイスは、IP 層への全てのインタフェースに必要なアーギュメントを使用して渡されるが、幾つかのトランスポートとアプリケーション層プロトコルは正しいアドバイスを導き出すことができない。従って、これらのインタフェースはアドバイスに対して中立の値を許さなければならない。なぜなら、常に肯定的や常に否定的なアドバイスは不正な動作を導くからである。
一般的に使用されているが推奨されない、ゲートウェイ障害検出のための別の技術が存在する。この技術は、ゲートウェイがお互いにブロードキャストしているインターネットゲートウェイプロトコル (IGP) のデータグラムを、受動的に受信 ("盗聴") するホストに依存する。このアプローチには、ゲートウェイが使用してもよい ([INTRO:2] 参照) 全ての内部ゲートウェイプロトコルを、ホストが解釈する必要があるという欠点がある。加えて、ブロードキャストネットワーク上でしか働かない。
現在、ping (すなわち ICMP エコーメッセージの使用) は、ゲートウェイプローブのために絶対的に必要とされるメカニズムである。ping が成功すれば、アドレスを持つインタフェースと、それが割り付けられたマシンの起動が保証される。しかし、そのマシンがホストに対するゲートウェイであることは保証しない。もしリダイレクトや他の証拠が、マシンがゲートウェイであることを示していれば、ping の正常は、そのマシンが起動していてさらにゲートウェイであることを示すというのが、一般的な推定である。しかしホストは、ゲートウェイが転送かリダイレクトするパケットを黙って破棄するので、この仮定は時々失敗する。この問題を避けるためには、開発中の新たな ICMP メッセージが "あなたはゲートウェイか ?" を尋ねるだろう。
IMPLEMENTATION:
以下の特定のアルゴリズムが提案されている。
Tr の大きさは利用可能なアドバイスの量に反比例する。Tr は、以下を保証する大きさにすべきであることに注意されたい。
推奨されているアルゴリズムは、キャッシュエントリ自身ではなく、経路キャッシュエントリによって指し示されているゲートウェイに関係するので、二つのレベルのデータ構造 (恐らく ARP と同等かキャッシュに似ている) が経路キャッシュを実装するために望ましいかもしれない。
もし障害ゲートウェイが現在のデフォルトでなければ、IP 層は即座にデフォルトゲートウェイに切り替えることができる。もし障害が起きたのが現在のデフォルトならば、IP 層は障害のある経路に対して新しい経路を確立するために、異なるデフォルトゲートウェイ (一つ以上のデフォルトを知っていることを想定) を選択しなければならない (MUST)。
DISCUSSION:
ゲートウェイが障害になった時、接続されたネットワーク上の他のゲートウェイは、何らかの内部ゲートウェイルーティングプロトコルを通じて障害のことを知るだろう。しかしこれは即座に行われるわけではない。なぜならゲートウェイルーティングプロトコルは、技術的に通常
30 〜 60 秒の調整時間を持つからである。もしゲートウェイが障害に応諾する前に、ホストが代替ゲートウェイに切り替えたら、新しい対象ゲートウェイは恐らく、データグラムを障害の起きたゲートウェイに転送し、障害ゲートウェイを指し示しているホストにリダイレクトを返送するだろう
(!)。ゲートウェイの調整時間の間、ホスト経路キャッシュの内容に急速な揺れが結果的に生じるだろう。こうした揺れを避けるために、ゲートウェイ障害のロジックはヒステリシスメカニズムを含むべきであると提案されている。しかし、経験上ではそうした揺れによる害は見られていない。なぜなら、ゲートウェイのルーティング情報が障害を解決するまで、ホストのサービスが復旧できないからである。
IMPLEMENTATION:
新たなデフォルトゲートウェイを選択する一つの実装技術は、ホストの一覧中のデフォルトゲートウェイを単純にラウンドロビンすることである。もう一つの方法は、ゲートウェイを優先度順でランク付けし、現在のゲートウェイが優先度の最も高いものでない時、より優先度の高いゲートウェイがサービスを回復したことを検出するために、それらにゆっくりと
"ping" することである。この ping は、非常に低いレート、例えば 1 秒間に 0.005 回で行うことができる。
以下の情報は設定可能でなければならない (MUST)。
この設定データを手動で入力する方法を提供しなければならない (MUST)。さらに、この情報を動的に決めるために複数の方法を用いることができる。[INTRO:1] の "ホスト初期化" のセクションを参照されたい。
DISCUSSION:
あるホスト実装は、どのゲートウェイが存在するかを知るために、ブロードキャストネットワーク上でのゲートウェイプロトコルの "盗聴"
を使用している。デフォルトゲートウェイ検出のための標準的な方法は作成中である。
IP 層は IP データグラムの組立を実装しなければならない (MUST)。
我々は、EMTU_R (効率的な受信 MTU) によって組立てられる最大のデータグラム長を明示している。これは時々、"組立バッファ長" と呼ばれる。EMTU_R は 576 以上でなければならない (MUST)、あるいは設定可能であるか無限にすべきである (SHOULD)、あるいは接続されたネットワークの MTU 以上であるべきである (SHOULD)。
DISCUSSION:
幾つかのアプリケーション層プロトコルは、576 よりも大きい EMTU_R 値を必要とするので、EMTU_R を固定値に制限することはコードに組み込むべきではない。
IMPLEMENTATION:
実装体は、各々のデータグラムで隣接する組立バッファを使用してもよいし、組立てられたデータグラム長に明確な制限をかけない、より複雑なデータ構造を使用してもよい。後者のケースの場合、EMTU_R
は "無限" であると言われる。
論理的に、組立は各々のフラグメントを、パケットバッファに適切なオフセットで単純にコピーすることによって実現される。継続的な再送において、パケット化は異なるが同じ組立て Id を使用するならば、フラグメントは部分的に重複してもよい。
組立の巧妙な部分は、データグラムの全てのバイトの組立が完了した時を決めるための記録方式である。記録方式のためにデータ空間を追加する必要のない Clark のアルゴリズム [IP:10] を推奨する。しかし [IP:10] とは反対に、一番目のフラグメントヘッダは、起こり得る ICMP 時間超過 (組立タイムアウト) メッセージに含めるために保存する必要がある。
トランスポート層が MMS_R、受信して IP データグラムに組立てられる最大メッセージ長、を知ることができるメカニズムが存在しなければならない (MUST) (セクション 3.4 の GET_MAXSIZES を参照されたい)。もし EMTU_R が無限でないならば、MMS_R の値は以下によって算出される。
MMS_R = EMTU_R - 20
なぜなら、20 は IP ヘッダの最小値だからである。
組立タイムアウトは存在しなければならない (MUST)。組立タイムアウト値は、残りの TTL から設定するのではなく固定値にすべきである (SHOULD)。その値は 60 秒から 120 秒までの間にすることが推奨される。もしこのタイムアウトが満了したら、部分的に組立てたデータグラムは破棄し、(もしフラグメント 0 を受信していたら) 送信元ホストに ICMP 時間超過メッセージを送信しなければならない (MUST)。
DISCUSSION:
IP 規約は、組立タイムアウトは IP ヘッダから取得する残りの TTL であるべきと述べているが、ゲートウェイは通常 TTL
を所要時間ではなく単純なホップ数として扱うので、これはうまく働かない。もし組立タイムアウトが小さ過ぎると、データグラムは不必要に破棄され、通信が失敗するだろう。少なくともタイムアウトは、インターネットに渡る典型的な最大遅延の同程度の大きさである必要がある。現実的な最小組立タイムアウトは
60 秒だろう。
キャッシュを、トランスポートプロトコルが様々な宛先に対して計測するラウンドトリップ時間保持し、これらの値を効率的な組立タイムアウト値を動的に決めるために使用することが提案されている。このアプローチについては、さらに検討が必要である。
もし組立タイムアウトの設定値が大き過ぎると、受信側ホストのバッファ資源の拘束時間が長過ぎて、MSL (最大セグメント生存時間) [TCP:1] が必要よりも大きくなるだろう。MSL は最大レートを制御し、それで分割されたデータグラムを 16 ビットの Ident フィールドの異なる値を使用して送信できる。大きい MSL は最大レートを低下させる。TCP [TCP:1] 規約は、任意に MSL として 2 分の値を想定している。これは、効率的な組立タイムアウト値の上限を設定する。
オプションで IP 層は、出力データグラムを意図的に分割するためのメカニズムを実装してもよい (MAY)。
IP 送信元と宛先アドレスとおそらく TOS のある特定の組み合わせに対して送信してもよい IP データグラムの最大長を、EMTU_S ("有効送信 MTU : effective MTU for sending") として示す。
ホストは、トランスポート層が所定の {送信元、宛先、TOS} の三つの組み合わせ (セクション 3.4 GET_MAXSIZES 呼び出し参照) に対して送信してもよい MMS_S、最大トランスポート層メッセージ長を認識することができるメカニズムを実装しなければならない (MUST)。もしローカルな分割が行われなければ、MMS_S の値は以下の通り。
MMS_S = EMTU_S - <IP header size>
そして、EMTU_S はデータグラムの送信元アドレスに対応するネットワークインタフェースの MTU 以下でなければならない。もし IP がトランスポート層によって挿入された幾つかのオプションに加え、自身の目的のために IP オプションを挿入するための空間を確保しなければ、この式にある <IP header size> は 20 である。
ローカルな分割を実装しないホストは、トランスポート層 (TCP の場合) かアプリケーション層 (UDP の場合) が IP 層から MMS_S を取得し、MMS_S の長さを超えるデータグラムを送信しないことを保証しなければならない (MUST)。
ローカルな分割を避け、パス沿いの全てのゲートウェイにおいて分割を避けられるサイズの EMTU_S を選択することが一般的に望ましい。パス沿いの最小 MTU を実際に知らない場合、IP 層は、宛先アドレスが接続されたネットワーク上に存在しない時は必ず EMTU_S <= 576 を使用すべきであり、存在する場合は接続されたネットワークの MTU を使用すべきである (SHOULD)。
各々の物理インタフェースの MTU は、設定可能でなければならない (MUST)。
ホスト IP 層実装は <全サブネット MTU> という設定フラグを所持してもよい (MAY)。それは、他のネットワークではなく同じネットワーク内の異なるサブネット上の宛先のために使用すべき、接続されたネットワークの MTU を示す。従ってこのフラグは EMTU_S を選択するために、サブネットアドレスマスクではなくネットワーククラスのマスクを使用させる。マルチホーム化されたホストでは、各々のネットワークインタフェースに対して "全サブネット MTU" フラグが必要である。
DISCUSSION:
データ送信時に使用するための正しいデータグラム長を抽出することは、複雑な話題である [IP:9]。
インターネットにおけるほぼ全てのネットワークは現在、576 かそれ以上の MTU をサポートしているので、非ローカルネットワークに送信するデータグラムの場合、576 を使うことを強く推奨する。
ホストは所定のパス上の MTU を、0 オフセットのデータグラムフラグメントを送信し、受信側が組立をタイムアウトする (それは完結できない!) のを待ち、ICMP 時間超過メッセージを返却することによって決定できることが提案されている。このメッセージは、最も大きい残存するフラグメントヘッダを本体部に含む。より直接的な方法が実験されているが、まだ採用はされていない (例えば RFC1063 参照)。
マルチホーム化されたホストは複数の IP アドレスを持つ。それは "論理インタフェース" としてのものであると考えてもよい。論理インタフェースは、一つ以上の物理インタフェースに結び付いてもよく、これらの物理インタフェースは同じか別のネットワークに接続してもよい。
以下は、マルチホーム化の重要なケースである。
最後に、マルチホーム化ではないもう一つの可能性を注記する。直接接続されたマシン間に代替物理パスを提供することによって、それらの間の信頼性やスループットを上げるために、一つの論理インタフェースを複数の物理インタフェースに結び付けてもよい例えば、二つのシステムは複数のポイントツーポイント回線によって接続してもよい。これは "リンク層多重化" と呼ばれる。リンク層多重化では、リンク層上のプロトコルは複数の物理インタフェースが提供されていることを知らない。リンク層のデバイスドライバが、多重化と物理インタフェースを渡るパケットのルーティングに責任を持つ。
インターネットプロトコル体系では、トランスポートプロトコルのインスタンス ("エンティティ") は自身のアドレスを持たないが、代わりに一つのインターネットプロトコル (IP) アドレスを使用する。これは IP、トランスポート、アプリケーション層、それらの間のインタフェースに密接な関係を持つ。特にアプリケーションソフトウェアは、マルチホーム化されたホストの複数の IP アドレスを知らなければならないかもしれない。その他の場合はネットワークソフトウェアの中で選択できる。
マルチホーム化されたホストからデータグラムを送信する際に、以下の一般的な規則が IP 送信元アドレスの選択に適用される。
マルチホーム化に関連して、以下の二つの主要件の問題がある。
DISCUSSION:
インターネットホストの実装者は、マルチホーム化のために二つの異なる概念的なモデルを使用した。それは、次の議論で詳しく要約化されている。このドキュメントは、どのモデルが望ましいかという立場に立ってはいない。各々立場を持っているようである。この両面性が、(A)
と (B) が任意であるという問題で反映されている。
o 強い ES モデル
強い ES (終端システム、すなわちホスト) モデルは、ホスト/ゲートウェイ (ES/IS) の区別を強調する。従って、上記
(A) と (B) の問題は、してもよい (MAY) から、しなければならない (MUST)
に代わる。それは、同じ物理ホスト内の一セットの論理ホストとしてマルチホーム化されたホストをモデル化する傾向がある。
(A) に関連して、強い ES モデルの提案者は、自動的なインターネットルーティングメカニズムは、宛先アドレスに対応しない物理インタフェースにデータグラムを振り分けられないことを注意している。
強い ES モデルの下では、出力データグラムのための経路算出は以下のマッピングである。
route(src IP addr, dest IP addr, TOS)
-> gateway
この場合、送信元アドレスは、対応する物理インタフェース上で直接到達できるゲートウェイを選択するためのパラメタとして含まれる。このモデルは、各々の IP アドレスに対して、少なくとも一つのデフォルトゲートウェイが一般にあることを、複数のゲートウェイが存在することがむしろ望ましいことを論理的に要求していることに注意されたい。
o 弱い ES モデル
この観点は、ES/IS の区別を強調しない。従って、(A) と (B) の問題は、してもよい (MAY) から、してはならない (MUST NOT)
に代わる。このモデルは、ゲートウェイルーティングプロトコルを盗聴するホストにとって、より自然かもしれない。そして、ゲートウェイ機能が組み込まれたホストにとって必要である。
弱い ES モデルは、リダイレクトメカニズムを失敗させるかもしれない。もしデータグラムが、宛先アドレスに対応していない物理インタフェースに送出されたら、第一ホップゲートウェイは、いつリダイレクトを送信する必要があるか分からないだろう。一方、もしホストが組み込みゲートウェイ機能を持っていれば、リダイレクトを聞かずともルーティング情報を持っている。
弱い ES モデルでは、出力データグラムのための経路算出は以下のマッピングである。
route(dest IP addr, TOS) -> gateway, interface
DISCUSSION:
初期コネクション要求 (例えば TCP "SYN" セグメント) か、データグラムサービス要求 (例えば UDP ベースのキュエリ)
を送信する時、マルチホーム化されたホスト上のトランスポート層は、どの送信元アドレスを使用するかを知っている必要がある。もしアプリケーションがそれを指定しなければ、トランスポート層は概念的な以下のマッピングを実行して
IP 層に尋ねなければならない。
GET_SRCADDR(remote IP addr, TOS)
-> local IP address
ここでの TOS はサービスタイプの値 (セクション 3.2.1.6 参照) であり、その結果は望ましい送信元アドレスである。このマッピングを実装するにあたり、以下の規則が提案されている。
将来、所定の宛先に対して使用する最善のネットワークについて、マルチホーム化されたホストが、接続された全てのネットワーク上のゲートウェイにアドバイスを依頼するための、定義された方法があるかもしれない
IMPLEMENTATION:
この処理はデータグラムルーティング (セクション 3.3.1 参照)
と本質的には同じであることに注意されたい。従って、ホストはこの二つの機能の実装を併用できるかもしれない。
下記の制限を条件に、ホストは送信元経路内の中間ホップとして振舞い、送信元経路付きデータグラムを指定された次のホップに転送してもよい (MAY)。
しかし、このゲートウェイ同様の機能を実行する際、ホストは送信元経路付きデータグラムを転送するゲートウェイの全ての関連規則 [INTRO:2] に従わなければならない (MUST)。これは次の特定の機能を含み、このドキュメントで前に規定された、これに対応するホスト機能を上書きする
送信元経路付きデータグラムのホスト転送を制限する規則を定義するために、もし次ホップがデータグラムが到達する際に同じ物理インタフェースを通るならば "ローカル送信元ルーティング" という用語を、さもなくば "非ローカル送信元ルーティング" という用語を使用する。
もしホストが、完成していない送信元経路が付いているが、何らかの理由により転送できないデータグラムを受信したら、ホストは ICMP 宛先未到達メッセージ (コード 5、送信元経路障害) を返却すべきである (SHOULD)。
セクション 3.2.1.3 は、4 つの IP ブロードキャストアドレス形式の標準を定義した。
制限付きブロードキャスト: {-1, -1}
直接ブロードキャスト: {<ネットワーク番号>, -1}
サブネット直接ブロードキャスト: {<ネットワーク番号>,<サブネット番号>,-1}
全サブネット直接ブロードキャスト: {<ネットワーク番号>,-1,-1}
ホストは、入力データグラムの宛先アドレスにおいて、これらのいずれの形式も認識しなければならない (MUST)
-1 の代わりに 0 を用いる、非標準のブロードキャストアドレス形式を使用するホスト*
のクラスがある。全てのホストは、これらの非標準のブロードキャストアドレスを、入力データグラムの宛先アドレスとして認識して受け入れるべきである
(SHOULD)。ホストはオプションで、各物理インタフェースに対して、ブロードキャストアドレスの
0 か -1 形式を選択するための設定オプションを持ってもよい (MAY)。しかし、このオプションはデフォルトで標準
(-1) の形式にすべきである (SHOULD)。
*4.2BSD Unix とその派生。4.3BSD にはない。
ホストがデータグラムをリンク層ブロードキャストアドレスに送信するとき、IP 宛先アドリスは正しい IP ブロードキャストか IP マルチキャストアドレスでなければならない (MUST)。
ホストは、リンク層ブロードキャストを経て受信したが、IP マルチキャストかブロードキャスト宛先アドレスを示していないデータグラムを、黙って破棄すべきである (SHOULD) (セクション 2.4 参照)。
ホストは、接続されたネットワークにブロードキャストするための制限付きブロードキャストアドレスを使用すべきである (SHOULD)。
DISCUSSION:
直接ブロードキャストアドレスではなく制限付きブロードキャストアドレスを使用することは、システムの頑強性を改善する。問題は大抵、過多なブロードキャストアドレス
(セクション 3.2.1.3 参照)
を解釈しないマシンや、どのブロードキャストアドレスを使用しているかについて異なる考えを持つマシンによって引き起こされる。後者の主要な例は、サブネット化を解釈しないが、サブネット化されたネットに接続されているマシンである。接続されたネットワークでサブネットブロードキャストを送信すると、それらのマシンに混乱を及ぼし、他のホストへのメッセージとしてそれを見る可能性がある。
制限付きブロードキャストアドレス宛てのデータグラムを、マルチホーム化されたホストの全てのインタフェースから送信すべきか否かについて議論されている。この規約では、その問題について触れていない。
ホストは、クラス D の IP アドレスからリンク層アドレスへのマッピングが指定されている (下記参照) 全ての接続されたネットワーク上で、ローカルな IP マルチキャストをサポートすべきである (SHOULD)。ローカルな IP マルチキャストのサポートは、マルチキャストデータグラムの送信やマルチキャストグループへの加入、マルチキャストデータグラムの受信を含む。これは、オプションである IGMP プロトコル自身を除き、[IP:4] の全てのサポートすることを意味する。
DISCUSSION:
IGMP は、複数のネットワークに渡る IP マルチキャストをサポートするために必要な情報を持つ、マルチキャストルーティングができるゲートウェイを提供する。この時点では、マルチキャストルーティングゲートウェイは実験的な段階であり、広く利用できない。マルチキャストルーティングゲートウェイを持つネットワークに接続していないか、他のネットワーク上で起動されたマルチキャストデータグラムを受信する必要がないホストにとっては、GMP
の目的は無いので、現在はオプションである。しかし、ローカルブロードキャストアドレス付けの望ましい代替手段として、ローカルネットワークのマルチキャストアドレスへ、IP
層によるアクセスを提供する目的のために、[IP:4]
の残りの部分が現在推奨されている。マルチキャストルーティングゲートウェイがより広く利用可能になった時、将来的には、IGMP
が推奨されるようになるだろう。
もし IGMP が実装されなければ、ホストは IP 層が初期化された時に "全ホスト" グループ (224.0.0.1) に加入し、IP 層が活性である間はメンバのままでいるべきである (SHOULD)。
DISCUSSION:
"全ホスト" グループへの加入は、たとえ IGMP
が実装されていなくても、ゲートウェイ検出プロトコルなどの、厳密にローカルなマルチキャストの使用をサポートするだろう。IP クラス D
アドレスとローカルアドレスのマッピングは、以下のタイプのネットワークについて規定されている。
他のタイプのネットワークでのマッピングは、将来規定される予定である。
ホストは、上位レベルプロトコルかアプリケーションが、接続されたネットワークのどのホストが IP マルチキャストアドレスをサポートしているかを決定する方法を提供すべきである (SHOULD)。
実用的である場合は必ず、ホストはエラー検出時に ICMP エラーデータグラムを返却しなければならない (MUST)。ICMP エラーメッセージの返却が明示的に禁止されている場合は除く。
DISCUSSION:
データグラムネットワークにおける共通的な現象は、"ブラックホール状態"
である。それは、データグラムは送出されるが、何も戻ってこないことである。エラーデータグラムが無ければ、ユーザが問題が何であるか見つけることが困難である。
IP 層とトランスポート層の間のインタフェースは、オプションやサービスタイプ、生存時間を含む、IP 層の全てのメカニズムへの完全なアクセスを提供しなければならない (MUST)。トランスポート層は、これらのインタフェースパラメタを設定するためのメカニズムを持つか、アプリケーションから渡すためのパスを提供しなければならない (MUST)。
DISCUSSION:
たとえそのメカニズムがインターネット (例えば TOS)
は現在効果を持たなくても、アプリケーションは適用可能なこれらのメカニズムを使用することが推奨される。これにより、これらのメカニズムが有効になった時に、ホストソフトウェアの大規模な改造無しで、即座に効果を持つことができる。
我々はここで、トランスポート層と IP 層との間の概念的なインタフェースを、手続き呼び出しのセットとして規定する。これは RFC791 [IP:1] のセクション 3.3 の情報の拡張である。
* データグラムの送信
SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
=> result )
パラメタは RFC791 で定義されている。Id パラメタを渡すのはオプションである。セクション 3.2.1.5 を参照されたい。
* データグラムの受信
RECV(BufPTR, prot
=> result, src, dst, SpecDest, TOS, len, opt)
パラメタは、以下を除いて全て RFC791 で定義されている
SpecDest = データグラムの特定宛先アドレス (セクション 3.2.1.3 で定義)
結果パラメタの dst は、データグラムの宛先アドレスを含む。これはブロードキャストかマルチキャストアドレスかもしれないので、SpecDest パラメタ (RFC-791 には無い) を渡さなければならない (MUST)。パラメタ opt は、データグラム中で受信した全ての IP オプションを含む。これらはトランスポート層にも渡さなければならない (MUST)。
* 送信元アドレスの選択
GET_SRCADDR(remote, TOS) -> local remote = リモート IP アドレス TOS = サービスタイプ local = ローカル IP アドレス
セクション 3.3.4.3 参照。
* 最大データグラム長を検出する
GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S MMS_R = 最大受信トランスポートメッセージ長 MMS_S = 最大送信トランスポートメッセージ長 (local, remote, TOS は上記で定義)
セクション 3.3.2 とセクション 3.3.3 参照。
* 正常配送についてのアドバイス
ADVISE_DELIVPROB(sense, local, remote, TOS)
パラメタ sense は、所定のアドバイスが肯定か否定を指定する 1 ビットのフラグである。セクション 3.3.1.4 の議論を参照されたい。その他のパラメタは前に定義されている。
* ICMP メッセージの送信
SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
-> result
(パラメタは RFC-791 で定義)
Id パラメタを渡すのはオプションである。セクション 3.2.1.5 を参照されたい。トランスポート層は、ポート未到達かキュエリタイプのメッセージである ICMP メッセージを送信できなければならない (MUST)。この機能は SEND() 呼び出しの特殊ケースと見なすことができるが、明確にするために別々に説明している。
* ICMP メッセージの受信
RECV_ICMP(BufPTR ) -> result, src, dst, len, opt (パラメタは RFC-791 で定義)
IP 層は、ある ICMP メッセージを適切なトランスポート層ルーチンまで渡さなければならない (MUST)。この機能は RECV() 呼び出しの特殊ケースと見なすことができるが、明確にするために別々に説明している。
ICMP エラーメッセージでは、上位に渡されるデータは元のインターネットヘッダと、ICMP メッセージに含まれる元のメッセージの全てのオクテットを含まなければならない (MUST)。このデータは、もしあれば、トランスポート層によってコネクション状態情報を探し当てるために使われるかもしれない。
特に、以下の ICMP メッセージが上位に渡される。
DISCUSSION:
将来、このインタフェースに、IP 層とトランスポート層の間でパスデータ
(セクション 3.3.1.3 参照) を渡すことが追加されるかもしれない
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------------|--------|-|-|-|-|-|--
| | | | | | |
IP と ICMP の実装 |3.1 |x| | | | |
リモートマルチホームをアプリケーション層で処理 |3.1 |x| | | | |
ローカルマルチホームのサポート |3.1 | | |x| | |
データグラムを転送するならゲートウェイ要件に適合 |3.1 |x| | | | |
組込みゲートウェイ用の設定スイッチ |3.1 |x| | | | |1
設定スイッチのデフォルトは非ゲートウェイ |3.1 |x| | | | |1
インタフェースの数に基づく自動設定 |3.1 | | | | |x|1
破棄したデータグラムをログに採取できる |3.1 | |x| | | |
カウンタに記録 |3.1 | |x| | | |
| | | | | | |
パージョン != 4 を黙って破棄 |3.2.1.1 |x| | | | |
IP チェックサムをチェックし、不正なら黙って破棄 |3.2.1.2 |x| | | | |
アドレス付け: | | | | | | |
サブネットアドレス付け (RFC-950) |3.2.1.3 |x| | | | |
送信元アドレスはホスト自身の IP アドレスで |3.2.1.3 |x| | | | |
なければならない | | | | | | |
不正な宛先アドレスのデータグラムを黙って破棄 |3.2.1.3 |x| | | | |
不正な送信元アドレスのデータグラムを黙って破棄 |3.2.1.3 |x| | | | |
組立サポート |3.2.1.4 |x| | | | |
同じデータグラムに同じ Id フィールドを保持 |3.2.1.5 | | |x| | |
| | | | | | |
TOS: | | | | | | |
トランスポート層が TOS を設定可能 |3.2.1.6 |x| | | | |
受信した TOS をトランスポート層に渡す |3.2.1.6 | |x| | | |
TOS で RFC-795 リンク層マッピングを使用 |3.2.1.6 | | | |x| |
TTL: | | | | | | |
0 の TTL を持つパケットの送信 |3.2.1.7 | | | | |x|
TTL < 2 の受信パケットを破棄 |3.2.1.7 | | | | |x|
トランスポート層が TTL を設定可能 |3.2.1.7 |x| | | | |
固定値の TTL は設定可能 |3.2.1.7 |x| | | | |
| | | | | | |
IP オプション: | | | | | | |
トランスポート層が IP オプションを送信可能 |3.2.1.8 |x| | | | |
受信した全ての IP オプションを上位層に渡す |3.2.1.8 |x| | | | |
IP 層は未知のオプションを黙って無視 |3.2.1.8 |x| | | | |
セキュリティオプション |3.2.1.8a| | |x| | |
ストリーム識別子オプションの送信 |3.2.1.8b| | | |x| |
ストリーム識別子オプションを黙って無視 |3.2.1.8b|x| | | | |
経路記録オプション |3.2.1.8d| | |x| | |
タイムスタンプオプション |3.2.1.8e| | |x| | |
送信元経路オプション: | | | | | | |
送信元経路オプションの起動 & 終了 |3.2.1.8c|x| | | | |
完結した SR を持つデータグラムを TL に渡す |3.2.1.8c|x| | | | |
正しい (非冗長) 返却経路を生成 |3.2.1.8c|x| | | | |
複数の SR オプションを一つのヘッダで送信 |3.2.1.8c| | | | |x|
| | | | | | |
ICMP: | | | | | | |
未知のタイプの ICMP メッセージを黙って破棄 |3.2.2 |x| | | | |
元のデータグラムの 8 オクテット以上を含める |3.2.2 | | |x| | |
受信したものと同じオクテットを含める |3.2.2 |x| | | | |
ICMP エラーをトランスポートプロトコルに demux |3.2.2 |x| | | | |
TOS=0 で ICMP エラーメッセージを送信 |3.2.2 | |x| | | |
ICMP エラーメッセージの要因: | | | | | | |
- ICMP エラーメッセージ |3.2.2 | | | | |x|
- IP ブロードキャストか IP マルチキャスト |3.2.2 | | | | |x|
- リンク層ブロードキャスト |3.2.2 | | | | |x|
- フラグメントの先頭以外 |3.2.2 | | | | |x|
- ユニークでない送信元アドレスのデータグラム |3.2.2 | | | | |x|
(禁止されていなければ ICMP エラーメッセージ返却|3.3.8 |x| | | | |
| | | | | | |
宛先未到達: | | | | | | |
宛先未到達を生成する (コード 2/3) |3.2.2.1 | |x| | | |
ICMP 宛先未到達を上位層に渡す |3.2.2.1 |x| | | | |
上位層が宛先未到達に基づいて動作する |3.2.2.1 | |x| | | |
宛先未到達をヒントとしてのみ解釈する |3.2.2.1 |x| | | | |
リダイレクト: | | | | | | |
ホストがリダイレクトを送信 |3.2.2.2 | | | |x| |
リダイレクトを受信したとき経路キャッシュ更新 |3.2.2.2 |x| | | | |
ホストとネットの両方のリダイレクトを処理 |3.2.2.2 |x| | | | |
不正なリダイレクトを破棄 |3.2.2.2 | |x| | | |
送信元損失: | | | | | | |
バッファ超過ならば送信元損失送信 |3.2.2.3 | | |x| | |
送信元損失を上位層に渡す |3.2.2.3 |x| | | | |
上位層が送信元損失に基づいて動作する |3.2.2.3 | |x| | | |
時間超過: 上位層に渡す |3.2.2.4 |x| | | | |
パラメタ問題: | | | | | | |
パラメタ問題メッセージを送信する |3.2.2.5 | |x| | | |
パラメタ問題を上位層に渡す |3.2.2.5 |x| | | | |
パラメタ問題をユーザに通知する |3.2.2.5 | | |x| | |
| | | | | | |
ICMP エコー要求や応答: | | | | | | |
エコーサーバとエコークライアント |3.2.2.6 |x| | | | |
エコークライアント |3.2.2.6 | |x| | | |
ブロードキャストアドレス宛てエコー要求を破棄 |3.2.2.6 | | |x| | |
マルチキャストアドレス宛てエコー要求を破棄 |3.2.2.6 | | |x| | |
エコー応答の送信元として特定のアドレスを使用 |3.2.2.6 |x| | | | |
エコー応答で同じデータを送信する |3.2.2.6 |x| | | | |
エコー応答を上位層に渡す |3.2.2.6 |x| | | | |
経路記録、タイムスタンプオプションを反映 |3.2.2.6 | |x| | | |
送信元経路オプションを反転して反映 |3.2.2.6 |x| | | | |
| | | | | | |
ICMP 情報要求や応答: |3.2.2.7 | | | |x| |
ICMP タイムスタンプとタイムスタンプ応答: |3.2.2.8 | | |x| | |
遅延の変化を最小限にする |3.2.2.8 | |x| | | |1
ブロードキャストタイムスタンプを黙って破棄 |3.2.2.8 | | |x| | |1
マルチキャストタイムスタンプを黙って破棄 |3.2.2.8 | | |x| | |1
TS 応答の送信元として特定のアドレスを使用 |3.2.2.8 |x| | | | |1
経路記録、タイムスタンプオプションを反映 |3.2.2.6 | |x| | | |1
送信元経路オプションを反転して反映 |3.2.2.8 |x| | | | |1
タイムスタンプ応答を上位層に渡す |3.2.2.8 |x| | | | |1
"標準値" の規則に従う |3.2.2.8 |x| | | | |1
| | | | | | |
ICMP アドレスマスク要求や応答: | | | | | | |
アドレスマスクの送信元が設定可能 |3.2.2.9 |x| | | | |
アドレスマスクの静的設定のサポート |3.2.2.9 |x| | | | |
起動時に動的にアドレスマスクを取得 |3.2.2.9 | | |x| | |
ICMP アドレスマスク要求/応答を通じて取得 |3.2.2.9 | | |x| | |
応答が無ければアドレスマスク要求を再送 |3.2.2.9 |x| | | | |3
応答が無ければデフォルトマスクを仮定 |3.2.2.9 | |x| | | |3
一番目の応答のみアドレスマスクを更新 |3.2.2.9 |x| | | | |3
道理に合ったアドレスマスクのチェック |3.2.2.9 | |x| | | |
権威の無いアドレスマスク応答送信 |3.2.2.9 | | | | |x|
エージェントであると明示的に設定 |3.2.2.9 |x| | | | |
静的設定 -> アドレスマスクの権威フラグ |3.2.2.9 | |x| | | |
初期化時に Adr Mask 応答をブロードキャスト |3.2.2.9 |x| | | | |3
| | | | | | |
出力データグラムのルーティング: | | | | | | |
ローカル/リモートの決定でアドレスマスクを使用 |3.3.1.1 |x| | | | |
接続ネットワーク上ゲートウェイ無しで動作 |3.3.1.1 |x| | | | |
次ホップゲートウェイの "経路キャッシュ" を維持 |3.3.1.2 |x| | | | |
ホストとネットワークリダイレクトを等しく扱う |3.3.1.2 | |x| | | |
キャッシュエントリが無ければ、デフォルトを使用 |3.3.1.2 |x| | | | |
複数のデフォルトゲートウェイのサポート |3.3.1.2 |x| | | | |
静的経路のテーブルを提供 |3.3.1.2 | | |x| | |
フラグ: リダイレクトによって経路更新 |3.3.1.2 | | |x| | |
ネットアドレスでなくホストの経路キャッシュキー |3.3.1.3 | | |x| | |
経路キャッシュに TOS を含める |3.3.1.3 | |x| | | |
| | | | | | |
次ホップゲートウェイの障害検出 |3.3.1.4 |x| | | | |
経路が常に適切であると仮定 |3.3.1.4 | | | |x| |
絶え間無くゲートウェイを ping |3.3.1.4 | | | | |x|
トラフィックが送信された時のみ ping |3.3.1.4 |x| | | | |
肯定的な指示が無い時にのみ ping |3.3.1.4 |x| | | | |
上位と下位の層がアドバイスを提供 |3.3.1.4 | |x| | | |
障害のあるデフォルトゲートウェイから別のに切替 |3.3.1.5 |x| | | | |
設定情報を手動入力する方法 |3.3.1.6 |x| | | | |
| | | | | | |
組立と分割: | | | | | | |
入力データグラムを組立可能 |3.3.2 |x| | | | |
少なくとも 576 バイトのデータグラム |3.3.2 |x| | | | |
EMTU_R が設定可能か無限 |3.3.2 | |x| | | |
トランスポート層が MMS_R を知ることが可能 |3.3.2 |x| | | | |
組立タイムアウト時に ICMP 時間超過送信 |3.3.2 |x| | | | |
固定の組立タイムアウト値 |3.3.2 | |x| | | |
| | | | | | |
MMS_S を上位層に渡す |3.3.3 |x| | | | |
出力パケットのローカルな分割 |3.3.3 | | |x| | |
さもなくば MMS_S より大きいものを送信しない |3.3.3 |x| | | | |
オフネットの宛先には最大 576 で送信 |3.3.3 | |x| | | |
全サブネット MTU 設定フラグ |3.3.3 | | |x| | |
| | | | | | |
マルチホーム化: | | | | | | |
特定の宛先アドレスと同じアドレスで応答 |3.3.4.2 | |x| | | |
アプリがローカル IP アドレスを選択可能 |3.3.4.2 |x| | | | |
"誤った" インタフェースの d'gram を黙って破棄 |3.3.4.2 | | |x| | |
"正しい" インタフェースにデータグラムを送信 |3.3.4.2 | | |x| | |4
| | | | | | |
送信元経路転送: | | | | | | |
送信元経路オプション付きのデータグラム転送 |3.3.5 | | |x| | |1
対応するゲートウェイ規則に従う |3.3.5 |x| | | | |1
ゲートウェイ規則によって TTL 更新 |3.3.5 |x| | | | |1
ICMP エラーコード 4,5 を生成可能 |3.3.5 |x| | | | |1
ローカルホストではない IP 送信元アドレス |3.3.5 | | |x| | |1
タイムスタンプ、経路記録オプションの更新 |3.3.5 |x| | | | |1
非ローカル送信元ルーティングの設定可能な切替 |3.3.5 |x| | | | |1
デフォルトはオフ |3.3.5 |x| | | | |1
非ローカル SRing の gwy アクセス規則を満たす |3.3.5 |x| | | | |1
転送しないなら宛先未到達を送信 (コード 5) |3.3.5 | |x| | | |2
| | | | | | |
ブロードキャスト: | | | | | | |
IP 送信元アドレスとしてブロードキャストアドレス|3.2.1.3 | | | | |x|
0/-1 ブロードキャスト形式の受信可 |3.3.6 | |x| | | |
0/-1 ブロードキャスト送信の設定可能なオプション|3.3.6 | | |x| | |
デフォルトは -1 ブロードキャスト |3.3.6 | |x| | | |
全てのブロードキャストアドレス形式を認識可能 |3.3.6 |x| | | | |
リンク層 b'cast で IP b'cast/m'castアドレス使用|3.3.6 |x| | | | |
リンク層のみの b'cast データグラムを黙って破棄 |3.3.6 | |x| | | |
接続ネットで制限付き b'cast アドレス使用 |3.3.6 | |x| | | |
| | | | | | |
マルチキャスト: | | | | | | |
ローカル IP マルチキャストのサポート (RFC-1112)|3.3.7 | |x| | | |
IGMP (RFC-1112) サポート |3.3.7 | | |x| | |
起動時に全ホストグループに加入 |3.3.7 | |x| | | |
上位層がインタフェースマルチキャスト能力を知る |3.3.7 | |x| | | |
| | | | | | |
インタフェース: | | | | | | |
トランスポート層が全ての IP メカニズムを使用可 |3.4 |x| | | | |
インタフェース指示をトランスポート層に渡す |3.4 |x| | | | |
全ての IP オプションをトランスポート層に渡す |3.4 |x| | | | |
トランスポート層がある ICMP メッセージを送信可 |3.4 |x| | | | |
特定の ICMP メッセージをトランスポート層に渡す |3.4 |x| | | | |
元から IP ヘッダ + 8 オクテット以上含める |3.4 |x| | | | |
一回のバウンドで高いビルを跳べる |3.5 | |x| | | |
脚注:
ユーザデータグラムプロトコル UDP [UDP:1] は、最小限のトランスポートサービスのみ - 保証無しのデータグラム送信 - を提供し、アプリケーションが IP 層のデータグラムサービスに直接アクセスする手段を与える。UDP は TCP のサービスレベルを必要としない、あるいは TCP からは利用できない通信サービス (マルチキャストやブロードキャスト送信など) を使用したいアプリケーションによって使用される。
UDP はほとんどゼロのプロトコルである。IP 上で提供する唯一のサービスは、データのチェックサム付与とポート番号による多重化である。従って、コネクション型プロトコルが扱うエンドツーエンド通信上の問題、例えば信頼性の高い送信のための再送やパケット化、組立、フロー制御、輻輳回避などは、必要ならば UDP 上で動作するアプリケーションプログラムが直接取り扱わなければならない。IP と TCP の極めて複雑な結合は、UDP と UDP を使用する数多くのアプリケーションの結合に反映されるだろう。
UDP の規約に既知のエラーは存在しない。
UDP の良く知られたポートは、TCP の良く知られたポートと同じ規則に従う。以下のセクション 4.2.2.1 を参照されたい。
もしデータグラムが、処理中の LISTEN 呼び出しの無い UDP ポート宛てに到着したら、UDP は ICMP ポート未到達メッセージを送信すべきである (SHOULD)。
UDP は IP 層から受信した全ての IP オプションを、透過的にアプリケーション層に渡さなければならない (MUST)。
アプリケーションは、UDP データグラムで送信する IP オプションを指定できなければならず (MUST)、UDP はこれらのオプションを IP 層に渡さなければならない (MUST)。
DISCUSSION:
現在、UDP を通じて渡す必要がある唯一のオプションは、送信元経路、経路記録、タイムスタンプである。しかし、将来新しいオプションが定義されるかもしれず、UDP
はアプリケーションとやりとりするオプションの形式や内容を仮定する必要はないし、仮定すべきではない。ただし、IP 層のセキュリティオプションについては例外である。
UDP に基づくアプリケーションは、要求データグラムから送信元経路を獲得し、それに対応する応答を送信するために、反転した経路を提供する必要があるかもしれない。
UDP は、IP 層から受信した全ての ICMP エラーメッセージをアプリケーション層に渡さなければならない (MUST)。少なくとも概念上は、ERROR_REPORT ルーチンへの upcall で実現してもよい (セクション 4.2.4.1 参照)。
DISCUSSION:
UDP データグラムの送信により発生した ICMP エラーメッセージは、非同期で受信されることに注意されたい。ICMP エラーメッセージの受信を望む UDP
ベースのアプリケーションは、これらのメッセージが到着した時に、これらを多重分離するのに必要な状態を保持する責任がある。例えばアプリケーションは、この目的のために受信処理をペンディングし続けてもよい。またアプリケーションは、前に同じポートを使用して生じた、遅れた
ICMP エラーメッセージによる混乱を回避する責任がある。
ホストは、UDP チェックサムの生成と評価を行う機能を実装しなければならない (MUST)。UDP チェックサムを生成するか否かについては、アプリケーションが任意に制御できてもよい (MAY) が、デフォルトはチェックサム有りでなければならない (MUST)。
もし、0 でなく正しくないチェックサムが付与された UDP データグラムを受信したら、UDP はそのデータグラムを黙って破棄しなければならない (MUST)。チェックサムの無い UDP データグラムを破棄すべきか、アプリケーションに渡すかについては、アプリケーションが任意に制御できてもよい (MAY)。
DISCUSSION:
ローカルエリアネットワーク内でしか実行されない幾つかのアプリケーションは、効率化のために UDP チェックサム無しを選択した。UDP
チェックサム無しの正当性については、これまで非常に多く議論されている。
IMPLEMENTATION:
UDP チェックサムには、共通的な実装誤りがある。TCP チェックサムとは異なり、UDP チェックサムはオプションである。チェックサムが無いことを示すために、UDP
ヘッダのチェックサムフィールドで値 0 が送信される。もし送信側が実際に 0 の UDP チェックサムを算出したら、全て 1 (65535)
にしてチェックサムを送信しなければならない。0 と 65535 は 1 の補数計算では等しいので、受信側で特殊な動作は必要無い
UDP データグラムを受信したとき、その特定宛先アドレスはアプリケーション層に渡さなければならない (MUST)。
アプリケーションプログラムは、UDP データグラムの送信で使用するために、IP 送信元アドレスを指定できるか、あるいは未指定に (その場合、ネットワークソフトウェアが適切な送信元アドレスを選択するだろう) できなければならない (MUST)。選択された送信元アドレスをアプリケーション層に通知する方法が存在すべきである (SHOULD)。(例えば、アプリケーションは後で、対応するインタフェースからのみ応答データグラムを受信できる)。
DISCUSSION:
UDP を使用する要求/応答アプリケーションは、要求の特定宛先アドレスと同じ応答の送信元アドレスを使用すべきである。[INTRO:1]
の "一般的な問題" を参照されたい。
不正な IP アドレス (例えばブロードキャストやマルチキャストアドレス) を持つ UDP データグラムを受信したら、UDP か IP 層は破棄しなければならない。(セクション 3.2.1.3 参照)。
ホストが UDP データグラムを送信したとき、送信元アドレスはそのホストの IP アドレス (の一つ) でなければならない (MUST)。
UDP へのアプリケーションインタフェースは、このドキュメントのセクション 3.4 で規定されている IP/トランスポートインタフェースへの完全なサービスを提供しなければならない (MUST)。従って、UDP を使用するアプリケーションは、このドキュメントのセクション 3.4 で規定されている、GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), RECV_ICMP() 呼び出しの機能を必要とする。例えば、{インタフェース、リモートホスト、TOS} の三つの特定の組で、有効な最大の UDP 最大データグラム長を知るために、GET_MAXSIZES() を使うことができる。
アプリケーション層プログラムは、送信する UDP データグラムの IP オプションだけでなく、TTL と TOS 値も設定できなければならず (MUST)、これらの値は透過的に IP 層に渡さなければならない。UDP は受信した TOS をアプリケーション層まで渡してもよい (MAY)。
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------------|--------|-|-|-|-|-|--
| | | | | | |
UDP | | | | | | |
-------------------------------------------------|--------|-|-|-|-|-|--
| | | | | | |
UDP がポート未到達を送信 |4.1.3.1 | |x| | | |
| | | | | | |
UDP 中の IP オプション | | | | | | |
- 受信した IP オプションをアプリ層に渡す |4.1.3.2 |x| | | | |
- アプリ層は送信時に IP オプションを指定可能 |4.1.3.2 |x| | | | |
- UDP は IP オプションを IP 層に渡す |4.1.3.2 |x| | | | |
| | | | | | |
ICMP メッセージをアプリケーション層に渡す |4.1.3.3 |x| | | | |
| | | | | | |
UDP チェックサム: | | | | | | |
- チェックサムを生成/照合できる |4.1.3.4 |x| | | | |
- 不正なチェックサムを黙って破棄する |4.1.3.4 |x| | | | |
- チェックサムを生成しない送信側オプション |4.1.3.4 | | |x| | |
- デフォルトはチェックサムを付与 |4.1.3.4 |x| | | | |
- チェックサムを必要とするための受信側オプション|4.1.3.4 | | |x| | |
| | | | | | |
UDP マルチホーム | | | | | | |
- 特定宛先アドレスをアプリケーションに渡す |4.1.3.5 |x| | | | |
- アプリ層がローカル IP アドレスを指定可能 |4.1.3.5 |x| | | | |
- アプリ層が wild ローカル IP アドレスを指定可能|4.1.3.5 |x| | | | |
- アプリ層に使用されるローカル IP アドレスを通知|4.1.3.5 | |x| | | |
| | | | | | |
不正な IP 送信元アドレスを UDP/IP が黙って破棄 |4.1.3.6 |x| | | | |
正しい IP 送信元アドレスのみ送信 |4.1.3.6 |x| | | | |
UDP アプリケーションインタフェースサービス | | | | | | |
アプリに対し完全な 3.4 の IP インタフェース |4.1.4 |x| | | | |
- データ送信時、TTL, TOS, IP オプション指定可能 |4.1.4 |x| | | | |
- 受信した TOS をアプリ層に渡す |4.1.4 | | |x| | |