メインコンテンツまでスキップ

4. Internet Layer - Protocols (インターネット層 - プロトコル)

4. Internet Layer - Protocols (インターネット層 - プロトコル)​

4.1 Introduction (はじめに)​

本章と第5章では、インターネット層で使用されるプロトコルであるIP、ICMP、およびIGMPについて扱います。ルータに関する文書において、フォワーディングが中心的なトピックであることは明らかであるため、第5章はフォワーディングに直接関連するプロトコルの側面に限定されています。本章には、インターネット層プロトコルに関する残りの議論が含まれています。

4.2 Internet Protocol - IP (インターネットプロトコル)​

4.2.1 Introduction (はじめに)​

ルータは[INTERNET:1]で定義されているIPプロトコルを実装しなければなりません(MUST)。また、その必須拡張機能であるサブネット([INTERNET:2]で定義)、IPブロードキャスト([INTERNET:3]で定義)、およびクラスレスドメイン間ルーティング(CIDR、[INTERNET:15]で定義)も実装しなければなりません(MUST)。

ルータの実装者は、[INTRO:2]の"Internet Protocol -- IP"というタイトルの章への適合性を考慮する必要はありません。なぜなら、その章は本文書で完全に繰り返されているか置き換えられているからです。ルータは、[INTRO:2]の"SPECIFIC ISSUES"というタイトルのセクションにおけるIPに関する要件に適合しなければならず(MUST)、無条件に適合すべきです(SHOULD)。

以下では、いくつかのケースにおいて、指定された操作は受信したデータグラムを静かに破棄することです。これは、データグラムがそれ以上の処理なしに破棄され、ルータがその結果としてICMPエラーメッセージを送信しないことを意味します(セクション[4.3]参照)。ただし、問題を診断するために、ルータは静かに破棄されたデータグラムの内容を含むエラーをログに記録する機能を提供すべきであり(SHOULD)(セクション[1.3.3]参照)、破棄されたデータグラムをカウントすべきです(SHOULD)。

4.2.2 Protocol Walk-Through (プロトコルの概要)​

RFC 791 [INTERNET:1]はインターネットプロトコルの仕様です。

4.2.2.1 Options: RFC 791 Section 3.2 (オプション)​

ルータ自身が受信したデータグラムでは、IP層は理解できるIPオプションを解釈し、残りはそのまま上位層プロトコルに渡さなければなりません(MUST)。

上位層プロトコルは、送信するデータグラムにIPオプションを設定する機能、または受信するデータグラムのIPオプションを調べる機能が必要な場合があります。本文書の後続セクションでは、上位層プロトコルが必要とする特定のIPオプションサポートについて説明します。

DISCUSSION (議論)

本メモも[INTRO:2]も、受信者が同じIPヘッダ内の複数のオプションを処理すべき順序を定義していません。複数のオプションを含むデータグラムを開始するホストとルータは、これがソースルートオプションと組み合わされた場合にオプションの意味にいくつかの曖昧さをもたらすことを認識しておく必要があります。

以下は、特定のIPオプションに関する要件です。

(a) Security Option (セキュリティオプション)

一部の環境では、開始または受信するすべてのパケットにセキュリティオプションが必要です。ルータは[INTERNET:5]で説明されている改訂されたセキュリティオプションを実装すべきです(SHOULD)。

DISCUSSION (議論)

[INTERNET:1]およびRFC 1038 ([INTERNET:16])で説明されているセキュリティオプションは廃止されていることに注意してください。

(b) Stream Identifier Option (ストリーム識別子オプション)

このオプションは廃止されています。ルータは開始するデータグラムにこのオプションを設定すべきではありません(SHOULD NOT)。ルータが受信したデータグラムのこのオプションは無視しなければなりません(MUST)。

(c) Source Route Options (ソースルートオプション)

ルータはソースルートの最終宛先として動作できなければなりません(MUST)。ルータが完了したソースルートを含むパケットを受信した場合、そのパケットは最終宛先に到達しています。そのようなオプションでは、ポインタは最後のフィールドを超えており、IPヘッダの宛先アドレスはルータのアドレスです。受信したオプション(記録されたルート)はトランスポート層(またはICMPメッセージ処理)に渡さなければなりません(MUST)。

一般的なケースでは、ソースルーティングされたデータグラムへの正しい応答は同じルートを通過します。ルータは、トランスポートプロトコルとアプリケーションが受信したデータグラムのソースルートを反転できる方法を提供しなければなりません(MUST)。ルータがポリシー制約を知らない場合、この反転されたソースルートは開始するデータグラムに挿入しなければなりません(MUST)(詳細は[INTRO:2]参照)。ただし、ルータがポリシーを認識している場合は、別のパスを選択してもかまいません(MAY)。

ルータの一部のアプリケーションでは、ユーザーがソースルートを入力できることが必要な場合があります(MAY)。

ルータは複数のソースルートオプションを含むデータグラムを開始してはなりません(MUST NOT)。複数のソースルートオプションを含むパケットを転送する際にルータがどのように処理すべきかについては、セクション[5.2.4.1]で説明されています。

ソースルートオプションが作成される場合(これはルータがソースルーティングされたデータグラムを開始するとき、または特別なフィルタのためにソースルートオプションが挿入されるときに発生します)、ソースホストを誤って含む記録されたルートを反転して作成された場合でも、正しく形成されなければなりません(MUST)(以下の議論のケース(B)参照)。

DISCUSSION (議論)

ソースルーティングされたデータグラムが、ソースSからルータG1、G2、Gnを経由して宛先Dにルーティングされる必要があるとします。ソースSは、宛先アドレスがG1のIPアドレスであり、データグラムを残りの宛先に配信するソースルートオプションを含むデータグラムを構築します。ただし、Sが発行するデータグラムのソースルートオプションが(A)であるべきか(B)であるべきかについて、仕様には曖昧さがあります。

(A): {>>G2, G3, ... Gn, D} <--- 正しい

(B): {S, >>G2, G3, ... Gn, D} <---- 誤り

(>>はポインタを示します)。(A)が送信された場合、Dで受信されるデータグラムには、オプション{G1, G2, ... Gn >>}が含まれ、SとDがIPソースおよび宛先アドレスとなります。(B)が送信された場合、Dで受信されるデータグラムには、再びSとDが同じIPソースおよび宛先アドレスとして含まれますが、オプションは{S, G1, ...Gn >>}となります。つまり、発信ホストがルートの最初のホップになります。

(d) Record Route Option (ルート記録オプション)

ルータは開始するデータグラムでルート記録オプションをサポートしてもかまいません(MAY)。

(e) Timestamp Option (タイムスタンプオプション)

