RFC 1812 - Requirements for IP Version 4 Routers

Status of this Memo (このメモのステータス)

この文書は、インターネットコミュニティに対してインターネット標準トラックプロトコルを規定し、改善のための議論と提案を求めるものです。本プロトコルの標準化状態については、「Internet Official Protocol Standards」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Preface (序文)

この文書は、RFC 1716 (歴史的ルーター要件文書) の更新版です。このRFCは、ワーキンググループの重要な作業成果を保持していますが、IESGがそれを現在の標準と見なすには、現在の技術を十分に記述できませんでした。

現在の編集者は、この文書を調達仕様および実装者のガイドとして使用できるように更新する任務を与えられました。その過程で、彼は完全に前任者の作業成果に依存し、専門家の寄稿者によって提供されたテキストに大きく依存しました。すべての功績は彼らのものであり、誤りは彼が負うべきものです。

この文書の内容と形式は、ワーキンググループの議長、および文書の元の編集者および著者であるPhilip Almquistに大きく負っています。また、前編集者であるFrank Kastenholzにも大きく負っています。彼らの努力がなければ、この文書は存在しなかったでしょう。

1. Introduction (はじめに)
2. Internet Architecture (インターネットアーキテクチャ)
3. Link Layer (リンク層)
4. Internet Layer - Protocols (ネットワーク層 - プロトコル)
5. Internet Layer - Forwarding (ネットワーク層 - 転送)
6. Transport Layer (トランスポート層)
7. Application Layer - Routing Protocols (アプリケーション層 - ルーティングプロトコル)
8. Application Layer - Network Management Protocols (アプリケーション層 - ネットワーク管理プロトコル)
9. Application Layer - Miscellaneous Protocols (アプリケーション層 - その他のプロトコル)
10. Operations and Maintenance (運用と保守)
11. References (参考文献)
Appendix A. Requirements for Source-Routing Hosts (付録A. ソースルーティングホストの要件)
Appendix B. Glossary (付録B. 用語集)
Appendix C. Future Directions (付録C. 今後の方向性)
Appendix D. Multicast Routing Protocols (付録D. マルチキャストルーティングプロトコル)
Appendix E. Additional Next-Hop Selection Algorithms (付録E. 追加のネクストホップ選択アルゴリズム)
Appendix F. Historical Routing Protocols (付録F. 歴史的ルーティングプロトコル)

1. Introduction

このメモは、RFC 1716「Requirements for Internet Gateways」([INTRO:1]) に代わるものです。

このメモは、インターネットプロトコルファミリーのネットワーク層転送機能を実行するデバイスの要件を定義し、議論します。インターネットコミュニティは通常、このようなデバイスをIPルーター (IP routers) または単にルーター (routers) と呼んでいます。OSIコミュニティは、このようなデバイスを中間システム (intermediate systems) と呼んでいます。多くの古いインターネット文書では、これらのデバイスをゲートウェイ (gateways) と呼んでいましたが、この名称は最近、アプリケーションゲートウェイ (application gateways) との混同を避けるため、ほとんど使用されなくなりました。

IPルーターと他のタイプのパケット交換デバイスとの違いは、ルーターが交換プロセス中にIPプロトコルヘッダーを検査することです。通常、メッセージ受信時に使用されたリンク層ヘッダーを削除し、IPヘッダーを変更し、再送信用のリンク層ヘッダーを置き換えます。

このメモの著者と読者は、多くのルーターが複数のプロトコルをサポートしていることを認識する必要があります。将来、インターネットのますます大きな部分が、マルチプロトコルファミリーのサポートを必要とするでしょう。しかし、このメモはTCP/IP以外のプロトコルファミリーに対するインターネット要件を規定しようとはしていません。

この文書は、インターネットに接続されたルーターが使用しなければならない標準プロトコルを列挙し、これらのプロトコルの現在の仕様を記述するRFCや他の文書を参照によって組み込んでいます。参照された文書のエラーを修正し、実装者のための追加の議論とガイダンスを追加します。

各プロトコルについて、このメモには要件、推奨事項、オプションの明示的なセットも含まれています。読者は、このメモの要件リスト自体が不完全であることを理解する必要があります。インターネットプロトコルルーターの完全な要件セットは、主に標準プロトコル仕様文書で定義されており、このメモに含まれる修正、改訂、および補足と組み合わされています。

このメモは、Requirements for Internet Hosts RFC ([INTRO:2]および[INTRO:3]) と併せて読む必要があります。インターネットホストとルーターの両方が、IPデータグラムを開始し、自分宛てのIPデータグラムを受信できる必要があります。インターネットホストとルーターの主な違いは、ルーターが転送アルゴリズムを実装するのに対し、インターネットホストは転送機能を必要としないことです。ルーターとして機能するインターネットホストは、このメモに含まれる要件に従う必要があります。

オープンシステムの相互接続の目標は、ルーターが必要に応じてインターネットホストとして正しく動作しなければならないことを要求します。この目標を達成するために、このメモはこのような状況に対する指針を提供します。簡素化と文書更新の容易さのために、このメモは[INTRO:2]および[INTRO:3]とのホスト要件に関する議論の重複を避け、参照によってこれらの文書の関連要件を組み込んでいます。場合によっては、この文書は[INTRO:2]および[INTRO:3]に記載された要件に取って代わります。

RFCを注意深く読んだ後に生成された誠実な実装は、このメモの要件とは些細な点でのみ異なるべきです。このような実装を生成するには、通常、インターネット技術コミュニティとのある程度の相互作用が必要であり、優れた通信ソフトウェアエンジニアリングプラクティスに従う必要があります。多くの場合、この文書の要件は、標準プロトコル文書で既に明示的または暗黙的に述べられているため、ここに含めることはある意味で冗長です。それらを含めたのは、過去の一部の実装が誤った選択を行い、相互運用性、パフォーマンス、および/または堅牢性の問題を引き起こしたためです。

このメモには、多くの要件と推奨事項に関する議論と説明が含まれています。単純な要件リストは危険です。なぜなら:

ある必須機能は他のものよりも重要であり、ある機能はオプションです。
ある機能はルーターの特定のアプリケーションでは重要ですが、他のアプリケーションでは無関係です。
制限された環境向けに設計された特定のベンダー製品には、異なる仕様を使用する正当な理由があるかもしれません。

ただし、インターネットの多様性と複雑性において任意のルーター相互運用性を実現するという全体的な目標を達成するには、このメモの仕様に従う必要があります。現在のほとんどの実装が、さまざまな側面(いくつかは軽微で、いくつかは重大)でこれらの要件を満たしていないにもかかわらず、この仕様は私たちが目指すべき理想です。

これらの要件は、現在のインターネットアーキテクチャの水準に基づいています。このメモは、仕様がまだ進化している分野に追加の情報を含めるか、追加の明確化を提供するために、必要に応じて更新されます。

1.1 Reading this Document

1.1.1 Organization (構成)

このメモは、[INTRO:2]および[INTRO:3]で使用されている階層的な構成を模倣しています。したがって、第2章ではインターネットアーキテクチャの層について説明します。第3章はリンク層をカバーします。第4章と第5章はネットワーク層プロトコルと転送アルゴリズムに焦点を当てています。第6章はトランスポート層をカバーします。上位層プロトコルは第7、8、9章に分散されています。第7章では、ルーターが互いにルーティング情報を交換するために使用するプロトコルについて説明します。第8章ではネットワーク管理について説明します。第9章では他の上位層プロトコルについて説明します。最後の章では、運用と保守機能をカバーします。この構成は、シンプルさ、明確さ、およびホスト要件RFCとの一貫性のために選択されました。このメモの付録には、参考文献、用語集、およびルーター標準の今後の方向性に関するいくつかの推測が含まれています。

要件を記述する際、実装がプロトコルの階層を厳密に反映していると仮定します。ただし、厳密な階層化は、プロトコルファミリーと推奨される実装方法の両方にとって不完全なモデルです。異なる層のプロトコルは、複雑で時には微妙な方法で相互作用し、特定の機能はしばしば複数の層を含みます。実装には多くの設計上の選択肢があり、その多くは厳密な階層化を創造的に破ることを含みます。各実装者は、[INTRO:4]および[INTRO:5]を読むことを強くお勧めします。

このメモの各主要部分は、次のサブセクションに編成されています:

(1) Introduction (はじめに)

(2) Protocol Walk-Through (プロトコルウォークスルー) - プロトコル仕様文書をセクションごとに考慮し、エラーを修正し、曖昧または不明確な可能性のある要件を述べ、さらなる明確化または説明を提供します。

(3) Specific Issues (具体的な問題) - ウォークスルーに含まれていないプロトコル設計と実装の問題について議論します。

このメモの多くの個別トピックの下に、DISCUSSIONまたはIMPLEMENTATIONとラベル付けされた括弧付きの資料があります。この資料は、前の要件テキストに対する理論的根拠、明確化、または説明を提供することを目的としています。実装資料には、実装者が検討したい提案されたアプローチが含まれています。DISCUSSIONおよびIMPLEMENTATIONセクションは標準の一部ではありません。

1.1.2 Requirements (要件)

このメモでは、各特定の要件の重要性を定義するために使用される単語はすべて大文字です。これらの単語は次のとおりです:

MUST (必須) この単語は、その項目が仕様の絶対要件であることを意味します。このような要件に違反することは根本的なエラーです。いかなる状況も正当化されません。
MUST IMPLEMENT (実装必須) このフレーズは、この仕様がその項目の実装を要求することを意味しますが、デフォルトで有効にすることを要求しません。
MUST NOT (禁止) このフレーズは、その項目が仕様の絶対禁止事項であることを意味します。
SHOULD (推奨) この単語は、特定の状況で特定の項目を無視する正当な理由があるかもしれないことを意味しますが、別の道を選択する前に、すべての影響を完全に理解し、注意深く検討する必要があります。
SHOULD IMPLEMENT (実装推奨) このフレーズの意味はSHOULDに似ていますが、特定の機能を提供することを推奨するが、必ずしもデフォルトで有効にすることを推奨しない場合に使用されます。
SHOULD NOT (非推奨) このフレーズは、特定の状況で記述された動作を受け入れることが正当で有用な理由があるかもしれないことを意味します。それでも、このラベルの付いた動作を実装する前に、すべての影響を完全に理解し、注意深く検討する必要があります。
MAY (任意) この単語は、その項目が真にオプションであることを意味します。あるベンダーは、特定の市場がそれを要求するため、または製品を強化するために、その項目を含めることを選択するかもしれません。別のベンダーは同じ項目を省略するかもしれません。

1.1.3 Compliance (適合性)

一部の要件はすべてのルーターに適用されます。他の要件は、特定の機能またはプロトコルを実装するルーターにのみ適用されます。以下の段落では、「関連する (relevant)」とは、すべてのルーターに適用される要件セットと、実装された機能とプロトコルのセットのために特定のルーターに適用される要件セットの和集合を意味します。

すべての関連する要件がこのメモに直接述べられているわけではないことに注意してください。このメモのさまざまなセクションは、ホスト要件仕様[INTRO:2]および[INTRO:3]のセクションを参照によって組み込んでいます。このメモへの適合性を判断するために、関連する要件がこのメモに直接述べられているか、これらの文書のいずれかから参照によってのみ組み込まれているかは重要ではありません。

実装がすべての関連するMUST、MUST IMPLEMENT、およびMUST NOT要件を満たす場合、その実装は条件付き適合 (conditionally compliant) と呼ばれます。実装が条件付き適合であり、さらにすべての関連するSHOULD、SHOULD IMPLEMENT、およびSHOULD NOT要件を満たす場合、その実装は無条件適合 (unconditionally compliant) と呼ばれます。実装が条件付き適合でない場合(つまり、1つ以上の関連するMUST、MUST IMPLEMENT、またはMUST NOT要件を満たさない場合)、その実装は非適合です。

この仕様は時折、実装が管理変数を実装すべきであり (SHOULD)、特定のデフォルト値を持つべきであると指摘しています。無条件適合実装はデフォルトの動作を実装し、他の実装された動作がある場合はその変数を実装します。条件付き適合実装は、変数のデフォルト設定が何であるかを明確に文書化するか、変数が実装されていない場合に何と解釈される可能性があるかを明確に文書化します。変数を実装せず、異なる動作を選択する実装は非適合です。

SHOULDおよびSHOULD NOT要件に対して、ルーターは、要件で規定された動作とは異なる動作をルーターに行わせる構成オプションを提供することができます。オプションにデフォルト設定があり、その設定がルーターを要求された方法で動作させる場合、このような構成オプションを持つことは、ルーターの無条件適合宣言を無効にしません。

同様に、このメモで明示的に禁止されていない限り、ルーターはMUSTまたはMUST NOT要件に違反させるオプションを提供することができます。このようなオプションを提供するルーターは、各このようなオプションにデフォルト設定があり、その設定がルーターをこのメモの要件に準拠させる場合にのみ、(完全または条件付きで)適合します。このメモの著者は、市場の現実を認識していますが、このようなオプションを提供しないことを強く推奨します。要件がMUSTまたはMUST NOTとしてマークされているのは、その分野の専門家がそれらを相互運用性またはインターネットでの正常な動作にとって特に重要であると考えているためです。ベンダーは、これらのルールに違反するオプションを提供することの顧客サポートコストを注意深く検討する必要があります。

もちろん、このメモはIPルーターの完全な仕様ではなく、OSIの世界でいわゆるプロファイル (profile) に近いものです。たとえば、このメモは多くのプロトコルの実装を要求します。それらのプロトコル仕様の大部分はこのメモで繰り返されていませんが、実装者はそれらの仕様に従ってプロトコルを実装する必要があります。

1.2 Relationships to Other Standards (他の標準との関係)

プロトコル仕様と標準化状態を調べる際に、いくつかの関連する参照文書があります:

INTERNET OFFICIAL PROTOCOL STANDARDS (インターネット公式プロトコル標準)

この文書は、インターネット標準プロセスを説明し、プロトコルの標準状態をリストします。執筆時点では、この文書の現在のバージョンは STD 1、RFC 1780、[ARCH:7]です。この文書は定期的に再発行されます。常にRFCリポジトリを参照し、この文書の最新バージョンを使用する必要があります。
Assigned Numbers (割り当て番号)

この文書は、さまざまなプロトコルで使用されるパラメーターの割り当てられた値をリストします。たとえば、IPプロトコルコード、TCPポート番号、Telnetオプションコード、ARPハードウェアタイプ、端末タイプ名をリストします。執筆時点では、この文書の現在のバージョンは STD 2、RFC 1700、[INTRO:7]です。この文書は定期的に再発行されます。常にRFCリポジトリを参照し、この文書の最新バージョンを使用する必要があります。
Host Requirements (ホスト要件)

この一対の文書は、ホストに適用される仕様をレビューし、あいまいさに対するガイダンスと明確化を提供します。これらの要件は、このメモで別途規定されていない限り、ルーターにも適用されることに注意してください。執筆時点では、これらの文書の現在のバージョンは RFC 1122 および RFC 1123 (STD 3)、[INTRO:2]および[INTRO:3]です。
Router Requirements (ルーター要件、以前はゲートウェイ要件と呼ばれていました)

このメモです。

これらの文書は異なる時期に改訂および更新されることに注意してください。これらの文書間に相違がある場合は、最新のものが優先されなければなりません。

これらおよび他のインターネットプロトコル文書は、次のアドレスから入手できます:

The InterNIC
DS.INTERNIC.NET
InterNIC Directory and Database Service
info@internic.net
+1-908-668-6587
URL: http://ds.internic.net/

1.3 General Considerations (一般的な考慮事項)

インターネットソフトウェアベンダーは、新しいベンダーが真剣に検討すべきいくつかの重要な教訓を学んできました。

1.3.1 Continuing Internet Evolution (継続的なインターネットの進化)

インターネットの巨大な成長は、大規模なデータグラムパケット通信システムの管理とスケーリングに関する問題を明らかにしました。これらの問題は解決されつつあるため、このメモで説明されている仕様は引き続き進化します。新しいルーティングプロトコル、アルゴリズム、アーキテクチャが継続的に開発されています。新しいネットワーク層プロトコルと既存のプロトコルへの変更も継続的に設計されています。ルーターはインターネットで重要な役割を果たし、インターネットに展開されたルーターの数はホストの数よりもはるかに少ないです。したがって、ベンダーはルーター標準がホスト標準よりも速く進化し続けることを予想する必要があります。これらの変更は、ベンダーとネットワーク運用を担当する組織が計画に広く参加しているため、注意深く計画および制御されます。

開発、進化、改訂は、今日のコンピューターネットワークプロトコルの特徴であり、この状況は数年間続くでしょう。インターネットプロトコルファミリー(または他のプロトコルファミリー!)のコンピューター通信ソフトウェアを開発し、その後、変化する仕様に対応するためにそのソフトウェアを維持および更新しないベンダーは、不満な顧客の列を残すでしょう。インターネットは大規模な通信ネットワークであり、ユーザーは常に連絡を取り合っています。経験は、ベンダーソフトウェアの欠陥に関する知識がインターネット技術コミュニティ全体に非常に迅速に広がることを示しています。

1.3.2 Robustness Principle (堅牢性の原則)

プロトコルのすべての層で、[TRANS:2]のJon Postelからの一般的なルールがあり、その適用は堅牢性と相互運用性に大きな利益をもたらすことができます:

自分がすることには保守的であれ、
他人から受け入れるものには寛容であれ。

ソフトウェアは、想像できるすべてのエラーを処理するように記述する必要があります。いかに起こりそうもないものでも。最終的に、その特定のエラーと属性の組み合わせを持つパケットが到着し、ソフトウェアが準備されていなければ、混乱に陥ります。ネットワークが、最悪の効果を生み出すように設計されたパケットを送信する悪意のあるエンティティで満たされていると仮定するのが最善です。この仮定は、適切な保護設計につながります。インターネットで最も深刻な問題は、低確率イベントによってトリガーされる予期しないメカニズムによって引き起こされます。単純な人間の悪意は決してそんなに曲がりくねった道をたどりません!

変化に適応する能力は、ルーターソフトウェアのすべての層に設計されなければなりません。簡単な例として、特定のヘッダーフィールドの値の列挙を含むプロトコル仕様を考えてみましょう。たとえば、タイプフィールド、ポート番号、またはエラーコード。この列挙は不完全であると仮定する必要があります。プロトコル仕様が4つの可能なエラーコードを定義している場合、5番目のコードが定義されたときにソフトウェアがクラッシュしてはなりません。未定義のコードはログに記録されるかもしれませんが、決して失敗を引き起こしてはなりません。

原則の第2の部分もほぼ同様に重要です: ホストまたは他のルーター上のソフトウェアには欠陥が含まれている可能性があり、これにより、合法的だが曖昧なプロトコル機能を利用することは賢明ではありません。明白でシンプルなプラクティスから離れることは賢明ではありません。他の場所で悪影響を及ぼす可能性があるためです。この点の系は: 誤動作するホストに注意してください。ルーターソフトウェアは、誤動作するホストが存在する状態で生き残る準備ができている必要があります。ルーターのインターネットでの重要な機能の1つは、このようなホストが共有通信設備に引き起こす可能性のある損害の量を制限することです。

1.3.3 Error Logging (エラーログ)

インターネットには、さまざまなシステムが含まれており、それぞれが多くのプロトコルとプロトコル層を実装しています。その中には、インターネットプロトコルソフトウェアにエラーや誤解を招く機能が含まれているものもあります。複雑さ、多様性、機能の分散のために、問題の診断は非常に困難な場合があります。

ルーターに、エラーまたは異常なイベントをログに記録するための注意深く設計された施設が含まれている場合、問題の診断に役立ちます。エラーをログに記録する際には、できるだけ多くの診断情報を含めることが重要です。特に、エラーを引き起こしたパケットのヘッダーをログに記録することは多くの場合有用です。ただし、エラーログが過度のリソースを消費したり、他の方法でルーターの動作を妨げたりしないようにするよう注意する必要があります。

異常だが無害なプロトコルイベントは、エラーログファイルを氾濫させる傾向があります。これは、循環ログを使用するか、既知の障害を診断するときにのみログ記録を有効にすることで回避できます。重複する連続したメッセージをフィルタリングおよびカウントすることが有用な場合があります。非常に効果的と思われる1つの戦略は、同時に:

常に異常な状況をカウントし、管理プロトコルを通じてこのようなカウントにアクセスできるようにする(第8章を参照)。および
さまざまなイベントのログ記録を選択的に有効にできるようにする。たとえば、すべてをログに記録したり、ホストXのすべてをログに記録したりできることが有用な場合があります。

このトピックは[MGT:5]でさらに議論されています。

1.3.4 Configuration (構成)

理想的な世界では、ルーターは構成が簡単で、完全に自己構成である可能性さえあります。しかし、現実世界の実際の経験は、これが不可能な目標であることを示しており、ベンダーが構成を簡単にするために行った多くの試みは、実際には予防するよりも顧客に多くのトラブルをもたらしました。極端な例として、構成情報なしで起動し、パケットのルーティングを開始するように設計されたルーターは、ほぼ確実に一部の不正なパラメーターを選択し、接続された不運なネットワークで深刻な問題を引き起こす可能性があります。

このメモは、パラメーターが構成可能なオプションでなければならないことを頻繁に要求します。これにはいくつかの理由があります。少数のケースでは、現在、最適な値についてある程度の不確実性または意見の相違があり、推奨値を将来更新する必要があるかもしれません。他のケースでは、値が外部要因に依存します。たとえば、通信負荷の分布、または近くのネットワークの速度とトポロジーであり、自己調整アルゴリズムが利用できないか、不十分な場合があります。いくつかのケースでは、管理要件のために構成可能性が必要です。

最後に、一部の構成オプションは、プロトコルの古いまたは不正な実装との通信に必要であり、これらはインターネットの多くの部分に存在し、ソースコードの配布はありません。正しいシステムがこれらの欠陥のあるシステムと共存するには、管理者は時折正しいシステムを誤って構成する必要があります。この問題は、欠陥のあるシステムの廃止とともに徐々に自己修正されますが、ベンダーは無視できません。

パラメーターが構成可能でなければならないと言うとき、私たちは、起動のたびに構成ファイルからその値を明示的に読み取ることを要求するつもりはありません。多くのパラメーターには、最も異常な状況を除くすべての状況に適した値があります。この場合、明示的に設定されていない場合、パラメーターがその値にデフォルトすることは非常に合理的です。

場合によっては、このメモはこのようなデフォルト値の特定の値を要求します。構成項目が既存の欠陥のあるシステムへの適応を制御する場合、デフォルト値の選択は微妙な問題です。インターネットが完全な相互運用性に収束することに成功するためには、実装に組み込まれたデフォルト値は、欠陥のある実装に対応するための誤った構成ではなく、公式プロトコルを実装する必要があります。市場の現実により、一部のベンダーは誤った構成のデフォルト値を選択しますが、ベンダーに標準に準拠したデフォルト値を選択するよう強く求めます。

最後に、ベンダーはすべての構成パラメーター、その制限、および影響に関する十分な文書を提供する必要があることに注意します。

1.4 Algorithms (アルゴリズム)

このメモのいくつかの場所で、ルーターが従うべき特定のアルゴリズムが指定されています。これらのアルゴリズム自体はルーターの必須事項ではありません。ルーターは、この文書に書かれているとおりに各アルゴリズムを実装する必要はありません。代わりに、実装は、指定されたアルゴリズムの厳密で文字通りの実装と同じ動作を外部世界に提示する必要があります。

アルゴリズムの記述方法は、優秀な実装者がそれらを実装する方法とは異なります。説明の目的で、簡潔さ、明確さ、および実装の詳細からの独立性を強調するスタイルが選択されました。優秀な実装者は、これらのアルゴリズムと同じ結果を生成するアルゴリズムと実装方法を選択しますが、より効率的またはそれほど汎用的ではない場合があります。

効率的なルーター実装の技術は、このメモの範囲を超えていることに注意してください。

2. Internet Architecture (インターネット・アーキテクチャ)

この章にはいかなる要件も含まれていません。ただし、インターネットおよびルーターの全般的なアーキテクチャに関する有用な背景情報は含まれています。

インターネット・アーキテクチャおよびそれを支えるプロトコル群に関する一般的な背景と議論は、DDN Protocol Handbook [ARCH:1] に記載されています。背景としては、たとえば [ARCH:2]、[ARCH:3]、[ARCH:4] を参照してください。インターネット・アーキテクチャとプロトコルは、[ARCH:5] や [ARCH:6] などの増え続ける多数の教科書でも扱われています。

2.1 Introduction (導入)

インターネット・システムは、インターネット・プロトコルを用いてホストコンピュータ間の通信を支援する、相互接続された複数のパケットネットワークから構成されます。これらのプロトコルには、Internet Protocol (IP)、Internet Control Message Protocol (ICMP)、Internet Group Management Protocol (IGMP)、およびそれらに依存するさまざまなトランスポート・プロトコルとアプリケーション・プロトコルが含まれます。セクション [1.2] で説明したように、Internet Engineering Steering Group はすべてのインターネット・プロトコルを列挙した Official Protocols メモを定期的に公開しています。

すべてのインターネット・プロトコルは、IP を基本的なデータ転送メカニズムとして使用します。IP はデータグラム、すなわちコネクションレスのインターネットワーク・サービスであり、アドレッシング、タイプ・オブ・サービス指定、フラグメンテーションと再構成、およびセキュリティの規定を含みます。ICMP と IGMP は、アーキテクチャ上は IP の上に層を成していますが、IP の不可分な一部と見なされます。ICMP はエラー報告、フロー制御、ファーストホップ・ルーターのリダイレクション、およびその他の保守・制御機能を提供します。IGMP は、ホストとルーターが IP マルチキャスト・グループに参加および離脱するためのメカニズムを提供します。

信頼性の高いデータ配信は、Transmission Control Protocol (TCP) などのトランスポート層プロトコルによってインターネット・プロトコル群に提供されます。TCP は、エンドツーエンドの再送信、再順序付け、およびコネクション制御を提供します。トランスポート層のコネクションレス・サービスは、User Datagram Protocol (UDP) によって提供されます。

2.2 Elements of the Architecture (アーキテクチャの要素)

2.2.1 Protocol Layering (プロトコルの層化)

インターネット・システムを使用して通信するには、ホストはインターネット・プロトコル群を構成する層化されたプロトコル群を実装しなければなりません。ホストは通常、各層から少なくとも 1 つのプロトコルを実装する必要があります。

インターネット・アーキテクチャで使用されるプロトコル層は、以下のとおりです [ARCH:7]:

Application Layer (アプリケーション層) Application Layer はインターネット・プロトコル群の最上位層です。インターネット・スイートはアプリケーション層をさらに細分しませんが、一部のアプリケーション層プロトコルには内部的なサブ層が存在します。インターネット・スイートのアプリケーション層は、OSI 参照モデル [ARCH:8] の上位 2 層（Presentation と Application）の機能を本質的に統合しています。また、インターネット・プロトコル群の Application Layer には、OSI 参照モデルの Session Layer に割り当てられた機能の一部も含まれます。

アプリケーション層プロトコルは、ユーザーに直接サービスを提供するユーザー・プロトコルと、共通のシステム機能を提供するサポート・プロトコルの 2 つのカテゴリに区別されます。最も一般的なインターネット・ユーザー・プロトコルは次のとおりです:
- Telnet (リモートログイン)
- FTP (ファイル転送)
- SMTP (電子メール配信)
その他に多数の標準化されたユーザー・プロトコルと、多くの私用ユーザー・プロトコルが存在します。

サポート・プロトコルには、ホスト名マッピング、ブート、および管理に用いられる SNMP、BOOTP、TFTP、Domain Name System (DNS) プロトコル、およびさまざまなルーティング・プロトコルが含まれます。

ルーターに関連する Application Layer プロトコルについては、このメモの第 7、8、9 章で説明します。
Transport Layer (トランスポート層) Transport Layer はエンドツーエンドの通信サービスを提供します。この層は OSI 参照モデルの Transport Layer とほぼ同等ですが、OSI の Session Layer の確立・破棄機能の一部も取り込んでいます。

現在、主要な Transport Layer プロトコルは 2 つあります:
- Transmission Control Protocol (TCP)
- User Datagram Protocol (UDP)
TCP は信頼性の高いコネクション指向のトランスポート・サービスであり、エンドツーエンドの信頼性、再順序付け、およびフロー制御を提供します。UDP はコネクションレス（データグラム）のトランスポート・サービスです。その他のトランスポート・プロトコルは研究コミュニティによって開発されており、公式なインターネット・トランスポート・プロトコルの集合は将来拡張される可能性があります。

ルーターに関連する Transport Layer プロトコルについては、第 6 章で説明します。
Internet Layer (インターネット層) すべてのインターネット・トランスポート・プロトコルは、Internet Protocol (IP) を使用してデータを送信元ホストから宛先ホストへ運びます。IP はコネクションレスないしデータグラムのインターネットワーク・サービスであり、エンドツーエンドの配信保証を提供しません。IP データグラムは、宛先ホストに到達した際に、破損していたり、重複していたり、順序が入れ替わっていたり、あるいは到達しなかったりすることがあります。IP より上位の層は、必要なときに信頼性の高い配信サービスに対して責任を負います。IP プロトコルには、アドレッシング、タイプ・オブ・サービス指定、フラグメンテーションと再構成、およびセキュリティの規定が含まれます。

IP のデータグラムないしコネクションレスという性質は、インターネット・アーキテクチャの基本的かつ特徴的な特徴です。

Internet Control Message Protocol (ICMP) は、IP の不可分な一部と見なされる制御プロトコルですが、アーキテクチャ上は IP の上に層を成しています。つまり、IP を使用してデータをエンドツーエンドで運びます。ICMP はエラー報告、輻輳報告、およびファーストホップ・ルーターのリダイレクションを提供します。

Internet Group Management Protocol (IGMP) は、IP マルチキャストのための動的ホストグループを確立するために使用されるインターネット層プロトコルです。

Internet 層プロトコルである IP、ICMP、および IGMP については、第 4 章で説明します。
Link Layer (リンク層) 直接接続されたネットワーク上で通信するには、ホストはそのネットワークとのインタフェースに使用される通信プロトコルを実装しなければなりません。これを Link Layer プロトコルと呼びます。

一部の古いインターネット文書ではこの層を Network Layer と呼んでいますが、これは OSI 参照モデルの Network Layer と同じものではありません。

この層には、Internet Layer の下かつ Physical Layer（メッセージを符号化して伝送する、通常は電気的または光学的な媒体接続）の上のすべてが含まれます。その責任は、メッセージを正しく配信することであり、メッセージ間の差異は区別しません。

この層のプロトコルは一般にインターネット標準化の範囲外です。インターネットは（意図的に）可能な限り既存の標準を使用します。したがって、インターネットの Link Layer 標準は、通常、アドレス解決および特定の Link Layer プロトコル上での IP パケット送信の規則のみを扱います。インターネットの Link Layer 標準については、第 3 章で説明します。

2.2.2 Networks (ネットワーク)

インターネット・システムを構成するネットワークには、パケット（コネクションレス）転送のみが要求されます。IP サービス仕様によれば、データグラムは順序不同に配信されたり、消失したり、重複したり、および/または誤りを含んだりすることがあります。

IP を使用するプロトコル（TCP など）の性能を合理的に保つには、ネットワークの損失率は非常に低くなければなりません。コネクション指向サービスを提供するネットワークでは、仮想回線によってもたらされる追加の信頼性がエンドツーエンドの堅牢性を高めますが、インターネットの動作に必須というわけではありません。

構成ネットワークは一般に 2 つのクラスに分類できます:

Local-Area Networks (LANs、ローカル・エリア・ネットワーク) LAN にはさまざまな設計があり得ます。LAN は通常、小さな地理的領域（たとえば単一の建物やプラント拠点）をカバーし、低遅延で高帯域幅を提供します。LAN はパッシブ（Ethernet に類似）であったり、アクティブ（ATM など）であったりします。
Wide-Area Networks (WANs、ワイド・エリア・ネットワーク) 地理的に分散したホストや LAN は、ワイド・エリア・ネットワーク（長距離ネットワークとも呼ばれる）によって相互接続されます。これらのネットワークは、回線と同一の複雑な内部構造を持つ場合があります。また、単純なポイントツーポイント回線である場合もあります。

2.2.3 Routers (ルーター)

インターネット・モデルでは、構成ネットワークはルーターまたは IP ルーターと呼ばれる IP データグラム転送装置によって相互接続されます。この文書では、router という用語のすべての使用は IP ルーターと同等です。多くの古いインターネット文書では、ルーターのことを gateway と呼んでいます。

歴史的に、ルーターは汎用 CPU 上で実行されるパケット交換ソフトウェアとして実現されてきました。しかし、カスタム・ハードウェア開発が安価になるにつれ、またより高いスループットが要求されるようになり、専用ハードウェアがますます一般的になっています。この仕様は、実装方法を問わずルーターに適用されます。

ルーターは 2 つ以上の論理インタフェース（IP サブネット、または番号なしポイントツーポイント回線（セクション [2.2.7] で説明）によって表される）に接続します。したがって、ルーターは少なくとも 1 つの物理インタフェースを持ちます。IP データグラムを転送するには、通常、ルーターがネクストホップ・ルーターのアドレスと該当インタフェース、または（最終ホップの場合）宛先ホストを選択する必要があります。この選択は、リレーまたは転送と呼ばれ、ルーター内のルート・データベースに依存します。ルート・データベースは、ルーティング・テーブルまたは転送テーブルとも呼ばれます。「router」という用語は、このルート・データベースを構築するプロセスに由来します。ルーティング・プロトコルと設定は、ルーティングと呼ばれるプロセスの中で相互作用します。

ルーティング・データベースは、インターネット・システムの現在のトポロジを反映するように動的に保守されるべきです。ルーターは通常、他のルーターとの分散ルーティングおよび到達可能性アルゴリズムに参加することでこれを実現します。

ルーターはデータグラム転送のみを提供し、ルーティングの柔軟性と堅牢性を維持するために、このサービスを維持するために必要な状態情報を最小限に抑えようとします。

パケット交換装置は Link Layer でも動作する場合があります。そのような装置は通常ブリッジと呼ばれます。ブリッジによって接続されたネットワーク・セグメントは、同じ IP ネットワーク・プレフィックスを共有し、単一の IP サブネットを形成します。これらの他の装置は、この文書の範囲外です。

2.2.4 Autonomous Systems (自律システム)

Autonomous System (AS、自律システム) とは、一連のルートによって相互接続されたサブネットワーク（ホストが接続されている）の集合からなる、ネットワーク・トポロジの接続されたセグメントです。サブネットワークとルーターは、単一の運用・保守 (O&M) 組織の管理下にあることが期待されます。AS 内では、ルーターは 1 つ以上の内部ルーティング・プロトコル、および場合によっては複数のメトリクス群を使用することがあります。AS は、他の AS に対して一貫した内部ルーティング計画と、その AS を通じて到達可能な宛先の一貫した像を提示することが期待されます。AS は Autonomous System 番号によって識別されます。

AS の概念は、インターネット・ルーティングにおいて重要な役割を果たします（セクション 7.1 参照）。

2.2.5 Addressing Architecture (アドレッシング・アーキテクチャ)

IP データグラムは 32 ビットの送信元アドレスと宛先アドレスを運び、それぞれは 2 つの部分、すなわち構成ネットワーク・プレフィックスとそのネットワーク上のホスト番号に分割されます。記号的には:

IP-address ::= { <Network-prefix>, <Host-number> }

データグラムを最終的に配信するには、経路上の最後のルーターが、IP アドレスの Host-number（または残り）部分をホストの Link Layer アドレスにマップしなければなりません。

2.2.5.1 Classical IP Addressing Architecture (古典的 IP アドレッシング・アーキテクチャ)

[INTERNET:2] など他处で十分に文書化されているが、ネットワーク・プレフィックスの歴史的な使用法を説明しておくことは有用である。それを記述するために発展した言語は、この文書および他の文書で使用され、多くのプロトコル背後の思考に浸透しています。

最も単純な古典的なネットワーク・プレフィックスは、Class A、B、C、D、または E のネットワーク・プレフィックスです。これらのアドレス範囲は、アドレスの最上位ビットの値を観察することによって区別され、アドレスを単純なプレフィックスとホスト番号フィールドに分割します。これは [INTERNET:18] で説明されています。簡単に言えば、分類は次のとおりです:

0xxx   - Class A - 標準的な 8 ビット・プレフィックスを持つ汎用ユニキャスト・アドレス
10xx   - Class B - 標準的な 16 ビット・プレフィックスを持つ汎用ユニキャスト・アドレス
110x   - Class C - 標準的な 24 ビット・プレフィックスを持つ汎用ユニキャスト・アドレス
1110   - Class D - IP マルチキャスト・アドレス - 28 ビット・プレフィックス、集約不可
1111   - Class E - 実験用に予約

この単純な概念は、サブネットの概念によって拡張されました。サブネットは、組織内の相互接続された LAN 構造の任意の複雑さを許容しながら、割り当てられたネットワーク・プレフィックスとルーティングの複雑さの爆発的増大からインターネット・システムを保護するために導入されました。サブネットは、インターネット・システムに多レベルの階層的ルーティング構造を提供します。[INTERNET:2] で説明されているサブネット拡張は、インターネット・アーキテクチャの必須部分です。基本的な考え方は、フィールドを 2 つの部分、すなわちサブネット番号とそのサブネット上の真のホスト番号に分割することです:

IP-address ::=
  { <Network-number>, <Subnet-number>, <Host-number> }

組織内の相互接続された物理ネットワークは、同じネットワーク・プレフィックスを使用しますが、サブネット番号は異なります。そのようなサブネット化されたネットワークのサブネット間の違いは、通常、そのネットワークの外部からは見えません。したがって、インターネットの残りの部分でのルーティングは、IP 宛先アドレスの部分のみを使用します。ネットワーク外のルーターは、とを合わせて、32 ビット IP アドレスの解釈されない残り部分として扱います。サブネット化されたネットワーク内では、ルーターは拡張ネットワーク・プレフィックスを使用します:

{ <Network-number>, <Subnet-number> }

この拡張ネットワーク番号を含むビット位置は、歴史的にサブネット・マスクと呼ばれる 32 ビットのマスクによって示されてきました。ビットは連続しており、とフィールドの間に位置するべきです (SHOULD)。より最新のプロトコルはサブネット・マスクではなくプレフィックス長を参照します。アドレスの「プレフィックス」部分とは、最上位ビットがすべて 1 で残りがすべて 0 であるサブネット・マスクによって選択される部分です。プレフィックスの長さは、サブネット・マスク内の 1 の数に等しくなります。この文書は、すべてのサブネット・マスクがプレフィックス長として表現可能であると想定します。

サブネット機構の発明者たちは、組織のネットワークの各部分が単一のサブネット番号しか持たないと想定していました。しかし実際には、複数のサブネットが単一の物理ケーブルを共有することが必要または有用であることが多々あります。このため、ルーターは同じ物理インタフェース上に複数のサブネットを設定でき、ルーティングまたは転送の観点からは、それらを別個の物理インタフェースであるかのように扱うことができるべきです。

2.2.5.2 Classless Inter Domain Routing (CIDR、クラスレス域間ルーティング)

インターネットの爆発的な成長により、アドレス割り当てポリシーの見直しが強制されました。汎用（Class A、B、C）ネットワークの伝統的な使用法は、IP の 32 ビット・アドレス空間のより良い利用を達成するために修正されました。Classless Inter Domain Routing (CIDR) [INTERNET:15] は、この追加の効率を達成するためにインターネット・バックボーンに現在展開されている方法です。CIDR は、任意のサイズのネットワークへの展開とルーティングに依存します。このモデルでは、ホストとルーターはインターネット内のアドレッシングの使用についていかなる想定も行いません。Class D（IP マルチキャスト）および Class E（実験用）アドレス空間は保存されますが、これは主に割り当てポリシーです。

定義により、CIDR は 3 つの要素から構成されます:

トポロジ的に有意なアドレス割り当て
ネットワーク層到達可能性情報を集約できるルーティング・プロトコル
一貫した転送アルゴリズム（「最長一致」）

ネットワークとサブネットの使用は現在では歴史的なものですが、それらを記述する言語は現在も使用中です。それらは、より扱いやすいネットワーク・プレフィックスという概念に置き換えられました。ネットワーク・プレフィックスとは、定義により、一連のシステムを定義するアドレスのより上位側の連続したビットの集合です。ホスト番号はそれらのシステムの中から選択します。インターネット全体が一律にネットワーク・プレフィックスを使用することは要求されません。ルーティング情報を折りたたむために、インターネットをアドレッシング領域に分割することが有用です。そのような領域内では、構成ネットワークに関する詳細情報が利用可能です。領域外では、共通のネットワーク・プレフィックスのみがアドバタイズされます。

古典的な IP アドレッシング・アーキテクチャは、ホスト番号をネットワーク・プレフィックスから区別するためにアドレスとサブネット・マスクを使用していました。ネットワーク・プレフィックスでは、プレフィックス内のビット数を示すだけで十分です。両方の表現が一般的に使用されています。アーキテクチャ的に正しいサブネット・マスクは、プレフィックス長記述を使用して表現できるものです。それらは、すべての可能なビット・パターンのうち、次のものを備えるサブセットを構成します:

より上位側に連続した 1 の文字列
より下位側に連続した 0 の文字列
その間にビットがないこと

ルーターは常にルートをネットワーク・プレフィックスとして扱い、そのモデルと矛盾する設定およびルーティング情報を拒否すべきです (SHOULD)。

IP-address ::= { <Network-prefix>, <Host-number> }

CIDR を使用する効果の 1 つは、ルーティング・テーブル内のアドレス・プレフィックスに関連付けられた宛先の集合が部分集合関係を示し得ることです。より小さな宛先集合（より長いプレフィックス）を記述するルートは、より大きな宛先集合（より短いプレフィックス）を記述するルートよりも具体的 (more specific) であると言われます。同様に、より大きな宛先集合（より短いプレフィックス）を記述するルートは、より小さな宛先集合（より長いプレフィックス）を記述するルートよりも抽象的 (less specific) であると言われます。ルーターはトラフィックを転送するとき、最も具体的に一致するルート（最長一致ネットワーク・プレフィックス）を使用しなければなりません (MUST)。

2.2.6 IP Multicasting (IP マルチキャスト)

IP マルチキャストは、Link Layer マルチキャストの IP インターネットへの拡張です。IP マルチキャストを使用すると、単一のデータグラムを、すべてに送信することなく複数のホストに宛てることができます。拡張された場合、これらのホストは異なるアドレス領域に存在し得ます。このホストの集合はマルチキャスト・グループと呼ばれます。各マルチキャスト・グループは、Class D の IP アドレスとして表現されます。グループに送信された IP データグラムは、ユニキャスト IP トラフィックに提供されるものと同じベストエフォート配信で、各グループ・メンバーに配信されます。データグラムの送信者自身が宛先グループのメンバーである必要はありません。

IP マルチキャスト・グループ・メンバーシップのセマンティクスは [INTERNET:4] で定義されています。その文書は、ホストとルーターがマルチキャスト・グループに参加および離脱する方法を説明しています。また、IP マルチキャスト・グループ・メンバーシップを監視するプロトコル、Internet Group Management Protocol (IGMP) も定義しています。

IP マルチキャスト・データグラムの転送は、静的ルーティング情報、またはマルチキャスト・ルーティング・プロトコルを通じて行われます。IP マルチキャスト・データグラムを転送する装置は、マルチキャスト・ルーターと呼ばれます。それらは IP ユニキャストも転送する場合としない場合があります。マルチキャスト・データグラムは、送信元アドレスと宛先アドレスの両方に基づいて転送されます。IP マルチキャスト・パケットの転送については、セクション [5.2.1] でより詳しく説明し、付録 D でマルチキャスト・ルーティング・プロトコルを論じます。

2.2.7 Unnumbered Lines and Networks Prefixes (番号なし回線とネットワーク・プレフィックス)

伝統的に、IP ホストまたはルーター上の各ネットワーク・インタフェースは独自の IP アドレスを持ちます。これは、すべてのポイントツーポイント・リンクに IP ネットワーク・プレフィックスの割り当てを強制するため、希少な IP アドレス空間の非効率的な使用を引き起こす可能性があります。

この問題を解決するために、多くの人々が番号なしポイントツーポイント回線の概念を提案し、実装してきました。番号なしポイントツーポイント回線には、それに関連付けられたネットワーク・プレフィックスはありません。その結果、番号なしポイントツーポイント回線に接続されたネットワーク・インタフェースには IP アドレスがありません。

IP アーキテクチャは伝統的にすべてのインタフェースが IP アドレスを持つと想定しているため、これらの番号なしインタフェースはいくつかの興味深いジレンマを引き起こします。たとえば、一部の IP オプション（Record Route など）は、ルーターがインタフェース・アドレスをオプションに挿入しなければならないと規定していますが、番号なしインタフェースには IP アドレスがありません。さらに根本的なこととして（第 5 章で見るように）、ルートにはネクストホップ・ルーターの IP アドレスが含まれます。ルーターは、この IP アドレスがルーターが接続されている IP（サブ）ネット上にあると想定します。その唯一の接続が番号なしポイントツーポイント回線である場合、その想定はもちろん破られます。

これらの困難を回避するために、2 つの方式が考案されました。第 1 の方式は、番号なしポイントツーポイント回線で接続された 2 つのルーターは、実際には 2 つのルーターではなく、むしろ一緒になって単一の仮想ルーターを構成する 2 つのハーフ・ルーターであるというものです。番号なしポイントツーポイント回線は、本質的に仮想ルーター内の内部バスと見なされます。仮想ルーターの 2 つの半分は、単一のルーターとまさに同じように振る舞うように活動を調整しなければなりません。

この方式は IP アーキテクチャにうまく収まりますが、2 つの重要な欠点があります。第 1 に、単一の番号なしポイントツーポイント回線という一般的なケースには対応しますが、ルーターと番号なしポイントツーポイント回線のメッシュのケースへの拡張が容易ではありません。第 2 の欠点は、ハーフ・ルーター間の相互作用が必然的に複雑であり、標準化されていないため、番号なしポイントツーポイント回線を使用した異なるベンダーの機器の接続を実質的に妨げることです。

これらの欠点のため、このメモは別の方式を採用しています。この方式は複数回発明されていますが、恐らく originally Phil Karn に帰因するものです。この方式では、番号なしポイントツーポイント回線を持つルーターは、このメモでは router-id と呼ばれる特別な IP アドレスも持ちます。router-id は、ルーターの IP アドレスの 1 つです（ルーターは少なくとも 1 つの IP アドレスを持つことが要求されます）。この router-id は、すべての番号なしインタフェースの IP アドレスであるかのように使用されます。

2.2.8 Notable Oddities (注目すべき特殊性)

2.2.8.1 Embedded Routers (組み込みルーター)

ルーターは、IP ルーター機能専用のスタンドアロン・コンピュータ・システムである場合があります。あるいは、2 つ以上のネットワークへの接続をサポートするホスト・オペレーティング・システム内にルーター機能を組み込むことも可能です。組み込みルーター・コードを持つ最もよく知られたオペレーティング・システムの例は、Berkeley BSD システムです。組み込みルーター機能はネットワーク構築を容易にするように見えますが、いくつかの隠れた落とし穴があります:

(1) ホストが単一の構成ネットワーク・インタフェースしか持たない場合、それはルーターとして動作すべきではありません (SHOULD NOT)。

例えば、組み込みルーター・コードを持つホストが、同じネット上でブロードキャスト・パケットやデータグラムをみだりに転送すると、多くの場合パケット雪崩を引き起こします。

(2) （マルチホームの）ホストがルーターとして動作する場合、この文書に含まれるルーターに対する要件の対象となります。

例えば、ルーティング・プロトコルの問題や、ルーターの制御および監視の問題は、組み込みルーターにとってもスタンドアロン・ルーターにとっても同様に困難かつ重要です。

インターネット・ルーターの要件と仕様は、オペレーティング・システムの変更とは独立に変化し得ます。インターネットで組み込みルーターを運用する管理者は、ルーター・コードを保守および更新することを強く推奨されます。これにはルーターのソースコードが必要になる場合があります。

(3) ホストが組み込みルーター・コードを実行すると、それはインターネット基盤の一部となります。したがって、ソフトウェアや設定のエラーは、他のホスト間の通信を妨げる可能性があります。その結果、ホスト管理者はある程度の自律性を失わなければなりません。

多くの状況で、ホスト管理者はオペレーティング・システムに組み込まれたルーター・コードを無効にする必要があります。このため、組み込みルーター機能を無効にすることは容易であるべきです。

(4) 組み込みルーター・コードを実行しているホストが、同時に他のサービスに使用される場合、2 つの使用モードに対する運用・保守 (O&M) 要件が衝突する可能性があります。

例えば、ルーターの O&M は多くの場合、運用センターからリモートで実行されます。これには、ホスト管理者が通常配布したくないであろう特権的なシステム・アクセスが必要になる場合があります。

2.2.8.2 Transparent Routers (透過ルーター)

インターネットでローカル・エリア・ネットワークとワイド・エリア（長距離）ネットワークを相互接続するための基本的なモデルは 2 つあります。第 1 に、ローカル・エリア・ネットワークにネットワーク・プレフィックスが割り当てられ、インターネット上のすべてのルーターがそのネットワークへのルーティング方法を知っている必要があります。第 2 に、ローカル・エリア・ネットワークがワイド・エリア・ネットワークのアドレス空間（の小さな一部）を共有します。第 2 のモデルをサポートするルーターは、アドレス共有ルーターまたは透過ルーターと呼ばれます。このメモの焦点は第 1 のモデルをサポートするルーターにありますが、これは透過ルーターの使用を除外するものではありません。

透過ルーターの基本的な考え方は、そのようなルーターの背後にあるローカル・エリア・ネットワーク上のホストが、ルーターの前にあるワイド・エリア・ネットワークのアドレス空間を共有することです。特定の状況では、これは非常に有用なアプローチであり、その制限によって重大な欠点が生じることはありません。

「前」および「後」という言葉は、このアプローチの制限の 1 つを示しています。この相互接続モデルは、地理的（およびトポロジ的に）限定されたスタブ環境にのみ適しています。これには、ワイド・エリア・ネットワークのネットワーク層アドレッシングに何らかの形態の論理アドレッシングが存在することが要求されます。ローカル環境の IP アドレスは、ワイド・エリア・ネットワーク内の少数（通常は 1 つ）の物理アドレスにマップされます。このマッピングは、ワイド・エリア・ネットワーク全体で使用される { IP アドレス <-> ネットワーク・アドレス } マッピングと整合する方法で行われます。

1 つのワイド・エリア・ネットワークでのマルチホーミングは可能ですが、インタフェースが地理的またはトポロジ的に分離されている場合、ルーティングの問題を引き起こす可能性があります。2 つ（以上）のワイド・エリア・ネットワークでのマルチホーミングは、アドレスの混同により問題となります。

透過ルーターが通常のワイド・エリア・ネットワーク・サービスを完全にエミュレートできない場合、見かけ上同じネットワークである他のホストからホストが観察する動作が異なる可能性があります。例えば、ARPANET は、オフラインのホストへの送信試行に対して Destination Dead 表示を提供する Link Layer プロトコルを使用していました。しかし、ARPANET と Ethernet の間に透過ルーターがあった場合、ARPANET 上のホストは Ethernet ホストに対する Destination Dead 表示を受け取りませんでした。

2.3 Router Characteristics (ルーターの特性)

インターネット・ルーターは、次の機能を実行します:

(1) この文書で指定された特定のインターネット・プロトコル、すなわち Internet Protocol (IP)、Internet Control Message Protocol (ICMP)、および必要に応じたその他のプロトコルに準拠すること。

(2) 2 つ以上のパケット・ネットワークへのインタフェースを持つこと。接続された各ネットワークについて、ルーターはそのネットワークに要求される機能を実装しなければなりません。これらの機能には通常、以下が含まれます:

接続されたネットワークのフレーミング（Ethernet ヘッダとチェックサムなど）による IP データグラムのカプセル化および非カプセル化
そのネットワークがサポートする最大サイズ（ネットワークの Maximum Transmission Unit、MTU）までの IP データグラムの送受信
必要に応じて、IP 宛先アドレスを接続されたネットワークの適切なネットワーク層アドレス（Ethernet ハードウェア・アドレスなど）に変換すること
もしあれば、ネットワークのフロー制御およびエラー表示への応答

詳細は第 3 章（Link Layer）を参照。

(3) インターネット・データグラムを受信および転送すること。このプロセスにおける重要な課題は、バッファ管理、輻輳制御、および公平性です。

必要に応じてエラー状況を認識し、ICMP エラーおよび情報メッセージを生成すること。
time-to-live フィールドがゼロになったデータグラムを廃棄すること。
次のネットワークの MTU に収めるために必要に応じてデータグラムをフラグメント化すること。

詳細は第 4 章（Internet Layer - Protocols）および第 5 章（Internet Layer - Forwarding）を参照。

(4) ルーティング・データベース内の情報に基づいて、各 IP データグラムのネクストホップ宛先を選択すること。詳細は第 5 章（Internet Layer - Forwarding）を参照。

(5) （通常は）内部ゲートウェイ・プロトコル (IGP) をサポートし、同じ自律システム内の他のルーターと分散ルーティングおよび到達可能性アルゴリズムを実行すること。さらに、一部のルーターは外部ゲートウェイ・プロトコル (EGP) をサポートし、他の自律システムとトポロジ情報を交換する必要があります。詳細は第 7 章（Application Layer - Routing Protocols）を参照。

(6) ロード、デバッグ、ステータス報告、例外報告、および制御を含む、ネットワーク管理およびシステム・サポート機能を提供すること。詳細は第 8 章（Application Layer - Network Management Protocols）および第 10 章（Operation and Maintenance）を参照。

ルーター・ベンダーは、特定のルーター製品の能力、複雑さ、および機能について多くの選択肢を持ちます。インターネット・システムは均質でも完全接続でもないことを観察すると有用かもしれません。技術的および地理的な理由から、インターネットはグローバルな相互接続システムと、その周辺の LAN の fringe に成長しつつあります。これらの周辺 LAN はますます密に相互接続されるようになり、その結果、fringe からより外れ、ルーター要件に対する要求が高まっています。

グローバルな相互接続システムは、複数の Autonomous System (AS) のルーターが接続された多数のワイド・エリア・ネットワークから構成されます。システムに直接接続されたホストは比較的少数です。
ほとんどのホストは LAN に接続されています。多くの組織は、ローカル・ルーターによって相互接続された LAN のクラスタを持っています。そのような各クラスタは、1 つ以上のポイントでルーターによってグローバルな相互接続システムに接続されます。単一のポイントでのみ接続されている場合、LAN はスタブ・ネットワークと呼ばれます。

グローバルな相互接続システム内のルーターには、通常次が要求されます:

高度なルーティングおよび転送アルゴリズム

これらのルーターには、高度に動的で、処理と通信の負担を最小限に抑え、タイプ・オブ・サービス・ルーティングを提供するルーティング・アルゴリズムが必要です。輻輳はまだ完全に解決された問題ではありません（セクション [5.3.6] 参照）。これらの分野の改善が期待されています。研究コミュニティはこれらの問題に積極的に取り組んでいます。

高可用性

これらのルーターは、週 7 日 24 時間のサービスを提供する、非常に高い信頼性を持つ必要があります。機器およびソフトウェアの障害は、広範囲（時にはグローバル）な影響を及ぼす可能性があります。障害の場合、迅速に復旧しなければなりません。あらゆる環境で、ルーターは非常に堅牢でなければならず、極端な輻輳やネットワーク資源の障害という条件下でも、場合によっては低下した状態で動作する能力を持たなければなりません。

高度な O&M 機能

インターネット・ルーターは通常、無人モードで動作します。通常、集中監視センターからリモートで運用されます。トラフィックやその他のイベントを監視および測定し、障害を診断するための洗練された手段を提供する必要があります。

高性能

現在のインターネットの長距離回線は、最も頻繁に全二重 56 KBPS、DS1（1.544 Mbps）、または DS3（45 Mbps）の速度です。ハーフ・デュプレックスのマルチアクセス・メディアである LAN は、通常 Ethernet（10Mbps）であり、次いで FDDI（100Mbps）です。しかし、ネットワーク・メディア技術は絶えず進歩しており、将来的にはより高い速度が予想されます。

LAN の fringe（たとえばキャンパス・ネットワーク）で使用されるルーターの要件は、ローカル・ネットワークの要求に大きく依存します。これらは高機能または中程度の性能の装置であり、おそらく複数の異なるベンダーから競争的に調達され、内部組織（たとえばキャンパス・コンピューティング・センター）によって運用されます。これらのルーターの設計は、低い平均レイテンシと良好なバースト性能、および遅延およびタイプ・オブ・サービスに敏感なリソース管理を強調すべきです。この環境では O&M がより非公式になる場合がありますが、それがより重要でないということはありません。ネットワークがより複雑かつ相互接続されるようになるにつれて、ルーティング機構が高度に動的であることの必要性はより重要になります。ユーザーは、グローバルな相互接続の速度のために、ローカル接続により多くを要求するようになります。

ネットワークの成長に伴い、また多くのネットワークが古い機器を段階的に廃止するほど古くなるにつれて、ルーターが他のベンダーのルーターと相互運用することがますます不可欠になってきました。

インターネット・システムは完全には相互接続されていませんが、システムの多くの部分は冗長接続を必要とします。豊富な接続は、通信回線やルーターの障害にもかかわらず信頼性の高いサービスを可能にし、インターネット・パスの短縮および追加容量の提供によってサービスを改善することもできます。残念ながら、このより豊かなトポロジは、特定の宛先への最適パスの選択をより困難にする可能性があります。

2.4 Architectural Assumptions (アーキテクチャ上の仮定)

現在のインターネット・アーキテクチャは、通信システムに関する一連の仮定に基づいています。ルーターに最も関連する仮定は次のとおりです:

インターネットはネットワークのネットワークである。

各ホストは特定のネットワークに直接接続されています。インターネットへのその接続は概念的なものに過ぎません。同じネットワーク上の 2 つのホストは、遠隔のネットワーク上のホストと通信する場合に使用するものと同じプロトコル群を使用して互いに通信します。

ルーターは接続状態情報を保持しない。

通信システムの堅牢性を向上させるために、ルーターはステートレスになるように設計されており、他のパケットとは独立に各 IP パケットを転送します。その結果、冗長パスを活用して、中間のルーターやネットワークの障害にもかかわらず堅牢なサービスを提供できます。

エンドツーエンドのフロー制御と信頼性に必要なすべての状態情報は、ホスト内、トランスポート層、またはアプリケーション・プログラムに実装されます。したがって、すべての接続制御情報は通信の端点と同じ場所に配置され、端点が故障した場合にのみ失われます。ルーターは、パケットを廃棄したりネットワーク遅延を増大させたりすることによってのみ、間接的にメッセージ・フローを制御します。

将来のプロトコル開発により、ルーターにさらに状態が置かれるようになる可能性が高いことに注意してください。これは特に、マルチキャスト・ルーティング、リソース予約、およびフローに基づく転送で可能性が高いです。

ルーティングの複雑さはルーター内にあるべきである。

ルーティングは複雑で困難な問題であり、ホストではなくルーターによって実行されるべきです。重要な目的は、インターネット・ルーティング・アーキテクチャの避けられない進化によって引き起こされる変更からホスト・ソフトウェアを隔離することです。

システムは広範なネットワーク変動を許容しなければならない。

インターネット設計の基本的な目的は、帯域幅、遅延、パケット損失、パケット順序の入れ替え、および最大パケット・サイズなど、広範なネットワーク特性を許容することです。別の目的は、利用可能な帯域幅を使用して、個々のネットワーク、ルーター、およびホストの障害に対する堅牢性です。最後に、目標は完全なオープン・システム相互接続です。インターネット・ルーターは、多様なインターネット・パスを介して、他のルーターやインターネット・ホストと堅牢かつ効果的に相互運用できなければなりません。

実装者がより控えめな目標に向けて設計する場合があります。例えば、LAN 環境は通常、インターネット全体よりもはるかに穏やかです。LAN はパケット損失と遅延が低く、パケットを順序替えしません。一部のベンダーは、単純な LAN 環境には十分だが、一般的な相互運用にはうまく機能しない実装を市場に出しています。ベンダーは、そのような製品を制限された LAN 市場内で経済的であると正当化します。しかし、孤立した LAN が孤立したままであることはめったにありません。それらはすぐに互いに、組織全体のインターネットに、そして最終的にはグローバルなインターネット・システムに接続されます。結局のところ、不完全または不十分なルーターによって利益を得るのは、顧客でもベンダーでもありません。

この文書の要件は、全機能ルーターのために設計されています。完全に準拠したルーターは、インターネットのほぼあらゆる部分で使用できることが意図されています。

3. Link Layer (リンク層)

[INTRO:1] は Link Layer 標準（各種リンク層上の IP、ARP など）を扱っているが、この文書は Link Layer の素材が別の Link Layer Requirements 文書で扱われることを予想しています。Link Layer Requirements 文書はホストとルーターの両方に適用可能です。したがって、この文書は [INTRO:1] のリンク層の問題を扱う部分を廃止するものではありません。

3.1 Introduction (導入)

ルーターは、他の種類のインターネット・システムと本質的に同じ Link Layer プロトコル要件を持ちます。これらの要件は、Requirements for Internet Gateways [INTRO:1] の第 3 章に記載されています。ルーターはその要件に準拠しなければならず (MUST)、その推奨事項に準拠すべきです (SHOULD)。その文書の一部の素材はやや時代遅れになっているため、以下にいくつかの追加要件と説明を含めます。

DISCUSSION インターネット・コミュニティは、この章および [INTRO:1] の「INTERNET LAYER PROTOCOLS」という章の両方に取って代わる Requirements for Internet Link Layer 標準を作成することが期待されています。

3.2 Link/Internet Layer Interface (リンク層/インターネット層インタフェース)

この文書は、Link Layer と上位層の間のインタフェースを規定する試みはしません。しかし、この文書の他の部分、特に第 5 章は、この層の境界を越えてさまざまな種類の情報を渡すことを要求することに注意してください。

このセクションは次の定義を使用します:

Source physical address (送信元物理アドレス) 送信元物理アドレスとは、パケットを受信したホストまたはルーターの Link Layer アドレスです。
Destination physical address (宛先物理アドレス) 宛先物理アドレスとは、パケットが送信された Link Layer アドレスです。

各受信パケットについて Link Layer から Internetwork Layer に渡されなければならない (MUST) 情報は:

(1) IP パケット [5.2.2] (2) データ部分（すなわち、Link Layer フレーミングを含まない）の長さ [5.2.2] (3) IP パケットを受信した物理インタフェースの識別 [5.2.3] (4) パケットの宛先物理アドレスが Link Layer ユニキャスト、ブロードキャスト、またはマルチキャストのいずれであるかの分類 [4.3.2]、[5.3.4]

さらに、Link Layer は次も提供すべきです (SHOULD):

(5) 送信元物理アドレス

各送信パケットについて Internetwork Layer から Link Layer に渡されなければならない (MUST) 情報は:

(1) IP パケット [5.2.1] (2) IP パケットの長さ [5.2.1] (3) 宛先物理インタフェース [5.2.1] (4) ネクストホップ IP アドレス [5.2.1]

さらに、Internetwork Layer も次を提供すべきです (SHOULD):

(5) Link Layer 優先度値 [5.3.3.2]

Link Layer はまた、送信しようとするパケットが Link Layer 優先度関連のエラーを引き起こす場合、Internetwork Layer に通知しなければなりません (MUST) [5.3.3.3]。

3.3 Specific Issues (具体的な問題)

3.3.1 Trailer Encapsulation (トレーラ・カプセル化)

10 メガビット Ethernet に接続できるルーターは、[LINK:1] で説明されているトレーラ・カプセル化を使用してカプセル化された Ethernet パケットを受信および転送できる場合があります (MAY)。ただし、ルーターはトレーラ・カプセル化されたパケットを発信すべきではありません (SHOULD NOT)。ルーターは、[INTRO:2] で説明されているメカニズムを使用して、パケットの直接宛先がトレーラ・カプセル化されたパケットを受け入れて処理できることを最初に確認せずに、トレーラ・カプセル化されたパケットを発信してはなりません (MUST NOT)。ルーターは（これらのメカニズムを使用して）トレーラ・カプセル化されたパケットを受け入れることに同意すべきではありません (SHOULD NOT)。

3.3.2 Address Resolution Protocol - ARP

ARP を実装するルーターは、[INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。

リンク層は、単に宛先の ARP キャッシュ・エントリがないという理由だけで、IP に対して Destination Unreachable エラーを報告してはなりません (MUST NOT)。ARP 要求/応答シーケンスの実行中に、少数のデータグラムを短時間キューに入れ、このことが実を結ばないことが判明した場合にのみ、キューに入れられたデータグラムの 1 つに対して宛先が到達不能であると応答すべきです (SHOULD)。

ルーターは、別のホストまたはルーターの Link Layer アドレスがブロードキャストまたはマルチキャスト・アドレスであると主張する ARP 応答を信じてはなりません (MUST NOT)。

3.3.3 Ethernet and 802.3 Coexistence (Ethernet と 802.3 の共存)

10 メガビット Ethernet に接続できるルーターは、[INTRO:2] の Ethernet 要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。

3.3.4 Maximum Transmission Unit - MTU

各論理インタフェースの MTU は、インタフェースの正当な MTU の範囲内で設定可能でなければなりません (MUST)。

多くの Link Layer プロトコルは、送信可能な最大フレーム・サイズを定義しています。そのような場合、ルーターは、Link Layer プロトコルで許可されているものより大きなフレームの送信を許可するような MTU の設定を許してはなりません (MUST NOT)。ただし、ルーターは、MTU より大きい場合でも、最大フレーム・サイズと同じ大きさのパケットを受信する用意があってしかるべきです (SHOULD)。

DISCUSSION これは、各物理インタフェースの MTU を設定可能にすることを要求する [INTRO:2] がホストに課す要件よりも厳しい要件であることに注意してください。

ネットワークが Link Layer の最大フレーム・サイズより小さい MTU を使用している場合、ルーターは、誤って設定された、または不完全に初期化されたホストから、MTU より大きなパケットを受信する可能性があります。Robustness Principle は、ルーターが可能であればこれらのパケットを正常に受信すべきであることを示しています。

3.3.5 Point-to-Point Protocol - PPP

[INTRO:1] とは対照的に、インターネットには標準的なポイントツーポイント回線プロトコルが存在します。それは、[LINK:2]、[LINK:3]、[LINK:4]、および [LINK:5] で定義されている Point-to-Point Protocol (PPP) です。

ポイントツーポイント・インタフェースとは、ポイントツーポイント回線上でデータを送信するように設計された任意のインタフェースです。そのようなインタフェースには、電話回線、リースド回線、専用または直接回線（2 線または 4 線）、および ISDN などの多重化インタフェースのポイントツーポイント・チャネルまたは仮想回線が含まれます。それらは通常、同期または非同期クロッキングを使用する標準化されたモデムまたはビット直列インタフェース（RS-232、RS-449、V.35 など）を使用します。多重化インタフェースには、多くの場合特殊な物理インタフェースがあります。

汎用シリアル・インタフェースは、ポイントツーポイント回線と同じ物理メディアを使用しますが、ポイントツーポイント接続だけでなく、リンク層ネットワークの使用もサポートします。リンク層ネットワーク（X.25 や Frame Relay など）は、別の IP リンク層仕様を使用します。

ポイントツーポイントまたは汎用シリアル・インタフェースを実装するルーターは、PPP を実装しなければなりません (MUST)。

すべての汎用シリアル・インタフェースで PPP をサポートしなければならない (MUST)。ルーターは、ポイントツーポイント回線上のインタフェースでない回線を、PPP 以外のポイントツーポイント回線プロトコルを使用するように設定できるようにしてもよい (MAY)。ポイントツーポイント・インタフェースは、有効化時にデフォルトで PPP を使用するか、有効化する前にリンク層プロトコルを設定することを要求するかのいずれかであるべきです (SHOULD)。汎用シリアル・インタフェースは、有効化する前にリンク層プロトコルを設定することを要求すべきです (SHOULD)。

3.3.5.1 導入

このセクションは、同期リンクおよび非同期リンクのいずれにおいても PPP を使用する他のルーターとの相互運用性を確保できるように、ルーター実装者にガイドラインを提供します。

オプション交渉メカニズムのセマンティクスを実装者が理解することは極めて重要です。オプションとは、ローカル装置がリモート・ピアに対して、リモート・ピアから何を受け入れるかを指示する手段であって、何を送信したいかではありません。リモート・ピアが、ローカル装置が受け入れ可能と述べたオプションの集合の範囲内で、送信するのに最も都合の良いものを決定します。したがって、リモート・ピアが、たとえリモート・ピアがそれらのオプションのいずれもサポートしていなくても、LCP Configuration Request (CR) で示されたすべてのオプションを ACK することは、完全に許容されかつ通常のことです。繰り返しますが、オプションは単に、各装置がピアに対して何を受け入れるか（必ずしも何を送信するかではない）を示すメカニズムにすぎません。

3.3.5.2 Link Control Protocol (LCP) オプション

PPP Link Control Protocol (LCP) は、交渉可能ないくつかのオプションを提供します。これらのオプションには、（その他の中でも）アドレスおよび制御フィールド圧縮、プロトコル・フィールド圧縮、非同期文字マップ、Maximum Receive Unit (MRU)、Link Quality Monitoring (LQM)、マジック・ナンバー（ループバック検出用）、Password Authentication Protocol (PAP)、Challenge Handshake Authentication Protocol (CHAP)、および 32 ビット Frame Check Sequence (FCS) が含まれます。

ルーターは、同期リンクおよび非同期リンクのいずれにおいても、アドレス/制御フィールド圧縮を使用してもよい (MAY)。ルーターは、同期リンクおよび非同期リンクのいずれにおいても、プロトコル・フィールド圧縮を使用してもよい (MAY)。これらの圧縮を受け入れられると示したルーターは、非圧縮の PPP ヘッダ情報も受け入れられる必要があります (MUST)。

DISCUSSION これらのオプションは PPP ヘッダの外観を制御します。通常、PPP ヘッダはアドレス、制御フィールド、およびプロトコル・フィールドから構成されます。アドレスはポイントツーポイント回線上では 0xFF であり、「ブロードキャスト」を示します。制御フィールドは 0x03 であり、「Unnumbered Information」を示します。プロトコル識別子は、フレームのデータ領域の内容を示す 2 バイト値です。システムがアドレスおよび制御フィールド圧縮を交渉すると、それはピアに対して、ヘッダの先頭にこれらのフィールドがあってもなくてもよい PPP フレームを受け入れることを示します。それは、これらのフィールドを削除してフレームを送信することを示すものではありません。

プロトコル・フィールド圧縮は、交渉されたとき、システムが合法である場合にプロトコル・フィールドを 1 バイトに圧縮して受信する用意があることを示します。送信側がそうする要件はありません。

アドレス/制御フィールド圧縮の使用は、番号付きモード（信頼性のある）PPP の使用と矛盾します。

IMPLEMENTATION 一部のハードウェアは可変長ヘッダ情報をうまく処理しません。そのような場合、リモート・ピアが完全な PPP ヘッダを送信するのが最も理にかなっています。実装は、リモート・ピアにアドレス/制御フィールドおよびプロトコル・フィールド圧縮オプションを送信しないことでこれを確保できます。リモート・ピアが圧縮ヘッダの受信能力を示していても、ローカル・ルーターが圧縮ヘッダを送信する要件はありません。

ルーターは、非同期 PPP リンクに対しては Asynchronous Control Character Map (ACCM) を交渉しなければなりません (MUST) が、同期リンクに対しては ACCM を交渉すべきではありません (SHOULD NOT)。ルーターが同期リンク上で ACCM の交渉を受けた場合、オプションを ACKnowledge し、その後それを無視しなければなりません (MUST)。

DISCUSSION 同期モードと非同期モードの両方を提供し、同じコードを使用してオプション交渉を実装する実装が存在します。この状況では、一方の端または他方が同期リンク上で ACCM オプションを送信する可能性があります。

ルーターは、maximum receive unit (MRU) を適切に交渉すべきです (SHOULD)。システムが 1,500 バイト未満の MRU を交渉したとしても、1,500 バイトのフレームを受信できる必要があります (MUST)。

ルーターは、link quality monitoring (LQM) オプションを交渉および有効化すべきです (SHOULD)。

DISCUSSION このメモは、リンクの品質が十分であるかどうかを決定するポリシーを規定していません。しかし、（セクション [3.3.6] 参照）、ルーターが失敗したリンクを無効にすることは重要です。

ルーターは、ループバック検出のための magic number オプションを実装および交渉すべきです (SHOULD)。

ルーターは、認証オプション（PAP - Password Authentication Protocol、および/または CHAP - Challenge Handshake Authentication Protocol）をサポートしてもよい (MAY)。

ルーターは 16 ビット CRC frame check sequence (FCS) をサポートしなければならず (MUST)、32 ビット CRC をサポートしてもよい (MAY)。

3.3.5.3 IP Control Protocol (IPCP) オプション

ルーターは、IP アドレス交渉の実行を提案してもよい (MAY)。ルーターは、ピアからの IP アドレス交渉実行の拒否 (REJect) を受け入れなければなりません (MUST)。

19,200 BPS 以下のリンク速度で動作するルーターは、Van Jacobson ヘッダ圧縮を実装し、実行を提案すべきです (SHOULD)。VJ 圧縮を実装するルーターは、それを有効化または無効化する管理制御を実装すべきです (SHOULD)。

3.3.6 Interface Testing (インタフェース試験)

ルーターは、物理インタフェースがパケット送信に利用可能かどうかをルーティング・ソフトウェアが判断できるようにするメカニズムを持たなければなりません (MUST)。限定された近隣集合に対して永続仮想回線が開かれる多重化インタフェースでは、ルーターは仮想回線が使用可能かどうかも判断できる必要があります。ルーターは、物理インタフェースの品質をルーティング・ソフトウェアが判断できるようにするメカニズムを持つべきです (SHOULD)。ルーターは、管理アクションによりパケット送信に利用可能または利用不可となったときに、ルーティング・ソフトウェアに通知するメカニズムを持たなければなりません (MUST)。ルーターは、何らかの理由でリンク層インタフェースが利用可能または利用不可となったことを検出したときに、ルーティング・ソフトウェアに通知するメカニズムを持たなければなりません (MUST)。

DISCUSSION ルーターがネットワーク接続が適切に機能しているかどうかを判断する実用的なメカニズムを持つことは極めて重要です。リンク喪失の検出に失敗する、あるいは問題が検出されたときに適切なアクションをとることに失敗すると、ブラックホールにつながる可能性があります。

ネットワーク接続の問題を検出するために利用可能なメカニズムは、使用されるリンク層プロトコルとインタフェース・ハードウェアによって大きく異なります。意図は、リンク層の制約内で障害を検出する能力を最大化することです。

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] で定義）、および Classless Inter-Domain Routing（CIDR、[INTERNET:15] で定義）を実装しなければなりません (MUST)。

ルーター実装者は、[INTRO:2] の "Internet Protocol -- IP" という節への準拠を考慮する必要はありません。その節はこの文書で完全に重複または置き換えられているためです。ルーターは、[INTRO:2] の IP に関する "SPECIFIC ISSUES" という節の要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。

以下では、特定の場合の指定されるアクションは、受信データグラムを暗黙的に廃棄 (silently discard) することです。これは、データグラムがそれ以上処理されることなく廃棄され、ルーターがそれに起因して ICMP エラー・メッセージ（セクション [4.3] 参照）を送信しないことを意味します。しかし、問題の診断のために、ルーターは暗黙的に廃棄されたデータグラムの内容を含むエラーをログに記録する機能（セクション [1.3.3] 参照）を提供すべきであり (SHOULD)、廃棄されたデータグラムをカウントすべきです (SHOULD)。

4.2.2 Protocol Walk-Through (プロトコル通覧)

RFC 791 [INTERNET:1] は Internet Protocol の仕様です。

4.2.2.1 Options: RFC 791 Section 3.2

ルーター自身が受信したデータグラム内では、IP 層は理解できる IP オプションを解釈し、残りを上位層プロトコルが使用するために変更せずに保持しなければなりません (MUST)。

上位層プロトコルは、送信するデータグラムに IP オプションを設定したり、受信するデータグラムの IP オプションを検査したりする能力を必要とする場合があります。この文書の後の節では、上位層プロトコルに要求される特定の IP オプション・サポートについて論じます。

DISCUSSION このメモも [INTRO:2] も、受信側が同じ IP ヘッダ内の複数オプションをどの順序で処理しなければならないかを定義していません。複数のオプションを含むデータグラムを発信するホストおよびルーターは、これがソースルート・オプションと組み合わされた場合に、特定のオプションの意味に曖昧さをもたらすことを認識していなければなりません。

特定の IP オプションの要件は次のとおりです:

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

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

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

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

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

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

一般的な場合、ソースルート付きデータグラムに対する正しい応答は同じルートを通ります。ルーターは、トランスポート・プロトコルおよびアプリケーションが、受信したデータグラム内のソースルートを逆転できる手段を提供しなければなりません (MUST)。この逆転されたソースルートは、ルーターがポリシー制約を認識していない場合、ルーターが発信するデータグラムに挿入されなければなりません (MUST)（詳細は [INTRO:2] 参照）。ただし、ルーターがポリシーを認識している場合、別のパスを選択してもよい (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 >>} となります。すなわち、発信ホストがルートの第 1 ホップとなります。

(d) Record Route Option（レコードルート・オプション）

ルーターは、ルーターが発信するデータグラム内の Record Route オプションをサポートしてもよい (MAY)。

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

ルーターは、ルーターが発信するデータグラム内のタイムスタンプ・オプションをサポートしてもよい (MAY)。次の規則が適用されます:

タイムスタンプ・オプションを含むデータグラムを発信するとき、ルーターは次の場合にオプションにタイムスタンプを記録しなければなりません (MUST):
- そのインターネット・アドレス・フィールドが事前指定されていない、または
- その最初の事前指定アドレスが、データグラムが送信されている論理インタフェースの IP アドレス（または、番号なしインタフェースを介してデータグラムが送信されている場合はルーターの router-id）である。
ルーター自身がタイムスタンプ・オプションを含むデータグラムを受信した場合、ルーターはオプションをトランスポート層または ICMP に処理のために渡す前に（オプション内に空きがあれば）現在の時刻をタイムスタンプ・オプションに挿入しなければなりません (MUST)。空きがない場合、ルーターはオプション内の Overflow Count をインクリメントしなければなりません (MUST)。
タイムスタンプ値は、[INTRO:2] で定義された規則に従わなければなりません (MUST)。

IMPLEMENTATION タイムスタンプ・オプションに含まれるタイムスタンプの有用性を最大化するため、挿入されるタイムスタンプは、実用上可能な限り、パケットがルーターに到着した時刻であるべきです。ルーターが発信したデータグラムの場合、挿入されるタイムスタンプは、実用上可能な限り、データグラムが送信のためにリンク層に渡された時刻であるべきです。

タイムスタンプ・オプションは非標準の時計の使用を許可しますが、同期されていない時計の使用はタイムスタンプの有用性を制限します。したがって、ルーターはクロックを同期する目的で Network Time Protocol を実装することが強く推奨されます。

4.2.2.2 Addresses in Options: RFC 791 Section 3.1

ルーターは、Record Route、Strict Source and Record Route、Loose Source and Record Route、または Timestamp オプションに自身のアドレスを挿入するよう求められます。ルーターがそのようなオプションにアドレスを挿入するとき、ルーターはパケットが送信されている論理インタフェースの IP アドレスを使用しなければならず (MUST)、この規則に従えない場合（出力インタフェースが IP アドレスを持たない、すなわち番号なしインタフェースであるため）は、代わりに router-id を挿入しなければなりません (MUST)。ルーターの router-id はルーターの IP アドレスの 1 つです。Router ID はシステム単位またはリンク単位で指定される場合があります。ルーターのアドレスのうちどれが 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 ヘッダには 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)。他のフラグメントよりも著しく小さい 1 つの IP フラグメントを生成する可能性のあるフラグメンテーション方式は、最初の IP フラグメントをより小さいものにしてもよい (MAY) です。

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

一部の TCP/IP 実装で使用される一般的な手法は、IP データグラムがルーターを通過するときに、576 バイトを超えない IP フラグメントに IP データグラムをフラグメント化するものです。これは、結果の IP フラグメントがそれ以上のフラグメンテーションなしにパスの残りを通過できるようにすることを意図しています。ただし、これは宛先ホストへの負荷を増大させます。なぜなら、1 つの IP データグラムに再構成するための IP フラグメントの数が多くなるからです。また、MTU が 1 回だけ変化し、576 バイトよりはるかに大きいままであるネットワークでは効率的ではありません。例として、MTU が 2048 の IEEE 802.5 ネットワークや、MTU が 1500 の Ethernet ネットワークがあります。

議論されたもう 1 つのフラグメンテーション手法は、IP データグラムを、ネクストホップ・ネットワークの MTU 以下のほぼ等しいサイズの IP フラグメントに分割するものです。これは、パスのさらに下流での追加のフラグメンテーションから生じるフラグメント数を最小化し、各フラグメントの等しい遅延を保証することを意図しています。

ルーターは、可能な限り最小数の 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 倍を超えるべきであるとしています。現在の推奨値は通常 Assigned Numbers RFC に掲載されています。TTL フィールドには 2 つの機能があります: TCP セグメントの寿命を制限すること（RFC 793 [TCP:1] p. 28 参照）、およびインターネットのルーティング・ループを終端させることです。TTL は秒単位の時間ですが、各ルーターは TTL フィールドを少なくとも 1 減らすことが要求されるため、ホップ・カウントのいくつかの属性も持ちます。

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

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

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

4.2.2.10 Multi-subnet Broadcasts: RFC 922

all-subnets ブロードキャスト（[INTERNET:3] では multi-subnet broadcasts と呼ばれる）は廃止されました。セクション [5.3.5.3] を参照してください。

4.2.2.11 Addressing: RFC 791 Section 3.2

2.2.5.1 で述べたように、現在 5 つのクラスの IP アドレス、すなわち Class A から Class E があります。Class D アドレスは IP マルチキャスト [INTERNET:4] に使用され、Class E アドレスは実験用に予約されています。Class 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)。

ローカル配送のために受信された（セクション [5.2.3] 参照）、送信元アドレスが { 0, 0 } である入力データグラムは、ルーターが関連プロトコルを実装しており、そのプロトコルが実行すべき適切なアクションを明確に定義している場合、受け入れられなければなりません (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, }

このネットワーク上の指定ホスト。これはルーターによって送信されてはならない (MUST NOT) が、ルーターが自身の IP アドレスを学習する初期化手順の一部として、この送信元アドレスを使用してもよい (MAY)。

限定ブロードキャスト。これは送信元アドレスとして使用されてはなりません (MUST NOT)。

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

(d) { , -1 }

Directed Broadcast - 指定されたネットワーク・プレフィックスへのブロードキャスト。これは送信元アドレスとして使用されてはなりません (MUST NOT)。ルーターは Network Directed Broadcast パケットを発信してもよく (MAY)、Network Directed Broadcast パケットを受信しなければなります (MUST)。ただし、ルーターはこれらのパケットの受信を防止する設定オプションを持っていてもよい (MAY) です。そのようなオプションは、受信を許可することをデフォルトとしなければなりません (MUST)。

(e) { 127, }

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

は、デバイスが接続されているルーティング・ドメイン内で一意となるように管理上割り当てられます。

IP アドレスは、上記の特殊ケースを除き、またはフィールドの値として 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 アドレスを意味します。specific-destination アドレスは、IP ヘッダがブロードキャストまたはマルチキャスト・アドレスを含まない限り、IP ヘッダ内の宛先アドレスとして定義され、その場合、specific-destination はデータグラムが到着した物理インタフェースに割り当てられた IP アドレスです。

ルーターは、この節の規則によって無効な IP 送信元アドレスを含む受信データグラムを暗黙的に廃棄しなければなりません (MUST)。この検証は、IP 層によって、または（適切な場合）トランスポート層の各プロトコルによって実行できます。ルーターが廃棄する任意のデータグラムと同様に、データグラムの廃棄はカウントされるべきです (SHOULD)。

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

4.2.3 SPECIFIC ISSUES

4.2.3.1 IP Broadcast Addresses

歴史的な理由から、IP パケットが IP ブロードキャストであることを示すために使用される多数の IP アドレス（標準的なものといくつかの非標準なもの）が存在します。ルーターは:

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

(2) 0.0.0.0 または { , 0 } に宛てられた任意のパケットを、受信時に暗黙的に廃棄（すなわち、ルーター内のアプリケーションにも配送しない）すべきです (SHOULD)。これらのパケットが暗黙的に廃棄されない場合、IP ブロードキャストとして扱われなければなりません (MUST)（セクション [5.3.5] 参照）。これらのパケットの受信を許可する設定オプションがあってもよい (MAY) です。このオプションは、それらを廃棄することをデフォルトとするべきです (SHOULD)。

(3) 接続された（サブ）ネットワーク宛の IP ブロードキャストを発信するとき、（セクション [4.3.3.9] で論じる ICMP Address Mask Reply の送信時を除き）限定ブロードキャスト・アドレス (255.255.255.255) を（デフォルトで）使用すべきです (SHOULD)。ルーターは限定ブロードキャストを受信しなければなりません (MUST)。

(4) 0.0.0.0 または { , 0 } に宛てられたデータグラムを発信すべきではありません (SHOULD NOT)。これらのパケット（関連する 1 の形式のブロードキャストを使用する代わりに）の生成を許可する設定オプションがあってもよい (MAY) です。このオプションは、それらを生成しないことをデフォルトとするべきです (SHOULD)。

DISCUSSION 第 2 の箇条書きにおいて、ルーターがそのネットワーク・プレフィックスへのインタフェースを持たない場合、ルーターは { , 0 } の形式のアドレスを認識できません。その場合、ルーターから見てパケットは IP ブロードキャスト・パケットではないため、第 2 の箇条書きの規則は適用されません。

4.2.3.2 IP Multicasting

IP ルーターは、[INTRO:2] で指定されている IP マルチキャストに関する Host Requirements を満たすべきです (SHOULD)。IP ルーターは、接続されたすべてのネットワーク上でローカル IP マルチキャストをサポートすべきです (SHOULD)。IP マルチキャスト・アドレスからリンク層アドレスへのマッピングが指定されている場合（各種 IP-over-xxx 仕様を参照）、それを使用すべきです (SHOULD)。また、代わりにリンク層ブロードキャストを使用するように設定可能であってもよい (MAY) です。ポイントツーポイント・リンクおよびその他すべてのインタフェースでは、マルチキャストはリンク層ブロードキャストとしてカプセル化されます。ローカル IP マルチキャストのサポートには、マルチキャスト・データグラムの発信、マルチキャスト・グループへの参加および受信、およびマルチキャスト・グループからの離脱が含まれます。これは、IGMP を含む [INTERNET:4] 全体（セクション [4.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

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

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

4.2.3.4 Subnetting

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

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

IMPLEMENTATION 古典的な IP ネットワークでは、これを達成するのは非常に困難でした。CIDR ネットワークでは、これは自然な副産物です。したがって、ルーターはサブネット・アーキテクチャについて仮定すべきではなく (SHOULD NOT)、各ルートを一般化されたネットワーク・プレフィックスとして扱うべきです (SHOULD)。

DISCUSSION 近年、インターネットは驚異的な速度で成長しています。これは IP アドレッシング技術に深刻な負荷をかけています。この負荷の主な要因は、厳格な IP アドレスのクラス境界です。これらは、ネットワーク・プレフィックスをそのネットワークに効率的にサイズ設定し、複数のネットワーク・プレフィックスを単一のルート広告に集約することを困難にします。厳格なクラス境界を排除し、各ルートを一般化されたネットワーク・プレフィックスとして扱うことで、これらの負荷を大幅に軽減できます。

現在これを行うための技術は Classless Inter Domain Routing (CIDR) [INTERNET:15] です。

同様の理由から、特定のネットワーク・プレフィックスに関連付けられたアドレス・ブロックは、異なるサイズのサブブロックに細分割され、サブブロックに関連付けられたネットワーク・プレフィックスの長さが異なる可能性があります。たとえば、ネットワーク・プレフィックスが 8 ビット長のブロック内で、1 つのサブブロックは 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)、または（ルーターが持たない場合）暗黙的に廃棄されなければなりません (MUST)。

4.3.2.2 ICMP Message TTL

ICMP メッセージを発信するとき、ルーターは TTL を初期化しなければなりません (MUST)。ICMP 応答の TTL は、応答を引き起こしたパケットから取得してはなりません。

4.3.2.3 Original Message Header

歴史的に、すべての ICMP エラー・メッセージには、エラーを引き起こしたデータグラムのインターネット・ヘッダおよび少なくとも最初の 8 データバイトが含まれてきました。IP-in-IP トンネリングおよびその他の技術の使用により、これはもはや不十分です。したがって、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 メッセージ内の IP 送信元アドレスは、ICMP メッセージが送信される物理インタフェースに関連付けられた IP アドレスの 1 つでなければなりません (MUST)。インタフェースに関連付けられた IP アドレスがない場合、代わりにルーターの router-id（セクション [5.2.5] 参照）が使用されます。

4.3.2.5 TOS and Precedence

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

ICMP Source Quench エラー・メッセージは、送信する場合、IP Precedence フィールドを、ICMP Source Quench メッセージの送信を引き起こしたパケットの IP Precedence フィールドと同じ値に設定しなければなりません (MUST)。その他すべての ICMP エラー・メッセージ（Destination Unreachable、Redirect、Time Exceeded、および Parameter Problem）は、precedence 値を 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 U.S. Department of Defense セキュリティ・オプション（[INTERNET:5] で定義）を使用する環境では、ICMP メッセージにセキュリティ・オプションを含める必要がある場合があります。このトピックの詳細情報は Defense Communications Agency から入手できるはずです。

4.3.2.7 When Not to Send ICMP Errors

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

ICMP エラー・メッセージ、または
セクション [5.2.2] で説明された IP ヘッダ検証テストに失敗したパケット（その節が ICMP エラー・メッセージの送信を具体的に許可する場合を除く）、または
IP ブロードキャストまたは IP マルチキャスト・アドレスに宛てられたパケット、または
リンク層ブロードキャストまたはマルチキャストとして送信されたパケット、または
ネットワーク・プレフィックスがゼロである、または無効な送信元アドレス（セクション [5.3.7] で定義）を持つパケット、または
最初のフラグメント以外のデータグラムのフラグメント（すなわち、IP ヘッダ内のフラグメント・オフセットが非ゼロであるパケット）。

さらに、このメモがパケットを暗黙的に廃棄すると規定しているいかなる場合にも、ICMP エラー・メッセージを送信してはなりません (MUST NOT)。

NOTE: これらの制限は、ICMP エラー・メッセージの送信に関するこの文書の他の箇所のいかなる要件よりも優先されます。

DISCUSSION これらの規則は、ブロードキャスト・パケットに応答してルーターやホストが ICMP エラー・メッセージを返すことから生じたブロードキャスト・ストームを防ぐことを目的としています。たとえば、存在しないポートへのブロードキャスト UDP パケットは、その宛先ポートのクライアントを持たないすべての装置からの ICMP Destination Unreachable データグラムの洪水を引き起こす可能性があります。大きな Ethernet では、結果の衝突によってネットワークが 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 Reply などの他の種類のメッセージを生成する頻度を制限する場合があります。

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

(1) カウントベース - たとえば、全体または特定の送信元ホストごとに、廃棄された N パケットごとに 1 つの ICMP エラー・メッセージを送信する。このメカニズムは、使用する場合は ICMP Source Quench に適している可能性がありますが、おそらく他のタイプの ICMP メッセージには適していません。 (2) タイマーベース - たとえば、特定の送信元ホストまたは全体に対して、最大でも T ミリ秒に 1 回 ICMP エラー・メッセージを送信する。 (3) 帯域幅ベース - たとえば、特定のインタフェースを介して送信される ICMP メッセージのレートを、接続されたネットワークの帯域幅の一定割合に制限する。

4.3.3 SPECIFIC ISSUES

4.3.3.1 Destination Unreachable

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

パケットがルーターに直接接続されたネットワーク上のホストに転送されるべきであり（すなわちルーターがラストホップ・ルーター）、ルーターが宛先ホストへのパスがないと確認した場合、ルーターは Destination Unreachable、Code 1（Host Unreachable）ICMP メッセージを生成しなければなりません (MUST)。パケットがルーターに直接接続されたネットワーク上のホストに転送されるべきであり、ルーターが、要求された TOS に等しいかデフォルト TOS（0000）であるルートがないためにパケットを転送できない場合、ルーターは Destination Unreachable、Code 12（Host Unreachable for TOS）ICMP メッセージを生成しなければなりません (MUST)。

DISCUSSION 意図は、ルーターが宛先へのパスを一切持たない（デフォルト・ルートを含む）場合、ルーターは「汎用の」ホスト/ネットワーク到達不能を生成することです。ルーターが宛先への 1 つ以上のパスを持っているが、それらのパスのいずれも許容される TOS を持たない場合、ルーターは「TOS に対して到達不能」メッセージを生成します。

4.3.3.2 Redirect

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

[INTRO:2] とは逆に、ルーターがルーティング・プロトコルを実行している場合、またはルーターおよびパケットが送信されるインタフェースで転送が有効になっている場合、ルーターはルーターが発信するパケットのパス選択において ICMP Redirect を無視してもよい (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 ストリームである可能性があります。IP 層がパケットの送信レートを制御することによって Source Quench に直接応答するメカニズムが提案されています ([INTERNET:11]、[INTERNET:12]) が、この提案は現在実験的であり、現在は推奨されていません。

4.3.3.4 Time Exceeded

ルーターがパケットを転送中にパケットの TTL フィールドが 0 に減少した場合、セクション [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] はこの要件の例外を定義しています。

[INTRO:2] で Parameter Problem メッセージの新しい亜種が定義されました:

Code 1 = 必須オプションが欠落している。

DISCUSSION この亜種は、軍事コミュニティで欠落したセキュリティ・オプションに対して現在使用されています。

4.3.3.6 Echo Request/Reply

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

Echo サーバ機能は、IP ブロードキャストまたは IP マルチキャスト・アドレスに宛てられた ICMP echo 要求に応答しないことを選択してもよい (MAY) です。

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

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

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

ICMP Echo Reply 内の IP 送信元アドレスは、対応する ICMP Echo Request メッセージの specific-destination アドレスと同じでなければなります (MUST)。

ICMP Echo Request で受信されたデータは、結果の Echo Reply に完全に含まれなければなります (MUST)。

ICMP Echo Request で Record Route および/または Timestamp オプションを受信した場合、この（これらの）オプションは現在のルーターを含むように更新され、切り詰められることなく Echo Reply メッセージの IP ヘッダに含められるべきです (SHOULD)。したがって、記録されたルートは往復全体のものとなります。

ICMP Echo Request で Source Route オプションを受信した場合、メッセージの配送を妨げるポリシーをルーターが認識していない限り、リターン・ルートを逆転させ、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 メッセージの specific-destination アドレスと同じでなければなります (MUST)。
ICMP Timestamp Request で Source Route オプションを受信した場合、ルーターがメッセージの配送を妨げるポリシーを認識していない限り、リターン・ルートを逆転させ、Timestamp Reply メッセージの Source Route オプションとして使用しなければなります (MUST)。
Timestamp Request で Record Route および/または Timestamp オプションを受信した場合、この（これらの）オプションは現在のルーターを含むように更新され、Timestamp Reply メッセージの IP ヘッダに含められるべきです (SHOULD)。
ルーターが Timestamp Request メッセージを送信するためのアプリケーション層インタフェースを提供する場合、着信する Timestamp Reply メッセージは ICMP ユーザ・インタフェースに渡されなければなります (MUST)。

タイムスタンプ値の推奨形式（標準値）は、午前 0 時からの Universal Time でのミリ秒です。しかし、ミリ秒の分解能でこの値を提供するのは困難な場合があります。たとえば、多くのシステムは、回線周波数（1 秒あたり 50 または 60 回）でのみ更新されるクロックを使用します。したがって、標準値にはある程度の余地が許容されます:

(a) 標準値は 1 秒あたり少なくとも 16 回更新されなければなりません (MUST)（すなわち、値の下位 6 ビットのみが未定義であり得ます）。 (b) 標準値の精度は、オペレータが設定した CPU クロックの精度、すなわち数分以内の正確さに近似しなければなります (MUST)。

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

4.3.3.9 Address Mask Request/Reply

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

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

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

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

ホストがブート時にルーターがダウンしている場合、アドレス・マスクを学習できない可能性があるため、ルーターは自身のアドレス・マスクを設定した後、各論理インタフェースで無償 (gratuitous) な ICMP Address Mask Reply をブロードキャストしてもよい (MAY) です。しかし、この機能は可変長アドレス・マスクを使用する環境では危険です。したがって、この機能が実装される場合、無償な Address Mask Reply は、次のいずれかの論理インタフェース上でブロードキャストされてはなりません (MUST NOT):

無償な Address Mask Reply の送信が設定されていないインタフェース。各論理インタフェースはこれを制御する設定パラメータを持たなければならず (MUST)、そのパラメータは無償な Address Mask Reply を送信しないことをデフォルトとしなければなりません (MUST)。
包摂（しかし同一ではない）ネットワーク・プレフィックスおよび物理インタフェースを共有するインタフェース。

IP ブロードキャスト・アドレスの { , -1 } 形式は、ブロードキャスト Address Mask Reply に使用されなければなります (MUST)。

DISCUSSION ルーターによる Address Mask Reply の送信を無効にする能力は、意図的にホストに対してアドレス・マスクについて嘘をつく一部のサイトで要求されます。この必要性は、Host Requirements 標準に準拠するホストが増えるにつれてなくなると予想されます。

上記の第 2 の箇条書きおよびどの IP ブロードキャスト・アドレスを使用するかに関する要件の理由は、同一の物理ネットワーク上で複数の IP ネットワーク・プレフィックスが使用されている場合の問題を防ぐためです。

4.3.3.10 Router Advertisement and Solicitations

IP ルーターは、ルーターが IP マルチキャストまたは IP ブロードキャスト・アドレッシングのいずれかをサポートするすべての接続ネットワーク上で、ICMP Router Discovery Protocol [INTERNET:13] のルーター側をサポートしなければなります (MUST)。実装には、ルーター用に指定されたすべての設定変数を指定されたデフォルト値と共に含めなければなりません (MUST)。

DISCUSSION ルーターは ICMP Router Discovery Protocol のホスト側を実装することを要求されませんが、IP 転送が無効（すなわちホストとして動作中）の間の運用に有用である可能性があります。

DISCUSSION ホストが RIP Version 1 をルーター発見プロトコルとして使用するのは非常に一般的であることに注意します。そのようなホストは RIP トラフィックをリッスンし、そのトラフィックから抽出された情報を使用してルーターを発見し、特定の宛先に対するファーストホップ・ルーターとしてどのルーターを使用するかを決定します。この動作は推奨されませんが、依然として一般的であり、実装者はそれを認識すべきです。

4.4 Internet Group Management Protocol - IGMP

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

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

5. Internet Layer - Forwarding (インターネット層 - 転送)

5.1 Introduction (導入)

この節は、パケットの転送プロセスについて説明します。

5.2 Forwarding Walk-Through (転送通覧)

IP には転送機能の個別の仕様はありません。代わりに、転送はインターネット層プロトコルのプロトコル仕様（[INTERNET:1]、[INTERNET:2]、[INTERNET:3]、[INTERNET:8]、[ROUTE:11]）によってカバーされます。

5.2.1 Forwarding Algorithm (転送アルゴリズム)

主要なプロトコル文書のいずれも転送アルゴリズムを詳細に説明していないため、ここに提示します。これは単なる一般的な概略であり、輻輳の処理など、後の節で扱う重要な詳細を省略しています。

実装がセクション [5.2.1.1]、[5.2.1.2]、[5.2.1.3] のアルゴリズムに正確に従うことは要求されません。ルーター・ソフトウェアを書く際の困難の多くは、同一のアルゴリズムの効果を維持しながらルーターがパケットを転送できるレートを最大化することにあります。それを行う方法の詳細は、ルーターのアーキテクチャに大きく依存するため、この文書の範囲外です。代わりに、ステップ間の順序依存性のみを示します:

(1) ルーターは、ヘッダの内容に基づくいかなるアクションを実行する前に、セクション [5.2.2] で説明されるように IP ヘッダを検証しなければなりません (MUST)。これにより、ルーターは他の資源を消費する前に不良パケットを検出して廃棄できます。

(2) 特定の IP オプションの処理では、ルーターが自身の IP アドレスをオプションに挿入することが要求されます。セクション [5.2.4] で述べたように、挿入されるアドレスは、パケットが送信される論理インタフェースのアドレス、またはパケットが番号なしインタフェース上で送信される場合はルーターの router-id でなければなりません (MUST)。したがって、これらのオプションの処理は、出力インタフェースが選択されるまで完了できません。

(3) ルーターは、パケットがルーター自身に配送されるべきかどうかをチェックする前に、TTL をチェックしてデクリメントしてはなりません (MUST NOT)。その理由はセクション [4.2.2.9] に記載されています。

(4) より一般的には、パケットがローカルでルーターに配送される場合、その IP ヘッダはいかなる方法でも変更されてはならない (MUST NOT)（ルーターが IP ヘッダ内の任意の Timestamp オプションにタイムスタンプを挿入することを要求される場合を除く）。したがって、ルーターがパケットがローカルにルーターに配送されるかどうかを判断する前に、取り消す用意のない方法で IP ヘッダを更新することはできません。

5.2.1.1 General (一般)

この節は、一般的な転送アルゴリズムを扱います。このアルゴリズムは、転送されるすべての形式のパケット、すなわちユニキャスト、マルチキャスト、およびブロードキャストに適用されます。

(1) ルーターは、Link Layer から IP パケット（およびセクション [3.1] で説明される追加情報）を受信します。

(2) ルーターは、セクション [5.2.2] で説明されるように IP ヘッダを検証します。IP 再構成は、ステップ (4) でローカル配送のためにキューイングされる IP フラグメント上でのみ行われないことに注意してください。

(3) ルーターは、IP オプションのほとんどの処理を実行します。セクション [5.2.4] で説明されるように、一部の IP オプションはルーティング決定が行われた後に追加の処理を要求します。

(4) ルーターは、IP データグラムがどのように処理を継続すべきかを決定するために、セクション [5.2.3] で説明されるように IP データグラムの宛先 IP アドレスを調べます。3 つの可能性があります:

IP データグラムはルーター宛であり、必要に応じて再構成を行ってローカル配送のためにキューイングされるべきです。
IP データグラムはルーター宛ではなく、転送のためにキューイングされるべきです。
IP データグラムは転送のためにキューイングされるべきですが、（コピーを）ローカル配送のためにキューイングもしなければなりません。

5.2.1.2 Unicast (ユニキャスト)

ローカル配送のケースは [INTRO:2] で十分にカバーされているため、以下は IP データグラムが転送のためにキューイングされたと仮定します。宛先が IP ユニキャスト・アドレスの場合:

(5) 転送側は、通常ルーターのルーティング・テーブル内のパケットの宛先を検索することによって、パケットのネクストホップ IP アドレスを決定します。この手順はセクション [5.2.4] でより詳細に説明されています。この手順はまた、パケットの送信にどのネットワーク・インタフェースを使用するかも決定します。

(6) 転送側は、パケットの転送が許可されていることを検証します。送信元および宛先アドレスは、セクション [5.3.7] およびセクション [5.3.4] で説明されるように有効でなければなりません。ルーターが転送に対する管理上の制約（セクション [5.3.9] で説明されるものなど）をサポートする場合、それらの制約が満たされなければなりません (MUST)。

(7) 転送側は、セクション [5.3.1] で説明されるように、パケットの TTL を（少なくとも 1 つ）デクリメントし、チェックします。

(8) 転送側は、ステップ 3 で完了できなかった IP オプション処理を実行します。

(9) 転送側は、セクション [4.2.2.7] で説明されるように、必要な IP フラグメンテーションを実行します。このステップは送信側インタフェース選択（ステップ 5）の後で発生するため、同じデータグラムのすべてのフラグメントは同じインタフェースから送信されます。

(10) 転送側は、パケットのネクストホップの Link Layer アドレスを決定します。これを行うメカニズムは Link Layer に依存します（第 3 章参照）。

(11) 転送側は、IP データグラム（またはその各フラグメント）を適切な Link Layer フレームにカプセル化し、ステップ 5 で選択されたインタフェースでの出力のためにキューイングします。

(12) 転送側は、必要に応じて、セクション [4.3.3.2] で説明されるように ICMP リダイレクトを送信します。

5.2.1.3 Multicast (マルチキャスト)

宛先が IP マルチキャストの場合、次のステップが実行されます。

IP ユニキャストの転送と IP マルチキャストの転送の主な違いは、次のとおりです:

IP マルチキャストは通常、データグラムの送信元および宛先 IP アドレスの両方に基づいて転送される。
IP マルチキャストは expanding ring search（拡大リング検索）を使用する。
IP マルチキャストは Link Level マルチキャストとして転送される。
ICMP エラーは IP マルチキャスト・データグラムへの応答として決して送信されない。

IP マルチキャストの転送は依然としてやや実験的であることに注意してください。その結果、以下に提示するアルゴリズムは必須ではなく、単なる例として提供されています。

(5a) データグラム・ヘッダ内の IP 送信元および宛先アドレスに基づいて、ルーターはデータグラムが転送のために適切なインタフェースで受信されたかどうかを決定します。そうでない場合、データグラムは暗黙的に廃棄されます。適切な受信インタフェースを決定する方法は、使用中のマルチキャスト・ルーティング・アルゴリズムに依存します。最も単純なアルゴリズムの 1 つである reverse path forwarding (RPF) では、適切なインタフェースはユニキャストをデータグラム送信元へ転送するために使用されるインタフェースです。

(6a) データグラム・ヘッダ内の IP 送信元および宛先アドレスに基づいて、ルーターはデータグラムの送信インタフェースを決定します。IP マルチキャストの expanding ring search（[INTERNET:4] 参照）を実装するため、各送信インタフェースに最小 TTL 値が指定されます。最小 TTL 値がデータグラム・ヘッダ内の TTL 値以下である各送信インタフェースから、マルチキャスト・データグラムのコピーが転送され、各そのようなインタフェース上で残りのステップを個別に適用することによって転送されます。

(7a) ルーターはパケットの TTL を 1 デクリメントします。

(8a) 転送側は、ステップ (3) で完了できなかった IP オプション処理を実行します。

(9a) 転送側は、セクション [4.2.2.7] で説明されるように、必要な IP フラグメンテーションを実行します。

(10a) 転送側は、Link Level カプセル化で使用する Link Layer アドレスを決定します。これを行うメカニズムは Link Layer に依存します。LAN 上では、データグラムの IP マルチキャスト・アドレスのアルゴリズム的な変換として、Link Level マルチキャストまたはブロードキャストが選択されます。詳細は各種 IP-over-xxx 仕様を参照してください。

(11a) 転送側は、パケット（またはその各フラグメント）を適切な Link Layer フレームにカプセル化し、適切なインタフェースでの出力のためにキューイングします。

5.2.2 IP Header Validation (IP ヘッダ検証)

ルーターが IP パケットを処理する前に、ヘッダが意味をなすことを確認するために、パケットの IP ヘッダに対して次の基本的な妥当性チェックを実行しなければなりません (MUST)。パケットが次のいずれかのテストに失敗した場合、暗黙的に廃棄されなければならず (MUST)、エラーはログに記録されるべきです (SHOULD)。

(1) Link Layer によって報告されたパケット長は、最小長の合法な IP データグラム（20 バイト）を保持するのに十分でなければならない。

(2) IP チェックサムは正しくなければならない。

(3) IP バージョン番号は 4 でなければならない。バージョン番号が 4 でない場合、パケットは IPng や ST-II などの別のバージョンの IP である可能性がある。

(4) IP ヘッダ長フィールドは、最小長の合法な IP データグラム（20 バイト = 5 ワード）を保持するのに十分な大きさでなければならない。

(5) IP 合計長フィールドは、IP ヘッダ長フィールドで長さが指定されている IP データグラム・ヘッダを保持するのに十分な大きさでなければならない。

ルーターは、これらのテストのいずれかを無効にする設定オプションを持ってはなりません (MUST NOT)。

パケットが第 2 および第 3 のテストに合格し、IP ヘッダ長フィールドが少なくとも 4 であり、IP 合計長フィールドと Link Layer によって報告されたパケット長の両方が少なくとも 16 である場合、上記の規則にかかわらず、ルーターは IP ヘッダ長フィールド（第 4 テストに失敗した場合）または IP 合計長フィールド（第 5 テストに失敗した場合）を指すポインタを持つ ICMP Parameter Problem メッセージで応答してもよい (MAY)。ただし、それでもパケットを廃棄しなければならず (MUST)、エラーをログに記録すべきです (SHOULD)。

これらの規則（およびこの文書全体）は、インターネット・プロトコルのバージョン 4 にのみ適用されます。これらの規則は、ルーターが IP の他のバージョンをサポートすることを禁止するものと解釈されるべきではありません (SHOULD NOT)。さらに、ルーターがパケットを何らかの他のバージョンの IP として真に分類できる場合、そのパケットを本メモの文脈でのエラー・パケットとして扱うべきではありません (SHOULD NOT)。

IMPLEMENTATION エラー報告の観点から、ヘッダがなぜ無効であったかを判断することは望ましいですが、常に完全に可能であるとは限りません。考えられる理由は 4 つあります:

Link Layer が IP ヘッダを切り捨てた。
データグラムが標準（バージョン 4）以外のバージョンの IP を使用している。
IP ヘッダが伝送中に破損した。
送信者が不正な IP ヘッダを生成した。

おそらく、リストされた順序でチェックを実行するのが望ましいです。なぜなら、この順序がエラーの原因を正しく分類する可能性が最も高いと考えるためです。エラー報告の目的で、これらのテストに失敗したパケットが IPng または ST-II を示す IP バージョン番号を持つかどうかをチェックすることも望ましい場合があります。これらはそれぞれの仕様に従って処理されるべきです。

さらに、ルーターは、Link Layer によって報告されたパケット長が、パケットの IP ヘッダに記録された IP 合計長以上であることを検証すべきです (SHOULD)。パケットが切り捨てられていると思われる場合、パケットは廃棄されなければならず (MUST)、エラーはログに記録されるべきであり (SHOULD)、ルーターはポインタが IP 合計長フィールドを指す ICMP Parameter Problem メッセージで応答すべきです (SHOULD)。

DISCUSSION データ破損に関心を持つ上位層プロトコルはいずれも、パケットが最終宛先に到達したときにパケット・データの切り捨てを検出するため、プロトコルの正当性を維持するためにルーターが上記のチェックを実行することは絶対に必要というわけではありません。しかし、このチェックを行うことで、ルーターはパス内のどのホップがパケットを切り捨てているかを判断するタスクを大幅に簡素化できます。また、下流システムがパケットを処理する必要がなくなるため、ルーターの下流での資源の消費を削減します。

最後に、IP ヘッダ内の宛先アドレスがルーターのアドレスのいずれでもない場合、ルーターはパケットに Strict Source and Record Route オプションが含まれていないことを検証すべきです (SHOULD)。パケットがこのテストに失敗した場合（strict source route オプションが含まれている場合）、ルーターはエラーをログに記録すべきであり (SHOULD)、ポインタが問題のあるパケットの IP 宛先アドレスを指す ICMP Parameter Problem エラーで応答すべきです (SHOULD)。

DISCUSSION 一部の人々は、ルーターが Bad Source Route メッセージではなく Parameter Problem メッセージで応答すべきであると提案するかもしれません。しかし、パケットがこのテストに失敗した場合、それは通常、直前のホップ・ルーターによるプロトコル・エラーを示します。一方、Bad Source Route は送信元ホストがネットワークを通じて存在しない、または壊れたパスを要求したことを示唆します。

5.2.3 Local Delivery Decision (ローカル配送の決定)

ルーターが IP パケットを受信したとき、パケットがルーターに宛てられているか（ローカルに配送されるべき）、あるいは別のシステムに宛てられているか（転送側によって処理されるべき）を決定しなければなりません (MUST)。特定の IP ブロードキャストおよび IP マルチキャストがローカルに配送されかつ転送されるというハイブリッドのケースもあります。ルーターは、次の規則を使用してこれら 3 つのケースのいずれが適用されるかを決定しなければなりません (MUST)。

期限切れでないソースルート・オプションとは、ポインタ値がソースルート内の最後のエントリを越えていないものです。パケットに期限切れでないソースルート・オプションが含まれている場合、オプション内のポインタは、ポインタがオプション内の最後のアドレスを越えるか、さもなければ次のアドレスがルーター自身のアドレスのいずれでもないようになるまで進められます。後者（通常の）ケースでは、以下の規則にかかわらず、パケットは転送され（ローカルには配送されません）。
パケットは、次の場合にローカルに配送され、転送の対象とはみなされません:
- パケットの宛先アドレスがルーターの IP アドレスのいずれかと完全に一致する、
- パケットの宛先アドレスが限定ブロードキャスト・アドレス（{-1, -1}）である、または
- パケットの宛先が転送されない IP マルチキャスト・アドレス（224.0.0.1 や 224.0.0.2 など）であり、パケットが到着した物理インタフェースに関連付けられた論理インタフェースの（少なくとも）1 つが宛先マルチキャスト・グループのメンバーである。
パケットは、次の場合に転送側に渡され、かつローカルに配送されます:
- パケットの宛先アドレスがルーターの論理インタフェースの少なくとも 1 つをアドレス指定するが、パケットが到着した物理インタフェースに関連付けられたいずれの論理インタフェースもアドレス指定しない IP ブロードキャスト・アドレスである、または
- パケットの宛先が転送を許可されている IP マルチキャスト・アドレス（224.0.0.1 や 224.0.0.2 とは異なる）であり、パケットが到着した物理インタフェースに関連付けられた論理インタフェースの（少なくとも）1 つが宛先マルチキャスト・グループのメンバーである。
パケットは、その宛先アドレスが、パケットが到着した物理インタフェースに関連付けられた論理インタフェースの少なくとも 1 つをアドレス指定する IP ブロードキャスト・アドレス（限定ブロードキャスト・アドレス以外）である場合、ローカルに配送されます。また、パケット到着したリンクがブロードキャストをユニキャストと異なる方法でカプセル化しない（たとえば異なる Link Layer 宛先アドレスを使用することによって）IP カプセル化を使用しない限り、転送側にも渡されます。
パケットは、その他のすべての場合において転送側に渡されます。

DISCUSSION 第 4 の箇条書きの最後の文の要件の目的は、同一の物理ケーブル上の別のネットワーク・プレフィックスへの指定ブロードキャストを扱うためです。通常、これは期待通りに機能します: 送信者はブロードキャストをルーターに Link Layer ユニキャストとして送信します。ルーターはそれがユニキャストとして到着したと認識するため、送信者がそれを送信したネットワーク・プレフィックスとは異なるネットワーク・プレフィックス宛であると推測します。したがって、ルーターはそれを到着したのと同じ（物理）インタフェースから Link Layer ブロードキャストとして安全に送信できます。しかし、ルーターがパケットが Link Layer ユニキャストとして受信されたかどうかを判断できない場合、この文はルーターが安全だが正しくない動作ではなく、安全だが正しい動作を行うことを保証します。

IMPLEMENTATION セクション [5.3.4] で説明されるように、Link Layer ブロードキャストとして受信されたパケットは一般に転送されません。その節の規則によって後に廃棄されるパケットを転送側に渡さないようにすることが有利な場合があります。

一部の Link Layer は（ハードウェアのため、またはドライバ内の特別なコードのためのいずれかで）、ルーターが送信するすべての Link Layer ブロードキャストおよびマルチキャストのコピーをルーターに配送できます。この機能の使用は、パケットを転送側に渡し、かつローカルに配送する必要があるケースの実装を簡素化できます。なぜなら、パケットを転送すると、ルーターがパケットのコピーを受信し、それをローカルに配送できるためです。このような状況では、受信したループバック・パケットを通常受信されたパケットとして扱わないよう（その後、転送などの規則の対象となる）注意する必要があります。

そのような Link Layer がなくても、転送およびローカル配送のためにキューイングするためにパケット全体のコピーを作成する必要はほとんどありませんが、フラグメントには注意が必要です。なぜなら、再構成はローカル配送されたパケットに対して実行されるが、転送されたパケットに対しては実行されないからです。1 つの単純な方式は、ルーターの出力キュー内の各パケットに関連付けられたフラグを持たせ、それが送信された後にローカル配送のためにキューイングされるべきかどうかを示すことです。

5.2.4 Determining the Next Hop Address (ネクストホップ・アドレスの決定)

ルーターがパケットを転送しようとする場合、それを直接宛先に送信できるか、別のルーターを経由する必要があるかを決定しなければなりません。後者の場合、どのルーターを使用するかを決定する必要があります。この節は、これらの決定がどのように行われるかを説明します。

この節は次の定義を使用します:

LSRR - IP Loose Source and Record Route オプション
SSRR - IP Strict Source and Record Route オプション
Source Route Option（ソースルート・オプション） - LSRR または SSRR
Ultimate Destination Address（最終宛先アドレス） - パケットの送信先: ソースルート付きパケットの場合はソースルート内の最後のアドレス、ソースルートなしパケットの場合は IP ヘッダ内の宛先アドレス
Adjacent（隣接） - IP ルーターを経由せずに到達可能
Next Hop Address（ネクストホップ・アドレス） - パケットを次に送信すべき隣接ホストまたはルーターの IP アドレス
IP Destination Address（IP 宛先アドレス） - 最終宛先アドレス。ただしソースルート付きパケットでは、ソースルートで指定された次のアドレス
Immediate Destination（即時宛先） - IP 宛先アドレスによってアドレス指定されるノード、システム、ルーター、エンドシステム、またはその他

5.2.4.1 IP Destination Address (IP 宛先アドレス)

次の場合:

IP ヘッダ内の宛先アドレスがルーターのアドレスのいずれかであり、
パケットに Source Route Option が含まれ、かつ
Source Route Option 内のポインタがオプションの末尾を越えていない

次の IP 宛先アドレスは、そのオプション内のポインタが指すアドレスです。次の場合:

IP ヘッダ内の宛先アドレスがルーターのアドレスのいずれかであり、
パケットに Source Route Option が含まれ、かつ
Source Route Option 内のポインタがオプションの末尾を越えている

メッセージはメッセージを解析しているシステムに宛てられます。

ルーターは、パケットの処理方法を決定するとき、Ultimate Destination Address（ソースルート・オプション内の最後のアドレス）ではなく、IP Destination Address を使用しなければなりません (MUST)。

データグラムに複数のソースルート・オプションが現れるのはエラーです。そのようなデータグラムを受信した場合、パケットを廃棄し、ポインタが 2 つ目のソースルート・オプションの先頭を指す ICMP Parameter Problem メッセージで応答すべきです (SHOULD)。

5.2.4.2 Local/Remote Decision (ローカル/リモートの決定)

IP パケットをセクション [5.2.3] で指定された規則に従って転送する必要があると決定された後、次のアルゴリズムを使用して、Immediate Destination が直接アクセス可能かどうかを決定しなければなりません (MUST)（[INTERNET:2] 参照）。

(1) IP アドレスが割り当てられていない（セクション [2.2.7] で説明される番号なし回線）各ネットワーク・インタフェースについて、回線の反対側の router-id を IP 宛先アドレスと比較します。それらが完全に等しい場合、パケットはこのインタフェースを介して送信できます。

DISCUSSION 言い換えれば、回線の遠端のルーターまたはホストは、パケットの宛先であるか、ソースルート付きパケットのソースルート内の次のステップです。

(2) 最初のステップでネットワーク・インタフェースが選択されなかった場合、ルーターに割り当てられた各 IP アドレスについて:

(a) インタフェースが使用するネットワーク・プレフィックスを分離します。

IMPLEMENTATION この操作の結果は通常、初期化中に計算されて保存されています。

(b) パケットの IP 宛先アドレスから対応するビットの集合を分離します。

(3) 宛先が番号なしインタフェース上の隣接の router-id でも、直接接続されたネットワーク・プレフィックスのメンバーでもない場合、IP 宛先は他のルーターを経由してのみアクセス可能です。ルーターおよびネクストホップ IP アドレスの選択はセクション [5.2.4.3] で説明されます。ルーターではないホストの場合、これは設定されたデフォルト・ルーターである場合があります。

IETF [ARCH:9, NRHP] での進行中の作業は、複数の IP（サブ）ネットワークが同じリンク層ネットワーク上に重ねて配置される場合などの一部のケースを検討しています。ポリシー上の制限がない場合、共通のリンク層ネットワークを使用するホストとルーターは、十分な情報が存在すれば、同じ IP（サブ）ネットワーク内になくても直接通信できます。Next Hop Routing Protocol (NHRP) は、IP エンティティがリモート宛先へ向かうそのようなリンク層ネットワークを通過するために使用する「最適」リンク層アドレスを決定できるようにします。

(4) 選択された「ネクストホップ」が NHRP を使用するように設定されたインタフェースを介して到達可能な場合、次の追加ステップが適用されます:

(a) IP 宛先アドレスを NHRP キャッシュ内の宛先アドレスと比較します。アドレスがキャッシュ内にある場合、データグラムを対応するキャッシュされたリンク層アドレスに送信します。 (b) アドレスがキャッシュ内にない場合、IP 宛先アドレスを含む NHRP 要求パケットを構成します。このメッセージは、そのインタフェース用に設定された NHRP サーバに送信されます。これは、ルーター自身内の論理的に分離されたプロセスまたはエンティティである場合があります。 (c) NHRP サーバは、データグラムおよび同じ宛先への後続のデータグラムを送信するために使用する適切なリンク層アドレスで応答します。システムは、NHRP 応答を待っている間、従来の「ネクストホップ」ルーターにデータグラムを送信してもよい (MAY) です。

5.2.4.3 Next Hop Address (ネクストホップ・アドレス)

EDITORS+COMMENTS ルーターは前節のアルゴリズムを適用して、IP 宛先アドレスが隣接しているかどうかを決定します。隣接している場合、ネクストホップ・アドレスは IP 宛先アドレスと同じです。それ以外の場合、Immediate Destination に到達するためにパケットを別のルーターを経由して転送する必要があります。このルーターの選択がこの節のトピックです。

パケットに SSRR が含まれている場合、ルーターはパケットを廃棄し、ICMP Bad Source Route エラーで応答しなければなりません (MUST)。それ以外の場合、ルーターは適切なネクストホップ・アドレスを決定するために、そのルーティング・テーブル内の IP 宛先アドレスを検索します。

DISCUSSION IP 仕様によれば、Strict Source Route はパケットが通過しなければならない一連のノードを指定しなければなりません。パケットはソースルートの 1 つのノードから次のノードへと、中間ネットワークのみを通過して移動しなければなりません。したがって、ルーターがソースルートの次のステップに隣接していない場合、ソースルートを満たすことはできません。したがって、ルーターはそのようなものを ICMP Bad Source Route エラーで拒否します。

ネクストホップ選択プロセスの目的は、ルーターの Forwarding Information Base (FIB) 内のエントリを調べ、FIB 内で利用可能なものからパケットに最適なルート（存在する場合）を選択することです。

概念的には、ルート検索アルゴリズムはいずれも、FIB の全内容からなる候補ルートの集合で開始します。アルゴリズムは、集合からルートを破棄する一連のステップから構成されます。これらのステップは Pruning Rules（刈り込み規則）と呼ばれます。通常、アルゴリズムが終了したとき、集合には正確に 1 つのルートが残っています。集合が空になった場合、宛先が到達不能であるためパケットは廃棄されます。また、複数のルートが集合に残ったままアルゴリズムが終了する可能性もあります。この場合、ルーターは残りのうち 1 つを除くすべてを任意に廃棄してもよく (MAY)、または最も最近使用されていないルートを選択することによって「負荷分散 (load-splitting)」を実行してもよい (MAY) です。

ルール 3（Weak TOS）を除き、ルーターはパケットのネクストホップを選択するとき、次の Pruning Rules を使用しなければなりません (MUST)。ルーターがネクストホップ決定時に TOS を考慮する場合、ルール 3 は以下に示す順序で適用されなければなりません (MUST)。これらの規則は、提示された順序で FIB に（概念的に）適用されなければなりません (MUST)。（歴史的観点、追加の刈り込み規則、およびその他の一般的なアルゴリズムについては、付録 E を参照してください。）

DISCUSSION ルール 3 は、セクション [5.3.2] がルーターが転送決定時に TOS を考慮すべきである (SHOULD) としているため任意です。

(1) Basic Match（基本一致）この規則は、パケットの IP 宛先アドレス以外の宛先へのルートを破棄します。たとえば、パケットの IP 宛先アドレスが 10.144.2.5 の場合、このステップはネット 128.12.0.0/16 へのルートを破棄しますが、ネットワーク・プレフィックス 10.0.0.0/8 および 10.144.0.0/16 へのルート、および任意のデフォルト・ルートを保持します。

   より正確には、各ルートには route.dest と呼ばれる宛先属性と、route.dest のどのビットが有意であるかを指定する対応するプレフィックス長 route.length があると仮定します。転送されるパケットの IP 宛先アドレスは ip.dest です。この規則は、次の条件を満たすルートを除くすべてのルートを候補の集合から破棄します:

   route.dest および ip.dest の最上位 route.length ビットが等しいルート。

   たとえば、パケットの IP 宛先アドレスが 10.144.2.5 で、ネットワーク・プレフィックス 10.144.1.0/24、10.144.2.0/24、および 10.144.3.0/24 が存在する場合、この規則は 10.144.2.0/24 のみを保持します。それは、パケットの IP 宛先アドレスの対応するビットと同じ値を持つプレフィックスを持つ唯一のルートだからです。

(2) Longest Match（最長一致） Longest Match は、上記で説明した Basic Match の洗練版です。Basic Match 刈り込みを実行した後、アルゴリズムは残りのルートを調べ、最も大きな route.length 値を持つものを決定します。それら以外はすべて破棄されます。

   たとえば、パケットの IP 宛先アドレスが 10.144.2.5 で、ネットワーク・プレフィックス 10.144.2.0/24、10.144.0.0/16、および 10.0.0.0/8 が存在する場合、この規則は最初のもの（10.144.2.0/24）のみを保持します。なぜなら、そのプレフィックス長が最長だからです。

(3) Weak TOS 各ルートには route.tos と呼ばれる type of service 属性があり、その可能な値は IP ヘッダの TOS フィールドで使用されるものと同一であると仮定されます。TOS 情報を配布するルーティング・プロトコルは、FIB に追加するルートの route.tos を適切に埋めます。他のルーティング・プロトコルからのルートは、デフォルト TOS（0000）を持つものとして扱われます。ルーティングされるパケットの IP ヘッダ内の TOS フィールドは ip.tos と呼ばれます。

   候補ルートの集合が調べられ、route.tos = ip.tos であるルートを含むかどうかが決定されます。含む場合、route.tos = ip.tos でないルートを除くすべてが破棄されます。含まない場合、route.tos = 0000 でないルートを除くすべてが候補ルートの集合から破棄されます。

   Weak TOS に基づくルーティングの追加の議論は [ROUTE:11] にあります。

DISCUSSION この規則の効果は、パケットで要求された TOS と一致する TOS を持つルートのみを選択することです。そのようなルートが存在しない場合、デフォルト TOS を持つルートが考慮されます。要求された TOS ではない非デフォルト TOS を持つルートは、そのようなルートがパケットの宛先へ向かう唯一の利用可能なルートである場合でも、決して使用されません。

(4) Best Metric（最良メトリクス）各ルートには route.metric と呼ばれるメトリクス属性と、route.domain と呼ばれるルーティング・ドメイン識別子があります。候補ルートの集合の各メンバーは、集合の他の各メンバーと比較されます。2 つのルートについて route.domain が等しく、一方の route.metric が他方と比較して厳密に劣っている場合、劣ったメトリクスを持つ方が集合から破棄されます。劣っているかどうかの決定は、通常、単純な算術比較によって行われますが、一部のプロトコルはより複雑な比較を必要とする構造化されたメトリクスを持つ場合があります。

(5) Vendor Policy（ベンダ・ポリシー） Vendor Policy は、前述の規則が可能なルートから選択するにはしばしば不十分であるという事実を補うための包括的な手段です。Vendor Policy 刈り込み規則は極めてベンダ固有です。セクション [5.2.4.4] を参照してください。

このアルゴリズムには 2 つの明確な欠点があります。おそらく、ルーター実装者はこれらの欠点に対処し、それらを Vendor Policy 刈り込み規則の一部にする技術を開発するかもしれません。

(1) IS-IS および OSPF のルート・クラスは直接的には処理されません。 (2) type of service 以外のパス特性（MTU など）は無視されます。

TOS がサポートされる方法の欠陥として、TOS をサポートするルーティング・プロトコルは、非ゼロの TOS 値を持つパケットを転送するときに暗黙的に優先されることにも注目する価値があります。

Basic Match および Longest Match 刈り込み規則は、いくつかの特定のタイプのルートの扱いを一般化します。これらのルートは、次の、好ましい順（低下順）で選択されます:

(1) Host Route（ホスト・ルート）: 特定のエンドシステムへのルートです。 (2) Hierarchical Network Prefix Routes（階層的ネットワーク・プレフィックス・ルート）: 特定のネットワーク・プレフィックスへのルートです。FIB には、互いを内包する（一方のプレフィックスが追加のビットを持つもう一方のプレフィックスである）複数のネットワーク・プレフィックスへのルートが含まれる場合があることに注意してください。これらはプレフィックス長の低下順に選択されます。 (5) Default Route（デフォルト・ルート）: 明示的なルートが存在しないすべてのネットワークへのルートです。これは定義により、プレフィックス長がゼロであるルートです。

刈り込み規則の適用後、ルートの集合が空（つまりルートが見つからなかった）の場合、パケットは廃棄されなければならず (MUST)、適切な ICMP エラーが生成されなければなりません (MUST)（IP 宛先アドレスがソースルート・オプションから来た場合は ICMP Bad Source Route、それ以外の場合はセクション [4.3.3.1] で説明されるように適切な ICMP Destination Host Unreachable または Destination Network Unreachable）。

5.2.4.4 Administrative Preference (管理上の優先順位)

Vendor Policy 刈り込み規則の 1 つの提案されたメカニズムは、administrative preference（管理上の優先順位）を使用することです。これは単純な優先順位付けアルゴリズムです。考え方は、選択する必要があるかもしれないルートに手動で優先順位を付けることです。

各ルートには、ルートのさまざまな属性に基づく preference 値が関連付けられています（preference 値の割り当ての具体的なメカニズムは以下に提案されています）。この preference 値は [0..255] の範囲の整数であり、0 が最も優先され、254 が最も優先されません。255 は、ルートを決して使用すべきではないことを意味する特別な値です。Vendor Policy 刈り込み規則の最初のステップは、最も好ましいルート以外をすべて破棄します（そして常に preference 値が 255 のルートを破棄します）。

このポリシーは、ルーティング・ループを作成するために容易に誤用される可能性があるため安全ではありません。いかなるプロトコルも、ルーターに設定された preference がその隣接のものと一致することを保証しないため、ネットワーク管理者は preference の設定において注意を払わなければなりません。

Address Match（アドレス一致）すべてのルート（同じルーティング・ドメインから学習）に単一の preference 値を割り当てることができると有用です。宛先の指定された集合のいずれにも一致するもので、その集合が指定されたネットワーク・プレフィックスに一致するすべての宛先である場合です。
Route Class（ルート・クラス）ルート・クラスの区別を維持するルーティング・プロトコルについて、特定のルート・クラス（intra-area、inter-area、internal metrics を持つ external、または external metrics を持つ external）を持つすべてのルート（同じルーティング・ドメインから学習）に単一の preference 値を割り当てることができると有用です。
Interface（インタフェース）すべてのルート（特定のルーティング・ドメインから学習）に単一の preference 値を割り当てることができると有用です。それらがパケットをルーターの特定の論理インタフェース（論理インタフェースは一般にルーターのネットワーク・インタフェースに 1 対 1 でマップされますが、複数の IP アドレスを持つネットワーク・インタフェースには複数の論理インタフェースが関連付けられる点を除く）からルーティングされるようにするものです。
Source router（送信元ルーター）すべてのルート（同じルーティング・ドメインから学習）に単一の preference 値を割り当てることができると有用です。それらが一連のルーターのいずれかから学習されたもので、その一連のルーターが更新の送信元アドレスが指定されたネットワーク・プレフィックスに一致するものである場合です。
Originating AS（発信元 AS）情報を提供するルーティング・プロトコルについて、別の特定のルーティング・ドメインで発信されたすべてのルート（特定のルーティング・ドメインから学習）に単一の preference 値を割り当てることができると有用です。BGP ルートの場合、発信元 AS はルートの AS_PATH 属性にリストされた最初の AS です。OSPF 外部ルートの場合、発信元 AS は、タグの Automatic ビットが設定され、タグの Path Length が 3 に等しくない場合、ルートの外部ルート・タグの下位 16 ビットと見なすことができます。
External route tag（外部ルート・タグ）すべての OSPF 外部ルート（同じルーティング・ドメインから学習）に単一の preference 値を割り当てることができると有用です。それらの外部ルート・タグが指定された値のリストのいずれかと一致する場合です。外部ルート・タグには構造化された値が含まれる可能性があるため、タグの特定のサブフィールドと一致させる機能を提供すると有用な場合があります。
AS path（AS パス）すべての BGP ルート（同じルーティング・ドメインから学習）に単一の preference 値を割り当てることができると有用な場合があります。それらの AS パスが指定された値の集合のいずれかと「一致する」場合です。どの種類の一致が最も有用かはまだ明らかではありません。単純なオプションは、特定の AS 番号がルートの AS_PATH 属性内のどこかに現れる（あるいは現れない）すべてのルートの一致を許可することです。より一般的ですがやや困難な代替案は、AS パスが指定された正規表現と一致するすべてのルートの一致を許可することです。

5.2.4.5 Load Splitting (負荷分割)

ネクストホップ選択プロセスの最後に、複数のルートが残っている場合があります。このような場合、ルーターにはいくつかの選択肢があります。ルートの一部を任意に破棄してもよい (MAY) です。等価でないと見なされないルーティング・ドメインからのルートのメトリクスを比較することによって、候補ルートの数を減らしてもよい (MAY) です。複数のルートを保持し、負荷分割 (load-splitting) メカニズムを使用してそれら間でトラフィックを分割してもよい (MAY) です。おそらく、これらの選択肢の相対的価値について言える唯一のことは、負荷分割は状況によっては有用ですが、そうでない場合もあるため、負荷分割を実装する賢明な実装者は、ネットワーク管理者がそれを無効にする手段も提供するであろうということです。

5.2.5 Unused IP Header Bits: RFC-791 Section 3.1 (未使用 IP ヘッダ・ビット)

IP ヘッダには、Type of Service フィールドと Flags フィールドにいくつかの予約ビットが含まれています。ルーターは、これらの予約ビットの 1 つ以上が非ゼロ値であるという理由だけでパケットを廃棄してはなりません (MUST NOT)。

ルーターはこれらの予約ビットの値を無視し、変更せずに通過させなければなりません (MUST)。ルーターがパケットをフラグメント化する場合、これらのビットを各フラグメントにコピーしなければなりません (MUST)。

DISCUSSION IP プロトコルの将来の改訂では、これらの未使用ビットを利用する可能性があります。これらの規則は、これらの改訂をインターネット内のすべてのルーターを同時にアップグレードすることなく展開できるようにすることを意図しています。

5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2 (フラグメンテーションと再構成)

セクション [4.2.2.7] で論じたように、ルーターは IP フラグメンテーションをサポートしなければなりません (MUST)。

ルーターは、転送前にいかなるデータグラムも再構成してはなりません (MUST NOT)。

DISCUSSION 通過するデータグラムのルーターによる再構成がパフォーマンスを改善する可能性があるようなトポロジーがあると示唆した人が少数います。フラグメントが宛先への異なるパスをとる可能性があるため、このような機能の安全な使用を妨げます。

この節のいかなる内容も、ルーターによるリンク層機能として実行されるフラグメンテーションまたは再構成を制御または制限するものと解釈されるべきではありません (SHOULD NOT)。

同様に、IP データグラムが別の IP データグラムにカプセル化されている（たとえばトンネリングされている）場合、そのデータグラムがさらにフラグメント化され、元のデータグラムを転送するためにフラグメントを再構成する必要があります。この節はこれを妨げるものではありません。

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

ICMP の一般的な要件はセクション [4.3] で論じました。この節は、ルーターのみが送信する ICMP メッセージについて論じます。

5.2.7.1 Destination Unreachable (宛先到達不能)

ICMP Destination Unreachable メッセージは、宛先（またはネクストホップ）が到達不能であるかサービスが利用不可であるために転送できないパケットへの応答としてルーターによって送信されます。そのようなケースの例には、存在せずしたがって ARP 要求に応答しないホストに宛てられたメッセージ、およびルーターが有効なルートを持たないネットワーク・プレフィックスに宛てられたメッセージが含まれます。

ルーターは ICMP Destination Unreachable メッセージを生成できる必要があり (MUST)、メッセージが生成される理由に最も近い応答コードを選択すべきです (SHOULD)。

次のコードが [INTERNET:8] および [INTRO:2] で定義されています:

0 = Network Unreachable（ネットワーク到達不能） - 宛先ネットワークへの転送パス（ルート）が利用不可である場合にルーターによって生成される。
1 = Host Unreachable（ホスト到達不能） - 直接接続されたネットワーク上の宛先ホストへの転送パス（ルート）が利用不可である（ARP に応答しない）場合にルーターによって生成される。
2 = Protocol Unreachable（プロトコル到達不能） - データグラムで指定されたトランスポート・プロトコルが最終宛先のトランスポート層でサポートされていない場合に生成される。
3 = Port Unreachable（ポート到達不能） - 指定されたトランスポート・プロトコル（UDP など）が最終宛先のトランスポート層でデータグラムを逆多重化できないが、送信者に通知するプロトコル・メカニズムを持たない場合に生成される。
4 = Fragmentation Needed and DF Set（フラグメンテーション必要・DF 設定） - ルーターがデータグラムをフラグメント化する必要があるが DF フラグが設定されているためにできない場合に生成される。
5 = Source Route Failed（ソースルート失敗） - ルーターがソースルート・オプション内のネクストホップへパケットを転送できない場合に生成される。
6 = Destination Network Unknown（宛先ネットワーク不明） - ルーターが宛先ネットワークが存在しないことを示唆するため、生成すべきではない (SHOULD NOT)（ネットワーク到達不能コード 0 をコード 6 の代わりに使用すべき）。
7 = Destination Host Unknown（宛先ホスト不明） - ルーターが（リンク層の助言から）宛先ホストが存在しないと判断できる場合にのみ生成される。
11 = Network Unreachable For Type Of Service（TOS に対するネットワーク到達不能） - 要求されたまたはデフォルトの TOS を持つ宛先ネットワークへの転送パス（ルート）が利用不可である場合にルーターによって生成される。
12 = Host Unreachable For Type Of Service（TOS に対するホスト到達不能） - ルーターが、宛先へのルートがデータグラムで要求された TOS ともデフォルト TOS（0）とも一致しないためにパケットを転送できない場合に生成される。

次の追加コードがここに定義されます:

13 = Communication Administratively Prohibited（通信が管理上禁止されている） - ルーターが管理上のフィルタリングのためにパケットを転送できない場合に生成される。
14 = Host Precedence Violation（ホスト優先順位違反）。要求された優先順位が特定の送信元/宛先ホストまたはネットワーク、上位層プロトコル、および送信元/宛先ポートの組み合わせに対して許可されていないことをホストに示すために、ファーストホップ・ルーターによって送信される。
15 = Precedence cutoff in effect（優先順位カットオフ発効中）。ネットワーク運用者が運用に要求される最小レベルの優先順位を課しており、データグラムはこのレベルより低い優先順位で送信された。

NOTE: [INTRO:2] は送信元ホスト孤立 (source host isolated) のコード 8 を定義しました。ルーターはコード 8 を生成すべきではなく (SHOULD NOT)、代わりに適切なコード 0（Network Unreachable）または 1（Host Unreachable）を使用すべきです (SHOULD)。[INTRO:2] はまた、宛先ネットワークへの通信が管理上禁止されているコード 9、および宛先ホストへの通信が管理上禁止されているコード 10 を定義しました。これらのコードは、米国軍機関が使用するエンドツーエンド暗号化装置による使用を意図していました。ルーターは、管理上パケットをフィルタリングする場合、新しく定義されたコード 13（Communication Administratively Prohibited）を使用すべきです (SHOULD)。

ルーターは、コード 13（Communication Administratively Prohibited）メッセージを生成しないようにする設定オプションを持ってもよい (MAY)。このオプションが有効な場合、転送が管理上禁止されているために廃棄されたパケットへの応答として ICMP エラー・メッセージは送信されません。

同様に、ルーターはコード 14（Host Precedence Violation）およびコード 15（Precedence Cutoff in Effect）メッセージを生成しないようにする設定オプションを持ってもよい (MAY)。このオプションが有効な場合、優先順位違反のために廃棄されたパケットへの応答として ICMP エラー・メッセージは送信されません。

ルーターは、同じ宛先ネットワーク上の他のホストが到達可能な可能性がある場合、常に Host Unreachable または Destination Host Unknown コードを使用しなければなりません (MUST)。そうしない場合、送信元ホストはネットワーク上のすべてのホストが到達不能であると誤って結論付ける可能性があり、そうではない場合があります。

[INTERNET:14] は、コード 4（Fragmentation needed and DF set）を含む Destination Unreachable メッセージの形式のわずかな変更を説明しています。ルーターはコード 4 Destination Unreachable メッセージを発信するとき、この変更された形式を使用しなければなりません (MUST)。

5.2.7.2 Redirect (リダイレクト)

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

ルーターは、[INTERNET:8] で指定された Redirect for Network または Redirect for Network and Type of Service メッセージ（コード 0 および 2）を生成してはなりません (MUST NOT)。ルーターは Redirect for Host メッセージ（コード 1）を生成できる必要があり (MUST)、[INTERNET:8] で指定された Redirect for Type of Service and Host メッセージ（コード 3）を生成できるべきです (SHOULD)。

DISCUSSION 直接接続されたネットワークが（古典的な意味で）サブネット化されていない場合、ルーターは通常、指定されたリモート・ネットワーク上のすべてのホストに適用されるネットワーク・リダイレクトを生成できます。ネットワーク・リダイレクトを使用することは、ホスト・リダイレクトを使用する場合よりも、ネットワーク・トラフィックとホスト・ルーティング・テーブル・ストレージをわずかに節約する可能性があります。しかし、節約は重要ではなく、サブネットはネットワーク・リダイレクトを解釈するために使用されるサブネット・マスクについてあいまいさを生じさせます。CIDR 環境では、ネットワーク・リダイレクトを使用できる場合を正確に指定することは困難です。したがって、ルーターはホスト（またはホストおよび type of service）リダイレクトのみを送信しなければなりません (MUST)。

コード 3（Redirect for Host and Type of Service）メッセージは、リダイレクトを引き起こしたパケットの宛先に対するルーターが選択したパスが（一部において）要求された TOS に依存する場合に生成されます。

コード 3 リダイレクト（Host and Type of Service）を生成できるルーターは、コード 3 リダイレクトの代わりにコード 1（Host）リダイレクトを代用するための設定オプション（デフォルトはオン）を持たなければなりません (MUST)。ルーターがそうするように設定されている場合、コード 3 リダイレクトの代わりにコード 1 リダイレクトを送信しなければなりません (MUST)。

ルーターがコード 3 リダイレクトを生成できない場合、コード 3 リダイレクトが要求される状況でコード 1 リダイレクトを生成しなければなりません (MUST)。

ルーターは、次のすべての条件が満たされない限り、Redirect メッセージを生成してはなりません (MUST NOT):

パケットが受信したのと同じ物理インタフェースから転送されていること、
パケット内の IP 送信元アドレスがネクストホップ IP アドレスと同じ論理 IP（サブ）ネットワーク上にあること、および
パケットに IP ソースルート・オプションが含まれていないこと。

ICMP Redirect で使用される送信元アドレスは、宛先アドレスと同じ論理（サブ）ネットに属さなければなりません (MUST)。

ルーティング・プロトコル（静的ルート以外）を使用するルーターは、パケットを転送するとき、ICMP Redirect から学習したパスを考慮してはなりません (MUST NOT)。ルーターがルーティング・プロトコルを使用していない場合、ルーターは設定を持ってもよく (MAY)、それが設定されている場合、パケットを転送するときに ICMP Redirect を通じて学習したルートを考慮することを許可します。

DISCUSSION ICMP Redirect は、ルーターがホストにルーティング情報を伝達するメカニズムです。ルーターはルーティング情報を学習するために他のメカニズムを使用するため、リダイレクトに従う理由はありません。リダイレクトを信じることは、ルーターの他の情報と矛盾し、ルーティング・ループを引き起こす可能性が高いです。

一方、ルーターがルーターとして動作していない場合、ホストに要求される動作に準拠しなければなりません (MUST)。

5.2.7.3 Time Exceeded

ルーターは、期限切れの TTL フィールドのためにパケットを廃棄したとき、Time Exceeded メッセージ Code 0（In Transit）を生成しなければなりません (MUST)。ルーターは、そのインタフェース上でのこれらのメッセージの発信を無効にするための、インタフェースごとのオプションを持ってもよい (MAY) ですが、そのオプションはメッセージの発信を許可することをデフォルトとしなければなりません (MUST)。

5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP

ルーターは IGMP のマルチキャスト・ルーター側を実装すべきです (SHOULD)。

5.3 SPECIFIC ISSUES

5.3.1 Time to Live (TTL)

IP ヘッダの Time-to-Live (TTL) フィールドは、データグラムの寿命を制限するタイマーとして定義されています。これは 8 ビット・フィールドで、単位は秒です。パケットを処理する各ルーター（または他のモジュール）は、経過時間が 1 秒未満であっても、TTL を少なくとも 1 デクリメントしなければなりません (MUST)。これが非常に頻繁に当てはまるため、TTL は事実上、データグラムがインターネットを伝播できる距離に対するホップ・カウント制限となります。

ルーターがパケットを転送するとき、TTL を少なくとも 1 デクリメントしなければなりません (MUST)。パケットを 1 秒以上保持する場合、1 秒ごとに TTL を 1 デクリメントしてもよい (MAY) です。

TTL がゼロ（以下）に減少した場合、パケットは廃棄されなければならず (MUST)、宛先がマルチキャスト・アドレスでない場合、ルーターは送信元に ICMP Time Exceeded メッセージ、Code 0（TTL Exceeded in Transit）メッセージを送信しなければなりません (MUST)。ルーターは、パケットの最終宛先へのパス上の別のルーターが TTL をゼロにデクリメントすることを予測できるという理由だけで、非ゼロの TTL を持つ IP ユニキャストまたはブロードキャスト・パケットを廃棄してはならない (MUST NOT) ことに注意してください。ただし、IP マルチキャストの場合、IP マルチキャストの expanding ring search アルゴリズム（[INTERNET:4] 参照）をより効率的に実装するために、ルーターはそうしてもよい (MAY) です。

DISCUSSION IP TTL は、やや分裂症的に、ホップ・カウント制限と時間制限の両方として使用されます。そのホップ・カウント機能は、ルーティング問題によってパケットがネットワーク内で無限にループし、ネットワークがメルトダウンするのを防ぐために重要です。時間制限機能は、TCP などのトランスポート・プロトコルによって、信頼性の高いデータ転送を確保するために使用されます。現在の多くの実装は TTL を純粋なホップ・カウントとして扱い、インターネット・コミュニティの一部には、時間制限機能はそれを必要とするトランスポート・プロトコルによって実行されるべきであるという強い意見があります。

この仕様では、時間制限機能は任意とするべきであるというルーター・ベンダー間の強い信念に従うことに、不本意ながら決定しました。彼らは、時間制限機能の実装が困難であるため、現在一般には行われていないと主張しました。さらに、この近道が TCP にデータを破損させた文書化された事例の欠如を指摘しました（もちろん、作成される問題はまれで再現が困難であると予想されるため、文書化された事例の欠如は、文書化されていない多数の事例がないことのわずかな保証にしかなりません）。

IP マルチキャストの概念（expanding ring search など）は、TTL が純粋なホップ・カウントとして扱われない限り、期待通りに機能しない場合があります。traceroute についても同様のことが幾分当てはまります。

ICMP Time Exceeded メッセージは、traceroute 診断ツールがそれに依存するため必要です。

したがって、トレードオフは、2 つの非常に有用なツールを（排除しないにしても）著しく損なうことと、全く発生しない可能性がある非常にまれで過渡的なデータ転送問題を回避することの間にあります。我々はツールを維持することを選択しました。

5.3.2 Type of Service (TOS)

IP ヘッダの Type-of-Service バイトは 3 つのセクションに分割されます: Precedence フィールド（上位 3 ビット）、慣習的に Type of Service または「TOS」（次の 4 ビット）と呼ばれるフィールド、および予約ビット（最下位ビット）です。予約ビットを管理する規則はセクション [4.2.2.3] で説明しました。Precedence フィールドはセクション [5.3.3] で論じます。TOS フィールドとその使用に関するより詳細な議論は [ROUTE:11] にあります。

ルーターは、パケットを転送する方法を決定するとき、パケットの IP ヘッダ内の TOS フィールドを考慮すべきです (SHOULD)。この節の残りは、この要件に準拠するルーターに適用される規則を説明します。

ルーターは、ルーティング・テーブル内の各ルートに対して TOS 値を維持しなければなりません (MUST)。TOS をサポートしないルーティング・プロトコルを通じて学習されたルートには、TOS ゼロ（デフォルト TOS）を割り当てなければなりません (MUST)。

宛先へのルートを選択するために、ルーターは次と同等のアルゴリズムを使用しなければなりません (MUST):

(1) ルーターはルーティング・テーブル内で宛先へのすべての利用可能なルートを検索します（セクション [5.2.4] 参照）。

(2) 利用可能なルートがない場合、ルーターは宛先が到達不能であるためパケットを廃棄します。セクション [5.2.4] を参照してください。

(3) それらのルートの 1 つ以上が、パケットで指定された TOS と完全に一致する TOS を持つ場合、ルーターは最良のメトリクスを持つルートを選択します。

(4) それ以外の場合、ルーターは上記のステップを繰り返しますが、TOS がゼロであるルートを調べます。

(5) 上記でルートが選択されなかった場合、ルーターは宛先が到達不能であるためパケットを廃棄します。ルーターは、適切なコード（Type of Service に対する Network Unreachable（コード 11）または Type of Service に対する Host Unreachable（コード 12））を指定する ICMP Destination Unreachable エラーを返します。

DISCUSSION TOS は過去にはほとんど使用されてきませんでしたが、ホストによるその使用は現在、Requirements for Internet Hosts RFC（[INTRO:2] および [INTRO:3]）によって必須とされています。ルーターにおける TOS のサポートは将来的には MUST となる可能性がありますが、現時点では経験を積み、その利点とコストの両方をよりよく判断できるようになるまで SHOULD です。

さまざまな人々が、TOS が転送機能の他の側面に影響を及ぼすべきであると提案しています。たとえば:

(1) ルーターは、Low Delay ビットが設定されたパケットを、出力キュー内の他のパケットの前に配置できる。 (2) ルーターがパケットを廃棄せざるを得ない場合、High Reliability ビットが設定されたものを廃棄しないように試みることができる。

これらのアイデアは [INTERNET:17] でより詳細に検討されていますが、この分野で要件を設けるのに十分な経験はまだありません。

5.3.3 IP Precedence

この節は、ルーターにおける IP Precedence フィールドの適切な処理に関する要件とガイドラインを規定します。Precedence は、異なるトラフィック・フローの相対的な重要性に基づいてネットワーク内の資源を割り当てる方式です。

5.3.3.1 Precedence-Ordered Queue Service

ルーターは Precedence 順キュー・サービスを実装すべきです (SHOULD)。Precedence 順キュー・サービスとは、（論理）リンクでの出力のためにパケットが選択されたとき、そのリンクのためにキューイングされた最高の Precedence を持つパケットが送信されることを意味します。Precedence 順キュー・サービスを実装するルーターは、インターネット層で Precedence 順キュー・サービスを抑制する設定オプションを持たなければなりません (MUST)。

任意のルーターは、厳密な Precedence 順序以外の結果となる他のポリシーベースのスループット管理手順を実装してもよい (MAY) ですが、それらを抑制する（すなわち厳密な順序を使用する）ように設定可能でなければなりません (MUST)。

セクション [5.3.6] で詳述するように、Precedence 順キュー・サービスを実装するルーターは、輻輳制御の目的で、高 Precedence パケットを廃棄する前に低 Precedence パケットを廃棄します。

Preemption（パケットの処理または送信の中断）は、インターネット層の機能としては想定されていません。他の層の一部のプロトコルはプリエンプション機能を提供する場合があります。

5.3.3.2 Lower Layer Precedence Mappings

Precedence 順キューイングを実装するルーターは Lower Layer Precedence Mapping を実装しなければならず (MUST)、他のルーターは実装すべきです (SHOULD)。

Lower Layer Precedence Mapping を実装するルーター:

そのような機能が定義されているリンク層に対して、IP Precedence を Link Layer 優先度メカニズムにマップできなければならない (MUST)。
すべての IP トラフィックに対する Link Layer のデフォルト優先度処理を選択する設定オプションを持たなければならない (MUST)。
各インタフェースに対して、IP precedence 値から Link Layer 優先度値への特定の非標準マッピングを設定できるべきです (SHOULD)。

DISCUSSION 一部の研究は、一部の Link Layer プロトコルの優先度機能の実用性に疑問を投げかけており、一部のネットワークはリンク層優先度メカニズムの欠陥のある実装を持つ場合があります。このような問題がネットワークに現れた場合に備えて、逃げ道を提供することが賢明と思われます。

一方、マルチメディア帯域幅予約や低遅延サービスなどの特殊なサービスを実装するために、新規なキューイング戦略を使用する提案があります。特殊なサービスとそれらをサポートするキューイング戦略は現在の研究課題であり、標準化の過程にあります。

実装者は、DOD ネットワークで使用される TCP/IP システムに対して、IP precedence の正しいリンク層マッピングが DOD ポリシーによって要求されていることを考慮したい場合があります。これらの要件は、すべてのユーザーにより良いインターネット・サービスを提供することを期待して、Precedence 機能の使用を（強制するのではなく）奨励することを意図しているため、Precedence 順キュー・サービスをサポートするルーターは、要求されたサービスのタイプに関わらず、厳密な Precedence 順序の維持をデフォルトとするべきです (SHOULD)。

5.3.3.3 Precedence Handling For All Routers

ルーター（Precedence 順キュー・サービスを採用しているかどうかに関わらず）:

(1) 管理上別様に設定されていない限り、すべての Precedence レベルの着信トラフィックを通常通り受信および処理しなければならない (MUST)。

(2) 特定のトラフィック送信元による Precedence レベルの使用を管理上制限する検証フィルタを実装してもよい (MAY)。提供される場合、このフィルタは次の種類の ICMP エラー・メッセージをフィルタリングで除外したり遮断したりしてはならない (MUST NOT): Destination Unreachable、Redirect、Time Exceeded、および Parameter Problem。このフィルタが提供される場合、アドレスによるパケット・フィルタリングに必要な手順がこのフィルタにも必要です。

DISCUSSION Precedence フィルタリングは、特定の送信元/宛先 IP アドレスの組、特定のプロトコル、特定のポートなどに適用可能であるべきです。

パケットが検証フィルタによって廃棄されたとき、コード 14 を持つ ICMP Destination Unreachable メッセージを送信すべきです (SHOULD)。ただし、これが設定の選択によって抑制されている場合を除きます。

(3) 指定されたレベル未満の Precedence を持つトラフィックを拒否または廃棄するようにルーターを設定できるカットオフ機能を実装してもよい (MAY)。この機能は管理アクションまたはいくつかの実装依存のヒューリスティクスによって活性化される場合がありますが、人間の介入なしに動作する任意のヒューリスティクス・メカニズムを無効にする設定オプションが存在しなければなりません (MUST)。パケットがカットオフ機能によって廃棄されたとき、コード 15 を持つ ICMP Destination Unreachable メッセージを送信すべきです (SHOULD)。ただし、これが設定の選択によって抑制されている場合を除きます。

ルーターは、IP precedence が 6（Internetwork Control）または 7（Network Control）であるデータグラムを、単に Precedence カットオフのために転送拒否してはなりません (MUST NOT)。ただし、高 Precedence トラフィックをフィルタリングするために、Precedence カットオフと併せて他の基準を使用してもよい (MAY) です。

DISCUSSION 制限なしの Precedence カットオフは、ルーティングおよび制御トラフィックの意図しないカットオフをもたらす可能性があります。一般的なケースでは、ホスト・トラフィックは値 5（CRITIC/ECP）以下に制限されるべきです。これは要件ではなく、特定のシステムでは正しくない場合があります。

(4) 自身が発信したものでないパケットの Precedence 設定を変更してはならない (MUST NOT)。

(5) サポートする各ルーティングまたは管理プロトコル（使用する Precedence 値を指定する OSPF などのプロトコルを除く）に使用する個別の Precedence 値を設定できるべきです (SHOULD)。

(6) 各ピア・アドレスごとに、ルーティングまたは管理トラフィックの Precedence 値を独立して設定できるようにしてもよい (MAY)。

(7) 提供される場合、Link Layer の Precedence 関連エラー表示に対して適切に応答しなければならない (MUST)。パケットが Precedence 関連の条件のためにリンクがそれを受け入れられず廃棄されたとき、コード 15 を持つ ICMP Destination Unreachable メッセージを送信すべきです (SHOULD)。ただし、これが設定の選択によって抑制されている場合を除きます。

DISCUSSION 上記 (3) で説明した Precedence カットオフ・メカニズムはやや論争の的です。カットオフの影響を受ける領域のトポロジカルな位置によっては、通過トラフィックがルーティング・プロトコルによってカットオフの領域へ向けられ、そこで廃棄される可能性があります。これは、通信ポイント間にカットオフの影響を受けない別のパスが存在する場合にのみ問題となります。この問題を回避する提案された方法には、過負荷条件下でもすべての Precedence レベルに最小帯域幅を提供する、またはカットオフ情報をルーティング・プロトコルで伝播するなどがあります。この問題に対する広く受け入れられた（かつ実装された）解決策がないため、通過ネットワークでカットオフ・メカニズムを活性化する際には最大の注意が推奨されます。

トランスポート層リレーは、(4) で禁止されている機能を正当に提供できる場合があります。Precedence レベルの変更は TCP およびおそらく他のプロトコルとの微妙な相互作用を引き起こす可能性があり、正しい設計は自明ではありません。

(5) および (6)（およびセクション [4.3.2] の ICMP メッセージにおける IP Precedence の議論）の意図は、このルーターがこれらのビットを他の方法で利用するかどうかにかかわらず、IP precedence ビットが適切に設定されるべきであるということです。将来的には、ルーティング・プロトコルおよびネットワーク管理プロトコルの仕様が、それらのプロトコルによって送信されるメッセージの IP Precedence の設定方法を規定すると期待しています。

(7) の適切な応答は、使用中のリンク層プロトコルに依存します。典型的には、ルーターは一定期間、その宛先への攻撃的なトラフィックの送信を試みるのを停止し、コード 15（要求された Precedence に対してサービス利用不可）を持つ ICMP Destination Unreachable メッセージをトラフィックの送信元に返すべきです (SHOULD)。また、一定期間、プリエンプトされた Link Layer 接続を再確立しようとしてはなりません (SHOULD)。

5.3.4 Forwarding of Link Layer Broadcasts

ほとんどの Link Layer プロトコル（PPP を除く）での IP パケットのカプセル化により、受信者は Link Layer プロトコル・ヘッダ（最も一般的には Link Layer 宛先アドレス）を調べるだけで、ブロードキャストとマルチキャストをユニキャストと区別できます。この節の Link Layer ブロードキャストを参照する規則は、ブロードキャストを区別できる Link Layer プロトコルにのみ適用されます。同様に、Link Layer マルチキャストを参照する規則は、マルチキャストを区別できる Link Layer プロトコルにのみ適用されます。

ルーターは、Link Layer ブロードキャストとして受信したパケットを転送してはなりません (MUST NOT)。ただし、IP マルチキャスト・アドレスに宛てられている場合を除きます。後者の場合、効果的なマルチキャスト・サービスがないため Link Layer ブロードキャストが使用されたと推測されます。

ルーターは、Link Layer マルチキャストとして受信したパケットを、パケットの宛先アドレスが IP マルチキャスト・アドレスでない限り、転送してはなりません (MUST NOT)。

ルーターは、Link Layer ブロードキャストを介して受信され、IP マルチキャストまたは IP ブロードキャストの宛先アドレスを指定していないパケットを暗黙的に廃棄すべきです (SHOULD)。

ルーターがパケットを Link Layer ブロードキャストとして送信するとき、IP 宛先アドレスは合法な IP ブロードキャストまたは IP マルチキャスト・アドレスでなければなりません (MUST)。

5.3.5 Forwarding of Internet Layer Broadcasts

IP ブロードキャスト・アドレスには 2 つの主要なタイプがあります: 限定ブロードキャストと指定ブロードキャストです。さらに、指定ブロードキャストには 3 つのサブタイプがあります: 指定されたネットワーク・プレフィックスに宛てられたブロードキャスト、指定されたサブネットワークに宛てられたブロードキャスト、および指定されたネットワークのすべてのサブネットに宛てられたブロードキャストです。ルーターによるブロードキャストのこれらカテゴリのいずれかへの分類は、ブロードキャスト・アドレスと、宛先ネットワークのサブネット構造に対するルーターの認識（ある場合）に依存します。同じブロードキャストは、異なるルーターによって異なるように分類されます。

限定 IP ブロードキャスト・アドレスは all-ones、すなわち { -1, -1 } または 255.255.255.255 と定義されます。

ネットワーク・プレフィックス指定ブロードキャストは、ローカル部が all-ones である、すなわち { , -1 } である IP アドレスのネットワーク・プレフィックスから構成されます。たとえば、Class A ネット・ブロードキャスト・アドレスは net.255.255.255、Class B ネット・ブロードキャスト・アドレスは net.net.255.255、Class C ネット・ブロードキャスト・アドレスは net.net.net.255 です（net はネットワーク・アドレスの 1 バイト）。

all-subnets-directed-broadcast は CIDR 環境では明確に定義されず、本メモのバージョン 1 で廃止されました。

セクション [4.2.3.1] で説明したように、ルーターは特定の非標準な IP ブロードキャスト・アドレスに遭遇する可能性があります:

0.0.0.0 は限定ブロードキャスト・アドレスの廃止された形式である。
{ , 0 } はネットワーク・プレフィックス指定ブロードキャスト・アドレスの廃止された形式である。

その節で説明したように、これらのアドレスのいずれかに宛てられたパケットは暗黙的に廃棄されるべきです (SHOULD) が、廃棄されない場合、上記で説明したブロードキャスト・アドレスの非廃止形式に宛てられたパケットに適用されるものと同じ規則に従って処理されなければなりません (MUST)。これらの規則は次の数節で説明します。

5.3.5.1 Limited Broadcasts

限定ブロードキャストは転送してはなりません (MUST NOT)。限定ブロードキャストは廃棄してはなりません (MUST NOT)。限定ブロードキャストは送信してもよく (MAY)、限定ブロードキャストで十分な場合は指定ブロードキャストの代わりに送信すべきです (SHOULD)。

DISCUSSION 一部のルーターには、要求を（ユニキャストまたは指定ブロードキャストとして）他のサーバに再送信することによって機能する UDP サーバが含まれています。この要件は、そのようなサーバを禁止するものと解釈されるべきではありません。ただし、そのようなサーバは誤って設定されると容易にパケットのループを引き起こす可能性があることに注意してください。したがって、そのようなサーバの提供者は、セットアップを注意深く文書化し、送信されるパケットの TTL を注意深く考慮することをおそらく勧められます。

5.3.5.2 Directed Broadcasts

ルーターは、リモート・ネットワークまたは接続された非サブネット化ネットワークに宛てられた、すべての有効な指定ブロードキャストをネットワーク・プレフィックス指定ブロードキャストとして分類しなければなりません (MUST)。CIDR の観点から、このようなものはネットワーク・プレフィックス内のホスト・アドレスのように見えることに注意してください。我々はそのようなネットワーク・プレフィックスのホスト部の検査を排除します。したがって、ルートがあり、それを無効にするポリシーがない場合、ルーターはネットワーク・プレフィックス指定ブロードキャストを転送しなければなりません (MUST)。ネットワーク・プレフィックス指定ブロードキャストは送信してもよい (MAY) です。

ルーターは、インタフェースでのネットワーク・プレフィックス指定ブロードキャストの受信を無効にするオプションを持ってよく (MAY)、ネットワーク・プレフィックス指定ブロードキャストの転送を無効にするオプションを持たなければなりません (MUST)。これらのオプションは、ネットワーク・プレフィックス指定ブロードキャストの受信および転送を許可することをデフォルトとしなければなりません (MUST)。

DISCUSSION 指定ブロードキャストを転送するかどうかについて、いくつかの議論がありました。本メモでは、転送の決定を宛先ネットワーク・プレフィックスに対するルーターの認識に依存させました。ルーターは、この認識がなければ、メッセージがユニキャストか指定ブロードキャストかを判断できません。メッセージを転送するかどうかの決定は、定義により、最終ホップ・ルーターでのみ可能です。

5.3.5.3 All-subnets-directed Broadcasts

本メモのバージョン 1 は、古典的なネットワーク番号のすべてのサブネットに指定ブロードキャストを配信するためのアルゴリズムを説明していました。このアルゴリズムは「壊れている」と記述され、特定の失敗ケースが指定されました。

古典的な IP ネットワーク番号が無意味である CIDR ルーティング・ドメインでは、all-subnets-directed-broadcast の概念もまた無意味です。ワーキング・グループの知る限り、この機能が実装または展開されたことはなく、現在では歴史の塵芥に追いやられています。

5.3.5.4 Subnet-directed Broadcasts

本メモのバージョン 1 は、サブネット指定ブロードキャストを扱う手順を詳述していました。CIDR ルーティング・ドメインでは、これらは net-directed-broadcast と区別できません。したがって、両者はセクション [5.3.5.2 Directed Broadcasts] で一緒に扱われ、ネットワーク・プレフィックス指定ブロードキャストと見なされるべきです。

5.3.6 Congestion Control (輻輳制御)

ネットワークの輻輳は、大まかに、資源（通常は帯域幅または CPU 時間）への需要が容量を超える状態と定義されます。輻輳回避は需要が容量を超えないよう防ごうとし、輻輳回復は稼働状態を回復させようとします。ルーターはこれら両方のメカニズムに寄与する可能性があります。この問題の研究には多大な努力が払われてきました。読者は研究の概観として [FORWARD:2] を読むことを推奨します。この主題に関する重要な論文には、[FORWARD:3]、[FORWARD:4]、[FORWARD:5]、[FORWARD:10]、[FORWARD:11]、[FORWARD:12]、[FORWARD:13]、[FORWARD:14]、および [INTERNET:10] などがあります。

ホストが [FORWARD:5] で説明されるような合理的な輻輳ポリシーを使用する場合、ルーターがピーク瞬間需要を処理するために利用可能でなければならないストレージの量は、リンクの帯域幅とそのリンクを使用するフローのパス遅延の積の関数であり、したがってこの Bandwidth*Delay 積が増大するにつれてストレージも増大すべきです。ストレージ容量と廃棄確率を関連付ける正確な関数は知られていません。

ルーターがそのストレージ容量を超えるパケットを受信した場合、それを（定義により、命令ではなく）廃棄するか、他の 1 つ以上のパケットを廃棄しなければなりません。どのパケットを廃棄するかは多くの研究の主題ですが、残念ながらこれまでのところ合意はほとんどありません。現在までの最良の知見は、リンクを最も重度に使用しているデータ・ストリームからパケットを廃棄することを示唆しています。ただし、廃棄するパケットの選択に関連する追加の要因として、トラフィックの Precedence、アクティブな帯域幅予約、およびそのパケットの選択に関連する複雑さが含まれる場合があります。

ルーターは、受信したばかりのパケットを廃棄してもよい (MAY) です。これは最も単純ですが最良ではありません。理想的には、ルーターは、適用される Quality of Service ポリシーが許可する場合、リンクを最も不当に乱用しているセッションの 1 つのキューからパケットを選択すべきです (SHOULD)。FIFO キューを使用するデータグラム環境での推奨ポリシーは、キューからランダムに選択したパケットを廃棄することです（[FORWARD:5] 参照）。フェア・キューを使用するルーターでの同等のアルゴリズムは、最長のキュー、または最大の仮想時間を使用しているキューから廃棄することです（[FORWARD:13] 参照）。ルーターは、どのパケットを廃棄するかを決定するためにこれらのアルゴリズムを使用してもよい (MAY) です。

ルーターが廃棄ポリシー（Random Drop など）を実装しており、対象のパケットのプールから廃棄するパケットを選択する場合:

Precedence 順キュー・サービス（セクション [5.3.3.1] 参照）が実装され有効化されている場合、ルーターは、廃棄されないパケットよりも高い IP precedence を持つパケットを廃棄してはなりません (MUST NOT)。
ルーターは、最大信頼性 TOS を要求する IP ヘッダを持つパケットを保護してもよい (MAY) です。ただし、それが前の規則に違反する場合を除きます。
ルーターは、IP フラグメント・パケットを保護してもよい (MAY) です。その理論は、データグラムのフラグメントをドロップすると、データグラムのすべてのフラグメントが送信元によって再送信されることになり、輻輳が増大する可能性があるためです。
ルーティングの変動や管理機能の中断を防ぐため、ルーターはルーティング制御、リンク制御、またはネットワーク管理に使用されるパケットが廃棄されるのを保護してもよい (MAY) です。専用ルーター（すなわち、汎用ホスト、ターミナル・サーバ等でもないルーター）は、送信元または宛先がルーター自身であるパケットを保護することで、この規則の近似を達成できます。

輻輳制御の高度な方法には公平性の概念が含まれ、パケットを失うことでペナルティを受ける「ユーザ」が、輻輳に最も寄与した者となるようにします。帯域幅輻輳制御を扱うためにどのメカニズムが実装されるにしても、ルーターが CPU 輻輳にも陥らないよう、消費される CPU 努力が十分に小さくなることが重要です。

セクション [4.3.3.3] で説明したように、本メモはルーターが廃棄しているパケットの送信元に Source Quench を送信すべきではない (SHOULD NOT) ことを推奨します。ICMP Source Quench は非常に弱いメカニズムであるため、ルーターがそれを送信する必要はなく、ホスト・ソフトウェアは輻輳の指標としてそれのみに依存すべきではありません。

5.3.7 Martian Address Filtering

IP 送信元アドレスは、4.2.2.11 または 5.3.7 で定義される特別な IP アドレスである場合、またはユニキャスト・アドレスでない場合、無効です。

IP 宛先アドレスは、4.2.3.1 で違法な宛先として定義されているものに含まれる場合、または Class E アドレス（255.255.255.255 を除く）である場合、無効です。

ルーターは、無効な IP 送信元アドレス、またはネットワーク 0 の送信元アドレスを持つパケットを転送すべきではありません (SHOULD NOT)。ルーターは、ネットワーク 127 の送信元アドレスを持つパケットを、ループバック・インタフェース経由を除き、転送すべきではありません (SHOULD NOT)。ルーターは、ネットワーク管理者がこれらのチェックを無効にできるスイッチを持ってよい (MAY) です。そのようなスイッチが提供される場合、チェックを実行することをデフォルトとしなければなりません (MUST)。

ルーターは、無効な IP 宛先アドレス、またはネットワーク 0 の宛先アドレスを持つパケットを転送すべきではありません (SHOULD NOT)。ルーターは、ネットワーク 127 の宛先アドレスを持つパケットを、ループバック・インタフェース経由を除き、転送すべきではありません (SHOULD NOT)。ルーターは、ネットワーク管理者がこれらのチェックを無効にできるスイッチを持ってよい (MAY) です。そのようなスイッチが提供される場合、チェックを実行することをデフォルトとしなければなりません (MUST)。

ルーターがこれらの規則によりパケットを廃棄した場合、少なくとも IP 送信元アドレス、IP 宛先アドレス、および（該当する場合）廃棄の原因となった IP オプションのポインタをログに記録すべきです (SHOULD)。

問題が送信元アドレスにあった場合は、パケットが受信された物理インタフェースおよびパケットを受信したホストまたはルーターの Link Layer アドレスもログに記録すべきです (SHOULD)。

5.3.8 Source Address Validation

ルーターは、パケットの送信元アドレスと、パケットが受信された論理インタフェースの転送テーブルとの比較に基づいてトラフィックをフィルタリングする能力を実装すべきです (SHOULD)。このフィルタリングが有効な場合、ルーターは、パケットが受信されたインタフェースが、送信元アドレスに含まれるアドレスに到達するためにパケットが転送されるインタフェースでない場合、パケットを暗黙的に廃棄しなければなりません (MUST)。より単純に言えば、ルーターが特定のインタフェースを通じてこのアドレスを含むパケットをルーティングしない場合、このインタフェースから読み取られたパケットで送信元アドレスとして現れたとしてもそのアドレスを信じてはならないということです。

この機能が実装される場合、デフォルトで無効でなければなりません (MUST)。

DISCUSSION この機能は、一部の状況で有用なセキュリティ改善を提供できますが、パスが非対称である状況では有効なパケットを誤って廃棄する可能性があります。

5.3.9 Packet Filtering and Access Lists

セキュリティの提供および/またはネットワークの一部を通るトラフィックの制限の手段として、ルーターはパケットを選択的に転送（またはフィルタリング）する能力を提供すべきです (SHOULD)。この能力が提供される場合、パケットのフィルタリングは、すべてのパケットを転送するか、送信元および宛先プレフィックスに基づいて選択的に転送するように設定可能であるべきです (SHOULD)。また、他のメッセージ属性でフィルタリングしてもよい (MAY) です。各送信元および宛先アドレスは、任意のプレフィックス長の指定を許可すべきです (SHOULD)。

DISCUSSION この機能は、境界の外側のシステムが境界の内側のシステムと特定のプロトコルを交換することを許可されない、または通信できるシステムが制限される場合に、一定のプライバシーを提供できます。また、境界の外側のシステムが境界の内側のシステムになりすまし、それとのセッションを模倣するという特定のクラスのセキュリティ侵害を防ぐのに役立ちます。

サポートされる場合、ルーターは、次のいずれかを許可するように設定可能であるべきです (SHOULD):

Include list（インクルード・リスト） - 転送されるメッセージ定義のリストの指定、または
Exclude list（エクスクルード・リスト） - 転送されるべきではないメッセージ定義のリストの指定。

この文脈での「メッセージ定義」は、送信元および宛先ネットワーク・プレフィックスを指定し、IP プロトコル・タイプや TCP ポート番号などの他の識別情報を含む場合があります。

ルーターは、インクルード・リストとエクスクルード・リストのいずれを指定するか、または他の同等の制御を選択できる設定スイッチを提供してもよい (MAY) です。

任意のアドレスに一致する値（たとえば、キーワード any、マスクがすべて 0 のアドレス、または長さがゼロのネットワーク・プレフィックス）は、送信元および/または宛先アドレスとして許可されなければなりません (MUST)。

アドレス対に加えて、ルーターはトランスポートおよび/またはアプリケーション・プロトコルと送信元および宛先ポートの任意の組み合わせの指定を許可してもよい (MAY) です。

ルーターは、パケットを暗黙的に廃棄する（すなわち、ICMP エラー・メッセージを送信せずに廃棄する）ことを許可しなければなりません (MUST)。

ルーターは、パケットが廃棄されたときに適切な ICMP 到達不能メッセージを送信することを許可すべきです (SHOULD)。ICMP メッセージは、宛先が到達不能である理由として Communication Administratively Prohibited（コード 13）を指定すべきです (SHOULD)。

ルーターは、指定を許可するアドレス対、プロトコル・タイプ、およびポートの各組み合わせごとに、ICMP 宛先到達不能メッセージ（コード 13）の送信を設定可能にすべきです (SHOULD)。

ルーターは、転送されなかったパケットをカウントし、選択的にログに記録することを許可すべきです (SHOULD)。

5.3.10 Multicast Routing

IP ルーターは、静的マルチキャスト・ルート、またはマルチキャスト・ルーティング・プロトコル（たとえば DVMRP [ROUTE:9]）によって動的に決定されたルートのいずれかに基づいて、IP マルチキャスト・パケットの転送をサポートすべきです (SHOULD)。IP マルチキャスト・パケットを転送するルーターは、マルチキャスト・ルーターと呼ばれます。

5.3.11 Controls on Forwarding

各物理インタフェースについて、ルーターはそのインタフェースで転送が有効かどうかを指定する設定オプションを持つべきです (SHOULD)。インタフェースでの転送が無効な場合、ルーター:

そのインタフェースで受信されたがルーター宛ではないパケットをすべて暗黙的に廃棄しなければならない (MUST)。
ルーターが発信したデータグラムを除き、そのインタフェースからパケットを送信してはならない (MUST NOT)。
そのインタフェースを通るパスの可用性をいかなるルーティング・プロトコルでもアナウンスしてはならない (MUST NOT)。

DISCUSSION この機能により、ネットワーク管理者は本質的にインタフェースをオフにすることができますが、ネットワーク管理のためにアクセス可能なままにします。

理想的には、この制御は物理インタフェースではなく論理インタフェースに適用されます。それはできません。なぜなら、ルーターが論理インタフェースと物理インタフェースの間に 1 対 1 の対応がない限り、パケットがどの論理インタフェースに到着したかを判断する既知の方法がないためです。

5.3.12 State Changes

ルーターの動作中、インタフェースが故障したり手動で無効化されたり、あるいはルーターが使用可能になることがあります。同様に、特定のインタフェースまたはルーター全体の転送が無効にされたり、（再）有効にされたりすることがあります。このような遷移は（通常）まれですが、ルーターがそれらを正しく処理することが重要です。

5.3.12.1 When a Router Ceases Forwarding

ルーターが転送を停止したとき、それはすべてのルートのアドバタイズを停止しなければなりません (MUST)。ただし、サードパーティ・ルートを除きます。ルーターは、ルーティング・ドメイン内の他のルーターからのルートの受信および使用を継続してもよい (MAY) です。転送データベースが保持されている場合、ルーターは転送データベース内のルートのタイミングを停止してはなりません (MUST NOT)。他のルーターから受信したルートが記憶されている場合、ルーターは記憶したルートのタイミングを停止してはなりません (MUST NOT)。ルーターは、転送が無効な間にタイマが満了したルートを、転送が有効な場合と同様に廃棄しなければなりません (MUST)。

DISCUSSION ルーターが転送を停止すると、それは本質的にルーターであることをやめます。それは依然としてホストであり、Host Requirements [INTRO:2] のすべての要件に従わなければなりません。ただし、ルーターは 1 つ以上のルーティング・ドメインの受動的なメンバーであり続ける可能性があります。そのため、ルーティング・ドメイン内の他のルーターをリッスンすることで転送データベースを維持することが許可されます。しかし、それ自体が転送を行っていないため、転送データベース内のいかなるルートもアナウンスしてはなりません。この規則の唯一の例外は、ルーターが他のルーターのみを使用するルートをアナウンスしているが、このルーターがアナウンスするように求められている場合です。

ルーターは、転送できないパケットの送信元に ICMP 宛先到達不能（host unreachable）メッセージを送信してもよい (MAY) です。ICMP リダイレクト・メッセージを送信すべきではありません (SHOULD NOT)。

DISCUSSION ICMP 宛先到達不能（host unreachable）の送信はルーターのアクションであることに注意してください。このメッセージはホストによって送信されるべきではありません。ホストに対するこの規則の例外は、パケットが可能な限り短い時間で再ルーティングされ、ブラックホールが回避されるように許可されています。

5.3.12.2 When a Router Starts Forwarding

ルーターが転送を開始するとき、通常ルーティング情報を交換するすべてのルーターへの新しいルーティング情報の送信を促進すべきです (SHOULD)。

5.3.12.3 When an Interface Fails or is Disabled

インタフェースが故障または無効化された場合、ルーターはそのインタフェースを使用する転送データベース内のすべてのルートを削除し、アナウンスを停止しなければなりません (MUST)。そのインタフェースを使用するすべての静的ルートを無効にしなければなりません (MUST)。同じ宛先および TOS への他のルートがルーターによって学習または記憶されている場合、ルーターは最良の代替を選択し、転送データベースに追加しなければなりません (MUST)。ルーターは、インタフェースが利用不可であるために転送できないすべてのパケットに対して、適切に、ICMP 宛先到達不能または ICMP リダイレクト・メッセージを送信すべきです (SHOULD)。

5.3.12.4 When an Interface is Enabled

利用不可であったインタフェースが利用可能になった場合、ルーターはそのインタフェースを使用するすべての静的ルートを再有効化しなければなりません (MUST)。そのインタフェースを使用するルートがルーターによって学習された場合、これらのルートは他のすべての学習済みルートと共に評価されなければならず (MUST)、ルーターはどのルートを転送データベースに配置するかを決定しなければなりません (MUST)。この決定の方法についての詳細は、第 [7] 章 Application Layer - Routing Protocols を参照してください。

ルーターは、通常ルーティング情報を交換するすべてのルーターへの新しいルーティング情報の送信を促進すべきです (SHOULD)。

5.3.13 IP Options

Record Route や Timestamp など、いくつかのオプションには、パケットを転送するときにルーターがアドレスを挿入するスロットが含まれています。しかし、そのような各オプションのスロット数は有限であるため、ルーターはアドレスを挿入できる空きスロットがないと判断する場合があります。以下に挙げる要件のいずれも、ルーターにアドレスを挿入する残りスロットのないオプションへのアドレスの挿入を要求するものと解釈されるべきではありません。セクション [5.2.5] は、ルーターがどのアドレスをオプションに挿入するかを選択しなければならない方法を論じています。

5.3.13.1 Unrecognized Options

転送されるパケット内の認識できない IP オプションは、変更せずに通過させなければなりません (MUST)。

5.3.13.2 Security Option

一部の環境では、すべてのパケットに Security オプションが要求されます。そのような要件は本メモおよび IP 標準仕様の範囲外です。ただし、[INTERNET:1] および [INTERNET:16] で説明されたセキュリティ・オプションは廃止されていることに注意してください。ルーターは [INTERNET:5] で説明された改訂セキュリティ・オプションを実装すべきです (SHOULD)。

DISCUSSION 複数のセキュリティ・レベルを持つネットワークで使用することを意図したルーターは、IPSO (RFC-1108) ラベルに基づくパケット・フィルタリングをサポートすべきです。このサポートを実装するために、ルーターはルーター管理者が各インタフェースに下限感度制限（たとえば Unclassified）と上限感度制限（たとえば Secret）の両方を設定できるようにする必要があります。2 つの制限が同じである（たとえば単一レベル・インタフェース）ことが一般的ですが、常にそうとは限りません。IPSO フィルタによって範囲外であると捕捉されたパケットは暗黙的にドロップされ、範囲外の IPSO ラベルによってドロップされたパケットの数をカウンタが記録すべきです。

5.3.13.3 Stream Identifier Option

このオプションは廃止されています。Stream Identifier オプションがルーターによって転送されるパケットに存在する場合、そのオプションは無視され、変更せずに通過させなければなります (MUST)。

5.3.13.4 Source Route Options

ルーターは、転送されるパケット内のソースルート・オプションのサポートを実装しなければなりません (MUST)。ルーターは、有効にしたときにすべてのソースルート付きパケットが廃棄されるようにする設定オプションを実装してもよい (MAY) です。ただし、そのようなオプションはデフォルトで有効化されてはなりません (MUST NOT)。

DISCUSSION インターネットを通じてデータグラムをソースルートする能力は、さまざまなネットワーク診断ツールにとって重要です。しかし、ソースルーティングはネットワーク内の管理およびセキュリティ制御を回避するために使用される可能性があります。具体的には、ルーティング・テーブルの操作がパケット・フィルタリングなどの他の方法に代わる管理的分離を提供するために使用される場合、ソースルート付きパケットによって脆弱になる可能性があります。

EDITORS+COMMENTS パケット・フィルタリングもソースルーティングによって無効にされる可能性があります。それがソースルート・パスの最終区間上のルーター以外のルーターに適用される場合です。ルート・フィルタもパケット・フィルタも、セキュリティに対する完全な解決策を構成するものではありません。

5.3.13.5 Record Route Option

ルーターは、転送されるパケット内の Record Route オプションをサポートしなければなりません (MUST)。

ルーターは、有効にしたときにルーターが転送されるパケット内の Record Route オプションを無視（すなわち変更せずに通過）するようにする設定オプションを提供してもよい (MAY) です。提供される場合、そのようなオプションは record-route を有効にすることをデフォルトとしなければなりません (MUST)。このオプションは、ルーター自身が受信したデータグラム内の Record Route オプションの処理に影響を与えるべきではありません（特に、ICMP echo 要求内の Record Route オプションはセクション [4.3.3.6] に従って引き続き処理されます）。

DISCUSSION Record Route はネットワークのトポロジに関する情報を開示するため、セキュリティ上の問題であると考える人々がいます。したがって、本メモはそれを無効にすることを許可しています。

5.3.13.6 Timestamp Option

ルーターは、転送されるパケット内の timestamp オプションをサポートしなければなりません (MUST)。timestamp 値は [INTRO:2] で与えられた規則に従わなければなりません (MUST)。

flags フィールド = 3（timestamp and prespecified address）の場合、次の事前指定アドレスがルーターの IP アドレスのいずれかと一致すれば、ルーターはそのタイムスタンプを追加しなければなりません (MUST)。事前指定アドレスが、パケットが到着したインタフェースのアドレスまたはそれが送信されるインタフェースのアドレスのいずれかである必要はありません。

IMPLEMENTATION timestamp オプションに含まれるタイムスタンプの有用性を最大化するために、挿入されるタイムスタンプは、実用上可能な限り、パケットがルーターに到着した時刻であることが推奨されます。ルーターが発信したデータグラムの場合、挿入されるタイムスタンプは、実用上可能な限り、データグラムが送信のためにネットワーク層に渡された時刻であるべきです。

ルーターは、フラグ・ワードがゼロ（timestamps only）または 1（timestamp and registering IP address）に設定されているときに、転送されるデータグラム内の Timestamp オプションを無視（すなわち変更せずに通過）するようにする設定オプションを提供してもよい (MAY) です。提供される場合、そのようなオプションはオフ（すなわちルーターはタイムスタンプを無視しない）をデフォルトとしなければなりません (MUST)。このオプションは、ルーター自身が受信したデータグラム内の Timestamp オプションの処理に影響を与えるべきではありません（特に、ルーターが受信したデータグラム内の Timestamp オプションにタイムスタンプを挿入し、ICMP echo 要求内の Timestamp オプションはセクション [4.3.3.6] に従って引き続き処理されます）。

DISCUSSION Record Route オプションと同様に、Timestamp オプションはネットワークのトポロジに関する情報を開示できます。一部の人々はこれをセキュリティ上の懸念と見なしています。

6. Transport Layer (トランスポート層)

ルーターは、ルーターがサポートするアプリケーション層プロトコルをサポートするために要求されるものを除き、いかなるトランスポート層プロトコルも実装する必要はありません。実際には、これはほとんどのルーターが Transmission Control Protocol (TCP) と User Datagram Protocol (UDP) の両方を実装することを意味します。

6.1 User Datagram Protocol - UDP

User Datagram Protocol (UDP) は [TRANS:1] で規定されています。

UDP を実装するルーターは、[INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。ただし、次の点を除きます:

本仕様は各プロトコル層間のインタフェースを規定しません。したがって、ルーターのインタフェースは [INTRO:2] に準拠する必要はありません。ただし、ルーターがサポートするアプリケーション層プロトコルの適切な機能のために準拠が要求される場合を除きます。
[INTRO:2] とは逆に、アプリケーションは UDP チェックサムの生成を無効にすべきではありません (SHOULD NOT)。

DISCUSSION 特定のアプリケーション・プロトコルは、それが受信する UDP データグラムに UDP チェックサムが含まれていることを要求する場合がありますが、受信した UDP データグラムに UDP チェックサムが含まれているという一般的な要件はありません。もちろん、受信したデータグラムに UDP チェックサムが存在する場合、チェックサムを検証しなければならず、チェックサムが正しくない場合はデータグラムを廃棄しなければなりません。

6.2 Transmission Control Protocol - TCP

Transmission Control Protocol (TCP) は [TRANS:2] で規定されています。

TCP を実装するルーターは、[INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。ただし、次の点を除きます:

本仕様は各プロトコル層間のインタフェースを規定しません。したがって、ルーターは [INTRO:2] の次の要件に準拠する必要はありません（もちろん、ルーターがサポートするアプリケーション層プロトコルの適切な機能のために準拠が要求される場合を除く）:
- Use of Push: RFC-793 Section 2.8: 受信した PSH フラグをアプリケーション層に渡すことは現在 OPTIONAL です。
- Urgent Pointer: RFC-793 Section 3.1: TCP は、緊急ポインタを受信し、以前に保留中の緊急データがなかった場合、または緊急ポインタがデータ・ストリーム内で進んだ場合、常にアプリケーション層に非同期に通知しなければなりません (MUST)。接続から読み取るべき緊急データがどれだけ残っているか、あるいは少なくともそれ以上の緊急データが残っているかどうかをアプリケーションが判断できる手段が存在しなければなりません (MUST)。
- TCP Connection Failures: アプリケーションは特定の接続に対する R2 の値を設定できる必要があります (MUST)。たとえば、インタラクティブなアプリケーションは R2 を「infinity（無限大）」に設定し、ユーザーにいつ切断するかを制御させる場合があります。
- TCP Multihoming: マルチホーム・ホスト上のアプリケーションがアクティブに TCP 接続を開くときにローカル IP アドレスを指定しない場合、TCP は（最初の）SYN を送信する前に IP 層にローカル IP アドレスを選択するよう要求しなければなりません (MUST)。セクション 3.4 の関数 GET_SRCADDR() を参照してください。
- IP Options: アプリケーションは、アクティブに TCP 接続を開くときにソースルートを指定できなければならず (MUST)、これはデータグラムで受信したソースルートよりも優先されなければなりません (MUST)。
同様の理由から、ルーターは [INTRO:2] のいかなる要件にも準拠する必要はありません。
[INTRO:2] の Maximum Segment Size Option に関する要件は次のように修正されます: 本メモのセクション [4.2.3.3] で論じた MTU 発見のホスト部分を実装するルーターは、パス MTU が不明な場合にのみ、SendMSS のデフォルト値として 536 を使用します。パス MTU が既知の場合、SendMSS のデフォルト値はパス MTU - 40 です。
[INTRO:2] の Maximum Segment Size Option に関する要件は次のように修正されます: ICMP Destination Unreachable コード 11 および 12 は追加のソフト・エラー条件です。したがって、これらのメッセージは TCP に接続を中止させてはなりません (MUST NOT)。

DISCUSSION ルーター内の TCP 実装は、[INTRO:2] の次の要件に準拠しなければならないことに特に注意してください:

設定可能な TTL の提供。[Time to Live: RFC-793 Section 3.9]
keep-alive 動作を設定するインタフェースの提供（keep-alive を使用する場合）。[TCP Keep-Alives]
エラー報告メカニズムとそれを管理する能力の提供。[Asynchronous Reports]
タイプ・オブ・サービスの指定。[Type-of-Service]

適用される一般的なパラダイムは、特定のインタフェースがルーターの外側に見える場合、インタフェースに対するすべての要件に従わなければならないということです。たとえば、ルーターが telnet 機能を提供する場合、それはトラフィックを生成し、外部ネットワークでルーティングされる可能性が高くなります。したがって、タイプ・オブ・サービスを正しく設定できる必要があり、さもないと telnet トラフィックが通過しない可能性があります。

6.3 INTERNET LAYER PROTOCOLS AND THE TRANSPORT LAYER

Internet Protocol (IP) およびその制御プロトコルである Internet Control Message Protocol (ICMP) と Internet Group Management Protocol (IGMP) は、実際にはインターネット層の一部です。前述のように、ルーターは IP を実装しなければならず (MUST)、また ICMP および IGMP を実装しなければなりません (MUST)。

7. APPLICATION LAYER - ROUTING PROTOCOLS (アプリケーション層 - ルーティング・プロトコル)

7.1 INTRODUCTION (導入)

技術的、管理的、そして時には政治的 reason により、インターネットのルーティング・システムは 2 つのコンポーネント - 内部ルーティングと外部ルーティング - から構成されます。本ドキュメントのセクション 2.2.4 で定義された自律システム (AS) の概念は、内部ルーティングと外部ルーティングを分離する上で重要な役割を果たします。この概念により、内部から外部へのルーティングへの変化が発生するルーターの集合を描画できるためです。IP データグラムは、宛先に到達するために 2 つ以上の自律システムのルーターを通過しなければならない場合があり、自律システムはそのような転送を可能にするために互いにトポロジ情報を提供しなければなりません。内部ゲートウェイ・プロトコル (IGP) は、AS 内（すなわち AS 内ルーティング）でルーティング情報を配布するために使用されます。外部ゲートウェイ・プロトコルは、AS 間（すなわち AS 間ルーティング）でルーティング情報を交換するために使用されます。

7.1.1 Routing Security Considerations (ルーティング・セキュリティ上の考慮事項)

ルーティングは、Robustness Principle（受け入れるものには寛容であれ）が適用されない数少ない領域の 1 つです。ルーターは、他のルーティング・システムからのルーティング・データを受け入れる際には、比較的疑わしげに振る舞うべきです (SHOULD)。

ルーターは、ルーティング情報源を最も信頼できるものから最も信頼できないものへとランク付けし、特定の宛先に関するルーティング情報を最も信頼できるソースから最初に受け入れる能力を提供すべきです (SHOULD)。これは、EGP およびさまざまな内部ルーティング・プロトコルを使用する元のコア/スタブ自律システム・ルーティング・モデルでは暗黙的でした。中央の信頼されたコアが姿を消した今、これはさらに重要です。

ルーターは、明らかに無効なルート（ネット 127 などのもの）をフィルタリングで除去するメカニズムを提供すべきです (SHOULD)。

ルーターは、デフォルトで、自らが使用、信頼、またはそれ以外に有効と見なさないルーティング・データを再配布してはなりません (MUST NOT)。まれに、疑わしい情報を再配布する必要がある場合がありますが、これは一部の人間の機関による直接的な仲介の下でのみ発生すべきです。

ルーターは、誰からのルーティング・データを受け入れることについて少なくとも少しは偏執的でなければならず (MUST)、別の当事者から提供されたルーティング情報を配布する際には特に注意しなければなりません (MUST)。具体的なガイドラインについては以下を参照してください。

7.1.2 Precedence (優先順位)

特定のルーティング・プロトコルの仕様で別途規定する場合を除き、ルーターは、自ら発信するルーティング・トラフィックを運ぶ IP データグラムの IP Precedence 値を 6（INTERNETWORK CONTROL）に設定すべきです (SHOULD)。

DISCUSSION ごくわずかな例外を除き、ルーティング・トラフィックはあらゆるネットワーク上で最も高い優先順位のトラフィックであるべきです。システムのルーティング・トラフィックが通過できない場合、他のものもおそらく通過しないでしょう。

7.1.3 Message Validation (メッセージ検証)

ピア・ツー・ピア認証にはいくつかのテストが伴います。メッセージ・パスワードと明示的な許容隣接リストの適用は、過去にルート・データベースの堅牢性を向上させてきました。ルーターは、有効なルーティング隣接を明示的にリスト化できる管理制御を実装すべきです (SHOULD)。ルーターは、それらをサポートするルーティング・プロトコルに対してピア・ツー・ピア認証を実装すべきです (SHOULD)。

ルーターは、送信元アドレスとメッセージを受信したインタフェースに基づいてルーティング隣接を検証すべきです (SHOULD)。直接接続されたサブネット内の隣接は、そのサブネットが想定されるインタフェース、または番号なしインタフェースを介してのみルーターと通信するように制限されるべきです (SHOULD)。他のインタフェースで受信されたメッセージは暗黙的に廃棄されるべきです (SHOULD)。

DISCUSSION この基本的なテストにより、セキュリティ侵害や多数のルーティング問題が回避されます。

7.2 INTERIOR GATEWAY PROTOCOLS (内部ゲートウェイ・プロトコル)

7.2.1 INTRODUCTION (導入)

内部ゲートウェイ・プロトコル (IGP) は、特定の AS 内のさまざまなルーター間でルーティング情報を配布するために使用されます。特定の IGP の実装に使用されるアルゴリズムにかかわらず、次の機能を実行する必要があります:

(1) AS の内部トポロジの変化に迅速に応答する (2) 回線のフラッピングが継続的なルーティング更新を引き起こさないようにするメカニズムを提供する (3) ループ・フリーなルーティングへの迅速な収束を提供する (4) 最小限の帯域幅を利用する (5) 負荷分割を可能にする等コスト・ルートを提供する (6) ルーティング更新の認証手段を提供する

現在インターネットで使用されている IGP は、距離ベクトル・アルゴリズムベースかリンク状態アルゴリズムベースのいずれかであると特徴付けられます。

このセクションでは、最も一般的に使用されているものと、将来広く使用される可能性のある最近開発されたプロトコルのいくつかを含む、いくつかの IGP について詳述します。AS 内ルーティングでの使用を意図した他の多数のプロトコルがインターネット・コミュニティに存在します。

（静的ルート以外の）ルーティング・プロトコルを実装するルーターは、OSPF を実装しなければなりません (MUST)（セクション [7.2.2] 参照）。ルーターは追加の IGP を実装してもよい (MAY) です。

7.2.2 OPEN SHORTEST PATH FIRST - OSPF

最短経路優先 (SPF) ベースのルーティング・プロトコルは、Dijkstra の最短経路アルゴリズムに基づくリンク状態アルゴリズムのクラスです。SPF ベースのアルゴリズムは ARPANET 創設以来存在していますが、IP および OSI コミュニティの両方で人気を得たのは最近になってからです。SPF ベースのシステムでは、各ルーターはフラッディングと呼ばれるプロセスを通じて完全なトポロジ・データベースを取得します。フラッディングは情報の信頼できる転送を保証します。各ルーターはその後、データベースで SPF アルゴリズムを実行して IP ルーティング・テーブルを構築します。OSPF ルーティング・プロトコルは SPF アルゴリズムの実装です。現在のバージョンである OSPF バージョン 2 は [ROUTE:1] で規定されています。OSPF バージョン 1 を説明する RFC-1131 は廃止されていることに注意してください。

本メモのセクション [8.3] に準拠するため、OSPF を実装するルーターは OSPF MIB [MGT:14] を実装しなければならないことに注意してください。

7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - DUAL IS-IS

米国規格協会 (ANSI) X3S3.3 委員会は、ドメイン内ルーティング・プロトコルを定義しました。このプロトコルは Intermediate System to Intermediate System Routeing Exchange Protocol と題されています。

その IP ネットワークへの適用は [ROUTE:2] で定義されており、Dual IS-IS（または Integrated IS-IS と呼ばれることもある）と呼ばれます。IS-IS はリンク状態 (SPF) ルーティング・アルゴリズムに基づいており、このクラスのプロトコルが持つすべての利点を共有しています。

7.3 EXTERIOR GATEWAY PROTOCOLS (外部ゲートウェイ・プロトコル)

7.3.1 INTRODUCTION (導入)

外部ゲートウェイ・プロトコルは、AS 間ルーティングに利用され、特定の自律システムの内部のネットワークの集合の到達可能性情報を隣接する自律システムに交換します。

AS 間ルーティングの分野は、インターネット技術タスク・フォース内の現在の研究トピックです。セクション [Appendix F.1] で説明された Exterior Gateway Protocol (EGP) は伝統的に AS 間プロトコルの選択でしたが、現在は歴史的なものです。Border Gateway Protocol (BGP) は EGP の多くの制限と制約を排除しており、そのため人気が急速に高まっています。ルーターはいかなる AS 間ルーティング・プロトコルも実装することを要求されません。ただし、ルーターが EGP を実装する場合、BGP も実装しなければなりません (MUST)。EGP として設計されたものではありませんが、RIP（セクション [7.2.4] で説明）は、AS 間ルーティングに使用されることがあります。

7.3.2 BORDER GATEWAY PROTOCOL - BGP

7.3.2.1 Introduction (導入)

Border Gateway Protocol (BGP-4) は、他の BGP スピーカーとネットワーク到達可能性情報を交換する AS 間ルーティング・プロトコルです。ネットワークの情報には、そのネットワークに到達するためにトラフィックが通過しなければならない AS の完全なリストが含まれます。この情報は、ループ・フリーなパスの保証に使用できます。この情報は、AS 接続性のグラフを構築するのに十分であり、そこからルーティング・ループを剪定し、AS レベルでのいくつかのポリシー決定を実施できます。

BGP は [ROUTE:4] で定義されています。[ROUTE:5] はインターネットでの BGP の適切な使用法を規定し、有用な実装のヒントとガイドラインを提供しています。[ROUTE:12] および [ROUTE:13] は追加の有用な情報を提供しています。

本メモのセクション [8.3] に準拠するため、BGP を実装するルーターは BGP MIB [MGT:15] を実装することが要求されます。

BGP を使用して実施できるポリシー決定の集合を特徴付けるには、AS が隣接 AS にアナウンスするのは自らが使用するルートのみであるという規則に焦点を当てる必要があります。この規則は、現在のインターネット全体で一般的に使用されているホップ・バイ・ホップのルーティング・パラダイムを反映しています。一部のポリシーはホップ・バイ・ホップのルーティング・パラダイムではサポートできず、したがってソースルーティングなどの技法を実施するために要求することに注意してください。たとえば、BGP は、ある AS がトラフィックを隣接 AS に送信し、そのトラフィックが隣接 AS から発信されたトラフィックとは異なるルートをとることを意図することを可能にしません。一方、BGP はホップ・バイ・ホップのルーティング・パラダイムに準拠するポリシーをサポートできます。

BGP の実装者は、[ROUTE:5] のセクション 6 で概説された推奨事項に従うことが強く推奨されます。

7.3.2.2 Protocol Walk-through (プロトコル通覧)

BGP はかなり複雑なルーティング・ポリシー（例として [ROUTE:5] のセクション 4.2 を参照）のサポートを提供しますが、すべての BGP 実装者がそのようなポリシーをサポートすることを要求されるわけではありません。しかし、最低限、BGP 実装は次のとおりです:

(1) AS が隣接 AS への BGP 学習ルートのアナウンスを制御できるようにすべきです (SHOULD)。実装は、少なくとも単一ネットワークの粒度でそのような制御をサポートすべきです (SHOULD)。実装はまた、自律システムの粒度でそのような制御をサポートすべきです (SHOULD)。ここで自律システムとは、ルートを発信した自律システム、またはローカル・システムにルートをアナウンスした自律システム（隣接自律システム）のいずれかです。

(2) AS が宛先への特定のパスを優先できるようにすべきです (SHOULD)（複数のパスが利用可能な場合）。そのような機能は、システム管理者が自律システムに重みを割り当て、ルート選択プロセスが最小の重みを持つルートを選択するように実装されるべきです (SHOULD)（ここでルートの重みとは、そのルートに関連付けられた AS_PATH パス属性内のすべての AS の重みの合計として定義されます）。

(3) AS が AS_PATH パス属性内の特定の AS を持つルートを無視できるようにすべきです (SHOULD)。そのような機能は、(2) で概説された技法、およびそのような AS に無限大を重みとして割り当てることによって実装できます。ルート選択プロセスは、重みが無限大に等しいルートを無視しなければなりません (MUST)。

7.3.3 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL (外部プロトコルなしの AS 間ルーティング)

2 つの自律システムまたはルーティング・ドメイン間で、2 つの別個の標準内部ルーティング・プロトコル間で標準的な外部ルーティング・プロトコルを使用せずにルーティング情報を交換することは可能です。

7.4 STATIC ROUTING (静的ルーティング)

静的ルーティングは、特定の宛先に対するルーターからのネクストホップを明示的に定義する手段を提供します。ルーターは、宛先がネットワーク・プレフィックスによって定義される静的ルートを定義する手段を提供すべきです (SHOULD)。メカニズムは、各静的ルートにメトリクスを指定できるようにすべきです (SHOULD)。

動的ルーティング・プロトコルをサポートするルーターは、使用されるルーティング・プロトコルに対して有効な任意のメトリクスで静的ルートを定義できるようにしなければなりません (MUST)。ルーターは、ルーティング・プロトコルを通じて伝播される場合とされない場合がある静的ルートのリストをユーザーが指定できる能力を提供しなければなりません (MUST)。さらに、ルーターは、情報を利用できるルーティング・プロトコルをサポートする場合、次の追加情報をサポートすべきです (SHOULD)。それらは:

TOS
サブネット・マスク
プレフィックス長
ルートをインポートできる特定のルーティング・プロトコルに固有のメトリクス

DISCUSSION 私たちは、特定のルーティング・プロトコルに有用なもののみをサポートすればよいことを意図しています。TOS が必要であっても、使用されていない他の部分をベンダーに実装させるべきではありません。

ルーターが静的ルートを動的ルートより優先するか（またはその逆）、あるいは関連するメトリクスが競合する静的ルートと動的ルートの間の選択に使用されるかは、各静的ルートごとに設定可能であるべきです (SHOULD)。

ルーターは、サポートする各ルーティング・ドメインに対して静的ルートにメトリクスを割り当てできるようにしなければなりません (MUST)。そのような各メトリクスは特定のルーティング・ドメインに明示的に割り当てられなければなりません (MUST)。例:

route 10.0.0.0/8 via 192.0.2.3 rip metric 3

route 10.21.0.0/16 via 192.0.2.4 ospf inter-area metric 27

route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99

DISCUSSION 静的ルートは、メトリクスではなくプリファレンス値を持つべきである（メトリクスは同じルーティング・ドメイン内の他のルートのメトリクスとしか比較できないため、静的ルートのメトリクスは他の静的ルートのメトリクスとのみ比較できる）ということが提案されています。これは、静的ルートが実際にメトリクスを持ち、それらのメトリクスが特定の動的ルートが同じ宛先への静的ルートを上書きするかどうかを決定するために使用される現在の一部の実装と相反します。したがって、本ドキュメントはプリファレンスではなくメトリクスという用語を使用します。

この技法は本質的に、静的ルートを RIP ルート、または OSPF ルート（あるいはメトリクスのドメインに応じてその他）にします。したがって、そのドメインのルート検索アルゴリズムが適用されます。しかし、これはルート漏洩 (route leaking) ではありません。なぜなら、静的ルートを動的ルーティング・ドメインに強制しても、ルーターがそのルートを動的ルーティング・ドメインに再配布することを許可するものではないからです。

特定のルーティング・ドメインに投入されない静的ルートの場合、ルート検索アルゴリズムは次のとおりです:

(1) 基本一致 (Basic match) (2) 最長一致 (Longest match) (3) 弱 TOS (Weak TOS)（TOS がサポートされる場合） (4) 最良メトリクス (Best metric)（メトリクスが実装定義の場合）

最後のステップは不要かもしれませんが、1 つのインタフェース上のプライマリ静的ルートと代替インタフェース上のセカンダリ静的ルートを持ち、プライマリ・ルートのインタフェースが故障した場合に代替パスへフェイルオーバーしたい場合に有用です。

7.5 FILTERING OF ROUTING INFORMATION (ルーティング情報のフィルタリング)

ネットワーク内の各ルーターは、その転送データベース内に含まれる情報に基づいて転送決定を行います。単純なネットワークでは、データベースの内容は静的に設定される場合があります。ネットワークがより複雑になるにつれて、転送データベースの動的更新の必要性は、ネットワークの効率的な運用にとって重要になります。

ネットワークを通るデータ・フローを可能な限り効率的にするには、ルーターが転送データベースの構築に使用する情報の伝播を制御するメカニズムを提供することが必要です。この制御は、どのルーティング情報源を信頼すべきか、および情報のどの部分を信じるかを選択するという形式をとります。結果として得られる転送データベースは、利用可能なルーティング情報のフィルタリングされたバージョンです。

効率性に加えて、ルーティング情報の伝播を制御することで、正しくないまたは悪いルーティング情報の拡散を防ぐことによって不安定性を減らすことができます。

一部のケースでは、ローカル・ポリシーが、完全なルーティング情報を広く伝播することを要求しない場合があります。

これらのフィルタリング要件は、SPF ベースでないプロトコルにのみ適用されます（したがって、距離ベクトル・プロトコルを実装しないルーターにはまったく適用されません）。

7.5.1 Route Validation (ルート検証)

ルーターは、本メモの仕様に違反するルートをアドバタイズするルーティング更新をエラーとしてログに記録すべきです (SHOULD)。ただし、更新を受信したルーティング・プロトコルがそれらの値を特別なルート（デフォルト・ルートなど）の符号化に使用している場合を除きます。

7.5.2 Basic Route Filtering (基本ルート・フィルタリング)

ルーティング情報のフィルタリングにより、ルーターが受信したパケットを転送するために使用するパスの制御が可能になります。ルーターは、どのルーティング情報源をリッスンするか、およびどのルートを信じるかを選択的に行うべきです。したがって、ルーターは次を指定する能力を提供しなければなりません (MUST):

ルーティング情報が受け入れられる論理インタフェース、および各論理インタフェースからどのルートが受け入れられるか。
論理インタフェース上で、すべてのルートがアドバタイズされるか、デフォルト・ルートのみがアドバタイズされるか。

一部のルーティング・プロトコルは、ルーティング情報の源として論理インタフェースを認識しません。そのような場合、ルーターは次を指定する能力を提供しなければなりません (MUST):

どの他のルーターからルーティング情報が受け入れられるか。

たとえば、1 つ以上のリーフ・ネットワークをより大きなネットワークの主要部分またはバックボーンに接続するルーターを想定します。各リーフ・ネットワークには出入りするパスが 1 つしかないため、ルーターは単にデフォルト・ルートをそれらに送信できます。それはリーフ・ネットワークをメイン・ネットワークにアドバタイズします。

7.5.3 Advanced Route Filtering (高度ルート・フィルタリング)

ネットワークのトポロジがより複雑になるにつれて、より複雑なルート・フィルタリングの必要性が生じます。したがって、ルーターは各ルーティング・プロトコルごとに独立して指定する能力を提供すべきです (SHOULD):

どの論理インタフェースまたはルーターからルーティング情報（ルート）が受け入れられ、各他のルーターまたは論理インタフェースからどのルートが信じられるか。
どのルートがどの論理インタフェース（群）を介して送信されるか。
ルーティング情報がどのルーターに送信されるか（これが使用されるルーティング・プロトコルでサポートされる場合）。

多くの状況で、上記の最初の箇条書きにリストされた単純な信じる/信じないの選択ではなく、別のルーターから受信したルーティング情報に信頼性順序を割り当てることが望ましいです。ルーターは次を指定する能力を提供してもよい (MAY) です:

受信した各ルートに割り当てられる信頼性またはプリファレンス。より高い信頼性を持つルートは、各ルートに関連付けられたルーティング・メトリクスに関わらず、より低い信頼性を持つルートよりも優先して選択されます。

ルーターがプリファレンスの割り当てをサポートする場合、ルーターは、自らが第 1 者情報として好まないルートを伝播してはなりません (MUST NOT)。ルートを伝播するために使用されるルーティング・プロトコルが第 1 者情報と第 3 者情報の区別をサポートしない場合、ルーターは自らが好まないルートを伝播してはなりません (MUST NOT)。

DISCUSSION たとえば、ルーターがルーター R からネットワーク C へのルートと、ルーター S から同じネットワークへのルートを受信したと仮定します。ルーター R がルーター S よりも信頼できると見なされる場合、ネットワーク C 宛のトラフィックは、ルーター S から受信したルートに関わらず、ルーター R に転送されます。

ルーターが使用しないルートのルーティング情報（上記の例のルーター S）は、他のルーターに渡してはなりません (MUST NOT)。

7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE (ルーティング・プロトコル間情報交換)

独立した IP ルーティング・プロセスを同じルーター内で実行できる場合、ルーターは別個の IP 内部ルーティング・プロトコル間でルーティング情報を交換できなければなりません (MUST)。ルーターは、2 つの別個の内部ルーティング・プロセス間で双方向のルーティング情報交換が設定されている場合にルーティング・ループを回避するための何らかのメカニズムを提供しなければなりません (MUST)。ルーターは、独立したルーティング・プロセスからルートを選択するための何らかの優先順位メカニズムを提供しなければなります (MUST)。ルーターは、管理境界を越えて使用される場合の IGP-IGP 交換の管理制御を提供すべきです (SHOULD)。

ルーターは、ネットワークごとにメトリクスを変換または変形する何らかのメカニズムを提供すべきです (SHOULD)。ルーター（またはルーティング・プロトコル）は、IGP にインポートされた外部ルートのグローバルなプリファレンスを許可してもよい (MAY) です。

DISCUSSION 異なる IGP は異なるメトリクスを使用するため、あるプロトコルからメトリクスの形式が異なる別のプロトコルに情報を導入する際に何らかの変換技法が必要です。一部の IGP は同じルーターまたはルーターの集合内で複数のインスタンスを実行できます。この場合、メトリクス情報は正確に保持することも変換することもできます。

異なるルーティング・プロセス間の変換技法は少なくとも 2 つあります。静的（または到達可能性）アプローチは、ある IGP でのルート・アドバタイズの存在を使用して、指定されたメトリクスを持つ別の IGP でルート・アドバタイズを生成します。変換または表参照アプローチは、ある IGP のメトリクスを使用して、何らかの手段（一方が他方のメトリクスの正確な関数であるか、または変換テーブルが使用されるかのいずれか）を通じて、別の IGP でメトリクスを作成します。

DISCUSSION ルーティング情報の双方向交換は、フィードバックを制限する制御メカニズムがないと危険です。これは、距離ベクトル・ルーティング・プロトコルがスプリット・ホライゾン技法で対処しなければならない問題、および EGP が第 3 者規則で対処する問題と同じです。ルーティング・ループは、許可/拒否されたルートの表またはリストを使用して明示的に、またはスプリット・ホライゾン規則、ノー・サード・パーティ規則、またはルート・タギング・メカニズムを使用して暗黙的に回避できます。ベンダーは、ネットワーク運用者にとって管理を容易にするため、可能な場合は暗黙的な技法を使用することが推奨されます。

8. APPLICATION LAYER - NETWORK MANAGEMENT PROTOCOLS (アプリケーション層 - ネットワーク管理プロトコル)

この章は [INTRO:3] の「REMOTE MANAGEMENT」で規定された要件に優先することに注意してください。

8.1 The Simple Network Management Protocol - SNMP

8.1.1 SNMP Protocol Elements

ルーターは SNMP [MGT:3] によって管理可能でなければなりません (MUST)。SNMP はトランスポートおよびネットワーク・プロトコルとして UDP/IP を使用して動作しなければなりません (MUST)。その他のものもサポートされてよい (MAY) です（[MGT:25, MGT:26, MGT:27, MGT:28] 参照）。

管理操作は、SNMP がルーター自身に実装されているかのように動作しなければなりません (MUST)。具体的には、管理操作は、ルーターのインタフェースのいずれかに割り当てられたルーターの IP アドレスのいずれかに対して SNMP 管理要求を送信することによって実行されなければなります (MUST)。実際の管理操作は、ルーター自身、またはルーターのプロキシのいずれかによって実行されてよい (MAY) です。

DISCUSSION この文言は、プロキシによる管理（プロキシ装置がパケットの宛先アドレス・フィールドにルーターの IP アドレスの 1 つを持つ SNMP パケットに応答する）と、SNMP がルーター自身に直接実装され、パケットを受信して適切な方法で応答する管理の両方を許可することを意図しています。

管理操作をルーターの IP アドレスの 1 つに送信できることは重要です。ネットワーク問題を診断する際、利用可能なルーターを識別する唯一のものはルーターの IP アドレスの 1 つである場合があります（おそらく別のルーターのルーティング・テーブルを調べることで得られたものです）。

すべての SNMP 操作（get、get-next、get-response、set、および trap）を実装しなければなりません (MUST)。

ルーターは、SNMP trap メッセージの生成をレート制限するメカニズムを提供しなければなりません (MUST)。ルーターは、[MGT:5] で説明された非同期アラート管理のアルゴリズムを通じてこのメカニズムを提供してもよい (MAY) です。

DISCUSSION trap をレート制限すべきという一般的な合意はありますが、それを最良に達成する方法についての合意はまだありません。引用された参考資料は実験的と見なされています。

8.2 Community Table

本仕様の目的上、ルーター内に抽象的な「コミュニティ・テーブル」が存在すると仮定します。このテーブルにはいくつかのエントリが含まれ、各エントリは特定のコミュニティに対するもので、そのコミュニティの属性を完全に定義するために必要なパラメータを含みます。抽象的なコミュニティ・テーブルの実際の実装方法は、もちろん実装固有です。

ルーターのコミュニティ・テーブルは、少なくとも 1 つのエントリを許可しなければならず (MUST)、少なくとも 2 つのエントリを許可すべきです (SHOULD)。

DISCUSSION 容量ゼロのコミュニティ・テーブルは無用です。それは、ルーターがいかなるコミュニティも認識せず、したがってすべての SNMP 操作が拒否されることを意味します。したがって、1 つのエントリがテーブルの最小有用サイズです。2 つのエントリを持つことで、1 つのエントリを読み取り専用アクセスに限定し、もう 1 つを書き込み能力を持たせることができます。

ルーターは、ユーザーが SNMP を使用せずに、SNMP コミュニティ・テーブルのエントリを手動で調査、追加、削除、および変更できるようにしなければなりません (MUST)。ユーザーはコミュニティ名を設定または MIB ビューを構築できなければなりません (MUST)。ユーザーは、コミュニティを読み取り専用（すなわち SET を許可しない）または読み書き可能（すなわち SET を許可する）として設定できる必要があります (MUST)。

ユーザーは、trap が使用される場合、各コミュニティまたは MIB ビューに対して通知が送信される少なくとも 1 つの IP アドレスを定義できなければなりません (MUST)。これらのアドレスはコミュニティまたは MIB ビューごとに定義可能であるべきです (SHOULD)。通知をコミュニティまたは MIB ビューごとに有効または無効にできることが望ましいです (SHOULD)。

ルーターは、特定のコミュニティに対して有効なネットワーク管理者のリストを指定する能力を提供すべきです (SHOULD)。有効化されている場合、ルーターは SNMP データグラムの送信元アドレスをリストに対して検証しなければならず (MUST)、そのアドレスが現れない場合はデータグラムを廃棄しなければなりません (MUST)。データグラムが廃棄された場合、ルーターは SNMP 認証失敗に対して適切なすべてのアクションを実行しなければなりません (MUST)。

DISCUSSION これはかなり限られた認証システムですが、さまざまな形態のパケット・フィルタリングと組み合わせることで、わずかながらセキュリティを向上させる可能性があります。

コミュニティ・テーブルは不揮発性ストレージに保存されなければなりません (MUST)。

コミュニティ・テーブルの初期状態には、コミュニティ名文字列 public および読み取り専用アクセスを持つ 1 つのエントリが含まれるべきです (SHOULD)。このエントリのデフォルト状態は trap を送信してはならず (MUST NOT)、実装されている場合、このエントリは管理者がそれを変更または削除するまでコミュニティ・テーブルに残らなければなりません (MUST)。

DISCUSSION デフォルトでは、trap はこのコミュニティに送信されません。Trap PDU はユニキャスト IP アドレスに送信されます。このアドレスは何らかの方法でルーターに設定されなければなりません。設定が行われる前はそのようなアドレスがないため、trap は誰に送信されるべきでしょうか。したがって、public コミュニティへの trap 送信はデフォルトで無効になります。これはもちろん、ルーターが稼働した後に管理操作によって変更できます。

8.3 Standard MIBS

ルーターの設定に関連するすべての MIB を実装する必要があります。すなわち:

MIB-II [MGT:2] の System、Interface、IP、ICMP、および UDP グループを実装しなければなりません (MUST)。
Interface Extensions MIB [MGT:18] を実装しなければなりません (MUST)。
IP Forwarding Table MIB [MGT:20] を実装しなければなりません (MUST)。
ルーターが TCP（Telnet 用など）を実装する場合、MIB-II [MGT:2] の TCP グループを実装しなければなりません (MUST)。
ルーターが EGP を実装する場合、MIB-II [MGT:2] の EGP グループを実装しなければなりません (MUST)。
ルーターが OSPF をサポートする場合、OSPF MIB [MGT:14] を実装しなければなりません (MUST)。
ルーターが BGP をサポートする場合、BGP MIB [MGT:15] を実装しなければなりません (MUST)。
ルーターが Ethernet、802.3、または StarLan インタフェースを持つ場合、Ethernet-Like MIB [MGT:6] を実装しなければなりません (MUST)。
ルーターが 802.4 インタフェースを持つ場合、802.4 MIB [MGT:7] を実装しなければなりません (MUST)。
ルーターが 802.5 インタフェースを持つ場合、802.5 MIB [MGT:8] を実装しなければなりません (MUST)。
ルーターが ANSI SMT 7.3 を実装する FDDI インタフェースを持つ場合、FDDI MIB [MGT:9] を実装しなければなりません (MUST)。
ルーターが ANSI SMT 6.2 を実装する FDDI インタフェースを持つ場合、FDDI MIB [MGT:29] を実装しなければなりません (MUST)。
ルーターが RS-232、V.10、V.11、V.35、V.36、または RS-422/423/449 などの V.24 シグナリングを使用するインタフェースを持つ場合、RS-232 [MGT:10] MIB を実装しなければなりません (MUST)。
ルーターが T1/DS1 インタフェースを持つ場合、T1/DS1 MIB [MGT:16] を実装しなければなりません (MUST)。
ルーターが T3/DS3 インタフェースを持つ場合、T3/DS3 MIB [MGT:17] を実装しなければなりません (MUST)。
ルーターが SMDS インタフェースを持つ場合、SMDS Interface Protocol MIB [MGT:19] を実装しなければなりません (MUST)。
ルーターがそのインタフェースのいずれかで PPP をサポートする場合、PPP MIB [MGT:11]、[MGT:12]、および [MGT:13] を実装しなければなりません (MUST)。
ルーターが RIP Version 2 をサポートする場合、RIP Version 2 MIB [MGT:21] を実装しなければなりません (MUST)。
ルーターがそのインタフェースのいずれかで X.25 をサポートする場合、X.25 MIB [MGT:22, MGT:23, MGT:24] を実装しなければなりません (MUST)。

8.4 Vendor Specific MIBS

インターネット標準および実験的 MIB は、ネットワーク要素で利用可能な統計、状態、設定、および制御情報の全範囲をカバーするものではありません。しかし、この情報は極めて有用です。ルーター（およびその他のネットワーク装置）のベンダーは一般に、この情報をカバーする MIB 拡張を開発しています。これらの MIB 拡張はベンダー固有 MIB と呼ばれます。

ルーターのベンダー固有 MIB は、実装された標準および実験的 MIB を通じて利用できないすべての統計、状態、設定、および制御情報へのアクセスを提供しなければなりません (MUST)。この情報は監視および制御操作の両方に利用可能でなければなりません (MUST)。

DISCUSSION この要件の意図は、コンソールを通じてルーターで行えることを SNMP を通じても行え、その逆も行えるようにする能力を提供することです。SNMP が動作する前に最低限の設定が必要です（たとえばルーターは IP アドレスを持たなければなりません）。この初期設定は SNMP を通じて行うことはできません。しかし、初期設定が行われた後は、ネットワーク管理を通じて完全な機能が利用可能であるべきです。

ベンダーは、すべてのベンダー固有 MIB 変数の仕様を利用可能にすべきです (SHOULD)。これらの仕様は SMI [MGT:1] に準拠しなければならず (MUST)、その記述は [MGT:4] で指定された形式でなければなりません (MUST)。

DISCUSSION ベンダー固有 MIB をユーザーに利用可能にすることは必要です。この情報がないと、ユーザーはベンダー固有パラメータにアクセスできるようにネットワーク管理システムを設定できません。その場合、これらのパラメータは役に立たなくなります。

NOTE 2: MIB 仕様の形式も指定されています。MIB 仕様を読み取り、ネットワーク管理ステーションに必要なテーブルを生成するパーサが利用可能です。これらのパーサは一般に標準 MIB 仕様形式のみを理解します。

8.5 Saving Changes (変更の保存)

SNMP によって変更されたパラメータは、不揮発性ストレージに保存されてよい (MAY) です。

DISCUSSION この要件が MAY である理由:

不揮発性ストレージの正確な物理的性質は本ドキュメントで指定されていません。したがって、パラメータは NVRAM/EEPROM、ローカル・フロッピーまたはハードディスク、あるいは一部の TFTP ファイル・サーバまたは BOOTP サーバなどに保存されてよいです。この情報が TFTP を通じて取得されるファイルにあると仮定します。その場合、ルーターの設定パラメータに加えられた変更は、設定ファイルを保持するファイル・サーバに伝播される必要があります。あるいは、SNMP 操作をファイル・サーバに向ける必要があり、その後変更が何らかの方法でルーターに伝播される必要があります。この問題に対する答えは
設定情報を保持するホストに、利用可能な TFTP サーバを持つこと以上の要件を課すため、ベンダーが潜在的な顧客がいずれも適切なホストを利用できると想定することは、おそらく安全ではありません。
変更されたパラメータを不揮発性ストレージにコミットするタイミングは、依然として議論の対象です。一部はすべての変更を直ちにコミットすることを好みます。他の者は、明示的なコマンドがあった場合にのみ不揮発性ストレージに変更をコミットすることを好みます。

9. APPLICATION LAYER - MISCELLANEOUS PROTOCOLS (アプリケーション層 - その他のプロトコル)

ルーターが実装するすべての追加のアプリケーション・プロトコルについて、ルーターは [INTRO:3] の関連要件に準拠しなければならず (MUST)、無条件に準拠すべきです (SHOULD)。

9.1 BOOTP

9.1.1 Introduction (導入)

Bootstrap Protocol (BOOTP) は、ブート中のホストがユーザーの監視なしに動的に自身を設定できるようにする UDP/IP ベースのプロトコルです。BOOTP は、ホストに割り当てられた IP アドレス、ブート・サーバ・ホストの IP アドレス、およびメモリにロードされて実行されるファイルの名前を通知する手段を提供します ([APPL:1])。ローカル・プレフィックス長またはサブネット・マスク、ローカル・タイム・オフセット、デフォルト・ルーターのアドレス、およびさまざまなインターネット・サーバのアドレスなどの他の設定情報も、BOOTP を使用してホストに通信できます ([APPL:2])。

9.1.2 BOOTP Relay Agents (BOOTP リレー・エージェント)

多くの場合、BOOTP クライアントとそれに関連する BOOTP サーバは同じ IP（サブ）ネットワーク上に存在しません。そのような場合、クライアントとサーバ間で BOOTP メッセージを転送するためにサードパーティのエージェントが必要です。そのようなエージェントはもともと BOOTP forwarding agent と呼ばれていました。しかし、ルーターの IP 転送機能との混同を避けるため、代わりに BOOTP relay agent という名前が採用されました。

DISCUSSION BOOTP リレー・エージェントは、ルーターの通常の IP 転送機能とは異なるタスクを実行します。ルーターが通常ネットワーク間で IP データグラムをほぼ透過的に切り替えるのに対し、BOOTP リレー・エージェントは BOOTP メッセージを最終宛先として受信し、その結果として新しい BOOTP メッセージを生成すると考えるのがより正確です。通常のパケットのように BOOTP メッセージを単にそのまま転送するという考え方には抵抗すべきです。

このリレー・エージェント機能は、クライアントとサーバを相互接続するルーター内に配置するのが最も便利です（ただし、クライアント（サブ）ネットに直接接続されたホスト内に配置してもよい）。

ルーターは BOOTP リレー・エージェント機能を提供してもよい (MAY) です。提供する場合、[APPL:3] の仕様に準拠しなければなりません (MUST)。

セクション [5.2.3] は、パケットがローカルに（ルーターに）配送される状況について論じました。UDP 宛先ポート番号が BOOTPS (67) であるすべてのローカル配送された UDP メッセージは、ルーターの論理 BOOTP リレー・エージェントによる特別な処理の対象と見なされます。

セクション [4.2.2.11] および [5.3.7] は無効な IP 送信元アドレスについて論じました。これらの規則によれば、ルーターは IP 送信元アドレスが 0.0.0.0 である受信データグラムを転送してはなりません。ただし、BOOTP リレー・エージェントをサポートするルーターは、IP 送信元アドレスが 0.0.0.0 である BOOTREQUEST メッセージをリレー・エージェントへのローカル配送のために受け入れなければなりません (MUST)。

10. OPERATIONS AND MAINTENANCE (運用と保守)

この章は、「Extensions to the IP Module」に関連する [INTRO:3] のいかなる要件にも優先します。

運用および保守 (O&M) 活動を支援する機能は、あらゆるルーター実装の不可欠な部分を形成します。これらの機能は相互運用性に直接関連しないように見えますが、ルーターを相互運用させ、うまくいかないときに問題を追跡しなければならないネットワーク管理者にとって不可欠です。この章には、ルーターの初期化、およびネットワーク管理者が自らのネットワークを保護し会計処理するための支援機能についての議論も含まれます。

10.1 Introduction (導入)

ルーター O&M には次の種類の活動が含まれます:

ルーターのプロセッサ、ネットワーク・インタフェース、または接続されたネットワーク、モデム、または通信回線のハードウェア問題の診断。
新しいハードウェアのインストール。
新しいソフトウェアのインストール。
クラッシュ後のルーターの再起動またはリブート。
ルーターの設定（または再設定）。
輻輳、ルーティング・ループ、不正な IP アドレス、ブラックホール、パケット雪崩、および不正な動作をするホストなどのインターネット問題の検出と診断。
一時的（たとえば通信回線の問題をバイパスするため）または永続的なネットワーク・トポロジの変更。
ルーターおよび接続されたネットワークのステータスとパフォーマンスの監視。
（相互）ネットワーク計画での使用のためのトラフィック統計の収集。
上記の活動を適切なベンダーおよび通信の専門家と調整する。

ルーターとそれに接続された通信回線は、多くの場合、集中型 O&M 組織によってシステムとして運用されます。この組織は、その O&M 機能を実行するために（相互）ネットワーク運用センター、または NOC を維持する場合があります。ルーターが NOC と同じネットワークに接続されていない可能性があるため、そのような NOC からのリモート制御と監視をインターネット・パスを通じてルーターがサポートすることは不可欠です。ネットワーク障害が一時的にネットワーク・アクセスを妨げる可能性があるため、多くの NOC は、ルーターが代替手段、多くの場合ルーターのコンソール・ポートに接続されたダイヤルアップ・モデムを通じてネットワーク管理用にアクセス可能であることを主張します。

IP パケットがインターネットを通過する際に、多くの場合、複数の NOC の管理下にあるルーターを使用するため、インターネット問題の診断には多くの場合複数の NOC の担当者の協力が必要です。場合によっては、同じルーターを複数の NOC が監視する必要がある場合がありますが、過度の監視がルーターのパフォーマンスに影響を与える可能性があるため、必要な場合のみです。

NOC で監視に利用可能なツールは、高度さの幅が広い場合があります。現在の実装には、ルーター・システム全体のマルチウィンドウの動的表示が含まれます。自動問題診断のための AI 技法の使用は将来提案されています。

ここで論じるルーター O&M 機能は、インターネット管理という大規模で困難な問題の一部にすぎません。これらの問題は、複数の管理組織だけでなく、複数のプロトコル層も含みます。たとえば、インターネット・アーキテクチャの現在の進化段階では、ホストの TCP 実装とルーター・システム内の最終的な IP レベルの輻輳との間に強い結合があります [OPER:1]。したがって、輻輳問題の診断には、ホスト内の TCP 統計の監視が必要になる場合があります。現在、インターネット管理、より具体的にはルーター O&M の分野で進行中の R&D 取り組みが多数あります。これらの R&D 取り組みはすでにルーター O&M の標準を生み出しています。これはまた、ベンダーの創造性が大きく貢献できる分野です。

10.2 Router Initialization (ルーターの初期化)

10.2.1 Minimum Router Configuration (最小ルーター設定)

ルーターがパケットを転送する前に満たされなければならない最小限の条件の集合が存在します。ルーターは、次のいずれかが成立しない限り、いかなる物理インタフェースでも転送を有効にしてはなりません (MUST NOT):

(1) ルーターが、その物理インタフェースに関連付けられた少なくとも 1 つの論理インタフェースの IP アドレスと関連するサブネット・マスクまたはネットワーク・プレフィックス長を知っている、または (2) ルーターがそのインタフェースが番号なしインタフェースであり、その router-id を知っていることを知っている。

これらのパラメータは明示的に設定されなければなりません (MUST):

ルーターは、その IP アドレス、プレフィックス長、または router-id に工場出荷時設定のデフォルト値を使用してはならず (MUST NOT)、
ルーターは、未設定のインタフェースが番号なしインタフェースであると想定してはならない (MUST NOT)。

DISCUSSION ルーターがベンダーがインストールしたインタフェースのデフォルト・アドレスと共に出荷された事例がありました。少数のケースで、これによりルーターがこれらのデフォルト・アドレスをアクティブなネットワークにアドバタイズする結果となりました。

10.2.2 Address and Prefix Initialization (アドレスとプレフィックスの初期化)

ルーターは、その IP アドレスとそれらのアドレス・マスクまたはプレフィックス長を静的に設定し、不揮発性ストレージに保存できるようにしなければなりません (MUST)。

ルーターは、システム初期化プロセスの副作用として、その IP アドレスとそれに対応するアドレス・マスクを動的に取得してもよい (MAY) です（セクション 10.2.3 参照）。

動的メソッドが提供される場合、特定のルーターで使用されるメソッドの選択は設定可能でなければなりません (MUST)。

セクション [4.2.2.11] で説明したように、IP アドレスはまたはフィールドの値として 0 または -1 を持つことは許可されません。したがって、ルーターは IP アドレスまたはアドレス・マスクを、これらのフィールドのいずれかが値 0 または -1 となるような値に設定することを許可すべきではありません (SHOULD NOT)。

DISCUSSION 任意のアドレス・マスクを使用すると、ルーティングが曖昧になる状況（つまり、異なるが等しく具体的なサブネット・マスクを持つ 2 つのルートが特定の宛先アドレスに一致する）を作成する可能性があります。これはネットワーク・プレフィックスの使用を支持する最も強い議論の 1 つであり、不連続サブネット・マスクの使用が許可されない理由です。

ルーターは、インストールする任意のアドレス・マスクに対して次のチェックを実行すべきです (SHOULD):

マスクはすべて 1 でもすべて 0 でもない（プレフィックス長は 0 でも 32 でもない）。
アドレスのネットワーク・プレフィックス部分に対応するビットはすべて 1 に設定されている。
ネットワーク・プレフィックスに対応するビットは連続している。

DISCUSSION ルートに関連付けられたマスクはサブネット・マスクとも呼ばれますが、このテストはそれらには適用すべきではありません。

10.2.3 Network Booting using BOOTP and TFTP (BOOTP と TFTP を使用したネットワーク・ブート)

ルーターをネットワークからブートできる方法とすべき方法について、多くの議論がありました。これらの議論は BOOTP と TFTP を中心に展開してきました。現在、ネットワークから TFTP でブートするルーターが存在します。ブート・イメージをロードするサーバを見つけるために BOOTP を使用できない理由はありません。

BOOTP はエンドシステムをブートするために使用されるプロトコルであり、ルーターでの使用に合わせていくらかの拡張を必要とします。ルーターが現在のブート・ホストを見つけるために BOOTP を使用している場合、BOOTP Request を送信すべきです (SHOULD)。

10.3 Operation and Maintenance (運用と保守)

10.3.1 Introduction (導入)

ルーターに対して O&M（運用と保守）機能を実行するための可能なモデルには幅があります。一方の極はローカルのみのモデルであり、この下では O&M 機能はローカル（ルーター機に接続された端末など）からのみ実行できます。もう一方の極は完全リモート・モデルであり、ローカルで実行できるのは絶対最小限の機能（強制ブートなど）のみで、ほとんどの O&M は NOC（ネットワーク運用センター）からリモートで行われます。中間的なモデルもあり、例えば NOC の担当者が Telnet プロトコルを使用してルーターにホストとしてログインし、ローカルでも呼び出せる機能を実行できるものなどです。ローカルのみのモデルは少数のルーター設置では十分な場合がありますが、通常は NOC からのリモート運用が必要であり、したがってほとんどのルーターにはリモート O&M の用意が必要です。

リモート O&M 機能は制御エージェント（プログラム）を通じて実行されてよい (MAY) です。直接的なアプローチでは、ルーターは標準インターネット・プロトコル（SNMP、UDP、TCP など）を使用して NOC から直接リモート O&M 機能をサポートします。間接的なアプローチでは、制御エージェントがこれらのプロトコルをサポートし、独自プロトコルを使用してルーター自体を制御します。直接的なアプローチが望ましいですが、いずれのアプローチも許容されます。多大な追加投資を要する専用ホスト・ハードウェアおよび/またはソフトウェアの使用は推奨されません。それにもかかわらず、一部のベンダーは制御エージェントをルーターの一部であるネットワークの統合された一部として提供することを選択する場合があります。この場合、標準インターネット・プロトコルとパスを使用し、ローカル・エージェント端末と同等の機能を持って、リモート・サイトから制御エージェントを操作する手段が利用可能でなければなりません (MUST)。

制御エージェントおよびベンダーが提供するその他の NOC ソフトウェア・ツールは、標準オペレーティング・システム上のユーザ・プログラムとして動作することが望ましいです。ルーターとの通信に標準インターネット・プロトコル UDP および TCP を使用することで、これが容易になるはずです。

リモート・ルーター監視、とくにリモート・ルーター制御は、対処すべき重要なアクセス制御の問題を提示します。これらの機能のためにルーター資源の使用制御を確保するためにも注意を払う必要があります。例えば、ルーター CPU 時間のある限定された割合以上をルーター監視に費やさせないようにすることが望ましくありません。一方で、O&M 機能は優先権を与えられなければならない (MUST) ため、ルーターが輻輳しているときでも実行できるようになります。しばしばそれが O&M が最も必要とされるときだからです。

10.3.2 Out Of Band Access (帯域外アクセス)

ルーターは帯域外（OOB）アクセスをサポートしなければなりません (MUST)。OOB アクセスはインバンド・アクセスと同じ機能を提供すべきです (SHOULD)。このアクセスは、不正アクセスを防ぐためにアクセス制御を実装すべきです (SHOULD)。

DISCUSSION この帯域外アクセスにより、NOC はネットワーク・アクセスが利用できないときに隔離されたルーターにアクセスする手段を得られます。

帯域外アクセスはネットワーク管理者にとって重要な管理ツールです。これはネットワーク接続とは独立して機器にアクセスすることを可能にします。これを実現する方法は多数あります。どの方法が使用されても、アクセスがネットワーク接続から独立していることが重要です。帯域外アクセスの例としては、ルーターへのダイヤルアップ・アクセスを提供するモデムに接続されたシリアル・ポートがあります。

OOB アクセスがインバンド・アクセスと同じ機能を提供することが重要です。既存のネットワーク接続を通じて機器にアクセスするインバンド・アクセスは、大半の場合、管理者が到達不能な理由を調べるために機器に到達する必要があるため、限定的です。インバンド・アクセスはルーターの設定や、より微妙な問題のトラブルシューティングには依然として非常に重要です。

10.3.2 Router O&M Functions (ルーター O&M 機能)

10.3.2.1 Maintenance - Hardware Diagnosis (保守 - ハードウェア診断)

各ルーターは、ローカル・ハードウェア保守の目的においてスタンドアロン装置として動作すべきです (SHOULD)。オンサイトのツールのみを使用してルーター・サイトで診断プログラムを実行する手段が利用可能であるべきです (SHOULD)。ルーターは障害の場合に診断を実行できるべきです (SHOULD)。提案されるハードウェアおよびソフトウェア診断についてはセクション [10.3.3] を参照してください。

10.3.2.2 Control - Dumping and Rebooting (制御 - ダンプと再起動)

ルーターは、ネットワーク管理者がルーターをリロード、停止、および再起動できるようにする、インバンドおよび帯域外の両方のメカニズムを含まなければなりません (MUST)。ルーターはまた、ソフトウェアまたはハードウェア障害のためにハングした場合にルーターを自動的に再起動するメカニズム（ウォッチドッグ・タイマーなど）を含むべきです (SHOULD)。

ルーターは、（クラッシュ後のベンダー・デバッグに有用な）ルーターのメモリ内容（および/またはその他の状態）をダンプするメカニズムを実装すべきです (SHOULD)。ダンプされた内容は、ルーターにローカルな安定ストレージ装置に保存するか、TFTP などのアップライン・ダンプ・メカニズム（[OPER:2]、[INTRO:3] 参照）を介して別のホストに保存します。

10.3.2.3 Control - Configuring the Router (制御 - ルーターの設定)

すべてのルーターには設定すべきパラメータがあります。ルーターを再起動せずにパラメータを更新できることが望ましいです (SHOULD)。最悪の場合、再起動が必要となる場合があります (MAY)。ルーターを再起動せずにパラメータを変更できない場合（例えばインタフェースの IP アドレスを変更する場合）があります。このような場合は、ルーターとその周囲のネットワークへの混乱を最小限に抑えるよう注意を払うべきです (SHOULD)。

ネットワーク越しにルーターを手動または自動で設定する方法があるべきです (SHOULD)。ルーターはホストまたは別のルーターからそのパラメータをアップロードまたはダウンロードできるべきです (SHOULD)。パラメータ形式と人間が編集可能な形式との間の変換を行う手段が、アプリケーション・プログラムまたはルーター機能のいずれかとして提供されるべきです (SHOULD)。ルーターはその設定用に何らかの安定ストレージを持つべきです (SHOULD)。ルーターは RARP、ICMP Address Mask Reply などのプロトコルを信じてはならず (SHOULD NOT)、BOOTP を信じない場合があります (MAY)。

DISCUSSION ここで注意が必要なのは、将来、RARP、ICMP Address Mask Reply、BOOTP およびその他のメカニズムが、ルーターが自動設定できるようにするために必要となる可能性があるということです。ルーターは将来的に自動設定できるようになるかもしれませんが、ここでの意図は、自動設定がより徹底的にテストされるまで、製品環境でのこの慣行を抑制することです。意図は自動設定を全面的に抑制することではありません。ルーターが設定を自動的に取得すると予想される場合、ルーターが起動時にこれらを信じ、設定を取得した後は無視するようにするのが賢明な場合があります。

10.3.2.4 Net Booting of System Software (システム・ソフトウェアのネット・ブート)

ルーターは、そのシステム・イメージを PROM、NVRAM、ディスクなどのローカル不揮発性ストレージに保持すべきです (SHOULD)。また、ホストまたは別のルーターからネットワーク越しにそのシステム・ソフトウェアをロードできる場合があります (MAY)。

ローカル不揮発性ストレージにシステム・イメージを保持できるルーターは、ネットワーク越しにシステム・イメージをブートするように設定可能であってもよい (MAY) です。このオプションを提供するルーターは、ネットワーク越しにシステム・イメージをブートできない場合、その不揮発性ローカル・ストレージ内のシステム・イメージをブートするように設定可能であるべきです (SHOULD)。

10.3.2.5 Detecting and responding to misconfiguration (設定ミスの検出と対応)

設定ミスを検出し対応するメカニズムが存在しなければなりません (MUST)。コマンドが誤って実行された場合、ルーターはエラー・メッセージを出すべきです (SHOULD)。ルーターは、正しく形成されていないコマンドを正しいものとして受け入れてはならない (SHOULD NOT) ことが望ましいです。

DISCUSSION エラーを検出できない場合があります。コマンドは正しく形成されているが、ネットワークに対しては不正です。これはルーターによって検出される場合がありますが、不可能な場合もあります。

別の形式の設定ミスは、ルーターが接続されているネットワークの設定ミスです。ルーターはネットワーク内の設定ミスを検出してもよい (MAY) です。ルーターはこれらの発見を、ルーターまたはホスト上のファイルに記録してもよく (MAY)、ネットワーク管理者がネットワーク上に考えられる問題があることを認識できるようにします。

DISCUSSION このような設定ミスの例としては、問題のルーターと同じアドレスを持つ別のルーターや、誤ったアドレス・マスクを持つルーターなどがあります。ルーターがそのような問題を検出した場合、ルーターが状況を修正しようと試みるのはおそらく最良の考えではありません。それは良いよりも害をもたらす可能性があります。

10.3.2.6 Minimizing Disruption (中断の最小化)

ルーターの設定を変更してもネットワークへの影響を最小限に抑えるべきです (SHOULD)。ルーターに単純な変更を加えたときに、ルーティング・テーブルを不必要にフラッシュしてはならない (SHOULD NOT) ことが望ましいです。ルーターが複数のルーティング・プロトコルを実行している場合、1 つのルーティング・プロトコルを停止しても、複数のルーティング・プロトコルによって学習されるネットワークを除き、他のルーティング・プロトコルを妨害すべきではありません (SHOULD NOT)。

DISCUSSION ネットワーク管理者の目標は、ネットワークのユーザーが可能な限り最高の接続性を得られるようにネットワークを運用することです。単純な設定変更のためにルーターをリロードすると、ルーティングの中断を引き起こし、最終的にネットワークとそのユーザーの中断を招く可能性があります。例えばルーティング・テーブルが不必要にフラッシュされると、デフォルト・ルートだけでなく、ネットワーク内のサイトへの特定のルートも失われます。この種の中断はユーザーにとって重大なダウンタイムを引き起こします。このセクションの目的は、可能な限りこれらの中断を回避すべきであることを指摘することです。

10.3.2.7 Control - Troubleshooting Problems (制御 - 問題のトラブルシューティング)

(1) ルーターはインバンド・ネットワーク・アクセスを提供しなければなりません (MUST) が、（セクション [8.2] で要求される場合を除き）セキュリティ上の考慮から、このアクセスはデフォルトで無効にされるべきです (SHOULD)。ベンダーは任意のインバンド・アクセスのデフォルト状態を文書化しなければなりません (MUST)。このアクセスは、不正アクセスを防ぐためにアクセス制御を実装すべきです (SHOULD)。

DISCUSSION インバンド・アクセスは主に、ルーターの永続的な運用状態に影響を与える可能性がある、または与えない可能性がある通常のネットワーク・プロトコルを通じたアクセスを指します。これには Telnet/RLOGIN コンソール・アクセスや SNMP 操作などが含まれますが、それらに限定されません。

これは、箱から出した直後は運用可能か、箱から出した直後は安全かという二つの陣営間の論争の的でした。ルーターへの任意の自動アクセスは不安全性をもたらす可能性がありますが、顧客にとっては、プラグを挿した直後にネットワーク越しにアクセスできるルーターの方が重要かもしれません。少なくとも 1 つのベンダーは、外部コンソール・アクセスなしでルーターを提供し、その設定を完了するためにネットワーク越しにルーターにアクセスすることに依存しています。

インバンド・アクセスをデフォルトで有効にするかどうかはベンダーの判断です。しかし、可能な不安全性を顧客に認識させるのもベンダーの責任です。

(2) ルーターは ICMP エコーを開始する能力を提供しなければなりません (MUST)。次のオプションが実装されるべきです (SHOULD):

o データ・パターンの選択

o パケット・サイズの選択

o レコード・ルート

さらに、次の追加オプションが実装されてよい (MAY) です:

o ルース・ソース・ルート

o ストリクト・ソース・ルート

o タイムスタンプ

(3) ルーターは traceroute を開始する能力を提供すべきです (SHOULD)。traceroute が提供される場合、サード・パーティ traceroute が実装されるべきです (SHOULD)。

上記 3 つの機能のそれぞれ（実装される場合）には、不正な人物による乱用を防ぐためにアクセス制限が課されるべきです (SHOULD)。

10.4 Security Considerations (セキュリティに関する考慮事項)

10.4.1 Auditing and Audit Trails (監査と監査証跡)

監査と課金はネットワーク運用者の悩みの種ですが、ネットワーク・セキュリティの責任者や料金を支払う責任者から最も求められる 2 つの機能です。セキュリティの文脈では、監査は、ネットワークを正常に運用し続け、リソースが悪用されるのを防ぐのに役立つ場合に望ましいものですが、それらのリソースの価値以上のコストをかけてはなりません。

(1) 設定の変更

ルーターは、ルーターの設定変更を監査する方法を提供すべきです (SHOULD)（オペレータのイニシャルと変更時刻の記録のような単純なものであっても）。

DISCUSSION 設定変更のログ（誰が、何を、いつ変更したか）は、トラフィックが突然町中を横断する際にアラスカ経由でルーティングされるような場合に非常に有用です。以前の設定に戻す能力も同様に有用です。

(2) パケット・アカウンティング

ベンダーは、ホストまたはネットワークのペア間のトラフィック・レベルを追跡するシステムを強く検討すべきです (SHOULD)。この情報の収集を特定のホストまたはネットワークのペアに限定するメカニズムも強く推奨されます。

DISCUSSION 上記のホスト・トラフィック行列は、他の統計からは明らかでないトラフィック傾向をネットワーク運用者に示すことができます。また、接続されたネットワークの構造を探ろうとするホストやネットワークを識別することもできます。例えば、接続されたネットワークのすべての IP アドレスに対してパケットを送信しようとする単一の外部ホストなどです。

(3) セキュリティ監査

ルーターは、次を含むセキュリティ関連の失敗または違反を監査する方法を提供しなければなりません (MUST):

o 認証失敗：不正なパスワード、無効な SNMP コミュニティ、無効な認証トークン

o ポリシー制御の違反：禁止されたソース・ルート、フィルタリングされた宛先

o 認証承認：正しいパスワード - Telnet インバンド・アクセス、コンソール・アクセス

ルーターは、このような監査を制限または無効にする方法を提供しなければなりません (MUST) が、監査はデフォルトでオンであるべきです (SHOULD)。監査の可能な方法には、コンソールへの違反のリスト表示（存在する場合）、内部的なログまたはカウント、あるいは SNMP トラップ機構または Unix ロギング機構を介したリモート・セキュリティ・サーバへのログがあります。ルーターはこれらの報告メカニズムの少なくとも 1 つを実装しなければなりません (MUST) - 複数を実装してもよい (MAY) です。

10.4.2 Configuration Control (設定制御)

ベンダーは、ルーター用のソフトウェア/ファームウェア・ロードの作成において、優れた設定制御の実践を使用する責任があります。とくに、ベンダーがインターネット経由での取得のために更新とロードを利用可能にする場合、顧客がそのロードが有効なものであることを確認する方法（ロードに対するチェックサムの検証など）を提供すべきです (SHOULD)。

DISCUSSION 多くのベンダーが現在、ソフトウェア製品の更新をインターネット経由で短い通知で提供しています。これは良い傾向であり奨励されるべきですが、設定制御プロセスにおける脆弱性の一端を提供します。

ベンダーが顧客にルーターの設定パラメータをリモートで変更する能力（Telnet セッションなどを通じて）を提供する場合、その能力は設定可能であるべきであり (SHOULD)、デフォルトでオフであるべきです (SHOULD)。ルーターはリモート再設定を許可する前に、有効な認証を要求すべきです (SHOULD)。この認証手順は、認証秘密をネットワーク越しに送信すべきではありません (SHOULD NOT)。例えば Telnet が実装される場合、ベンダーは Kerberos、S-Key、または類似の認証手順を実装すべきです (SHOULD)。

DISCUSSION 正しく識別されたネットワーク運用者にルーターをいじらせることは必要ですが、他の誰かにそうさせることは無謀です。

ルーターは、文書化されていないバックドア・アクセスやマスタ・パスワードを持ってはなりません (MUST NOT)。ベンダーは、デバッグや製品開発の目的で追加されたそのようなアクセスが、製品が顧客に配布される前に削除されることを確実にしなければなりません (MUST)。

DISCUSSION ベンダーは、意図的なもの（インバンド・アクセスなど）について、そのコードに存在する脆弱性を顧客に認識させる責任があります。トラップ・ドア、バックドア、マスタ・パスワードは、意図的であれ偶発的であれ、比較的安全なルーターを運用ネットワーク上の重大な問題に変える可能性があります。想定される運用上の利点は、潜在的な問題に見合うものではありません。

11. REFERENCES (参照文献)

実装者は、インターネット・プロトコル標準が時折更新されることを認識しておくべきです (SHOULD)。これらの参照文献は本稿執筆時点のものですが、慎重な実装者は常に最新の RFC 索引を確認し、RFC が別のより新しい RFC によって更新または置換されていないことを確認します。参照 [INTRO:6] は最新の RFC 索引を入手するためのさまざまな方法を説明しています。

REFERENCES

Implementors should be aware that Internet protocol standards are occasionally updated. These references are current as of this writing, but a cautious implementor will always check a recent version of the RFC index to ensure that an RFC has not been updated or superseded by another, more recent RFC. Reference [INTRO:6] explains various ways to obtain a current RFC index.

APPL:1. Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford University, Sun Microsystems, September 1985.

APPL:2. Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993.

APPL:3. Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993.

ARCH:1. DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three volumes), DDN Network Information Center, SRI International, Menlo Park, California, USA, December 1985.

ARCH:2. V. Cerf and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communication, May 1974. Also included in [ARCH:1].

ARCH:3. J. Postel, C. Sunshine, and D. Cohen, "The ARPA Internet Protocol", Computer Networks, volume 5, number 4, July 1981. Also included in [ARCH:1].

ARCH:4. B. Leiner, J. Postel, R. Cole, and D. Mills, :The DARPA Internet Protocol Suite", Proceedings of INFOCOM '85, IEEE, Washington, DC, March 1985. Also in: IEEE Communications Magazine, March 1985. Also available from the Information Sciences Institute, University of Southern California as Technical Report ISI-RS-85-153.

ARCH:5. D. Comer, "Internetworking With TCP/IP Volume 1: Principles, Protocols, and Architecture", Prentice Hall, Englewood Cliffs, NJ, 1991.

ARCH:6. W. Stallings, "Handbook of Computer-Communications Standards Volume 3: The TCP/IP Protocol Suite", Macmillan, New York, NY, 1990.

ARCH:7. Postel, J., "Internet Official Protocol Standards", STD 1, RFC 1780, Internet Architecture Board, March 1995.

ARCH:8. Information processing systems - Open Systems Interconnection - Basic Reference Model, ISO 7489, International Standards Organization, 1984.

ARCH:9 R. Braden, J. Postel, Y. Rekhter, "Internet Architecture Extensions for Shared Media", 05/20/1994

FORWARD:1. IETF CIP Working Group (C. Topolcic, Editor), "Experimental Internet Stream Protocol", Version 2 (ST-II), RFC 1190, October 1990.

FORWARD:2. Mankin, A., and K. Ramakrishnan, Editors, "Gateway Congestion Control Survey", RFC 1254, MITRE, Digital Equipment Corporation, August 1991.

FORWARD:3. J. Nagle, "On Packet Switches with Infinite Storage", IEEE Transactions on Communications, volume COM-35, number 4, April 1987.

FORWARD:4. R. Jain, K. Ramakrishnan, and D. Chiu, "Congestion Avoidance in Computer Networks With a Connectionless Network Layer", Technical Report DEC-TR-506, Digital Equipment Corporation.

FORWARD:5. V. Jacobson, "Congestion Avoidance and Control", Proceedings of SIGCOMM '88, Association for Computing Machinery, August 1988.

FORWARD:6. W. Barns, "Precedence and Priority Access Implementation for Department of Defense Data Networks", Technical Report MTR- 91W00029, The Mitre Corporation, McLean, Virginia, USA, July 1991.

FORWARD:7 Fang, Chen, Hutchins, "Simulation Results of TCP Performance over ATM with and without Flow Control", presentation to the ATM Forum, November 15, 1993.

FORWARD:8 V. Paxson, S. Floyd "Wide Area Traffic: the Failure of Poisson Modeling", short version in SIGCOMM '94.

FORWARD:9 Leland, Taqqu, Willinger and Wilson, "On the Self-Similar Nature of Ethernet Traffic", Proceedings of SIGCOMM '93, September, 1993.

FORWARD:10 S. Keshav "A Control Theoretic Approach to Flow Control", SIGCOMM 91, pages 3-16

FORWARD:11 K.K. Ramakrishnan and R. Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions of Computer Systems, volume 8, number 2, 1980.

FORWARD:12 H. Kanakia, P. Mishara, and A. Reibman]. "An adaptive congestion control scheme for real-time packet video transport", In Proceedings of ACM SIGCOMM 1994, pages 20-31, San Francisco, California, September 1993.

FORWARD:13 A. Demers, S. Keshav, S. Shenker, "Analysis and Simulation of a Fair Queuing Algorithm", 93 pages 1-12

FORWARD:14 Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism", 92 pages 14-26

INTERNET:1. Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

INTERNET:2. Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, Stanford, USC/Information Sciences Institute, August 1985.

INTERNET:3. Mogul, J., "Broadcasting Internet Datagrams in the Presence of Subnets", STD 5, RFC 922, Stanford University, October 1984.

INTERNET:4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.

INTERNET:5. Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991.

INTERNET:6. Braden, R., Borman, D., and C. Partridge, "Computing the Internet Checksum", RFC 1071, USC/Information Sciences Institute, Cray Research, BBN Communications, September 1988.

INTERNET:7. Mallory T., and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, BBN Communications, January 1990.

INTERNET:8. Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.

INTERNET:9. A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Wilder, and R. Zahavi, "Evaluation of Internet Performance - FY89", Technical Report MTR-89W00216, MITRE Corporation, February, 1990.

INTERNET:10. G. Finn, A "Connectionless Congestion Control Algorithm", Computer Communications Review, volume 19, number 5, Association for Computing Machinery, October 1989.

INTERNET:11. Prue, W., and J. Postel, "The Source Quench Introduced Delay (SQuID)", RFC 1016, USC/Information Sciences Institute, August 1987.

INTERNET:12. McKenzie, A., "Some comments on SQuID", RFC 1018, BBN Labs, August 1987.

INTERNET:13. Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991.

INTERNET:14. Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.

INTERNET:15 Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy" RFC 1519, BARRNet, cisco, Merit, OARnet, September 1993.

INTERNET:16 St. Johns, M., "Draft Revised IP Security Option", RFC 1038, IETF, January 1988.

INTERNET:17 Prue, W., and J. Postel, "Queuing Algorithm to Provide Type- of-service For IP Links", RFC 1046, USC/Information Sciences Institute, February 1988.

INTERNET:18 Postel, J., "Address Mappings", RFC 796, USC/Information Sciences Institute, September 1981.

INTRO:1. Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC 1009, USC/Information Sciences Institute, June 1987.

INTRO:2. Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.

INTRO:3. Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

INTRO:4. Clark, D., "Modularity and Efficiency in Protocol Implementations", RFC 817, MIT Laboratory for Computer Science, July 1982.

INTRO:5. Clark, D., "The Structuring of Systems Using Upcalls", Proceedings of 10th ACM SOSP, December 1985.

INTRO:6. Jacobsen, O., and J. Postel, "Protocol Document Order Information", RFC 980, SRI, USC/Information Sciences Institute, March 1986.

INTRO:7. Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. This document is periodically updated and reissued with a new number. It is wise to verify occasionally that the version you have is still current.

INTRO:8. DoD Trusted Computer System Evaluation Criteria, DoD publication 5200.28-STD, U.S. Department of Defense, December 1985.

INTRO:9 Malkin, G., and T. LaQuey Parker, Editors, "Internet Users' Glossary", FYI 18, RFC 1392, Xylogics, Inc., UTexas, January 1993.

LINK:1. Leffler, S., and M. Karels, "Trailer Encapsulations", RFC 893, University of California at Berkeley, April 1984.

LINK:2 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer July 1994.

LINK:3 McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, Merit May 1992.

LINK:4 Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, L&A, Daydreamer, May 1992.

LINK:5 Simpson, W., "PPP Link Quality Monitoring", RFC 1333, Daydreamer, May 1992.

MGT:1. Rose, M., and K. McCloghrie, "Structure and Identification of Management Information of TCP/IP-based Internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.

MGT:2. McCloghrie, K., and M. Rose (Editors), "Management Information Base of TCP/IP-Based Internets: MIB-II", STD 16, RFC 1213, Hughes LAN Systems, Inc., Performance Systems International, March 1991.

MGT:3. Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990.

MGT:4. Rose, M., and K. McCloghrie (Editors), "Towards Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991.

MGT:5. Steinberg, L., "Techniques for Managing Asynchronously Generated Alerts", RFC 1224, IBM Corporation, May 1991.

MGT:6. Kastenholz, F., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., January 1993.

MGT:7. McCloghrie, K., and R. Fox "IEEE 802.4 Token Bus MIB", RFC 1230, Hughes LAN Systems, Inc., Synoptics, Inc., May 1991.

MGT:8. McCloghrie, K., Fox R., and E. Decker, "IEEE 802.5 Token Ring MIB", RFC 1231, Hughes LAN Systems, Inc., Synoptics, Inc., cisco Systems, Inc., February 1993.

MGT:9. Case, J., and A. Rijsinghani, "FDDI Management Information Base", RFC 1512, The University of Tennesse and SNMP Research, Digital Equipment Corporation, September 1993.

MGT:10. Stewart, B., Editor "Definitions of Managed Objects for RS-232- like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992.

MGT:11. Kastenholz, F., "Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, FTP Software, Inc., June 1992.

MGT:12. Kastenholz, F., "The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol", RFC 1472, FTP Software, Inc., June 1992.

MGT:13. Kastenholz, F., "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", RFC 1473, FTP Software, Inc., June 1992.

MGT:14. Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, Computer Science Center, August 1991.

MGT:15. Willis, S., and J. Burruss, "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet Communications Inc., October 1991.

MGT:16. Baker, F., and J. Watt, "Definitions of Managed Objects for the DS1 and E1 Interface Types", RFC 1406, Advanced Computer Communications, Newbridge Networks Corporation, January 1993.

MGT:17. Cox, T., and K. Tesink, Editors "Definitions of Managed Objects for the DS3/E3 Interface Types", RFC 1407, Bell Communications Research, January 1993.

MGT:18. McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, Hughes LAN Systems, August 1992.

MGT:19. Cox, T., and K. Tesink, "Definitions of Managed Objects for the SIP Interface Type", RFC 1304, Bell Communications Research, February 1992.

MGT:20 Baker, F., "IP Forwarding Table MIB", RFC 1354, ACC, July 1992.

MGT:21. Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, Xylogics, Inc., Cisco Systems, November 1994

MGT:22. Throop, D., "SNMP MIB Extension for the X.25 Packet Layer", RFC 1382, Data General Corporation, November 1992.

MGT:23. Throop, D., and F. Baker, "SNMP MIB Extension for X.25 LAPB", RFC 1381, Data General Corporation, ACC, November 1992.

MGT:24. Throop, D., and F. Baker, "SNMP MIB Extension for MultiProtocol Interconnect over X.25", RFC 1461, Data General Corporation, May 1993.

MGT:25. Rose, M., "SNMP over OSI", RFC 1418, Dover Beach Consulting, Inc., March 1993.

MGT:26. Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419, Novell, Inc., Apple Computer, Inc., March 1993.

MGT:27. Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.

MGT:28. Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, NYSERNet, Inc., University of Tennessee at Knoxville, February 1989.

MGT:29. Case, J., "FDDI Management Information Base", RFC 1285, SNMP Research, Incorporated, January 1992.

OPER:1. Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, FACC, January 1984.

OPER:2. Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July 1992.

ROUTE:1. Moy, J., "OSPF Version 2", RFC 1583, Proteon, March 1994.

ROUTE:2. Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, DEC, December 1990.

ROUTE:3. Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988.

ROUTE:4. Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco, T.J. Watson Research Center, IBM Corp., October 1991.

ROUTE:5. Gross, P, and Y. Rekhter, "Application of the Border Gateway Protocol in the Internet", RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.

ROUTE:6. Mills, D., "Exterior Gateway Protocol Formal Specification", RFC 904, UDEL, April 1984.

ROUTE:7. Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827, BBN, October 1982.

ROUTE:8. Seamonson, L, and E. Rosen, "STUB" "Exterior Gateway Protocol", RFC 888, BBN, January 1984.

ROUTE:9. Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, BBN, Stanford, November 1988.

ROUTE:10. Deering, S., Multicast Routing in Internetworks and Extended LANs, Proceedings of '88, Association for Computing Machinery, August 1988.

ROUTE:11. Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, Consultant, July 1992.

ROUTE:12. Rekhter, Y., "Experience with the BGP Protocol", RFC 1266, T.J. Watson Research Center, IBM Corp., October 1991.

ROUTE:13. Rekhter, Y., "BGP Protocol Analysis", RFC 1265, T.J. Watson Research Center, IBM Corp., October 1991.

TRANS:1. Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.

TRANS:2. Postel, J., "Transmission Control Protocol", STD 7, RFC 793, USC/Information Sciences Institute, September 1981.

APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS (ソース・ルーティング・ホストの要件)

以下に示す制限の下で、ホストはソース・ルート内の中継ホップとして動作し、ソース・ルーティングされたデータグラムを次に指定されたホップに転送してもよい (MAY) です。

しかし、このルーターのような機能を実行する際、ホストはソース・ルーティングされたデータグラムを転送するルーターに対するすべての関連規則 [INTRO:2] に従わなければなりません (MUST)。これには次の具体的な規定が含まれます:

(A) TTL TTL フィールドは [INTRO:2] のルーター用に指定されたとおりにデクリメントされ、データグラムは場合によっては廃棄されなければなりません (MUST)。

(B) ICMP 宛先到達不能 (Destination Unreachable) ホストは次のコードを持つ宛先到達不能メッセージを生成できる (MUST) 必要があります: 4 (フラグメンテーションが必要だが DF が設定されている) - ソース・ルーティングされたデータグラムをターゲット・ネットワークに収めるためにフラグメント化できない場合。 5 (ソース・ルート失敗) - ソース・ルーティングされたデータグラムを転送できない場合（例えばルーティング問題のため、またはストリクト・ソース・ルートの次ホップが接続されたネットワーク上にないため）。

(D) レコード・ルート・オプション (Record Route Option) ソース・ルーティングされたデータグラムを転送するホストは、Record Route オプションを含む場合、そのオプションに空きがあればそれを更新しなければなりません (MUST)。

(E) タイムスタンプ・オプション (Timestamp Option) ソース・ルーティングされたデータグラムを転送するホストは、Timestamp Option を含む場合、このオプションの規則に従って現在のタイムスタンプをそのオプションに追加しなければなりません (MUST)。

ソース・ルーティングされたデータグラムのホスト転送を制限する規則を定義するため、次ホップがデータグラムが到着したものと同じ物理インタフェースを通じて到達する場合、これをローカル・ソース・ルーティングと呼び、そうでない場合は非ローカル・ソース・ルーティングと呼びます。

ホストはローカル・ソース・ルーティングを無制限に実行してもかまいません (MAY)。

非ローカル・ソース・ルーティングをサポートするホストは、転送を無効にする設定可能なスイッチを持たなければなりません (MUST) が、このスイッチはデフォルトで無効でなければなりません (MUST)。

ホストは非ローカル転送を制限する設定可能なポリシー・フィルタに対するすべてのルーター要件 [INTRO:2] を満たさなければなりません (MUST)。

ホストが不完全なソース・ルートを持つデータグラムを受信したが、何らかの理由でそれを転送しない場合、そのデータグラム自体が ICMP エラー・メッセージでなかった限り、ホストは ICMP 宛先到達不能（コード 5、ソース・ルート失敗）メッセージを返すべきです (SHOULD)。

APPENDIX B. GLOSSARY (用語集)

本付録は、このメモで使用される特定の用語を定義します。また、関心のある汎用的な用語もいくつか定義します。より一般的な定義の集合については [INTRO:9] も参照してください。

Autonomous System (AS) Autonomous System (AS) は、一組の subnetworks（hosts を付属）とそれらを相互接続する一組の routes からなるネットワーク・トポロジの連結セグメントです。これらの subnetworks と routers は、単一の operations and maintenance (O&M) 組織の管理下にあると想定されます。1 つの AS 内では、routers は 1 つ以上の interior routing protocols を使用し、時には複数組の metrics を使用する場合があります。AS は、他の AS に対して一貫した内部 routing plan の外観と、その AS を通じて到達可能な destinations の一貫した全体像を提示することが期待されます。AS は Autonomous System number によって識別されます。

Connected Network ルーターがインタフェース接続されている network prefix は、多くの場合 local network またはそのルーターの subnetwork と呼ばれます。しかしこれらの用語は混乱を招く可能性があるため、本メモでは Connected Network という用語を使用します。

Connected (Sub)Network Connected (Sub)Network とは、ルーターがインタフェース接続されている IP subnetwork、または connected network がサブネット化されていない場合は connected network のことです。Connected Network も参照してください。

Datagram internet modules の対の間で送信される単位。ソースからデスティネーションへ、datagrams と呼ばれるデータが送信されます。Internet Protocol は信頼できる通信機能を提供しません。端から端への acknowledgments も、hop-by-hop の acknowledgments もありません。error retransmissions はなく、flow control もありません。IP を参照してください。

Default Route ルーティング・テーブルに明示的にリストされていない network prefixes 宛てのデータを転送するために使用されるルーティング・テーブル項目。

Dense Mode multicast forwarding には 2 つのパラダイムが可能です。Dense Mode forwarding では、network multicast は、multicast routing neighbor から指示されない限り、受信したインタフェース以外のすべてのインタフェースに対して data link layer multicast として転送されます。Sparse Mode を参照してください。

EGP Exterior Gateway Protocol。autonomous systems を接続する gateways (routers) に routing information を配布するプロトコル。IGP を参照してください。

EGP-2 Exterior Gateway Protocol version 2。Internet 内の Autonomous Systems 間のトラフィックを処理するために開発された EGP routing protocol です。

Forwarder ルーター内部にあり、ルーターのインタフェース間で packets を切り替える (switching) 責任を持つ論理エンティティ。Forwarder はまた、packet を local delivery のためにキューイングする、別のインタフェースからの送信のためにキューイングする、またはその両方を行う決定を下します。

Forwarding Forwarding とは、ルーターが受信した各 packet に対して行うプロセスです。packet はルーターによって消費されてもよく、ルーターの 1 つ以上のインタフェースから出力されてもよく、あるいはその両方です。Forwarding には、packet をどうするかの決定と、それを（可能な）出力または内部消費のためにキューイングするプロセスが含まれます。

Forwarding Information Base (FIB) 本ドキュメントでは、IP Datagrams を転送するために必要な情報を含むテーブルを Forwarding Information Base と呼びます。これには最低限、到達可能な各 destination network prefix のための interface identifier と next hop 情報が含まれます。

Fragment 出力ネットワーク上で全体として送信するには大きすぎた上位層の packet の一部を表す IP datagram。

General Purpose Serial Interface 正確に 2 つのシステムのみを接続できる物理メディアであり、したがって point to point line として設定可能ですが、X.25 や Frame Relay などのプロトコルを使用して link layer networking をサポートするようにも設定可能です。link layer network は別のシステムをスイッチに接続し、より上位の通信層が接続上に仮想回線を多重化します。Point to Point Line を参照してください。

IGP Interior Gateway Protocol。Autonomous System (AS) 内で routing information を配布するプロトコル。EGP を参照してください。

Interface IP Address ルーターの特定のインタフェースに割り当てられた IP Address と network prefix length。

Internet Address internet 内の host を識別する割り当て番号。これは 2 つの部分からなります。IP address と prefix length です。prefix length は、アドレスの最も具体的なビットのうち、network prefix を構成するビット数を示します。

IP Internet Protocol。Internet のネットワーク層プロトコル。RFC 791 で定義されたパケット交換の datagram プロトコルです。IP は信頼できる通信機能を提供しません。つまり、end-to-end や hop-by-hop の acknowledgments はありません。

IP Datagram IP Datagram は Internet Protocol における end-to-end 伝送の単位です。IP Datagram は、IP header に続いてすべての上位層データ（TCP、UDP、ICMP など）から構成されます。IP Datagram は、IP header に続いて message です。

IP Datagram は完全な IP end-to-end 伝送単位です。IP Datagram は 1 つ以上の IP Fragments から構成されます。

本メモでは、修飾のない用語 Datagram は IP Datagram を指すものと理解されるべきです。

IP Fragment IP Fragment は IP Datagram の構成要素です。IP Fragment は、IP header に続いて、元の IP Datagram の上位層の全部または一部から構成されます。

1 つ以上の IP Fragments が単一の IP Datagram を構成します。

本メモでは、修飾のない用語 Fragment は IP Fragment を指すものと理解されるべきです。

IP Packet IP Datagram または IP Fragment。

本メモでは、修飾のない用語 Packet は一般に IP Packet を指すものと理解されるべきです。

Logical [network] interface 我々は logical [network] interface を、一意の IP address によって区別される、connected network への論理パスと定義します。

Martian Filtering 無効な source または destination address を含む packet は martian とみなされ、廃棄されます。

MTU (Maximum Transmission Unit) logical interface を通じて送信または受信できる最大の packet のサイズ。このサイズには IP header が含まれますが、Link Layer headers や framing のサイズは含まれません。

Multicast 複数の hosts を宛先とする packet。broadcast を参照してください。

Multicast Address 複数の hosts によって認識可能な特別な種類の address。

Multicast Address は Functional Address または Group Address として知られることもあります。

Network Prefix IP Address のうち、システムの集合を示す部分。これは、subnet mask をアドレスと論理 AND することで、または（同等に）アドレスの最も有意なビット以外のビットをゼロに設定することで、IP Address から選択されます。

Originate packet がルーターによって送信される理由は 2 つあります。1) packet を受信して転送している、2) ルーター自体が送信のために packet を作成した（route advertisements など）。ルーターが送信のために作成した packet は、ルーターで originate（発信）されたと言われます。

Packet packet は Internet Layer と Link Layer の間のインタフェースを通じて渡されるデータ単位です。これには IP header とデータが含まれます。packet は完全な IP datagram または IP datagram の fragment である場合があります。

Path 特定のルーターから特定の destination host へと packet が通過する routers および (sub-)networks の系列。path は一方向であることに注意してください。与えられた host の対の 2 つの方向で異なる paths を持つことは珍しくありません。

Physical Network Physical Network とは、Link Layer で連続している network（または internet の一部）です。その内部構造（存在する場合）は Internet Layer に対して透過的です。

本メモでは、bridges や repeaters などの装置を使用して接続された複数の media コンポーネントは、そのような装置は IP に対して透過的であるため、単一の Physical Network とみなされます。

Physical Network Interface これは Connected Network への物理インタフェースであり、(おそらく一意の) Link-Layer address を持ちます。単一のルーター上の複数の Physical Network Interfaces は同じ Link-Layer address を共有してもよいですが、その address は同じ Physical Network 上の異なるルーター間で一意でなければなりません。

Point to Point Line 正確に 2 つのシステムのみを接続できる物理メディア。本ドキュメントでは、IP エンティティを接続するために使用される場合にのみ、このような line を指すために使用されます。General Purpose Serial Interface を参照してください。

router 複数の networks を接続する専用コンピュータ。Routers は forwarding と呼ばれるプロセスでこれらの networks 間で packets を切り替えます (switching)。このプロセスは、packet が最終目的地に配送されるまで、複数の routers によって単一の packet 上で数回繰り返される場合があります - packet を router から router へと切り替え、packet が目的地に到達するまでです。

RPF Reverse Path Forwarding - broadcast および multicast packets の next hops を推論するために使用される方法。

Silently Discard 本メモは、ルーターが受信した packet（または datagram）を Silently Discard すべき (SHOULD) いくつかのケースを指定しています。これは、ルーターがそれ以上の処理なしに packet を廃棄し、その結果として ICMP error message（セクション [4.3.2] 参照）を送信しないことを意味します。しかし、問題の診断のため、ルーターは（セクション [1.3.3] 参照）廃棄された packet の内容を含めてエラーをログに記録する能力を提供すべきであり (SHOULD)、そのイベントを統計カウンタに記録すべきです (SHOULD)。

Silently Ignore ルーターが Silently Ignore（暗黙に無視）するとは、error log または何らかの network management protocol を通じてエラー報告を生成する可能性があること以外に何のアクションも取らず、エラーの源を廃棄または無視する場合をいいます。とくに、ルーターは ICMP error message を生成しません。

Sparse Mode multicast forwarding には 2 つのパラダイムが可能です。Sparse Mode forwarding では、network layer multicast datagram は、それを要求した routers および hosts に対して data link layer multicast frame として転送されます。初期転送状態は dense-mode の逆であり、ネットワークのどの部分もデータを望んでいないと仮定します。Dense Mode を参照してください。

Specific-destination address これは、IP header に IP broadcast または IP multicast address が含まれていない限り、IP header 内の destination address と定義されます。その場合、specific-destination は packet が到着した物理インタフェースに割り当てられた IP address です。

subnet network の一部であり、物理的に独立した network である場合があり、他の部分と network address を共有し、subnet number によって区別されます。subnet と network の関係は、network と internet の関係に相当します。

subnet number internet address の一部であり、subnet を指定します。これは internet routing の目的では無視されますが、intranet routing に使用されます。

TOS Type Of Service。IP header 内のフィールドで、transport layer または application が network layer から期待する信頼性の程度を表します。

TTL Time To Live。IP header 内のフィールドで、packet が有効とみなされる期間の長さを表します。これは hop count と timer value の組み合わせです。

APPENDIX C. FUTURE DIRECTIONS (今後の方向性)

本付録は、このドキュメントの将来の改訂版が取り組む可能性がある作業を列挙します。

Router Requirements の準備において、我々はいくつかの他のアーキテクチャ上の問題に遭遇しました。これらの各々はこのドキュメントでいくらか扱われていますが、それでも IP アーキテクチャにおける未解決の問題として分類されるべきです。

ここで提示されるトピックのほとんどは、一般的に技術がまだ比較的新しく、コミュニティが運用経験を蓄積している最中であるため、具体的な要件を策定することが適切でない領域を示しています。

その他のトピックは進行中の研究領域を表しており、慎重な開発者が注視すべき領域を示しています。

(1) SNMP Version 2

(2) 追加の SNMP MIB

(7) ルーティング・プロトコル間でのルート漏洩 (leaking routes) に関するより詳細な要件

(8) ルーター・システムのセキュリティ

(9) ルーティング・プロトコルのセキュリティ

(10) インターネットワーク・プロトコル層のセキュリティ。このドキュメントを書いた当初の作業以降、IP のセキュリティを洗練させる広範な作業がありました。このセキュリティ作業をここに含めるべきです。

(12) ロード分割 (Load Splitting)

(13) フラグメントを異なるパスに沿って送信すること

(15) 同一のワイヤ上の複数の論理 (sub)net。Router Requirements はこれのサポートを要求していません。我々は、ルールの文言を正しく機能させるために注意深く行う必要があるアーキテクチャの断片（例えば、directed broadcasts の転送や Redirects の発行）のいくつかを識別する試みをし、論理インタフェースを物理インタフェースから明確に区別するよう努めました。しかし、この問題を詳細に研究したわけではなく、同一ワイヤ上の複数の論理 (sub)net が存在する場合にドキュメント内のすべてのルールが正しいということには全く確信がありません。

(15) 輻輳制御とリソース管理。IETF の専門家（Mankin と Ramakrishnan）の助言に基づき、我々は Source Quench を非推奨（SHOULD NOT）とし、それ以外に具体的なことはほとんど述べませんでした（セクション 5.3.6）。

(16) ルーターとホストの両方に共通の Link-Layer 要件ドキュメントの策定。

(17) 共通の PPP LQM アルゴリズムの策定。

(18) レイヤ間を通過する他の情報（セクション [3.2] 以上）の調査。例えば物理ネットワーク MTU、IP precedence から Link Layer priority 値へのマッピングなど。

(19) アドレス解決が失敗した場合、Link Layer は IP に通知すべきでしょうか（Link Layer priority 値の問題がある場合に IP に通知するのと同じように）？

(20) すべてのルーターに DNS リゾルバの実装を要求すべきでしょうか？

(21) ルーターを設定する際に IP アドレスを使用できる場所ならどこでも、人間のユーザーがホスト名を使用できるべきでしょうか？ ping や traceroute でも？

(22) Almquist の next hop に関するドラフト覚書および route leaking に関する覚書は、見直され、最新に更新され、公開される必要があります。

(23) precedence に対する redirect メッセージが必要かどうかを判断するための調査が必要です。不要な場合、type-of-service redirects は受け入れられるでしょうか？

(24) RIPv2 および RIP+CIDR と可変長ネットワーク・プレフィックス。

(25) BGP-4 CIDR は重要になるでしょう、そして皆が BGP-4 に賭けています。言及しないわけにはいきません。おそらく BGP-3 と BGP-4 の違いを説明し、アップグレードの問題を探る必要があります。

(26) Loose Source Route Mobile IP および一部のマルチキャストにはこれが必要になる場合があります。おそらくそれを SHOULD に格上げすべきでしょう（Fred Baker の提案に従って）。

APPENDIX D. MULTICAST ROUTING PROTOCOLS (マルチキャスト・ルーティング・プロトコル)

マルチキャストは Internet Protocol ファミリ内では比較的新しい技術です。まだ広く展開も一般的に使用もされていません。しかし、その重要性は今後数年で高まると予想されます。

この付録は、インターネットを通じたマルチキャストのルーティングのために調査されている技術のいくつかを説明します。

勤勉な実装者は、マルチキャスト機能を適切に開発するために、この分野の発展を常に把握しておくでしょう。

この付録はいかなる標準や要件も規定しません。

D.1 Introduction (導入)

マルチキャスト・ルーティング・プロトコルは、TCP/IP internet 全体での IP マルチキャスト・データグラムの転送を可能にします。一般的にこれらのアルゴリズムは、データグラムの送信元アドレスと宛先アドレスに基づいてデータグラムを転送します。さらに、データグラムは複数のマルチキャスト・グループ・メンバーに転送する必要がある場合があり、その際データグラムを複製して複数のインタフェースから送信することが必要になることがあります。

マルチキャスト・ルーティング・プロトコルの状態は、IP ユニキャストの転送に利用可能なプロトコルよりも未発達です。TCP/IP 向けに 3 つの実験的マルチキャスト・ルーティング・プロトコルが文書化されています。各々はマルチキャスト・グループのメンバーシップを監視するために IGMP プロトコル（セクション [4.4] で議論）を使用します。

D.2 Distance Vector Multicast Routing Protocol - DVMRP

[ROUTE:9] で文書化されている DVMRP は、Distance Vector または Bellman-Ford 技術に基づいています。これはマルチキャスト・データグラムのみをルーティングし、単一の Autonomous System 内でそうします。DVMRP は [ROUTE:10] で説明されている Truncated Reverse Path Broadcasting アルゴリズムの実装です。さらに、マルチキャスト・ルーティング機能を持たない IP ドメインを通じた IP マルチキャストのトンネリングを規定しています。

D.3 Multicast Extensions to OSPF - MOSPF

現在開発中の MOSPF は、OSPF への下位互換性のある追加であり、Autonomous System 内での IP マルチキャストとユニキャストの両方の転送を可能にします。MOSPF ルーターはルーティング・ドメイン内の OSPF ルーターと混在でき、ユニキャストの転送において相互運用します。OSPF は link-state または SPF ベースのプロトコルです。

link state advertisements でグループ・メンバーシップを正確に示すことで、MOSPF ルーターはデータグラムの送信元を根とするツリーとしてマルチキャスト・データグラムのパスを計算できます。グループ・メンバーを含まないそれらのブランチは破棄でき、不必要なデータグラム転送ホップを排除します。

D.4 Protocol Independent Multicast - PIM

現在開発中の PIM は、既存のユニキャスト基盤の上で動作するマルチキャスト・ルーティング・プロトコルです。PIM は dense および sparse の両方のグループ・メンバーシップを提供します。これは他のプロトコルとは異なり、sparse グループに対して明示的な join モデルを使用します。join は共有ツリーで発生し、per-source ツリーに切り替えることができます。帯域幅が豊富でグループ・メンバーシップが dense な場合、すべてのリンクにデータをフラッディングし、その後グループ・メンバーがいない例外ケースをプルーニングすることで、オーバヘッドを削減できます。

APPENDIX E Additional Next-Hop Selection Algorithms (追加のネクストホップ選択アルゴリズム)

セクション [5.2.4.3] は、ルーターが packet の next-hop を選択する際に使用すべき (SHOULD) アルゴリズムを規定しています。

この付録は next-hop 選択問題に対する歴史的観点を提供します。また、インターネットで見られる可能性のあるいくつかの追加の pruning 規則と next-hop 選択アルゴリズムを提示します。

この付録は、Philip Almquist による初期の未公刊の著作『Ruminations on the Next Hop』から引かれた資料を提示します。

この付録はいかなる標準や要件も規定しません。

E.1. Some Historical Perspective (歴史的観点)

トピックの歴史を簡単に振り返ることは有用です。まず、ルーターがルーティング決定を行う方法として「クラシック・モデル」と呼ばれるものから始めます。このモデルは IP よりも古いものです。このモデルでは、ルーターは RIP などの単一のルーティング・プロトコルを話します。そのプロトコルはルーターの Forwarding Information Base (FIB) の内容を完全に決定します。ルート検索アルゴリズムは自明です。ルーターは FIB 内で、packet の destination address の network prefix 部分と完全に一致する destination 属性を持つルートを探します。1 つ見つかればそれが使用され、見つからなければ destination は到達不能です。ルーティング・プロトコルは各 destination に対して最大 1 つのルートしか保持しないため、同じ destination に一致する複数のルートがある場合にどうするかという問題は生じません。

長年にわたり、このクラシック・モデルは小さな方法で拡張されてきました。default routes、subnets、host routes の導入により、ある意味で destination に一致する複数のルーティング・テーブル項目を持つことが可能になりました。これは、ルートの階層があるという合意によって容易に解決されました。host routes は subnet routes より優先され、subnet routes は net routes より優先され、net routes は default routes より優先されます。

可変長サブネット・マスク（可変長 network prefixes）をサポートする技術の導入により、一般的なアプローチは同じままでしたが、その記述はやや複雑になりました。network prefixes は、アーキテクチャの意識的な単純化と正規化として導入されました。我々は現在、network prefix への各ルートに、それに関連する prefix length があると言います。この prefix length は、prefix 内のビット数を示します。これは従来の subnet mask を使用しても表現できます。ルートは、ルートの network prefix 内の各有意ビットが packet の destination address 内の対応するビットと一致しない限り、packet をルーティングするために使用できません。マスクにより多くのビットが設定されたルートは、より少ないビットが設定されたルートよりも優先されます。これは単に上記のルートの階層の一般化であり、このメモの残りの部分では longest match を優先するルートの選択と呼ばれます。

クラシック・モデルが拡張されたもう 1 つの方法は、ルーティング・プロトコルがルーティング・テーブルの内容を完全に制御するという概念をわずかに緩和したことです。まず、static routes が導入されました。初めて、同じ destination に 2 つのルート（1 つは動的、もう 1 つは静的）を同時に持つことが可能になりました。このような場合、ルーターは静的ルートか動的ルートのどちらを優先するかを決定するポリシー（場合によっては設定可能、場合によってはルーターのソフトウェアの作成者が選択）を持つ必要がありました。しかし、このポリシーは longest match が使用するルートを一意に決定しなかった場合の tie-breaker としてのみ使用されました。したがって、例えば、ポリシーが静的ルートを動的ルートより優先する場合でも、静的 default route が動的 net route より優先されることはありません。

クラシック・モデルは、ドメイン間 (inter-domain) ルーティング・プロトコルが発明されたとき、さらに拡張される必要がありました。従来のルーティング・プロトコルは「interior gateway protocols」(IGPs) と呼ばれるようになり、各インターネット・サイトには奇妙な新しい獣である「exterior gateway」が存在しました。これは、自身のサイト内の他のルーターと IGP を話すと同時に、いくつかの「BBN Core Gateways」（当時インターネット・バックボーンを構成していたルーター）と EGP を話すルーターです。両方のプロトコルがルーターのルーティング・テーブルの内容を決定しようとしました。理論的には、ルーターが同じ destination に対して 3 つのルート（EGP、IGP、static）を持つ可能性があります。

当時のインターネット・トポロジのため、IGP ルートを EGP ルートより優先するポリシーによってルーターが最もうまく処理できるだろうということは、ほとんど議論なく解決されました。しかし、longest match の厳格さは疑われることなく残りました。IGP から学習した default route が、EGP から学習した net route より優先されることは決してありません。

インターネット・トポロジ、ひいてはインターネット内のルーティングはそれ以来かなり進化しましたが、このわずかに拡張されたバージョンのクラシック・モデルは（BGP が EGP を置き換えたことを除いて）今日までそのまま生き残っています。概念的には（そして多くの場合実装上も）各ルーターはルーティング・テーブルと 1 つ以上のルーティング・プロトコル・プロセスを持ちます。これらの各プロセスは好きな項目を追加でき、自身が作成した項目を削除または変更できます。packet をルーティングする際、ルーターは longest match を使用し、tie-break のためにポリシー機構を補って、最良のルートを選択します。この拡張されたクラシック・モデルはうまく機能してきましたが、いくつかの欠点があります。

o サービス品質 (quality of service) や MTU などのパス特性を無視します（拡張して考慮することは可能ですが）。

o pure longest match とは異なるルート検索アルゴリズムを必要とするルーティング・プロトコル（OSPF や Integrated IS-IS など）をサポートしません。

o tie-breaking 機構がどうあるべきかについては確固たる合意がありません。tie-breaking 機構は、ネットワーク管理者が「正しい」ルートと考えるものをルーターが常に選択するように設定することが、不可能でないにしても困難であることが多いことが判明しています。

E.2. Additional Pruning Rules (追加の Pruning 規則)

セクション [5.2.4.3] は、FIB からルートを選択するために使用するいくつかの pruning 規則を定義しました。使用できる他の規則もあります。

o OSPF Route Class 領域 (areas) を持つ、または internal と external のルートを区別するルーティング・プロトコルは、ルートを、ルートの計算に使用された情報の種類によってクラスに分割します。ルートは、利用可能な最も優先されるクラスから常に選択され、ない場合は 2 番目に優先されるクラスから選択され、以下同様です。OSPF では、クラス（最も優先されるものから最も優先されないものの順）は、intra-area、inter-area、type 1 external（内部メトリックを持つ外部ルート）、および type 2 external です。さらに追加の細かい点として、ルーターは intra-area ルートを使用して到達可能であるべきアドレスを知るように設定され、intra-area ルートが利用できない場合でも、これらの destinations に到達するために inter-area または external ルートを使用しません。

より正確には、各ルートにはルーティング・プロトコルによって割り当てられる route.class と呼ばれるクラス属性があると仮定します。候補ルートの集合が、route.class = intra-area であるものを含むかどうかが調べられます。含む場合、route.class = intra-area でないものを除くすべてのルートが破棄されます。そうでない場合、ルーターは packet の destination がローカル・エリア用に設定されたアドレス範囲内に収まるかどうかをチェックします。収まる場合、候補ルートの集合全体が削除されます。そうでない場合、候補ルートの集合が route.class = inter-area であるものを含むかどうかが調べられます。含む場合、route.class = inter-area でないものを除くすべてのルートが破棄されます。そうでない場合、候補ルートの集合が route.class = type 1 external であるものを含むかどうかが調べられます。含む場合、route.class = type 1 external でないものを除くすべてのルートが破棄されます。

o IS-IS Route Class IS-IS route classes は OSPF のものと全く同じように機能します。しかし、Integrated IS-IS によって定義されるクラスの集合は異なるため、IS-IS route classes と OSPF route classes の間に 1 対 1 のマッピングはありません。Integrated IS-IS によって使用されるルート・クラスは（最も優先されるものから最も優先されないものの順に）intra-area、inter-area、external です。

Integrated IS-IS の internal class は OSPF の internal class と等価です。同様に、Integrated IS-IS の external class は OSPF の type 2 external class と等価です。しかし、Integrated IS-IS は inter-area ルートと内部メトリックを持つ external ルートを区別しない - 両方とも inter-area ルートと見なされます。したがって、OSPF は内部メトリックを持つ外部ルートよりも真の inter-area ルートを優先しますが、Integrated IS-IS は 2 つのタイプのルートに等しい優先度を与えます。

o IDPR Policy Policy の特定のケース。IETF の Inter-domain Policy Routing Working Group は、インターネットで真のポリシー・ベースのルーティングをサポートするための Inter-Domain Policy Routing (IDPR) と呼ばれるルーティング・プロトコルを考案しています。特定のヘッダ属性の組み合わせ（source と destination アドレスの特定の組み合わせや特別な IDPR source route オプションなど）を持つ packet は、IDPR プロトコルによって提供されるルートを使用することが要求されます。したがって、他の Policy pruning 規則とは異なり、IDPR Policy は Basic Match 以外のいかなる pruning 規則よりも前に適用される必要があります。

具体的には、IDPR Policy は転送される packet を調べ、その属性がポリシー・ベースのルートを使用して転送されることを要求するかどうかを確認します。要求する場合、IDPR Policy は IDPR プロトコルによって提供されないすべてのルートを削除します。

E.3 Some Route Lookup Algorithms (いくつかのルート検索アルゴリズム)

このセクションは、使用されている、または提案されたいくつかのルート検索アルゴリズムを検討します。各々は、それが使用する pruning 規則の系列を与えることによって記述されます。各アルゴリズムの長所と短所が提示されます。

E.3.1 The Revised Classic Algorithm (改訂クラシック・アルゴリズム)

Revised Classic Algorithm は、セクション [E.1] で議論された伝統的アルゴリズムの形式です。このアルゴリズムのステップは次のとおりです。

Basic match
Longest match
Best metric
Policy

一部の実装は Policy ステップを省略します。これは、ルートが比較不能なメトリック（異なるルーティング・ドメインから学習されたため）を持つ場合にのみ必要となるためです。

このアルゴリズムの利点は次のとおりです。

(1) 広く実装されています。

(2) Policy ステップ（実装者が任意の複雑さにできる）を除き、アルゴリズムは理解も実装も簡単です。

その欠点は次のとおりです。

(1) IS-IS や OSPF のルート・クラスを扱えないため、Integrated IS-IS や OSPF には使用できません。

(2) TOS やその他のパス属性を扱いません。

(3) ポリシー機構はいかなる方法でも標準化されておらず、したがって多くの場合実装固有です。これは実装者（適切なポリシー機構を発明する必要がある）とユーザー（機構の使用方法を学ぶ必要がある）の両方に余分な作業をもたらします。この標準化された機構の欠如は、異なるベンダーのルーターに対して一貫した設定を構築することを困難にします。これはマルチベンダ相互運用性に対する重大な実践的障害を提示します。

(4) ベンダーが現在提供している専有のポリシー機構は、インターネットの複雑な部分ではしばしば不十分です。

(5) このアルゴリズムは、一般に利用可能なドキュメントや標準に書き留められたことがありません。事実上、インターネットの folklore の一部です。

E.3.2 The Variant Router Requirements Algorithm (変種 Router Requirements アルゴリズム)

Router Requirements Working Group の一部のメンバーは、セクション [5.2.4.3] で説明されたアルゴリズムのわずかな変種を提案しました。この変種では、要求された type of service に一致することは、目的地アドレスのできるだけ多くに一致することよりも重要であると見なされます（より重要ではなく）。例えば、このアルゴリズムは、デフォルト type of service を持つ network route よりも、正しい type of service を持つ default route を優先します。一方、[5.2.4.3] のアルゴリズムは反対の選択をします。

このアルゴリズムのステップは次のとおりです。

Basic match
Weak TOS
Longest match
Best metric
Policy

このアルゴリズムの支持者と通常の Router Requirements Algorithm の支持者との間の議論は、それぞれの側が、自身のアルゴリズムが相手のアルゴリズムよりも単純で直感的なルーティングをもたらすケースを示せることを示唆しています。この変種は、[5.2.4.3] で規定されたアルゴリズムと同じ長所と短所の集合を持ちますが、Longest Match の前に Weak TOS で pruning することは、このアルゴリズムを標準の Router Requirements Algorithm よりも OSPF および Integrated IS-IS と互換性の低いものにします。

E.3.3 The OSPF Algorithm (OSPF アルゴリズム)

OSPF は、1 つの決定的な違いを除いて、Router Requirements Algorithm と事実上同一のアルゴリズムを使用します。OSPF は OSPF route classes を考慮します。

アルゴリズムは次のとおりです。

Basic match
OSPF route class
Longest match
Weak TOS
Best metric
Policy

type of service のサポートは常に存在するとは限りません。存在しない場合、当然 4 番目のステップは省略されます。

このアルゴリズムは Revised Classic Algorithm に対していくつかの利点があります。

(1) type of service ルーティングをサポートします。

(2) その規則は書き留められており、単なるインターネットの folklore の一部ではありません。

(3) （当然ながら）OSPF で動作します。

しかし、このアルゴリズムは Revised Classic Algorithm のいくつかの欠点も保持しています。

(1) type of service 以外のパス特性（例えば MTU）は無視されます。

(2) Revised Classic Algorithm と同様に、Policy ステップの詳細（あるいは存在そのもの）は実装者の裁量に任されています。

OSPF Algorithm にはさらに別の欠点（Revised Classic Algorithm にはない）もあります。OSPF 内部（intra-area または inter-area）ルートは、destination address のより少ないビットに一致する場合であっても、常に他のルーティング・プロトコルから学習したルートよりも優れていると見なされます。これは一部のネットワークでは不適切なポリシー決定です。

最後に、OSPF Algorithm の TOS サポートは、非ゼロの TOS 値を持つ packet を転送する際に、TOS をサポートするルーティング・プロトコルが暗黙的に優先されるという欠陥に悩まされていることは注目に値します。これは場合によっては適切でない可能性があります。

E.3.4 The Integrated IS-IS Algorithm (Integrated IS-IS アルゴリズム)

Integrated IS-IS は、OSPF Algorithm と似ているが全く同一ではないアルゴリズムを使用します。Integrated IS-IS は異なるルート・クラスの集合を使用し、type of service の扱いがわずかに異なります。アルゴリズムは次のとおりです。

Basic Match
IS-IS Route Classes
Longest Match
Weak TOS
Best Metric
Policy

Integrated IS-IS は Weak TOS を使用しますが、プロトコルは IP header 内の TOS フィールドの可能な値のうち、小さな特定のサブセットに対するルートのみを運ぶことができます。TOS フィールドに他の値を含む packet は、デフォルト TOS を使用してルーティングされます。

type of service のサポートはオプションです。無効にされた場合、4 番目のステップは省略されます。OSPF と同様に、仕様には Policy ステップは含まれません。

このアルゴリズムは Revised Classic Algorithm に対していくつかの利点があります。

(1) type of service ルーティングをサポートします。 (2) その規則は書き留められており、単なるインターネットの folklore の一部ではありません。 (3) （当然ながら）Integrated IS-IS で動作します。

しかし、このアルゴリズムは Revised Classic Algorithm のいくつかの欠点も保持しています。

(1) type of service 以外のパス特性（例えば MTU）は無視されます。 (2) Revised Classic Algorithm と同様に、Policy ステップの詳細（あるいは存在そのもの）は実装者の裁量に任されています。 (3) IS-IS route classes と OSPF route classes の違いのため、OSPF では動作しません。また、IS-IS は可能な TOS 値のサブセットのみをサポートするため、Integrated IS-IS アルゴリズムのいくつかの明白な実装では OSPF の TOS の解釈をサポートしません。

Integrated IS-IS Algorithm にはさらに別の欠点（Revised Classic Algorithm にはない）もあります。IS-IS 内部（intra-area または inter-area）ルートは、IS-IS ルートが destination address のより少ないビットに一致し、要求された type of service を提供しない場合であっても、常に他のルーティング・プロトコルから学習したルートよりも優れていると見なされます。これはすべての場合に適切とは限らないポリシー決定です。

最後に、Integrated IS-IS Algorithm の TOS サポートは、OSPF Algorithm について指摘されたものと同じ欠陥に悩まされていることは注目に値します。

Security Considerations (セキュリティに関する考慮事項)

このドキュメントの焦点は相互運用性でありセキュリティではありませんが、ネットワーク・セキュリティに何らかの影響を及ぼすセクションが明らかに多数存在します。

セキュリティは人によって異なる意味を持ちます。ルーターの観点からのセキュリティとは、自身のネットワークを運用可能な状態に保つことを助け、さらにインターネット全体を健全に保つことを助けるものです。このドキュメントの目的上、我々が関心を持つセキュリティ・サービスは、サービス拒否 (denial of service)、完全性 (integrity)、およびそれらに適用される認証 (authentication) です。セキュリティ・サービスとしてのプライバシー (privacy) は重要ですが、少なくともこのドキュメントの日付時点では、ルーターの懸念の周辺にすぎません。

このドキュメントのいくつかの箇所には「Security Considerations」という題のセクションがあります。これらのセクションは、議論中の一般的なトピックに適用される具体的な考慮事項を議論します。

このドキュメントが「これを行えばルーター/ネットワークは安全になる」と言うことはめったにありません。むしろ、「これは良い考えであり、それを行えば、インターネットとローカル・システムのセキュリティを一般的に改善するかもしれない」と言います。

残念ながら、これが現時点での最新技術の状態です。ルーターが関心を持つネットワーク・プロトコルのほとんどに、合理的な組み込みセキュリティ機能はほとんど、あるいは全くありません。業界とプロトコル設計者は、これらの問題に取り組み続けています。進展はありますが、BGP や OSPF ルーティング・プロトコルで利用可能なピア・ツー・ピア認証などの小さな一歩にすぎません。

とくに、このドキュメントはネットワーク・セキュリティの開発と強化に関する現在の研究に注目します。本稿執筆時点（1993年12月）で進行中の研究、開発、およびエンジニアリングの具体的な分野は、IP Security、SNMP Security、および共通認証技術です。

上記すべてにもかかわらず、ベンダーとユーザーの両方がルーターのセキュリティを改善するためにできることがあります。ベンダーは Trusted Computer System Interpretation [INTRO:8] のコピーを入手すべきです (SHOULD)。ベンダーがこれらのガイドラインに基づく正式な検証に自社デバイスを提出することを決定しなかったとしても、この出版物はコンピューティング・デバイスの一般的なセキュリティ設計と実践に関する優れたガイダンスを提供します。

APPENDIX F. HISTORICAL ROUTING PROTOCOLS (歴史的ルーティング・プロトコル)

本付録は、歴史的なルーティング・プロトコル EGP、RIP、および GGP に関する背景を提供します。プロトコルの規定 (MUST/SHOULD 要件や実装アルゴリズム) は、参照のために英語原文のまま記載しています。

APPENDIX F: HISTORICAL ROUTING PROTOCOLS

Certain routing protocols are common in the Internet, but the authors of this document cannot in good conscience recommend their use. This is not because they do not work correctly, but because the characteristics of the Internet assumed in their design (simple routing, no policy, a single "core router" network under common administration, limited complexity, or limited network diameter) are not attributes of today's Internet. Those parts of the Internet that still use them are generally limited "fringe" domains with limited complexity.

As a matter of good faith, collected wisdom concerning their implementation is recorded in this section.

F.1 EXTERIOR GATEWAY PROTOCOL - EGP

F.1.1 Introduction

Exterior Gateway Protocol (EGP) は、同じまたは異なる自律システム (Autonomous Systems) のルーター間で到達可能性情報を交換するために使用される EGP を規定しています。EGP 更新メッセージ内の距離フィールドに対する標準的な解釈（つまりメトリック）がないため、EGP はルーティング・プロトコルとは見なされません。したがって、距離は同じ AS のルーター間でのみ比較可能です。しかし、これは隣接ルーターおよび非隣接ルーターへのルートの両方について、高品質の到達可能性情報を提供するように設計されています。

EGP は [ROUTE:6] で定義されています。実装者はほぼ確実に [ROUTE:7] および [ROUTE:8] も読むことを望むでしょう。それらには有用な説明と背景資料が含まれているためです。

DISCUSSION 現在の EGP 仕様には重大な制限があり、最も重要なのは、ルーターがルーターの自律システム内から到達可能なネットワークのみをアドバタイズすることを制限することです。この第三者 EGP 情報の伝播を防ぐ制限は、長期間存続するルーティング・ループを防ぐためのものです。これは事実上、EGP を 2 レベルの階層に制限します。

  RFC-975 は EGP 仕様の一部ではなく、無視されるべきです。

F.1.2 Protocol Walk-through

  Indirect Neighbors: RFC-888, page 26

     An implementation of EGP MUST include indirect neighbor
     support.

  Polling Intervals: RFC-904, page 10

     The interval between Hello command retransmissions and the
     interval between Poll retransmissions SHOULD be configurable
     but there MUST be a minimum value defined.

     The interval at which an implementation will respond to Hello
     commands and Poll commands SHOULD be configurable but there
     MUST be a minimum value defined.

  Network Reachability: RFC-904, page 15

An implementation MUST default to not providing the external list of routers in other autonomous systems; only the internal list of routers together with the nets that are reachable through those routers should be included in an Update Response/Indication packet. However, an implementation MAY elect to provide a configuration option enabling the external list to be provided. An implementation MUST NOT include in the external list routers that were learned through the external list provided by a router in another autonomous system. An implementation MUST NOT send a network back to the autonomous system from which it is learned, i.e. it MUST do split- horizon on an autonomous system level.

If more than 255 internal or 255 external routers need to be specified in a Network Reachability update, the networks reachable from routers that can not be listed MUST be merged into the list for one of the listed routers. Which of the listed routers is chosen for this purpose SHOULD be user configurable, but SHOULD default to the source address of the EGP update being generated.

An EGP update contains a series of blocks of network numbers, where each block contains a list of network numbers reachable at a particular distance through a particular router. If more than 255 networks are reachable at a particular distance through a particular router, they are split into multiple blocks (all of which have the same distance). Similarly, if more than 255 blocks are required to list the networks reachable through a particular router, the router's address is listed as many times as necessary to include all the blocks in the update.

Unsolicited Updates: RFC-904, page 16

If a network is shared with the peer, an implementation MUST send an unsolicited update upon entry to the Up state if the source network is the shared network.

Neighbor Reachability: RFC-904, page 6, 13-15

The table on page 6 that describes the values of j and k (the neighbor up and down thresholds) is incorrect. It is reproduced correctly here:

  Name    Active  Passive Description
  -----------------------------------------------
   j         3       1    neighbor-up threshold
   k         1       0    neighbor-down threshold

The value for k in passive mode also specified incorrectly in RFC- 904, page 14 The values in parenthesis should read:

  (j = 1, k = 0, and T3/T1 = 4)

As an optimization, an implementation can refrain from sending a Hello command when a Poll is due. If an implementation does so, it SHOULD provide a user configurable option to disable this optimization.

Abort timer: RFC-904, pages 6, 12, 13

An EGP implementation MUST include support for the abort timer (as documented in section 4.1.4 of RFC-904). An implementation SHOULD use the abort timer in the Idle state to automatically issue a Start event to restart the protocol machine. Recommended values are P4 for a critical error (Administratively prohibited, Protocol Violation and Parameter Problem) and P5 for all others. The abort timer SHOULD NOT be started when a Stop event was manually initiated (such as through a network management protocol).

Cease command received in Idle state: RFC-904, page 13

When the EGP state machine is in the Idle state, it MUST reply to Cease commands with a Cease-ack response.

Hello Polling Mode: RFC-904, page 11

An EGP implementation MUST include support for both active and passive polling modes.

Neighbor Acquisition Messages: RFC-904, page 18

As noted the Hello and Poll Intervals should only be present in Request and Confirm messages. Therefore the length of an EGP Neighbor Acquisition Message is 14 bytes for a Request or Confirm message and 10 bytes for a Refuse, Cease or Cease-ack message. Implementations MUST NOT send 14 bytes for Refuse, Cease or Cease-ack messages but MUST allow for implementations that send 14 bytes for these messages.

Sequence Numbers: RFC-904, page 10

Response or indication packets received with a sequence number not equal to S MUST be discarded. The send sequence number S MUST be incremented just before the time a Poll command is sent and at no other times.

F.2 ROUTING INFORMATION PROTOCOL - RIP

F.2.1 Introduction

RIP is specified in [ROUTE:3]. Although RIP is still quite important in the Internet, it is being replaced in sophisticated applications by more modern IGPs such as the ones described above. A router implementing RIP SHOULD implement RIP Version 2 [ROUTE:?], as it supports CIDR routes. If occasional access networking is in use, a router implementing RIP SHOULD implement Demand RIP [ROUTE:?].

Another common use for RIP is as a router discovery protocol. Section [4.3.3.10] briefly touches upon this subject.

F.2.2 Protocol Walk-Through

Dealing with changes in topology: [ROUTE:3], page 11

    An implementation of RIP MUST provide a means for timing out
    routes.  Since messages are occasionally lost, implementations
    MUST NOT invalidate a route based on a single missed update.

    Implementations MUST by default wait six times the update
    interval before invalidating a route.  A router MAY have
    configuration options to alter this value.

DISCUSSION It is important to routing stability that all routers in a RIP autonomous system use similar timeout value for invalidating routes, and therefore it is important that an implementation default to the timeout value specified in the RIP specification.

  However, that timeout value is too conservative in environments
  where packet loss is reasonably rare.  In such an environment, a
  network manager may wish to be able to decrease the timeout period
  to promote faster recovery from failures.

IMPLEMENTATION There is a very simple mechanism that a router may use to meet the requirement to invalidate routes promptly after they time out. Whenever the router scans the routing table to see if any routes have timed out, it also notes the age of the least recently updated route that has not yet timed out. Subtracting this age from the timeout period gives the amount of time until the router again needs to scan the table for timed out routes.

Split Horizon: [ROUTE:3], page 14-15

An implementation of RIP MUST implement split horizon, a scheme used for avoiding problems caused by including routes in updates sent to the router from which they were learned.

An implementation of RIP SHOULD implement Split horizon with poisoned reverse, a variant of split horizon that includes routes learned from a router sent to that router, but sets their metric to infinity. Because of the routing overhead that may be incurred by implementing split horizon with poisoned reverse, implementations MAY include an option to select whether poisoned reverse is in effect. An implementation SHOULD limit the time in which it sends reverse routes at an infinite metric.

IMPLEMENTATION Each of the following algorithms can be used to limit the time for which poisoned reverse is applied to a route. The first algorithm is more complex but does a more thorough job of limiting poisoned reverse to only those cases where it is necessary.

  The goal of both algorithms is to ensure that poison reverse is
  done for any destination whose route has changed in the last Route
  Lifetime (typically 180 seconds), unless it can be sure that the
  previous route used the same output interface.  The Route Lifetime
  is used because that is the amount of time RIP will keep around an
  old route before declaring it stale.

  The time intervals (and derived variables) used in the following
  algorithms are as follows:

  Tu The Update Timer; the number of seconds between RIP updates.
       This typically defaults to 30 seconds.

  Rl The Route Lifetime, in seconds.  This is the amount of time
       that a route is presumed to be good, without requiring an
       update.  This typically defaults to 180 seconds.

  Ul The Update Loss; the number of consecutive updates that have to
       be lost or fail to mention a route before RIP deletes the
       route.  Ul is calculated to be (Rl/Tu)+1.  The +1 is to
       account for the fact that the first time the ifcounter is
       decremented will be less than Tu seconds after it is
       initialized.  Typically, Ul will be 7: (180/30)+1.

  In The value to set ifcounter to when a destination is newly
       learned.  This value is Ul-4, where the 4 is RIP's garbage
       collection timer/30

  The first algorithm is:

  - Associated with each destination is a counter, called the
     ifcounter below.  Poison reverse is done for any route whose
     destination's ifcounter is greater than zero.

  - After a regular (not triggered or in response to a request)
     update is sent, all the non-zero ifcounters are decremented by
     one.

  - When a route to a destination is created, its ifcounter is set
     as follows:

     - If the new route is superseding a valid route, and the old
        route used a different (logical) output interface, then the
        ifcounter is set to Ul.

     - If the new route is superseding a stale route, and the old
        route used a different (logical) output interface, then the
        ifcounter is set to MAX(0, Ul - INT(seconds that the route
        has been stale/Ut).

     - If there was no previous route to the destination, the
        ifcounter is set to In.

     - Otherwise, the ifcounter is set to zero

  - RIP also maintains a timer, called the resettimer below.  Poison
     reverse is done on all routes whenever resettimer has not
     expired (regardless of the ifcounter values).

  - When RIP is started, restarted, reset, or otherwise has its
     routing table cleared, it sets the resettimer to go off in Rl
     seconds.

  The second algorithm is identical to the first except that:

  - The rules which set the ifcounter to non-zero values are changed
     to always set it to Rl/Tu, and

  - The resettimer is eliminated.

Triggered updates: [ROUTE:3], page 15-16; page 29

  Triggered updates (also called flash updates) are a mechanism for
  immediately notifying a router's neighbors when the router adds or
  deletes routes or changes their metrics.  A router MUST send a
  triggered update when routes are deleted or their metrics are
  increased.  A router MAY send a triggered update when routes are
  added or their metrics decreased.

  Since triggered updates can cause excessive routing overhead,
  implementations MUST use the following mechanism to limit the
  frequency of triggered updates:

  (1) When a router sends a triggered update, it sets a timer to a
       random time between one and five seconds in the future.  The
       router must not generate additional triggered updates before
       this timer expires.

  (2) If the router would generate a triggered update during this
       interval it sets a flag indicating that a triggered update is
       desired.  The router also logs the desired triggered update.

  (3) When the triggered update timer expires, the router checks the
       triggered update flag.  If the flag is set then the router
       sends a single triggered update which includes all the
       changes that were logged.  The router then clears the flag
       and, since a triggered update was sent, restarts this
       algorithm.

  (4) The flag is also cleared whenever a regular update is sent.

  Triggered updates SHOULD include all routes that have changed
  since the most recent regular (non-triggered) update.  Triggered
  updates MUST NOT include routes that have not changed since the
  most recent regular update.

DISCUSSION Sending all routes, whether they have changed recently or not, is unacceptable in triggered updates because the tremendous size of many Internet routing tables could otherwise result in considerable bandwidth being wasted on triggered updates.

Use of UDP: [ROUTE:3], page 18-19.

RIP packets sent to an IP broadcast address SHOULD have their initial TTL set to one.

Note that to comply with Section [6.1] of this memo, a router SHOULD use UDP checksums in RIP packets that it originates, MUST discard RIP packets received with invalid UDP checksums, but MUST NOT discard received RIP packets simply because they do not contain UDP checksums.

Addressing Considerations: [ROUTE:3], page 22

A RIP implementation SHOULD support host routes. If it does not, it MUST (as described on page 27 of [ROUTE:3]) ignore host routes in received updates. A router MAY log ignored hosts routes.

The special address 0.0.0.0 is used to describe a default route. A default route is used as the route of last resort (i.e., when a route to the specific net does not exist in the routing table). The router MUST be able to create a RIP entry for the address 0.0.0.0.

Input Processing - Response: [ROUTE:3], page 26

When processing an update, the following validity checks MUST be performed:

o The response MUST be from UDP port 520.

o The source address MUST be on a directly connected subnet (or on a directly connected, non-subnetted network) to be considered valid.

o The source address MUST NOT be one of the router's addresses.

DISCUSSION Some networks, media, and interfaces allow a sending node to receive packets that it broadcasts. A router must not accept its own packets as valid routing updates and process them. The last requirement prevents a router from accepting its own routing updates and processing them (on the assumption that they were sent by some other router on the network).

An implementation MUST NOT replace an existing route if the metric received is equal to the existing metric except in accordance with the following heuristic.

An implementation MAY choose to implement the following heuristic to deal with the above situation. Normally, it is useless to change the route to a network from one router to another if both are advertised at the same metric. However, the route being advertised by one of the routers may be in the process of timing out. Instead of waiting for the route to timeout, the new route can be used after a specified amount of time has elapsed. If this heuristic is implemented, it MUST wait at least halfway to the expiration point before the new route is installed.

F.2.3 Specific Issues

RIP Shutdown

 An implementation of RIP SHOULD provide for a graceful shutdown
 using the following steps:

 (1) Input processing is terminated,

 (2) Four updates are generated at random intervals of between two
      and four seconds, These updates contain all routes that were
      previously announced, but with some metric changes.  Routes
      that were being announced at a metric of infinity should
      continue to use this metric.  Routes that had been announced
      with a non-infinite metric should be announced with a metric
      of 15 (infinity - 1).

DISCUSSION The metric used for the above really ought to be 16 (infinity); setting it to 15 is a kludge to avoid breaking certain old hosts that wiretap the RIP protocol. Such a host will (erroneously) abort a TCP connection if it tries to send a datagram on the connection while the host has no route to the destination (even if the period when the host has no route lasts only a few seconds while RIP chooses an alternate path to the destination).

RIP Split Horizon and Static Routes

Split horizon SHOULD be applied to static routes by default. An implementation SHOULD provide a way to specify, per static route, that split horizon should not be applied to this route.

F.3 GATEWAY TO GATEWAY PROTOCOL - GGP

The Gateway to Gateway protocol is considered obsolete and SHOULD NOT be implemented.

Acknowledgments

O that we now had here But one ten thousand of those men in England That do no work to-day!

What's he that wishes so? My cousin Westmoreland? No, my fair cousin: If we are mark'd to die, we are enow To do our country loss; and if to live, The fewer men, the greater share of honour. God's will! I pray thee, wish not one man more. By Jove, I am not covetous for gold, Nor care I who doth feed upon my cost; It yearns me not if men my garments wear; Such outward things dwell not in my desires: But if it be a sin to covet honour, I am the most offending soul alive. No, faith, my coz, wish not a man from England: God's peace! I would not lose so great an honour As one man more, methinks, would share from me For the best hope I have. O, do not wish one more! Rather proclaim it, Westmoreland, through my host, That he which hath no stomach to this fight, Let him depart; his passport shall be made And crowns for convoy put into his purse: We would not die in that man's company That fears his fellowship to die with us. This day is called the feast of Crispian: He that outlives this day, and comes safe home, Will stand a tip-toe when the day is named, And rouse him at the name of Crispian. He that shall live this day, and see old age, Will yearly on the vigil feast his neighbours, And say 'To-morrow is Saint Crispian:' Then will he strip his sleeve and show his scars. And say 'These wounds I had on Crispin's day.' Old men forget: yet all shall be forgot, But he'll remember with advantages What feats he did that day: then shall our names. Familiar in his mouth as household words Harry the king, Bedford and Exeter, Warwick and Talbot, Salisbury and Gloucester,

Be in their flowing cups freshly remember'd. This story shall the good man teach his son; And Crispin Crispian shall ne'er go by, From this day to the ending of the world, But we in it shall be remember'd; We few, we happy few, we band of brothers; For he to-day that sheds his blood with me Shall be my brother; be he ne'er so vile, This day shall gentle his condition: And gentlemen in England now a-bed Shall think themselves accursed they were not here, And hold their manhoods cheap whiles any speaks That fought with us upon Saint Crispin's day.

                               -- William Shakespeare

This memo is a product of the IETF's Router Requirements Working Group. A memo such as this one is of necessity the work of many more people than could be listed here. A wide variety of vendors, network managers, and other experts from the Internet community graciously contributed their time and wisdom to improve the quality of this memo. The editor wishes to extend sincere thanks to all of them.

The current editor also wishes to single out and extend his heartfelt gratitude and appreciation to the original editor of this document; Philip Almquist. Without Philip's work, both as the original editor and as the Chair of the working group, this document would not have been produced. He also wishes to express deep and heartfelt gratitude to the previous editor, Frank Kastenholz. Frank changed the original document from a collection of information to a useful description of IP technology - in his words, a "snapshot" of the technology in 1991. One can only hope that this snapshot, of the technology in 1994, is as clear.

Philip Almquist, Jeffrey Burgan, Frank Kastenholz, and Cathy Wittbrodt each wrote major chapters of this memo. Others who made major contributions to the document included Bill Barns, Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve Knowles, Yoni Malachi, Michael Reilly, and Walt Wimer.

Additional text came from Andy Malis, Paul Traina, Art Berggreen, John Cavanaugh, Ross Callon, John Lekashman, Brian Lloyd, Gary Malkin, Milo Medin, John Moy, Craig Partridge, Stephanie Price, Yakov Rekhter, Steve Senum, Richard Smith, Frank Solensky, Rich Woundy, and others who have been inadvertently overlooked.

Some of the text in this memo has been (shamelessly) plagiarized from earlier documents, most notably RFC-1122 by Bob Braden and the Host

Requirements Working Group, and RFC-1009 by Bob Braden and Jon Postel. The work of these earlier authors is gratefully acknowledged.

Jim Forster was a co-chair of the Router Requirements Working Group during its early meetings, and was instrumental in getting the group off to a good start. Jon Postel, Bob Braden, and Walt Prue also contributed to the success by providing a wealth of good advice before the group's first meeting. Later on, Phill Gross, Vint Cerf, and Noel Chiappa all provided valuable advice and support.

Mike St. Johns coordinated the Working Group's interactions with the security community, and Frank Kastenholz coordinated the Working Group's interactions with the network management area. Allison Mankin and K.K. Ramakrishnan provided expertise on the issues of congestion control and resource allocation.

Many more people than could possibly be listed or credited here participated in the deliberations of the Router Requirements Working Group, either through electronic mail or by attending meetings. However, the efforts of Ross Callon and Vince Fuller in sorting out the difficult issues of route choice and route leaking are especially acknowledged.

The editor thanks his employer, Cisco Systems, for allowing him to spend the time necessary to produce the 1994 snapshot.

Editor's Address

The address of the current editor of this document is

  Fred Baker
  Cisco Systems
  519 Lado Drive
  Santa Barbara, California 93111
  USA

  Phone:+1 805-681-0115

  EMail: fred@cisco.com

Preface (序文)​

Contents​

1. Introduction​

1.1 Reading this Document​

1.1.1 Organization (構成)​

1.1.2 Requirements (要件)​

1.1.3 Compliance (適合性)​

1.2 Relationships to Other Standards (他の標準との関係)​

1.3 General Considerations (一般的な考慮事項)​

1.3.1 Continuing Internet Evolution (継続的なインターネットの進化)​

1.3.2 Robustness Principle (堅牢性の原則)​

1.3.3 Error Logging (エラーログ)​

1.3.4 Configuration (構成)​

1.4 Algorithms (アルゴリズム)​

2. Internet Architecture (インターネット・アーキテクチャ)​

2.1 Introduction (導入)​

2.2 Elements of the Architecture (アーキテクチャの要素)​

2.2.1 Protocol Layering (プロトコルの層化)​

2.2.2 Networks (ネットワーク)​

2.2.3 Routers (ルーター)​

2.2.4 Autonomous Systems (自律システム)​

2.2.5 Addressing Architecture (アドレッシング・アーキテクチャ)​

2.2.5.1 Classical IP Addressing Architecture (古典的 IP アドレッシング・アーキテクチャ)​

2.2.5.2 Classless Inter Domain Routing (CIDR、クラスレス域間ルーティング)​

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

2.2.7 Unnumbered Lines and Networks Prefixes (番号なし回線とネットワーク・プレフィックス)​

2.2.8 Notable Oddities (注目すべき特殊性)​

2.2.8.1 Embedded Routers (組み込みルーター)​

2.2.8.2 Transparent Routers (透過ルーター)​

2.3 Router Characteristics (ルーターの特性)​

2.4 Architectural Assumptions (アーキテクチャ上の仮定)​

3. Link Layer (リンク層)​

3.1 Introduction (導入)​

3.2 Link/Internet Layer Interface (リンク層/インターネット層インタフェース)​

3.3 Specific Issues (具体的な問題)​

3.3.1 Trailer Encapsulation (トレーラ・カプセル化)​

3.3.2 Address Resolution Protocol - ARP​

3.3.3 Ethernet and 802.3 Coexistence (Ethernet と 802.3 の共存)​

3.3.4 Maximum Transmission Unit - MTU​

3.3.5 Point-to-Point Protocol - PPP​

3.3.5.1 導入​

3.3.5.2 Link Control Protocol (LCP) オプション​

3.3.5.3 IP Control Protocol (IPCP) オプション​

3.3.6 Interface Testing (インタフェース試験)​

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

4.1 Introduction (導入)​

4.2 Internet Protocol - IP​

4.2.1 Introduction (導入)​

4.2.2 Protocol Walk-Through (プロトコル通覧)​

4.2.2.1 Options: RFC 791 Section 3.2​

4.2.2.2 Addresses in Options: RFC 791 Section 3.1​

4.2.2.3 Unused IP Header Bits: RFC 791 Section 3.1​

4.2.2.4 Type of Service: RFC 791 Section 3.1​

4.2.2.5 Header Checksum: RFC 791 Section 3.1​

4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1​

4.2.2.7 Fragmentation: RFC 791 Section 3.2​

4.2.2.8 Reassembly: RFC 791 Section 3.2​

4.2.2.9 Time to Live: RFC 791 Section 3.2​

4.2.2.10 Multi-subnet Broadcasts: RFC 922​

4.2.2.11 Addressing: RFC 791 Section 3.2​

4.2.3 SPECIFIC ISSUES​

4.2.3.1 IP Broadcast Addresses​

4.2.3.2 IP Multicasting​

4.2.3.3 Path MTU Discovery​

4.2.3.4 Subnetting​

4.3 Internet Control Message Protocol - ICMP​

4.3.1 Introduction (導入)​

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

4.3.2.1 Unknown Message Types​

4.3.2.2 ICMP Message TTL​

4.3.2.3 Original Message Header​

4.3.2.4 ICMP Message Source Address​

4.3.2.5 TOS and Precedence​

4.3.2.6 Source Route​

4.3.2.7 When Not to Send ICMP Errors​

4.3.2.8 Rate Limiting​

4.3.3 SPECIFIC ISSUES​

4.3.3.1 Destination Unreachable​

4.3.3.2 Redirect​

4.3.3.3 Source Quench​