| Prev | Next |
このチャプタとチャプタ 5 は、インターネット層で使用されるプロトコル、IP, ICMP, IGMP について論じている。ルータを論じるドキュメントでは、転送は明らかに重要なトピックなので、チャプタ 5 自体は転送に直接関連するプロトコルの側面に限定している。このチャプタは、インターネット層プロトコルのその他を含んでいる。
[INTERNET:1] で定義されているように、ルータは IP プロトコルを実装しなければならない (MUST)。ルータはさらにその必須の拡張、サブネット ([INTERNET:2] で定義)、IP ブロードキャスト ([INTERNET:3] で定義)、クラスレスドメイン間ルーティング (CIDR: [INTERNET:15] で定義)もまた実装しなければならない (MUST)。
ルータ実装者は、"インターネットプロトコル -- IP" のタイトルが付けられた [INTRO:2] のセクションに準拠しようと考える必要はない。なぜなら、そのセクションは全体的にこのドキュメントと重複し、このドキュメントに取って代わるからである。ルータは、[INTRO:2] の IP に関連する "特定の問題" (SPECIFIC ISSUE) のタイトルが付けられたセクションの要件に準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。
次に、あるケースで規定された動作は受信したデータグラムを黙って破棄することである。これは、以降の処理を行わずにデータグラムを破棄し、結果としてルータは如何なる ICMP エラーメッセージも送信しない (セクション [4.3] 参照) ことを意味する。しかし問題の診断のために、ルータはエラーをログ採取する機能 (セクション [1.3.3] 参照) を提供すべきであり (SHOULD)、黙って破棄したデータグラムの内容を含め、破棄したデータグラムの個数を数えるべきである (SHOULD)。
RFC791 [INTERNET:1] は、インターネットプロトコルの規約である。
ルータ自身によって受信されたデータグラムでは、IP 層は理解できる IP オプションを解釈し、その他は上位層プロトコルで使用するために変更せずに残しておかなければならない (MUST)。
上位層プロトコルは、送信するデータグラムに IP オプションを設定したり、受信するデータグラムの IP オプションを検査できることを必要とするかもしれない。このドキュメントの後半のセクションは、上位層プロトコルによって必要とされる特定の IP オプションのサポートについて論じている。
DISCUSSION
このメモも [INTRO:2] も、受信者が同じ IP
ヘッダ中の複数のオプションを処理しなければならない順番は定義していない。複数のオプションを含むデータグラムを作成するホストやルータは、送信元経路オプションと併用する時、あるオプションの意味が曖昧になることを知っておかねばならない。
以下は、特定の IP オプションの要件である。
(a) セキュリティオプション
ある環境では、生成、あるいは受信された全てのパケットにセキュリティオプションを必要とする。ルータは、[INTERNET:5]
で規定されている改訂されたセキュリティオプションを実装すべきである (SHOULD IMPLEMENT)。
DISCUSSION
[INTERNET:1] と RFC1038
([INTERNET:16])
で規定されているセキュリティオプションは、廃止されたことに注意されたい。
(b) ストリーム識別子オプション
このオプションは廃止された。ルータは自分が生成するデータグラムにこのオプションを付加すべきでない
(SHOULD NOT)。ルータは、受信したデータグラムのこのオプションを無視しなければならない (MUST)。
(c) 送信元経路オプション
ルータは、送信元経路の最終宛先として動作できなければならない
(MUST)。もしルータが完了した送信元経路を含むパケットを受信したら、そのパケットは最終宛先に到達している。そのようなオプションの場合、ポインタは最終フィールドを超えたところを指しており、IP
ヘッダ中の宛先アドレスはルータのアドレスになっている。受信したオプション (記録されている経路) は、トランスポート層 (あるいは ICMP メッセージ処理)
に渡さなければならない (MUST)。
通常のケースでは、送信元経路を持つデータグラムに対する正しい応答は同じ経路を辿る。ルータは、トランスポートプロトコルとアプリケーションが、受信したデータグラム中の送信元経路を逆戻りできる手段を提供しなければならない (MUST)。ルータがポリシー上の制約を知らない場合、反転させた送信元経路を、生成するデータグラムに挿入 (詳細は [INTRO:2] 参照) しなければならない (MUST)。しかし、もしルータがポリシーを知っているならば、別の経路を選択してもよい (MAY)。
ルータの幾つかのアプリケーションは、ユーザが送信元経路を入力できることを要求してもよい (MAY)。
ルータは複数の送信元経路オプションを含むデータグラムを生成してはならない (MUST NOT)。もし、複数の送信元経路オプションを含むパケットの転送を要求されたらルータが何をすべきかについては、セクション [5.2.4.1] で規定されている。
送信元経路オプションが生成される場合 (ルータが送信元経路付きデータグラムを発行するか、特殊なフィルタの結果として送信元経路を挿入する時に起こる)、たとえそれが送信元ホストを誤って含む (以下の議論のケース (B) 参照) 記録経路を反転することによって生成されるものであっても、正しく作成しなければならない (MUST)。
DISCUSSION
送信元経路が付加されたデータグラムが、ルータ G1, G2, Gn の順路を経て、送信元 S から宛先 D まで送られると仮定する。送信元 S は宛先アドレスとして
G1 の IP アドレスを持ち、データグラムが宛先までの残りの道を得るための送信元経路オプションを持つデータグラムを生成する。しかし、S
によって送信されたデータグラム中の送信元経路オプションが、以下の (A) か (B) のどれであるべきかについて規約は曖昧である。
(A): {>>G2, G3, ... Gn, D} <--- 正しい
(B): {S, >>G2, G3, ... Gn, D} <---- 誤り
(>> はポインタを表す)。もし (A) が送信されたら、D で受信するデータグラムは、IP 送信元アドレスが S で、宛先アドレスが D になり、オプション {G1, G2, ... Gn >>} を含む。もし (B) が送信されたら、D で受信するデータグラムは、(A) と同様に IP 送信元アドレスが S で、宛先アドレスが D であるが、オプションは {S, G1, ...Gn >>} である。すなわち、生成元ホストがその経路の第一ホップになってしまう。
(d) 経路記録オプション
ルータは、ルータが生成するデータグラムに記録経路オプションをサポートしてもよい (MAY)。
(e) タイムスタンプオプション
ルータは、ルータが生成するデータグラムにタイムスタンプオプションをサポートしてもよい (MAY)。以下の規則を適用する。
IMPLEMENTATION
タイムスタンプオプションに含まれるタイムスタンプの利用を最大限に活用するために、挿入されるタイムスタンプは、パケットがルータにほぼ実際に到着した時間であるべきである。ルータによって生成されるデータグラムの場合は、挿入されるタイムスタンプは、転送するためにリンク層にデータグラムをほぼ実際に渡した時間であるべきである。
タイムスタンプオプションは標準でないタイムクロックの使用を許しているが、時刻の合っていないタイムクロックの使用はタイムスタンプの有用性を制限する。従って、ルータは自分の時間を合わせるために、ネットワークタイムプロトコルを実装することが推奨される。
ルータは自分のアドレスを、経路記録や厳密な送信元と経路記録、厳密でない送信元と経路記録、タイムスタンプオプションに挿入することが求められる。ルータがこれらのオプションに自分のアドレスを挿入する場合、パケットを送信しようとしている物理インタフェースの IP アドレスを使用しなければならない。出力インタフェースが IP アドレスを持っていないために (例えば番号なしのインタフェース等)、この規則に従うことができない場合は、ルータは自分のルータ ID を代わりに挿入しなければならない (MUST)。ルータのルータ ID は、ルータの IP アドレスの一つである。ルータ ID はシステムベースで指定してもよいし、リンクベースで指定してもよい。ルータ ID として使用されるルータのアドレスは、ネットワーク管理者によって変更されない限り、(たとえリブートしても) 変更してはならない (MUST NOT)。関連する管理変更は、例えばルータ ID として使用される IP アドレスが、ルータの IP アドレスの一つから除くようなルータの再設定を伴う。複数の番号無しインタフェースを持つルータは、複数のルータ ID を持ってもよい (MAY)。各々の番号無しインタフェースは、特定のルータ ID を割り当てなければならない (MUST)。この割当ては、(たとえリブートしても) ルータを再設定せずに変更してはならない (MUST NOT)。
DISCUSSION
この規定は、ルータが IP アドレスを一つも持たないことを許していない。我々はこれが重大な制限であるとは考えていない。なぜなら、たとえルータがポイントツーポイント回線にしか接続されていなくても、チャプタ
[8] の管理しやすさの要件に適合するために、ルータは IP アドレスを必要とするからである。
IMPLEMENTATION
ルータ ID の選択において、この要件を満たす一つのあり得る方法は、ルータに割り当てられた IP アドレスのうち、数値上 (32 ビットの整数値としてアドレスを扱う)
最小の (あるいは最大の) IP アドレスを使用することである。
IP ヘッダは二つの予約ビットを含む。一つはサービスタイプのバイトで、もう一つはフラグフィールドである。ルータは、ルータによって生成されるデータグラムに、これらのビットのどちらにも 1 を設定してはならない (MUST NOT)。ルータは、単に一つ以上のこれらの予約ビットが 0 でない値であるという理由で、パケットを落と (受信/転送を拒否) してはならない (MUST NOT)。すなわち、ルータはそのビットをチェックしてはならない (MUST NOT)。
DISCUSSION
IP プロトコルの将来の改訂により、これらの未使用ビットが使用されるかもしれない。これらの規則は、インターネット内の全てのルータを同時にアップグレードすることなく、これらの改訂を展開できることを保証しようとしている。
IP ヘッダのサービスタイプバイトは、三つのセクションに分割される。それは、優先度フィールド (上位 3 ビット)、慣例的にサービスタイプまたは TOS と呼ばれているフィールド (次の 4 ビット)、予約ビット (残りのビット) である。
予約ビットの管理方法は、セクション [4.2.2.3] に記述されている。
TOS フィールドとその使用に関する詳細な議論は、[ROUTE:11] にある。
IP 優先度フィールドの規定は、セクション [5.3.3] に取って代わる。RFC795、サービスマッピングは廃止され、実装すべきではない (SHOULD NOT)。
セクション [5.2.2] で述べられているように、ルータは受信した如何なるパケットの IP チェックサムも検査しなければならず (MUST)、不正なチェックサムを含むメッセージを破棄しなければならない (MUST)。ルータは、このチェックサム検査を無効にする手段を提供してはならない (MUST NOT)。
IP ヘッダのうち唯一変わるものが生存時間だけである場合、ルータは IP ヘッダチェックサムの増分更新を使用してもよい (MAY)。これは、IP ヘッダの改悪をルータが検出しない可能性を減らす。チェックサムの増分更新の議論は [INTERNET:6] を参照されたい。
IMPLEMENTATION
実装時の詳細なヒントを含め、IP チェックサムついてのより詳細な規定は、[INTERNET:6]
と [INTERNET:7] で見ることができる。
ルータは認識できない IP オプションを無視しなければならない (MUST)。この要件により生ずる結果として、ルータはオプションリストの最終と操作無しオプションを実装しなければならない (MUST)。なぜなら、どちらも明示的な長さを含まないからである。
DISCUSSION
将来の IP オプションは全て明示的な長さを含むだろう。
[INTERNET:1] で説明されているように、ルータは分割をサポートしなければならない (MUST)。
ルータが IP データグラムを分割する時、ルータはフラグメントの個数を最小にすべきである (SHOULD)。ルータが IP データグラムを分割する時、ルータはフラグメントを順序通りに送信すべきである (SHOULD)。他よりも際立って小さい一つの IP フラグメントを生成するかもしれない分割方法では、一番最初の IP フラグメントを小さくしてもよい (MAY)。
DISCUSSION
インターネットでよく使われている幾つかの分割技術が存在する。一つは、一番始めを MTU サイズとし、その他をおよそ同じサイズで MTU よりも小さくし、IP
データグラムを IP フラグメントに分割する方法である。この理由は二つの面がある。シーケンスにおける一番最初の IP フラグメントは、ホスト間の現在のパスの有効
MTU であり、以降の IP フラグメントは IP データグラムをさらに分割することを最小限にするサイズとなる。もう一つの技術は、IP データグラムを MTU サイズの
IP フラグメントに分割し、最後のフラグメントのみ小さくする方法である。これは [INTERNET:1] で説明されている。
幾つかの TCP/IP 実装でよく使われているやり方は、IP データグラムがルータを通過して送られる時に、IP データグラムを 576 バイトを超えない IP フラグメントに分割する方法である。これは、結果的に IP フラグメントを更に分割せずに、残りの経路を通過させることを意図している。しかしこれは、より多くの IP フラグメントを一つの IP データグラムに組み立てることになるので、宛先ホストに大きな負荷をかけることになるだろう。また、MTU が一回しか変わらず、576 バイトよりもずっと大きいネットワーク上でも効率的ではない。例えば、MTU が 2048 である IEEE 802.5 ネットワークや、MTU が 1500 であるイーサネットネットワークといった LAN ネットワークが該当する。
もう一つ議論されている分割技術は、IP データグラムを、次ホップネットワークの MTU と等しいかそれ以下のサイズで、ほぼ等しいサイズの IP フラグメントに分割することである。この意図は、パスを下ってさらに分割された結果生じるフラグメントの個数を最小限に留め、各々のフラグメントに対して遅延が等しくなることを保証することである。
ルータが生成する IP フラグメントの数は、可能な限り最小限にすべきである (SHOULD)。
遅いマシンで作業していると、もしメッセージを分割する必要があるならば、最初に小さい IP フラグメントを送信した方が、遅いインタフェースを持つホストで全てのフラグメントを受信する機会が最大限に増えると思わせる。
関連した [INTRO:2] のセクションに規定されているように、ルータは自分に配送されたデータグラムの組み立てをサポートしなければならない (MUST)。
ルータによって生成、あるいは受信されたバケットを処理する生存時間 (TTL) は、[INTRO:2] が適用される。このセクションは、その規定を何も変更しない。しかし、[INTRO:2] の IP プロトコルのセクションの残りが書き直されたので、このセクションも同様である。
特にルータは、転送する時以外にパケットの TTL をチェックしてはならない (MUST NOT) ことに注意されたい。
ルータは、0 の生存時間 (TTL) の値を持つデータグラムを生成または転送してはならない (MUST NOT)。
ルータは、単に TTL が 0 か 1 で受信したという理由だけでデータグラムを破棄してはならない (MUST NOT)。もしそのデータグラムがルータ向けで、他の値が正しければ、ルータは受信を試みなければならない (MUST)。
ルータが生成するメッセージに対し、IP 層は送信される全てのデータグラムの TTL フィールドを設定する手段を、トランスポート層に提供しなければならない (MUST)。固定の TTL 値を使用する場合、その値は設定可能でなければならない (MUST)。その数は典型的なインターネットの直径を超えるべきであり (SHOULD)、現在の識者は成長を計算に入れてインターネットの直径の二倍を超えるべきであると提案している。現在提案されている値は通常、番号割当て RFC で公表されている。TTL フィールドは二つの役割を持っている。それは、TCP セグメントの生存時間を制限する (RFC793 [TCP:1], p.28) ことと、インターネットルーティングループを終結させることである。TTL は秒単位の時間であるが、各々のルータは TTL フィールドを少なくとも 1 減らす必要があるので、ホップ数の特性も持ち合わせている。
TTL の満了はルータによるデータグラムの破棄を意図しているが、宛先ホストで破棄することは意図していない。データグラムを転送することによってルータとして振舞うホストは、TTL に関するルータの規則に従わなければならない。
上位層プロトコルは、あるインターネット資源の "拡張スコープ" 検索を実装するために、TTL を設定することを望むかもしれない。これは何らかの診断ツールによって使用され、例えば IP マルチキャストを使用している所定のクラスの、"最も近い" サーバを捜し当てるのに効果的であることが期待される。特定のトランスポートプロトコルもまた、データグラムの最大生存時間に結び付けられた自分自身の TTL を指定したいかもしれない。
固定のデフォルト値は、少なくともインターネットの "直径"、すなわち有り得る最長パスほど十分大きくなければならない。継続的なインターネットの発展に備えるために、効率的な値は直径の約二倍である。ここで書かれているように、米国を渡るメッセージは、しばしば 15 から 20 のルータを横断する。デフォルトの TTL 値についての議論では 40 を超え、64 が一般的な値である。
全サブネットのブロードキャスト ([INTERNET:3] では複数サブネットブロードキャストと呼ばれる) は廃止された。セクション [5.3.5.3] 参照。
[2.2.5.1] に記述したように、現在クラス A からクラス E まで、5 個の IP アドレスのクラスが存在する。クラス D は IP マルチキャスト [INTERNET:4] で使用され、クラス E は実験的使用のために予約されている。クラス A, B, C のアドレスの区別はもはや重要ではない。それらは、一般化されたユニキャストネットワークプレフィクスとして使用され、クラスについては歴史的な興味しかない。
IP マルチキャストアドレスはホストのグループを表す 28 ビットの論理アドレスであり、永久的か一時的かのいずれかである。永久的マルチキャストアドレスは、インターネット番号割当て機関 [INTRO:7] によって割り当てられ、一時的アドレスは動的に一時的グループに割り当てられる。グループメンバシップは、IGMP [INTERNET:4] を使用して動的に決定される。
以下の IP アドレスの表記方法を用いて、汎用的なユニキャスト IP アドレスの重要な特殊ケースについて要約して説明する。
{ <Network-prefix>, <Host-number> }
全てのビットが 1 のフィールドは -1 と記述し、全てビットが 0 のフィールドは 0 と記述する。
(a) { 0, 0 }
このネットワーク上のこのホスト。ルータは (例えば、もしルータが設定情報をロードするために BOOTP を使用しているならば)
初期化手続きの一部で、これを送信元アドレスとして使用してもよい (MAY)。しかしこれを除いては、送信元アドレスとして使用してはならない
(MUST NOT)。
ローカル配送 ([5.2.3] 参照) のために受信された { 0, 0 } の送信元アドレスを持つ入力データグラムは、ルータがこれに関連するプロトコルを実装していて、実行すべき適切な動作をそのプロトコルが明確に定義しているならば、受信しなければならない (MUST)。さもなくば、送信元アドレスが { 0, 0 } であるローカル配送されたデータグラムを、ルータは黙って破棄しなければならない (MUST)。
DISCUSSION
あるプロトコルは、送信元アドレスが { 0, 0 } であるデータグラムの受信に応じて、ある特定の動作を定義している。二つの例は、BOOTP と ICMP
マスク要求である。これらのプロトコルの適切な処理は、送信元アドレスが { 0, 0 }
であるデータグラムを受信できる能力にしばしば依存する。しかし、大半のプロトコルは送信元アドレスが { 0, 0 }
であるデータグラムを無視することが最善である。それらは、恐らく誤って設定されたホストやルータによって生成されたからである。つまり、もしルータが { 0, 0 }
の送信元アドレスを持つデータグラムの扱い方を知っているならば、それを受信しなければならない
(MUST)。さもなくば、ルータはそれを破棄しなければならない (MUST)。
また、{ 0, 0 } の標準的でない使用については、セクション [4.2.3.1] を参照されたい。
(b) { 0, <Host-number> }
このネットワーク上の特定のホスト。ルータは自分の IP アドレスを知る初期化手続きの一部でこれを送信元アドレスとして使用してもよい (MAY)
が、それを除いてルータは送信してはならない (MUST NOT)。
(c) { -1, -1 }
限定されたブロードキャスト。送信元アドレスとして使用してはならない (MUST NOT)。
この宛先アドレスを持つデータグラムは、接続された物理ネットワーク上の全てのホストとルータによって受信される。しかし、ネットワークの外側には転送されない。
(d) { <Network-prefix>, -1 }
直接ブロードキャスト - 特定のネットワークプレフィクスに向けられたブロードキャスト。送信元アドレスとして使用してはならない
(MUST NOT)。ルータは、ネットワーク直接ブロードキャストパケットを生成してもよい
(MAY)。ルータは、ネットワーク直接ブロードキャストパケットを受信しなければならない
(MUST) が、これらのパケットの受信を止める設定オプションを持ってもよい
(MAY)。そのようなオプションは、デフォルトでは受信を許さなければならない (MUST)。
(e) { 127, <any> }
内部ホストループバックアドレス。この形式のアドレスは、ホストの外側に出てはならない (MUST NOT)。
<Network-prefix> は、デバイスが接続されているルーティングドメイン内で、値がユニークになるように管理上割り当てられる
上記に示した特殊なケースを除いて、IP アドレスは <Host-number> や <Network-prefix> フィールドに 0 か -1 の値を持つことが許されない。これは、各々のこれらのフィールドが少なくとも 2 ビット長であることを暗黙的に意味する。
DISCUSSION
このドキュメントの以前の版では、サブネット番号も 0 と -1 のいずれも使用不可であり、少なくとも 2 ビット長でなければならないことを記述していた。CIDR
の世界では、サブネット番号は明らかにネットワークプレフィクスの拡張であり、プレフィクスの残りが無ければ解釈できない。従って、このサブネット番号の制限は
CIDR の観点では無意味であり、無視しても差しつかえない。
ブロードキャストアドレスの更なる議論については、セクション [4.2.3.1] を参照されたい。
ルータはいかなるデータグラムを発行する時も、IP 送信元アドレスは自分の IP アドレスの一つ (ブロードキャストやマルチキャストアドレスは除く) でなければならない (MUST)。唯一の例外は、初期化の時である。
大抵の用途において、ブロードキャストやマルチキャストの宛先に向けられたデータグラムは、あたかもルータの IP アドレスの一つに向けられたかのように処理される。つまり、
特定の宛先アドレスという用語は、ホストのローカル IP アドレスと同等の意味を持つ。特定の宛先アドレスは、もしヘッダがブロードキャストやマルチキャストアドレスを含んでいなければ、IP ヘッダ内の宛先アドレスであると定義される。その場合、特定の宛先はデータグラムが到達した物理インタフェースに割り当てられた IP アドレスである。
ルータは、このセクションの規則により不正な IP 送信元アドレスを含む受信データグラムを、黙って破棄しなければならない (MUST)。この確認は、IP 層か (適切ならば) トランスポート層の各プロトコルのいずれかによって実施される。ルータはデータグラムを破棄する場合、データグラムを破棄した数をカウントすべきである (SHOULD)。
DISCUSSION
誤ったアドレスを持つデータグラムは、ユニキャストデータグラムのリンク層ブロードキャストによって、あるいは、設定が誤っている別のルータやホストによって引き起こされるかもしれない。
歴史的な理由により、IP パケットが IP ブロードキャストであることを示すために使用される沢山の IP アドレスが存在する (あるものは標準化され、あるものは標準化されていない)。ルータは、
DISCUSSION
二段落目に関して、ルータはそのネットワークプレフィクスへのインタフェースを持っていなければ、{ <Network-prefix>, 0 }
の形式のアドレスを明らかに認識することができない。その場合、ルータから見るとそのパケットは
IP ブロードキャストパケットではないので、二段落目の規則は適用されない。
IP ルータは、[INTRO:2] で規定されている IP マルチキャストに関連するホスト要件を満たすべきである (SHOULD)。IP ルータは、全ての接続されたネットワーク上のローカル IP マルチキャストをサポートすべきである (SHOULD)。IP マルチキャストアドレスからリンク層アドレスへのマッピングが規定された場合 (様々な IP-over-xxx 規約参照)、ルータはそのマッピングを使用すべきである (SHOULD)。または、その代わりとしてリンク層のブロードキャストを使用するよう設定可能にしてもよい (MAY)。ポイントツーポイント回線や他の全てのインタフェース上では、マルチキャストはリンク層のブロードキャストとしてカプセル化される。ローカル IP マルチキャストのサポートは、マルチキャストデータグラムの生成、マルチキャストグループへの加入、マルチキャストデータグラムの受信、マルチキャストグループからの離脱を含む。これは、IGMP (セクション [4.4] 参照) を含む [INTERNET:4] の全てをサポートすることを暗黙的に意味する。
DISCUSSION
[INTERNET:4] は IP マルチキャストのためのホスト拡張という題名であるが、全ての IP
システム、ホストとルータ両方に適用される。特にルータは、マルチキャストグループに加入してもよいので、ルータが IGMP
のホストの役割を実行し、グループメンバシップを、(自分がマルチキャストルータであるか否かに関わらず)
接続されたネットワーク上に存在するかもしれない全てのマルチキャストルータに通知することは正しい。
幾つかのルータプロトコルは、IP マルチキャストのサポートを明確に必要とするかもしれない (例えば OSPF [ROUTE:1]) し、あるいは推奨するかもしれない (例えば ICMP ルータ検出 [INTERNET:13])。
分割を避けたり最小限に留めるために、送信元から宛先までのパスに沿ったパス MTU を知ることが望ましい。パス MTU は、パスにおける各々のホップの最小値である。[INTERNET:14] は、任意のインターネットパスの最大転送単位 (MTU) を動的に検出する技術を説明している。[INTERNET:14] をサポートしていないルータを通過するパスについては、この技術では正しいパス MTU を検出しないかもしれない。しかし、その技術は古い技術や現在実行されている技術によって選択されるパス MTU と同等か、あるいはより正確なパス MTU を常に選択するだろう。
ルータが IP データグラムを生成する時、ルータは [INTERNET:14] で規定された、データグラムのサイズを限定するためのスキームを使用すべきである (SHOULD)。もしデータグラムの宛先へのルータの経路が、パス MTU 情報を提供するルーティングプロトコルから分かるならば、[INTERNET:14] で規定されているスキームを依然として使用するが、ルーティングプロトコルによるパス MTU 情報をパス MTU についての初期推測として、そしてパス MTU の上限として使用すべきである (SHOULD)。
ある環境下では、サブネット化されたネットワークの一部ではないパスを通じてのみ相互接続されている、ある特定のネットワークのサブネットをサポートすることが望ましいかもしれない。これは、隣接していないサブネットワークのサポートとして知られている。
ルータは、隣接していないサブネットワークをサポートしなければならない (MUST)。
IMPLEMENTATION
古い IP ネットワークでは、これを達成することが非常に難しかったが、CIDR ネットワークでは当然の副産物である。従って、ルータはサブネット体系を仮定すべきでない
(SHOULD NOT) が、各々の経路を汎用のネットワークプレフィクスとして扱うべきである (SHOULD)。
DISCUSSION
インターネットは、最近すごい勢いで成長している。これは IP アドレス付け技術に厳しい負担をかけている。この負担の主要な要因は、厳密な
IP アドレスクラスの境界である。これらは、ネットワークプレフィクスのサイズを効率的に定めたり、複数のネットワークプレフィクスを単一の経路通知に集約させることを困難にしている。IP
アドレスの厳密なクラス境界を取り除き、各経路を包括的なネットワークプレフィクスとして扱うことによって、これらの負担を大幅に減らすであろう。
現在これを行うための技術は、クラスレスドメイン間ルーティング (CIDR) [INTERNET:15] である。
同様な理由で、あるネットワークプレフィクスに割り当てられたアドレスブロックは、異なるサイズのサブブロックに更に分割することができる。そのため、サブブロックに割り当てられたネットワークプレフィクスは、異なる長さを持つだろう。例えば、ネットワークプレフィクスが 8 ビット長であるブロックの中で、あるサブブロックは 16 ビットのネットワークプレフィクスを持ってもよいし、またあるものは 18 ビットのネットワークプレフィクスを持ってもよいし、他にも 14 ビットのネットワークプレフィクスを持ってもよい。
ルータは、設定とルーティングデータベースの両方で可変長のネットワークプレフィクスをサポートしなければならない (MUST)。
ICMP は、ルーティングや診断、IP のエラー機能を提供する補助プロトコルである。それは [INTERNET:8] で規定されている。ルータは ICMP をサポートしなければならない (MUST)。
ICMP メッセージは、以下のセクションで論じられる二つのクラスにグループ化される。
ICMP エラーメッセージ 宛先未到達 セクション 4.3.3.1 リダイレクト セクション 4.3.3.2 送信元抑制 セクション 4.3.3.3 時間超過 セクション 4.3.3.4 パラメタ問題 セクション 4.3.3.5 ICMP キュエリメッセージ エコー セクション 4.3.3.6 情報 セクション 4.3.3.7 タイムスタンプ セクション 4.3.3.8 アドレスマスク セクション 4.3.3.9 ルータ検出 セクション 4.3.3.10
一般的な ICMP 要件と議論は、次のセクションにある。
未知のタイプの ICMP を受信したら、ICMP ユーザインタフェースに渡す (もしルータがそれを持っているならば) か、黙って破棄 (もしルータがインタフェースを持っていないならば) しなければならない (MUST)。
ICMP メッセージを生成する時、ルータは TTL を初期化しなければならない (MUST)。ICMP 応答の TTL は、応答の要因となったパケットから取得してはならない。
歴史的に、全ての ICMP エラーメッセージは、エラーの要因となったデータグラムのインターネットヘッダと、少なくとも最初の 8 データバイトを含んでいた。IP-IP トンネルや他の技術を使用するため、これはもはや適切ではない。従って、ICMP データグラムは 576 バイトの ICMP データ長を超えない範囲で、元のデータグラムを可能な限り多く含むべきである (SHOULD)。ルータはエラーを検出する前に転送時に通常実行した、IP ヘッダに対する如何なる修正 (例えば、TTL の減算やオプションの更新等) も取り消す必要が無いことを除いて、返却する IP ヘッダ (とユーザデータ) は、受信したものと同じでなければならない (MUST)。幾つかのケースでは、セクション [4.3.3.5] の要件がこの要件を上書きすることを注意されたい (例えばパラメタ問題メッセージにおいて、その問題が修正されたフィールドにあるならば、ルータはその修正を取り消さなければならない)。セクション [4.3.3.5] を参照されたい。
このドキュメントが他のケースを規定している部分を除き、ルータが生成する ICMP メッセージの IP 送信元アドレスは、ICMP メッセージを送信する物理インタフェースに割り当てられた IP アドレスの一つでなければならない (MUST)。もしインタフェースに割り当てられた IP アドレスが無いならば、代わりにルータのルータ ID (セクション [5.2.5] 参照) を使用する。
その TOS 値を設定すると、その宛先に振り分けることができない故に ICMP エラーメッセージが即座に破棄されるということがないならば、ICMP エラーメッセージは、そのメッセージの送信を誘発したパケット中の TOS ビットと同じ値が設定された TOS ビットを含むべきである (SHOULD)。さもなくば、ICMP エラーメッセージは通常の TOS (すなわち 0) で送信しなければならない (MUST)。ICMP 応答メッセージは、応答を引き起こした ICMP 要求の中の TOS ビットと同じ値を設定した TOS ビットを含むべきである (SHOULD)。
ICMP 送信元抑制エラーメッセージは、もし送信されたならば、ICMP 送信元抑制メッセージの送信を引き起こしたパケット中の IP 優先度フィールドと同じ値を、IP 優先度フィールドに持たなければならない (MUST)。他の全ての ICMP エラーメッセージ (宛先未到達、リダイレクト、時間超過、パラメタ問題) は、優先度値に 6 (インターネットワーク制御) か 7 (ネットワーク制御) を持つべきである (SHOULD)。これらのエラーメッセージの IP 優先度値は設定可能でもよい (MAY)。
ICMP 応答メッセージは、IP 優先度フィールドに、応答を引き起こした ICMP 要求の中の IP 優先度フィールドと同じ値を設定しなければならない (MUST)。
もし、ICMP エラーメッセージの送信を引き起こしたパケットが送信元経路オプションを含んでいたら、ICMP エラーメッセージは、同じタイプ (厳密または厳密でない) の送信元経路オプションも含むべきである (SHOULD)。それは、元のパケットの送信元経路オプション中の記録された経路のポインタの位置の前に、反転することによって作成される。これらは、ICMP エラーメッセージが、元のパケット中の送信元経路オプションに対して不平を示す ICMP パラメタ問題でないか、あるいはルータが ICMP エラーメッセージの配送を防ぐポリシーを知らない場合に行われる。
DISCUSSION
米国国防省セキュリティオプション ([INTERNET:5] で定義)
を使用する環境では、ICMP メッセージはセキュリティオプションを含む必要があるかもしれない。このトピックにおける詳細な情報は国防通信機関から入手すべきである。
ICMP エラーメッセージは以下の受信の結果で送信してはならない (MUST NOT)。
ICMP エラーメッセージ
さらに、このメモでパケットを黙って破棄するよう記述している場合は、ICMP エラーメッセージを送信してはならない (MUST NOT)。
注記: これらの制限は、ICMP エラーメッセージの送信に対するこのドキュメントのその他の要件よりも優先される。
DISCUSSION
これらの規則は、ルータやホストがブロードキャストパケットに応答して、ICMP
エラーメッセージを返却することによってブロードキャストの嵐が起こされることを防ぐ意図がある。例えば、存在しないポートへのブロードキャスト
UDP パケットは、その宛先ポートのためのクライアントを持たない全てのデバイスからの、ICMP
宛先未到達データグラムの洪水を引き起こし得る。大規模なイーサネット上では、結果として衝突が生じ、一秒以上もの間ネットワークが役に立たなくなり得る。
接続されたネットワーク上にブロードキャストされる全てのパケットは、その IP 宛先として正しい IP ブロードキャストアドレスを持つべきである (セクション [5.3.4] と [INTRO:2] 参照)。しかし、幾つかのデバイスはこの規則に違反している。従って、ブロードキャストパケットの検出を確実に行うために、ルータは IP 層のアドレスだけでなく、リンク層のブロードキャストをチェックする必要がある。
IMPLEMENTATION+
これは、リンク層がリンク層のブロードキャストパケットを受信した時に、IP 層に通知することを必要とする。セクション
[3.1] 参照。
ICMP 送信元抑制メッセージを送信するルータは、メッセージを生成する割合を制限できなければならない (MUST)。ルータは他の種類の ICMP エラーメッセージ (宛先未到達、リダイレクト、時間超過、パラメタ問題) を送信する割合も制限できるべきである (SHOULD)。割合制限パラメタは、ルータの設定の一部として設定可能であるべきである (SHOULD)。どのように制限が適用されるか (例えばルータ毎かインタフェース毎か) は、実装者の判断に任される。
DISCUSSION
ICMP エラーメッセージを送信するルータの二つの問題点は、
これらの問題の解決に役立たせるために、ルータは ICMP エラーメッセージを生成する頻度を制限できる。同様な理由で、ルータは例えば ICMP エコー応答など別の種類のメッセージを生成する頻度を制限してもよい。
IMPLEMENTATION
ICMP メッセージを送信する割合を制限するために、様々なメカニズムが使用され、提案されている。
もしルータが、パケット中に指定された宛先への経路が全く無い (デフォルト経路が無いことを含む) ためにパケットを転送できないならば、ルータはコード 0 (ネットワーク未到達) の ICMP メッセージ、宛先未到達を生成しなければならない (MUST)。もしルータがパケット中に指定された宛先ネットワークへの経路を持っているが、その経路で指定された TOS がデフォルト TOS (0000) でも、ルータが振り分けようと試みているパケットの TOS でもないならば、ルータはコード 11 (TOS のためにネットワーク未到達) の ICMP メッセージ、宛先未到達を生成しなければならない (MUST)。
もし、パケットが直接ルータに接続されたネットワーク上のホストに転送されるもの (つまりそのルータは最終ホップのルータ) で、ルータが宛先ホストへのパスが存在しないことを突きとめたならば、ルータはコード 1 (ホスト未到達) の ICMP メッセージ、宛先未到達を生成しなければならない (MUST)。もし、パケットが直接ルータに接続されたネットワーク上にあるホストに転送されたもので、パケットで要求された TOS と等しいか、デフォルト TOS (0000) である TOS を持つ宛先への経路が無いために、そのパケットを転送できないならば、ルータはコード 12 (TOS のためにホスト未到達) の ICMP メッセージ、宛先未到達を生成しなければならない (MUST)。
DISCUSSION
この意図は、ルータが宛先へのパス (デフォルト経路を含め) を全く持たないならば、"一般的な"
ホスト/ネットワーク未到達を生成することである。もしルータが経路への一つ以上のパスを持つが、いずれのパスも受諾できる TOS
を持たないならば、ルータは "TOS のために未到達" を生成する。
ICMP リダイレクトメッセージは、あるトラフィックで異なる次ホップのルータを使用すべきであることをローカルホストに通知するために生成される。
[INTRO:2] とは反対に、ルータはもしルーティングプロトコルを動かしているか、ルータやパケットを送信しようとしているインタフェース上で転送が有効であれば、ルータが生成したパケットのパスを選択する時に、ICMP リダイレクトを無視してもよい (MAY)。
ルータは ICMP 送信元抑制メッセージを生成すべきでない (SHOULD NOT)。セクション [4.3.2] で規定されているように、送信元抑制メッセージを生成するルータは、それを生成する割合を制限できなければならない (MUST)。
DISCUSSION
調査によると、送信元抑制はネットワーク帯域を浪費するが、輻輳を防ぐには非効率的 (不当)
であることが判明している。例えば、[INTERNET:9] と
[INTERNET:10] を参照されたい。セクション
[5.3.6] は、どのようにルータが負荷やネットワーク輻輳を扱うべきかについて、現在の考え方を論じている。
ルータは、受信した ICMP 送信元抑制メッセージを無視してもよい (MAY)。
DISCUSSION
ルータ自身は、別のルータやホストに送信するパケットを生成した結果、送信元抑制を受信するかもしれない。そのデータグラムは、例えば別のルータに送信された
EGP 更新や、ホストに送信された telnet ストリームかもしれない。パケットが送信される割合を制御することによって、IP
層に送信元抑制に対して直接応答させるメカニズムが提案されている ([INTERNET:11],
[INTERNET:12])。しかしこの提案は現在実験段階であり、現在は推奨されない。
ルータがパケットを転送し、パケットの TTL フィールドが 0 に減らされる時、セクション [5.2.3.8] の要件が適用される。
ルータがルータ宛てのパケットを組み立てる時、インターネットホストとして動作する。従って、[INTRO:2] の組み立て要件を適用する。
ルータが (ルータ宛ての) 時間超過メッセージを受信する時、[INTRO:2] に従わなければならない (MUST)。
他の ICMP メッセージで特にカバーされていないエラーについては、ルータはパラメタ問題メッセージを生成しなければならない (MUST)。IP ヘッダフィールドやポインタフィールドによって指されたバイトを含む IP オプションは、この ICMP メッセージで返却する IP ヘッダの中に、変更せずに含めなければならない (MUST)。セクション [4.3.2] は、この要件に対する例外を定義している。
パラメタ問題メッセージの新たな変形は、[INTRO:2] で定義された。
Code 1 = 必要なオプションが省略されている
DISCUSSION
この変形は現在、軍部でセキュリティオプションの省略に対して使用されている。
ルータは自分に送信されたエコー要求を受信し、それに対するエコー応答を送信する、ICMP エコーサーバ機能を実装しなければならない (MUST)。ルータは少なくとも最大 576 と、接続された全てのネットワークの MTU で、ICMP エコー要求データグラムを受信し、組み立て、エコーする準備をしなければならない (MUST)。
エコーサーバ機能は、IP ブロードキャストか IP マルチキャストアドレスを持つ ICMP エコー要求に応答しないことを選択してもよい (MAY)。
ルータはもし可能ならば、全ての ICMP エコー要求を黙って無視させる設定オプションを持つべきである (SHOULD)。もし提供されるならば、このオプションはデフォルトで応答を許さなければならない (MUST)。
DISCUSSION
ブロードキャストやマルチキャストのエコー要求についての、この曖昧な規定は、[INTRO:2] の
"エコー要求/応答" セクションが由来である。
セクション [10.3.3] で述べられているように、ルータは診断のために、エコー要求を送信したりエコー応答を受信するための、ユーザ/アプリケーション層のインタフェースも実装しなければならない (MUST)。全ての ICMP エコー応答メッセージは、このインタフェースに渡さなければならない (MUST)。
ICMP エコー応答の中のIP送信元アドレスは、対応する ICMP エコー要求メッセージの特定の宛先アドレスと同じでなければならない (MUST)。
ICMP エコー要求の中で受信したデータは、結果として生じたエコー応答に全体を含めなければならない (MUST)。
もし ICMP エコー要求の中に経路記録やタイムスタンプオプションを受信したら、このオプション (これらのオプション) を取り除かずに、現在のルータを含めるために更新し、エコー応答メッセージの IP ヘッダに含めるべきである (SHOULD)。従って、記録された経路は全体の往復経路になるだろう。
もし ICMP エコー要求の中に送信元経路オプションを受信したら、ルータがメッセージの配送を妨げるポリシーを知らないならば、返却経路を反転させてエコー応答メッセージの送信元経路オプションとして使用しなければならない (MUST)。
ルータは、これらのメッセージを生成したり応答すべきではない (SHOULD NOT)。
DISCUSSION
情報要求/応答のペアは、ディスクレスワークステーション等のような自己設定システムのサポートや、ブート時に
IP ネットワークプレフィクスを発見できることを意図していた。しかし、これらのメッセージは現在は廃止されている。ホストが自分の
IP アドレスを発見するために、RARP と BOOTP プロトコルがよりよいメカニズムを提供している。
ルータは、タイムスタンプとタイムスタンプ応答を実装してもよい (MAY)。もしそれらが実装されているならば、
タイムスタンプ値 (標準値) における好ましい形式は、世界時の真夜中からのミリ秒である。しかし、ミリ秒の分解能でこの値を提供することは難しいかもしれない。例えば、多くのシステムは一秒間に 5, 60 回のライン頻度でしか更新しないクロックを使用している。従って、標準値には多少の許容範囲が認められている。
IMPLEMENTATION
二番目の条件を適えるために、ルータは起動するか再開する時に、時刻サーバにキュエリを送る必要があるかもしれない。この目的のために、UDP
時刻サーバプロトコルを使用することが推奨される。より進歩した実装は、ミリ秒のクロック同期をほぼ達成するために、ネットワークタイムプロトコル
(NTP: Network Time Protocol) を使用するだろう。しかし、これは必須ではない。
ルータはアドレスマスク要求メッセージの受信をサポートし、ICMP アドレス応答メッセージで応答しなければならない (MUST)。これらのメッセージは [INTERNET:2] で定義されている。
ルータは各々の論理インタフェースにおいて、ルータがそのインタフェースでアドレスマスク要求に答えることを許すか否かを指定する設定オプションを持つべきである (SHOULD)。そして、このオプションはデフォルトで応答を許可しなければならない (MUST)。ルータは、正しいアドレスマスクを知る前にアドレスマスク要求に応答してはならない (MUST NOT)。
ルータは、0.0.0.0 の送信元アドレスを持ち、複数の論理インタフェースに割り当てられ、それらのインタフェースのアドレスマスクが全て同じではない物理インタフェース上に到着したアドレスマスク要求に応答してはならない (MUST NOT)。
ルータは、含まれている情報がアドレスマスクに関するルータの認識と一致しているか否かを決定するために、受信した全ての ICMP アドレスマスク応答を検査すべきである (SHOULD)。もし ICMP アドレスマスク応答にエラーが見つかったら、ルータはそのアドレスマスクと送信側の IP アドレスをログに採取すべきである (SHOULD)。ルータは、ICMP アドレスマスク応答の内容を、正しいアドレスマスクを決めるのに使用してはならない (MUST NOT)。
ホストが立ち上がった時にルータが停止していたら、ホストはアドレスマスクを認識できないかもしれないので、ルータは自分のアドレスマスクを設定した後で、各々の論理インタフェース上に 自発的な ICMP アドレスマスク応答をブロードキャストしてもよい (MAY)。しかし、この機能は可変長のアドレスマスクを使用する環境では危険になり得る。従って、もしこの機能を実装するならば、自発的なアドレスマスク応答は、以下に該当する論理インタフェース上には、どれにもブロードキャストしてはならない (MUST NOT)。
アドレスマスク応答をブロードキャストする際、IP ブロードキャストアドレスの { <Network-prefix>, -1 } 形式を使用しなければならない (MUST)。
DISCUSSION
アドレスマスク応答の送信をルータによって無効にする能力は、アドレスマスクについて意図的にホストに嘘をつく幾つかのサイトで必要である。この必要性は、ホストがホスト要件の標準に準拠するにつれて無くなることが期待される。
上記の二段落目と、使用される IP ブロードキャストアドレスに関する要件の両方の理由は、複数の IP ネットワークプレフィクスが同じ物理ネットワーク上で使用される際の問題を避けることである。
IP ルータは、IP マルチキャストか IP ブロードキャストアドレス付けをサポートしている全ての接続されたネットワーク上で、ICMP ルータ検出プロトコル [INTERNET:13] のルータ部をサポートしなければならない (MUST)。実装体は、ルータで規定されている設定変数の全てを、規定されているデフォルト値で含まなければならない (MUST)。
DISCUSSION
ルータは、ICMP ルータ検出プロトコルのホスト部を実装する必要はないが、IP 転送が無効の間
(すなわちホストとして動作している時)、ホスト部を実装していることは運用上効果的かもしれない。
DISCUSSION
ホストがルータ検出プロトコルとして RIP バージョン 1 を試用することは、かなり一般的である。そのようなホストは
RIP トラフィックをリッスンし、そのトラフィックから抽出された情報を使用してルータを検出し、ある宛先において第一ホップルータとしてどのルータを使用するか決める。この動作は推奨されないが、依然として一般的であり、実装者はこのことを知っておくべきである。
IGMP [INTERNET:4] は、単一の物理ネットワーク上のホストとマルチキャストルータ間で、特定のマルチキャストグループ内でホストのメンバーシップを確立するために、使用されるプロトコルである。マルチキャストルータは、インターネットを渡って IP マルチキャスト転送をサポートするために、マルチキャストルーティングプロトコルと共にこの情報を使用する。
ルータは、IGMP のホスト部を実装すべきである (SHOULD)。
| Prev | Next |