ルータは開始するデータグラムでタイムスタンプオプションをサポートしてもかまいません(MAY)。以下の規則が適用されます。

  • タイムスタンプオプションを含むデータグラムを開始する場合、ルータは以下の場合にオプションにタイムスタンプを記録しなければなりません(MUST)。

    • そのインターネットアドレスフィールドが事前指定されていない場合、または
    • その最初の事前指定されたアドレスが、データグラムを送信する論理インターフェースのIPアドレスである場合(または、データグラムが番号なしインターフェース経由で送信される場合はルータのrouter-id)。

  • ルータ自身がタイムスタンプオプションを含むデータグラムを受信した場合、ルータは(オプションにスペースがあれば)タイムスタンプオプションに現在時刻を挿入してから(MUST)、オプションをトランスポート層またはICMP層に渡して処理させなければなりません。スペースがない場合、ルータはオプションのオーバーフローカウンタをインクリメントしなければなりません(MUST)。

  • タイムスタンプ値は[INTRO:2]で定義された規則に従わなければなりません(MUST)。

IMPLEMENTATION (実装)

タイムスタンプオプションに含まれるタイムスタンプの有用性を最大化するために、挿入されるタイムスタンプは、パケットがルータに到着する時刻にできるだけ近い時刻であるべきです。ルータが開始するデータグラムの場合、挿入されるタイムスタンプは、データグラムが送信のためにリンク層に配信される時刻にできるだけ近い時刻であるべきです。

タイムスタンプオプションは非標準時間クロックの使用を許可していますが、同期されていないクロックの使用はタイムスタンプの有用性を制限します。したがって、ルータはクロックを同期するためにネットワークタイムプロトコルを実装することが推奨されます。

4.2.2.2 Addresses in Options: RFC 791 Section 3.1 (オプション内のアドレス)​

ルータは、ルート記録、厳密なソースおよびルート記録、緩いソースおよびルート記録、またはタイムスタンプオプションに自分のアドレスを挿入するよう求められます。ルータがそのようなオプションに自分のアドレスを挿入する場合、パケットを送信する論理インターフェースのIPアドレスを使用しなければなりません(MUST)。出力インターフェースにIPアドレスが関連付けられていないため(つまり、番号なしインターフェース)、この規則を遵守できない場合、ルータは代わりにそのrouter-idを挿入しなければなりません(MUST)。ルータのrouter-idは、ルータのIPアドレスの1つです。ルータIDは、システム単位またはリンク単位で指定できます(MAY)。router-idとして使用されるルータのアドレスは、ネットワーク管理者が変更しない限り、(再起動後でも)変更してはなりません(MUST NOT)。関連する管理上の変更には、router-idとして使用されるIPアドレスがルータのIPアドレスの1つでなくなるようにルータを再構成することが含まれます。複数の番号なしインターフェースを持つルータは、複数のrouter-idを持ってもかまいません(MAY)。各番号なしインターフェースは、特定のrouter-idに関連付けられなければなりません(MUST)。この関連付けは、ルータを再構成せずに(再起動後でも)変更してはなりません(MUST NOT)。

DISCUSSION (議論)

この仕様は、少なくとも1つのIPアドレスを持たないルータを許可しません。ルータがポイントツーポイントリンクのみに接続されている場合でも、ルータは第[8]章の管理可能性要件を満たすためにIPアドレスが必要であるため、これを深刻な制限とは考えていません。

IMPLEMENTATION (実装)

この要件を満たすrouter-idを選択する1つの可能な方法は、ルータに割り当てられた数値的に最小(または最大)のIPアドレスを使用することです(アドレスを32ビット整数として扱います)。

4.2.2.3 Unused IP Header Bits: RFC 791 Section 3.1 (未使用のIPヘッダビット)​

IPヘッダには2つの予約ビットが含まれています。1つはType of Serviceバイトに、もう1つはFlagsフィールドにあります。ルータは開始するデータグラムでこれらのビットのいずれも1に設定してはなりません(MUST NOT)。ルータは、これらの予約ビットの1つ以上がゼロ以外の値を持つという理由だけでパケットを破棄(受信または転送を拒否)してはなりません(MUST NOT)。つまり、ルータはこれらのビットの値を調べてはなりません(MUST NOT)。

DISCUSSION (議論)

IPプロトコルの将来の改訂版では、これらの未使用ビットが使用される可能性があります。これらの規則は、そのような改訂版がインターネット上のすべてのルータを同時に更新することなく展開できることを保証することを目的としています。

4.2.2.4 Type of Service: RFC 791 Section 3.1 (サービスタイプ)​

IPヘッダのType-of-Serviceバイトは3つの部分に分かれています。Precedenceフィールド(最上位3ビット)、一般にType of ServiceまたはTOSと呼ばれるフィールド(次の4ビット)、および予約ビット(最下位ビット)です。

予約ビットの規則はセクション[4.2.2.3]で説明されています。

TOSフィールドとその使用に関するより広範な議論は[ROUTE:11]にあります。

IP Precedenceフィールドの説明はセクション[5.3.3]で置き換えられています。RFC 795、Service Mappingsは廃止されており、実装すべきではありません(SHOULD NOT)。

4.2.2.5 Header Checksum: RFC 791 Section 3.1 (ヘッダチェックサム)​

セクション[5.2.2]で説明されているように、ルータは受信したすべてのパケットのIPチェックサムを検証しなければならず(MUST)、無効なチェックサムを含むメッセージを破棄しなければなりません(MUST)。ルータはこのチェックサム検証を無効にする手段を提供してはなりません(MUST NOT)。

ルータは、IPヘッダへの唯一の変更がTime-to-Liveである場合、IPヘッダチェックサムの増分更新を使用してもかまいません(MAY)。これにより、ルータがIPヘッダの検出されない破損を持つ可能性が減少します。チェックサムの増分更新に関する議論については、[INTERNET:6]を参照してください。

IMPLEMENTATION (実装)

IPチェックサムのより完全な説明(多くの実装アドバイスを含む)は、[INTERNET:6]および[INTERNET:7]にあります。

4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1 (認識されないヘッダオプション)​

ルータは認識できないIPオプションを無視しなければなりません(MUST)。この要件の帰結として、ルータはEnd of Option ListオプションとNo Operationオプションを実装しなければなりません(MUST)。なぜなら、どちらも明示的な長さを含まないからです。

DISCUSSION (議論)

将来のすべてのIPオプションには明示的な長さが含まれます。

4.2.2.7 Fragmentation: RFC 791 Section 3.2 (フラグメンテーション)​

ルータは[INTERNET:1]で説明されているフラグメンテーションをサポートしなければなりません(MUST)。

ルータがIPデータグラムをフラグメント化する場合、フラグメント数を最小化すべきです(SHOULD)。ルータがIPデータグラムをフラグメント化する場合、フラグメントを順番に送信すべきです(SHOULD)。あるIPフラグメントを別のIPフラグメントよりも著しく小さくする可能性があるフラグメンテーション方法では、最初のIPフラグメントを最小にしてもかまいません(MAY)。

DISCUSSION (議論)

インターネットで一般的に使用されているフラグメンテーション技術がいくつかあります。1つの技術は、IPデータグラムをIPフラグメントに分割し、最初のフラグメントをMTUサイズにし、他のフラグメントをほぼ同じサイズでMTUより小さくするものです。これは2つの理由で行われます。シーケンスの最初のIPフラグメントは、ホスト間の現在のパスの実効MTUとなり、後続のIPフラグメントのサイズは、IPデータグラムのさらなるフラグメンテーションを最小化するように設計されています。別の技術は、IPデータグラムをMTUサイズのIPフラグメントに分割し、最後のフラグメントのみをより小さくするもので、[INTERNET:1]で説明されています。

