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

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にも大きく負っています。彼らの努力がなければ、この文書は存在しなかったでしょう。

Contents​

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
[email protected]
+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 (アルゴリズム)​

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

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

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

に最終更新