一部のTCP/IP実装で使用される一般的なトリックは、ルータを通過する必要があるIPデータグラムを576バイト以下のIPフラグメントにフラグメント化することです。これは、結果として得られるIPフラグメントがさらなるフラグメンテーションなしにパスの残りを通過できるようにすることを目的としています。ただし、これは宛先ホストにより大きな負荷を課します。なぜなら、IPデータグラムに再構成するIPフラグメントが増えるからです。また、MTUが一度だけ変更され、576バイトをはるかに上回る状態を保つネットワークでは効率的ではありません。例としては、MTUが2048のIEEE 802.5ネットワークやMTUが1500のイーサネットなどのLANネットワークが含まれます。

議論されている別のフラグメンテーション技術は、IPデータグラムをほぼ等しいサイズのIPフラグメントに分割し、サイズが次ホップネットワークのMTU以下になるようにするものです。これは、パスの下流でのさらなるフラグメンテーションが引き起こすフラグメント数を最小化し、各フラグメントが等しい遅延を持つことを保証することを目的としています。

ルータはできるだけ少ないIPフラグメントを生成すべきです(SHOULD)。

低速マシンでの作業から、メッセージをフラグメント化する必要がある場合に小さなIPフラグメントを最初に送信することで、低速インターフェースを持つホストがすべてのフラグメントを受信する可能性が最大化されると考えられます。

4.2.2.8 Reassembly: RFC 791 Section 3.2 (再構成)​

[INTRO:2]の対応するセクションで指定されているように、ルータは自身に渡すデータグラムの再構成をサポートしなければなりません(MUST)。

4.2.2.9 Time to Live: RFC 791 Section 3.2 (生存時間)​

ルータが開始または受信するパケットのTime to Live (TTL)の処理は[INTRO:2]によって管理されています。本セクションはその規定を変更するものではありません。ただし、[INTRO:2]のIPプロトコルセクションの残りが書き直されているため、本セクションも書き直されています。

特に、ルータはパケットの転送時以外にパケットのTTLを調べてはなりません(MUST NOT)。

ルータはTime-to-Live (TTL)値がゼロのデータグラムを開始または転送してはなりません(MUST NOT)。

ルータは受信時にTTLがゼロまたは1であるという理由だけでデータグラムを破棄してはなりません(MUST NOT)。ルータ宛てであり、それ以外は有効である場合、ルータはそれを受信しようと試みなければなりません(MUST)。

ルータが開始するメッセージの場合、IP層は送信される各データグラムのTTLフィールドを設定する方法をトランスポート層に提供しなければなりません(MUST)。固定TTL値が使用される場合、それは構成可能でなければなりません(MUST)。この数値はインターネットの典型的な直径を超えるべきです(SHOULD)。現在の知見では、インターネットの直径の2倍を超えて成長を許容すべきであることが示唆されています。現在推奨される値は、通常RFC Assigned Numbersで公開されています。TTLフィールドには2つの機能があります。TCPセグメントの生存時間を制限すること(RFC 793 [TCP:1]、p. 28参照)と、インターネットルーティングループを終了することです。TTLは秒単位の時間ですが、各ルータがTTLフィールドを少なくとも1減らさなければならないため、ホップ数の性質も持っています。

TTLの期限切れは、ルータによってデータグラムが破棄されることを意図していますが、宛先ホストによってではありません。したがって、データグラムを転送することでルータとして動作するホストは、ルータのTTL規則に従わなければなりません(MUST)。

上位層プロトコルは、一部のインターネットリソースの「拡張範囲」検索を実装するためにTTLを設定したい場合があります。これは一部の診断ツールで使用されており、IPマルチキャストを使用して特定のクラスの「最も近い」サーバーを見つけるのに有用であると予想されます。特定のトランスポートプロトコルは、データグラムの最大生存時間に対して独自のTTL制限を指定したい場合もあります。

固定デフォルト値は、インターネットの「直径」、つまり可能な最長パスに対応するのに十分な大きさでなければなりません。合理的な値は、インターネットの継続的な成長を許容するために直径の約2倍です。執筆時点では、米国を横断するメッセージは頻繁に15〜20のルータを通過します。これは、デフォルトのTTL値が40を超えるべきであることを示唆しており、64が一般的な値です。

4.2.2.10 Multi-subnet Broadcasts: RFC 922 (マルチサブネットブロードキャスト)​

all-subnetsブロードキャスト([INTERNET:3]でマルチサブネットブロードキャストと呼ばれています)は非推奨です。セクション[5.3.5.3]を参照してください。

4.2.2.11 Addressing: RFC 791 Section 3.2 (アドレス指定)​

2.2.5.1で説明されているように、現在5つのIPアドレスクラスがあります。クラスAからクラスEまでです。クラスDアドレスはIPマルチキャスト[INTERNET:4]に使用され、クラスEアドレスは実験的使用のために予約されています。クラスA、B、Cアドレスの区別はもはや重要ではありません。これらは汎用ユニキャストネットワークプレフィックスとして使用され、そのクラスに関しては歴史的な意味しかありません。

IPマルチキャストアドレスは、ホストのグループを表す28ビットの論理アドレスであり、永続的または一時的である可能性があります。永続的なマルチキャストアドレスはInternet Assigned Number Authority [INTRO:7]によって割り当てられ、一時的なアドレスは一時的なグループに動的に割り当てることができます。グループメンバーシップはIGMP [INTERNET:4]を使用して動的に決定されます。

ここで、以下のIPアドレス表記を使用して、汎用ユニキャストIPアドレスの重要な特殊ケースを要約します。

{ <Network-prefix>, <Host-number> }

そして、すべてのビットが1に設定されたフィールドを表すために-1表記を、すべてのビットが0に設定されたフィールドを表すために0を使用します。

(a) { 0, 0 }

このネットワーク上のこのホスト。ルータはこれをソースアドレスとして使用してはなりません(MUST NOT)。ただし、ルータは初期化中(例えば、ルータがBOOTPを使用して構成情報をロードする場合)にソースアドレスとして使用してもかまいません(MAY)。

ソースアドレス{ 0, 0 }を持つローカル配信される着信データグラム(セクション[5.2.3]参照)の場合、ルータが関連するプロトコルを実装し、そのプロトコルが取るべき適切なアクションを明確に定義している場合は受け入れなければなりません(MUST)。そうでない場合、ルータはソースアドレス{ 0, 0 }を持つローカル配信されるデータグラムを静かに破棄しなければなりません(MUST)。

DISCUSSION (議論)

一部のプロトコルは、ソースアドレス{ 0, 0 }を持つデータグラムを受信したときに取るべき特定のアクションを定義しています。2つの例はBOOTPとICMP Mask Requestです。これらのプロトコルの通常の動作は、通常、ソースアドレス{ 0, 0 }を持つデータグラムを受信できることに依存しています。ただし、ほとんどのプロトコルでは、ソースアドレス{ 0, 0 }を持つデータグラムを無視する方が良いです。なぜなら、それらは誤って構成されたホストまたはルータによって生成される可能性があるからです。したがって、ルータがソースアドレス{ 0, 0 }を持つ特定のデータグラムの処理方法を知っている場合、ルータはそれを受け入れなければなりません(MUST)。そうでない場合、ルータはそれを破棄しなければなりません(MUST)。

{ 0, 0 }の非標準的な使用については、セクション[4.2.3.1]も参照してください。

(b) { 0, <Host-number> }

このネットワーク上の指定されたホスト。ルータはこれを送信してはなりません(MUST NOT)。ただし、ルータは初期化中にソースアドレスとして使用してもかまいません(MAY)。それによってルータは自身のIPアドレスを学習します。

(c) { -1, -1 }

制限付きブロードキャスト。これはソースアドレスとして使用してはなりません(MUST NOT)。

この宛先アドレスを持つデータグラムは、接続された物理ネットワーク上のすべてのホストとルータによって受信されますが、そのネットワークを超えて転送されることはありません。

(d) { <Network-prefix>, -1 }

指定されたネットワークプレフィックスへの指向性ブロードキャスト - 指向性ブロードキャスト。これはソースアドレスとして使用してはなりません(MUST NOT)。ルータはネットワーク指向性ブロードキャストパケットを開始してもかまいません(MAY)。ルータはネットワーク指向性ブロードキャストパケットを受信しなければなりません(MUST)。ただし、ルータはこれらのパケットの受信を防ぐ構成オプションを持ってもかまいません(MAY)。そのようなオプションは、受信を許可することをデフォルトにしなければなりません(MUST)。

(e) { 127, <any> }

内部ホストループバックアドレス。この形式のアドレスはホストの外部に現れてはなりません(MUST NOT)。

&lt;Network-prefix>は管理上割り当てられるため、その値はデバイスが接続されているルーティングドメイン内で一意になります。

IPアドレスでは、上記の特殊ケースを除いて、&lt;Host-number>または&lt;Network-prefix>フィールドが0または-1の値を持つことは許可されていません。これは、これらの各フィールドの長さが少なくとも2ビットであることを意味します。

DISCUSSION (議論)

本文書の以前のバージョンでは、サブネット番号も0でも-1でもなく、少なくとも2ビットの長さでなければならないと示されていました。CIDRの世界では、サブネット番号は明らかにネットワークプレフィックスの拡張であり、プレフィックスの残りなしでは解釈できません。したがって、CIDRが与えられれば、このサブネット番号の制限は意味をなさず、安全に無視できます。

ブロードキャストアドレスに関する詳細な議論については、セクション[4.2.3.1]を参照してください。

ルータがデータグラムを開始する場合、IPソースアドレスは自身のIPアドレスの1つ(ただし、ブロードキャストまたはマルチキャストアドレスではない)でなければなりません(MUST)。唯一の例外は初期化中です。

ほとんどの場合、ブロードキャストまたはマルチキャスト宛先宛てのデータグラムの処理は、ルータのIPアドレスの1つ宛ての場合と同様に処理されます。つまり、

  • ルータはブロードキャスト宛先アドレスを持つすべてのパケットを受信し、通常どおり処理しなければなりません(MUST)。

  • ルータは、受信を要求したマルチキャスト宛先アドレスに送信されたすべてのパケットを受信し、通常どおり処理しなければなりません(MUST)。

specific-destination addressという用語は、ホストのIPアドレスのローカル同等物を示します。特定の宛先アドレスは、IPヘッダの宛先アドレスとして定義されます。ただし、ヘッダにブロードキャストまたはマルチキャストアドレスが含まれている場合、特定の宛先は、データグラムが到着した物理インターフェースに割り当てられたIPアドレスです。

ルータは、このセクションの規則に従って無効なIPソースアドレスを含む受信データグラムを静かに破棄しなければなりません(MUST)。この検証は、IP層または(適切な場合)トランスポート層の各プロトコルによって実行できます(MAY)。ルータによって破棄されるすべてのデータグラムと同様に、データグラムの破棄はカウントされるべきです(SHOULD)。

DISCUSSION (議論)

誤って宛先指定されたデータグラムは、ユニキャストデータグラムのリンク層ブロードキャストや、混乱または誤って構成された別のルータまたはホストによって引き起こされる可能性があります。

4.2.3 Specific Issues (特定の問題)​

4.2.3.1 IP Broadcast Addresses (IPブロードキャストアドレス)​

歴史的理由により、パケットがIPブロードキャストであることを示すために使用される多くのIPアドレス(一部は標準、一部は非標準)があります。ルータは

(1) 255.255.255.255または{ &lt;Network-prefix>, -1 }宛てのパケットをIPブロードキャストとして扱わなければなりません(MUST)。

(2) 受信時に0.0.0.0または{ &lt;Network-prefix>, 0 }宛てのすべてのパケットを静かに破棄すべきです(SHOULD)(つまり、ルータのアプリケーションにも渡さない)。これらのパケットが静かに破棄されない場合、IPブロードキャストとして扱わなければなりません(MUST)(セクション[5.3.5]参照)。これらのパケットの受信を許可する構成オプションがあってもかまいません(MAY)。このオプションは、それらを破棄することをデフォルトにすべきです(SHOULD)。

(3) 接続された(サブ)ネットワークへのIPブロードキャストを開始する場合、(デフォルトで)制限付きブロードキャストアドレス(255.255.255.255)を使用すべきです(SHOULD)(ただし、セクション[4.3.3.9]で説明されているICMPアドレスマスク応答を送信する場合を除く)。ルータは制限付きブロードキャストを受信しなければなりません(MUST)。

(4) 0.0.0.0または{ &lt;Network-prefix>, 0 }宛てのデータグラムを開始すべきではありません(SHOULD NOT)。これらのデータグラムの生成を許可する構成オプションがあってもかまいません(MAY)(関連する1s形式のブロードキャストを使用する代わりに)。このオプションは、それらを生成しないことをデフォルトにすべきです(SHOULD)。

DISCUSSION (議論)

2番目のポイントでは、ルータがそのネットワークプレフィックスへのインターフェースを持っていない場合、ルータは明らかに{ &lt;Network-prefix>, 0 }形式のアドレスを認識できません。その場合、ルータの観点からはパケットがIPブロードキャストパケットではないため、2番目のポイントの規則は適用されません。

4.2.3.2 IP Multicasting (IPマルチキャスト)​

IPルータは、IPマルチキャストに関して[INTRO:2]で指定されたホスト要件を満たすべきです(SHOULD)。IPルータは、すべての接続されたネットワーク上でローカルIPマルチキャストをサポートすべきです(SHOULD)。IPマルチキャストアドレスからリンク層アドレスへのマッピングが指定されている場合(さまざまなIP-over-xxx仕様を参照)、そのマッピングを使用すべきであり(SHOULD)、代わりにリンク層ブロードキャストを使用するように構成できます(MAY)。ポイントツーポイントリンクおよび他のすべてのインターフェースでは、マルチキャストはリンク層ブロードキャストとしてカプセル化されます。ローカルIPマルチキャストのサポートには、マルチキャストデータグラムの開始、マルチキャストグループへの参加とマルチキャストデータグラムの受信、およびマルチキャストグループからの離脱が含まれます。これは、IGMP(セクション[4.4]参照)を含む[INTERNET:4]のすべてをサポートすることを意味します。

DISCUSSION (議論)

[INTERNET:4]のタイトルはHost Extensions for IP Multicastingですが、ホストとルータを含むすべてのIPシステムに適用されます。特に、ルータはマルチキャストグループに参加できるため、IGMPのホスト部分を実行し、接続されたネットワーク上に存在する可能性のあるすべてのマルチキャストルータ(それら自体がマルチキャストルータであるかどうかにかかわらず)にグループメンバーシップを通知することが正しいです。

一部のルーティングプロトコルは、IPマルチキャストのサポートを特に必要とする場合(例えば、OSPF [ROUTE:1])、または推奨する場合(例えば、ICMP Router Discovery [INTERNET:13])があります。

4.2.3.3 Path MTU Discovery (パスMTU検出)​

フラグメンテーションを排除または最小化するために、ソースから宛先へのパスMTUを知ることが望ましいです。パスMTUは、パス内の各ホップのMTUの最小値です。[INTERNET:14]は、任意のインターネットパスの最大伝送単位(MTU)を動的に発見する技術を説明しています。[INTERNET:14]をサポートしていないルータを通過するパスの場合、この技術は正しいパスMTUを発見できない可能性がありますが、常に古い技術や現在の慣行で選択されたパスMTUと同じくらい正確なパスMTUを選択し、多くの場合はより正確です。

ルータがIPデータグラムを開始する場合、[INTERNET:14]で説明されているスキームを使用してデータグラムのサイズを制限すべきです(SHOULD)。データグラムの宛先へのルータのルートが、パスMTU情報を提供するルーティングプロトコルから学習された場合でも、[INTERNET:14]で説明されているスキームが使用されますが、ルーティングプロトコルからのパスMTU情報は、パスMTUの初期推定値として、およびパスMTUの上限として使用されるべきです(SHOULD)。

4.2.3.4 Subnetting (サブネット化)​

場合によっては、サブネット化されたネットワークの一部ではないパスを介してのみ相互接続された特定のネットワークのサブネットをサポートすることが望ましい場合があります。これは、不連続サブネットのサポートと呼ばれます。

ルータは不連続サブネットをサポートしなければなりません(MUST)。

IMPLEMENTATION (実装)

従来のIPネットワークでは、これは実装が困難です。CIDRネットワークでは、これは自然な副産物です。したがって、ルータはサブネットアーキテクチャについて仮定を立てるべきではなく(SHOULD NOT)、各ルートを汎用ネットワークプレフィックスとして扱うべきです(SHOULD)。

DISCUSSION (議論)

インターネットは最近驚くべき速度で成長しています。これにより、IPアドレス指定技術に深刻な負担がかかっています。この負担の主な要因は、IPアドレスの厳格なクラス境界です。これにより、ネットワークプレフィックスのサイズを効率的に調整し、複数のネットワークプレフィックスを単一のルーティングアナウンスに集約することが困難になります。IPアドレスの厳格なクラス境界を排除し、各ルートを汎用ネットワークプレフィックスとして扱うことで、これらの負担を大幅に軽減できます。

現在これを行っている技術は、クラスレスドメイン間ルーティング(CIDR) [INTERNET:15]です。

同様の理由により、特定のネットワークプレフィックスに関連付けられたアドレスブロックは、異なるサイズのサブブロックに細分化できるため、サブブロックに関連付けられたネットワークプレフィックスは異なる長さになります。例えば、ネットワークプレフィックスの長さが8ビットのブロック内で、あるサブブロックには16ビットのネットワークプレフィックス、別のサブブロックには18ビットのネットワークプレフィックス、3番目のサブブロックには14ビットのネットワークプレフィックスがある可能性があります。

ルータは、インターフェース構成とルーティングデータベースで可変長ネットワークプレフィックスをサポートしなければなりません(MUST)。

4.3 Internet Control Message Protocol - ICMP (インターネット制御メッセージプロトコル)​

4.3.1 Introduction (はじめに)​

ICMPは、IPのルーティング、診断、およびエラー機能を提供する補助プロトコルです。[INTERNET:8]で説明されています。ルータはICMPをサポートしなければなりません(MUST)。

ICMPメッセージは2つのカテゴリに分類され、以下のセクションで説明されます。

ICMPエラーメッセージ:

  • Destination Unreachable (宛先到達不能) セクション 4.3.3.1
  • Redirect (リダイレクト) セクション 4.3.3.2
  • Source Quench (ソース抑制) セクション 4.3.3.3
  • Time Exceeded (時間超過) セクション 4.3.3.4
  • Parameter Problem (パラメータ問題) セクション 4.3.3.5

ICMPクエリメッセージ:

  • Echo (エコー) セクション 4.3.3.6
  • Information (情報) セクション 4.3.3.7
  • Timestamp (タイムスタンプ) セクション 4.3.3.8
  • Address Mask (アドレスマスク) セクション 4.3.3.9
  • Router Discovery (ルータ検出) セクション 4.3.3.10

一般的なICMP要件と議論は次のセクションにあります。

4.3.2 General Issues (一般的な問題)​

4.3.2.1 Unknown Message Types (不明なメッセージタイプ)​

不明なタイプのICMPメッセージが受信された場合、ICMPユーザーインターフェース(ルータが持っている場合)に渡すか(MUST)、静かに破棄(ルータが持っていない場合)しなければなりません。

4.3.2.2 ICMP Message TTL (ICMPメッセージTTL)​

ICMPメッセージを開始する場合、ルータはTTLを初期化しなければなりません(MUST)。ICMP応答のTTLは、応答をトリガーしたパケットから取得してはなりません(MUST NOT)。

4.3.2.3 Original Message Header (元のメッセージヘッダ)​

歴史的に、各ICMPエラーメッセージには、エラーをトリガーしたデータグラムのインターネットヘッダと少なくとも最初の8データワードが含まれています。IP-in-IPトンネリングおよび他の技術の使用により、これはもはや十分ではありません。したがって、ICMPデータグラムは、ICMPデータグラムが576バイトの長さを超えないように、元のデータグラムをできるだけ多く含むべきです(SHOULD)。返されるIPヘッダ(およびユーザーデータ)は受信したものと同一でなければなりません(MUST)。ただし、ルータは、エラーの検出前に転送中に通常行われるIPヘッダへの変更を元に戻す必要はありません(例えば、TTLのデクリメントやオプションの更新)。セクション[4.3.3.5]の要件は、一部のケース(つまり、変更されたフィールドに問題がある場合のParameter Problemメッセージの場合、ルータは変更を元に戻さなければならない)でこの要件を上書きすることに注意してください。セクション[4.3.3.5]を参照してください。

4.3.2.4 ICMP Message Source Address (ICMPメッセージソースアドレス)​

本文書で特に指定されていない限り、ルータが開始するICMPメッセージのIPソースアドレスは、ICMPメッセージを送信する物理インターフェースに関連付けられたIPアドレスの1つでなければなりません(MUST)。インターフェースに関連付けられたIPアドレスがない場合、代わりにルータのrouter-idが使用されます(セクション[5.2.5]参照)。

4.3.2.5 TOS and Precedence (TOSと優先順位)​

ICMPエラーメッセージは、ICMPエラーメッセージの送信を引き起こしたパケットのTOSビットと同じ値にTOSビットを設定すべきです(SHOULD)。ただし、その値に設定すると、宛先にルーティングできないためにICMPエラーメッセージが即座に破棄される場合を除きます。そうでない場合、ICMPエラーメッセージは通常のTOS(つまり、ゼロ)で送信しなければなりません(MUST)。ICMP応答メッセージは、応答を引き起こしたICMP要求のTOSビットと同じ値にTOSビットを設定すべきです(SHOULD)。

ICMPエラーメッセージSource Quench(送信される場合)は、ICMP Source Quenchメッセージの送信を引き起こしたパケットのIP Precedenceフィールドと同じ値にIP Precedenceフィールドを設定しなければなりません(MUST)。他のすべてのICMPエラーメッセージ(Destination Unreachable、Redirect、Time Exceeded、およびParameter Problem)は、優先順位値を6(INTERNETWORK CONTROL)または7(NETWORK CONTROL)に設定すべきです(SHOULD)。これらのエラーメッセージのIP Precedence値は構成可能であってもかまいません(MAY)。

ICMP応答メッセージは、応答を引き起こしたICMP要求のIP Precedenceフィールドと同じ値にIP Precedenceフィールドを設定しなければなりません(MUST)。

4.3.2.6 Source Route (ソースルート)​

ICMPエラーメッセージの送信を引き起こしたパケットにソースルートオプションが含まれている場合、ICMPエラーメッセージには、元のパケットのソースルートオプションのポインタの前の記録された部分を反転して作成された同じタイプ(strictまたはloose)のソースルートオプションも含まれるべきです(SHOULD)。ただし、ICMPエラーメッセージが元のパケットのソースルートオプションに関する苦情のICMP Parameter Problemメッセージである場合、またはルータがICMPエラーメッセージの配信を妨げるポリシーを知っている場合を除きます。

DISCUSSION (議論)

米国国防総省のセキュリティオプション([INTERNET:5]で定義)を使用する環境では、ICMPメッセージにセキュリティオプションを含める必要がある場合があります。このトピックの詳細は、Defense Communications Agencyから入手できるはずです。

4.3.2.7 When Not to Send ICMP Errors (ICMPエラーを送信しない場合)​

ICMPエラーメッセージは、以下を受信した結果として送信してはなりません(MUST NOT)。

  • ICMPエラーメッセージ、または

  • セクション[5.2.2]で説明されているIPヘッダ検証テストに失敗したパケット(そのセクションがICMPエラーメッセージの送信を特に許可している場合を除く)、または

  • IPブロードキャストアドレスまたはIPマルチキャストアドレス宛てのパケット、または

  • リンク層ブロードキャストまたはマルチキャストとして送信されたパケット、または

  • ネットワークプレフィックスがゼロのソースアドレスを持つパケット、または無効なソースアドレスを持つパケット(セクション[5.3.7]で定義)、または

  • 最初のフラグメント以外のデータグラムの任意のフラグメント(つまり、IPヘッダのフラグメントオフセットがゼロでないパケット)。

さらに、ICMPエラーメッセージは、本メモがパケットを静かに破棄すべきであると示すすべてのケースで送信してはなりません(MUST NOT)。

注意:これらの制限は、本文書の他の場所でICMPエラーメッセージを送信する要件よりも優先されます。

DISCUSSION (議論)

これらの規則は、ルータまたはホストがブロードキャストパケットにICMPエラーメッセージで応答するために発生するブロードキャストストームを防ぐことを目的としています。例えば、存在しないポートへのUDPブロードキャストパケットは、そのポートを持たないすべてのデバイスからICMP Destination Unreachableデータグラムの洪水をトリガーする可能性があります。大きなイーサネットでは、結果として生じる衝突により、ネットワークが1秒以上使用できなくなる可能性があります。

接続されたネットワーク上でブロードキャストされる各データグラムには、IP宛先として有効なIPブロードキャストアドレスが必要です(セクション[5.3.4]および[INTRO:2]参照)。ただし、一部のデバイスはこの規則に違反しています。したがって、ブロードキャストパケットを確実に検出するために、ルータはIP層アドレスだけでなく、リンク層ブロードキャストもチェックする必要があります。

IMPLEMENTATION+ (実装)

これには、リンク層がリンク層ブロードキャストパケットが受信されたときにIP層に通知することが必要です。セクション[3.1]を参照してください。

4.3.2.8 Rate Limiting (レート制限)​

ICMP Source Quenchメッセージを送信するルータは、メッセージの生成レートを制限できなければなりません(MUST)。ルータは、他のタイプのICMPエラーメッセージ(Destination Unreachable、Redirect、Time Exceeded、Parameter Problem)を送信するレートも制限できるべきです(SHOULD)。レート制限パラメータは、ルータの構成の一部として構成可能であるべきです(SHOULD)。制限の適用方法(例えば、ルータごとまたはインターフェースごと)は実装者の裁量に任されます。

DISCUSSION (議論)

ルータによるICMPエラーメッセージの送信に関する2つの問題は次のとおりです。 (1) 逆パスの帯域幅の消費、および (2) ルータリソース(例えば、メモリ、CPU時間)の使用

これらの問題を解決するために、ルータはICMPエラーメッセージを生成する頻度を制限できます。同様の理由により、ルータは特定の他のタイプのメッセージ(例えば、ICMP Echo Replies)が生成される頻度を制限できます。

IMPLEMENTATION (実装)

ICMPメッセージの送信レートを制限するために、さまざまなメカニズムが使用または提案されています。

(1) カウントベース - 例えば、破棄されたN番目のパケットごと、または特定のソースホストごとにICMPエラーメッセージを送信します。このメカニズムはICMP Source Quench(使用される場合)に適している可能性がありますが、他のタイプのICMPメッセージには適していない可能性があります。

(2) タイマーベース - 例えば、特定のソースホストまたは合計でTミリ秒ごとに最大1つのICMPエラーメッセージを送信します。

(3) 帯域幅ベース - 例えば、特定のインターフェースを介したICMPメッセージの送信レートを、接続されたネットワークの帯域幅の特定の割合に制限します。

4.3.3 Specific Issues (特定の問題)​

4.3.3.1 Destination Unreachable (宛先到達不能)​

ルータがパケットに宛先へのルートがないために(デフォルトルートを含む)パケットを転送できない場合、ルータはICMP Destination Unreachableメッセージ、コード0(Network Unreachable)を生成しなければなりません(MUST)。ルータがパケットで指定された宛先ネットワークへのルートを実際に持っているが、ルータが持っているルートがデフォルトTOS(0000)でもルータがルーティングしようとしているパケットのTOSでもないTOSを指定している場合、ルータはICMP Destination Unreachableメッセージ、コード11(Network Unreachable for TOS)を生成しなければなりません(MUST)。

パケットがルータに直接接続されたネットワークに直接接続されたホストに転送される必要がある場合(つまり、ルータが最後のホップルータである場合)、ルータが宛先ホストへのパスがないと判断した場合、ルータはICMP Destination Unreachableメッセージ、コード1(Host Unreachable)を生成しなければなりません(MUST)。パケットがルータに直接接続されたネットワークに直接接続されたホストに転送される必要があり、ルータが宛先へのルートがパケットで要求されたTOSまたはデフォルトTOS(0000)と等しいTOSを持たないためにパケットを転送できない場合、ルータはICMP Destination Unreachableメッセージ、コード12(Host Unreachable for TOS)を生成しなければなりません(MUST)。

DISCUSSION (議論)

意図は、ルータが宛先への絶対的なパスを持っていない場合(デフォルトルートを含む)、ルータが「汎用」Host/Network Unreachableを生成することです。ルータが宛先への1つ以上のパスを持っているが、これらのパスのいずれも許容可能なTOSを持っていない場合、ルータは「for TOS unreachable」メッセージを生成します。

4.3.3.2 Redirect (リダイレクト)​

ICMP Redirectメッセージは、ローカルホストに特定のトラフィックに対して異なるネクストホップルータを使用すべきであることを通知するために生成されます。

[INTRO:2]とは異なり、ルータがルーティングプロトコルを実行している場合、またはルータおよびパケットを送信するインターフェースで転送が有効になっている場合、ルータが開始するパケットのパスを選択する際にICMPリダイレクトを無視してもかまいません(MAY)。

4.3.3.3 Source Quench (ソース抑制)​

ルータはICMP Source Quenchメッセージを開始すべきではありません(SHOULD NOT)。セクション[4.3.2]で指定されているように、Source Quenchメッセージを開始するルータは、その生成レートを制限できなければなりません(MUST)。

DISCUSSION (議論)

研究は、Source Quenchがネットワーク帯域幅を消費するが、輻輳に対する非効率的(および不公平な)救済策であることを示しているようです。例えば、[INTERNET:9]および[INTERNET:10]を参照してください。セクション[5.3.6]では、ルータがネットワークの過負荷と輻輳をどのように処理すべきかについての現在の考え方について説明しています。

ルータは受信したすべてのICMP Source Quenchメッセージを無視してもかまいません(MAY)。

DISCUSSION (議論)

ルータ自身は、別のルータまたはホストに送信されたパケットの開始によりSource Quenchを受信する場合があります。そのようなデータグラムは、例えば、別のルータへのEGP更新や、ホストへのtelnetフローなどです。Source Quenchにパケット送信レートを制御することで直接応答するIP層のメカニズムが提案されています([INTERNET:11]、[INTERNET:12])が、この提案は現在実験的であり、現在は推奨されていません。

4.3.3.4 Time Exceeded (時間超過)​

ルータがパケットを転送し、パケットのTTLフィールドがゼロにデクリメントされた場合、セクション[5.2.3.8]の要件が適用されます。

ルータがルータ宛てのパケットを再構成する場合、インターネットホストとして動作します。したがって、[INTRO:2]の再構成要件が適用されます。

ルータが(つまり、ルータ宛ての)Time Exceededメッセージを受信した場合、[INTRO:2]に準拠しなければなりません(MUST)。

4.3.3.5 Parameter Problem (パラメータ問題)​

他のICMPメッセージで特にカバーされていないエラーについては、ルータはParameter Problemメッセージを生成しなければなりません(MUST)。ポインタフィールドで示されるバイトを含むIPヘッダフィールドまたはIPオプションは、このICMPメッセージで返されるIPヘッダ内で変更されないままでなければなりません(MUST)。セクション[4.3.2]は、この要件の例外を定義しています。

Parameter Problemメッセージの新しいバリアントが[INTRO:2]で定義されています。

コード1 = 必要なオプションがありません。

DISCUSSION (議論)

このバリアントは、現在、軍事コミュニティでセキュリティオプションが欠落している場合に使用されています。

4.3.3.6 Echo Request/Reply (エコー要求/応答)​

ルータは、ルータに送信されたEcho Requestsを受信し、対応するEcho Repliesを送信するICMP Echoサーバー機能を実装しなければなりません(MUST)。ルータは、少なくとも576のサイズおよびすべての接続されたネットワークのMTUの最大値のICMP Echo Requestデータグラムを受信、再構成、および応答する準備ができていなければなりません(MUST)。

Echoサーバー機能は、IPブロードキャストアドレスまたはIPマルチキャストアドレス宛てのICMPエコー要求に応答しないことを選択してもかまいません(MAY)。

ルータは、有効にすると、ルータがすべてのICMPエコー要求を静かに無視するようにする構成オプションを持つべきです(SHOULD)。提供される場合、このオプションは応答を許可することをデフォルトにしなければなりません(MUST)。

DISCUSSION (議論)

ブロードキャストおよびマルチキャストEcho要求への応答に関する中立的な規則は、[INTRO:2]の"Echo Request/Reply"セクションに由来します。

セクション[10.3.3]で説明されているように、ルータは診断目的でEcho Requestsを送信しEcho Repliesを受信するためのユーザー/アプリケーション層インターフェースも実装しなければなりません(MUST)。すべてのICMP Echo Replyメッセージは、このインターフェースに渡されなければなりません(MUST)。

ICMP Echo ReplyのIPソースアドレスは、対応するICMP Echo Requestメッセージの特定の宛先アドレスと同じでなければなりません(MUST)。

ICMP Echo Requestで受信されたデータは、生成されたEcho Replyに完全に含まれていなければなりません(MUST)。

Record RouteおよびTimestampオプションがICMP Echo Requestで受信された場合、このオプション(これらのオプション)は現在のルータを含むように更新され(SHOULD)、トランケートされずにEcho ReplyメッセージのIPヘッダに含まれるべきです。したがって、記録されたルートは全往復に使用されます。

Source RouteオプションがICMP Echo Requestで受信された場合、リターンパスは反転され、ルータがメッセージの配信を妨げるポリシーを知っている場合を除いて、Echo ReplyメッセージのSource Routeオプションとして使用されなければなりません(MUST)。

4.3.3.7 Information Request/Reply (情報要求/応答)​

ルータはこれらのメッセージを開始または応答すべきではありません(SHOULD NOT)。

DISCUSSION (議論)

Information Request/Replyペアは、自己構成システム(ディスクレスワークステーションなど)をサポートして、起動時にIPネットワークプレフィックスを発見できるようにすることを目的としていました。ただし、これらのメッセージは現在廃止されています。RARPおよびBOOTPプロトコルは、ホストが自身のIPアドレスを発見するためのより良いメカニズムを提供します。

4.3.3.8 Timestamp and Timestamp Reply (タイムスタンプとタイムスタンプ応答)​

ルータはTimestampとTimestamp Replyを実装してもかまいません(MAY)。実装される場合、次のようになります。

  • ICMP Timestampサーバー機能は、受信した各Timestampメッセージに対してTimestamp Replyを返さなければなりません(MUST)。遅延の分散が最小化されるように設計されるべきです(SHOULD)。

  • IPブロードキャストアドレスまたはIPマルチキャストアドレス宛てのICMP Timestamp Requestメッセージは静かに破棄してもかまいません(MAY)。

  • ICMP Timestamp ReplyのIPソースアドレスは、対応するTimestamp Requestメッセージの特定の宛先アドレスと同じでなければなりません(MUST)。

  • Source RouteオプションがICMP Timestamp Requestで受信された場合、リターンパスは反転され、ルータがメッセージの配信を妨げるポリシーを知っている場合を除いて、Timestamp ReplyメッセージのSource Routeオプションとして使用されなければなりません(MUST)。

  • Record RouteおよびTimestampオプションがTimestamp Requestで受信された場合、このオプション(これらのオプション)は現在のルータを含むように更新され(SHOULD)、Timestamp ReplyメッセージのIPヘッダに含まれるべきです。

  • ルータがTimestamp Requestメッセージを送信するためのアプリケーション層インターフェースを提供する場合、着信Timestamp Responseメッセージは上方のICMPユーザーインターフェースに渡されなければなりません(MUST)。

タイムスタンプ値の好ましい形式(標準値)は、協定世界時の真夜中からのミリ秒です。ただし、この値をミリ秒の解像度で提供することは困難な場合があります。例えば、多くのシステムは、ライン周波数、50または60回/秒でのみ更新されるクロックを使用しています。したがって、標準値にはある程度の余裕があります。

(a) 標準値は少なくとも1秒あたり16回更新されなければなりません(MUST)(つまり、値の下位6ビットが未定義である可能性があります)。

(b) 標準値の精度は、オペレータが設定したCPUクロックの精度に近づかなければなりません(MUST)。つまり、数分以内に正確です。

IMPLEMENTATION (実装)

2番目の条件を満たすために、ルータは起動時または再起動時にタイムサーバーに問い合わせる必要がある場合があります。この目的には、UDP Time Serverプロトコルの使用が推奨されます。より高度な実装では、Network Time Protocol (NTP)を使用してミリ秒に近いクロック同期を取得します。ただし、これは必須ではありません。

4.3.3.9 Address Mask Request/Reply (アドレスマスク要求/応答)​

ルータは、ICMP Address Mask要求メッセージの受信とICMP Address Mask応答メッセージでの応答をサポートしなければなりません(MUST)。これらのメッセージは[INTERNET:2]で定義されています。

ルータは、各論理インターフェースについて、ルータがそのインターフェースのAddress Mask要求に応答することが許可されているかどうかを指定する構成オプションを持つべきです(SHOULD)。このオプションは応答を許可することをデフォルトにしなければなりません(MUST)。ルータは、正しいアドレスマスクを知る前にAddress Mask要求に応答してはなりません(MUST NOT)。

ルータは、ソースアドレスが0.0.0.0であり、アドレスマスクがすべて同じではない複数の論理インターフェースに関連付けられた物理インターフェースに到着するAddress Mask要求に応答してはなりません(MUST NOT)。

ルータは、受信したすべてのICMP Address Mask Repliesをチェックして、含まれている情報がルータのアドレスマスクの知識と一致するかどうかを判断すべきです(SHOULD)。ICMP Address Mask Replyが誤っているように見える場合、ルータはアドレスマスクと送信者のIPアドレスをログに記録すべきです(SHOULD)。ルータは、ICMP Address Mask Replyの内容を使用して正しいアドレスマスクを決定してはなりません(MUST NOT)。

ホストがルータの起動時にダウンしている場合、ホストがアドレスマスクを知ることができない可能性があるため、ルータは自身のアドレスマスクを構成した後、各論理インターフェースで非請求のICMP Address Mask Repliesを送信してもかまいません(MAY)。ただし、この機能は可変長アドレスマスクを使用する環境では危険な場合があります。したがって、非請求のAddress Mask Repliesは、以下の論理インターフェースで送信してはなりません(MUST NOT)。

  • 非請求のAddress Mask Repliesを送信するように構成されていない。各論理インターフェースには、これを制御する構成パラメータが必要であり(MUST)、そのパラメータは非請求のAddress Mask Repliesを送信しないことをデフォルトにしなければなりません(MUST)。

  • 包含する(ただし同一ではない)ネットワークプレフィックスと物理インターフェースを共有する。

IPブロードキャストアドレスの{ &lt;Network-prefix>, -1 }形式は、Address Mask Repliesをブロードキャストするために使用されなければなりません(MUST)。

DISCUSSION (議論)

ルータがAddress Mask Repliesの送信を無効にする機能は、アドレスマスクについてホストに意図的に嘘をつく少数のサイトで必要です。この必要性は、より多くのホストがホスト要件標準に準拠するにつれて消滅すると予想されます。

上記の2番目のポイントの理由と、使用するIPブロードキャストアドレスに関する要件は、複数のIPネットワークプレフィックスが同じ物理ネットワーク上で使用されている場合の問題を防ぐためです。

4.3.3.10 Router Advertisement and Solicitations (ルータ広告と要請)​

IPルータは、ルータがIPマルチキャストアドレス指定またはIPブロードキャストアドレス指定をサポートするすべての接続されたネットワーク上で、ICMP Router Discoveryプロトコル[INTERNET:13]のルータ部分をサポートしなければなりません(MUST)。実装には、ルータに指定されたすべての構成変数を指定されたデフォルト値で含める必要があります(MUST)。

DISCUSSION (議論)

ルータはICMP Router Discoveryプロトコルのホスト部分を実装する必要はありませんが、IP転送が無効になっている場合(つまり、ホストとして動作している場合)の動作に有用である可能性があります。

DISCUSSION (議論)

ホストがRIPバージョン1をルータ検出プロトコルとして使用することが一般的であることに注意してください。そのようなホストはRIPトラフィックをリッスンし、そのトラフィックから抽出された情報を使用してルータを発見し、特定の宛先の最初のホップルータとしてどのルータを使用するかを決定します。この動作は推奨されていませんが、依然として一般的であり、実装者はそれを認識しておく必要があります。

4.4 Internet Group Management Protocol - IGMP (インターネットグループ管理プロトコル)​

IGMP [INTERNET:4]は、単一の物理ネットワーク上のホストとマルチキャストルータの間で使用され、特定のマルチキャストグループへのホストのメンバーシップを確立するプロトコルです。マルチキャストルータは、この情報をマルチキャストルーティングプロトコルと組み合わせて使用し、インターネット全体でIPマルチキャスト転送をサポートします。

ルータはIGMPのホスト部分を実装すべきです(SHOULD)。

に最終更新