Network Working Group F. Baker, Editor Request for Comments: 1812 Cisco Systems Obsoletes: 1716, 1009 June 1995 Category: Standards Track Requirements for IP Version 4 Routers このメモのステータス このドキュメントは、インターネット社会のためのインターネット標準ト ラックプロトコルを規定し、改善のための議論や提案を要求する。このプ ロトコルの標準化状態と状況については、「インターネット公式プロトコ ル標準」(STD 1) の現在の版を参照されたい。このメモの配布は制限され ない。 序文 このドキュメントは、旧ルータ要件の RFC1716 の更新版である。その RFC はワーキンググループで実施された重要な作業を留めたが、現在の標準を 考慮して IESG の現在の技術を適切に記述することが出来なかった。 現在の編者はドキュメントの更新を求め続け、調達規定や実装者向けの指 針として有効になっている。ここにおいて、編者は提出されたものを公正 に受け、本文の大半を専門家の寄稿者に頼っている。功績は全て彼らのも のであり、エラーは編者によるものである。 このドキュメントの内容や形式は、大部分において、ワーキンググループ の議長でありドキュメントの起草者と作成者である Philip Almquist によ るものである。さらに、大半は以前の編者である Frank Kastenholz にも よっている。彼らの努力なしでは、このドキュメントは存在していなかっ たであろう。 Table of Contents 1. 導入 1.1 このドキュメントを読むにあたって 1.1.1 構成 1.1.2 要件 1.1.3 適合性 1.2 他の標準との関係 1.3 一般的な考慮 1.3.1 インターネットの継続的な発展 1.3.2 安定さの指針 1.3.3 エラーログの採取 1.3.4 設定 1.4 アルゴリズム 2. インターネットアーキテクチャ 2.1 導入 2.2 アーキテクチャの要素 2.2.1 プロトコル層 2.2.2 ネットワーク 2.2.3 ルータ 2.2.4 自律システム 2.2.5 アドレス体系 2.2.5.1 IP アドレス体系クラス 2.2.5.2 クラスレスドメイン間ルーティング (CIDR) 2.2.6 IP マルチキャスト 2.2.7 アンナンバード回線とネットワークプレフィクス 2.2.8 著名な特殊ケース 2.2.8.1 組み込みルータ 2.2.8.2 トランスペアレントルータ 2.3 ルータの特徴 2.4 体系的な仮定条件 3. リンク層 3.1 導入 3.2 リンク/インターネット層インタフェース 3.3 特定の問題 3.3.1 トレイラカプセル化 3.3.2 アドレス解決プロトコル - ARP 3.3.3 イーサネットと 802.3 の共存 3.3.4 最大転送単位 - MTU 3.3.5 ポイントツーポイントプロトコル - PPP 3.3.5.1 導入 3.3.5.2 リンク制御プロトコル (LCP) オプション 3.3.5.3 IP 制御プロトコル (IPCP) オプション 3.3.6 インタフェーステスト 4. インターネット層 - プロトコル 4.1 導入 4.2 インターネットプロトコル - IP 4.2.1 導入 4.2.2 プロトコル - ウォークスルー 4.2.2.1 オプション: RFC791 セクション3.2 4.2.2.2 オプション中のアドレス: RFC791 セクション3.1 4.2.2.3 未使用 IP ヘッダビット: RFC791 セクション3.1 4.2.2.4 サービスタイプ: RFC791 セクション3.1 4.2.2.5 ヘッダチェックサム: RFC791 セクション3.1 4.2.2.6 未知のヘッダオプション: RFC791 セクション3.1 4.2.2.7 分割: RFC791 セクション3.2 4.2.2.8 組み立て: RFC791 セクション 3.2 4.2.2.9 生存時間: RFC791 セクション 3.2 4.2.2.10 複数サブネットブロードキャスト: RFC922 4.2.2.11 アドレス付け: RFC791 セクション3.2 4.2.3 特定の問題 4.2.3.1 IP ブロードキャストアドレス 4.2.3.2 IP マルチキャスト 4.2.3.3 経路 MTU 検出 4.2.3.4 サブネット化 4.3 インターネット制御メッセージプロトコル - ICMP 4.3.1 導入 4.3.2 一般的な問題 4.3.2.1 未知のメッセージタイプ 4.3.2.2 ICMP メッセージ TTL 4.3.2.3 元のメッセージヘッダ 4.3.2.4 ICMP メッセージ送信元アドレス 4.3.2.5 TOS と優先度 4.3.2.6 送信元経路 4.3.2.7 ICMP エラーを送信しないケース 4.3.2.8 割合制限 4.3.3 特定の問題 4.3.3.1 宛先未到達 4.3.3.2 リダイレクト 4.3.3.3 送信元抑制 4.3.3.4 時間超過 4.3.3.5 パラメタ問題 4.3.3.6 エコー要求/応答 4.3.3.7 情報要求/応答 4.3.3.8 タイムスタンプとタイムスタンプ応答 4.3.3.9 アドレスマスク要求/応答 4.3.3.10 ルータの宣伝と懇願 4.4 インターネットグループ管理プロトコル - IGMP 5. インターネット層 - 転送 5.1 導入 5.2 転送ウォークスルー 5.2.1 転送アルゴリズム 5.2.1.1 一般 5.2.1.2 ユニキャスト 5.2.1.3 マルチキャスト 5.2.2 IPヘッダ評価 5.2.3 ローカル配送の決定 5.2.4 次ホップアドレスの決定 5.2.4.1 IP宛先アドレス 5.2.4.2 ローカル/リモート決定 5.2.4.3 次ホップアドレス 5.2.4.4 管理上の優先度 5.2.4.5 負荷分散 5.2.5 未使用 IPヘッダビット: RFC-791 セクション 3.1 5.2.6 分割と組み立て: RFC-791 セクション 3.2 5.2.7 インターネット制御メッセージプロトコル - ICMP 5.2.7.1 宛先未到達 5.2.7.2 リダイレクト 5.2.7.3 時間超過 5.2.8 インターネットグループ管理プロトコル - IGMP 5.3 特定の問題 5.3.1 生存時間 (TTL) 5.3.2 サービスタイプ (TOS) 5.3.3 IP 優先度 5.3.3.1 優先度順序キューサービス 5.3.3.2 下位層優先度マッピング 5.3.3.3 全てのルータのための優先度処理 5.3.4 リンク層ブロードキャストの転送 5.3.5 インターネット層ブロードキャストの転送 5.3.5.1 限定ブロードキャスト 5.3.5.2 直接ブロードキャスト 5.3.5.3 全サブネット直接ブロードキャスト 5.3.5.4 サブネット直接ブロードキャスト 5.3.6 輻輳制御 5.3.7 マーチャンアドレスフィルタ 5.3.8 送信元アドレス評価 5.3.9 パケットフィルタとアクセスリスト 5.3.10 マルチキャストルーティング 5.3.11 転送時の制御 5.3.12 状態変更 5.3.12.1 ルータが転送を終了する時 5.3.12.2 ルータが転送を開始する時 5.3.12.3 インタフェース障害か使用不可な時 5.3.12.4 インタフェースが使用可能な時 5.3.13 IP オプション 5.3.13.1 認識できないオプション 5.3.13.2 セキュリティオプション 5.3.13.3 ストリーム識別子オプション 5.3.13.4 送信元経路オプション 5.3.13.5 経路記録オプション 5.3.13.6 タイムスタンプオプション 6. トランスポート層 6.1 ユーザデータグラムプロトコル - UDP 6.2 転送制御プロトコル - TCP 7. アプリケーション層 - ルーティングプロトコル 7.1 導入 7.1.1 ルーティングセキュリティの考慮 7.1.2 優先度 7.1.3 メッセージ評価 7.2 内部ゲートウェイプロトコル 7.2.1 導入 7.2.2 オープン最短パス優先 - OSPF 7.2.3 中間システムツー中間システム - 二重 IS-IS 7.3 外部ゲートウェイプロトコル 7.3.1 導入 7.3.2 ボーダーゲートウェイプロトコル - BGP 7.3.2.1 導入 7.3.2.2 プロトコルウォークスルー 7.3.3 外部プロトコルの無い AS 間ルーティング 7.4 静的ルーティング 7.5 ルーティング情報のフィルタリング 7.5.1 経路評価 7.5.2 基本経路フィルタリング 7.5.3 拡張経路フィルタリング 7.6 ルーティングプロトコル間情報交換 8. アプリケーション層 - ネットワーク管理プロトコル 8.1 簡易ネットワーク管理プロトコル - SNMP 8.1.1 SNMP プロトコル要素 8.2 コミュニティテーブル 8.3 標準 MIBS 8.4 ベンダ特定 MIB 8.5 変更の保存 9. アプリケーション層 - 様々なプロトコル 9.1 BOOTP 9.1.1 導入 9.1.2 BOOTP 配送エージェント 10. 運用と保守 10.1 導入 10.2 ルータの初期化 10.2.1 最低限のルータ設定 10.2.2 アドレスとプレフィクスの初期化 10.2.3 BOOTP と TFTP を使用したネットワーク起動 10.3 運用と保守 10.3.1 導入 10.3.2 帯域外アクセス 10.3.2 ルータ O&M 機能 10.3.2.1 保守 - ハードウェア診断 10.3.2.2 制御 - ダンプ採取と再起動 10.3.2.3 制御 - ルータの設定 10.3.2.4 システムソフトウェアのネット起動 10.3.2.5 設定誤りの検出と応答 10.3.2.6 中断の最小限化 10.3.2.7 制御 - トラブルシューティング問題 10.4 セキュリティ考慮 10.4.1 監査と証跡 10.4.2 設定制御 11. 参照 付録 A 送信元ルーティングホストの要件 付録 B. 用語解説 付録 C. 将来の方向性 付録 D マルチキャストルーティングプロトコル D.1 導入 D.2 距離ベクトルマルチキャストルーティングプロトコル - DVMRP D.3 OSPF のマルチキャスト拡張 - MOSPF D.4 プロトコル無依存マルチキャスト - PIM 付録 E 追加の次ホップ選択アルゴリズム E.1. 幾つかの歴史的な総体的見地 E.2. 追加の枝刈り規則 E.3 幾つかの経路検索アルゴリズム E.3.1 改訂されたクラシックアルゴリズム E.3.2 ルータ要件アルゴリズムの変形版 E.3.3 OSPF アルゴリズム E.3.4 統合 IS-IS アルゴリズム セキュリティの考慮 付録 F: 歴史的なルーティングプロトコル F.1 外部ゲートウェイプロトコル - EGP F.1.1 導入 F.1.2 プロトコルウォークスルー F.2 ルーティング情報プロトコル - RIP F.2.1 導入 F.2.2 プロトコルウォークスルー F.2.3 特定の問題 F.3 ゲートウェイツーゲートウェイプロトコル - GGP 謝辞 編者のアドレス 1. 導入 このメモは RFC1716 "インターネットゲートウェイの要件" (INTRO:1)を置 き換えている。 このメモは、インターネットプロトコルスイートのネットワーク層の転送機 能を実現する装置に対する要件について定義し論じている。インターネット 社会では通常、このような装置を IP ルータ、または単にルータと呼んでい る。OSI 社会ではこのような装置を中間システムと呼んでいる。多くのより 古いインターネットドキュメントでは、これらの装置をゲートウェイと呼ん でいるが、アプリケーションゲートウェイとの混乱を避けるために、最近は あまりこの名前では呼ばれていない。 IP ルータは、交換処理の一部としてルータが IP ヘッダを調べるという点 において、他のパケット交換装置とは区別されている。通常 IP ルータは受 信したメッセージに付いているリンク層ヘッダを削除し、IP ヘッダを更新 し、さらに転送するためにリンク層ヘッダを置き換える。 このメモの筆者は、読者も同様だと思うが、多くのルータが 1 つ以上のプ ロトコルをサポートしていると認識している。将来のインターネットの大部 分において、複数のプロトコルスイートのサポートが必要とされるだろう。 しかしながら、このメモは TCP/IP 以外のプロトコルスイートの要件を規定 しようとはしない。 このドキュメントは、インターネットに接続されたルータが使用しなければ ならない標準プロトコルを列挙し、これらのプロトコルの現在の規定を記し ている RFC や他のドキュメントを参照することによって取り込んでいる。 参照しているドキュメントのエラーを修正し、実装者のための付加議論やガ イダンスを追加している。 また各々のプロトコルに対し、このメモは要件や推奨、オプションの明示的 なセットを含んでいる。読者は、このメモの要件のリストはそれ自身では不 完全であることを理解しなければならない。インターネットプロトコルルー タの要件の完全なセットは、このメモに含まれている修正や改訂、補足と共 に、基本的には標準プロトコル規定ドキュメントに定義されている。 このメモは、インターネットホストの要件の RFC ([INTRO:2] と [INTRO:3]) と共に読まなければならない。インターネットホストとルータの両方とも、 IP データグラムの起動側能力と受信側能力を持たなければならない。イン ターネットホストとルータの主要な相違は、ルータは転送アルゴリズムを実 装し、インターネットホストは転送機能を必要としないという点である。ル ータとして動作するインターネットホストは、このメモに含まれている要件 を守らなければならない。 オープンシステムの相互接続の目標は、ルータは必要時にインターネットホ ストとして正しく機能しなければならないことを命ずることである。これを 達成するために、このメモはその様なインスタンスのための指針を提供する。 ドキュメントの更新を単純で容易にするために、このメモはホストの要件と 重複する議論 ([INTRO:2] と [INTRO:3]) を避けようとしており、参照する ことによってそのドキュメントの関連要件を取り込んでいる。幾つかのケー スでは、[INTRO:2] と [INTRO:3] で述べられた要件が、このドキュメント によって代えらている。 RFC を注意深く読んだ後作成されたプロトコルの信頼性のある実装は、この メモの要件とわずかな点しか異ならないはずである。そうした実装を作成す る際、インターネット技術社会との協調作業がしばしば必要であり、適切な 通信ソフトウェアエンジニアリングの実践に従わなければならない。多くの 場合、このドキュメントの要件は、既に標準プロトコルドキュメントで言及 されているか含まれている。従って、それらをここに含めることは冗長であ る。幾つかの過去の実装が誤った選択を行っており、相互接続性やパフォー マンス、頑強性に問題がある場合は、ここに含めている。 このメモは、多くの要件や推奨についての議論と説明を含んでいる。要件を 単に一覧化することは危険である。なぜなら、 o ある必要な特徴は他の特徴よりも重要であり、ある特徴は任意である。 o ある特徴は、あるルータのアプリケーションにおいて危険であり、他のア プリケーションにとっては無駄である。 o 制限付きのコンテキストで設計されたある特定のベンダ製品が、異なる規 約の使用を選択する正当な理由があるかもしれない。 しかしこのメモの規定は、インターネットの多様性や複雑性に渡って、任意 のルータと相互接続を可能にする一般的な目標を適えるために従わなければ ならない。最近の実装は、あるものはマイナーな、またあるものはメジャー な様々な点においてこれらの要件に適合していないが、この規定は我々が向 かうべき理想である。 これらの要件は、現在のインターネットアーキテクチャのレベルに基づいて いる。このメモは、追加説明を提供する必要がある場合や、規定が更に進歩 してある範囲における追加情報が必要な場合に更新されるだろう。 1.1 このドキュメントを読むにあたって 1.1.1 構成 このメモは、[INTRO:2] と [INTRO:3]で用いられている層構成に習っている。 そして、チャプタ 2 はインターネットアーキテクチャで見られる層につい て説明している。チャプタ 3 はリンク層をカバーしている。チャプタ 4 と 5 は、インターネット層プロトコルと転送アルゴリズムに関係している。チャ プタ 6 はトランスポート層をカバーしている。上位層プロトコルは、チャ プタ 7,8,9 に区分けされている。チャプタ 7 は、ルータがお互いに経路情 報を交換するのに使用するプロトコルについて論じている。チャプタ 8 は ネットワーク管理について論じている。チャプタ 9 は、他の上位層プロト コルについて論じている。最後のチャプタは、操作や保守の特徴をカバーし ている。この構成は、単純かつ明確で、ホスト要件の RFC と一貫性を持た せるために選択された。このメモの付録は、参考図書、用語、ルータの標準 の将来の方向性についての推測を含んでいる。 要件を記述する際、我々は実装体がプロトコルの層分けを厳密に反映してい ると仮定する。しかし厳密な層分けは、プロトコルスイートや推奨された実 装アプローチの両方にとって不完全なモデルである。異なる層のプロトコル は複雑に、時には微妙な方法で相互作用し、ある特定の機能はしばしば複数 の層を巻きこんでいる。実装における設計の選択肢は数多く存在し、それら の多くは厳密な層分けの創造的な破壊を伴っている。全ての実装者は、 [INTRO:4] と [INTRO:5] を読むことが推奨される。 このメモの各々の主要なセクションは、以下のサブセクションから構成され る。 (1) 導入 (2) プロトコルウォークスルー - プロトコル規定ドキュメントをセクショ ン毎に考慮し、エラーを修正し、曖昧か不十分な定義かもしれない要件 を開始し、更なる解明や説明を提供している。 (3) 特殊な問題 - ウォークスルーには含まれないプロトコル設計や実装の 問題について論じている。 このメモの数多くの個々のトピックの下に、DISCUSSION や IMPLEMENTATION という記述で示された挿入文がある。この文は前述の要件のテキストを正当 化、明確化、説明することを意図している。実装の挿入文は、実装者が考慮 したいかもしれない提案されたアプローチを含んでいる。DISCUSSION と IMPLEMENTATION のセクションは、この標準の一部ではない。 1.1.2 要件 このメモでは、各々の特定の要件の重要性を定義するために使用する単語は 大文字で記述される。これらの単語は、 o MUST この単語は、その項目がこの規定の絶対的な要件であることを意味する。 この要件に反することは重大なエラーであり、正当化されるケースは存 在しない。 o MUST IMPLEMENT このフレーズは、この規定ではその項目が実装される必要があることを 意味するが、デフォルトで使用可能にする必要はない。 o MUST NOT このフレーズは、その項目がこの規定の絶対的な禁止であることを意味 する。 o SHOULD この単語は、ある事情においてこの項目を無視する正当な理由が存在し てもよいことを意味する。しかし、完全な実装が理解され、異なる方向 を選択する前に注意深く熟慮しなければならない。 o SHOULD IMPLEMENT このフレーズは SHOULD の意味と同様であるが、ある特徴を提供するこ とは推奨するが、デフォルトで使用可能とすることを推奨してはいない 時に使用される。 o SHOULD NOT このフレーズは、規定された振る舞いは受諾可能または有効であるよう な事情で正当な理由が存在してもよいことを意味する。たとえそうであっ ても、完全な実装を理解し、この記述で説明された振る舞いを実装する 前に注意深く熟慮しなければならない。 o MAY この単語は、この項目は全く任意であることを意味する。あるベンダは 特定の市場で必要だからその項目を含む、あるいは製品を拡張すること を選択するかもしれないし、またあるベンダは同じ項目を省略するかも しれない。 1.1.3 適合性 幾つかの要件は、全てのルータで受諾可能である。他の要件は、特定の特徴 かプロトコルを実装する場合にのみ受諾可能である。以下のパラグラフでは、 実装した特徴とプロトコルのセットのために、関連は全てのルータで受諾で きる要件と、特定のルータで受諾できる要件のセットを合わせたものに関連 する。 全ての関連要件が直接このメモで述べられているとは限らない。このメモの 様々な部分は、ホスト要件規定 [INTRO:2] と [INTRO:3] のセクションを参 照することによって取り入れている。このメモの適合性を決定するのに、関 連要件がこのメモで直接述べてあるか、他のドキュメントのものから参照す ることによって取り込まれているかは大した問題ではない。 もし全ての関連 MUST, MUST IMPLEMENT, MUST NOT 要件を満足するならば、 その実装体は条件付きで準拠していることになる。もし条件付きで準拠して おり、さらに全ての関連 SHOULD, SHOULD IMPLEMENT, SHOULD NOT 要件も満 足するならば、その実装体は無条件に準拠していることになる。もし条件付 きで準拠していなければ (すなわち、一つ以上の関連 MUST, MUST IMPLEMENT, MUST NOT 要件を満足していない)、その実装体は準拠していない。 この規定はたまに、実装体が管理変数を実装すべき (SHOULD) で、あるデフォ ルト値を持つべき (SHOULD) であることを示す。無条件に準拠した実装体は、 そのデフォルト振る舞いを実装し、もし別の振る舞いが実装されているなら ば、その変数を実装する。条件付きで準拠した実装は、変数のデフォルト設 定が何か、あるいは変数を実装していない場合は、デフォルト設定をどのよ うに解釈してよいかを明確にドキュメント化する。変数を実装しておらず、 別の振る舞いも選択していない実装体は準拠していない。 いかなる SHOULD, SHOULD NOT 要件も、ルータはその要件で規定されている 以外の動作を行わせる設定オプションを提供してもよい。たとえそのような 設定オプションを持っていても、もしそのオプションがデフォルト設定を持っ ており、その設定によってルータが要求された方法で処理されるならば、無 条件に準拠しているというルータの主張を無効にはしない。 同様に、このメモで明確に禁止されている場合を除いて、ルータは MUST や MUST NOT 要件に反する処理を行わせるオプションを提供してもよい。その ようなオプションを提供するルータは、各々のオプションがこのメモの要件 に適合するデフォルト設定を持つ場合にのみ、(完全あるいは条件付きで) 準拠している。このメモの筆者はマーケットの現実は認識しているが、その ようなオプションは用意されないことを強く推奨することに注意されたい。 要件が MUST か MUST NOT で記述されているのは、その道の専門家がインタ ーネットの相互接続性や適切な機能性において特に重要であると判断したか らである。ベンダは、これらの規則を破るオプションを提供する際、消費者 サポートのコストを慎重に考慮すべきである。 もちろん、このメモは IP ルータの完全な規定ではなく、OSI の世界でいう プロファイルに近いものである。例えば、このメモは数多くのプロトコルが 実装されることを要求している。それらのプロトコル規定の大半の内容はこ のメモでは繰り返さないが、実装者はそれでもなお、それらの規定に従って プロトコルを実装することを求められる。 1.2 他の標準との関係 プロトコル規定と標準の状態をチェックするための幾つかの参照ドキュメン トが存在する。 o INTERNET OFFICIAL PROTOCOL STANDARDS このドキュメントはインターネット標準プロセスを記述し、プロトコ ルの状態を一覧化している。このメモが作成された時は、このドキュ メントの現在のバージョンは STD 1, RFC1780 [ARCH:7] である。この ドキュメントは定期的に再発行されている。RFC の保管場所を常に調 べ、このドキュメントの最新の版を使用すべきである。 o Assigned Numbers このドキュメントは、様々なプロトコルで使用されるパラメタの値割 当てをリスト化している。例えば、IP プロトコルのコードや TCP の ポート番号、Telnet のオプションコード、ARP のハードウェアタイプ 名がある。このメモが作成された時は、このドキュメントの現在のバ ージョンは STD 2, RFC1700 [INTRO:7] である。このドキュメントは 定期的に再発行されている。RFC の保管場所を常に調べ、このドキュ メントの最新の版を使用すべきである。 o Host Requirements この一組のドキュメントはホストに適用する規定をレビューし、指針 や曖昧部分の説明を提供している。これらの要件はこのメモで規定さ れたもの以外を除いて、ルータにも適用される。このメモが作成され た時、このドキュメントの現在のバージョンは RFC1122 と RFC1123 (STD 3) [INTRO:2] と [INTRO:3] である。 o Router Requirements (formerly Gateway 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 一般的な考慮 インターネットソフトウェアのベンダが知っておくべき、また新たなベン ダが深慮すべき幾つかの重要な教訓がある。 1.3.1 インターネットの継続的な発展 インターネットの莫大な成長は、大きなデータグラムパケット通信システ ムにおける管理や規模の問題を表面化させた。これらは問題として位置づ けられ、結果的にこのメモで規定されている規約は、進化し続けるだろう。 新しいルーティングプロトコル、アルゴリズム、アーキテクチャは、永続 的に進化する。新しいインターネット層プロトコルや既存のプロトコルの 更新によってもまた、永続的に改訂されていくだろう。ルータは、インタ ーネットにおいて重要な役割を持ち、インターネットで開発されたルータ の数はホストの数よりもずっと少ない。従って、ベンダはルータの標準は ホストの標準よりもずっと早く進化し続けていくと予期すべきである。ベ ンダやネットワークの取り扱いに責任のある組織によるこの計画には、多 数の参加者がいるので、これらの変更は慎重に計画され管理されるだろう。 発展、進化、改訂は今日のコンピュータネットワークプロトコルの特徴で あり、こうした状態は数年続くだろう。インターネットプロトコルスイー ト (あるいは他のいかなるプロトコルスイートも!) のためのコンピュータ 通信ソフトウェアを開発し、変更される規約に対してソフトウェアを保守、 更新することができないベンダは、不幸な消費者を残して去ってしまうか もしれない。インターネットは大規模な通信ネットワークであり、ユーザ は絶え間無くインターネットを通じて交信する。経験的に、ベンダソフト ウェアの欠陥に関する情報はインターネット技術社会を通じて即座に広が るようだ。 1.3.2 安定さの指針 プロトコルの全ての層において、アプリケーションが頑強性と相互接続性 に莫大な利益をもたらす一般的な規則が存在する (Jon Postel の [TRANS:2] より)。 自ら行うことには保守的であれ、 他から受けることには革新的であれ。 ソフトウェアは、たとえ起こりそうに無くても、考えられる全ての異常を 扱うよう記述すべきである。結局、パケットは異常や属性の特定のコンビ ネーションで入ってくる。もしソフトウェアがそれに対して準備されてい なければ、混沌が起こり得る。ネットワークは、最悪の事象を起こすよう 設計されたパケットを送信する、悪意を持ったエンティティで満ちている と仮定することが最善である。この仮定は適切な防御設計につながるだろ う。インターネットにおける最も重大な問題は、人間の悪意ですらそんな 遠回りな道筋を辿らないような起きそうにもないイベントがトリガとなる、 不測のメカニズムによって引き起こされるものである！ 変更への順応性は、ルータソフトウェアの全てのレベルで設計しなければ ならない。簡単な例として、例えばタイプフィールドやポート番号、エラ ーコードといった特定のヘッダフィールドの列挙値を含むプロトコル規定 を考える場合、この列挙は不完全であると仮定しなければならない。もし プロトコル規定が四つのあり得るエラーコードを定義しているならば、ソ フトウェアは五つ目のコードが定義されたときに壊れてはならない。未定 義のコードはログに採取してもよいが、失敗の要因になってはならない。 指針の二番目の部分も同様に重要である。ホストや他のルータ上のソフト ウェアは、正しいが曖昧なプロトコル機能を利用することを不得策にする 欠陥を含んでいるかもしれない。厄介な事象が別の場所に生じないよう、 明確さや簡潔さからかけ離れて脱線するのは賢明ではない。この結果は誤 動作するホストを警戒することであり、ルータソフトウェアは誤動作する ホストが存在する中で生き残る準備をしておくべきである。インターネッ トにおけるルータの重要な機能は、そうしたホストが共有された通信設備 に及ぼす混乱の量を制限することである。 1.3.3 エラーログの採取 インターネットは様々なシステムを含み、各々が多くのプロトコルやプロ トコル層を実装している。これらの幾つかは、インターネットプロトコル ソフトウェア中にバグや誤った機能を含んでいる。複雑さや多様性、機能 の分散の結果、問題の診断は大抵非常に困難である。 もしルータが異常や奇妙なイベントのログを採取するために慎重に設計さ れた機能を含んでいれば、問題の診断は助けになるだろう。エラーのログ を採取する際、できる限り多くの診断情報を含むことは重要である。特に、 エラーを引き起こしたパケットのヘッダを記録することはしばしば有効で ある。しかし、エラーログの採取により、極端に高価な量の資源を消費し ないことや、ルータの処理を妨げないことを保証するよう注意しなければ ならない。 異常だが無害なプロトコルイベントが、エラーのログファイルを溢れさせ る傾向がある。これは循環ログを使用するか、既知の障害を診断する場合 にしかログ採取を有効にしないことによって回避できる。重複した成功メッ セージをフィルターにかけたり、数えたりすることは有効かもしれない。 上手く作用しそうな戦略は、以下の両方である。 o 常に異常を数え、管理プロトコル (チャプタ8参照) を通じて、その数に アクセスできるようにする。 o 多様なイベントのログ採取を選択的に採取可能にする。例えば、全ての ログを採取できたり、ホスト X の全てのログを採取できたりすることは 有効だろう。 このトピックは、さらに [MGT:5] で論じている。 1.3.4 設定 理想的な世界では、ルータは設定が容易で、恐らく完全に自動設定さえ行 われるだろう。しかし、現実世界の実際の経験では、これが不可能な目標 であることを示唆しており、設定を容易にしようとするベンダの試みは、 実際には消費者の悲嘆を防ぐよりはむしろ助長させている。極端な例を挙 げれば、設定情報を全く必要とせずに起動され開始するよう設計されたル ータは、ほぼ確実に幾つかの誤ったパラメタを選択し、恐らくそれを接続 するのに不適切なネットワーク上で重大な問題を引き起こしている。 しばしばこのメモは、パラメタが設定可能なオプションであることを要求 する。これには幾つかの理由がある。あるケースでは、最適値について不 確かで同意されていないことが現在存在し、将来推奨値を更新する必要が あるかもしれない。また他のケースでは、値は実際には外的要因、例えば 通信負荷の分散や隣接ネットワークの速度やトポロジに依存し、自己チュ ーニングアルゴリズムが利用できなかったり、不十分でありえる。あるケ ースでは、管理上の要件のために設定可能である必要がある。 最後に、ある設定オプションは、インターネットの多くの部分でまだ使用 されている、ソース無しで配布された、時代遅れや正しくないプロトコル 実装と通信するために必要である。正しいシステムをこれらの欠陥システ ムと共存させるために、管理者は時折、正しいシステムに誤りを含む設定 をしなければならない。この問題は、欠陥システムが撤廃されるにつれて 徐々に正されるだろうが、ベンダは無視できない。 パラメタが設定可能であると宣言する場合は、その値を明示的に設定ファ イルから、ブート時に毎回読み込む必要があることを意図していない。多 くのパラメタにとって、最も一般的でない状況を除き、適切な一つの値が 存在する。そのような場合、もし明示的に設定されていなければ、その値 をパラメタのデフォルト値とすることは極めて効率的である。 このメモは、あるケースでそうしたデフォルトのための特定の値を要求す る。設定項目が既存の欠陥システムへの適応を制御する場合、デフォルト の選択は繊細な問題である。もしインターネットが相互接続性を完遂する 方向に収束するならば、実装体に作り込まれたデフォルト値は、欠陥実装 に適応するための誤った設定ではなく、公式的なプロトコルを実装しなけ ればならない。商用を考慮すると、ベンダは誤った設定のデォルト値を選 択したいかもしれないが、我々はベンダが標準に適合したデフォルト値を 選択することを強く推奨する。 最後に、ベンダは全ての設定パラメタの制限や効果について、十分なドキュ メントを提供する必要があることに注意されたい。 1.4 アルゴリズム このメモの幾つかの場所で、ルータが従うべき特定のアルゴリズムが規定 されている。これらのアルゴリズムはルータの要件ではない。ルータは、 このメモに書かれてある各々のアルゴリズムを実装する必要は無い。むし ろ実装体は、厳密的で文字通りの、規定されたアルゴリズムの実装と同じ 動作を外部世界に提供しなければならない。 アルゴリズムは、優れた実装体が実装するのとは異なる方法で規定されて いる。解説目的のために、簡潔さや明確さ、実装の詳細に依存しないこと を強調したスタイルが選択されている。優れた実装体は、これらのアルゴ リズムと同じ結果を生み出すが、より効率的であったり、一般的でないア ルゴリズムや実装方法を選択する。 効率的なルータの実装技術は、このメモの適用外であることに注意された い。 2. インターネットアーキテクチャ このチャプタは、如何なる要件も含まない。しかし、インターネットとル ータの一般的なアーキテクチャについての有効な背景情報を含む。 インターネットアーキテクチャとサポートするプロトコルスイートの一般 背景や議論は、DDN プロトコルハンドブック [ARCH:1] に見ることができ る。背景については、例えば [ARCH:2], [ARCH:3], [ARCH:4] を参照され たい。インターネットアーキテクチャとプロトコルは、例えば [ARCH:5], [ARCH:6] といった、絶えず増え続けているテキストブックでカバーされて いる。 2.1 導入 インターネットシステムは、インターネットプロトコルを使用したホスト コンピュータ間の通信をサポートしている、数多くの相互接続パケットネッ トワークから構成されている。これらのプロトコルは、インターネットプ ロトコル (IP)、インターネット制御メッセージプロトコル (ICMP)、イン ターネットグループ管理プロトコル (IGMP)、これらと独立した多様なトラ ンスポートやアプリケーションプロトコルである。セクション [1],[2] に 記述されているように、インターネット技術運営グループは、全てのイン ターネットプロトコルを一覧化している公式プロトコルのメモを定期的に 発行している。 全てのインターネットプロトコルは、基本データ転送メカニズムとして IP を使用する。IP はデータグラムで、コネクションレスの相互ネットワーク サービスであり、アドレス付けやサービスタイプ指定、分割、組立、セキュ リティを含む。ICMP と IGMP はアーキテクチャ上は IP 上に位置するが、 IP の一部として必要な部分と見なされる。ICMP は、エラー通知、フロー 制御、第一ホップルータリダイレクション、その他の保守や管理機能を提 供する。IGMP は、ホストとルータが IP マルチキャストグループに加入し たり、離脱するためのメカニズムを提供する。 信頼性のあるデータ配送は、インターネットプロトコルスイートでは、エ ンドツーエンドの再送、再順序付け、コネクション制御を提供する転送制 御プロトコル (TCP) 等のトランスポート層プロトコルによって提供される。 トランスポート層のコネクションレスサービスは、ユーザデータグラムプ ロトコル (UDP) によって提供される。 2.2 アーキテクチャの要素 2.2.1 プロトコル層 インターネットシステムを使用して通信するために、ホストはインターネッ トプロトコルスイートを構成するプロトコルの層に分けられたセットを実 装しなければならない。ホストは一般に、各々の層に対して少なくとも一 つのプロトコルを実装しなければならない。 インターネットアーキテクチャで使用されるプロトコルの層は以下の通り [ARCH:7]。 o アプリケーション層 アプリケーション層は、インターネットプロトコルスイートの最上位層 である。幾つかのアプリケーション層プロトコルが内部に存在するが、 インターネットスイートはアプリケーション層を更に分割しない。イン ターネットスイートは、OSI 参照モデル [ARCH:8] の上位の二つの層 - プレゼンテーションとアプリケーション - の機能を本質的に結合し ている。インターネットプロトコルスイートのアプリケーション層は、 OSI 参照モデルのセション層に属する幾つかの機能も含む。 我々は、アプリケーション層プロトコルの二つのカテゴリを区別する。 それは、直接ユーザにサービスを提供するユーザプロトコルと、共通の システム機能を提供するサポートプロトコルである。最も一般的なイン ターネットユーザプロトコルは、 - Telnet (リモートログイン) - FTP (ファイル転送) - SMTP (電子メール配送) 他の標準化されたユーザプロトコルや私的ユーザプロトコルは、数多く 存在する。 ホスト名のマッピング、ブート、管理で使用されるサポートプロトコル は、SNMP,BOOTP,TFTP,ドメイン名システム (DNS) プロトコル、様々な ルーティングプロトコルを含む。 ルータに関係するアプリケーション層プロトコルは、このメモのチャプ タ 7,8,9 で論じられている。 o トランスポート層 トランスポート層は、エンドツーエンドの通信サービスを提供する。こ の層は、OSI 参照モデルのトランスポート層におおよそ等しいが、OSI トランスポート層は OSI のセション層の確立/破棄機能の幾つかとも協 調している点は除く。 現状、二つの主要なトランスポート層プロトコルが存在する。 - 転送制御プロトコル (TCP) - ユーザデータグラムプロトコル (UDP) TCPは、エンドツーエンドの信頼性、再順序付け、フロー制御を提供す る、信頼性のあるコネクション型トランスポートサービスである。UDP は、コネクションレス (データグラム) のトランスポートサービスであ る。その他のトランスポートプロトコルは研究団体によって開発されて おり、公式インターネットプロトコルのセットは、将来拡張されるかも しれない。 ルータに関係するトランスポート層プロトコルは、チャプタ 6 で論じ られる。 o インターネット層 全てのインターネットトランスポート層プロトコルは、送信元ホストか ら宛先ホストにデータを運ぶためにインターネットプロトコル (IP) を 使用する。IP はコネクションレスまたはデータグラムの相互ネットワ ークサービスであり、エンドツーエンドの配送の保証は提供しない。IP データグラムは、破損したり、重複したり、順序通りで無く宛先ホスト に到着するかもしれないし、あるいは全く到着しないかもしれない。IP 上の層は、必要であれば、信頼できるサービスを提供する責任がある。 IP プロトコルはアドレス付けの提供、サービスタイプの指定、分割、 組立、セキュリティを含む。 IP のデータグラムでコネクションレスの特性は、インターネットアー キテクチャの基礎であり、特徴的な性質である。 インターネット制御メッセージプロトコル (ICMP) は、アーキテクチャ 上は IP の上に位置し、データをエンドツーエンドに運ぶために IP を 使用するが、IP の一部として必要な部分と見なされる制御プロトコル である。ICMP は、エラー通知、輻輳通知、第一ホップルータリダイレ クションを提供する。 インターネットグループ管理プロトコル (IGMP) は、IP マルチキャス トの動的なホストグループを確立するために使用されるインターネット 層プロトコルである。 インターネット層プロトコルの IP,ICMP,IGMP は、チャプタ 4 で論じ られる。 o リンク層 直接接続されたネットワーク上で通信するために、ホストはそのネット ワークにインタフェースするために使用される通信プロトコルを実装し なければならない。我々はこれをリンク層プロトコルと呼ぶ。 幾つかの古いインターネットドキュメントは、この層をネットワーク層 と呼んでいるが、OSI 参照モデルのネットワーク層と同じではない。 この層はインターネット層の下で、物理層 (媒体接続、通常電気的か光 学的、メッセージを符号化して転送する) の上の全てを含む。その責任 は、メッセージの正しい配送であり、その中では区別は無い。 この層のプロトコルは通常、インターネット標準化の範囲外であり、イ ンターネットは (意図的に) 可能であれば必ず既存の標準を使用する。 従って、インターネットリンク層標準は大抵、アドレス解決や特定のリ ンク層プロトコル上で IP パケットを運ぶための規則のみ扱っている。 インターネット層標準は、チャプタ 3 で論じられている。 2.2.2 ネットワーク インターネットシステムのネットワーク構成要素は、パケット (コネクショ ンレス) 転送を提供する必要があるだけである。IP サービス規定に従い、 データグラムの送信は順序通りでない、損失または重複、エラーが含まれ る可能性がある。 IP を使用するプロトコル (例えば TCP) の効率的なパフォーマンスのため に、ネットワークの損失割合は非常に低くあるべきである。コネクション 型サービスを提供するネットワークでは、仮想回線によって提供される余 分な信頼性はエンド/エンドのシステムの頑強性を高めるが、インターネッ ト処理では必要ない。 ネットワーク構成要素は通常、二つのクラスに分割される。 o ローカルエリアネットワーク (LAN) LAN は多様な設計を持つ。LAN は通常、地理上の小規模なエリア (例 えば一つのビルや工場) をカバーし、遅延の少ない高帯域を提供する。 LAN は受動的 (イーサネットと同様) かもしれないし、能動的 (例え ば ATM) かもしれない。 o ワイドエリアネットワーク (WAN) 地理的に散在したホストや LAN はワイドエリアネットワークによっ て相互接続され、遠距離転送ネットワークとも呼ばれる。これらのネッ トワークは回線/パケット交換の複雑な内部構造を持つか、あるいは ポイントツーポイントと同じ位単純かもしれない。 2.2.3 ルータ インターネットモデルでは、ネットワーク構成要素はルータ又は IP ルー タと呼ばれる IP データグラムの転送によって相互に接続される。このド キュメントでは、ルータという用語は全て、IP ルータに相当する。多くの 古いインターネットドキュメントは、ルータをゲートウェイと呼んでいる。 歴史的に、ルータは汎用的な CPU 上で実行されるパケット交換ソフトウェ アで実現されてきた。しかし、カスタムハードウェア開発が安価になり、 より高いスループットが求められるようになったので、専用的なハードウェ アがますます一般的になりつつある。この規約は、ルータがどのような実 装であるかに関わらず適用される。 ルータは、IP サブネットやアンナンバードのポイントツーポイント回線 (セクション [2.2.7] で論じられる) によって表わされる、二つ以上の論 理的なインタフェースに接続する。従って、ルータは少なくとも一つの物 理インタフェースを持っている。IP データグラムの転送では通常、ルータ は次ホップのルータか、(最終ホップとして) 宛先ホストに関連するアドレ スとインタフェースを選択する必要がある。この選択は、ルータ内部の経 路データベースに依存したリレー、または転送と呼ばれる。経路データベ ースはルーティングテーブル、または転送テーブルとも呼ばれる。"ルータ" という用語は、この経路データベースを生成するプロセス、つまりルーティ ングプロトコルやルーティングと呼ばれるプロセスにおける設定動作に由 来する。 ルーティングデータベースは、インターネットシステムの現在のトポロジ を反映するために動的に維持されるべきである。ルータは通常、他のルー タとの分散ルーティング、到達性アルゴリズムに参加することによってこ れを実現する ルータはデータグラム転送のみを提供し、ルーティングの融通性や頑強性 のために、このサービスを支えるのに必要な状態情報を最小化することが 求められる。 パケット交換デバイスはまたリンク層で処理してもよく、そのようなデバ イスは通常ブリッジと呼ばれる。ブリッジによって接続されたネットワー クセグメントは、単一の IP サブネットを形成する同じ IP ネットワーク プレフィクスを共有する。これらの他のデバイスは、このドキュメントの 適用外である。 2.2.4 自律システム 自律システム (AS: Autonomous System) はネットワークトポロジの接続さ れたセグメントであり、一組の経路によって相互接続されたサブネットワ ーク (と所属するホスト) の集合体で構成される。サブネットワークとル ータは、単一の運用と保守 (O&M: operations and maintenance) 組織の管 理下にあることが予想される。AS の中では、ルータは一つ以上の内部ルー ティングプロトコルを使用してよく、時にはメトリックの複数の組みを使 用してもよい。AS は、内部ルーティング計画の明確な外観と、AS を通じ て到達可能な宛先の一貫した構図を他の AS に提供することが期待される。 AS は、自律システム番号によって識別される。 AS の概念は、インターネットルーティングにおいて重要な役割を演じる (セクション 7.1 参照)。 2.2.5 アドレス体系 IPデータグラムは 32 ビットの送信元/宛先アドレスを運び、その各々は二 つの部分 - ネットワークプレフィクスとそのネットワーク上のホスト番号 の構成要素 - に区切られる。記号では、 IP-address ::= { , } 最後にデータグラムを配送するために、そのパスの最後のルータは、IP ア ドレスのホスト番号 (あるいは残り) の部分を、そのホストのリンク層ア ドレスにマッピングする。 2.2.5.1 IP アドレス体系クラス 他のドキュメント [INTERNET:2] に詳述されているが、ネットワークプレ フィクスの歴史的な使用について記述することは有効である。それを記述 するために開発された言語は、このドキュメントや他のドキュメントで使 用され、多くのプロトコルの背景の考えに浸透している。 最も簡単なネットワークプレフィクスのクラスは、クラス A,B,C,D,E のネッ トワークプレフィクスである。これらのアドレス範囲は、アドレスの最上 位ビットの値を見ることによって区別され、アドレスを簡単なプレフィク スとホスト番号フィールドに分ける。これは [INTERNET:18] で説明されて いる。簡単に言うと、そのクラスは 0xxx - クラス A - 標準的な 8 ビットプレフィクスを持つ、汎用の ユニキャストアドレス。 10xx - クラス B - 標準的な 16 ビットプレフィクスを持つ、汎用の ユニキャストアドレス。 110x - クラス C - 標準的な 24 ビットプレフィクスを持つ、汎用の ユニキャストアドレス。 1110 - クラス D - IP マルチキャストアドレス - 28 ビットプレフィ クス、集約不可。 1111 - クラス E - 実験で使用するため予約 この単純な記法は、サブネットの概念によって拡張された。これらは、ネッ トワークプレこの単純な記法は、サブネットの概念によって拡張された。 これらは、ネットワークプレフィクスの割当てやルーティングの複雑性の 爆発的な増加に対して、インターネットシステムを保護する一方、組織内 の相互接続された LAN 構造を任意に複雑化できるよう導入された。サブネッ トは、インターネットシステムに対する複数レベルの階層的なルーティン グ構造を提供する。[INTERNET:2] で説明されているサブネット拡張は、イ ンターネットアーキテクチャの必要な部分である。その基本的な考え方は、 フィールドを二つの部分、サブネット番号とサブネット上 の真のホスト番号に区切ることである。 IP-address ::= { , , } 組織内の相互接続された物理ネットワークは同じネットワークプレフィク スを持つが、サブネット番号は異なる。サブネット化されたネットワーク のサブネット間の区別は、通常そのネットワークの外側には見えない。従っ て、インターネットの残りのルーティングは、IP 宛先アドレスの 部のみを使用する。ネットワークの外側のルータは、 と の両方を、32 ビット IP アドレスの解 釈されていない残りの部分として扱う。サブネット化されたネットワーク 内では、ルータは以下の拡張されたネットワークプレフィクスを使用する。 { , } この拡張ネットワーク部を含んでいるビット位置は、歴史的にサブネット マスクと呼ばれる 32 ビットマスクによって識別されてきた。 ビットは、 と フィー ルドの間に連続して存在すべきである (SHOULD)。より最近のプロトコルは サブネットマスクとは呼ばず、プレフィクス長と呼んでいる。アドレスの "プレフィクス" 部は、上位ビットが全て 1 で残りが 0 のサブネットマス クによって選択されるものである。プレフィクスの長さは、サブネットマ スクの 1 の個数に等しい。このドキュメントは、全てのサブネットマスク がプレフィクス長で表現可能であると仮定している。 サブネットメカニズムの発明者は、組織のネットワークの各々の部分が一 つのサブネット番号しか持たないと仮定していた。実際は、複数のサブネッ トに一つの物理ケーブルを共有させることが必要であり、有効であること が判明している。そのため、ルータは同一の物理インタフェース上で、複 数のサブネットを構成できるべきであり、(ルーティングや転送の見地か ら) あたかも別の物理インタフェースであるかのようにそれらを扱うべき である。 2.2.5.2 クラスレスドメイン間ルーティング (CIDR) インターネットの爆発的な成長により、アドレス割当て方法の見直しを余 儀なくされた。IP の 32 ビットアドレス空間をより効率的に利用できるよ うにするために、汎用 (クラス A, B, C) ネットワークの伝統的な使用方 法が修正された。クラスレスドメイン間ルーティング (CIDR: Classless Inter Domain Routing) [INTERNET:15] は、この付加効率の目的を達成す るために、現在インターネットバックボーンで展開中の方法である。CIDR は任意の大きさのネットワークへの展開とルーティングに依存する。この モデルでは、ホストとルータはインターネットのアドレスの付け方につい て何も仮定しない。クラス D (IP マルチキャスト) とクラス E (実験) ア ドレス空間については、本来は割当て方法であるが、変更無く残されてい る。 定義によると、CIDR は三つの要素から構成される。 o トポロジ的に重要なアドレス割当て o ネットワーク層の到達性情報を集約できるルーティングプロトコル o 一貫した転送アルゴリズム ("最長照合") ネットワークとサブネットを使うことは、それらを記述するために使用さ れる言語は現在使われ続けてはいるが、今や過去のものである。それらは、 より扱いやすいネットワークプレフィクスの概念に置き換えられつつある。 定義によると、ネットワークプレフィクスは、一組のシステムを定義する アドレスの上端のビットの連続したセットであり、ホスト番号はそれらの システムの中から選択される。インターネット全体がネットワークプレフィ クスを統一的に使用する要件はない。ルーティング情報を崩すために、イ ンターネットをアドレスの付いたドメインに分割することは有効である。 そのようなドメインの中ではネットワーク構成についての詳細な情報が取 得でき、その外側には共通のネットワークプレフィクスしか通知されない。 旧来の IP アドレス体系は、ホスト番号とネットワークプレフィクスを区 別するためにアドレスとサブネットマスクを使用した。ネットワークプレ フィクスでは、プレフィクス中のビット数を示すだけで十分である。両方 の表現は共通して使用される。体系的に正しいサブネットマスクは、プレ フィクス長の記述を使用した表現が可能である。それらは、以下のあり得 るビットパターン全てのサブセットを構成する。 o 上位の終端で連続した 1 の列 o 下位の終端で連続した 0 の列 o 介入ビット無し ルータは経路を常にネットワークプレフィクスとして扱うべきであり (SHOULD)、そのモデルに矛盾する設定やルーティング情報を拒否すべきで ある (SHOULD)。 IP-address ::= { , } CIDR を使用することの影響は、ルーティングテーブルの中でアドレスプレ フィクスと結び付けられた一組の宛先は、サブセットの関係を示すかもし れないことである。より小さな宛先の組 (プレフィクスが長い) を示す経 路は、より大きな宛先の組 (プレフィクスが短い) を示す経路よりも特定 的であると言われる。同様に、より大きい宛先の組 (プレフィクスが短い) を示す経路は、より小さな宛先の組 (プレフィクスが長い) を示す経路よ りも非特定的であると言われる。ルータはトラフィックを転送するとき、 最も特定的な一致経路 (一致するネットワークプレフィクスが最も長い) を使用しなければならない。 2.2.6 IP マルチキャスト IP マルチキャストは、リンク層マルチキャストの IP インターネットへの 拡張である。IP マルチキャストを使用して、単一のデータグラムを全ての ホストに送信せずに、複数のホスト宛てに送信することかできる。拡張し た場合、これらのホストが異なるアドレスドメインに存在していてもよい。 このホストの集合体は、マルチキャストグループと呼ばれる。各々のマル チキャストグループは、クラス D の IP アドレスで表現される。そのグル ープに送信された IP データグラムは、ユニキャスト IP トラフィックで 提供されるものと同じ最善努力方式の配送で、各グループメンバに配送さ れる。データグラムの送信者自身は、宛先グループのメンバである必要は ない。 IP マルチキャストグループメンバシップの意味は、[INTERNET:4] で定義 されている。そのドキュメントは、ホストとルータがどのようにマルチキャ ストグループに加わるか、どのように外れるかを規定している。また、そ のドキュメントは、IP マルチキャストグループメンバシップを監視する、 インターネットグループ管理プロトコル (IGMP: Internet Group Management Protocol)もまた定義している。 IP マルチキャストデータグラムの転送は、静的ルーティング情報を通じて、 あるいはマルチキャストルーティングプロトコルを経由して達成される。 IP マルチキャストデータグラムを転送するデバイスは、マルチキャストル ータと呼ばれる。それらは、IP ユニキャストを転送してもよいし、転送し なくともよい。マルチキャストデータグラムは、送信元と宛先アドレスの 両方に基づいて転送される。IP マルチキャストパケットの転送は、セクショ ン [5.2.1] で詳述されている。Appendix D はマルチキャストルーティン グプロトコルについて論じている。 2.2.7 アンナンバード回線とネットワークプレフィクス 伝統的に、IP ホストかルータ上の各々のネットワークインタフェースは、 自分自身の IP アドレスを持つ。これは、全てのホイントツーポイント回 線に IP ネットワークプレフィクスの割当てを強いるので、不足した IP アドレス空間の使用効率が悪い。 この問題を解決するために、多くの人々が番号を付けないポイントツーポ イント回線の概念を提案し実装した。番号を付けないポイントツーポイン ト回線は、それに割り当てられたネットワークプレフィクスを全く持たな い。結果的に、番号を付けないポイントツーポイント回線に接続されたネッ トワークインタフェースは、IP アドレスを持たない。 IP 体系は伝統的に全てのインタフェースが IP アドレスを持つと仮定して きたので、これらの番号無しインタフェースはいくつかの興味深いジレン マを引き起こす。例えば、ある IP オプション (例えば経路記録) は、ル ータがそのオプションにインタフェースアドレスを挿入しなければならな いと規定しているが、番号無しインタフェースは IP アドレスを持たない。 より根本的な問題は (チャプタ 5 にあるように)、経路は次ホップルータ の IP アドレスを含むことである。ルータは、ルータが接続されている IP (サブ) ネット上にこの IP アドレスがあることを期待する。この仮定は、 コネクションが番号を付けないポイントツーポイント回線しかなければ無 論破られる。 これらの問題を解決するために、二つのスキームが考案された。一つ目の スキームは、番号の付かないポイントツーポイント回線によって接続され た二つのルータは、実際には二つのルータではなく、二つで一つの仮想ル ータを構成する半分のルータと考えることである。番号の付かないポイン トツーポイント回線は、その仮想ルータの内部バスと本質的に見なされる。 仮想ルータを成す二つの半分は、実際に一つのルータのように振舞うよう 作業を協調しなければならない。 このスキームは IP 体系にうまく適応するが、二つの重要な欠点を持つ。 一つ目の欠点は、一本の番号無しポイントツーポイント回線の一般的なケ ースには対応できるが、ルータと番号無しポイントツーポイント回線のメッ シュ構成のケースに対応するために容易に拡張できないことである。二つ 目の欠点は、半分のルータ間の相互動作はかなり複雑であり標準化もされ ておらず、番号無しポイントツーポイント回線を使用する異なるベンダ製 の装置の接続を、実質的に妨げることである。 これらの欠点があるため、このメモは別のスキームを採用した。これは何 度か創案されているが、恐らく元は Phil Karn によるものである。このス キームでは、番号無しのポイントツーポイント回線を持つルータは、特殊 な IP アドレスも持つ。このメモでは、それをルータ ID と呼ぶ。ルータ ID は、ルータの IP アドレス (ルータは少なくとも一つの IP アドレスを 持つ必要がある) の一つである。このルータ ID は、あたかも全ての番号 無しインタフェースの IP アドレスであるかのように使用される。 2.2.8 著名な特殊ケース 2.2.8.1 組み込みルータ ルータは、IP ルータ機能専用のスタンドアロンコンピュータシステムであっ てもよい。また、二つ以上のネットワークへの接続をサポートするホスト オペレーティングシステムに、ルータ機能を組み込むことも可能である。 組み込まれたルータコードを持つオペレーティングシステムの最も良く知 られた例は、バークレイ BSD システムである。組み込みルータ機能は、ネッ トワークを容易に構築するようにみえるが、数多くの隠れた落とし穴があ る。 (1) もしホストが、ネットワークインタフェース構成要素を一つしか持た ないならば、ルータとして振る舞うべきではない。 例えば、ブロードキャストパケットやデータグラムを同一ネットワー ク上に余計に転送する組み込みルータコードを持つホストは、しばし ばパケットのなだれ現象を引き起こす。 (2) もし (マルチホームの) ホストがルータとして振る舞うならば、この ドキュメントに含まれているルータの要件に従う必要がある。 例えば、ルーティングプロトコルの問題やルータ制御と監視の問題は、 スタンドアロンルータと同様に、組み込みルータにおいても困難であ り重要である。 インターネットルータの要件や規約は、オペレーティングシステムの 変更とは関係なく変更されるかもしれない。インターネットで組み込 みルータを運用する管理者は、ルータコードを保守し更新することが 強く推奨される。これは、ルータのソースコードを必要とするかもし れない。 (3) ホストが組み込みルータコードを実行するとき、それはインターネッ ト基盤の一部となる。従って、ソフトウェアや設定の誤りが他のホス ト間の通信の妨げになりえる。つまり、ホスト管理者は、ある程度の 自主性を失わざるをえない。 多くの環境では、ホスト管理者はオペレーティングシステムに組み込 まれたルータコードを無効にする必要があるだろう。このため、組み 込みルータの機能を無効にする方法は簡単であるべきである。 (4) 組み込みルータのコードを実行しているホストが、同時に他のサービ スでも使用される時、運用と管理要件の二つの使用モードが競合する かもしれない。 例えば、ルータの O&M は多くの場合オペレーションセンターで遠隔に 実現される。これにより、ホスト管理者が通常与えたくないであろう 特権的なシステムアクセスを必要とするかもしれない。 2.2.8.2 トランスペアレントルータ ローカルエリアネットワークとワイドエリア (遠距離) ネットワークをイ ンターネットで相互接続する場合、二つの基本的なモデルが存在する。一 つ目は、ローカルエリアネットワークがネットワークプレフィクスを割り 当てられ、インターネット中の全てのルータは、そのネットワークへのル ーティング方法を知らなければならない。二つ目は、ローカルエリアネッ トワークが、ワイドエリアネットワークのアドレス空間 (の少しの部分) を共有する。この二つ目のモデルをサポートするルータは、アドレス共有 ルータ、あるいはトランスペアレントルータと呼ばれる。このメモの焦点 は一つ目のモデルをサポートするルータであるが、トランスペアレントル ータの使用を除外することは意図していない。 トランスペアレントルータの基本的な考え方は、そうしたルータの後方に あるローカルエリアネットワーク上のホストが、ルータの前方にあるワイ ドエリアネットワークのアドレス空間を共有することである。ある状況で はこれは非常に有効なアプローチであり、その制限が重大な欠点をもたら すことはない。 前方や後方という単語はこのアプローチの制限の一つを示す。相互接続の このモデルは、地理的に (トポロジ的に) 限定されたスタブ環境にのみ適 切である。ワイドエリアネットワークのネットワークレベルのアドレス付 けにおいて、論理的なアドレス付けの形式がいくつか必要である。ローカ ル環境の IP アドレスは、ワイドエリアネットワークの幾つかの (大抵は 一つの) 物理アドレスにマッピングされる。これは、ワイドエリアネット ワーク全体で使用される { IPアドレス <-> ネットワークアドレス } のマッ ピングと整合する方法でマッピングされる。 マルチホーミングは一つのワイドエリアネットワーク上で可能であるが、 もしインタフェースが地理的かトポロジ的に切り離されたら、ルーティン グの問題をもたらすかもしれない。二つ (以上) のワイドエリアネットワ ーク上のマルチホーミングは、アドレスの混乱により問題である。 もしトランスペアレントルータが通常のワイドエリアネットワークのサー ビスを完全にエミュレートできなければ、ホストが明らかに同じネットワ ークにある他のホストから見た振る舞いが異なるかもしれない。例えば ARPANET は、オフラインのホストに送信する試みに対する応答で、宛先デッ ド指示を提供するリンク層プロトコルを使用した。しかし、もし ARPANET とイーサネットの間にトランスペアレントルータが存在したら、ARPANET 上のホストはイーサネット上ののホストに対する宛先デッド指示を受信し ないだろう。 2.3 ルータの機能 インターネットルータは、以下の機能を実現する。 (1) このドキュメントに記述された特定のインターネットプロトコルに適 合する。それは、インターネットプロトコル (IP)、インターネット制 御管理プロトコル (ICMP)、必要に応じ他のプロトコルを含む。 (2) 二つ以上のパケットネットワークのインタフェースを持つ。各々の接 続されたネットワークに対して、ルータはそのネットワークで必要と される機能を実装しなければならない。これらの機能は、通常以下を 含む。 o 接続されたネットワークフレーム (例えばイーサネットヘッダや チェックサム) を持つ、IP データグラムのカプセル化とカプセル 除去。 o そのネットワークでサポートされた最大長までの IP データグラム の送受信。このサイズはネットワークの最大転送単位、あるいは MTU である。 o IP 宛先アドレスの、接続ネットワークの適切なネットワークレベ ルのアドレス (例えば、イーサネットのハードウェアアドレス) へ の変換 o もし必要なら、ネットワークフロー制御やエラー指示への応答。 詳細は、チャプタ 3 (リンク層) 参照のこと。 (3) インターネットデータグラムの受信や転送。この処理における重要な 問題はバッファ管理、輻輳制御、公正さである。 o エラー状態の認識と、必要に応じて ICMP エラーや情報メッセージ の生成。 o 生存時間フィールドが 0 に達したデータグラムの破棄。 o 次ネットワークの MTU に合わせるために必要な場合、データグラ ムの分割。 詳細は、チャプタ 4 (インターネット層 - プロトコル) とチャプタ 5 (インターネット層 - 転送) 参照のこと。 (4) ルーティングデータベース中の情報に基づく、各 IP データグラムの 次ホップの宛先の選択。詳細は、チャプタ 3 (インターネット層 - 転 送) を参照のこと。 (5) (通常) 同じ自律システムの他のルータと共に、分散ルーティングと到 達性アルゴリズムを実行するための、内部ゲートウェイプロトコル (IGP: interior gateway protocol) のサポート。加えて、幾つかのル ータは他の自律システムとトポロジ情報を交換するために、外部ゲー トウェイプロトコル (EGP: exterior gateway protocol) をサポート する必要があるだろう。詳細は、チャプタ 7 (アプリケーション層 - ルーティングプロトコル) を参照のこと。 (6) 負荷、デバッグ、状態通知、例外通知や管理を含むネットワーク管理 とシステムサポート機能の提供。詳細は、チャプタ 8 (アプリケーショ ン層 - ネットワーク管理プロトコル) とチャプタ 10 (操作と保守)を 参照のこと。 ルータベンダは特定のルータ製品に対して能力、複雑性、機能性で沢山の 選択肢がある。インターネットシステムは、同質のものでも完全に一貫し たものでもないと認識することは有効的かもしれない。技術や地理的な理 由により、インターネットは LAN のはずれ周辺を加えたグローバルな相互 接続システムにまで大きくなりつつある。これらの外辺の LAN がますます 数多く相互接続されるに従って、除外される LAN はますます減り、ルータ への要求がますます高くなる。 o グローバルな相互接続システムは、幾つかの自律システム (AS) のルー タを接続した数多くのワイドエリアネットワークで構成され、システム に直接接続されるホストは比較的少ない。 o 大半のホストは、LAN に接続される。多くの組織は、ローカルルータに よって相互接続された LAN の集団を持つ。そうした各々の集団は、グロ ーバルな相互接続システムにルータによって一つ以上の点で接続される。 もし一点だけでしか接続されていなければ、LAN はスタブネットワーク と見なされる。 グローバルな相互接続システムの中にあるルータは一般に以下を必要とす る。 o 進歩したルーティングと転送アルゴリズム これらのルータは高度に動的で、処理と通信負担を最小限とし、サービ スタイプのルーティングを提供するルーティングアルゴリズムを必要と する。輻輳はまだ完全に解決された問題ではない (セクション [5.3.6] 参照)。研究団体はこれらの問題に対して活発に検討しており、これら の分野での改善が期待される。 o 高可用性 これらのルータは信頼性が高く、1 日 24 時間、1 週間 7 日のサービ スを提供する必要がある。装置やソフトウェアの障害は、広範囲 (時に はグローバル) への影響を引き起こす可能性がある。障害が発生した場 合、即刻回復しなければならない。如何なる環境においても、ルータは 高度に頑強性を持ち、極端な輻輳状態やネットワーク資源の障害の下で、 質の低下した状態でも運用できなければならない。 o 進歩した O&M の機能 インターネットルータは通常、無人モードで運用される。ルータは通常、 中央監視センタから遠隔操作される。ルータは、障害診断のためにトラ フィックや他のイベントの監視や計測を行うための、洗練された手段を 提供する必要がある。 o 高いパフォーマンス インターネットにおける遠距離回線は今日、大半が全二重 56 Kbps、 DS1(1.544Mbps)、DS3(45Mbps) の速度である。LAN は半二重のマルチア クセスメディアであり、通常イーサネット (10Mbps)、規模は小さいが FDDI (100Mbps) である。しかし、ネットワークメディア技術は絶えず 成長しており、将来はより高速になるだろう。 LAN 周り (例えばキャンパスネットワーク) で使用されるルータは、ロー カルネットワークの要求に強く依存している。これらは高度あるいは中度 のパフォーマンスデバイスで、おそらく複数の異なるベンダから競札で調 達し、内部組織 (例えばキャンパスコンピュータセンタ) によって運用さ れる。これらのルータの設計は、遅延やサービスタイプを意識した資源管 理と共に、平均応答時間が短く、適切なバーストパフォーマンスを重視す べきである。この環境では正規の O&M は少ないが、重要性は低くない。高 度に動的なルーティングメカニズムの必要性は、ネットワークが複雑で相 互接続が増すにつれてより重要になるだろう。利用者は、グローバルな相 互接続の速度のために、ローカル接続からより多くを要求するだろう。 ネットワークが大きくなるにつれ、そして古い機器が徐々に撤去される程 ネットワークが古くなるにつれて、ルータが他ベンダ製のルータと相互運 用することは、ますます避けられなくなる。 たとえインターネットシステムが完全に相互接続されていなくとも、シス テムの多くの部分は冗長な接続性を持つ必要がある。豊富な接続性は、通 信回線やルータの障害にもかかわらず信頼できるサービスを可能にし、イ ンターネット経路を短縮することによって、そして付加的な収容能力を提 供することによってサービスを改善することもできる。不幸にも、このよ り高度なトポロジは、特定の宛先への最善経路の選択を非常に難しくする。 2.4 体系的な仮定条件 現在のインターネット体系は、通信システムに関する一連の仮定条件に基 づいている。最もルータに関連する仮定条件は、以下のものである。 o インターネットはネットワークのネットワークである。 各々のホストは幾つかの特定のネットワークに直接接続されており、イ ンターネットへの接続は単なる概念上のものである。同一ネットワーク 上の二つのホストは、離れたネットワーク上のホストと通信するために 用いる同一セットのプロトコルを使用して、お互いに通信する。 o ルータはコネクション状態情報を保存しない 通信システムの頑強性を改善するため、ルータは状態無しで設計され、 他のパケットとは独立して各々の IP パケットを転送する。結果的に、 ルータとネットワーク間で障害が発生しても頑強なサービスを提供でき るようにするために、冗長的なパスを活用することができる。 エンドツーエンドのフロー制御と信頼性に必要な全ての状態情報は、ホ ストのトランスポート層かアプリケーションプログラムで実装される。 従って、全てのコネクション制御情報は通信の両終端で保持され、一方 の終端に障害が起きた場合にのみその情報が失われる。ルータはパケッ トを落とすかネットワーク遅延を増やすことにより、間接的にしかメッ セージフローを制御できない。 将来のプロトコルの発達により、ルータに幾つかの状態が組み込まれる ようになるかもしれないことに注意されたい。これはマルチキャストル ーティングや資源予約、フローベースの転送で特に起こりそうである。 o ルーティングの複雑さはルータ内にあるべきである。 ルーティングは複雑で難しい問題であり、ホストではなくルータによっ て実現されるべきである。重要な目的は、インターネットルーティング 体系の避けられない発展によりもたらされる変更から、ホストソフトウェ アを保護することである。 o システムは広範囲なネットワークの多様性を許容しなければならない。 インターネット設計の基本的な目的は、広範囲なネットワーク特性、例 えば帯域や遅延、パケット損失、パケットの再順序、最大パケット長等 を許容することである。もう一つの目的は、個々のネットワークやルー タやホストの障害に対し、利用可能な帯域がまだある限り使用する頑強 性である。最後に、目標は完全なオープンシステムの相互接続であり、 インターネットルータは様々なインターネット経路に渡って、他のいか なるルータあるいはインターネットホストとも、頑強かつ効率的に相互 運用できなければならない。 時々、実装者は望ましくない目標のために設計することがある。例えば、 LAN 環境は通常インターネットよりも全体的に非常に優しく、LAN のパ ケット損失や遅延は低く、パケットを再順序化することも少ない。幾つ かのベンダは、単一の LAN 環境に適した実装体を擁したが、一般的な 相互運用では上手く動作しなかった。ベンダは、限定された LAN マー ケットの範囲内では経済的であるとして、そのような製品を正当化して いる。しかし、孤立した LAN が長い間孤立したままであることはめっ たにない。それらは間もなくお互いに接続され、組織単位で相互接続さ れ、最終的に世界的なインターネットシステムに接続されるだろう。結 局のところ、不完全で標準以下のルータが消費者やベンダの要求を満た すことはない。 このドキュメントの要件は、完全な機能を有するルータに対して設計さ れている。完全に準拠されたルータは、インターネットのほぼいかなる 部分にあっても利用できることを意図している。 3. リンク層 [INTRO:1] はリンク層の標準 (ARP 等の様々なリンク層上の IP) をカバー しているが、このドキュメントでは、リンク層に関連する内容は別のリン ク層要件のドキュメントでカバーされるだろうと期待している。リンク層 要件のドキュメントは、ホストとルータの両方に適用できるだろう。従っ て、このドキュメントは [INTRO:1] のリンク層の内容を扱っている部分を 廃止してはいない。 3.1 導入 ルータは、他のインターネットシステムと同様に、本質的にリンク層プロ トコル要件を持つ。これらの要件は、インターネットゲートウェイ要件 [INTRO:1] のチャプタ 3 に示されている。ルータはその要件に従わなけれ ばならず (MUST)、その推奨に従うべきである (SHOULD)。そのドキュメン トの幾つかの内容は古くなったので、幾つかの要件と説明を以下に含めて いる。 DISCUSSION: インターネット社会がインターネットリンク層のための標準を作成し、 このチャプタと [INTRO:1] の "インターネット層プロトコル" とタイ トル付けされたチャプタに取って代わることが期待される。 3.2 リンク/インターネット層インタフェース このドキュメントは、リンク層とその上位層間のインタフェースを規定す るつもりはない。しかし、このドキュメントの他のパート、特にチャプタ 5 は、この層境界で渡すべき様々な種類の情報を要求していることに注意 されたい。 このセクションは以下の定義を使用する。 o 送信元物理アドレス 送信元物理アドレスはパケットをどこから受信したかを示す、ホストか ルータのリンク層アドレスである。 o 宛先物理アドレス 宛先物理アドレスはパケットをどこへ送信したかを示すリンク層アドレ スである。 各々の受信パケットについて、リンク層からインターネットワーク層に渡 さなければならない情報は、 (1) IPパケット [5.2.2] (2) リンク層フレームの (すなわちリンク層フレームを含まない) データ 部の長さ [5.2.2] (3) IP パケットを受信した物理インタフェースの識別情報 [5.2.3] (4) パケットの宛先物理アドレスのリンク層ユニキャスト、ブロードキャ スト、マルチキャストへの分類 (5) 送信元物理アドレス 各々の送信パケットについて、インターネットワーク層からリンク層に渡 さなければならない情報は、 (1) IP パケット [5.2.1] (2) IP パケットの長さ [5.2.1] (3) 宛先物理インタフェース [5.2.1] (4) 次ホップ IP アドレス [5.2.1] 加えて、インターネットワーク層は以下も渡すべきである。 (5) リンク層優先度の値 [5.3.3.2] また、もし送信されたパケットがリンク層の優先度関連の異常を引き起こ したら、リンク層はインターネットワーク層に通知しなければならない [5.3.3.3]。 3.3 特定の問題 3.3.1 トレイラカプセル化 10メガビットのイーサネットに接続できるルータは、[LINK:1] で規定され ているトレイラカプセル化を使用してカプセル化されたイーサネットパケッ トを送受信できてもよい (MAY)。しかし、ルータはトレイラカプセル化さ れたパケットを発行すべきではない (SHOULD NOT)。ルータは、パケットの 直接の宛先がトレイラカプセル化されたパケットの受信に同意し受信可能 であることを、[INTRO:2] で規定されているメカニズムを使用して最初に 検証せずに、トレイラカプセル化されたパケットを発行してはならない (MUST NOT)。 3.3.2 アドレス解決プロトコル - ARP ARP を実装しているルータは、[INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。 リンク層は、宛先未到達エラーを IP に単独で通知してはならない (MUST NOT)。なぜなら、その宛先に対する ARP キャッシュエントリが存在 しないからである。リンク層は、ARP 要求/応答シーケンスを実行する間、 少数のデータグラムを一時的にキューイングし、これが効果が無いと判明 した場合にのみ、キューイングされたデータグラムの一つに対して、宛先 が未到達であると応答すべきである (SHOULD)。 別のホストかルータのリンク層アドレスがブロードキャストやマルチキャ ストアドレスであると主張する如何なる ARP 応答も信じないようにしなけ ればならない (MUST)。 3.3.3 イーサネットと 802.3 の共存 10 MBのイーサネットに接続できるルータは、[INTRO:2] のイーサネット要 件に準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。 3.3.4 最大転送単位 - MTU 各々の論理インタフェースの MTU は、そのインタフェースに対して正しい MTU の範囲内で設定可能でなければならない (MUST)。 多くのリンク層プロトコルは、送信してもよい最大フレーム長を定義して いる。そのような場合、ルータはリンク層プロトコルで許されているサイ ズよりも大きいフレームの送信を可能にするような MTU の設定を許しては ならない (MUST NOT)。しかし、ルータはたとえ MTU よりも大きくとも、 最大フレーム長と同じ大きさのパケットの受信を同意すべきである (SHOULD)。 DISCUSSION これは、[INTRO:2] でホストに課せられている、各々の物理インタフェ ースの MTU を設定可能にすることを求める要件よりも厳しい要件であ ることに注意されたい。 もしネットワークがリンク層の最大フレーム長よりも小さい MTU を使 用しているならば、ルータは設定の誤ったホストや不完全に初期化され たホストから、MTU よりも大きいパケットを受信してもよい。頑強性の 原則は、ルータは可能ならばこれらのパケットを正常に受信すべきであ ることを指示している。 3.3.5 ポイントツーポイントプロトコル - PPP [INTRO:1] に反して、実際にはインターネットには標準的なポイントツー ポイント回線プロトコルがある。それは、[LINK:2], [LINK:3], [LINK:4], [LINK:5] で定義されたポイントツーポイントプロトコル (PPP) である。 ポイントツーポイントインタフェースは、ポイントツーポイント回線上に データを送信するために設計されたインタフェースである。このようなイ ンタフェースは、電話回線、専用回線、専用線、直接回線 (2 線か 4 線) を含み、ポイントツーポイントチャネルや ISDN 等の多重化インタフェー スの仮想回線を使用してもよい。それらは同期か非同期クロックを使用し た、標準化されたモデムかビットシリアルインタフェース (RS-232, RS-449, V.35等) を通常使用する。多重化インタフェースは、しばしば特 殊な物理インタフェースを持つ。 一般目的シリアルインタフェースは、ポイントツーポイント回線と同じ物 理媒体を使用するが、ポイントツーポイントの接続性だけでなく、リンク 層ネットワークの使用もサポートしている。リンク層ネットワーク (X.25 やフレームリレー等) は、別の IP リンク層規約を使用する。 ポイントツーポイントか一般目的シリアルインタフェースを実装するルー タは、PPP を実装しなければならない (MUST IMPLEMENT)。 ルータの全ての一般目的シリアルインタフェースで、PPP がサポートされ なければならない (MUST)。ルータは、PPP 以外のポイントツーポイント回 線を使用するよう、回線の設定を可能にしてもよい (MAY)。ポイントツー ポイントインタフェースは、利用可能なときデフォルトで PPP を使用する か、利用可能になる前にリンク層プロトコルの設定を要求するべきである (SHOULD)。一般目的シリアルインタフェースは、利用可能になる前にリン ク層プロトコルの設定を要求すべきである (SHOULD)。 3.3.5.1 導入 このセクションは、ルータ実装者に、同期/非同期回線上で PPP を使用す る他のルータとの相互接続性を保証するためのガイドラインを提供する。 実装者がオプション折衝メカニズムを理解することは重要である。オプショ ンは、ローカルデバイスがリモートの相手から何を受諾し何を送信して欲 しくないかを、ローカルデバイスがリモートの相手に示す手段である。ロ ーカルデバイスが受諾できると主張したオプションセットの制限の中で、 何を送信するのが最も効率的であるかを決定することはリモートの相手次 第である。従って、たとえリモートの相手がそれらのオプションの幾つか をサポートしていなくても、リモートの相手が LCP 通信設定要求 (CR) で 指示された全てのオプションに ACK を送信することは、完全に受け入れら れるし、一般的である。また、オプションは単にいずれかのデバイスが何 を受諾するかを相手に示すメカニズムであり、必ずしも何を送信するかを 示すわけではない。 3.3.5.2 リンク制御プロトコル (LCP) オプション PPP リンク制御プロトコル (LCP) は、折衝してもよい数多くのオプション を提供する。これらのオプションは、(他の中でも) アドレスと制御フィー ルド圧縮、プロトコルフィールド圧縮、同期キャラクタマッピング、最大 受信単位 (MRU)、リンク品質監視 (LQM)、マジックナンバ (ループバック の検出のため)、パスワード認証プロトコル (PAP)、同期認証プロトコル (CHAP)、32 ビットフレームチェックシーケンス (FCS) を含む。 ルータは、同期/非同期回線のいずれかでアドレス/制御フィールド圧縮を 使用してもよい(MAY)。ルータは、同期/非同期回線のいずれかでプロトコ ルフィールド圧縮を使用してもよい (MAY)。これらの圧縮を受諾できるこ とを示すルータは、非圧縮の PPP ヘッダ情報も受諾できなければならない (MUST)。 DISCUSSION これらのオプションは PPP ヘッダの形を制御する。通常、PPP ヘッダ はアドレス、制御フィールド、プロトコルフィールドで構成される。ポ イントツーポイント回線上のアドレスは 0xFF であり、"ブロードキャ スト" を示す。制御フィールドは 0x03 であり、"アンナーバード情報" を示す。プロトコル識別子は 2 バイト値で、フレームのデータ域の内 容を示す。もしシステムがアドレスと制御フィールド圧縮を折衝するな らば、ヘッダの前部にこれらのフィールドを持つ PPP フレームや持た ない PPP フレームを受諾することを相手に示す。それは、これらのフィ ールドを削除して送信することを示すわけではない。 プロトコルフィールド圧縮が折衝された場合、そのシステムは 1 バイ トに圧縮されたプロトコルフィールドを、規則に則っている場合に受信 できることを示す。送信者が実際に圧縮するという要件はない。 アドレス/制御フィールド圧縮の使用は、ナンバードモードの (信頼で きる) PPP の使用と相反する。 IMPLEMENTATION あるハードウェアは、可変長のヘッダ情報を上手く扱うことができない。 そのような場合、リモートの相手が完全な PPP ヘッダを送信すること が最も重要である。実装体は、アドレス/制御フィールドとプロトコル フィールド圧縮オプションをリモートの相手に送信しないことによって これを保証してもよい。たとえリモートの相手が圧縮ヘッダの受信能力 を示したとしても、ローカルルータが圧縮したヘッダを送信する要件は ない。 ルータは、非同期 PPP リンクでは非同期制御文字マップ (ACCM) を折衝し なければならない (MUST) が、同期リンクでは ACCM を折衝すべきではな い (SHOULD NOT)。もしルータが同期リンク上で ACCM を折衝する試みを受 信したら、そのオプションに対して ACK を送信し、その上でそれを無視し なければならない (MUST)。 DISCUSSION 同期と非同期の両方の操作モードを提供し、オプション折衝を実装する のに同じコードを使用している実装体が存在する。この場合、どちらか 一方の終端が同期リンク上で ACCM オプションを送信する可能性がある。 ルータは、最大受信単位 (MRU) を正確に折衝すべきである (SHOULD)。た とえシステムが、MRU を 1500 バイト以下で折衝したとしても、1500 バイ トのフレームを受信できなければならない (MUST)。 ルータはリンク品質監視 (LQM) オプションを折衝し、利用可能にすべきで ある (SHOULD)。 DISCUSSION このメモは、リンクの品質が適切であるか否かを決定するための指針を 規定しない。しかし、障害のあるリンクを利用不可にすることは重要で ある (セクション[3.3.6]参照)。 ルータはループバック検出のために、マジックナンバオプションを実装し、 折衝すべきである (SHOULD)。 ルータは認証オプション (PAP - パスワード認証プロトコルや CHAP - 同 期認証プロトコル)をサポートしなければならない (MUST)。 ルータは 16 ビット CRC フレームチェックシーケンス (FCS) をサポート しなければならず (MUST)、32 ビット CRC をサポートしてもよい (MAY)。 3.3.5.3 IP 制御プロトコル (IPCP) オプション ルータは IP アドレス折衝の実行を申し出てもよい (MAY)。ルータは相手 からの IP アドレス折衝を実行することに対する拒否 (REJect) を受諾し なければならない (MUST)。 19200bps かそれ以下の回線速度で運用するルータは、Van Jacobson ヘッ ダ圧縮の実行を実装し提供すべきである (SHOULD)。VJ 圧縮を実装するル ータは、VJ 圧縮を利用可/不可にする管理制御を実装すべきである (SHOULD)。 3.3.6 インタフェーステスト ルータは、物理インタフェースがパケット送信で利用可能か否かを、ルー ティングソフトウェアが決定するためのメカニズムを持たなければならな い (MUST)。限定された一連の隣接者に対して永久的な仮想回線がオープン されている多重化インタフェース上では、ルータは仮想回線が利用できる か否かを決定できなけばならない (MUST)。ルータは、ルーティングソフト ウェアが物理インタフェースの品質を判断するためのメカニズムを持つべ きである (SHOULD)。ルータは、管理上の動作のためのパケット送信で物理 インタフェースが利用可能になる時、あるいは利用不可になる時に、ルー ティングソフトウェアに通知するメカニズムを持たなければならない (MUST)。ルータは、何らかの理由でリンクレベルインタフェースが利用可 能になったこと、あるいは利用不可になったことを検出した時に、ルーティ ングソフトウェアに通知するメカニズムを持たなければならない (MUST)。 DISCUSSION ルータが、そのネットワークコネクションが正常に機能していることを 決定するために動かせるメカニズムを持つことは重要である。リンク損 失を検出しないか、問題を検出したときに適切な動作を実行しないこと は、ブラックホールを招く可能性がある。 ネットワークコネクションの問題を検出するために利用できるメカニズ ムは、使用するリンク層プロトコルやインタフェースハードウェアによっ てかなり異なる。その目的は、障害を検出する能力をリンク層の制約の 中で最大限に活用することである。 4. インターネット層 - プロトコル 4.1 導入 このチャプタとチャプタ 5 は、インターネット層で使用されるプロトコル、 IP, ICMP, IGMP について論じている。ルータを論じるドキュメントでは、 転送は明らかに重要なトピックなので、チャプタ 5 自体は転送に直接関連 するプロトコルの側面に限定している。このチャプタは、インターネット 層プロトコルのその他を含んでいる。 4.2 インターネットプロトコル - IP 4.2.1 導入 [INTERNET:1] で定義されているように、ルータは IP プロトコルを実装し なければならない (MUST)。ルータはさらにその必須の拡張、サブネット ([INTERNET:2] で定義)、IP ブロードキャスト ([INTERNET:3] で定義)、 クラスレスドメイン間ルーティング (CIDR: [INTERNET:15]で定義) もまた 実装しなければならない (MUST)。 ルータ実装者は、"インターネットプロトコル -- IP" のタイトルが付けら れた [INTRO:2] のセクションに準拠しようと考える必要はない。なぜなら、 そのセクションは全体的にこのドキュメントと重複し、このドキュメント に取って代わるからである。ルータは、[INTRO:2] の IP に関連する "特 定の問題" (SPECIFIC ISSUE) のタイトルが付けられたセクションの要件に 準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。 次に、あるケースで規定された動作は受信したデータグラムを黙って破棄 することである。これは、以降の処理を行わずにデータグラムを破棄し、 結果としてルータは如何なる ICMP エラーメッセージも送信しない (セク ション [4.3] 参照) ことを意味する。しかし問題の診断のために、ルータ はエラーをログ採取する機能 (セクション [1.3.3] 参照) を提供すべきで あり (SHOULD)、黙って破棄したデータグラムの内容を含め、破棄したデー タグラムの個数を数えるべきである (SHOULD)。 4.2.2 プロトコル - ウォークスルー RFC791 [INTERNET:1] は、インターネットプロトコルの規約である。 4.2.2.1 オプション: RFC791 セクション3.2 ルータ自身によって受信されたデータグラムでは、IP 層は理解できる IP オプションを解釈し、その他は上位層プロトコルで使用するために変更せ ずに残しておかなければならない (MUST)。 上位層プロトコルは、送信するデータグラムに IP オプションを設定した り、受信するデータグラムの IP オプションを検査できることを必要とす るかもしれない。このドキュメントの後半のセクションは、上位層プロト コルによって必要とされる特定の IP オプションのサポートについて論じ ている。 DISCUSSION このメモも [INTRO:2] も、受信者が同じ IP ヘッダ中の複数のオプショ ンを処理しなければならない順番は定義していない。複数のオプション を含むデータグラムを作成するホストやルータは、送信元経路オプショ ンと併用する時、あるオプションの意味が曖昧になることを知っておか ねばならない。 以下は、特定の IP オプションの要件である。 (a) セキュリティオプション ある環境では、生成、あるいは受信された全てのパケットにセキュリ ティオプションを必要とする。ルータは、[INTERNET:5] で規定されて いる改訂されたセキュリティオプションを実装すべきである (SHOULD IMPLEMENT)。 DISCUSSION [INTERNET:1] と RFC1038 ([INTERNET:16]) で規定されているセキュリ ティオプションは、廃止されたことに注意されたい。 (b) ストリーム識別子オプション このオプションは廃止された。ルータは自分が生成するデータグラ ムにこのオプションを付加すべきでない (SHOULD NOT)。ルータは、 受信したデータグラムのこのオプションを無視しなければならない (MUST)。 (c) 送信元経路オプション ルータは、送信元経路の最終宛先として動作できなければならない (MUST)。もしルータが完了した送信元経路を含むパケットを受信し たら、そのパケットは最終宛先に到達している。そのようなオプショ ンの場合、ポインタは最終フィールドを超えたところを指しており、 IP ヘッダ中の宛先アドレスはルータのアドレスになっている。受信 したオプション (記録されている経路) は、トランスポート層 (あ るいは ICMP メッセージ処理) に渡さなければならない (MUST)。 通常のケースでは、送信元経路を持つデータグラムに対する正しい 応答は同じ経路を辿る。ルータは、トランスポートプロトコルとア プリケーションが、受信したデータグラム中の送信元経路を逆戻り できる手段を提供しなければならない (MUST)。ルータがポリシー上 の制約を知らない場合、反転させた送信元経路を、生成するデータ グラムに挿入 (詳細は [INTRO:2] 参照) しなければならない (MUST)。しかし、もしルータがポリシーを知っているならば、別の 経路を選択してもよい (MAY)。 ルータの幾つかのアプリケーションは、ユーザが送信元経路を入力 できることを要求してもよい (MAY)。 ルータは複数の送信元経路オプションを含むデータグラムを生成し てはならない (MUST NOT)。もし、複数の送信元経路オプションを含 むパケットの転送を要求されたらルータが何をすべきかについては、 セクション [5.2.4.1] で規定されている。 送信元経路オプションが生成される場合 (ルータが送信元経路付き データグラムを発行するか、特殊なフィルタの結果として送信元経 路を挿入する時に起こる)、たとえそれが送信元ホストを誤って含む (以下の議論のケース (B) 参照) 記録経路を反転することによって 生成されるものであっても、正しく作成しなければならない (MUST)。 DISCUSSION 送信元経路が付加されたデータグラムが、ルータ G1, G2, Gn の順路を 経て、送信元 S から宛先 D まで送られると仮定する。送信元 S は宛 先アドレスとして G1 の IP アドレスを持ち、データグラムが宛先まで の残りの道を得るための送信元経路オプションを持つデータグラムを生 成する。しかし、S によって送信されたデータグラム中の送信元経路オ プションが、以下の (A) か (B) のどれであるべきかについて規約は曖 昧である。 (A): {>>G2, G3, ... Gn, D} <--- 正しい (B): {S, >>G2, G3, ... Gn, D} <---- 誤り (>> はポインタを表す)。もし (A) が送信されたら、D で受信するデー タグラムは、IP 送信元アドレスが S で、宛先アドレスが D になり、 オプション {G1, G2, ... Gn >>} を含む。もし (B) が送信されたら、 D で受信するデータグラムは、(A) と同様に IP 送信元アドレスが S で、宛先アドレスが D であるが、オプションは {S, G1, ...Gn >>} で ある。すなわち、生成元ホストがその経路の第一ホップになってしまう。 (d) 経路記録オプション ルータは、ルータが生成するデータグラムに記録経路オプションを サポートしてもよい (MAY)。 (e) タイムスタンプオプション ルータは、ルータが生成するデータグラムにタイムスタンプオプショ ンをサポートしてもよい (MAY)。以下の規則を適用する。 o タイムスタンプオプションを含むデータグラムを発行するとき、 もし以下が当てはまるならば、ルータはそのオプションにタイム スタンプを記録しなければならない (MUST) - インターネットアドレスフィールドがあらかじめ指定されてい ない、あるいは - あらかじめ指定されたアドレスの先頭が、データグラムが送信 されている論理インタフェースの IP アドレス (あるいはデー タグラムがアンナンバードのインタフェース上に送信されてい るなら、そのルータのルータ ID) である。 o もしルータ自身がタイムスタンプオプションを含むデータグラム を受信したら、ルータはトランスポート層にそのオプションを渡 すか、ICMP の処理を行う前に、現在の時間をタイムスタンプオプ ションに (もしオプションに挿入するスペースがあるならば) 挿 入しなければならない (MUST)。もしスペースが無ければ、ルータ はオプション中のオーバフロー数を加算しなければならない (MUST)。 o タイムスタンプの値は、[INTRO:2] で定義された規則に従わなけ ればならない (MUST)。 IMPLEMENTATION タイムスタンプオプションに含まれるタイムスタンプの利用を最大限に 活用するために、挿入されるタイムスタンプは、パケットがルータにほ ぼ実際に到着した時間であるべきである。ルータによって生成されるデ ータグラムの場合は、挿入されるタイムスタンプは、転送するためにリ ンク層にデータグラムをほぼ実際に渡した時間であるべきである。 タイムスタンプオプションは標準でないタイムクロックの使用を許して いるが、時刻の合っていないタイムクロックの使用はタイムスタンプの 有用性を制限する。従って、ルータは自分の時間を合わせるために、ネッ トワークタイムプロトコルを実装することが推奨される。 4.2.2.2 オプション中のアドレス: RFC791 セクション3.1 ルータは自分のアドレスを、経路記録や厳密な送信元と経路記録、厳密で ない送信元と経路記録、タイムスタンプオプションに挿入することが求め られる。ルータがこれらのオプションに自分のアドレスを挿入する場合、 パケットを送信しようとしている物理インタフェースの IP アドレスを使 用しなければならない。出力インタフェースが IP アドレスを持っていな いために (例えば番号なしのインタフェース等)、この規則に従うことがで きない場合は、ルータは自分のルータ ID を代わりに挿入しなければなら ない (MUST)。ルータのルータ ID は、ルータの IP アドレスの一つである。 ルータ ID はシステムベースで指定してもよいし、リンクベースで指定し てもよい。ルータ ID として使用されるルータのアドレスは、ネットワー ク管理者によって変更されない限り、(たとえリブートしても) 変更しては ならない (MUST NOT)。関連する管理変更は、例えばルータ ID として使用 される IP アドレスが、ルータの IP アドレスの一つから除くようなルー タの再設定を伴う。複数の番号無しインタフェースを持つルータは、複数 のルータ ID を持ってもよい (MAY)。各々の番号無しインタフェースは、 特定のルータ ID を割り当てなければならない (MUST)。この割当ては、 (たとえリブートしても) ルータを再設定せずに変更してはならない (MUST NOT)。 DISCUSSION この規定は、ルータが IP アドレスを一つも持たないことを許していな い。我々はこれが重大な制限であるとは考えていない。なぜなら、たと えルータがポイントツーポイント回線にしか接続されていなくても、チャ プタ [8] の管理しやすさの要件に適合するために、ルータは IP アド レスを必要とするからである。 IMPLEMENTATION ルータ ID の選択において、この要件を満たす一つのあり得る方法は、 ルータに割り当てられた IP アドレスのうち、数値上 (32 ビットの整 数値としてアドレスを扱う) 最小の (あるいは最大の) IP アドレスを 使用することである。 4.2.2.3 未使用 IP ヘッダビット: RFC791 セクション3.1 IP ヘッダは二つの予約ビットを含む。一つはサービスタイプのバイトで、 もう一つはフラグフィールドである。ルータは、ルータによって生成され るデータグラムに、これらのビットのどちらにも 1 を設定してはならない (MUST NOT)。ルータは、単に一つ以上のこれらの予約ビットが 0 でない値 であるという理由で、パケットを落と (受信/転送を拒否) してはならない (MUST NOT)。すなわち、ルータはそのビットをチェックしてはならない (MUST NOT)。 DISCUSSION IP プロトコルの将来の改訂により、これらの未使用ビットが使用され るかもしれない。これらの規則は、インターネット内の全てのルータを 同時にアップグレードすることなく、これらの改訂を展開できることを 保証しようとしている。 4.2.2.4 サービスタイプ: RFC791 セクション3.1 IP ヘッダのサービスタイプバイトは、三つのセクションに分割される。そ れは、優先度フィールド (上位 3 ビット)、慣例的にサービスタイプまた は TOS と呼ばれているフィールド (次の 4 ビット)、予約ビット (残りの ビット) である。 予約ビットの管理方法は、セクション [4.2.2.3] に記述されている。 TOS フィールドとその使用に関する詳細な議論は、[ROUTE:11] にある。 IP 優先度フィールドの規定は、セクション [5.3.3] に取って代わる。 RFC795、サービスマッピングは廃止され、実装すべきではない (SHOULD NOT)。 4.2.2.5 ヘッダチェックサム: RFC791 セクション3.1 セクション [5.2.2] で述べられているように、ルータは受信した如何なる パケットの IP チェックサムも検査しなければならず (MUST)、不正なチェッ クサムを含むメッセージを破棄しなければならない (MUST)。ルータは、こ のチェックサム検査を無効にする手段を提供してはならない (MUST NOT)。 IP ヘッダのうち唯一変わるものが生存時間だけである場合、ルータは IP ヘッダチェックサムの増分更新を使用してもよい (MAY)。これは、IP ヘッ ダの改悪をルータが検出しない可能性を減らす。チェックサムの増分更新 の議論は [INTERNET:6] を参照されたい。 IMPLEMENTATION 実装時の詳細なヒントを含め、IP チェックサムついてのより詳細な規 定は、[INTERNET:6] と [INTERNET:7] で見ることができる。 4.2.2.6 未知のヘッダオプション: RFC791 セクション3.1 ルータは認識できない IP オプションを無視しなければならない (MUST)。 この要件により生ずる結果として、ルータはオプションリストの最終と操 作無しオプションを実装しなければならない (MUST)。なぜなら、どちらも 明示的な長さを含まないからである。 DISCUSSION 将来の IP オプションは全て明示的な長さを含むだろう。 4.2.2.7 分割: RFC791 セクション3.2 [INTERNET:1]で説明されているように、ルータは分割をサポートしなけれ ばならない(MUST)。 ルータが IP データグラムを分割する時、ルータはフラグメントの個数を 最小にすべきである (SHOULD)。ルータが IP データグラムを分割する時、 ルータはフラグメントを順序通りに送信すべきである (SHOULD)。他よりも 際立って小さい一つの IP フラグメントを生成するかもしれない分割方法 では、一番最初の IP フラグメントを小さくしてもよい (MAY)。 DISCUSSION インターネットでよく使われている幾つかの分割技術が存在する。一つ は、一番始めを MTU サイズとし、その他をおよそ同じサイズで MTU よ りも小さくし、IP データグラムを IP フラグメントに分割する方法で ある。この理由は二つの面がある。シーケンスにおける一番最初の IP フラグメントは、ホスト間の現在のパスの有効 MTU であり、以降の IP フラグメントは IP データグラムをさらに分割することを最小限にする サイズとなる。もう一つの技術は、IP データグラムを MTU サイズの IP フラグメントに分割し、最後のフラグメントのみ小さくする方法で ある。これは [INTERNET:1] で説明されている。 幾つかの TCP/IP 実装でよく使われているやり方は、IP データグラム がルータを通過して送られる時に、IP データグラムを 576 バイトを超 えない IP フラグメントに分割する方法である。これは、結果的に IP フラグメントを更に分割せずに、残りの経路を通過させることを意図し ている。しかしこれは、より多くの IP フラグメントを一つの IP デー タグラムに組み立てることになるので、宛先ホストに大きな負荷をかけ ることになるだろう。また、MTU が一回しか変わらず、576 バイトより もずっと大きいネットワーク上でも効率的ではない。例えば、MTU が 2048 である IEEE 802.5 ネットワークや、MTU が 1500 であるイーサ ネットネットワークといった LAN ネットワークが該当する。 もう一つ議論されている分割技術は、IP データグラムを、次ホップネッ トワークの MTU と等しいかそれ以下のサイズで、ほぼ等しいサイズの IP フラグメントに分割することである。この意図は、パスを下ってさ らに分割された結果生じるフラグメントの個数を最小限に留め、各々の フラグメントに対して遅延が等しくなることを保証することである。 ルータが生成する IP フラグメントの数は、可能な限り最小限にすべき である (SHOULD)。 遅いマシンで作業していると、もしメッセージを分割する必要があるな らば、最初に小さい IP フラグメントを送信した方が、遅いインタフェ ースを持つホストで全てのフラグメントを受信する機会が最大限に増え ると思わせる。 4.2.2.8 組み立て: RFC791 セクション 3.2 関連した [INTRO:2] のセクションに規定されているように、ルータは自分 に配送されたデータグラムの組み立てをサポートしなければならない (MUST)。 4.2.2.9 生存時間: RFC791 セクション 3.2 ルータによって生成、あるいは受信されたバケットを処理する生存時間 (TTL) は、[INTRO:2] が適用される。このセクションは、その規定を何も 変更しない。しかし、[INTRO:2] の IP プロトコルのセクションの残りが 書き直されたので、このセクションも同様である。 特にルータは、転送する時以外にパケットの TTL をチェックしてはならな い (MUST NOT) ことに注意されたい。 ルータは、0 の生存時間 (TTL) の値を持つデータグラムを生成または転送 してはならない (MUST NOT)。 ルータは、単に TTL が 0 か 1 で受信したという理由だけでデータグラム を破棄してはならない (MUST NOT)。もしそのデータグラムがルータ向けで、 他の値が正しければ、ルータは受信を試みなければならない (MUST)。 ルータが生成するメッセージに対し、IP 層は送信される全てのデータグラ ムの TTL フィールドを設定する手段を、トランスポート層に提供しなけれ ばならない (MUST)。固定の TTL 値を使用する場合、その値は設定可能で なければならない (MUST)。その数は典型的なインターネットの直径を超え るべきであり (SHOULD)、現在の識者は成長を計算に入れてインターネット の直径の二倍を超えるべきであると提案している。現在提案されている値 は通常、番号割当て RFC で公表されている。TTL フィールドは二つの役割 を持っている。それは、TCP セグメントの生存時間を制限する (RFC793 [TCP:1], p.28) ことと、インターネットルーティングループを終結させる ことである。TTL は秒単位の時間であるが、各々のルータは TTL フィール ドを少なくとも 1 減らす必要があるので、ホップ数の特性も持ち合わせて いる。 TTL の満了はルータによるデータグラムの破棄を意図しているが、宛先ホ ストで破棄することは意図していない。データグラムを転送することによっ てルータとして振舞うホストは、TTL に関するルータの規則に従わなけれ ばならない。 上位層プロトコルは、あるインターネット資源の "拡張スコープ" 検索を 実装するために、TTL を設定することを望むかもしれない。これは何らか の診断ツールによって使用され、例えば IP マルチキャストを使用してい る所定のクラスの、"最も近い" サーバを捜し当てるのに効果的であること が期待される。特定のトランスポートプロトコルもまた、データグラムの 最大生存時間に結び付けられた自分自身の TTL を指定したいかもしれない。 固定のデフォルト値は、少なくともインターネットの "直径"、すなわち有 り得る最長パスほど十分大きくなければならない。継続的なインターネッ トの発展に備えるために、効率的な値は直径の約二倍である。ここで書か れているように、米国を渡るメッセージは、しばしば 15 から 20 のルー タを横断する。デフォルトの TTL 値についての議論では 40 を超え、64 が一般的な値である。 4.2.2.10 複数サブネットブロードキャスト: RFC922 全サブネットのブロードキャスト ([INTERNET:3] では複数サブネットブロ ードキャストと呼ばれる) は廃止された。セクション [5.3.5.3] 参照。 4.2.2.11 アドレス付け: RFC791 セクション3.2 2.2.5.1 に記述したように、現在クラス A からクラス E まで、5 個の IP アドレスのクラスが存在する。クラス D は IP マルチキャスト [ INTERNET:4] で使用され、クラス E は実験的使用のために予約されてい る。クラス A, B, C のアドレスの区別はもはや重要ではない。それらは、 一般化されたユニキャストネットワークプレフィクスとして使用され、 クラスについては歴史的な興味しかない。 IP マルチキャストアドレスはホストのグループを表す 28 ビットの論理ア ドレスであり、永久的か一時的かのいずれかである。永久的マルチキャス トアドレスは、インターネット番号割当て機関 [INTRO:7] によって割り当 てられ、一時的アドレスは動的に一時的グループに割り当てられる。グル ープメンバシップは、IGMP [INTERNET:4] を使用して動的に決定される。 以下の IP アドレスの表記方法を用いて、汎用的なユニキャスト IP アド レスの重要な特殊ケースについて要約して説明する。 { , } 全てのビットが 1 のフィールドは -1 と記述し、全てビットが 0 のフィ ールドは 0 と記述する。 (a) { 0, 0 } このネットワーク上のこのホスト。ルータは (例えば、もしルータが 設定情報をロードするために BOOTP を使用しているならば) 初期化 手続きの一部で、これを送信元アドレスとして使用してもよい (MAY)。 しかしこれを除いては、送信元アドレスとして使用してはならない (MUST NOT)。 ローカル配送 ([5.2.3] 参照) のために受信された { 0, 0 } の送信 元アドレスを持つ入力データグラムは、ルータがこれに関連するプロ トコルを実装していて、実行すべき適切な動作をそのプロトコルが明 確に定義しているならば、受信しなければならない (MUST)。さもな くば、送信元アドレスが { 0, 0 } であるローカル配送されたデータ グラムを、ルータは黙って破棄しなければならない (MUST)。 DISCUSSION あるプロトコルは、送信元アドレスが { 0, 0 } であるデータグラムの 受信に応じて、ある特定の動作を定義している。二つの例は、BOOTP と ICMP マスク要求である。これらのプロトコルの適切な処理は、送信元 アドレスが { 0, 0 } であるデータグラムを受信できる能力にしばしば 依存する。しかし、大半のプロトコルは送信元アドレスが { 0, 0 } で あるデータグラムを無視することが最善である。それらは、恐らく誤っ て設定されたホストやルータによって生成されたからである。つまり、 もしルータが { 0, 0 } の送信元アドレスを持つデータグラムの扱い方 を知っているならば、それを受信しなければならない (MUST)。さもな くば、ルータはそれを破棄しなければならない (MUST)。 また、{ 0, 0 } の標準的でない使用については、セクション [4.2.3.1] を参照されたい。 (b) { 0, } このネットワーク上の特定のホスト。ルータは自分の IP アドレス を知る初期化手続きの一部でこれを送信元アドレスとして使用して もよい (MAY) が、それを除いてルータは送信してはならない (MUST NOT)。 (c) { -1, -1 } 限定されたブロードキャスト。送信元アドレスとして使用してはな らない (MUST NOT)。 この宛先アドレスを持つデータグラムは、接続された物理ネットワ ーク上の全てのホストとルータによって受信される。しかし、ネッ トワークの外側には転送されない。 (d) { , -1 } 直接ブロードキャスト - 特定のネットワークプレフィクスに向けら れたブロードキャスト。送信元アドレスとして使用してはならない (MUST NOT)。ルータは、ネットワーク直接ブロードキャストパケッ トを生成してもよい (MAY)。ルータは、ネットワーク直接ブロード キャストパケットを受信しなければならない (MUST) が、これらの パケットの受信を止める設定オプションを持ってもよい (MAY)。そ のようなオプションは、デフォルトでは受信を許さなければならな い (MUST)。 (e) { 127, } 内部ホストループバックアドレス。この形式のアドレスは、ホスト の外側に出てはならない (MUST NOT)。 は、デバイスが接続されているルーティングドメイン 内で、値がユニークになるように管理上割り当てられる 上記に示した特殊なケースを除いて、IP アドレスは や フィールドに 0 か -1 の値を持つことが許されない。 これは、各々のこれらのフィールドが少なくとも 2 ビット長であること を暗黙的に意味する。 DISCUSSION このドキュメントの以前の版では、サブネット番号も 0 と -1 のいず れも使用不可であり、少なくとも 2 ビット長でなければならないこと を記述していた。CIDR の世界では、サブネット番号は明らかにネット ワークプレフィクスの拡張であり、プレフィクスの残りが無ければ解釈 できない。従って、このサブネット番号の制限は CIDR の観点では無意 味であり、無視しても差しつかえない。 ブロードキャストアドレスの更なる議論については、セクション [4.2.3.1] を参照されたい。 ルータはいかなるデータグラムを発行する時も、IP 送信元アドレスは自分 の IP アドレスの一つ (ブロードキャストやマルチキャストアドレスは除 く) でなければならない (MUST)。唯一の例外は、初期化の時である。 大抵の用途において、ブロードキャストやマルチキャストの宛先に向けら れたデータグラムは、あたかもルータの IP アドレスの一つに向けられた かのように処理される。つまり、 o ルータは、ブロードキャストの宛先アドレスを持つパケットを、正常に 受信して処理しなければならない (MUST)。 o ルータは、受信を求められたマルチキャストの宛先アドレスに送信され たパケットを、正常に受信して処理しなければならない (MUST)。 特定の宛先アドレスという用語は、ホストのローカル IP アドレスと同等 の意味を持つ。特定の宛先アドレスは、もしヘッダがブロードキャストや マルチキャストアドレスを含んでいなければ、IP ヘッダ内の宛先アドレス であると定義される。その場合、特定の宛先はデータグラムが到達した物 理インタフェースに割り当てられた IP アドレスである。 ルータは、このセクションの規則により不正な IP 送信元アドレスを含む 受信データグラムを、黙って破棄しなければならない (MUST)。この確認は、 IP 層か (適切ならば) トランスポート層の各プロトコルのいずれかによっ て実施される。ルータはデータグラムを破棄する場合、データグラムを破 棄した数をカウントすべきである (SHOULD)。 DISCUSSION 誤ったアドレスを持つデータグラムは、ユニキャストデータグラムのリ ンク層ブロードキャストによって、あるいは、設定が誤っている別のル ータやホストによって引き起こされるかもしれない。 4.2.3 特定の問題 4.2.3.1 IPブロードキャストアドレス 歴史的な理由により、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 アドレスマスク応答を送信する時を除いて)、限定ブロードキャストア ドレス (255.255.255.255) を (デフォルトで) 使用すべきである (SHOULD)。 (4) 0.0.0.0 か { , 0 } のアドレスを持つデータグラム を生成すべきではない (SHOULD NOT)。(関連する 1 の形式のブロード キャストを使用する代わりに) これらのパケットを生成可能にする設 定オプションが存在してもよい (MAY)。このオプションは、デフォル トでは生成しないようすべきである (SHOULD)。 DISCUSSION 二段落目に関して、ルータはそのネットワークプレフィクスへのインタ フェースを持っていなければ、{ , 0 } の形式のアド レスを明らかに認識することができない。その場合、ルータから見ると そのパケットは IP ブロードキャストパケットではないので、二段落目 の規則は適用されない。 4.2.3.2 IP マルチキャスト IP ルータは、[INTRO:2] で規定されている IP マルチキャストに関連する ホスト要件を満たすべきである (SHOULD)。IP ルータは、全ての接続され たネットワーク上のローカル IP マルチキャストをサポートすべきである (SHOULD)。IP マルチキャストアドレスからリンク層アドレスへのマッピン グが規定された場合 (様々な IP-over-xxx 規約参照)、ルータはそのマッ ピングを使用すべきである (SHOULD)。または、その代わりとしてリンク層 のブロードキャストを使用するよう設定可能にしてもよい (MAY)。ポイン トツーポイント回線や他の全てのインタフェース上では、マルチキャスト はリンク層のブロードキャストとしてカプセル化される。ローカル IP マ ルチキャストのサポートは、マルチキャストデータグラムの生成、マルチ キャストグループへの加入、マルチキャストデータグラムの受信、マルチ キャストグループからの離脱を含む。これは、IGMP (セクション [4.4] 参 照) を含む [INTERNET:4] の全てをサポートすることを暗黙的に意味する。 DISCUSSION [INTERNET:4] は IP マルチキャストのためのホスト拡張という題名で あるが、全ての IP システム、ホストとルータ両方に適用される。特に ルータは、マルチキャストグループに加入してもよいので、ルータが IGMP のホストの役割を実行し、グループメンバシップを、(自分がマル チキャストルータであるか否かに関わらず) 接続されたネットワーク上 に存在するかもしれない全てのマルチキャストルータに通知することは 正しい。 幾つかのルータプロトコルは、IP マルチキャストのサポートを明確に 必要とするかもしれない (例えば OSPF [ROUTE:1]) し、あるいは推奨 するかもしれない (例えば ICMP ルータ検出 [INTERNET:13])。 4.2.3.3 パス MTU 検出 分割を避けたり最小限に留めるために、送信元から宛先までのパスに沿っ たパス MTU を知ることが望ましい。パス MTU は、パスにおける各々のホッ プの最小値である。[INTERNET:14] は、任意のインターネットパスの最大 転送単位 (MTU) を動的に検出する技術を説明している。[INTERNET:14] を サポートしていないルータを通過するパスについては、この技術では正し いパス MTU を検出しないかもしれない。しかし、その技術は古い技術や現 在実行されている技術によって選択されるパス MTU と同等か、あるいはよ り正確なパス MTU を常に選択するだろう。 ルータが IP データグラムを生成する時、ルータは [INTERNET:14] で規定 された、データグラムのサイズを限定するためのスキームを使用すべきで ある (SHOULD)。もしデータグラムの宛先へのルータの経路が、パス MTU 情報を提供するルーティングプロトコルから分かるならば、[INTERNET:14] で規定されているスキームを依然として使用するが、ルーティングプロト コルによるパス MTU 情報をパス MTU についての初期推測として、そして パス MTU の上限として使用すべきである (SHOULD)。 4.2.3.4 サブネット化 ある環境下では、サブネット化されたネットワークの一部ではないパスを 通じてのみ相互接続されている、ある特定のネットワークのサブネットを サポートすることが望ましいかもしれない。これは、隣接していないサブ ネットワークのサポートとして知られている。 ルータは、隣接していないサブネットワークをサポートしなければならな い (MUST)。 IMPLEMENTATION 古い IP ネットワークでは、これを達成することが非常に難しかったが、 CIDR ネットワークでは当然の副産物である。従って、ルータはサブネッ ト体系を仮定すべきでない (SHOULD NOT) が、各々の経路を汎用のネッ トワークプレフィクスとして扱うべきである (SHOULD)。 DISCUSSION インターネットは、最近すごい勢いで成長している。これは IP アドレ ス付け技術に厳しい負担をかけている。この負担の主要な要因は、厳密 な IP アドレスクラスの境界である。これらは、ネットワークプレフィ クスのサイズを効率的に定めたり、複数のネットワークプレフィクスを 単一の経路通知に集約させることを困難にしている。IP アドレスの厳 密なクラス境界を取り除き、各経路を包括的なネットワークプレフィク スとして扱うことによって、これらの負担を大幅に減らすであろう。 現在これを行うための技術は、クラスレスドメイン間ルーティング (CIDR) [INTERNET:15] である。 同様な理由で、あるネットワークプレフィクスに割り当てられたアドレス ブロックは、異なるサイズのサブブロックに更に分割することができる。 そのため、サブブロックに割り当てられたネットワークプレフィクスは、 異なる長さを持つだろう。例えば、ネットワークプレフィクスが 8 ビット 長であるブロックの中で、あるサブブロックは 16 ビットのネットワーク プレフィクスを持ってもよいし、またあるものは 18 ビットのネットワー クプレフィクスを持ってもよいし、他にも 14 ビットのネットワークプレ フィクスを持ってもよい。 ルータは、設定とルーティングデータベースの両方で可変長のネットワー クプレフィクスをサポートしなければならない (MUST)。 4.3 インターネット制御メッセージプロトコル - ICMP 4.3.1 導入 ICMP は、ルーティングや診断、IP のエラー機能を提供する補助プロトコ ルである。それは [INTERNET:8] で規定されている。ルータはICMPをサポ ートしなければならない (MUST)。 ICMPメッセージは、以下のセクションで論じられる二つのクラスにグルー プ化される。 ICMP エラーメッセージ 宛先未到達 セクション 4.3.3.1 リダイレクト セクション 4.3.3.2 送信元抑制 セクション 4.3.3.3 時間超過 セクション 4.3.3.4 パラメタ問題 セクション 4.3.3.5 ICMP キュエリメッセージ エコー セクション 4.3.3.6 情報 セクション 4.3.3.7 タイムスタンプ セクション 4.3.3.8 アドレスマスク セクション 4.3.3.9 ルータ検出 セクション 4.3.3.10 一般的な ICMP 要件と議論は、次のセクションにある。 4.3.2 一般的な問題 4.3.2.1 未知のメッセージタイプ 未知のタイプの ICMP を受信したら、ICMP ユーザインタフェースに渡す (もしルータがそれを持っているならば) か、黙って破棄 (もしルータがイ ンタフェースを持っていないならば) しなければならない (MUST)。 4.3.2.2 ICMP メッセージ TTL ICMP メッセージを生成する時、ルータは TTL を初期化しなければならな い (MUST)。ICMP 応答の TTL は、応答の要因となったパケットから取得し てはならない。 4.3.2.3 元のメッセージヘッダ 歴史的に、全ての ICMP エラーメッセージは、エラーの要因となったデー タグラムのインターネットヘッダと、少なくとも最初の 8 データバイトを 含んでいた。IP-IP トンネルや他の技術を使用するため、これはもはや適 切ではない。従って、ICMP データグラムは 576 バイトの ICMP データ長 を超えない範囲で、元のデータグラムを可能な限り多く含むべきである (SHOULD)。ルータはエラーを検出する前に転送時に通常実行した、IP ヘッ ダに対する如何なる修正 (例えば、TTL の減算やオプションの更新等) も 取り消す必要が無いことを除いて、返却する IP ヘッダ (とユーザデータ) は、受信したものと同じでなければならない (MUST)。幾つかのケースでは、 セクション [4.3.3.5] の要件がこの要件を上書きすることを注意されたい (例えばパラメタ問題メッセージにおいて、その問題が修正されたフィール ドにあるならば、ルータはその修正を取り消さなければならない)。セクショ ン [4.3.3.5] を参照されたい。 4.3.2.4 ICMP メッセージ送信元アドレス このドキュメントが他のケースを規定している部分を除き、ルータが生成 する ICMP メッセージの IP 送信元アドレスは、ICMP メッセージを送信す る物理インタフェースに割り当てられた IP アドレスの一つでなければな らない (MUST)。もしインタフェースに割り当てられた IP アドレスが無い ならば、代わりにルータのルータ ID (セクション [5.2.5] 参照) を使用 する。 4.3.2.5 TOS と優先度 その TOS 値を設定すると、その宛先に振り分けることができない故に ICMP エラーメッセージが即座に破棄されるということがないならば、ICMP エラーメッセージは、そのメッセージの送信を誘発したパケット中の TOS ビットと同じ値が設定された TOS ビットを含むべきである (SHOULD)。さ もなくば、ICMP エラーメッセージは通常の TOS (すなわち 0) で送信しな ければならない (MUST)。ICMP 応答メッセージは、応答を引き起こした ICMP 要求の中の TOS ビットと同じ値を設定した TOS ビットを含むべきで ある (SHOULD)。 ICMP 送信元抑制エラーメッセージは、もし送信されたならば、ICMP 送信 元抑制メッセージの送信を引き起こしたパケット中の IP 優先度フィール ドと同じ値を、IP 優先度フィールドに持たなければならない (MUST)。他 の全ての ICMP エラーメッセージ (宛先未到達、リダイレクト、時間超過、 パラメタ問題) は、優先度値に 6 (インターネットワーク制御) か 7 (ネッ トワーク制御) を持つべきである (SHOULD)。これらのエラーメッセージの IP 優先度値は設定可能でもよい (MAY)。 ICMP 応答メッセージは、IP 優先度フィールドに、応答を引き起こした ICMP 要求の中の IP 優先度フィールドと同じ値を設定しなければならない (MUST)。 4.3.2.6 送信元経路 もし、ICMP エラーメッセージの送信を引き起こしたパケットが送信元経路 オプションを含んでいたら、ICMP エラーメッセージは、同じタイプ (厳密 または厳密でない) の送信元経路オプションも含むべきである (SHOULD)。 それは、元のパケットの送信元経路オプション中の記録された経路のポイ ンタの位置の前に、反転することによって作成される。これらは、ICMP エ ラーメッセージが、元のパケット中の送信元経路オプションに対して不平 を示す ICMP パラメタ問題でないか、あるいはルータが ICMP エラーメッ セージの配送を防ぐポリシーを知らない場合に行われる。 DISCUSSION 米国国防省セキュリティオプション ([INTERNET:5] で定義) を使用す る環境では、ICMP メッセージはセキュリティオプションを含む必要が あるかもしれない。このトピックにおける詳細な情報は国防通信機関か ら入手すべきである。 4.3.2.7 ICMP エラーを送信しないケース ICMPエラーメッセージは以下の受信の結果で送信してはならない (MUST NOT)。 o ICMP エラーメッセージ o セクション [5.2.2] に記述されている IP ヘッダの確認テストに失敗し たパケット (そのセクションで ICMP エラーメッセージの送信を特に許 している場合は除く) o IP ブロードキャストか IP マルチキャスト宛てのパケット o リンク層ブロードキャストかマルチキャストとして送信されたパケット o 送信元アドレスが 0 のネットワークプレフィクスを持つか、不正な (セ クション [5.3.7] で定義されている) 送信元アドレスを持つパケット o 最初のセグメント以外のデータグラムのフラグメント (すなわち、IP ヘッ ダのフラグメントオフセットが 0 でないパケット) さらに、このメモでパケットを黙って破棄するよう記述している場合は、 ICMP エラーメッセージを送信してはならない (MUST NOT)。 注記: これらの制限は、ICMP エラーメッセージの送信に対するこのドキュ メントのその他の要件よりも優先される。 DISCUSSION これらの規則は、ルータやホストがブロードキャストパケットに応答し て、ICMP エラーメッセージを返却することによってブロードキャスト の嵐が起こされることを防ぐ意図がある。例えば、存在しないポートへ のブロードキャスト UDP パケットは、その宛先ポートのためのクライ アントを持たない全てのデバイスからの、ICMP 宛先未到達データグラ ムの洪水を引き起こし得る。大規模なイーサネット上では、結果として 衝突が生じ、一秒以上もの間ネットワークが役に立たなくなり得る。 接続されたネットワーク上にブロードキャストされる全てのパケットは、 その IP 宛先として正しい IP ブロードキャストアドレスを持つべきで ある (セクション [5.3.4] と [INTRO:2] 参照)。しかし、幾つかのデ バイスはこの規則に違反している。従って、ブロードキャストパケット の検出を確実に行うために、ルータは IP 層のアドレスだけでなく、リ ンク層のブロードキャストをチェックする必要がある。 IMPLEMENTATION+ これは、リンク層がリンク層のブロードキャストパケットを受信した時 に、IP 層に通知することを必要とする。セクション [3.1] 参照。 4.3.2.8 割合制限 ICMP 送信元抑制メッセージを送信するルータは、メッセージを生成する割 合を制限できなければならない (MUST)。ルータは他の種類の ICMP エラー メッセージ (宛先未到達、リダイレクト、時間超過、パラメタ問題) を送 信する割合も制限できるべきである (SHOULD)。割合制限パラメタは、ルー タの設定の一部として設定可能であるべきである (SHOULD)。どのように制 限が適用されるか (例えばルータ毎かインタフェース毎か) は、実装者の 判断に任される。 DISCUSSION ICMP エラーメッセージを送信するルータの二つの問題点は、 (1) 戻りパスの帯域の消費 (2) ルータ資源の使用 (例えばメモリや CPU 時間等) これらの問題の解決に役立たせるために、ルータは ICMP エラーメッセ ージを生成する頻度を制限できる。同様な理由で、ルータは例えば ICMP エコー応答など別の種類のメッセージを生成する頻度を制限して もよい。 IMPLEMENTATION ICMPメッセージを送信する割合を制限するために、様々なメカニズムが 使用され、提案されている。 (1) 数ベース - 例えば全体あるいは指定された送信元ホストに対して、 N 個のパケットが落ちた毎に ICMP エラーメッセージを送信する。 このメカニズムは ICMP 送信元抑制で使用するなら適切かもしれな いが、恐らく他のタイプの ICMP メッセージでは適切でない。 (2) 時間ベース - 例えば、指定された送信元ホストあるいは全体に対 して、T ミリ秒毎に最大一回 ICMP エラーメッセージを送信する。 (3) 帯域ベース - 例えば、ICMP メッセージを特定のインタフェース上 に送信する割合を、接続されたネットワークの帯域の何分の一かに 制限する。 4.3.3 特定の問題 4.3.3.1 宛先未到達 もしルータが、パケット中に指定された宛先への経路が全く無い (デフォ ルト経路が無いことを含む) ためにパケットを転送できないならば、ルー タはコード 0 (ネットワーク未到達) の ICMP メッセージ、宛先未到達を 生成しなければならない (MUST)。もしルータがパケット中に指定された宛 先ネットワークへの経路を持っているが、その経路で指定された TOS がデ フォルト TOS (0000) でも、ルータが振り分けようと試みているパケット の TOS でもないならば、ルータはコード 11 (TOS のためにネットワーク 未到達) の ICMP メッセージ、宛先未到達を生成しなければならない (MUST)。 もし、パケットが直接ルータに接続されたネットワーク上のホストに転送 されるもの (つまりそのルータは最終ホップのルータ) で、ルータが宛先 ホストへのパスが存在しないことを突きとめたならば、ルータはコード 1 (ホスト未到達) の ICMP メッセージ、宛先未到達を生成しなければならな い (MUST)。もし、パケットが直接ルータに接続されたネットワーク上にあ るホストに転送されたもので、パケットで要求された TOS と等しいか、デ フォルト TOS (0000) である TOS を持つ宛先への経路が無いために、その パケットを転送できないならば、ルータはコード 12 (TOS のためにホスト 未到達) の ICMP メッセージ、宛先未到達を生成しなければならない (MUST)。 DISCUSSION この意図は、ルータが宛先へのパス (デフォルト経路を含め) を全く持 たないならば、"一般的な" ホスト/ネットワーク未到達を生成すること である。もしルータが経路への一つ以上のパスを持つが、いずれのパス も受諾できる TOS を持たないならば、ルータは "TOS のために未到達" を生成する。 4.3.3.2 リダイレクト ICMP リダイレクトメッセージは、あるトラフィックのために別の次ホップ のルータを使用すべきであることをローカルホストに通知するために生成 される。 [INTRO:2] とは反対に、ルータはもしルーティングプロトコルを動かして いるか、ルータやパケットを送信しようとしているインタフェース上で転 送が有効であれば、ルータが生成したパケットのパスを選択する時に、 ICMP リダイレクトを無視してもよい (MAY)。 4.3.3.3 送信元抑制 ルータは ICMP 送信元抑制メッセージを生成すべきでない (SHOULD NOT)。 セクション [4.3.2] で規定されているように、送信元抑制メッセージを生 成するルータは、それを生成する割合を制限できなければならない (MUST)。 DISCUSSION 調査によると、送信元抑制はネットワーク帯域を浪費するが、輻輳を防 ぐには非効率的 (不当) であることが判明している。例えば、 [INTERNET:9] と [INTERNET:10] を参照されたい。セクション [5.3.6] は、どのようにルータが負荷やネットワーク輻輳を扱うべきかについて、 現在の考え方を論じている。 ルータは、受信した ICMP 送信元抑制メッセージを無視してもよい (MAY)。 DISCUSSION ルータ自身は、別のルータやホストに送信するパケットを生成した結果、 送信元抑制を受信するかもしれない。そのデータグラムは、例えば別の ルータに送信された EGP 更新や、ホストに送信された telnet ストリ ームかもしれない。パケットが送信される割合を制御することによって、 IP 層に送信元抑制に対して直接応答させるメカニズムが提案されてい る ([INTERNET:11], [INTERNET:12])。しかしこの提案は現在実験段階 であり、現在は推奨されない。 4.3.3.4 時間超過 ルータがパケットを転送し、パケットの TTL フィールドが 0 に減らされ る時、セクション [5.2.3.8] の要件が適用される。 ルータがルータ宛てのパケットを組み立てる時、インターネットホストと して動作する。従って、[INTRO:2] の組み立て要件を適用する。 ルータが (ルータ宛ての) 時間超過メッセージを受信する時、[INTRO:2] に従わなければならない (MUST)。 4.3.3.5 パラメタ問題 他の ICMP メッセージで特にカバーされていないエラーについては、ルー タはパラメタ問題メッセージを生成しなければならない (MUST)。IP ヘッ ダフィールドやポインタフィールドによって指されたバイトを含む IP オ プションは、この ICMP メッセージで返却する IP ヘッダの中に、変更せ ずに含めなければならない (MUST)。セクション [4.3.2] は、この要件に 対する例外を定義している。 パラメタ問題メッセージの新たな変形は、[INTRO:2] で定義された。 Code 1 = 必要なオプションが省略されている DISCUSSION この変形は現在、軍部でセキュリティオプションの省略に対して使用さ れている。 4.3.3.6 エコー要求/応答 ルータは自分に送信されたエコー要求を受信し、それに対するエコー応答 を送信する、ICMP エコーサーバ機能を実装しなければならない (MUST)。 ルータは少なくとも最大 576 と、接続された全てのネットワークの MTU で、ICMP エコー要求データグラムを受信し、組み立て、エコーする準備を しなければならない (MUST)。 エコーサーバ機能は、IP ブロードキャストか IP マルチキャストアドレス を持つ ICMP エコー要求に応答しないことを選択してもよい (MAY)。 ルータはもし可能ならば、全ての ICMP エコー要求を黙って無視させる設 定オプションを持つべきである (SHOULD)。もし提供されるならば、このオ プションはデフォルトで応答を許さなければならない (MUST)。 DISCUSSION ブロードキャストやマルチキャストのエコー要求についての、この曖昧 な規定は、[INTRO:2] の "エコー要求/応答" セクションが由来である。 セクション [10.3.3] で述べられているように、ルータは診断のために、 エコー要求を送信したりエコー応答を受信するための、ユーザ/アプリケー ション層のインタフェースも実装しなければならない (MUST)。全ての ICMP エコー応答メッセージは、このインタフェースに渡さなければならな い (MUST)。 ICMP エコー応答の中の IP 送信元アドレスは、対応する ICMP エコー要求 メッセージの特定の宛先アドレスと同じでなければならない (MUST)。 ICMP エコー要求の中で受信したデータは、結果として生じたエコー応答に 全体を含めなければならない (MUST)。 もし ICMP エコー要求の中に経路記録やタイムスタンプオプションを受信 したら、このオプション (これらのオプション) を取り除かずに、現在の ルータを含めるために更新し、エコー応答メッセージの IP ヘッダに含め るべきである (SHOULD)。従って、記録された経路は全体の往復経路になる だろう。 もし ICMP エコー要求の中に送信元経路オプションを受信したら、ルータ がメッセージの配送を妨げるポリシーを知らないならば、返却経路を反転 させてエコー応答メッセージの送信元経路オプションとして使用しなけれ ばならない (MUST)。 4.3.3.7 情報要求/応答 ルータは、これらのメッセージを生成したり応答すべきではない (SHOULD NOT)。 DISCUSSION 情報要求/応答のペアは、ディスクレスワークステーション等のような 自己設定システムのサポートや、ブート時に IP ネットワークプレフィ クスを発見できることを意図していた。しかし、これらのメッセージは 現在は廃止されている。ホストが自分の IP アドレスを発見するために、 RARP と BOOTP プロトコルがよりよいメカニズムを提供している。 4.3.3.8 タイムスタンプとタイムスタンプ応答 ルータは、タイムスタンプとタイムスタンプ応答を実装してもよい (MAY)。 もしそれらが実装されているならば、 o ICMP タイムスタンプサーバ機能は、受信した全てのタイムスタンプメッ セージに対して、タイムスタンプ応答を返却しなければならない (MUST)。 遅延の変動を最小限にするよう設計すべきである (SHOULD)。 o IP ブロードキャストかマルチキャストアドレス向けの ICMP タイムスタ ンプ要求メッセージは、黙って破棄してもよい (MAY)。 o ICMP タイムスタンプ応答の中の IP 送信元アドレスは、対応するタイム スタンプ要求メッセージで指定された宛先アドレスと同じでなければな らない (MUST)。 o もし ICMP タイムスタンプ要求で送信元経路オプションを受信して、ル ータがそのメッセージの配送を止めるポリシーを知らないならば、返却 経路を反転して、タイムスタンプ応答メッセージの送信元経路オプショ ンとして使用しなければならない (MUST)。 o もし ICMP タイムスタンプ要求で経路記録とタイムスタンプオプション を受信したら、このオプションに現在の経路を含めるよう更新し、タイ ムスタンプ応答メッセージの IP ヘッダに含めるべきである (SHOULD)。 o もしルータが、タイムスタンプ要求メッセージを送信するための応用層 インタフェースを提供するならば、受信したタイムスタンプ応答メッセ ージを ICMP ユーザインタフェースに渡さなければならない (MUST)。 タイムスタンプ値 (標準値) における好ましい形式は、世界時の真夜中か らのミリ秒である。しかし、ミリ秒の分解能でこの値を提供することは難 しいかもしれない。例えば、多くのシステムは一秒間に 5, 60 回のライン 頻度でしか更新しないクロックを使用している。従って、標準値には多少 の許容範囲が認められている。 (a) 標準値は少なくとも 1 秒間に 16 回更新しなければならない (MUST)。 (すなわち、値のうち多くて 6 個の下位ビットは未定義でもよい)。 (b) 標準値の精度は、演算セットの CPU クロック、すなわち数分以内の精 度に近づけなければならない (MUST)。 IMPLEMENTATION 二番目の条件を適えるために、ルータは起動するか再開する時に、時刻 サーバにキュエリを送る必要があるかもしれない。この目的のために、 UDP 時刻サーバプロトコルを使用することが推奨される。より進歩した 実装は、ミリ秒のクロック同期をほぼ達成するために、ネットワークタ イムプロトコル (NTP: Network Time Protocol) を使用するだろう。し かし、これは必須ではない。 4.3.3.9 アドレスマスク要求/応答 ルータはアドレスマスク要求メッセージの受信をサポートし、ICMP アドレ ス応答メッセージで応答しなければならない (MUST)。これらのメッセージ は [INTERNET:2] で定義されている。 ルータは各々の論理インタフェースにおいて、ルータがそのインタフェー スでアドレスマスク要求に答えることを許すか否かを指定する設定オプショ ンを持つべきである (SHOULD)。そして、このオプションはデフォルトで応 答を許可しなければならない (MUST)。ルータは、正しいアドレスマスクを 知る前にアドレスマスク要求に応答してはならない (MUST NOT)。 ルータは、0.0.0.0 の送信元アドレスを持ち、複数の論理インタフェース に割り当てられ、それらのインタフェースのアドレスマスクが全て同じで はない物理インタフェース上に到着したアドレスマスク要求に応答しては ならない (MUST NOT)。 ルータは、含まれている情報がアドレスマスクに関するルータの認識と一 致しているか否かを決定するために、受信した全ての ICMP アドレスマス ク応答を検査すべきである (SHOULD)。もし ICMP アドレスマスク応答にエ ラーが見つかったら、ルータはそのアドレスマスクと送信側の IP アドレ スをログに採取すべきである (SHOULD)。ルータは、ICMP アドレスマスク 応答の内容を、正しいアドレスマスクを決めるのに使用してはならない (MUST NOT)。 ホストが立ち上がった時にルータが停止していたら、ホストはアドレスマ スクを認識できないかもしれないので、ルータは自分のアドレスマスクを 設定した後で、各々の論理インタフェース上に 自発的な ICMP アドレスマ スク応答をブロードキャストしてもよい (MAY)。しかし、この機能は可変 長のアドレスマスクを使用する環境では危険になり得る。従って、もしこ の機能を実装するならば、自発的なアドレスマスク応答は、以下に該当す る論理インタフェース上には、どれにもブロードキャストしてはならない (MUST NOT)。 o 自発的なアドレスマスク応答を送信する設定になっていない。各々の論 理インタフェースは、これを制御する設定パラメタを持たなければなら ない (MUST)。そして、そのパラメタは、自発的なアドレスマスク応答を 送信しないことがデフォルトでなければならない (MUST)。 o ネットワークプレフィクスと物理インタフェースを包含して (しかし同 一ではない) 共有する。 アドレスマスク応答をブロードキャストする際、IP ブロードキャストアド レスの { , -1 } 形式を使用しなければならない (MUST)。 DISCUSSION アドレスマスク応答の送信をルータによって無効にする能力は、アドレ スマスクについて意図的にホストに嘘をつく幾つかのサイトで必要であ る。この必要性は、ホストがホスト要件の標準に準拠するにつれて無く なることが期待される。 上記の二段落目と、使用される IP ブロードキャストアドレスに関する 要件の両方の理由は、複数の IP ネットワークプレフィクスが同じ物理 ネットワーク上で使用される際の問題を避けることである。 4.3.3.10 ルータの告知と誘導 IP ルータは、IP マルチキャストか IP ブロードキャストアドレス付けを サポートしている全ての接続されたネットワーク上で、ICMP ルータ検出プ ロトコル [INTERNET:13] のルータ部をサポートしなければならない (MUST)。 実装体は、ルータで規定されている設定変数の全てを、規定されているデ フォルト値で含まなければならない (MUST)。 DISCUSSION ルータは、ICMP ルータ検出プロトコルのホスト部を実装する必要はな いが、IP 転送が無効の間 (すなわちホストとして動作している時)、ホ スト部を実装していることは運用上効果的かもしれない。 DISCUSSION ホストがルータ検出プロトコルとして RIP バージョン 1 を試用するこ とは、かなり一般的である。そのようなホストは RIP トラフィックを リッスンし、そのトラフィックから抽出された情報を使用してルータを 検出し、ある宛先において第一ホップルータとしてどのルータを使用す るか決める。この動作は推奨されないが、依然として一般的であり、実 装者はこのことを知っておくべきである。 4.4 インターネットグループ管理プロトコル - IGMP IGMP [INTERNET:4] は、単一の物理ネットワーク上のホストとマルチキャ ストルータ間で、特定のマルチキャストグループ内でホストのメンバーシッ プを確立するために、使用されるプロトコルである。マルチキャストルー タは、インターネットを渡って IP マルチキャスト転送をサポートするた めに、マルチキャストルーティングプロトコルと共にこの情報を使用する。 ルータは、IGMP のホスト部を実装すべきである (SHOULD)。 5. インターネット層 - 転送 5.1 導入 このセクションは、パケットの転送プロセスについて規定している。 5.2 転送ウォークスルー IP における転送機能の別の規定は存在しない。代わりに、転送はインター ネット層プロトコルのプロトコル規定([INTERNET:1], [INTERNET:2], [INTERNET:3], [INTERNET:8], [ROUTE:11])によってカバーされている。 5.2.1 転送アルゴリズム 主要なプロトコルドキュメントはどれも転送アルゴリズムを詳細に説明し ていないので、ここでそれを提供する。これは単に一般的な概要であり、 例えば輻輳の扱いといった重要な詳細は略している。それらは後のセクショ ンで扱っている。 実装体は、セクション[5.2.1.1],[5.2.1.2],[5.2.1.3]に記述されているア ルゴリズムに正確に従う必要はない。ルータソフトウェアを書く挑戦の大 半は、アルゴリズムと同じ効果を依然として達成しながらも、ルータがパ ケットを転送できる割合を最大化することである。それを行う方法の詳細 は、ルータのアーキテクチャに強く依存する部分であるので、このドキュ メントの適用範囲を超えている。その代わり、以下のステップの順序に従 うことを指摘するだけである。 (1) ルータは、ヘッダの内容に基づく動作を実行する前に、セクション [5.2.2]に記述されているようにIPヘッダを検証する。これらよりルー タは他の資源を消費する前に、不正なパケットを検出して破棄するこ とが可能になる。 (2) あるIPオプションの処理では、ルータが自分のIPアドレスをオプショ ン中に挿入する必要がある。セクション[5.2.4]で記述されているよう に、挿入されるアドレスはパケットが送信される論理インタフェース のアドレスか、もしアンナンバードのインタフェース上でパケットが 送信されるならばルータのルータIDでなければならない。従って、こ れらのオプションの処理は出力インタフェースが選択される後まで完 了できない。 (3) セクション[4.2.2.9]で言及されている理由により、ルータはパケット をルータ自身に配送すべきか否かをチェックする前に、TTL をチェッ クしたり決定することができない。 (4) より一般的に、パケットをローカルにルータに配送するとき、その IP ヘッダはどんなことがあっても修正してはならない (MUST NOT)。(IP ヘッダ中のタイムスタンプオプションにタイムスタンプを挿入する必 要があるかも知れないことを除く)。従って、元に戻す機能を持たない ルータは、パケットをローカルにルータに配送するか否かを決定する 前に IP ヘッダを更新することができない。 5.2.1.1 一般 このセクションは、一般的な転送アルゴリズムをカバーしている。このア ルゴリズムは転送するパケットの全ての形式、ユニキャスト、マルチキャ スト、ブロードキャスト、に適用される。 (1) ルータはリンク層からIPパケット(とセクション[3.1]に記述されてい るような、それに関する追加情報)を受信する。 (2) ルータは、セクション [5.2.2] で規定されているように IP ヘッダを 評価する。ステップ (4) のローカル配送のためにキューイングされた IP フラグメントを除いて、IP の組み立ては行わないことに注意され たい。 (3) ルータは、IP オプションの大半の処理を実行する。セクション [5.2. 4] で規定されているように、幾つかの IP オプションはルーティング の決定を行った後で追加の処理を必要とする。 (4) ルータはセクション [5.2.3] で規定されているように、IP データグ ラムの処理をどのように継続すべきかを決定するために、IP データグ ラムの宛先 IP アドレスをチェックする。起こりえることは三つある。 o IP データグラムがルータ宛てであり、ローカル配送のためにキュ ーイングすべきである。必要ならば組み立てを実行する。 o IP データグラムがルータ宛てでなく、転送のためにキューイング すべきである。 o IP データグラムは転送のためにキューイングすべきであるが、コ ピーしたものをローカル配送するためのキューイングもまた行わな ければならない。 5.2.1.2 ユニキャスト ローカル配送の場合は、[INTRO:2] によって十分にカバーされているので、 以下は IP データグラムが転送のためにキューイングされているものと仮 定する。もし、その宛先が IP ユニキャストアドレスならば、 (5) 転送者は、通常ルータのルーティングテーブルにパケットの宛先を検 索することによって、そのパケットに対し次のホップの IP アドレス を決定する。この手続きは、セクション [5.2.4] で詳細に規定されて いる。この手続きは、パケットを送信するのにどのネットワークイン タフェースを使用するかも決定する。 (6) 転送者は、パケットの転送が許されているかを検証する。送信元と宛 先アドレスは、セクション [5.3.7] とセクション [5.3.4] で規定さ れているように、正しいべきである。もしルータが転送において、例 えばセクション [5.3.9] に規定されているような管理上の制約をサポ ートしているならば、それらの制約を満たさなければならない。 (7) 転送者は、セクション [5.3.1] で規定されているようにパケットの TTL を減らし (少なくとも 1)、チェックする。 (8) 転送者は、ステップ 3 で完了できなかった IP オプションの処理を全 て実行する。 (9) 転送者は、セクション [4.2.2.7] で規定されているように必要な IP 分割を実行する。このステップは出力インタフェースの選択 (ステッ プ 5) の後で発生するので、同じデータグラムの全てのフラグメント は同じインタフェースに送出されるだろう。 (10) 転送者はパケットの次ホップのリンク層アドレスを決定する。これを 行うメカニズムは、リンク層依存である (チャプタ 3 参照)。 (11) 転送者は、IP データグラム (あるいはその各々のフラグメント) を 適切なリンク層フレームでカプセル化し、ステップ 5 で選択されたイ ンタフェース上に出力するためにキューイングする。 (12) 転送者は、セクション [4.3.3.2] で規定されているように、必要な らば ICMP リダイレクトを送信する。 5.2.1.3 マルチキャスト もし宛先が IP マルチキャストならば、以下のステップを実施する。 IP ユニキャストの転送と IP マルチキャストの転送との主要な相違点は、 o IP マルチキャストは通常、データグラムの送信元と宛先 IP アドレスの 両方に基づいて転送される。 o IP マルチキャストは、拡張リング検索を使用する。 o IP マルチキャストは、リンク層マルチキャストとして転送される。 o ICMP エラーは、IP マルチキャストデータグラムの応答で送信されない。 IP マルチキャストの転送は、まだ若干実験的である。結果として、以下に 提供されているアルゴリズムは必須ではなく、単なる例としてのみ提供さ れることに注意されたい。 (5a) データグラムヘッダにある IP 送信元と宛先アドレスに基づいて、ル ータはデータグラムを転送のための適切なインタフェース上で受信し たか否かを決定する。もし否ならば、そのデータグラムを黙って破棄 する。適切な受信インタフェースを決定する方法は、使用するマルチ キャストアルゴリズムに依存する。最も簡単なアルゴリズムの一つの 逆経路転送 (RPF: reverse path forwarding) では、適切なインタフェ ースはデータグラムの送信元にユニキャストで転送するために使用す る一つである。 (6a) データグラムヘッダにある IP 送信元と宛先アドレスに基づいて、ル ータはデータグラムを出力するインタフェースを決定する。IP マル チキャストの拡張リング検索を実装するために ([INTERNET:4] 参照)、 最小の TTL 値が各々の出力インタフェースとして指定される。マル チキャストデータグラムのコピーは、最小の TTL 値がデータグラム ヘッダ中の TTL 値以下である各々の出力インタフェースに、各々の インタフェース上で残りのステップを別個に適用することによって転 送される。 (7a) ルータはパケットの TTL を一つ減らす。 (8a) 転送者は、ステップ (3) で完了していない全ての IP オプション処 理を実行する。 (9a) 転送者は、セクション [4.2.2.7] で規定されている必要な IP 分割 を実行する。 (10a) 転送者は、リンクレベルのカプセル化で使用するリンク層アドレス を決定する。これを行うためのメカニズムは、リンク層依存である。 LAN 上では、データグラムの IP マルチキャストアドレスのアルゴリ ズム変換として、リンク層マルチキャストかブロードキャストが選択 される。詳細については、様々な xxx 上の IP 規定を参照されたい。 (11a) 転送者は、パケット (あるいはその各々のフラグメント) を適切なリ ンク層フレームにカプセル化し、適切なインタフェース上に出力する ためにキューイングする。 5.2.2 IP ヘッダ評価 ルータは如何なる IP パケットも処理が可能になる前に、ヘッダが意味あ ることを保証するために、パケットの IP ヘッダに対して以下の基本的な 評価チェックを実施しなければならない (MUST)。もしパケットが以下のテ ストに失敗したら、ルータは黙って破棄しなければならず (MUST)、そのエ ラーはログに採取すべきである (SHOULD)。 (1) リンク層によって通知されたパケット長は、正当な最小長の IP デー タグラム (20 バイト) を十分保持する大きさでなければならない。 (2) IP チェックサムは正しくなければならない。 (3) IP バージョン番号は 4 でなければならない。もしバージョン番号が 4 でないならば、そのパケットは IPng や ST-II といった別の IP バ ージョンかもしれない。 (4) IP ヘッダ長フィールドは、正当な最小の IP データグラム (20 バイ ト = 5 ワード) を保持する大きさでなければならない。 (5) IP 全体長フィールドは、その長さが IP ヘッダ長フィールドで指定さ れている IP データグラムヘッダを保持する大きさでなければならな い。 ルータは、これらのテストを不能にする設定オプションを持ってはならな い (MUST NOT)。 もしパケットが二番目と三番目のテストに通過し、その IP ヘッダ長フィ ールドは少なくとも 4 で、IP 全体長とリンク層によって通知されるパケッ ト長が両方とも少なくとも 16 ならば、上記の規則にも関わらず、ルータ はポインタが IP ヘッダ長フィールド (もし四番目のテストに失敗したら) を指すか、IP 全体長フィールド (もし五番目のテストに失敗したら) を指 す、ICMP パラメタ問題メッセージで応答してもよい (MAY)。しかし、ルー タはそのパケットを破棄しなければならず (MUST)、依然としてログに採取 すべきである (SHOULD)。 これらの規則 (とこの全体のドキュメント) は、インターネットプロトコ ルのバージョン 4 にのみ適用される。これらの規則を、ルータが IP の他 のバージョンをサポートすることを禁じていると解釈すべきではない。さ らに、もしルータが IP の他の幾つかのバージョンとして正しくパケット を分類できるならば、このメモのコンテキストの範囲内でそのパケットを 異常として扱うべきではない IMPLEMENTATION 常に完全に可能であるとは限らないが、エラー通知の目的で何故ヘッダ が不正であるかを決定することが望ましい。以下の四つの理由がありえ る。 o リンク層が IP ヘッダを落とした。 o データグラムが標準 (バージョン 4) 以外の IP バージョンを使用し ている。 o IP ヘッダが送信中に壊れた。 o 送信者が不正な IP ヘッダを生成した。 この順番が最もエラーの原因を正しく分類すると思われるので、記述さ れた順序通りに実行することが恐らく望ましいだろう。エラー通知の目 的で、これらのテストに失敗したパケットが IPng か ST-II を示す IP バージョン番号を持っているか否かをチェックすることも望ましいかも しれない。これらは関連する規約に従って取り扱うべきである。 加えて、ルータはリンク層によって通知されるパケット長が、少なくとも パケット IP ヘッダに記録された IP 全体長の大きさであることを検証す べきである (SHOULD)。もしパケットが落とされているようならば、そのパ ケットを破棄しなければならず (MUST)、エラーをログに採取すべきであり (SHOULD)、ポインタが IP 全体長フィールドを指す ICMP パラメタ問題メッ セージで応答すべきである (SHOULD)。 DISCUSSION データが最終宛先に到達した時に、データの改変に関係する何らかの上 位層プロトコルが、パケットデータが落ちていることを検出するので、 ルータが上記で提案されているプロトコルの正当性を維持するための チェックを実行することは、絶対的に必要であるというわけではない。 しかし、このチェックを行うことによって、ルータは経路中のどのホッ プがそのパケットを落としたかを決定する作業を、かなり簡単にするこ とができる。また、下流のシステムはそのパケットを扱う必要が無いの で、そのルータから下流の資源を減らすことにもなる。 最後に、IP ヘッダ中の宛先アドレスがルータのアドレスの一つでないなら ば、ルータはパケットが厳密な送信元と記録経路オプションを含まないこ とを検証すべきである。もしパケットがこのテストに失敗したら (厳密な 送信元経路オプションを含むならば)、ルータはそのエラーをログに採取す べきであり (SHOULD)、ポインタが問題のあるパケットの IP 宛先アドレス を指す、ICMP パラメタ問題エラーで応答すべきである (SHOULD)。 DISCUSSION ある人は、ルータはパラメタ問題メッセージではなく、不正な送信元経 路メッセージで応答すべきであると提案するかもしれない。しかし、不 正な送信元経路は送信元ホストが存在しないものを、あるいはネットワ ークを通って壊れたパスを要求したことを示すのに対して、パケットが このテストに失敗した時は通常、直前のホップのルータによるプロトコ ルエラーを示す。 5.2.3 ローカル配送の決定 ルータが IP パケットを受信した時、ルータはそのパケットがルータ宛て である (そしてローカルに配送すべき) か、別のシステム宛てである (そ して転送者によって扱うべき) かを決定しなければならない。ある IP ブ ロードキャストや IP マルチキャストが、ローカルに配送されるのと転送 されるのと両方ある混成ケースも存在する。ルータは以下の規則を使用し て、これらの三つのケースのどれに当てはまるかを決定しなければならな い (MUST)。 o 終了していない送信元経路オプションは、そのポインタ値が送信元経路 中の最終エントリを過ぎた所を指していない。パケットが終了していな い送信元経路オプションを含むならば、オプション中のポインタは、ポ インタがオプション中の最終アドレスを過ぎた所を指すか、さもなくば 次のアドレスがルータ自身のアドレスの一つでない所まで進められる。 後者 (通常) のケースの場合、パケットは以下の規則に関わらず転送さ れる (ローカルに配送されない)。 o 以下のケースでは、パケットはローカルに配送され、転送するものとは 見なされない。 - パケットの宛先アドレスが、ルータの IPアドレスの一つに正確に一 致する。 - パケットの宛先アドレスが、限定されたブロードキャストアドレス ({-1, -1)} である。 - パケットの宛先が、決して転送されない (例えば 224.0.0.1 や 224.0.0.2) IP マルチキャストアドレスであり、パケットが到着した 物理インタフェースに割り当てられた論理インタフェースの (少なく とも) 一つが宛先マルチキャストグループのメンバである。 o 以下のケースでは、パケットは転送者に渡され、かつローカルに配送さ れる。 - パケットの宛先アドレスが IP ブロードキャストアドレスであり、そ のアドレスはルータの論理インタフェースの少なくとも一つに向けら れているが、パケットが到着した物理インタフェースに割り当てられ た論理インタフェースのどれにも向けられていない。 - パケットの宛先が、転送可能な (224.0.0.1 や 224.0.0.2 ではない) IP マルチキャストアドレスであり、パケットが到着した物理インタ フェースに割り当てられた論理インタフェースの (少なくとも) 一つ が宛先マルチキャストグループのメンバである。 o もしパケットの宛先アドレスが、パケットが到着した物理インタフェー スに割り当てられた論理インタフェースの少なくとも一つに向けられた、 (限定されたブロードキャストアドレス以外の) IP ブロードキャストア ドレスならば、そのパケットはローカルに配送される。パケットが到着 したリンクが、ユニキャストとは違ってブロードキャストをカプセル化 しない (例えば、異なるリンク層宛先アドレスを使うことによって) IP カプセル化を使用しないならば、そのパケットは転送者にも渡される。 o それ以外のケースでは、パケットは転送者に渡される。 DISCUSSION 四番目の段落の最後のセンテンスの要件の目的は、同じ物理ケーブル上 の別のネットワークプレフィクスへの直接ブロードキャストを扱うこと である。通常、これは送信者がリンク層ユニキャストとしてルータにブ ロードキャストを送信したと想定して動作する。ルータはそれがユニキャ ストとして到着したことに示し、従って送信者が送信したのとは異なる ネットワークプレフィクス宛てに向けなければならない。従って、ルー タはそのパケットが到着した所と同じ (物理) インタフェースに、リン ク層ブロードキャストとして安全に送信できる。しかし、もしルータが そのパケットをリンク層ユニキャストとして受信したか否かを通知でき ないならば、そのセンテンスは、安全でないが正しいことよりはむしろ 安全だが誤っていることをルータが行うことを保証している。 IMPLEMENTATION セクション [5.3.4] で規定されているように、リンク層ブロードキャ ストとして受信したパケットは一般的には転送されない。そのセクショ ンの規則のため、後で破棄されるパケットを転送者に渡すことを避ける ことは都合がよいかもしれない。 幾つかのリンク層は、(ハードウェアのためかドライバの特殊コードの ためかのいずれかにより) 全てのリンク層ブロードキャストや送信され たマルチキャストのコピーをルータに配送できる。この機能を使用する と、パケットを転送者に渡してローカルにも配送するケースの実装を簡 素化できる。なぜなら、パケットを転送することにより自動的にルータ がパケットのコピーを受信でき、その後でローカルに配送することがで きる。これらの環境では、受信したループバックパケットを、受信した (そして転送規則に適う等) 通常のパケットとして扱うことを避けるよ う注意しなければならない。 ローカルに配送されたパケットに対して組み立ては実行するが、転送す るパケットには実行しないので、フラグメントには注意しなければなら ないが、たとえそのようなリンク層でなくても、無論、転送とローカル 配送の両方に対してキューイングするために、パケット全体のコピーを 作成する必要はほとんど無い。一つの簡単なスキームは、ルータの出力 キュー上にある各々のパケットに、そのパケットを送信した後にローカ ル配送のためにキューイングすべきか否かを示すフラグを割り当てるこ とである。 5.2.4 次ホップアドレスの決定 ルータがパケットを転送する時、その宛先に直接送信するか、別のルータ を通して渡す必要があるかを決定しなければならない。もし後者ならば、 どのルータを使用するかを決定する必要がある。このセクションは、どの ようにこれらの決定を行うかを説明している。 このセクションは、決定に際して以下を使用する。 o LSRR - IP の厳密でない送信元と記録レコードオプション。 o SSRR - IP の厳密な送信元と記録レコードオプション。 o 送信元経路オプション - LSRR または SSRR。 o 最後の宛先アドレス - どこにパケットが送信されるか。送信元経路付き パケットの送信元経路中の最終アドレスか、送信元経路付きでないパケッ トの IP ヘッダ中の宛先アドレス。 o 隣接 - IP ルータを経由せずに到達可能。 o 次ホップアドレス - パケットを次に送信すべき隣接ホストかルータの IP アドレス。 o IP 宛先アドレス - 送信元経路付きパケットで送信元経路で指定された 次のアドレスを除く、最終の宛先アドレス。 o 隣接した宛先 - ノード、システム、ルータ、終端システム、または IP 宛先アドレスによってアドレス付けされた全てのもの。 5.2.4.1 IP 宛先アドレス もし、 o IP ヘッダ中の宛先アドレスが、ルータのアドレスの一つであり、 o パケットが送信元経路オプションを含み、 o 送信元経路オプション中のポインタが、オプションの最終以降を指して いないならば、 次の IP 宛先アドレスは、そのオプションによって指されたアドレスであ る。もし、 o IP ヘッダ中の宛先アドレスが、ルータのアドレスの一つであり、 o パケットが送信元経路オプションを含み、 o 送信元経路オプションのポインタが、オプションの最終以降を指してい ないならば、 そのメッセージは、そのメッセージを解析するシステム宛てである。 ルータはパケットの扱い方を決定する際、最終の宛先アドレス (送信元経 路オプションの最終アドレス) ではなく、IP 宛先アドレスを使用しなけれ ばならない (MUST)。 データグラムに一つ以上の送信元経路オプションが現われることはエラー である。もしルータがそのようなデータグラムを受信したら、ルータはパ ケットを破棄し、ポインタが二番目目の送信元経路オプションの始めを指 す ICMP パラメタ問題メッセージで応答すべきである (SHOULD)。 5.2.4.2 ローカル/リモート決定 セクション [5.2.3] で規定された規則に従って IP パケットを転送する必 要があると決定した後、隣接した宛先が直接アクセス可能か否かを決定す る ([INTERNET:2]参照) ために、以下のアルゴリズムを使用しなければな らない (MUST)。 (1) IP アドレスが割り当てられていない各々のネットワークインタフェー ス (セクション [2.2.7] に記述されているようなアンナンバードの回 線) に対しては、回線の他方の終端のルータ ID を IP 宛先アドレス と比較する。もしそれが正確に一致しているならば、そのパケットは このインタフェースを通じて転送できる。 DISCUSSION 言い換えると、回線のリモート側の終端のルータかホストは、パケット の宛先か、送信元経路付きのパケットの送信元経路中の次のステップで ある。 (2) ルータに割り当てられた各々の IP アドレスに対して、一番目のステッ プでネットワークインタフェースが選択されなかったならば、 (a) インタフェースによって使用されるネットワークプレフィクスを抜き 出す。 IMPLEMENTATION この処理の結果は、大抵初期化の間に既に算出され保持されているだろ う。 (b) パケットの IP 宛先アドレスから対応する一連のビットを抜き出す。 (c) 結果とした割り出したネットワークプレフィクスを比較する。もしそ れらがお互いに等しいならば、対応するネットワークインタフェース を通じてそのパケットを送信できる。 (3) もし宛先がアンナンバードインタフェース上の隣接者のルータ ID で も、直接接続されたネットワークプレフィクスのメンバでもないなら ば、IP 宛先は他の幾つかのルータを通じてしかアクセスできない。ル ータと次ホップの IPアドレスの選択については、セクション [5.2.4. 3] で規定されている。ルータでないホストの場合、これは設定された デフォルトルータであるかもしれない。 IETF [ARCH:9, NRHP] での継続中の作業では、例えば複数の IP (サブ) ネッ トワークが同じリンク層ネットワーク上に存在する時といった、幾つかの ケースを考慮している。ポリシーによる制限が無ければ、共通のリンク層 ネットワークを使用しているホストやルータは、もし適切な情報が提供さ れているならば、たとえ同じ IP (サブ) ネットワークに存在しなくとも直 接通信することができる。次ホップルーティングプロトコル (NHRP: Next Hop Routing Protocol) は、IP エンティティが、リモートの宛先に向けて リンク層ネットワークを横切るために使用する「最適な」リンク層アドレ スを決定することを可能にする。 (4) もし選択された「次ホップ」が、NHRP を使用するよう設定されたイン タフェースを通じて到達可能ならば、以下の追加ステップが適用され る。 (a) IP 宛先アドレスを NHRP キャッシュ中の宛先アドレスと比較する。 もしアドレスがキャッシュ中のアドレスならば、そのデータグラム を対応するキャッシュされたリンク層アドレスに送信する。 (b) もしアドレスがキャッシュ中のアドレスでないならば、IP 宛先アド レスを含む NHRP 要求パケットを作成する。このメッセージは、そ のインタフェースに設定された NHRP サーバに送信される。これは 論理的にルータ自身の別のプロセス、又はエンティティであっても よい。 (c) NHRP サーバは、そのデータグラムと、後に続く同じ宛先へのデータ グラムを送信するために使用する適切なリンク層アドレスをもって 応答するだろう。システムは、NHRP 応答を待つ間、伝統的な「次ホッ プ」ルータにそのデータグラムを送信してもよい (MAY)。 5.2.4.3 次ホップアドレス EDITORS+COMMENTS ルータは、IP 宛先アドレスが隣接しているか否かを決定するために、 前のセクションのアルゴリズムを適用する。もし隣接しているならば、 次ホップアドレスは IP 宛先アドレスと同じである。隣接していなけれ ば、そのパケットを別のルータに転送して、それの隣接した宛先に到達 させなければらない。このルータの選択が、このセクションの主題であ る。 もしパケットが SSRR を含むならば、ルータはそのパケットを破棄し、 ICMP 不正送信元経路エラーで応答しなければならない (MUST)。さもな くば、ルータは適切な次ホップアドレスを決定するために、自分のルー ティングテーブル中に IP 宛先アドレスを検索する。 DISCUSSION IP 規定により、厳密な送信元経路はパケットが横切らなければならな い一続きのノードを指定しなければならならない。つまり、そのパケッ トは送信元経路の一つのノードから次へ、間にネットワークのみを媒介 して横切らなければならない。従って、もしルータが送信元経路の次の ステップに隣接していなければ、送信元経路を満たすことができない。 よって、ルータはそのようなパケットを ICMP 不正送信元経路エラーで 拒否する。 次ホップ選択処理の目標は、ルータの転送情報ベース (FIB: Forwarding Information Base) 中にエントリを検査し、FIB 中の利用可能な経路から そのパケットにとっての最善経路を (もし存在するならば) 選択すること である。 概念的に、経路検索アルゴリズムは、FIB 全体の内容を構成する一組の候 補の経路から開始する。アルゴリズムは、その組みから経路を破棄する一 連のステップで構成される。これらのステップは枝刈り規則 (Pruning Rules) と呼ばれる。通常、アルゴリズムが完了する時、ちょうど一つの経 路がその組みの中で残る。もしその組みが空になったら、そのパケットは 宛先が未到達なので破棄される。また、その組みで一つ以上の経路が残っ ている時にアルゴリズムが完了することも有り得る。この場合、ルータは それらのうち一つ以外の全てを任意に破棄してよいし、最も最近使用され ていない経路を選択することによって「負荷分散」を実行してもよい。 規則 3 (弱い TOS) の例外で、ルータはパケットの次ホップを選択する際、 次の枝刈り規則を使用しなければならない (MUST)。ルータが次ホップを決 定する際 TOSを考慮するならば、以下に示された順番で規則 3 を適用しな ければならない。これらの規則は (概念的に)、出現した順番で FIB に適 用しなければならない (MUST)。(歴史的な見地や、追加の枝刈り規則や他 の一般アルゴリズムの使用については、付録 E を参照されたい)。 DISCUSSION セクション [5.3.2] は転送を決める時ルータのみが TOS を考慮すべき (SHOULD) であると述べているので、規則 3 は任意である。 (1) 基本照合 この規則は、パケットの IP 宛先アドレス以外の宛先への経路を 全て破棄する。例えば、もしパケットの IP 宛先アドレスが 10.144.2.5 ならば、このステップはネットワークプレフィクス 10.0.0.0/8 や 10.144.0.0/16 への経路やデフォルト経路は残す が、ネット 128.12.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) 最長照合 最長照合は、上述されている基本照合の改善である。基本照合に よる枝刈りを実施した後、アルゴリズムは残った経路を検査して、 どれが最長の 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) 弱い TOS 各々の経路は route.tos と呼ばれるサービス属性のタイプを持ち、 その有り得る値は IPヘッダの TOS フィールドで使用される値と 同じであると仮定する。TOS 情報を配送するルーティングプロト コルは、route.tos を FIB に追加する経路に適切に記入する。他 のルーティングプロトコルによる経路は、デフォルト TOS (0000) を持つものとして扱う。振り分けようとしているパケットの IP ヘッダ中の TOS フィールドは ip.tos と呼ばれる。 経路の候補の組みは、route.tos = ip.tos である経路を含むか否 かを決定するために検査される。もし含むならば、 route.tos = ip.tos を除く全ての経路が破棄される。もし含まな いならば、route.tos = 0000 を除く全ての経路が候補の組みから 破棄される。 弱い TOS に基づくルーティングの追加の議論は、[ROUTE:11] に ある。 DISCUSSION この規則の効果は、パケットで要求された TOS に一致する TOS を持つ 経路のみを選択することである。そのような経路が存在しない場合は、 デフォルトの TOS を持つ経路が考慮される。パケットで要求されてな くデフォルトでない TOS を持つ経路は、たとえパケットの宛先へ行く のにその経路しか利用可能な経路がなくとも決して使用されない。 (4) 最善メトリック 各々のメトリックは、route.metric と呼ばれるメトリック属性と、 route.domain と呼ばれるルーティングドメイン識別子を持つ。候 補経路の組みの各々のメンバは、その組みの他の各々のメンバと比 較される。もし route.domain が二つの経路で等しく、route.metric が一方と比較して厳密に劣っているならば、劣ったメトリックを持っ た方の経路は、その組みから破棄される。幾つかのプロトコルはよ り複雑な比較を必要とする構造化されたメトリックを持つかもしれ ないが、劣っているかを決める方法は通常単純な算術比較である。 (5) ベンダポリシー ベンダポリシーは、前に一覧化されている規則ではありえる経路か ら選択するのに不適切であることが多いという事実を補うための、 ある種のキャッチオールである。ベンダポリシーの枝刈り規則は、 極めてベンダ固有である。セクション [5.2.4.4] を参照されたい。 このアルゴリズムには、以下の二つの異なる欠点がある。恐らくルータ 実装者は、これらの欠点を扱うための技術を開発し、ベンダポリシーの 枝刈り規則の一部にするかもしれない。 (1) IS-IS と OSPF 経路クラスは、全く扱われない。 (2) サービスタイプ以外のパスプロパティ (例えば MTU) が無視される。 TOS がサポートされる方法の欠陥に気づく価値もある。0 でない TOS 値 を持つパケットを転送する時に、TOS をサポートするルーティングプロ トコルが暗黙的に選ばれる。 基本照合と最長照合の枝刈り規則は、経路の数多くの特定のタイプの扱 いを一般化する。これらの経路は以下の減少、優先順位で選択される。 (1) ホスト経路 : これは特定の終端システムへの経路である。 (2) 階層的なネットワークプレフィクス経路: これは特定のネットワー クプレフィクスへの経路である。FIB がお互い (あるプレフィクス は付加ビットを持った他のプレフィクスである) を包含するネット ワークプレフィクスへの複数の経路を含むかもしれないことに注意 されたい。これらは、プレフィクス長の短い順序で選択される。 (5) デフォルト経路 : これは明示的な経路が無い場合の全てのネットワ ークへの経路である。それは、定義上プレフィクス長が 0 の経路で ある。 もし枝刈り規則の適用後に経路の組みが空 (すなわち経路が見つからな い) ならば、そのパケットを破棄して、適切な ICMP エラーを生成しな ければならない (MUST)。(もし IP 宛先アドレスが送信元経路オプショ ンのものならば ICMP 不正送信元経路、さもなくばセクション [4.3.3.1] で規定されているように、ICMP 宛先ホスト到達不可か宛先ネットワーク 到達不可のどちらも適切である) 。 5.2.4.4 管理上の優先度 ベンダポリシーの枝刈り規則として提案されているメカニズムは、管理 上の優先度を使用することである。それは、単純な優先順位付けアルゴ リズムである。この考えは、複数の中から一つを選択する必要がある経 路の優先度を手動で付けることである。 各々の経路は、経路の様々な属性に基づいて優先値を割り当てる (優先 値の割当ての特定のメカニズムは以下に提案されている)。この優先値は、 [0...255] の範囲の整数値で、 0 が最も優先度が高く、254 が最も優先 度が低い。255 は特別な値であり、その経路は決して使用すべきでない ことを意味する。ベンダポリシーの枝刈り規則の第一ステップは、最も 優先度の高い経路を除く、全ての経路を破棄することである (優先度の 値が 255 である経路は常に破棄する)。 このポリシーはたやすく誤って用いられ、ルーティングループを引き起 こしえる点で安全ではない。ルータに設定される優先度が、その隣接者 に設定される優先度と矛盾が無いことを保証するプロトコルは存在しな いので、ネットワーク管理者が優先度を設定する際は注意しなければな らない。 o アドレス照合 宛先の特定の組みへの (同一のルーティングドメインから教わった) 経路全てに、一つの優先度値を割り当てられることは便利である。そ の場合、宛先の組みは特定のネットワークプレフィクスと一致する全 ての宛先である。 o 経路クラス 区別を維持するルーティングプロトコルにとって、特定の経路クラス (イントラ域、インター域、内部メトリクスを持った外部、外部メト リクスを持った外部) を持つ (同一のルーティングドメインから教わっ た) 経路全てに、一つの優先度値を割り当てられることは便利である。 o インタフェース パケットがルータの特定の論理インタフェース (複数の IP アドレス が、それに割り当てられた複数の論理インタフェースを持つことを除 いて、論理インタフェースは通常、ルータのネットワークインタフェ ースに 1 対 1 でマッピングされる) に振り分けられる (同一のルー ティングドメインから教わった) 経路全てに、一つの優先度値を割り 当てられることは便利である。 o 送信元ルータ ルータの幾つかの組みから教わった (同一のルーティングドメインか ら教わった) 経路全てに、一つの優先度値を割り当てられることは便 利である。その場合、ルータの組みは、その更新が特定のネットワー クプレフィクスと一致する送信元アドレスを持つものである。 o 起動側 AS 情報を提供するルーティングプロトコルにとって、別の特定のルーティ ングドメインで起動した (同一のルーティングドメインから教わった) 経路全てに、一つの優先度値を割り当てられることは便利である。 BGP 経路の場合、起動側 AS は経路の AS_PATH 属性で一覧化された うちの一番目の AS である。OSPF 外部経路の場合、もしタグの自動 ビットが設定され、タグのパス長が 3 でないならば、起動側 AS は 経路の外部経路タグの下位 16 ビットと見なしてもよい。 o 外部経路タグ 外部経路タグが特定の値のリストに一致する (同一のルーティングド メインから教わった) OSPF 外部経路全てに、一つの優先度値を割り 当てられることは便利である。外部経路タグは構造化された値を持っ てもよいので、タグの特定のサブフィールドと照合する機能を提供す ることは便利かもしれない。 o AS パス AS パスが特定の値の組みに "一致する" (同一のルーティングドメイ ンから教わった) BGP 経路全てに、一つの優先度値を割り当てられる ことは便利である。どのような種類の照合が最も効果的であるかは、 まだはっきりと明確になっていない。単純なオプションは、経路の AS_PATH 属性のどこかに出現する (あるいは出現しない) 全ての経路 の照合を可能にすることである。より一般的だがより難しい代替手段 は、AS パスが特定の正規表現に一致する全ての経路の照合を可能に することである。 5.2.4.5 負荷分散 次ホップ選択処理の最後で、複数の経路がまだ残るかもしれない。この 場合、ルータは幾つかの選択肢がある。ルータは経路の幾つかを任意に 破棄してもよい。ルータは、同等とみなされないルーティングドメイン からの経路のメトリクスを比較することによって、代表経路の数を減ら してもよい。ルータは一つ以上の経路を保持し、それらの中でトラフィッ クを配分する負荷分散メカニズムにかけてもよい。おそらく、この選択 肢の相対的な利点について言えるのは、負荷分散がある状況では効果的 であり、また別の状況では効果的でないということだけである。従って、 負荷分散を実装する賢い実装者は、ネットワーク管理者がそれを無効に する方法も提供するだろう。 5.2.5 未使用 IP ヘッダビット: RFC-791 セクション 3.1 IP ヘッダは、サービスタイプフィールドとフラグフィールドの中に幾つ かの予約ビットを含む。ルータは、単にこれらのビットの一つ以上が 0 でないという理由だけで、パケットを落としてはならない (MUST NOT)。 ルータはこれらの予約ビットの値を無視しなければならず (MUST)、値を 変更せずに渡さなければならない (MUST)。もしルータがパケットを分割 するならば、これらのビットを各々のフラグにコピーしなければならな い (MUST)。 DISCUSSION IP プロトコルの将来の改訂は、これらのビットを使用するかもしれな い。これらの規則は、インターネット中の全てのルータを同時にアップ グレードすることなく、これらの改訂が展開できることを保証すること を意図している。 5.2.6 分割と組み立て: RFC-791 セクション 3.2 セクション [4.2.2.7]で論じられているように、ルータは IP 分割をサポ ートしなければならない (MUST)。 ルータは、転送する前に如何なるデータグラムも組み立ててはならない (MUST NOT)。 DISCUSSION 何人かの人々は、ルータによるデータグラム通過時の再組み立てが、パ フォーマンスを改善するようなトポロジーがあるかもしれないことを提 案した。フラグメントが宛先へ異なるパスを通るかもしれないという事 実は、そのような機能の安全な使用を妨げる。 このセクションは、ルータによってリンク層の機能として実行される分 割、組み立てを制御、あるいは制限すると解釈すべきでない。 同様にもし IP データグラムが別の IP データグラムにカプセル化され (例えばトンネル化)、そのデータグラムが代わりに分割されるならば、 そのフラグメントは元のデータグラムを転送するために組み立てなけれ ばならない。このセクションは、これを除外していない。 5.2.7 インターネット制御メッセージプロトコル - ICMP 一般的な要件は、セクション [4.3] で論じられている。このセクションは、 ルータによって送信される ICMP メッセージについてのみ論じる。 5.2.7.1 宛先未到達 ICMP 宛先未到達メッセージは、宛先 (あるいは次ホップ) が到達不可か、 サービスが利用不可であるために転送できないパケットに対する応答とし て、ルータによって送信される。このようなケースの例では、そこにおら ず、それ故に ARP 要求に応答しないホスト宛てのメッセージや、ルータが 正しい経路を持っていないネットワークプレフィクス宛てのメッセージを 含む。 ルータは、ICMP 宛先未到達メッセージを生成できなければならず (MUST)、 そのメッセージを生成した理由に最も近い応答コードを選択すべきである (SHOULD)。 以下のコードは、[INTERNET:8] と [INTRO:2] で定義されている。 0 = ネットワーク未到達 - 宛先ネットワークへの転送パス (経路) が利用 できない場合に、ルータによって生成される。 1 = ホスト未到達 - 直接接続されたネットワーク上で宛先ホストへの転送 パス (経路) が利用できない (ARP に応答しない) 場合に、ルータに よって生成される。 2 = プロトコル未到達 - データグラムで指定されたトランスポートプロト コルが、最終宛先のトランスポート層でサポートされていない場合に 生成される。 3 = ポート未到達 - 指定されたトランスポートプロトコル (例えば UDP) が、最終宛先のトランスポート層でデータグラムを逆多重化できない が、それを送信側に通知するメカニズムをプロトコルが持たない場合 に生成される。 4 = 分割が必要で DF が設定 - ルータがデータグラムを分割する必要があ るが、DF フラグが設定されているために分割できない場合に生成する。 5 = 送信元経路失敗 - ルータが送信元経路オプションの次ホップにパケッ トを転送できない場合に生成される。 6 = 未知の宛先ネットワーク - これは、ルータとしては宛先ネットワーク が存在しないことを暗黙的に意味するので、このコードは生成すべき でない (SHOULD NOT)。(コード 6 の代わりにネットワーク未到達コー ドの 0 を使用すべきである (SHOULD))。 7 = 未知の宛先ホスト - ルータが、宛先ホストが存在しないことを (リン ク層の通知より) 決定できない場合にのみ生成する。 11 = サービスタイプに対するネットワーク未到達 - 要求された、あるい はデフォルトの TOS を持つ宛先ネットワークへの転送パス (経路) が利用できない場合に、ルータによって生成される。 12 = サービスタイプに対するホスト未到達 - 宛先への経路がデータグラ ムで要求された TOS か、デフォルト TOS (0) のいずれかに一致しな いためにパケットを転送できない場合に、ルータによって生成される。 以下の追加コードがここに定義される。 13 = 管理上禁止された通信 - ルータがパケットを管理上のフィルタによ り転送できない場合に生成される。 14 = ホスト優先度違反。要求された優先度が送信元/宛先ホスト、ネット ワーク、上位層プロトコル、送信元/宛先ポートの特定の組み合わせ に対して許可されていないことを示すために、そのホストへの第一ホッ プのルータによって送信される。 15 = 優先度による遮断結果。ネットワーク運用者が、運用において必要な 優先度の最小レベルを課し、データグラムがこのレベルを下回って送 信された。 注記: [INTRO:2] は、分離された送信元ホストとしてコード 8 を定義して いる。ルータはコード 8 を生成すべきでなく (SHOULD NOT)、コード 0 (ネットワーク未到達)とコード 1 (ホスト未到達) のどちらか適切なコー ドを代わりに使用すべきである (SHOULD)。[INTRO:2] は、管理上禁止され た宛先ネットワークとの通信に対してコード 9 と、管理上禁止された宛先 ホストとの通信に対してコード 10 も定義している。これらのコードは、 米国軍事機関で使用されるエンドツーエンドの暗号デバイスで使用するこ とを意図している。もしパケットを管理上フィルタにかけるならば、ルー タは新たに定義されたコード 13 (管理上禁止された通信) を使用すべきで ある (SHOULD)。 ルータは、コード 13 (管理上禁止された通信) のメッセージを生成しない 通信オプションを持ってもよい (MAY)。このオプションが可の場合、転送 が管理上禁止されているという理由で落とされたパケットの応答として、 ICMP エラーメッセージは送信されない。 同様にルータは、コード 14 (ホスト優先度違反) とコード 15 (優先度に よる遮断結果) のメッセージを生成しない通信オプションを持ってもよい (MAY)。このオプションが可の場合、優先度違反の理由で落とされたパケッ トの応答として、ICMP エラーメッセージは送信されない。 ルータは、同じ宛先ネットワーク上の他のホストが到達可能であるかもし れない時は、ホスト未到達か未知の宛先ホストを必ず使用しなければなら ない (MUST)。さもなくば、送信元ホストはそのネットワーク上の全てのホ ストが未到達であると誤って結論づけ、そのケースではないかもしれない 場合がある。 [INTERNET:14] は、コード 4 (分割が必要で DF が設定) を含む宛先未到 達メッセージの形式のわずかな修正を規定している。ルータはコード 4 の 宛先未到達メッセージを生成する時、この修正された形式を使用しなけれ ばならない (MUST)。 5.2.7.2 リダイレクト ICMP リダイレクトメッセージは、トラフィックのあるクラスに対し異なる 次ホップのルータを使用すべきであることを、ローカルホストに通知する ために生成される。 ルータは、[INTERNET:8] で規定されているネットワークのためのリダイレ クトか、ネットワークとサービスタイプのためのリダイレクトメッセージ (コード 0 と 2) を生成してはならない (MUST NOT)。ルータは、 [INTERNET:8] で規定されたホストのためのリダイレクトメッセージ (コー ド 1) を生成できなければならず (MUST)、サービスタイプとホストのため のリダイレクトメッセージ (コード 3) を生成できるべきである (SHOULD)。 DISCUSSION もし直接接続されたネットワークが (古典的な意味で) サブネットでな いならば、ルータは通常、特定のリモートネットワーク上の全てのホス トに適用するネットワークリダイレクトを生成できる。ホストリダイレ クトの代わりにネットワークリダイレクトを使用することは、ネットワ ークトラフッィクやホストのルーティングテーブル領域にとって、わず かに経済的かもしれない。しかし、その節約は重要なものではなく、サ ブネットは、ネットワークリダイレクトを解釈するために使用されるサ ブネットマスクに関する曖昧性を生む。CIDR 環境では、ネットワーク リダイレクトが使用されるケースを正確に特定することが難しい。従っ て、ルータはホスト (またはホストとサービスタイプ) リダイレクトの みを送信しなければならない。 コード 3 (ホストとサービスタイプのためのリダイレクト) メッセージは、 リダイレクトの要因となったパケットが、ルータによって選択されたパス が要求された TOS に (部分的に) 依存する宛先を持つ場合に生成される。 コード 3 リダイレクト (ホストとサービスタイプ) を生成できるルータは、 コード 3 リダイレクトの代替としてコード 1 (ホスト) リダイレクトを利 用可能にするために、設定オプション (デフォルトがオン) を持たなけれ ばならない (MUST)。もしそのオプションがそのように設定されているなら ば、ルータはコード 3 リダイレクトの代わりにコード 1 リダイレクトを 送信しなければならない (MUST)。 もしルータがコード 3 リダイレクトを生成できないならば、コード 3 リ ダイレクトを要する時に、その代替としてコード 1 を生成しなければなら ない (MUST)。 ルータは以下の条件が適わないならば、リダイレクトメッセージを生成し てはならない (MUST NOT)。 o そのパケットは、受信したのと同じ物理インタフェースに転送される。 o そのパケット中の IP 送信元アドレスは、次ホップの IP アドレスと同 じ論理 IP (サブ) ネットワーク上にある。 o そのパケットは、IP 送信元経路オプションを持たない。 ICMP リダイレクトで使用される送信元アドレスは、宛先アドレスと同じ論 理 (サブ) ネットワークに属さなければならない (MUST)。 (静的ルーティング以外の) ルーティングプロトコルを使用するルータは、 パケットを転送する際に、ICMP リダイレクトから知ったパスを考慮しては ならない (MUST NOT)。もしルータがルーティングプロトコルを使用してい ないならば、ルータは、もし設定されたら、パケットを転送する時に、 ICMP リダイレクトを通じて知った経路を考慮することを可能にするような 設定を持ってもよい (MAY)。 DISCUSSION ICMP リダイレクトは、ルータがルーティング情報をホストに伝達する ためのメカニズムである。ルータはルーティング情報を知るために他の メカニズムを使用すので、リダイレクトに従う理由はない。ルータの他 の情報に反するリダイレクトを信じることにより、ルーティングループ を引き起こすかもしれない。 一方、ルータがルータとして振る舞わないならば、ホストに要求された 動作に従わなければならない(MUST)。 5.2.7.3 時間超過 ルータは、TTL フィールドの満了によりパケットを破棄する時、時間超過 メッセージコード 0 (通過中) を生成しなければならない (MUST)。ルータ は、インタフェース上でこれらのメッセージの生成を不可にするためのオ プションをインタフェース毎に持ってもよい (MAY)。しかし、そのオプショ ンはデフォルトで、そのメッセージの生成を可能にしなければならない (MUST)。 5.2.8 インターネットグループ管理プロトコル - IGMP IGMP [INTERNET:4] は、単一の物理ネットワーク上で、特定のマルチキャ ストグループ内のホストのメンバシップを確立するための、ホストとマル チキャストルータ間で使用されるプロトコルである。マルチキャストルー タは、インターネットを渡る IP マルチキャスト転送をサポートするため に、マルチキャストルーティングプロトコルと共にこの情報を使用する。 ルータは、IGMP のマルチキャストルータ部を実装すべきである (SHOULD)。 5.3 特定の問題 5.3.1 生存時間 (TTL) IP ヘッダの生存時間 (TTL) フィールドは、データグラムの生存時間を限 定するタイマとして定義されている。それは 8 ビットフィールドで単位は 秒である。パケットを処理する各々のルータ (あるいは他のモジュール) は、たとえ経過した時間が 1 秒よりもずっと小さくても、TTL を少なくと も 1 減らさなければならない (MUST)。大抵はこのケースなので、TTL は、 インターネットを通じてデータグラムを伝達させることができる有効なホッ プ数の制限である。 ルータがパケットを転送する時、TTL を少なくとも 1 減らさなければなら ない (MUST)。もしルータが 1 秒以上パケットを保持するならば、各秒に つき 1 ずつ TTL を減らしてもよい (MAY)。 もし TTL が 0 (以下)に減らされるならば、そのパケットを破棄しなけれ ばならず (MUST)、もし宛先がマルチキャストアドレスでないならば、ルー タは ICMP 時間超過メッセージ、コード 0 (通過中に TTL 超過) メッセー ジを送信元に送信しなければならない (MUST)。ルータは、0 でない TTL を持つ IP ユニキャストかブロードキャストパケットを、単に、そのパケッ トの最終宛先へのパス上の別のルータが TTL を 0 に減らすことを予測で きるという理由で破棄してはならない (MUST NOT)。しかしルータは、IP マルチキャストの拡張リング検索アルゴリズム ([INTERNET:4] 参照) をよ り効率的に実装するために、IP マルチキャストに対してはそうしてもよい (MAY)。 DISCUSSION IP TTL は、ホップ数制限と時間制限の両方として幾らか支離滅裂に使 用される。そのホップ数機能は、ルーティングの問題によりネットワー ク内でパケットの無限ループを引き起こすことによるネットワークの崩 壊が起きないことを保証するために重要である。時間制限機能は、例え ば TCP のようなトランスポートプロトコルによって、信頼できるデー タ転送を保証するために使用される。多くの現在の実装は、TTL を純粋 なホップ数として扱う。時間制限機能は、それを必要とするトランスポ ートプロトコルが代わりに実行すべきであるという強い意見が、インタ ーネット社会の一部にはある。 この規約では、時間制限機能はオプションであるべきというルータベン ダ間の強い信念に従うことに不本意ながら決定した。彼らは、時間制限 機能の実装は現在一般に行われておらず、かなり難しいものであること を主張した。彼らは更に、この近道によって TCP のデータ破壊が引き 起こされるケースは証拠資料が無いことを指摘した (もちろんこの問題 が発生することは希で、再現することは困難であると予想される。 従っ て、証拠資料が無いというのは、記録に残されていないケースはほとん ど起こらないことを示しているわけではない)。 拡張リング検索のような IP マルチキャストの考えは、TTL を純粋なホッ プ数として扱わなければ、期待通りに動作しないかもしれない。 traceroute についても同じ事が言える。 ICMP 時間超過メッセージは、traceroute 診断ツールがこれに依存して いるので必要である。 従って、もし除かなければ二つの非常に便利なツールにとって害になる ことと、全く発生しないかもしれない非常に希で一時的なデータ転送の 問題を回避することとのトレードオフである。我々は、ツールを残すこ とを選択した。 5.3.2 サービスタイプ (TOS) IP ヘッダ中のサービスタイプのバイトは、三つのセクションに分割さ れる。それは、優先度フィールド (上位 3 ビット)、慣例的にサービス タイプ、または "TOS" と呼ばれるフィールド (次の 4 ビット)、予約 ビット (下位ビット) である。予約ビットを管理する規則は、セクショ ン [4.2.2.3] で規定されている。優先度フィールドは、セクション [5.3.3] で論じられる。TOS フィールドとその使用についてのより広範 な議論は、[ROUTE:11] で見ることができる。 ルータは転送方法を決定する時、パケットの IP ヘッダ中の TOS フィ ールドを考慮すべきである (SHOULD)。このセクションの残りは、この 要件に従うルータに適用される規則を規定する。 ルータは、ルーティングテーブルの各々の経路に対して、TOS 値を保持 しなければならない (MUST)。TOS をサポートしていないルーティング プロトコルを通じて知った経路は、0 の TOS (デフォルト TOS) を割り 当てなければならない (MUST)。 宛先への経路を選択するために、ルータは以下と同等のアルゴリズムを 使用しなければならない (MUST)。 (1) ルータは、宛先への利用可能な経路 (セクション[5.2.4] 参照) を 全てルーティングテーブルに置かなければならない (MUST)。 (2) もし経路が無いならば、ルータは宛先未到達という理由でそのパケッ トを落とす。セクション[5.2.4] 参照。 (3) もしそれらの経路の一つ以上がパケットに指定された TOS と正確 に一致する TOS を持っているならば、ルータは最善のメトリック を持つ経路を選択する。 (4) さもなくば、TOS が 0 の経路を見つけることを除いて、ルータは 上記のステップを繰り返す。 (5) もし上記で何の経路も選択されないならば、ルータは宛先未到達の 理由でそのパケットを落とす。ルータは、サービスタイプを持つネッ トワーク未到達 (コード 11) か、サービスタイプを持つホスト未 到達 (コード 12) のどちらかの適切なコードを指定した ICMP 宛 先未到達エラーを返却する。 DISCUSSION TOS は過去ほとんど使用されていないが、ホストによるその使用はイン ターネットホスト要件の RFC ([INTRO:2] と [INTRO:3]) では義務であ る。ルータでの TOS のサポートは、将来 MUST になるかもしれない。 しかし、我々がより多くの経験を積み、利益と代価の両方をより良く判 断できるまで、SHOULD とする。 様々な人が、TOS は転送機能の他の面に作用すべきであると提案してい る。例えば、 (1) ルータは、低遅延ビットが設定されたパケットを、出力キュー中の 他のパケットより前に置くことができる (2) ルータが強制的にパケットを破棄する際、高信頼性ビットが設定さ れたパケットの破棄を避けようとすることができる。 これらのアイデアは [INTERNET:17]でより詳細に調査されているが、こ の分野に要件を設けるにはそのようなスキームについてまだ十分な経験 が無い。 5.3.3 IP 優先度 このセクションは、ルータにおける IP 優先度フィールドの適切な処理 についての要件とポリシーを規定する。優先度は、異なるトラフィック フローの相対的な重要性に基づいた、ネットワークでの資源の割当ての ためのスキームである。IP 規約は、トラフィックの様々なタイプに対 して、このフィールドで使用する特定の値を定義している。 ルータにおける優先度処理の基本的なメカニズムは優先的な資源割当て であり、優先順序化されたキューサービスと優先度に基づく輻輳制御の 両方と、リンク層の優先権機能の選択を含む。ルータは、ルーティング やルータが元となるトラフィックの管理と制御のための IP 優先度も選 択する。IP 優先度のより拡張された議論とその実装については [ FORWARD:6] を参照されたい。 優先度順序キューサービスは、このセクションで論じられているように、 転送処理のためのキューと出力リンクのためのキューを含むが、それに 限定してはいない。これは、優先度をサポートしているルータは、例え ばパケットバッファやリンク層コネクションといった固定の資源を割り 当てる点においても、優先度指示を使用すべきであることを意図してい る。一連のそうした点は、実装に依存する。 DISCUSSION 優先度フィールドは元々、大きなトラフィックの急増やネットワークへ の主要な障害が本来の脅威であると見なされる DOD システムで使用す るために提供されたが、それは、多くの非軍事 IP ネットワークでも効 果的に適用できる。ネットワークのトラフィック制御能力は、近年非常 に大規模になったけれども、ユーザのトラフィック生成能力もまた大き くなり、ネットワーク負荷状態は依然として時々発生する。IP ベース のルーティングや管理プロトコルは、インターネットの継続的な運用に とってますます不可欠になりつつあるので、負荷は以下の二つの付加的 な危険をネットワークにもたらす。 (1) 高遅延は、ルーティングプロトコルパケットの損失を結果として引 き起こすかもしれない。高遅延により、ルーティングプロトコルは トポロジの変更を誤って推論し、この誤った情報を他のルータに伝 播するかもしれない。これは経路の変動だけでなく、余分な処理の 負担を他のルータにもたらすかもしれない。 (2) 高遅延により、負荷状態が発生したネットワーク中の問題を解析し、 恐らく修正あるいは緩和するためのネットワーク管理ツールの使用 に差し支えるかもしれない。 優先度メカニズムの実装と適切な使用は、これらの問題の両方を軽減す る。 5.3.3.1 優先度順序キューサービス ルータは優先度順序キューサービスを実装すべきである (SHOULD)。優先度 順序キューサービスは、パケットが (論理) リンク上の出力のために選択 されるとき、キューイングされた優先度の最も高いパケットが、そのリン クに対して送信される。優先度順序キューサービスを実装しているルータ は、インターネット層で優先度順序キューサービスを抑制するための設定 オプションも持たなければならない (MUST)。 如何なるルータも、厳密な順序付け以外の結果をもたらす他のポリシーに 基づくスループット管理手続きを実装してもよい (MAY) が、それを抑制す る (すなわち厳密な順序付けを使用する) よう設定できなければならない (MUST)。 セクション [5.3.6] に詳述されているように、優先度順序キューサービス を実装しているルータは、輻輳制御目的で、高優先度のパケットを破棄す る前に低優先度のパケットを破棄する。 先取り (処理の割り込みやパケットの転送) は、インターネット層の機能 として想定されていない。他の層における幾つかのプロトコルは、先取り 機能を提供してもよい。 5.3.3.2 下位層優先度マッピング 優先度順序キューイングをサポートするルータは、下位層優先度マッピン グを実装しなければならず (MUST IMPLEMENT)、サポートしないルータは下 位層優先度マッピングを実装すべきである (SHOULD IMPLEMENT)。 下位層優先度マッピングを実装するルータは、 o 定義されたそのような機能を持つリンク層のためのリンク層優先度メカ ニズムに、IP 優先度をマッピングできなければならない (MUST)。 o 全ての IP トラフィックに対し、リンク層のデフォルト優先度の取り扱 いを選択するための設定オプションを持たなければならない (MUST)。 o 各々のインタフェースに対し、IP 優先度値の特殊な非標準のリンク層優 先度値へのマッピングを設定できるべきである (SHOULD)。 DISCUSSION 幾つかの調査により、幾つかのリンク層プロトコルの優先度機能の動作 は疑わしく、幾つかのネットワークにはリンク層優先度メカニズムの実 装に欠陥があるかもしれない。そのような問題がネットワークに見られ る場合、回避メカニズムを提供することは賢明であるようだ。 一方、マルチメディア帯域の予約や低遅延サービスといった特別なサー ビスを実装するために、斬新なキューイング戦略を使用する提案がある。 それらをサポートする特殊なサービスやキューイング戦略は現在の研究 テーマであり、標準化の作業中である。 実装者は、IP 優先度の正しいリンク層マッピングが、DOD ネットワー クで使用される TCP/IP システムのための DOD ポリシーによって要求 されることを考慮したいかもしれない。その要件は、より良いインター ネットサービスを全てのユーザに提供することを期待して、優先度機能 の使用を推奨 (強制ではない) する意図があるので、優先度順序キュー サービスをサポートするルータは、要求されたサービスタイプに関わら ず、デフォルトで厳密な優先度順序を維持すべきである。 5.3.3.3 全てのルータのための優先度処理 ルータは (優先度順序キューサービスを用いるか否かに関わらず): (1) 管理上でそうしない設定がなされていないならば、全ての優先度レベ ルのトラフィックを正常に受諾し、処理しなければならない (MUST)。 (2) 特定のトラフィック源による優先度レベルの使用を管理上制限する評 価フィルタを実装してもよい (MAY)。もし提供するならば、このフィ ルタは次の ICMP エラーメッセージの類を除外したり、落としてはな らない (MUST NOT): 宛先未到達、リダイレクト、時間超過、パラメタ 問題。もしこのフィルタを提供するならば、アドレスによるパケット フィルタに必要な手続きは、このフィルタにも必要とされる。 DISCUSSION 優先度フィルタは特定の送信元/宛先 IPアドレスの組み合わせやプロト コル、特定のポート等に適用できるべきである。 もし設定での選択で抑制されていないならば、評価フィルタによってパケッ トを落とした時は、コード 14 を持つ ICMP 宛先未到達メッセージを送信 すべきである (SHOULD)。 (3) 指定されたレベルよりも低い優先度を持つトラフィックを拒否したり、 落とすような設定をルータで可能にする、遮断機能を実装してもよい (MAY)。この機能は、管理作業や自発的診断による実装によって作動さ せもよいが、人間の干渉無しで運用する自発的診断メカニズムを不可 にする設定オプションを持たなければならない (MUST)。もし設定での 選択で抑制されていないならば、遮断機能によってパケットを落とし た時、コード 15 を持つ ICMP 宛先未到達メッセージを送信すべきで ある (SHOULD)。 ルータは、単に優先度遮断を理由に IP 優先度 6 (内部ネットワーク 制御) か 7 (ネットワーク制御) を持つデータグラムの転送を拒否し てはならない (MUST NOT)。しかし、高優先度トラフィックをフィルタ にかけるために、優先度遮断と組み合わせて別の基準を使用してもよ い。 DISCUSSION 無制限の優先度遮断は、ルーティングやトラフィック制御の意図しない 遮断を結果として招き得る。一般的な場合、ホストトラフィックは 5 (CRITIC/ECP) の値かそれ以下に制限すべきであるが、これは要件では なく、あるシステムでは正しくないかもしれない。 (4) 起動していないパケットの優先度設定を変更してはならない (MUST NOT)。 (5) (どの優先度値を使用しなければならないかを規定する OSPF 等のプロ トコルを除いて) サポートされている各々のルーティングや管理プロ トコルで使用する優先度値とは別の値を設定できるべきである (SHOULD)。 (6) 各アドレスの組み合わせに対し、独立してルーティングや管理トラ フィックの優先度を設定できてもよい (MAY)。 (7) リンク層の優先度関連エラー指示に、提供された所で適切に応答しな ければならない (MUST)。もし設定での選択で抑制されていないならば、 優先度関連の条件によりリンクが受諾できないためにパケットが落ち た時、コード 15 を持つ ICMP 宛先未到達メッセージを送信するべき である (SHOULD)。 DISCUSSION (3) に記述されている優先度遮断メカニズムについては議論されている。 遮断によって影響を受けるエリアのトポロジ上の位置に依存して、通過 トラフィックはパケットが落とされる場合、ルーティングプロトコルに よって遮断のエリアに向けられるかもしれない。遮断によって影響を受 けない別のパスが通信ポイント間に存在する場合に、唯一問題がある。 この問題を避けるのに提案されている方法は、たとえ負荷状態であって も最小限の帯域を全ての優先度レベルに提供することや、遮断情報をル ーティングプロトコルで通知することを含む。この問題に対して広く受 け入れられた (実装された) 解決方法が無い中、通過ネットワークで遮 断メカニズムを動作させる際は、十分注意することが推奨される。 トランスポート層中継は、上記 (4) で禁止された機能を合法的に提供 できる。優先度レベルの変更は、TCP とおそらく他のプロトコルに微妙 な相互作用を及ぼすかもしれない。正しく設計することは重要な作業で ある。 (5) と (6) (とセクション [4.3.2] の ICMP メッセージ中の IP 優先 度の議論) の意図は、このルータが他の方法でそれらのビットに基づい て動作するか否かに関わらず、IP 優先度ビットを適切に設定すべきで あるということである。ルーティングプロトコルやネットワーク管理プ ロトコルの将来の規約で、それらのプロトコルによって送信されるメッ セージに対して IP 優先度をどのように設定すべきかが規定されること を期待する。 (7) の適切な応答は、使用するリンク層プロトコルに依存する。通常、 ルータはある期間その宛先への攻撃的なトラフィックの送信の試みを止 めるべきであり、コード 15 (要求された優先度のためのサービスが利 用不可) を持つ ICMP 宛先未到達メッセージを、そのトラフィックの送 信元へ返却すべきである。ルータはまた、先取りされたリンク層コネク ションの再確立をしばらくの間試みるべきでもない。 5.3.4 リンク層ブロードキャストの転送 (PPP を除く) 大半のリンク層プロトコルでの IP パケットのカプセル化は、 受信側が単純にリンク層のプロトコルヘッダ (最も共通的には、リンク層 宛先アドレス) を調べることによって、ブロードキャストとマルチキャス トをユニキャストから区別することを可能にする。このセクションにおけ るリンク層ブロードキャストを参照する規則は、ブロードキャストの区別 を可能にするリンク層プロトコルにのみ適用される。また、リンク層マル チキャストを参照する規則は、マルチキャストの区別を可能にするリンク 層プロトコルにのみ適用される。 もし IP マルチキャストアドレスに向けられていないならば、ルータはリ ンク層ブロードキャストとして受信した如何なるパケットも転送してはな らない (MUST NOT)。後者のケースでは、あるものは効果的なマルチキャス トサービスが無いためにリンク層ブロードキャストが使用されたと推測す るだろう。 もしパケットの宛先アドレスが IP マルチキャストアドレスでないならば、 ルータはリンク層マルチキャストとして受信した如何なるパケットも転送 してはならない (MUST NOT)。 ルータは、リンク層ブロードキャストによって受信したパケットを黙って 破棄すべきである (SHOULD) が、IP マルチキャストか IP ブロードキャス ト宛先アドレスかの特定はしない。 ルータがリンク層ブロードキャストとしてパケットを送信する時、IP 宛先 アドレスは正しい IP ブロードキャストか IP マルチキャストアドレスで なければならない (MUST)。 5.3.5 インターネット層ブロードキャストの転送 IP ブロードキャストアドレスには、二つの主要なタイプが在る。それは、 限定ブロードキャストと直接ブロードキャストである。加えて、直接ブロ ードキャストには三つのサブタイプが在る。それは、特定のネットワーク プレフィクスに向けられたブロードキャスト、特定のサブネットに向けら れたブロードキャスト、特定のネットワークの全てのサブネットに向けら れたブロードキャストである。ルータによるブロードキャストのこれらの カテゴリの一つへの分類は、ブロードキャストアドレスと、宛先ネットワ ークのサブネット構造のルータの理解 (もしあれば) に依存する。同じブ ロードキャストは、異なるルータによって別々に分類される。 限定 IP ブロードキャストアドレスは、全て 1 : { -1, -1 } か 255.255.255.255 であると定義される。 ネットワークプレフィクス直接ブロードキャストは、ローカル部が全て 1 の IP アドレスのネットワークプレフィクス、あるいは { , -1 } で構成される。例えば、クラス A ネットワー クのブロードキャストアドレスは net.255.255.255 であり、クラス B ネッ トワークのブロードキャストアドレスは net.net.255.255 であり、クラス C ネットワークのブロードキャストアドレスは net.net.net.255 である。 net は、ネットワークアドレスの 1 バイトである。 全サブネット直接ブロードキャストは CIDR 環境ではうまく定義されてお らず、このメモのバージョン 1 で反対された。 セクション [4.2.3.1] に記述されているように、ルータは以下の非標準の IP ブロードキャストアドレスに遭遇するかもしれない。 o 0.0.0.0 は、限定ブロードキャストアドレスの廃止された形式である。 o { , 0 } は、ネットワークプレフィクス直接ブロード キャストアドレスの廃止された形式である。 そのセクションに記述されているように、これらのアドレスのどれかのア ドレスを持つパケットは黙って破棄すべきである (SHOULD) が、もしそう でないならば、上記で説明されたブロードキャストアドレスの廃止されて いない形式のアドレスを持つパケットに適用される同じ規則に従って扱わ なければならない (MUST)。これらの規則は、次の 2, 3 セクションで規定 される。 5.3.5.1 限定ブロードキャスト 限定ブロードキャストは転送してはならない(MUST NOT)。限定ブロードキャ ストは破棄してはならない (MUST NOT)。限定ブロードキャストは、限定ブ ロードキャストで十分の場合、直接ブロードキャストの代わりに送信して もよく (MAY)、送信すべきである (SHOULD)。 DISCUSSION 幾つかのルータは、(ユニキャストか直接ブロードキャストとして) 要 求を他のサーバに再送する機能を持つ UDP サーバを含む。この要件は、 そのようなサーバを禁じていると解釈すべきではない。しかし、そのよ うなサーバはもし誤って構成されたら、簡単にパケットループを引き起 こすことに注意されたい。従って、そのようなサーバの提供者はおそら く、注意深くセットアップすることや送信パケットの TTL を慎重に考 慮すべきであることを、ドキュメントで十分に忠告するだろう。 5.3.5.2 直接ブロードキャスト ルータは、全ての正しい、リモートネットワークあるいは接続されたサブ ネット化されていないネットワーク宛ての直接ブロードキャストを、ネッ トワークプレフィクス直接ブロードキャストとして分類しなければならな い (MUST)。CIDR の観点では、それはネットワークプレフィクス内のホス トアドレスとして現れることに注意されたい。我々は、そのようなネット ワークプレフィクスのホスト部の点検を除外する。経路が与えられ、最優 先のポリシーが無いならば、ルータはネットワークプレフィクス直接ブロ ードキャストを転送しなければならない (MUST)。ネットワークプレフィク ス直接ブロードキャストは送信してもよい (MAY)。 ルータは、あるインタフェース上で、ネットワークプレフィクス直接ブロ ードキャストの受信を不可にするオプションを持ってもよく (MAY)、ネッ トワークプレフィクス直接ブロードキャストの転送を不可にするオプショ ンを持たなければならない (MUST)。これらのオプションはデフォルトで、 ネットワークプレフィクス直接ブロードキャストの受信や転送を許さなけ ればならない (MUST)。 DISCUSSION 直接ブロードキャストを転送するか転送しないかについて、幾つかの議 論がなされている。このメモでは、ルータの宛先ネットワークプレフィ クスの知識に従って転送するという決定をした。この知識無しで、ルー タはメッセージがユニキャストか直接ブロードキャストかを決定するこ とはできない。メッセージを転送するか転送しないかの決定は、最終ホッ プのルータでのみ可能な定義である。 5.3.5.3 全サブネット直接ブロードキャスト このメモの最初の版は、古典的なネットワーク番号の全てのサブネットへ の直接ブロードキャストを配送するためのアルゴリズムを説明した。この アルゴリズムは "壊れた" と明記され、ある失敗ケースが示された。 CIDR ルーティングドメインでは、古典的な IP ネットワーク番号は意味を 持たず、全サブネット直接ブロードキャストの概念もまた意味を持たない。 ワーキンググループの認識では、その設備は決して実装されないし提供さ れず、現在歴史のごみ箱に捨てられている。 5.3.5.4 サブネット直接ブロードキャスト このメモの最初の版は、サブネッと直接ブロードキャストを扱うための手 続きを説明した。CIDR ルーティングドメインでは、これらはネットワーク 直接ブロードキャストと識別できない。従って、この二つはセクション [5.3.5.2 直接ブロードキャスト] で一緒に扱われ、ネットワークプレフィ クス直接ブロードキャストとして見るべきである。 5.3.6 輻輳制御 ネットワークにおける輻輳は、リソースの需要 (大抵帯域か CPU 時間) が 許容量を超えた状態として大雑把に定義されている。輻輳回避は許容量を 超える需要を防ぐ試みで、輻輳回復は適切な運用状態に回復する試みであ る。ルータがこれらのメカニズムの両方に貢献することは可能である。そ の問題の検討には多大な労力が費やされた。読者は、この作業を調べるた めに [FORWARD:2] を読むことが望ましい。その主題についての重要な紙面 は、他の中でも [FORWARD:3]、[FORWARD:4]、[FORWARD:5]、[FORWARD:10]、 [FORWARD:11]、[FORWARD:12]、[FORWARD:13]、[FORWARD:14]、[INTERNET:10] を含む。 ホストが [FORWARD:5] で説明されているような効率的な輻輳ポリシーを用 いる時に、ルータが一時的な需要のピークを扱うために利用可能にすべき 記憶装置の量は、パスがリンクを使用するフローを遅延させるリンク時間 と帯域の積の機能である。従って、この帯域×遅延の積が増えるに従って 記憶装置を増やすべきである。破棄する可能性に関係する記憶装置の許容 量の正確な機能は未知である。 ルータが記憶装置の許容量を超えてパケットを受信した時、そのパケット か、他の幾つかのパケットを破棄しなければならない (規定ではなく定義 による)。どのパケットを破棄するかは要検討項目であるが、不幸にもこれ までのところほとんど合意を得られていない。これまでの最善の叡智は、 データストリームから最も大量にリンクを使用しているパケットの破棄を 提案する。しかし、トラフィックの優先度や活性帯域の予約、そのパケッ トの選択に関連した複雑性を含め、数多くの追加要因が関係するかもしれ ない。 ルータは単に受信したパケットを破棄してもよい (MAY)。これは最も簡単 であるが最善のポリシーではない。理想的には、もし適用可能なサービス 品質ポリシーがこれを許すならば、ルータは最もひどくリンクを乱用して いるセッションの一つからパケットを選択すべきである。 FIFO キューを使用するデータグラム環境で推奨されるポリシーは、キュー から選択したパケットをランダムに破棄することである ([FORWARD:5] 参 照)。公正なキューを使用しているルータと同等のアルゴリズムは、最も長 いキューから破棄することか、あるいは最も大きい仮想時間 ([FORWARD:13] 参照) を使用することである。ルータは、どのパケットを破棄するかを決 定するために、これらのアルゴリズムを使用してもよい (MAY)。 もしルータが、適格なパケットのプールから破棄するためのパケットを選 択する破棄ポリシー (例えばランダムドロップ) を実装するならば: o もし優先度順序キューサービス (セクション [5.3.3.1] で説明) が実装 され、使用可能ならば、ルータは破棄されないパケットよりも IP 優先 度が高いパケットを破棄してはならない (MUST NOT)。 o ルータは、そうすると前の規則に反する場合を除いて、IP ヘッダが最大 信頼性 TOS を要求するパケットを保護してもよい (MAY)。 o ルータは、データグラムのフラグメントを落とすと、データグラムの全 てのフラグメントが送信元によって再送されるので、輻輳が増すかもし れないという推測に基づいて、分割された IP パケットを保護してもよ い (MAY)。 o ルーティングの乱れや管理機能の中断を避けるために、ルータはルーティ ング制御、リンク制御、ネットワーク管理のために使用されるパケット を破棄することから保護してもよい (MAY)。専用ルータは (すなわち、 一般的な目的のホストや端末サーバにならないルータ) は、送信元か宛 先がルータ自身であるパケットを保護することによって、この規則に近 いことが達成できる。 輻輳制御の進歩した方法は公正さの概念を含む。そのため、パケットを失 うことによって罰則を科せられた 'ユーザ' は最も輻輳の一因となったも のである。帯域輻輳制御を扱うためにどんなメカニズムが実装されていて も、消費される CPU の負荷は、ルータが CPU の輻輳にも追いこまれない 程十分に小さいことが重要である。 セクション [4.3.3.3] で説明されているように、このドキュメントは、ル ータが破棄したパケットの送信側に送信元抑制を送信すべきでない (SHOULD NOT) ことを推奨する。ICMP 送信元抑制は非常に弱いメカニズム である。従って、ルータはそれを送信する必要はないし、ホストソフトウェ アはそれを輻輳を示すものとして全面的に使用すべきではない。 5.3.7 マーチャンアドレスフィルタ IP 送信元アドレスは、もしセクション 4.2.2.11 や 5.3.7 で定義されて いるような特別な IP アドレスか、ユニキャストアドレスでないならば不 正である。 IP 宛先アドレスは、セクション 4.2.3.1 の違反した宛先として定義され たものの中にあるか、クラス 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 宛先アドレスを、そしてもし問題が送信元アドレ スにあるならば、パケットを受信した物理インタフェースとパケットを受 信したホストかルータのリンク層アドレスをログに採取すべきである (SHOULD)。 5.3.8 送信元アドレス評価 ルータは、パケットの送信元アドレスとパケットを受信した論理インタフェ ース用の転送テーブルの比較に基づいて、トラフィックをフィルタする能 力を実装すべきである [SHOULD IMPLEMENT]。もしこのフィルタが利用可能 ならば、ルータはもしパケットを受信したインタフェースが、送信元アド レスに含まれているアドレスに到達させるためにパケットを転送するイン タフェースでないならば、そのパケットを黙って破棄しなければならない (MUST)。同様に、もしルータがこのアドレスを含むパケットを、特定のイ ンタフェースを通じて振り分けないならば、このインタフェースから読み 込んだアドレス中の送信元アドレスとして現われているならば、そのアド レスを信じるべきではない。 もしこの機能を実装するならば、デフォルトでは不可にしなければならな い (MUST)。 DISCUSSION この機能は、ある状況で有効なセキュリティ改善を提供できるが、パス が非対称である状況では正しいパケットを誤って破棄し得る。 5.3.9 パケットフィルタとアクセスリスト ネットワークの部分を通じてセキュリティとトラフィック制限を提供する 手段として、ルータはパケットを選択して転送する (フィルタする) 機能 を提供すべきである (SHOULD)。もしこの機能を提供するならば、パケット のフィルタは全パケットを転送するか、送信元と宛先のプレフィクスに基 づいてそれらを選択して転送するかを設定可能にすべきであり (SHOULD)、 他のメッセージ属性に基づいてフィルタしてもよい (MAY)。各送信元と宛 先アドレスは、任意のプレフィクス長の指定を可能にすべきである (SHOULD)。 DISCUSSION この機能によりある程度のプライバシーを提供でき、境界の外側のシス テムが境界の内側のシステムとのあるプロトコルの交換を許可しない、 あるいはどのシステムと通信してもよいかを制限することができる。ま た、境界の外側のシステムが境界の内側のシステムに成りすましたり、 そのセッションを真似るような、ある種のセキュリティ破りを防ぐこと ができる。 もしサポートするならば、ルータは以下の一つを許可するよう設定可能に すべきである (SHOULD)。 o 包含リスト - 転送するメッセージ定義のリストを指定する。 o 除外リスト - 転送しないメッセージ定義のリストを指定する。 この文脈における「メッセージ定義」は送信元と宛先のネットワークプレ フィクスを示し、IP プロトコルタイプや TCP ポート番号等の他の識別情 報を含んでもよい。 ルータは、包含リストや除外リストやそれと同等の制御間での選択を可能 にする設定スイッチを提供してもよい (MAY)。 如何なるアドレスとも一致する値 (例えばエニイのキーワード、全て 0 の マスクを持つアドレス、長さが 0 であるネットワークプレフィクス) を、 送信元と宛先アドレスとして許さなければならない (MUST)。 アドレスのペアに加えて、ルータはトランスポートやアプリケーションプ ロトコル、送信元と宛先ポートの指定を可能にしてもよい (MAY)。 ルータはパケットを黙って破棄する (すなわち ICMP エラーメッセージを 送信しない) ことを可能にしなければならない (MUST)。 ルータは、パケットを破棄する時、適切な ICMP 未到達メッセージの送信 を可能にすべきである (SHOULD)。ICMP メッセージは、宛先未到達の理由 として通信管理上禁止 (コード 13) を指定すべきである (SHOULD)。 ルータは、指定を許可されたアドレスペア、プロトコルタイプ、ポートの 各々の組み合わせに対して、ICMP 宛先未到達メッセージ (コード 13) の 送信を設定可能にすべきである (SHOULD)。 ルータは転送しないパケットを数えるべきであり (SHOULD)、ログの採取を 選択できるべきである (SHOULD)。 5.3.10 マルチキャストルーティング IP ルータは、IP マルチキャストパケットの転送を、静的マルチキャスト 経路か、マルチキャストルーティングプロトコル (例えば DVMRP [ROUTE:9]) によって動的に決定された経路のいずれかに基づいてサポートすべきであ る (SHOULD)。IP マルチキャストパケットを転送するルータは、マルチキャ ストルータと呼ばれる。 5.3.11 転送時の制御 各々の物理インタフェースに対して、ルータは転送がそのインタフェース 上で可能にするか否かを指定する、設定オプションを持つべきである (SHOULD)。インタフェース上で転送が不可の場合、ルータは、 o そのインタフェース上で受信したが、ルータ宛てではないパケットは破 棄しなければならない (MUST)。 o ルータによって生成されたデータグラムを除いて、そのインタフェース にパケットを送出してはならない (MUST NOT)。 o そのインタフェースを通るパスの有効性を、如何なるルーティングプロ トコルによっても知らせてはならない (MUST NOT) DISCUSSION この機能により、ネットワーク管理者は本質的にインタフェースを閉じ るが、ネットワーク管理のためにアクセス可能なままにすることが可能 である。 理想的には、その制御は物理インタフェースではなく、論理インタフェ ースに適用される。論理インタフェースと物理インタフェースが 1 対 1 対応でない場合、パケットが到着した論理インタフェースをルータが 決定する一般的な方法は存在しない。 5.3.12 状態変更 ルータの稼動中に、インタフェースが異常になるか手動で使用不可になる かもしれないし、ルータによって使用が可能になるかもしれない。同様に、 転送が特定のインタフェースやルータ全体で使用不可かもしれないし、(再 度) 使用可能かもしれない。そのような変化は (通常) 珍しいが、ルータ がそれらを正しく処理することは重要である。 5.3.12.1 ルータが転送を終了する時 ルータが転送を止める時、サードパーティ経路を除いて全てのルータへの 通知を止めなければならない (MUST)。受信と、自分のルーティングドメイ ン内の他のルータからの経路の使用は継続してもよい (MAY)。もし転送デ ータベースが保持されるならば、ルータは転送データベース中の経路のタ イマ計測を止めてはならない (MUST NOT)。もし他のルータから受信した経 路を記憶しているならば、覚えている経路のタイマ計測を止めてはならな い (MUST NOT)。転送不能の間にタイマが満了した経路は、転送可能だった 場合と同じように破棄しなければならない (MUST)。 DISCUSSION ルータが転送を止める時、ルータが本質的にルータであることを止める。 ルータは依然としてホストであり、ホスト要件 [INTRO:2] の要件の全 てに従わなければならない。しかしながら、ルータは依然として一つ以 上のルーティングドメインの受動的なメンバであってもよい。その場合、 そのルーティングドメイン中の他のルータをリッスンすることによって、 転送データベースを保持することが可能である。しかし、ルータ自身は 転送を実行しないので、転送データベース中の如何なる経路も通知しな くてよい。この規則の唯一の例外は、ルータが他のルータのためだけに 使用する経路を通知する場合であり、このルータは通知することが求め られる。 ルータは、ICMP 宛先未到達 (ホスト未到達) メッセージを転送できないパ ケットの送信者に送信してもよい (MAY)。ルータは、ICMP リダイレクトメッ セージを送信すべきでない (SHOULD NOT)。 DISCUSSION ICMP 宛先未到達 (ホスト未到達) を送信することは、ルータの動作で ある。このメッセージは、ホストが送信すべきでない。ホストに対する この規則の例外は許されており、それにより最短時間で再振り分け可能 になるかもしれないし、ブラックホールを避けられるかもしれない。 5.3.12.2 ルータが転送を開始する時 ルータが転送を開始する時、ルータは正常に経路情報を交換する全てのル ータへ、新しい経路情報を手早く送信すべきである (SHOULD)。 5.3.12.3 インタフェース障害か使用不可な時 もしインタフェースが障害か使用不可である時、ルータはそのインタフェ ースを使用する転送データベース中の全ての経路を削除し、通知を止めな ければならない (MUST)。ルータは、そのインタフェースを使用する全ての 静的経路を使用不可にしなければならない (MUST)。もし同じ宛先と TOS の他の経路をルータによって知らされ覚えているならば、そのルータは最 善の代替を選択し、転送データベースに追加しなければならない (MUST)。 ルータは、インタフェースが使用不可になったことによって転送できない 全てのパケットに対する応答として、適宜 ICMP 宛先未到達か ICMP リダ イレクトメッセージを送信すべきである (SHOULD)。 5.3.12.4 インタフェースが使用可能な時 もし使用不能なインタフェースが使用可能になった時、ルータはそのイン タフェースを使用する全ての静的経路を再度使用可能にしなければならな い (MUST)。もしルータがその経路をルータによって知らされたら、これら の経路を他の全ての認識している経路と共に評価し、転送データベース中 にどの経路を置いておくべきかを決定しなければならない (MUST)。どのよ うにこの決定を下すかの詳細情報について、実装者はチャプタ [7] アプリ ケーション層 - ルーティングプロトコルを参照されたい。 ルータが転送を開始する時、ルータは正常に経路情報を交換する全てのル ータへ、新しい経路情報を手早く送信すべきである (SHOULD)。 5.3.13 IP オプション 経路記録やタイムスタンプ等の幾つかのオプションは、パケットを転送す る時にルータが自身のアドレスを挿入するスロットを含む。しかし、各々 のそうしたオプションはスロットの固定番号を持ち、そのために自身のア ドレスを挿入できる空きスロットが存在しないことがあるかもしれない。 挿入する残りのスロットが無いオプションに、ルータがアドレスを挿入す る必要があると解釈すべき要件は、以降のリストにはない。セクション [5.2.5] は、オプションに挿入する自身のアドレスをどのようにルータが 選択しなければならないかを論じている。 5.3.13.1 認識できないオプション 転送パケット中の認識できない IP オプションは、変更せずにパススルー しなければならない (MUST)。 5.3.13.2 セキュリティオプション ある環境では、全てのパケットにセキュリティオプションを必要とする。 そうした要件は、このドキュメントや IP 標準規約の適用外である。しか し、[INTERNET:1] と [INTERNET:16] で規定されているセキュリティオプ ションは廃止されていることに注意されたい。ルータは、[INTERNET:5] で 規定されている改訂版セキュリティオプションを実装すべきである (SHOULD IMPLEMENT)。 DISCUSSION 複数のセキュリティレベルを持つネットワークで使用することが意図さ れたルータは、IPSO (RFC-1108) ラベルに基づくパケットフィルタをサ ポートすべきである。このサポートを実装するために、ルータは低次セ キュリティ制限 (例えば分類無し) と高次セキュリティ制限 (例えば秘 密) の両方を、ルータ管理者が各々のインタフェースに設定することを 可能にする必要があるだろう。二つの制限が同じである (例えば単一レ ベルインタフェース) ことは普通だが常にそうとは限らない。範囲外で あるために IPSO フィルタに捉えられるパケットは黙って落とされるべ きであり、カウンタは IPSO ラベルの範囲外のために落とされたパケッ トの個数を控えておくべきである。 5.3.13.3 ストリーム識別子オプション このオプションは廃止された。もしストリーム識別子オプションがルータ によって転送されるパケットに存在したら、そのオプションを無視して、 変更せずにパススルーしなけれはならない (MUST)。 5.3.13.4 送信元経路オプション ルータは、転送パケット中の送信元経路オプションのサポートを実装しな ければならない (MUST)。ルータは、使用可で設定されている場合に送信元 経路付きのパケットを全て破棄する設定オプションを実装してもよい (MAY)。 しかし、そのオプションはデフォルトでは使用可にしてはならない (MUST NOT)。 DISCUSSION インターネットを通じた送信元経路データグラムの能力は、様々なネッ トワーク診断ツールのために重要である。しかし、送信元ルーティング をネットワーク内のバイパス管理やセキュリティ制御で使用してもよい。 特に、パケットフィルタ等の他の方法の代わりに管理上の分離を提供す るためにルーティングテーブルの操作が用いられる場合、送信元経路付 きのパケットによって害を被りやすいかもしれない。 EDITORS+COMMENTS もし送信元経路付きのパスの最終区間を除く全てのルータに適用される ならば、パケットフィルタは送信元ルーティングによっても無効になり える。経路もパケットフィルタも、セキュリティのための完全な解決に はならない。 5.3.13.5 経路記録オプション ルータは、転送パケット中の経路記録オプションのサポートを実装しなけ ればならない (MUST)。 ルータは、もし使用可ならばルータが転送パケットで記録経路オプション を無視する (すなわち変更せずにパススルーする) 設定オプションを提供 してもよい (MAY)。もし提供するならば、そのオプションはデフォルトで 経路記録を使用可にしなければならない (MUST)。このオプションは、ルー タ自身によって受信されたデータグラム中の経路記録オプションの処理に 影響してはならない (特に ICMP エコー要求中の経路記録オプションは、 依然としてセクション [4.3.3.6] に従って処理される) 。 DISCUSSION 経路記録はネットワークのトポロジについての情報を明らかにするので、 セキュリティ上問題であると考える人はいる。従って、このドキュメン トは使用不可にすることを許している。 5.3.13.6 タイムスタンプオプション ルータは、転送パケット中でタイムスタンプオプションをサポートしなけ ればならない (MUST)。タイムスタンプ値は [INTRO:2] の規則に従わなけ ればならない (MUST)。 もしフラグフィールド = 3 ならば (タイムスタンプと事前指定アドレス)、 ルータはもし事前指定アドレスがルータの IP アドレスのいずれかと一致 するならば、タイムスタンプを追加しなければならない (MUST)。事前指定 アドレスは、パケットの到着したインタフェース上のアドレスか、パケッ トを送信しようとしているインタフェース上のアドレスのいずれかである 必要はない。 IMPLEMENTATION タイムスタンプオプションに含まれるタイムスタンプの有用性を最大限 に活用するために、パケットがルータに到着した時間と実際に近い時間 を挿入することが提案されている。ルータが生成するデータグラムの場 合、挿入されるタイムスタンプは、送信するためにデータグラムをネッ トワーク層に渡した時間と実際に近い時間であるべきである。 ルータは、もし使用可ならば、フラグワードが 0 (タイムスタンプのみ) か、1 (タイムスタンプと登録された IP アドレス) である場合、転送され るデータグラム中のタイムスタンプオプションを無視する (すなわち変更 せずにパススルーする) 設定オプションを提供してもよい (MAY)。もし提 供するならば、そのオプションはデフォルトでオフ (すなわちルータはタ イムスタンプを無視しない) でなければならない (MUST)。このオプション は、ルータ自身が受信したデータグラム中のタイムスタンプの処理に影響 すべきでない (特に、ルータは自分が受信したデータグラム中のタイムス タンプオプションにタイムスタンプを挿入するだろう。そして、ICMP エコ ー要求は依然としてセクション [4.3.3.6] に従って処理される)。 DISCUSSION 経路記録オプションと同様に、タイムスタンプオプションはネットワー クのトポロジに関する情報を明らかにする。ある人は、これをセキュリ ティの懸案と見なしている。 6. トランスポート層 ルータは、アプリケーション層プロトコルをサポートする必要がない場合 はトランスポート層を実装する必要はない。実際は、これは大半のルータ が転送制御プロトコル (TCP) とユーザデータグラムプロトコル (UDP) の 両方を実装することを意味する。 6.1 ユーザデータグラムプロトコル - UDP ユーザデータグラムプロトコル (UDP) は、[TRANS:1] で規定される。 UDP を実装するルータは、以下を除いて [INTRO:2] の要件に準拠しなけれ ばならず (MUST)、無条件に準拠すべきである (SHOULD)。 o この規約は、様々なプロトコル層間のインタフェースを規定しない。従っ て、ルータのインタフェースは、ルータによってサポートされるアプリ ケーション層の適切な機能実現のために準拠する必要があるものを除い て、[INTRO:2] に準拠する必要はない。 o [INTRO:2] とは反対に、アプリケーションは UDP チェックサムの生成を 不可にすべきではない (SHOULD NOT)。 DISCUSSION 特定のアプリケーションプロトコルは、受信した UDP データグラムが UDP チェックサムを含んでいなければならないことを要求してもよいが、 受信した UDP データグラムが UDP チェックサムを含むという一般的な 要件はない。無論、もし UDP チェックサムが受信した UDP に提供され たら、そのチェックサムをチェックし、もし不正ならば破棄しなければ ならない。 6.2 転送制御プロトコル - TCP 転送制御プロトコル (TCP) は、[TRANS:2] で規定される。 TCP を実装するルータは、以下を除いて [INTRO:2] の要件に準拠しなけれ ばならず (MUST)、無条件に準拠すべきである (SHOULD)。 o この規約は、様々なプロトコル層間のインタフェースを規定しない。従っ て、ルータは [INTRO:2] の次の要件に準拠する必要はない。(ルータに よってサポートされるアプリケーション層の適切な機能実現のために準 拠する必要があるものを除く)。 プッシュの使用: RFC-793 セクション 2.8: 受信した PSH フラグをアプリケーション層に渡すことは、現在 OPTIONAL である。 緊急ポインタ: RFC-793 セクション 3.1: TCP は、緊急ポインタを受信し、ペンディングである緊急データ が前に無い場合やデータストリーム中で緊急ポインタに進んだ場 合は常に、非同期にアプリケーション層に通知しなければならな い (MUST)。アプリケーションが、コネクションから読み込むべき 緊急データがどれくらい残っているかを知るか、あるいは少なく とも読み込むべき緊急データがもっとあるか否かを決定する方法 がなければならない (MUST)。 TCP コネクション障害: アプリケーションは、特定のコネクションに R2 の値を設定でき なければならない (MUST)。例えば、対話型アプリケーションは R2 を '無限' に設定し、いつ切断するかについてユーザに制御を 与える。 TCP マルチホーミング: もしマルチホーム化されたホスト上のアプリケーションが、TCP コネクションを活性でオープンする時に自側 IP アドレスを指定 しないならば、TCP は IP 層に (最初の) SYN を送信する前に自 側 IP アドレスを選択することを依頼しなければならない (MUST)。 セクション 3.4 の GET_SRCADDR() 機能を参照されたい。 IP オプション: アプリケーションは TCP コネクションを活性的にオープンする時、 送信元経路を指定できなければならず (MUST)、これはデータグラ ムで受信した送信元経路より優先しなければならない (MUST)。 o 同様の理由で、ルータは [INTRO:2] の要件の全てに準拠する必要がある わけではない。 o [INTRO:2] にある最大セグメント長オプションに関する要件は、次のよ うに改訂される。(このメモのセクション [4.2.3.3] で論じられている) MTU 検出のホスト部を実装するルータは、パス MTU が分からない場合に 限り SendMSS のデフォルト値として 536 を使用する。もしパス MTU が 分かったならば、SendMSS のデフォルト値はパス MTU - 40 である。 o [INTRO:2] の最大セグメント長オプションに関する要件は、次のように 改訂される。ICMP 宛先未到達のコード 11 と 12 は、追加のソフトエラ ー状態である。従って、これらのメッセージは TCP にコネクションをア ボートさせてはならない (MUST NOT)。 DISCUSSION ルータ中の TCP 実装は、[INTRO:2] の次の要件に適合しなければなら ないことに、特に注意すべきである。 o 設定可能な TTL を提供すること。[生存時間: RFC-793 セクション 3.9] o もしキープアライブを完全に使用するならば、キープアライブの振る 舞いを設定するインタフェースを提供すること。[TCP キープアライ ブ] o エラー通知メカニズムと、それを管理する能力を提供すること。[非 同期通知] o サービスタイプを指定すること。[サービスタイプ] 一般に適用されるパラダイムは、もし特定のインタフェースがルータの 外側で見えるならば、そのインタフェースに対する全ての要件に従わな ければならない。例えばもしルータが telnet 機能を提供するならばト ラフィックを生成し、外部ネットワークに振り分けられるだろう。従っ て、サービスタイプを正しく設定できなければならず、さもなくば telnet トラフィックが通じないかもしれない。 7. アプリケーション層 - ルーティングプロトコル 7.1 導入 技術的、経済的、時々政治的な理由により、インターネットルーティング システムは二つの構成要素で構成される。それは、内部ルーティングと外 部ルーティングである。自律システム (AS) の概念は、このドキュメント のセクション 2.2.4 で定義されているように、外部ルーティングから内部 ルーティングを切り離す際にキーの役割を果たし、この概念により、内部 から外部への変更が発生する一組のルータを正確に捉えることが可能にな る。IP データグラムは、宛先に到達するために二つ以上の自律システムの ルータを横断しなければならないかもしれず、そうした転送を可能にする ために、自律システムは互いにトポロジ情報を提供しなければならない。 内部ゲートウェイプロトコル (IGP) は、AS の範囲内でルーティング情報 を分散するために使用される (イントラ AS ルーティング) 。外部ゲート ウェイはプロトコルは、AS 間でルーティング情報を交換するために使用さ れる。 7.1.1 ルーティングセキュリティの考慮 ルーティングは、安定性原理 (受信するものに寛大であれ) が適用されな い箇所の一つである。ルータは、他のルーティングシステムからルーティ ングデータを受信する際、比較的疑い深くあるべきである。 ルータはルーティング情報の送信元を、最も信頼できるものから最も信頼 できないものまでランク付けする能力を提供し、最も信頼できる送信元か ら特定の宛先に関するルーティング情報を最初に受信すべきである (SHOULD)。これは、EGP や様々な内部ルーティングプロトコルを使用する 元のコア/スタブ自律システムルーティングモデルにおいて暗黙的であった。 それは中央の信頼できるコアが無くなってもさらに重要である。 ルータは、明白に不正な経路 (例えばネット 127) をフィルターするメカ ニズムを提供すべきである (SHOULD)。 ルータはデフォルトで、自分自身が使用していない、信頼していない、正 当であるとみなしていないルーティングデータを再配布してはならない (MUST NOT)。希なケースで、疑わしい情報を再配布することが必要かもし れないが、これはある人間の機関による直接の調停下でのみ起こすべきで ある。 ルータは、どこかからルーティングデータを受信することは、少なくとも 若干は恐れなければならず、別のパーティーによって提供されたルーティ ング情報を配布する時、特に注意しなければならない。特定の指針につい ては、以下を参照されたい。 7.1.2 優先度 特定のルーティングプロトコルの規約で規定しているものを除き、ルータ はルーティングトラフィックを運ぶ IP データグラムの IP 優先度値を 6 (INTERNETWORK CONTROL) に設定すべきである (SHOULD) DISCUSSION ルーティングトラフィックはほとんど例外無く、如何なるネットワーク においても最も高い優先度であるべきである。もしシステムのルーティ ングトラフィックが通じなければ、他の機会は無いだろう。 7.1.3 メッセージ評価 ペアツーペアの認証は幾つかのテストを伴う。メッセージパスワードと明 示的に受諾できる隣接者リストのアプリケーションは、過去に経路データ ベースの強靭性を改善した。ルータは、正しいルーティング隣接者の明示 的なリスト化を可能にする管理制御を実装すべきである (SHOULD IMPLEMENT)。ルータは、それをサポートしているルーティングプロトコル のためのペアツーペアの認証を実装すべきである (SHOULD IMPLEMENT)。 ルータは、送信元アドレスとメッセージを受信したインタフェースに基づ いてルーティング隣接者を評価すべきである (SHOULD)。すなわち、サブネッ トと仮定したインタフェースを経由して、あるいはアンナンバードインタ フェースを経由してルータと通信するために、直接接続されたサブネット 内の隣接者に限定されるべきである (SHOULD)。他のインタフェース上で受 信したメッセージは、黙って破棄すべきである (SHOULD)。 DISCUSSION セキュリティ破りや多数のルーティング問題は、この基本的なテストに よって避けられる。 7.2 内部ゲートウェイプロトコル 7.2.1 導入 内部ゲートウェイプロトコル (IGP) は、特定の AS 内の様々なルータ間で ルーティング情報を配布するために使用される。特定の IGP を実装するた めに使用されるアルゴリズムには関係なく、以下の機能を実現すべきであ る。 (1) AS の内部ドポロジ内の変更に即座に応答する。 (2) 回線フラッピングが継続的なルーティング更新を引き起こさないよう なメカニズムを提供する。 (3) ループフリールーティングへの素早い収束を提供する。 (4) 最小限の帯域を利用する。 (5) 負荷分散を可能にするために等価経路を利用する。 (6) ルーティング更新の認証のための手段を提供する。 インターネットで今日使用される現在の IGP は、距離ベクトルかリンク状 態アルゴリズムのいずれかに基づくものとして特徴付けられる。 最も一般的に使用されるものや、将来広く使用されると思われる最近開発 されたプロトコルを含め、幾つかの IGP についてはこのセクションで詳細 に説明する。イントラ AS ルーティングで使用することを意図した数多く の他のプロトコルが、インターネット社会に存在する。 ルーティングプロトコル (静的経路以外) を実装しているルータは、OSPF (セクション [7.2.2] 参照) を実装しなければならない (MUST IMPLEMENT)。 ルータは追加の IGP を実装してもよい (MAY) 7.2.2 オープン最短パス優先 - OSPF 最短パス優先 (SPF: Shortest Path First) ベースのルーティングプロト コルは、Dijkstra の最短パスアルゴリズムに基づくリンク状態アルゴリズ ムの一つのクラスである。SPF ベースのアルゴリズムは大体 ARPANET の頃 から存在するが、IP と OSI 社会の両方で主に使われるようになったのは ほんの最近のことである。SPF ベースのシステムでは、各々のルータはフ ラッディングと呼ばれるプロセスを通じてトポロジ全体のデータベースを 得る。フラッディングは情報の信頼できる転送を保証する。そして各々の ルータは、IP ルーティングテーブルを作成するために、自身のデータベー スに対して SPF アルゴリズムを実行する。OSPF ルーティングプロトコル は、SPF アルゴリズムの実装である。現在のバージョンは、[ROUTE:1] で 規定されている OSPF バージョン 2 である。OSPF バージョン 1 を規定し ている RFC-1131 は廃止されたことに注意されたい。 このメモのセクション [8.3] に従うために、OSPF を実装するルータは OSPF MIB [MGT:14] を実装しなければならない (MUST)。 7.2.3 中間システムツー中間システム - 二重 IS-IS 米国規格協会 (ANSI) X3S3.3 委員会は、内部ドメインルーティングプロト コルを定義した。このプロトコルは、中間システムツー中間システムルー ティング交換プロトコルと名づけられた。 IP ネットワークへのそのアプリケーションは [ROUTE:2] で定義され、二 重 IS-IS (あるいは統合 IS-IS) と呼ばれている。IS-IS はリンク状態 (SPF) ルーティングアルゴリズムに基づき、プロトコルのこのクラスの長 所を全て共有する。 7.3 外部ゲートウェイプロトコル 7.3.1 導入 外部ゲートウェイプロトコルは、特定の自律システムへの一連のネットワ ークの到達性情報を、隣接する自律システムと交換するための自律システ ム間ルーティングとして利用される。 AS 間ルーティングの分野は、インターネット技術作業団体内の現在の調査 トピックである。セクション [付録 F.1] で規定されている外部ゲートウェ イプロトコル (EGP) は、伝統的にえり抜きの AS 間プロトコルであるが、 現在は歴史的である。ボーダーゲートウェイプロトコル (BGP) は EGP の 数多くの制限や限定を取り除き、その結果急速に普及しつつある。ルータ は AS 間ルーティングプロトコルを実装する必要はない。しかし、もしル ータが EGP を実装するならば、BGP も実装しなければならない (MUST IMPLEMENT)。外部ゲートウェイプロトコルとして設計されてはいないが、 RIP (セクション [7.2.4] で規定) は時々 AS 間ルーティングのために使 用されることがある。 7.3.2 ボーダーゲートウェイプロトコル - BGP 7.3.2.1 導入 ボーダーゲートウェイプロトコル (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 プロトコルウォークスルー BGP は ([ROUTE:5] のセクション 4.2 の例に見られるような) 極めて複雑 なルーティングポリシーのサポートを提供するが、全ての BGP 実装者がそ のようなポリシーをサポートする必要があるわけではない。しかし、最低 限 BGP 実装は、 (1) BGP が知った隣接する AS への経路の通知を、AS が制御できるべきで ある (SHOULD)。実装体は、少なくとも単一ネットワークの精度でそう した制御をサポートすべきである (SHOULD)。また、実装体は自律シス テムの精度でもそうした制御をサポートすべきである (SHOULD)。その 場合、自律システムは経路を起動する自律システムか、ローカルシス テム (隣接する自律システム) に経路を通知する自律システムのいず れかであってもよい。 (2) (一つ以上のパスが使用可能である時) 宛先への特定のパスを選ばせる ことを AS に可能にすべきである (SHOULD)。そのような機能は、シス テム管理者が自律システムに重みを割り当てることを可能にし、経路 選択処理に最も低い重みを持つ経路 (経路の重みは、その経路に割り 当てられた AS_PATH パス属性の全ての AS の重みの合計として定義さ れる) を選択させることによって実装すべきである (SHOULD)。 (3) AS_PATH パス属性中の ある AS が持つ経路を無視することを AS に可 能にすべきである (SHOULD)。そのようの機能は (2) で概説された技 術を使用し、AS の重みとして無限を割り当てることによって実装でき る。経路選択処理は、無限に等しい重みを持つ経路を無視しなければ ならない。 7.3.3 外部プロトコルの無い AS 間ルーティング 二つの別個の、標準の内部ルーティングプロトコルの間で標準の外部ルー ティングプロトコルを使用せずに、二つの自律システムかルーティングド メイン間で、ルーティング情報を交換することは可能である。これを行う 最も一般的な方法は、二つのプロセス間の経路情報の交換を行う境界ルー タの一つで、独立して両方の内部プロトコルを実行することである。 EGP から IGP への情報の交換において、適切な制御がなければ、単一ルー タにおける二つの IGP 間のルーティング情報のこれらの交換は、ルーティ ングループを生成しそうである。 7.4 静的ルーティング 静的ルーティングは、特定の宛先に対するルータからの次ホップを明示的 に定義する手段を提供する。ルータは宛先への静的経路を定義する手段を 提供すべきである (SHOULD)。その場合、宛先はネットワークプレフィクス によって定義される。そのメカニズムは、各々の静的経路に対してメトリッ クの指定も可能にすべきである (SHOULD)。 動的ルーティングプロトコルをサポートするルータは、使用するルーティ ングプロトコルにおいて正しいメトリックで静的経路を定義することを可 能にしなければならない (MUST)。ルータは、ルーティングプロトコルを通 じて通知するかもしれない静的経路のリストを、ユーザが指定する能力を 提供しなければならない (MUST)。加えて、もしその情報を使用できるルー ティングプロトコルをサポートするならば、ルータは以下の追加情報をサ ポートすべきである (SHOULD)。 o TOS o サブネットマスク o プレフィクス長 o 経路を取り込める所定のルーティングプロトコルに特定なメトリック 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 経路 (あるいはメトリックの ドメインに依存した何か) の中に、静的経路を作成する。従って、その ドメインの経路検索アルゴリズムが適用できる。しかし、静的経路を動 的ルーティングドメインの中に強いることは、ルータがその経路を動的 ルーティングドメインに再配布する権限を与えないので、これは経路漏 れではない。 特定のルーティングドメインに置かれない静的経路のために、経路検出 アルゴリズムは (1) 基本照合 (2) 最長照合 (3) 弱い TOS (もし TOS がサポートされるなら) (4) 最善メトリック (メトリックは実装定義である) 最終ステップは必要ないかもしれないが、一つのインタフェース上に主 要静的経路、代替インタフェース上に第二静的経路を持ちたい場合に有 効である。その場合、もし主要経路のインタフェースが障害ならば代替 パスにフェイルオーバーできる。 7.5 ルーティング情報のフィルタリング ネットワーク内のルータは、転送データグラムダース内に含まれた情報に 基づいて転送決定を下す。単純なネットワークでは、データベースの内容 は静的に設定可能かもしれない。ネットワークがより複雑になるにつれ、 転送データベースの動的更新の必要性がネットワークの効率的な運用のた めに重要である。 もしネットワークを通じたデータフローを可能な限り効率的にするならば、 転送データベースを作成するためにルータが使用する情報の通知を制御す るメカニズムを提供することが必要である。この制御はルーティング情報 の送信元が信頼できるものを選択し、信用できる情報の部分を選択すると いう形態を取る。その結果の転送データベースは、利用可能な経路情報の フィルタされたバージョンである。 効率性に加え、ルーティング情報の通知を制御することは、不正なあるい は悪いルーティング情報の広がりを防ぐことによって不安定さを減らす。 幾つかのケースで、ローカルポリシーは広く通知しない完全なルーティン グ情報を必要とするかもしれない。 これらのフィルタリング要件は、非 SPF ベースのプロトコルにのみ適用さ れる (従って距離ベクトルアルゴリズムを実装しないルータには全く適用 されない)。 7.5.1 経路評価 もし更新を受信したルーティングプロトコルが、それらの値を特別な経路 (例えばデフォルト経路) を符号化するために使用しないならば、ルータは このメモの規定に違反した経路を通知しているルーティング更新を、エラ ーとしてログに記録すべきである (SHOULD)。 7.5.2 基本経路フィルタリング ルーティング情報のフィルタリングは、受信したパケットを転送するため にルータによって使用されるパスの制御を可能にする。ルータはルーティ ング情報のどの送信元をリッスンするか、どの経路を信じるかを選択可能 にすべきである。従って、ルータは以下を指定する能力を提供しなければ ならない (MUST) o どの論理インタフェース上でルーティング情報を受諾するか、各々の論 理インタフェースから何の経路を受諾するか。 o 論理インタフェース上に通知するのは、全ての経路かデフォルト経路の みか。 あるルーティングプロトコルは、論理インタフェースをルーティング情報 の送信元として認識しない。そのような場合、ルータは以下を指定する能 力を提供しなければならない (MUST)。 o 他のどのルータからルーティング情報を受諾するか 例えば、一つ以上のリーフネットワークを、主要な部分やより大きなネッ トワークのバックボーンに接続しているルータを想定する。リーフネット ワークの各々は入出力のパスを一つしか持っていないので、ルータは単に デフォルト経路に送信することができる。ルータはリーフネットワークを 主ネットワークに通知する。 7.5.3 拡張経路フィルタリング ネットワークのトポロジがより複雑になるにつれて、より複雑な経路フィ ルタリングの必要性が増している。従って、ルータは各々のルーティング プロトコルに依存せずに、以下を指定する能力を提供すべきである (SHOULD)。 o どの論理インタフェース又はルータから、ルーティング情報を受諾する か、他の各ルータや論理インタフェースからのどの経路を信用するか。 o どの論理インタフェースを経由して、どの経路を送信するか。 o 使用するルーティングプロトコルによってサポートされているならば、 どのルータにルーティング情報を送信するか。 多くの状況では、別のルータから受信したルーティング情報に、上記の第 一段落に示されている単に信用するか信用しないかの選択の代わりに、信 頼性の順位を割り当てることが望ましい。ルータは以下を指定する能力を 提供してもよい (MAY)。 o 受信した各経路に割り当てる信頼性や優先度。各経路に割り当てられた ルーティングメトリックに関わらず、より低い信頼性のものよりも、よ り高い信頼性を持つ経路が選択されるだろう。 もしルータが優先度の割り当てをサポートするならば、ルータは第一パー ティ情報として好まない経路を通知してはならない (MUST NOT)。もし経路 を通知するために使用しているルーティングプロトコルが、第一と第三の パーティ情報を区別できないならば、ルータは好まない経路を通知しては ならない (MUST NOT)。 DISCUSSION 例えば、ルータがルータ R からネットワーク C までの経路とルータ S から同じネットワークまでの経路を受信すると仮定する。もしルータ R がルータ S よりも信頼性が高いと見なすならば、ネットワーク C 向け のトラフィックは、ルータ S から受信した経路に関わらずルータ R に 転送されるだろう。 ルータが使用しない経路のルーティング情報 (上記の例ではルータ S) は、 他のルータに渡してはならない (MUST NOT)。 7.6 ルーティングプロトコル間情報交換 もし同じルータの中で複数の独立した IP ルーティングプロセスを実行で きるならば、ルータは別々の IP 内部ルーティングプロトコル間で、ルー ティング情報を交換できなればならない (MUST)。ルータが二つの別個の内 部ルーティングプロセス間でルーティング情報の 2 方向の交換を行うため に設定される時、ルータはルーティングループを避けるためのメカニズム を提供しなければならない (MUST)。ルータは独立したルーティングプロセ スから経路を選択するために、幾つかの優先度メカニズムを提供しなけれ ばならない (MUST)。ルータは、管理上の境界をまたがって使用する場合、 IGP-IGP 交換の管理上の制御を提供すべきである (SHOULD)。 ルータは、ネットワーク毎に翻訳、あるいは変換メトリックのための幾つ かのメカニズムを提供すべきである (SHOULD)。ルータ (あるいはルーティ ングプロトコル) は、IGP にインポートされる外部経路のグローバルな優 先度を可能にしてもよい (MAY)。 DISCUSSION 異なる IGP は異なるメトリックを使用し、情報をあるプロトコルから メトリックの異なる形式を持つ別のプロトコルに導入する時、翻訳技術 を必要とする。幾つかの IGP は、同じルータかルータのセットの中に 複数のインスタンスを実行することができる。この場合、メトリック情 報は正確に保持するか翻訳することができる。 異なるルーティングプロセスの間で翻訳するのに、少なくとも二つの技 術が存在する。静的 (あるいは到達可能性) アプローチは、所定のメト リックで他の IGP における経路通知を生成するために、ある IGP にお ける経路通知の存在を使用する。翻訳あるいは表のアプローチは、機能 (定数値を追加する等) か表検索のいずれかを使用して、他の IGP にお けるメトリックを生成するために、ある IGP のメトリックを使用する。 ルーティング情報の 2 方向の交換は、フィードバックを制限するため の制御メカニズム無しでは危険である。これは、距離ベクトルルーティ ングプロトコルが水平分割技術を取り上げたり、EGP がサードパーティ 規則を取り上げることと同じ問題である。ルーティングループは、許可 /拒否経路のテーブルかリストを使用することによって明示的に避ける ことができ、また水平分割規則や非サードパーティ規則や経路タグ付け メカニズムを使用することによって暗黙的に避けることができる。ベン ダは、ネットワーク運用者の管理をより容易にすることを可能にするた めに、暗黙的なメカニズムを使用することが推奨される。 8. アプリケーション層 - ネットワーク管理プロトコル このチャプタは [INTRO:3] の "遠隔管理" で述べられている要件に取って 代わることに注意されたい。 8.1 簡易ネットワーク管理プロトコル - SNMP 8.1.1 SNMP プロトコル要素 ルータは SNMP [MGT:3] によって管理しなければならない (MUST)。SNMP は、トランスポートとネットワークプロトコルとして、UDP/IP を使用して 運用しなければならない (MUST)。他のもの ([MGT:25, MGT:26, MGT:27, MGT:28] 参照) をサポートしてもよい (MAY)。SNMP 管理運用は、あたかも ルータ自身に SNMP が実装されているように運用しなければならない (MUST)。特に、管理運用はルータのインタフェースに割り当てられた IP アドレスに、SNMP 管理要求を送信することによって実施しなければならな い (MUST)。実際の管理運用は、ルータかルータのためのプロクシのいずれ かによって実現してもよい。 DISCUSSION この言葉は、プロクシ装置がパケットの宛先アドレスフィールドにルー タの IP アドレスの一つを持つ SNMP パケットに応答する場合はプロク シによって、あるいはルータ自身の中に SNMP を直接実装し、パケット を受信して適切な方法で応答を返すことによってのいずれかで管理でき ることを意図している。 管理運用をルータの IP アドレスの一つに送信できることは重要である。 ネットワークの問題を診断する際、使用可能なルータを識別する唯一の ものは、ルータの IP アドレスの一つかもしれない。それは、恐らく別 のルータのルーティングテーブルを見ることによって獲得されるだろう。 あらゆる SNMP 運用 (get, get-next, get-response, set, trap) を実装 しなければならない (MUST)。 ルータは、SNMP トラップメッセージの生成を制限する割合を指定するメカ ニズムを提供しなければならない (MUST)。ルータは、[MGT:5] で説明され ている非同期警告管理のアルゴリズムを通じて、このメカニズムを提供し てもよい (MAY)。 DISCUSSION トラップの割合制限の必要性についての一般合意はあるが、これをどの ように最善に実現するかについてコンセンサスがまだない。引用されて いる参照は実験と見なされる。 8.2 コミュニティテーブル この規約の目的のために、ルータ内に抽象的な 'コミュニティテーブル' が存在すると仮定する。このテーブルは幾つかのエントリを含み、特定の コミュニティに対する各エントリは、そのコミュニティの属性を完全に定 義するために必要なパラメタを含む。抽象的なコミュニティテーブルを実 際に実装する方法は、無論実装特定である。 ルータのコミュニティテーブルは少なくとも一つのエントリを可能にしな ければならず (MUST)、少なくとも二つのエントリを可能にすべきである (SHOULD)。 DISCUSSION 容量がゼロのコミュニティテーブルは無意味である。それはルータが如 何なるコミュニティも認識せず、従って全ての SNMP 運用が拒否される ことを意味する。 従って、一エントリはテーブルの最低限の有効サイズである。二つのエ ントリを持つことにより、一つのエントリは読み込みだけのアクセスを 許可し、他方には書き込み能力を持たせることが可能になる。 ルータは、SNMP コミュニティテーブル中のエントリをチェック、追加、削 除をユーザが手動で (SNMP を使用せずに) 行えるようにしなければならな い (MUST)。ユーザはコミュニティ名を設定するか、MIB ビューを生成でき なければならない (MUST)。ユーザは、コミュニティを読み込みだけ (すな わち SET 不許可) か読み書き可能 (すなわち SET 許可) としてコミュニ ティを設定できなければならない (MUST)。 もしトラップを使用するならば、ユーザは各々のコミュニティか MIB ビュ ーのための通知を送信する、少なくとも一つの IP アドレスを定義できな ければならない (MUST)。これらのアドレスは、コミュニティか MIB ビュ ーに基づいて定義可能にすべきである (SHOULD)。コミュニティか MIB ビュ ーに基づく通知の可/不可の設定を可能にすべきである (SHOULD)。 ルータは、特定のコミュニティの正しいネットワーク管理者のリストを指 定する能力を提供すべきである (SHOULD)。もし可能ならば、ルータは SNMP データグラムの送信元アドレスをリストに対して評価しなければなら ず (MUST)、もしそのアドレスが無ければ、データグラムを破棄しなければ ならない (MUST)。もしデータグラムを破棄したら、ルータは SNMP 認証失 敗に対する適切な全てのアクションを行わなければならない (MUST)。 DISCUSSION これはむしろ限定された認証システムであるが、様々なパケットフィル タリングの形式と組み合わせて、ある程度セキュリティを高めてもよい。 コミュニティテーブルは、不揮発性の記憶装置に保存しなければならない (MUST)。 コミュニティテーブルの初期状態は、公のコミュニティ名文字列と読み込 みのみのアクセス権を持つ一つのエントリを含むべきである (SHOULD)。こ のエントリのデフォルト状態はトラップを送信してはならない (MUST)。も しそれが実装されているならば、このエントリは管理者がそれを変更する、 または削除するまで、コミュニティテーブルに残ったままでなければなら ない (MUST)。 DISCUSSION デフォルトでは、トラップはこのコミュニティに送信されない。トラッ プ PDU は、ユニキャスト IP アドレスに送信される。このアドレスは、 ある方法でルータ内に設定しなければならない。設定する前はそうした アドレスは存在しないので、誰にトラップを送信すべきか ? よって、 公のコミュニティへのトラップの送信は、デフォルトで不可である。こ れはもちろん一旦ルータを操作すれば、管理上の運用により変更可能で ある。 8.3 標準 MIBS ルータの設定に関連する全ての MIBS を実装すべきである。以下の通り。 o システム、インタフェース、IP、ICMP、MIB-II [MGT:2] の UDP グルー プは実装しなければならない (MUST)。 o インタフェース拡張 MIB [MGT:18] を実装しなければならない (MUST)。 o IP 転送テーブル MIB [MGT:20] を実装しなければならない (MUST)。 o もしルータが TCP (例えば Telnet) を実装するならば、MIB-II [MGT:2] の TCP グループを実装しなければならない (MUST)。 o もしルータが EGP を実装するならば、MIB-II [MGT:2] の EGP グループ を実装しなければならない (MUST)。 o もしルータが OSPF をサポートするならば、OSPF MIB [MGT:14] を実装 しなければならない (MUST)。 o もしルータが BGP をサポートするならば、BGP MIB [MGT:15] を実装し なければならない (MUST)。 o もしルータがイーサネット、802.3、StarLan インタフェースをサポート するならば、イーサネット回線 MIB [MGT:6] を実装しなければならない (MUST)。 o もしルータが 802.4 インタフェースをサポートするならば、802.4 MIB [MGT:7] を実装しなければならない (MUST)。 o もしルータが 802.5 インタフェースをサポートするならば、802.5 MIB [MGT:5] を実装しなければならない (MUST)。 o もしルータが ANSI SMT 7.3 を実装する FDDI インタフェースをサポー トするならば、FDDI MIB [MGT:9] を実装しなければならない (MUST)。 o もしルータが ANSI SMT 6.2 を実装する FDDI インタフェースをサポー トするならば、FDDI MIB [MGT:29] を実装しなければならない (MUST)。 o もしルータが RS-232 や V10, V11, V35, V36, RS-422/423/449 等の V.24 信号を使用するインタフェースをサポートするならば、RS-232 MIB [MGT:10] を実装しなければならない (MUST)。 o もしルータが T1/DS1 インタフェースをサポートするならば、T1/DS1 MIB [MGT:16] を実装しなければならない (MUST)。 o もしルータが T3/DS3 インタフェースをサポートするならば、T3/DS3 MIB [MGT:17] を実装しなければならない (MUST)。 o もしルータが SMDS インタフェースをサポートするならば、SMDS インタ フェースプロトコル MIB [MGT:19] を実装しなければならない (MUST)。 o もしルータがあるインタフェースで PPP をサポートするならば、PPP MIB [MGT:11], [MGT:12], [MGT:13] を実装しなければならない (MUST)。 o もしルータが RIP バージョン 2 をサポートするならば、RIP バージョ ン 2 MIB [MGT:21] を実装しなければならない (MUST)。 o もしルータがあるインタフェース上の X.25 をサポートするならば、 X.25 MIB [MGT:22], [MGT:23], [MGT:24] を実装しなければならない (MUST)。 8.4 ベンダ特定 MIB インターネット標準と実験上の MIB は、ネットワーク要素で利用可能な統 計、状態、設定、制御の情報の全体の範囲をカバーしていない。しかし、 これらの情報は極めて有効である。ルータ (や他のネットワーク装置) の ベンダは通常、この情報をカバーする MIB 拡張を開発している。これらの MIB 拡張は、ベンダ特定 MIB と呼ばれる。 ルータのベンダ特定 MIB は、実装された標準や実験上の MIB を通じて利 用できない統計、状態、設定、制御の全ての情報へのアクセスを提供しな ければならない (MUST)。この情報は監視と制御操作の両方で利用できなけ ればならない (MUST)。 DISCUSSION この要件の意図は、コンソール等を通じて実行できる SNMP によって、 ルータ上で何かを実行する能力を提供することである。SNMP が操作で きる前に、ある最低限の量の設定が必要である (例えばルータが IP ア ドレスを持たなければならない)。この初期設定は SNMP を通じて行う ことができない。しかし、一旦初期設定を行ったら、ネットワーク管理 を通じて完全な機能を利用可能にすべきである。 ベンダは、全てのベンダ特定 MIB の規約を利用可能にすべきである (SHOULD)。これらの規約は SMI [MGT:1] に適合し、その説明は [MGT:4] で規定された形式でなければならない (MUST)。 DISCUSSION ベンダ特定 MIB をユーザに利用可能にすることは必要である。この情 報が無ければ、ユーザはベンダ特定パラメタにアクセス可能な自分達の ネットワーク管理システムを設定できないだろう。すると、これらのパ ラメタは無意味になる。 MIB 記述の形式もまた規定されている。MIB 記述を読み、ネットワーク 管理ステーションに必要なテーブルを生成する解析器もまた利用可能で ある。これらの解析器は通常、標準的な MIB 形式のみを理解する。 8.5 変更の保存 SNMP によって変更されたパラメタは、不揮発性記憶装置に保存してもよい (MAY)。 DISCUSSION この要件が MAY である理由は以下の通り。 o 不揮発性記憶装置の正確な物理特性は、このドキュメントでは規定し ない。よって、NVRAM/EEPROM、ローカルフロッピー、ハードディスク の中や、TFTP ファイルサーバや BOOTP サーバの中等にパラメタを保 存してもよい。この情報が TFTP を通じて取り込まれるファイルの中 に在るものと仮定する。その場合、ルータ上の設定パラメタに施され た変更は、設定ファイルを保持しているファイルサーバに伝達し返す 必要がある。代わりに、SNMP 操作をファイルサーバに直接仕向ける 必要があり、その後で変更をルータに伝達する必要がある。この問題 に対する答えは明白ではないようである。 これは、利用できる TFTP サーバを単に持つことに比べ、設定情報を 保持しているホストにより多くの要件を課す。ベンダが、潜在的な消 費者は利用可能な適切なホストを持つと仮定することは、あまり安全 ではない。 o 変更されたパラメタを不揮発性記憶装置に反映するタイミングは、依 然として議論の余地のある問題である。ある人は即座に全ての変更を 反映することを好む。またある人は、明示的なコマンド投入時のみ、 変更を不揮発性記憶装置に反映することを好む。 9. アプリケーション層 - 様々なプロトコル ルータが実装する全ての追加アプリケーションプロトコルに対して、ルー タは [INTRO:3] の関連要件に従わなければならず (MUST)、無条件に従う べきである (SHOULD)。 9.1 BOOTP 9.1.1 導入 ブートストラッププロトコル (BOOTP) は、起動するホストがユーザの管理 無しに自分自身を動的に設定することを可能にする、UDP/IP ベースのプロ トコルである。BOOTP は、自身に割り当てられた IP アドレス、ブートサ ーバホストの IP アドレス、メモリにロードされ実行されるファイルの名 前をホストに通知する手段を提供する ([APPL:1])。ローカルプレフィクス 長、サブネットマスク、ローカルタイムオフセット、デフォルトルータの アドレス、様々なインターネットサーバのアドレス等の他の設定情報も、 BOOTP を使用するホストに通知できる ([APPL:2])。 9.1.2 BOOTP 配送エージェント 多くの場合、BOOTP クライアントとそれに関係する BOOTP サーバは、同じ IP (サブ) ネットワーク上には存在しない。そのような場合、クライアン トとサーバ間で BOOTP メッセージを転送するために、サードパーティエー ジェントが必要である。そうしたエージェントは、元々 BOOTP 転送エージェ ントと呼ばれる。しかし、ルータの IP 転送機能との混同を避けるために、 BOOTP 配送エージェントという名前が代わりに適用される。 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. 運用と保守 このチャプタは "IP モデルの拡張" に関連する [INTRO:3] の要件に取っ て代わる。 運用と保守 (O&M) 活動をサポートする設備は、ルータ実装の本質的な部分 を形成する。これらの機能は相互運用性とは直接関連しないように見える が、ルータを相互運用しなければならず、運用できない場合に問題を追跡 しなければならないネットワーク管理者にとっては重要である。このチャ プタは、ルータの初期化やネットワークを安全で経済的にする際にネット ワーク管理者を補助する設備についての議論も含む。 10.1 導入 ルータの O&M には、以下の種類の活動が含まれる。 o ルータのプロセッサやネットワークインタフェース、接続されたネット ワーク、通信回線等のハードウェア問題を診断する。 o 新しいハードウェアをインストールする。 o 新しいソフトウェアをインストールする。 o クラッシュした後でルータを再開始、あるいは再起動する。 o ルータを設定 (あるいは再設定) する。 o 輻輳やルーティングループ、不正な IP アドレス、ブラックホール、パ ケットのなだれ現象、不正に振る舞うホスト等のインターネット問題を 検出し診断する。 o 一時的 (例えば通信回線障害をバイパスする) あるいは永続的にネット ワークトポロジを変更する o ルータや接続されたネットワークの状態やパフォーマンスを監視する。 o (内部) ネットワーク化計画で使用するために、トラフィックの統計を収 集する。 o 上記の活動を、適切なベンダや電気通信の専門家と協調する。 ルータや接続された通信回線は、集中化された 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 ルータの初期化 10.2.1 最低限のルータ設定 ルータがパケットを転送する前に満足させなければならない最低限の一連 の条件がある。ルータは以下のいずれかを満たさなければ、如何なる物理 インタフェースにも転送を可能にしてはならない (MUST NOT)。 (1) ルータは、IP アドレスと割り当てられたサブネットマスクか、物理イ ンタフェースに割り当てられた少なくとも一つの論理インタフェース のネットワークプレフィクス長を知っている。 (2) ルータはインタフェースがアンナンバードのインタフェースであるこ とを知っていて、そのルータ ID を知っている。 これらのパラメタは明示的に設定しなければならない (MUST)。 o ルータは、IP アドレスとプレフィクス長、あるいはルータ ID に対して、 工場設定のデフォルト値を使用してはならない (MUST NOT)。 o ルータは、未設定のインタフェースがアンナンバードのインタフェース であると仮定してはならない (MUST NOT)。 DISCUSSION ベンダがインタフェースに対してインストールしたデフォルトアドレス を持ってルータが出荷される実体がある。幾つかのケースにおいて、こ のことによりこれらのデフォルトアドレスが活性なネットワークに通知 される結果を招く。 10.2.2 アドレスとプレフィクスの初期化 ルータは、自身の IP アドレスとアドレスマスクかプレフィクス長を静的 に設定し、不揮発性記憶装置に保存できなければならない (MUST)。 ルータは、自身の IP アドレスとそれに対応するアドレスマスクを、シス テムの初期化処理の副作用で動的に獲得してもよい (MAY)。(セクション [10.2.3] 参照) もし動的な方法を提供するならば、特定のルータで使用する方法の選択は 設定可能でなければならない (MUST)。 セクション [4.2.2.11] で説明されているように、IP アドレスは か フィールドに 0 か -1 の値を持つこ とは許されない。従って、ルータは IP アドレスかアドレスマスクを、こ れらの上記のフィールドに 0 か -1 を持たせるような値に設定することを 可能にすべきではない (SHOULD NOT)。 DISCUSSION ルーティングが曖昧になる状況を生み出すために任意のアドレスマスク を使用することは可能である (例えば異なるが、同時に特定のサブネッ トマスクを持つ二つの経路が、ある特定の宛先アドレスに一致する)。 これはネットワークプレフィクスを使用する最も強力な論拠の一つであ り、連続していないサブネットマスクの使用を許さない理由である。 ルータはインストールするアドレスマスクに対して以下のチェックを施す べきである (SHOULD)。 o マスクは全て 1 でも全て 0 でもない (プレフィクス長は 0 でも 32 で もない)。 o アドレスのネットワークプレフィクス長に対応するビットが、全て 1 に 設定されていない。 o ネットワークプレフィクスに対応するビットが連続している。 DISCUSSION 経路に割り当てられたマスクは時々サブネットマスクと呼ばれ、このテ ストはそれらに適用されるべきではない。 10.2.3 BOOTP と TFTP を使用したネットワーク起動 どのようにルータをネットワークから起動できるか、あるいは起動すべき かについて多くの議論がある。これらの議論は BOOTP や TFTP の周辺を巻 き込んでいる。現在、ネットワークから TFTP によって起動するルータが 存在する。起動イメージがそこからロードされるべきサーバを配置するた めに BOOTP を使用できない理由はない。 BOOTP は終端システムを起動するためのプロトコルであり、ルータでの使 用に適応させるには拡張する必要がある。もしルータが BOOTP を使用する ならば、現在の起動ホストを配置するために、最初のインタフェースに対 する自分のハードウェアアドレスを持つ BOOTP 要求を、あるいはもし別途 事前に設定されているならば、BOOTP パケットのハードウェアアドレスフィ ールドに指定するための別のインタフェースのハードウェアアドレスか別 の番号を持つ BOOTP 要求を送信すべきである。これはハードウェアアドレ ス無しで (同期回線だけのルータの様に)、起動ロード検出で BOOTP の使 用を可能にするためである。その後 BOOTP 応答で検出したイメージを取り 込むために TFTP を使用することができる。もし使用するインタフェース か番号を設定していなければ、ルータは BOOTP サーバによって一致するも のが検出されるまで、インタフェースハードウェアアドレスを通じて巡回 してもよい (MAY)。 ルータは、BOOTP を通じて認識したパラメタをローカルの不揮発性記憶装 置中に格納する能力を実装すべきである (SHOULD IMPLEMENT)。ルータは、 ネットワーク上でロードされるシステムイメージをローカルの固定記憶装 置中に格納する能力を実装してもよい (MAY)。 ルータは、ルータが新しいブートイメージの取得するよう、リモートユー ザが要求することを可能にする設備を持ってもよい (MAY)。三つの場所: 要求に含まれた場所、最後に起動イメージを取得したサーバ、サーバを配 置するために BOOTP を使用、の一つから新しい起動イメージを取得するこ とを区別すべきである。 10.3 運用と保守 10.3.1 導入 O&M 機能をルータ上で実現するのに可能なモデルの範囲がある。極端なも のはローカルだけのモデルで、O&M 機能をローカルにのみ (例えば、ルー タ機器に接続された端末から) 実行できる。別の極端なものは、絶対的に 最低限なローカルに実行される機能 (起動の強制等) のみを許した完全な リモートモデルで、NOC から最もリモートに行われる O&M を持つ。NOC の 人員が、ローカルにも呼び出すことのできる機能を実行するために、telnet プロトコルを使用してホストのようにルータにログインする等の中間のモ デルがある。ローカルのみのモデルは幾つかのルータのインストールでは 適切かもしれないが、NOC からの遠隔操作が通常必要とされ、従って遠隔 O&M の準備が大半のルータに必要である。 遠隔 O&M 機能は、制御エージェント (プログラム) を通じて実施される。 直接のアプローチでは、ルータは遠隔 O&M 機能を標準的なインターネット プロトコル (SNMP や UDP、TCP 等) を使用して、NOC から直接サポートす る。直接でないアプローチでは、制御エージェントはこれらのプロトコル をサポートし、専用プロトコルを使用してルータ自身を制御する。どちら のアプローチもアクセス可能であるが、直接アプローチの方が好ましい。 重要な追加投資を必要とする専門のホストハードウェアやソフトウェアの 使用は推奨されない。それでもやはり、あるベンダはルータが一つの構成 要素であるネットワークの統合された一部として、制御エージェントの提 供を選択するかもしれない。もしこのケースであるならば、インターネッ トプロトコルとパスとローカルエージェント端末に関して同等の機能性を 使用して、遠隔サイトから制御エージェントを操作するために利用可能な 手段が必要である。 制御エージェントとベンダが提供する他の NOC ソフトウェアツールは、標 準的なオペレーションシステムでユーザプログラムとして操作することが 望ましい。ルータとの通信で標準的なインターネットプロトコル UDP と TCP を使用することは、これを容易にするはずである。 遠隔ルータ監視と (特に) 遠隔ルータ制御は、取り組まなければなければ ならない重要なアクセス制御問題をもたらす。これらの機能のためのルー タ資源の使用の制御を保証することも注意しなければならない。例えばル ータの CPU 時間の制限された配分よりも、ルータ監視により多く取らせる ことは望ましいことではない。一方、ルータが輻輳した時は大抵 O&M が最 も必要とされるケースなので、その場合は O&M 機能の役割を行使できるよ う優先させなければならない。 10.3.2 帯域外アクセス ルータは帯域外アクセス (OOB) をサポートしなければならない (MUST)。 OOB アクセスは帯域内アクセスと同じ機能を提供すべきである (SHOULD)。 このアクセスは権限外のアクセスを防ぐために、アクセス制御を実装すべ きである (SHOULD)。 DISCUSSION この帯域外アクセスは、ネットワークアクセスが使用不可の場合の間、 NOC が分離されたルータにアクセスするための方法を可能にするだろう。 帯域外アクセスは、ネットワーク管理のための重要な管理ツールである。 ネットワークコネクションに依存しない装置のアクセスを可能にする。 このアクセスを遂行する方法は数多く存在する。どれを使用するにして も、アクセスがネットワークコネクションに無依存であることは重要で ある。帯域外アクセスの例は、ルータへのダイアルアップを提供するモ デムに接続するシリアルポートである。 OOB アクセスが帯域内アクセスと同じ機能性を提供することは重要であ る。帯域内アクセス、あるいは既存のネットワークコネクションを通じ てアクセスする装置は、大半時間のために制限され、なぜ未到達かを解 決するために管理者は装置を到達させる必要がある。帯域内アクセスは、 ルータを設定するためやより微妙な問題を解析するために、依然として 非常に重要である。 10.3.2 ルータ O&M 機能 10.3.2.1 保守 - ハードウェア診断 各々のルータは、ローカルハードウェアの保守のために、スタンドアロン デバイスとして運用すべきである (SHOULD)。オンサイトツールのみを使用 して、ルータ側で診断プログラムを実行する手段が利用可能であるべきで ある (SHOULD)。ルータは、障害の場合に診断を実行できるべきである (SHOULD)。提案されたハードウェア/ソフトウェア診断については、セクショ ン [10.3.3] を参照されたい。 10.3.2.2 制御 - ダンプ採取と再起動 ルータは、ネットワーク管理者がルータをリロード、停止、再起動できる ためのメカニズムを、帯域内と帯域外の両方に含まなければならない (MUST)。ルータは、ソフトウェアかハードウェアの障害によりハングした 場合に、ルータを自動的にリロードするメカニズムも含むべきである (SHOULD)。 ルータは、ルータのメモリ (とクラッシュ後のベンダでのデバッグのため に有効な他の状態) の内容をダンプ採取するためのメカニズムと、ルータ のローカルな固定記憶装置デバイスに保存するか、TFTP 等の活性回線採取 メカニズムを通じて別のホストに保存する ([OPER:2, [INTRO:3] 参照) か のいずれかを実装すべきである (SHOULD IMPLEMENT)。 10.3.2.3 制御 - ルータの設定 全てのルータは、設定が必要かもしれない設定パラメタを持っている。ル ータを再起動せずにパラメタの更新を可能にすべきである (SHOULD)。最悪、 再開始を要求してもよい (MAY)。ルータを再起動せずにパラメタを変更す ることができない (例えば、インタフェースの IP アドレスを変更する) 場合があるかもしれない。これらの場合、ルータや周辺のネットワークの 中断を最小限にする注意を払うべきである。 手動か自動のいずれかでネットワーク上でルータを設定する方法があるべ きである (SHOULD)。ルータはホストか別のルータから、自分のパラメタを アップロードかダウンロードできるべきである (SHOULD)。パラメタ形式と 人間が編集可能な形式との間を変換する手段を、アプリケーションプログ ラムかルータの機能で提供すべきである (SHOULD)。ルータは、自身の設定 を格納する、ある種の固定記憶装置を持つべきである (SHOULD)。ルータは RAPP や ICMP アドレスマスク応答等のプロトコルを信じるべきでなく (SHOULD NOT)、BOOTP を信じなくてもよい (MAY)。 DISCUSSION 将来的に RAPP や ICMP アドレスマスク応答、BOOTP、その他のメカニ ズムは、ルータの自動設定を可能にするために必要とされるかもしれな いことを、ここに注記する必要がある。将来ルータは自動的に設定でき るかもしれないが、ここでの意図は、自動設定がより完全に試験される まで、製品環境でのこの実践を推奨しないということである。その意図 は、自動設定を全く推奨しないということではない。ルータが自身の設 定を自動的に取得することが期待される場合、それが現れた時にルータ が信じ、設定を取得した後で無視することを可能にすることは賢いだろ う。 10.3.2.4 システムソフトウェアのネット起動 ルータは自身のシステムイメージを、PROM や NVRAM 等のローカルの不 揮発性記憶装置に保持すべきである (SHOULD)。ネットワーク上でホス トや別のルータからシステムソフトウェアをロードできてもよい (MAY)。 自身のシステムイメージをローカルの不揮発性記憶装置に保持できるル ータは、ネットワーク上でシステムイメージを起動するよう設定可能で あってもよい (MAY)。このオプションを提供するルータは、ネットワー ク上でシステムイメージを起動できない場合に、不揮発性のローカル記 憶装置中のシステムイメージを起動するよう設定可能にすべきである (SHOULD)。 DISCUSSION ルータが立ち上がり、自分自身を実行できることは重要である。NVRAM は大規模ネットワークで使用されるルータにとっての特定の解決方法か もしれない。なぜなら、PROM の変更は、数多くの、あるては地理的に 散在したルータに責任を持つネットワーク管理者が極めて時間を消費す るからである。ルータがバク修正や新機能を PROM のインストールより も速く取得するための容易な方法があるべきなので、システムイメージ をネット起動できることは重要である。さらに、もしルータが PROM で はなく NVRAM を持っているならば、そのイメージをネット起動して、 その後 NVRAM に置くだろう。 ルータは、誤ったイメージを検出して恐らく保護するために、ロードさ れたイメージに対して基本的な一貫性チェックを実行すべきである (SHOULD)。 ルータは実行しているソフトウェアに基づいて、異なる設定を区別できて もよい (MAY)。もし設定コマンドが、あるソフトウェアのバージョンを別 のものに変更したら、そのソフトウェアと互換性のある設定を使用できれ ば便利である。 10.3.2.5 設定誤りの検出と応答 設定誤りを検出し、応答するメカニズムが存在しなければならない (MUST)。 もし誤ったコマンドが実行されたら、ルータはエラーメッセージを提供す べきである (SHOULD)。ルータは不完全な形式のコマンドを、あたかも正常 であるかのように受け入れるべきではない (SHOULD NOT)。 DISCUSSION エラーを検出できない場合がある。それは、コマンドは正しい形式だが ネットワークに関連して誤っている場合である。これはルータで検出し てもよいが、検出できなくともよい。 設定誤りの別の形態は、ルータが接続されているネットワークの設定誤り である。ルータは、ネットワークの設定誤りを検出してもよい (MAY)。ル ータは、これらの検出をルータかホスト上のファイルにログ採取してもよ い (MAY)。それにより、ネットワーク管理者はネットワーク上に起こり得 る問題があることが分かるだろう。 DISCUSSION こうした設定誤りの例は、問題あるか誤ったアドレスマスクを持つルー タと同じアドレスを持つ別のルータである。もしルータがこうした問題 を検出したら、ルータがその状況を修正することは恐らく最善の考えで はない。それは百害あって一利無しである。 10.3.2.6 中断の最小限化 ルータの設定変更によるネットワークへの影響は最小限にすべきである (SHOULD)。ルーティングテーブルは簡単な変更がルータに施された時、不 必要に消去すべきでない (SHOULD NOT)。もし、ルータが幾つかのルーティ ングプロトコルを実行しているならば、一つのネットワークが一つ以上の ルーティングプロトコルによって認識される場合を除いて、一つのルーティ ングプロトコルの停止により、他のルーティングプロトコルを中断すべき でない (SHOULD NOT)。 DISCUSSION ネットワークの利用者が有り得る最善の接続性を得るよう、ネットワー クを実行することがネットワーク管理の目標である。簡単な設定変更で ルータを再起動することは、ルーティングの中断を引き起こし、最終的 にネットワークとその利用者の中断を引き起こす。もしルーティングテ ーブルが不必要に消去されたら、ネットワーク内のサイトへの特定の経 路だけでなく、例えばデフォルト経路が失われるだろう。この種類の中 断は、利用者の重要な故障時間を引き起こすだろう。このセクションの 目的は、可能な場合は常にこれらの中断が回避されるべきであると指摘 することである。 10.3.2.7 制御 - トラブルシューティング問題 (1) ルータは、帯域内ネットワークアクセスを提供しなければならない (MUST) が、(セクション [8.2] の要件を除いて) セキュリティを 考慮した場合、このアクセスはデフォルトで不能にすべきである (SHOULD)。ベンダは、如何なる帯域内アクセスのデフォルト状態も ドキュメント化しなければならない (MUST)。このアクセスは、権 限外のアクセスを防ぐためにアクセス制御を実装すべきである (SHOULD)。 DISCUSSION 帯域内アクセスは基本的に、ルータの永久的な運用状態に影響を与える かもしれないし、与えないかもしれない通常のネットワークプロトコル を通じたアクセスのことを言う。これは Telnet/RLOGIN 制御アクセス や SNMP 操作を含むが、それらに限定されるわけではない。 これは、箱の外の操作と箱の分担外の安全性との間の論点であった。ル ータへの自動的なアクセスは危険性を持ち込むかもしれないが、消費者 がルータを接続したら直ぐにネットワーク上でアクセスできることは、 より重要かもしれない。少なくとも一つのベンダは外部コンソール制御 無しでルータを供給し、設定を完全にするためにネットワークを通じて ルータにアクセスできることに依存している。 帯域内アクセスがデフォルトで可能か否かはベンダ次第であるが、危険 性が伴うことを消費者に知らせることはベンダの責任でもある。 (2) ルータは ICMP エコー要求を起動する能力を提供しなければならな い (MUST)。以下のオプションを実装すべきである (SHOULD)。 o データパターンの選択 o パケットサイズの選択 o 経路記録 以下の追加オプションを実装してもよい (MAY)。 o 厳密でない送信元経路 o 厳密な送信元経路 o タイムスタンプ (3) ルータは、traceroute を起動する能力を提供すべきである (SHOULD)。もし traceroute を提供するならば、サードパーティ traceroute を実装すべきである (SHOULD)。 上記の三つの設備の各々は (もし実装するならば)、権限を持たない人によ る悪用を防ぐことを念頭において、アクセス制限を持たせるべきである (SHOULD)。 10.4 セキュリティ考慮 10.4.1 監査と証跡 監査と請求はネットワーク運用者の悩みの種であるが、ネットワークセキュ リティを担当する人や料金を支払う責任のある人に最も必要とされる二つ の機能である。セキュリティの文脈では、資源の価値以上のコストをかけ ずにネットワークの動作維持を助け、悪用から資源を保護するのであれば、 監査は望ましい。 (1) 設定変更 ルータは、たとえそれがオペレータによる起動と変更時間を記録する 程度に簡単なものであっても、ルータの設定変更に対して監査する方 法を提供すべきである (SHOULD)。 DISCUSSION 設定変更 (誰が設定変更を施し、何が何時変更されたか) のログ採取は 非常に有効である。特に、トラフィックが町を通り過ぎる際に、突然ア ラスカを通る経路になった場合に有効である。そして、以前の設定に復 帰させる機能も有効である。 (2) パケット計算 ベンダは、相手のホストやネットワーク間のトラフィックレベル を追跡するためのシステムを提供することを強く考慮すべきであ る。この情報を集めることについて、ホストやネットワークの特 定の相手に制限するメカニズムもまた、強く推奨される。 DISCUSSION 上記で説明されているホストトラフィックマトリクスは、他の統計情報 では明白でないトラフィックの傾向を、ネットワーク運用者に一見して 分からせる。接続されたネットワークの構造を厳密に調査することは、 ホストやネットワークの識別も可能にする。例えば、接続されたネット ワークのネットワークアドレスの範囲内の全ての IP アドレスにパケッ トを送信しようとする単一の外部ホストである。 (3) セキュリティ監査 ルータは、以下を含む障害や違反に関連するセキュリティを監査 する方法を提供しなければならない (MUST)。 o 認証失敗: 不正なパスワード、不正な SNMP コミュニティ、不 正な認証トークン。 o 指針制御の違反: 禁じられた送信元経路、フィルタリングされ た宛先。 o 認証の是認: 適切なパスワード - 帯域内アクセスの Telnet 、 コンソールアクセス。 ルータはそうした監査を制限し無効にする方法を提供しなければ ならない (MUST) が、デフォルトでは監査すべきである (SHOULD)。 監査で有り得る方法は、もし存るならコンソールへの違反一覧表 示、内部的なログ採取やカウント、SNMP トラップメカニズムか適 切な Unix ログ採取メカニズムを通じたリモートセキュリティサ ーバへのログ採取を含む。ルータは、これらの通知メカニズムを 少なくとも一つは実装しなければならず (MUST)、一つ以上実装し てもよい (MAY)。 10.4.2 設定制御 ベンダはルータのソフトウェア/ファームウェアのロードの生成において、 優れた設定制御の実施を用いることに責任を持つ。特に、もしベンダがイ ンターネット上での更新やロードを可能にするならば、ベンダは消費者が そのロードが正当なものであることを確認する方法、恐らくロード上で チェックサムを照合することによる、も提供すべきである。 DISCUSSION 多くのベンダは現在、ソフトウェア製品の短い更新通知をインターネッ トを通じて提供している。これは良い傾向であり、推奨されるべきであ るが、設定制御プロセスの弱点を晒すことになる。 もしベンダが消費者がルータの設定パラメタを遠隔で変更する機能、例え ば Telnet セションを通じて、を提供するならば、それを実施する機能は 設定可能であるべきであり (SHOULD)、デフォルトはオフにすべきである (SHOULD)。ルータは遠隔再設定を許可する前に、正当な認証を必要とすべ きである (SHOULD)。この認証手続きでは、認証機密をネットワーク上に送 信すべきでない (SHOULD NOT)。例えば、もし telnet が実装されるならば、 ベンダは Kerberos か S-Key、あるいはそれと同様の認証手続きを実装す べきである (SHOULD IMPLEMENT)。 DISCUSSION 適切に確認されたネットワーク運用者がルータをいじることを許可する ことは必要であり、そうでない人にそれを許可することは無謀である。 ルータは、ドキュメント化されていない裏口アクセスとマスタパスワード を持ってはならない (MUST NOT)。ベンダは製品が消費者に渡る前に、デバッ グ目的や製品開発で追加されたそうしたアクセスを削除することを保証し なければならない (MUST)。 DISCUSSION ベンダは、意図したコード中の弱点、例えば帯域内アクセス、を消費者 が知ることを保証する責任がある。意図的かあるいは意図しないトラッ プドアや裏口、マスタパスワードは、比較的安全なルータをネットワー ク運用上の主要な問題に変える。想定される運用上の利点は、潜在的な 問題により釣り合わない。 11. 参照 実装者は、インターネットプロトコル標準が時々更新されることを知るべ きである。これらの参照はこれが記述された際の現在のものだが、慎重な 実装者は RFC が更新されたか、別のものによって代わっていないことを保 証するために、RFC インデクスの最新の版を常にチェックするだろう。[ INTRO:6] の参照は、現在の RFC インデクスを入手するための様々な方法 について説明している。 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. 付録 A 送信元ルーティングホストの要件 以下に示す制約に従って、ホストは送信元経路中の中間ホップとして振る 舞い、指定された次のホップに送信元経路付きのデータグラムを転送する ことができてもよい (MAY)。 しかし、ルータに似たこの機能を実行する際、ホストは送信元経路付きの データグラムをルータが転送するための全ての適切な規則 [INTRO:2] に従 わなければならない (MUST)。これは、以下の特定の準備を含む。 (A) TTL TTL フィールドを減算し、[INTRO:2] のルータで規定されているよう にデータグラムは恐らく破棄しなければならない (MUST)。 (B) ICMP 宛先未到達 ホストは、以下のコードを持つ宛先未到達メッセージを生成できなけ ればならない (MUST)。 4 (分割が必要だが、DF が設定されている) : 送信元経路を持つデー タグラムを、ターゲットのネットワークに合わせるための分割ができ ない場合。 5 (送信元経路障害) : 例えばルーティング障害や厳密な送信元経路 の次ホップが接続されたネットワーク上に無いために、送信元経路付 きのデータグラムを転送できない場合。 (C) IP 送信元アドレス 転送しようとしている送信元経路付きのデータグラムは、転送するホ ストの IP アドレスの一つでは無い送信元アドレスを持ってもよい (通常持つだろう) (MAY)。 (D) 経路記録オプション 経路記録オプションを含む送信元経路付きのデータグラムを転送する ホストは、もし空きスペースがあるならば、そのオプションを更新し なければならない (MUST)。 (E) タイムスタンプオプション タイムスタンプオプションを含む送信元経路付きのデータグラムを転 送するホストは、このオプションの規則に従って、現在のタイムスタ ンプをそのオプションに追加しなければならない (MUST)。 送信元経路付きのデータグラムを転送するホストを制限する規則を定義す るために、次ホップがデータグラムが到着した所と同じ物理インタフェー スを通すならば、ローカル送信元ルーティング、さもなくば非ローカル送 信元ルーティングという用語を使用する。 ホストは何の制約も無く、ローカル送信元ルーティングの実行を許される。 非ローカル送信元ルーティングをサポートするホストは、転送を不可にす るための設定可能なスイッチを持たなければならず (MUST)、このスイッチ はデフォルトで不可でなければならない (MUST)。 ホストは、設定可能なポリシーフィルター [INTRO:2] の非ローカル転送を 制限する、ルータ要件全てを満たさなければならない (MUST)。 もしホストが不完全な送信元経路を持つデータグラムを受信したが、ある 理由によりそれを転送しないならば、そのデータグラム自身が ICMP エラ ーメッセージでなければ、ホストは ICMP 宛先未到達 (コード 5、送信元 経路障害) メッセージを返却すべきである (SHOULD)。 付録 B. 用語解説 この付録は、このメモで使用された特定の用語を定義する。また、興味が あるかもしれない一般目的の用語についても定義する。定義のより多くの 一般的なセットについては [INTRO:9] も参照されたい。 自律システム (AS) 自律システム (AS) は、一組の経路によって相互接続された、(接続 されたホストを持つ) サブネットワークの集まりから構成されるネッ トワークトポロジの接続されたセグメントである。サブネットワーク とルータは、単一の運用と保守 (O&M) 組織化の制御の下にあること が期待される。AS の中では、ルータは一つ以上の内部ルーティング プロトコルと、メトリックの幾つかのセットを時々使用してもよい。 AS は首尾一貫したルーティング計画の外観や、AS を通じた宛先到達 可能性の一貫した構図を、他の AS に提供することが期待される。AS は自律システム番号によって識別される。 接続されたネットワーク ルータがインタフェースするネットワークプレフィクスは、ルータの ローカルネットワークあるいはサブネットワークと大抵呼ばれる。し かし、これらの用語は混乱を招き得るので、このメモでは接続された ネットワークという用語を使用している。 接続された (サブ) ネットワーク 接続された (サブ) ネットワークはルータがインタフェースする IP サブネットワークであり、もし接続されたネットワークがサブネット 化されていなければ接続されたネットワークである。接続されたネッ トワーク参照。 データグラム インターネットモジュールのペア間で送信される単位。データグラム と呼ばれるデータは、送信元から宛先へ送信される。インターネット プロトコルは、信頼できる通信設備を提供しない。エンドツーエンド、 あるいはホップバイホップのいずれかで、受け取りの通知が無い。エ ラーが無く再送が無い。フロー制御が無い。IP 参照。 デフォルト経路 明示的にルーティングテーブルにリスト化されていないネットワーク プレフィクスにアドレス付けられたデータを向けるために使用される ルーティングテーブルエントリ。 高密度モード マルチキャスト転送では、二つのパラダイムが可能である。密集モー ドの転送では、マルチキャストルーティング隣接者によって指示され なければ、受信したところを除く全てのインタフェースに、データリ ンク層マルチキャストとしてネットワークマルチキャストが転送され る。低密度モード参照。 EGP 外部ゲートウェイプロトコル。ルーティング情報を自律システムを接 続するゲートウェイ (ルータ) に配布するプロトコル。IGP 参照。 EGP-2 外部ゲートウェイプロトコルバージョン 2。これは、インターネット 中の自律システム間のトラフィックを扱うために開発された EGP ル ーティングプロトコルである。 転送者 ルータのインタェース内でパケット交換するのに責任がある、ルータ 内の論理的なエンティティ。転送者は、ローカル配送にパケットをキュ ーイングするか、別のインタフェースに転送するためにパケットをキュ ーイングするか、その両方かの決定も行う。 転送 転送は、ルータが受信した各々のパケットを通過させる処理である。 パケットはルータによって消費されてもよく、ルータの一つ以上のイ ンタフェースへの出力であってもよく、その両方であってもよい。転 送は (可能な) 出力か内部消費のためにキューイングすることだけで なく、パケットに何をするかを決定する処理も含む。 転送情報ベース (FIB) IP データグラムを転送するために必要な情報を含むテーブルで、こ のドキュメントでは転送情報ベースと呼んでいる。最低限、これは各 々の到達可能な宛先ネットワークプレフィクスに対して、インタフェ ース識別子と次ホップ情報を含む。 フラグメント 出力ネットワーク上に全体を送信するには大きすぎる上位層のパケッ トの一部分を表す IP データグラム。 汎用シリアルインタフェース 正確に二つのシステムを接続する能力を持つ物理媒体で、従ってポイ ントツーポイント回線として設定可能であり、X.25 やフレームリレ ーといったプロトコルを使用するリンク層ネットワークをサポートこ とも設定可能である。リンク層ネットワークは別のシステムを交換機 に接続し、上位通信層はコネクション上の仮想回線を多重化する。ポ イントツーポイント回線参照。 IGP 内部ゲートウェイプロトコル。自律システム (AS) のルーティング情 報を配布する。EGP 参照。 インターフェース IP アドレス ルータの特定のインタフェースに割り当てられた IP アドレスとネッ トワークプレフィクス長。 インターネットアドレス インターネット中のホストを識別する割り当て番号。IP アドレスと プレフィクス長の二つの部分を持つ。プレフィクス長は、ネットワー クプレフィクスを構成する最も意味を持つアドレスのビット数を示す。 IP インターネットプロトコル。インターネットのネットワーク層プロト コル。それはパケット交換であり、RFC 791 で定義されたデータグラ ムプロトコルである。IP は、信頼性のある通信設備を提供しない。 すなわち、ホップバイホップのエンドツーエンドの受信確認は存在し ない。 IP データグラム IP データグラムは、インターネットプロトコルにおけるエンドツー エンドの転送の単位である。IP データグラムは、上位層のデータ (例えば TCP, UDP, ICMP 等) 全てが後続する IP ヘッダで構成され る。IP データグラムは、メッセージが後続する IP ヘッダである。 IP データグラムは IP エンドツーエンド転送単位である。 IP データグラムは一つ以上の IP フラグメントから構成される。 このメモでは、データグラムという不十分な用語は、IP データグラ ムのことを呼ぶものと解釈すべきである。 IP フラグメント IP フラグメントは IP データグラムの構成要素である。IP フラグメ ントは、元の IP データグラムの上位層の全て、あるいは一部が後続 する IP ヘッダで構成される。 一つ以上の IP フラグメントは、単一の IP データグラムを構成する。 このメモでは、フラグメントという不十分な用語は、IP フラグメン トのことを呼ぶものと解釈すべきである。 IP パケット IP データグラム、または IP フラグメント。 このメモでは、パケットという不十分な用語は、IP パケットのこと を呼ぶものと解釈すべきである。 論理 [ネットワーク] インタフェース ユニークな IP アドレスによって区別される、接続されたネットワー クへの論理パスである論理 [ネットワーク] インタフェースを定義す る。 マーチャンフィルタリング 不正な送信元か宛先アドレスを含むパケットは、マーチャンであると 見なされ破棄される。 MTU (最大転送単位) 論理インタフェースを通じて送受信可能な最大パケットサイズ。この サイズは IP ヘッダを含むが、リンク層ヘッダやフレームのサイズは 含まない。 マルチキャスト 複数のホスト宛てのパケット。ブロードキャスト参照。 マルチキャストアドレス 複数のホストが認識可能な特別なタイプのアドレス。 マルチキャストアドレスは時々、機能的アドレス、あるいはグループ アドレスと呼ばれる。 ネットワークプレフィクス 一組のシステムを示す IP アドレスの一部。論理的にサブネットマス クとアドレスとで AND をとることによって、あるいは (同等に) ア ドレスの最も意味のある <プレフィクス長> ビットの中ではないアド レスのビットを 0 に設定することによって、IP アドレスから選択さ れる。 起動する パケットは、二つの理由のうちの一つによりルータが送信できる。1) パケットが受信され、転送されようとしている。2) ルータ自身が転 送する (例えば経路通知など) ためにパケットを生成する。ルータが 転送のために生成するパケットは、ルータで起動されたといわれる。 パケット パケットは、インターネット層とリンク層との間のインタフェースを 横切って渡されるデータの単位である。それは、IP ヘッダとデータ を含む。パケットは完全な IP データグラムか、IP データグラムの フラグメントであってもよい。 パス パケットが特定のルータから特定の宛先ホストに渡る、ルータと (サ ブ) ネットワークの道筋。パスは単一方向であることに注意されたい。 所定のホストのペア間の二つの方向で異なるパスを持つことは普通で はない。 物理ネットワーク 物理ネットワークは、リンク層に隣接したネットワーク (インターネッ トの一部分) である。その内部構造は (もしあれば) インターネット 層では意識されない。 このメモでは、ブリッジやリピータ等のデバイスを使用して接続され る幾つかのメディア構成要素は、単一の物理ネットワークとして見な される。なぜなら、そのようなデバイスは IP では意識されないから である。 物理ネットワークインタフェース これは接続されたネットワークへの物理インタフェースであり、(恐 らくユニークな) リンク層アドレスを持つ。単一のルータ上にある複 数の物理ネットワークインタフェースは、同じリンク層アドレスを共 有してもよいが、同じ物理ネットワーク上にある異なるルータでは、 アドレスはユニークでなければならない。 ポイントツーポイント回線 正確に二つのシステムを接続する物理メディアケーブル。このドキュ メントでは、IP エンティティを接続するために使用するような回線 のことを呼ぶためにのみ使用する。汎用シリアルインタフェース参照。 ルータ 幾つかのネットワークを接続する特殊な目的の専用コンピュータ。ル ータは転送と呼ばれる処理において、これらのネットワーク間でパケッ トを交換する。この処理は、複数のルータによって最終宛先にパケッ トを配送できるまで、単一のパケットに対して何回か繰り返してもよ い。パケットがその宛先に到達するまで、ルータからルータへ、また ルータへ...とパケットを交換する。 RPF 逆パス転送 - ブロードキャストとマルチキャストパケットの次ホッ プを推論するために使用される方法。 黙って破棄 このメモは、ルータが受信パケット (またはデータグラム) を黙って 破棄するケースを規定している。これは、ルータが更に処理せずにパ ケットを破棄すべきであることを意味し、ルータは結果的に何の ICMP エラーメッセージ (セクション [4.3.2] 参照) も送信しないだ ろう。しかし、問題の診断のために、ルータは黙って破棄したパケッ トの内容を含む、エラーのログ採取 (セクション [1.3.3] 参照) 機 能を提供すべきであり、統計カウンタにそのイベントを記録すべきで ある。 黙って無視 ルータは、エラーログ中にあるいはネットワーク管理プロトコルを通 じてエラー通知を恐らく生成したり、破棄したり、あるいは無視する 以外に、エラーの送信元に対して何のアクションも起こさないならば、 エラーや状態を黙って無視すると言う。特に、ルータは ICMP エラー メッセージを生成しない (NOT)。 低密度モード マルチキャスト転送では、二つのパラダイムが可能である。低密度モ ードの転送では、ネットワーク層マルチキャスト転送は、それを要求 したルータとホストにデータリンク層マルチキャストフレームとして 転送される。初期転送状態は高密度モードの逆であり、データを望む ネットワークの部分は存在しないものと想定される。高密度モード参 照。 特定宛先アドレス もしヘッダが IP ブロードキャストか IP マルチキャストアドレスを 含まないならば、これは IP ヘッダ中の宛先アドレスであると定義さ れる。その場合、特定の宛先はパケットが到着した物理インタフェー スに割り当てられた IP アドレスである。 サブネット 物理的に独立したネットワークであってもよく、ネットワークの他の 部分とネットワークアドレスを共有し、サブネット番号によって区別 されるネットワークの一部。ネットワークはサブネットで構成され、 インターネットはネットワークで構成される。 サブネット番号 サブネットを明示するインターネットアドレスの一部。それはインタ ーネットルーティングでは無視されるが、イントラネットルーティン グでは使用される。 TOS サービスタイプ。トランスポート層やアプリケーションによってネッ トワーク層に望まれる、信頼性の度合いを表す IP ヘッダ中のフィー ルド。 TTL 生存時間。どのくらいの時間だけパケットが正当であると見なされる かを表す IP ヘッダ中のフィールド。これは、ホップ数とタイマ値を 兼ねる。 付録 C. 将来の方向性 この付録は、このドキュメントの将来の改訂で取り上げたい作業を一覧化 する。 ルータ要件を準備するにあたり、我々は幾つかの他の体系的な問題に突き 当たった。これらの各々は、ある程度このドキュメントで取り扱っている が、依然として IP 体系におけるオープンな問題として分類すべきである。 ここに挙げられているトピックの大半は概して、技術がまだ比較的新しく、 社会がまだ運用上の経験を十分に積んでいないため、特定の要件を作成す ることが適切でない分野を示す。 他のトピックは進行中の研究の分野を表しており、慎重な開発者が綿密に 検討するであろう分野を示す。 (1) SNMP バージョン 2 (2) 追加 SNMP MIB (7) ルーティングプロトコル間で経路を漏らすためのより詳細な要件 (8) ルーティングシステムセキュリティ (9) ルーティングプロトコルセキュリティ (10) 相互ネットワークプロトコル層セキュリティ。このドキュメントを作 成している元の作業以来、IP のセキュリティを洗練する大規模な作 業がある。このセキュリティ作業は、ここに含めるべきである。 (12) 負荷分散 (13) 異なるパスへのフラグメント送信 (15) 同じ配線上の複数の論理 (サブ) ネット。ルータ要件はこれをサポー トする必要はない。正しいことが起きるように規則の表現は慎重にし なければならない箇所で、体系の一部を識別する試み (例えば直接ブ ロードキャストの転送とリダイレクトの発行) を行っており、明確に 論理インタフェースを物理インタフェーと区別しようとしている。し かし、この問題について詳細には研究しておらず、ドキュメント中の 全ての規則が、同一配線上の複数の論理 (サブ) ネットが存在する場 合に正しいという自信はあまり無い (15) 輻輳制御と資源管理。IETF の専門家 (Mankin と Ramakrishnan) の アドバイスで、我々は送信元抑制を (SHOULD NOT) として反対し、具 体的な点は述べていない [セクション 5.3.6]。 (16) ルータとホストの両方で共通なリンク層要件のドキュメントの作成 (17) 共通的な PPP LQM アルゴリズムを開発すること (18) 物理ネットワークの MTU や IP 優先度のリンク層優先度値へのマッ ピング等、層間で渡す他の情報 (上記とセクション [3.2]) の調査 (19) もしアドレス解決が失敗したらリンク層は IP に通知すべきか (リン ク層優先度値に問題がる場合の通知も同様) ? (20) 全てのルータに DNS リゾルバの実装を要求すべきか ? (21) 人間のユーザがルータを設定する際、IP アドレスを使用できるとこ ろは常にホスト名を使用できるべきか ? たとえ、ping や traceroute であっても ? (22) 次ホップの熟慮と経路漏れの熟慮に関する Almquist のドラフトは改 訂の必要があり、近々起草され発行される。 (23) 優先度のリダイレクトメッセージが必要か否かを決定するための調査。 もし不要ならば、サービスタイプのリダイレクトを受け入れるか ? (24) RIPv2 と RIP+CIDR と可変長ネットワークプレフィクス (25) BGP-4 CIDR が重要になりつつあり、誰もが BGP-4 に賭けつつある。 我々はその観察を避けるわけにはいかない。恐らく、BGP-3 と BGP-4 との相違を記述し、更新問題を探求する必要がある。 (26) 厳密でない送信元経路モバイル IP と幾つかのマルチキャストは、こ れを必要とするかもしれない。恐らく、それは SHOULD に引きあげる べきである (Fred Baker の提案) 付録 D マルチキャストルーティングプロトコル マルチキャストは、インターネットプロトコルファミリの中で比較的新し い技術である。それはまだ広く普及しておらず、一般にはまだ使用されて いない。しかしその重要性は、年が経つに連れて増しつつある。 この付録は、インターネットを通じたルーティングマルチキャストを調査 している技術の幾つかを示している。 勤勉な実装者は、正確にマルチキャスト設備を開発するために、この分野 を並行して発展させるだろう。 この付録はいかなる標準も要件も規定しない。 D.1 導入 マルチキャストルーティングプロトコルは、TCP/IP インターネットを通じ た IP マルチキャストデータグラムの転送を可能にする。通常、これらの アルゴリズムは、送信元と宛先アドレスに基づいてデータグラムを転送す る。加えて、データグラムを複製して複数のインタフェースに送出する必 要がある度に、幾つかのマルチキャストグループメンバにデータグラムを 転送する必要がある。 マルチキャストルーティングプロトコルの状態は、IP ユニキャストの転送 で利用できるプロトコルほど発達していない。三つの実験的なマルチキャ ストルーティングプロトコルが、TCP/IP でドキュメント化されている。各 々は、マルチキャストグループメンバシップを監視するために IGMP プロ トコル (セクション [4.4] で論じられている) を使用する。 D.2 距離ベクトルマルチキャストルーティングプロトコル - DVMRP [ROUTE:9] でドキュメント化されている DVMRP は、距離ベクトルかベルマ ンフォード技術に基づいている。それはマルチキャストデータグラムのみ を振り分け、単一の自律システムの中でそれを行う。DVMRP は [ROUTE:10] で説明された、除去された逆パスブロードキャストアルゴリズムの実装で ある。加えて、それは非マルチキャストルーティング能力がある IP ドメ インを通じた、IP マルチキャストのトンネル化を規定する。 D.3 OSPF のマルチキャスト拡張 - MOSPF 現在開発中の MOSPF は、自律システムの中で IP マルチキャストとユニキャ ストの両方の転送を可能にする、OSPF の下位互換のある追加である。 MOSPF ルータは、ルーティングドメインの中で OSPF ルータと混在するこ とができ、それらはユニキャストの転送で相互運用可能だろう。OSPF はリ ンク状態、あるいは SPF ベースのプロトコルである。 グループメンバシップを正確に指し示すリンク状態通知を追加することに よって、MOSPF ルータはデータグラム送信元で振り分けられるトリーとし て、マルチキャストデータグラムのパスを算出できる。グループメンバを 含まないそれらの分岐は破棄でき、不要なデータグラム転送ホップを除去 できる。 D.4 プロトコル無依存マルチキャスト - PIM 現在開発中の PIM は、既存のユニキャスト基盤上で動作するマルチキャス トルーティングプロトコルである。PIM は密集と分散両方のグループメン バシップを提供できる。分散グループでは明示的な結合モデルを使用する ので、それぞれのプロトコルは異なっている。結合は共有トリー上で発生 し、送信元トリー毎に切り替えることができる。バンド幅が豊富でグルー プメンバシップが密集している場合、データを全てのリンクに大量に送出 し、後でグループメンバの無い例外を刈り込むことによってオーバヘッド を減少させることができる。 付録 E 追加の次ホップ選択アルゴリズム セクション [5.2.4.3] は、ルータがパケットの次ホップ選択の時に使用す べきアルゴリズムを規定している。 この付録は、次ホップ選択問題の歴史的な総体見地を提供する。さらに、 インターネットで見られる幾つかの追加の除去規則と次ホップ選択アルゴ リズムを提供する。 この付録は、Philip Almquist による以前の非公開の作業、次ホップに関 する要件からの資料の引用を提供する。 この付録は、如何なる標準や要件も規定しない。 E.1. 幾つかの歴史的な総体的見地 そのトピックの歴史を簡潔に振り返ることは有効であり、ルータがどのよ うにルーティング決定を行うかについての"クラシックモデル"と時々呼ば れるものから始まった。このモデルは IP に先行する。このモデルでは、 ルータは例えば RIP のような、ある単一のルーティングプロトコルを話す。 そのプロトコルは、ルータの転送情報ベース (FIB) の内容を完全に決定す る。ルータ検索アルゴリズムは些細なものであり、ルータは、パケットの 宛先アドレスのネットワークプレフィクス部に宛先属性が正確に一致する 経路を FIB の中に探す。もし一つ見つかったらそれを使用し、もし見つか らなかったら、その宛先は未到達である。ルーティングプロトコルは各々 の宛先に対してほとんど一つの経路を保持するので、同じ宛先に一致する 経路が複数存在する時に何をすべきかという問題が起こり得ない。 年が経つにつれて、このクラシックモデルは少しずつ拡張された。デフォ ルト経路やサブネット、ホスト経路の実装で、幾つかの意味で宛先に一致 する一つ以上のルーティングテーブルエントリを持つことが可能になった。 これは、経路の階層が存在するという意見の一致により容易に解決した。 ホスト経路はサブネッと経路よりも好まれ、サブネッと経路はネット経路 よりも好まれ、ネット経路はデフォルト経路よりも好まれるべきである。 可変長サブネットマスク (可変長ネットワークプレフィクス) をサポート する技術の実装で、その記述は少し複雑になったけれども通常のアプロー チは同じで、ネットワークプレフィクスは体系の意識的な簡略化と規則化 として導入された。我々は今、ネットワークプレフィクス経路への各経路 は、それに割り当てられたプレフィクス長を持つと言う。このプレフィク ス長はプレフィクスのビット数を示す。それは、古典的なサブネットマス クを使用して表現してもよい。もしルータのネットワークプレフィクス中 の各々意味のあるビットが、パケットの宛先アドレス中の対応するビット に一致しなければ、そのパケットを振り分けるためにその経路を使用でき ない。マスクにより多くのビットセットを持つ経路はマスクにより少ない ビットセットを持つ経路よりも好まれる。これは上記に記述されている経 路の階層の単純な一般化であり、このメモの残りでは最長照合を好むこと によって経路を選択することで参照されるだろう。 クラシックモデルが拡張されたもう一つの方法は、ルーティングプロトコ ルはルーティングテーブルの内容上で制御を完了するという考えを少し緩 和することによる。最初に静的経路が導入された。まず第一に、同時に二 つの経路 (一つは動的でもう一つは静的) を持つことが有り得る。これが 起きた時、静的経路と動的経路のどちらをより好むかについてルータはポ リシー (ある場合は設定可能で、またある場合はルータのソフトウェア作 成者によって選択される) を持たなければならない。しかし、このポリシ ーは最長照合がユニークに使用すべき経路を決定しなかった時の均衡破り としてのみ使用される。従って、例えばたとえポリシーが動的経路よりも 静的経路を望んでも、静的デフォルト経路は動的ネット経路よりも決して 好まれることはなかった。 クラシックモデルは、ドメイン間ルーティングプロトコルが発明された時、 更に拡張しなければならなかった。伝統的なルーティングプロトコルは " 内部ゲートウェイプロトコル" (IGP) と呼ばれるようになり、各々のイン ターネットサイトでは "外部ゲートウェイ" と呼ばれる一風変わった新し いものが存在し、EGP を幾つかの "BBN コアゲートウェイ" に話すルータ (当時インターネットバックボーンを形成するルータ) は、同時に IGP を そのサイトの他のルータに話した。両方のプロトコルは、ルータのルーティ ングテーブルの内容を決定することを望んだ。理論的に、これはルータに 同じ宛先への三つの経路 (EGP. IGP, 静的) を結果的に持たせた。当時の インターネットトポロジのため、それは、ルータは IGP 経路を EGP 経路 よりも好むというポリシーによることが最善であることで、ほとんど議論 されることも無く解決された。しかし、最長照合の高さが問題視されてい なかったので、IGP から学んだデフォルト経路は、EGP から学んだネット 経路よりも決して好まれることはなかった。 インターネットトポロジや必然的にインターネットにおけるルーティング は、その時からかなり発展したけれども、クラシックモデルのこのわずか な拡張バージョンは、(BGP が EGP に置き換わったことを除き) インター ネットに今日そのまま生き残っている。概念的に (しばしば実装において)、 各々のルータは一つのルーティングテーブルを持ち、一つ以上のルーティ ングプロトコルプロセスを持つ。これらのプロセスの各々は、望ましいエ ントリを追加したり、作成したエントリを削除したり修正することができ る。パケットを振り分ける時、ルータは最長照合を使用して最善経路を抽 出し、同評価から決定するためのポリシーメカニズムで補う。この拡張さ れたクラシックモデルは我々の目的にうまく適っているが、以下の数多く の欠点を持っている。 o それは、サービス品質や MTU 等のパス特性を無視する (それは考慮して 拡張できるが)。 o それは、純粋な最長照合と異なる経路検索アルゴリズムを必要とするル ーティングプロトコル (例えば OSPF や統合 IS-IS) をサポートしない。 o 同評価から決定するためのメカニズムが何であるべきかについての確固 たる意見の一致はない。例えばルータはネットワーク管理者が "適切な" 経路であると見なしたものを常に抽出するように設定することが不可能 でなければ、同評価から決定するためのメカニズムはしばしば難しいと 見なされる。 E.2. 追加の枝刈り規則 セクション [5.2.4.3] は、FIB から経路を選択するために使用する幾 つかの枝刈り規則を定義した。他にも使用できる規則は存在する。 o OSPF 経路クラス 内部と外部の領域を持つか、二者を区別するルーティングプロトコ ルは、経路を算出するために使用される情報のタイプによって、経 路をクラスに分割する。もしどれも使用可能ならば、経路は最も望 ましいクラスから常に選択され、それが使用できない場合は二番目 に望ましいクラスから選択される。OSPF では、(最も望ましい経路 から最も望ましくない経路の順番で) クラスはイントラ領域、イン ター領域、タイプ 1 外部 (外部メトリックを持つ外部経路)、タイ プ 2 外部領域である。追加案としては、ルータは何のアドレスがイ ントラ領域経路を使用してアクセス可能であるべきかを知るために 設定され、利用可能なイントラ領域経路がない場合でもこれらの宛 先に到達するためにインター領域か外部経路を使用しないだろう。 より正確には、各々の経路は route.class と呼ばれるクラス属性を 持つと仮定する。それはルーティングプロトコルによって割り当て られる。候補の経路のセットは、route.class がイントラ領域に等 しいものを含むか否かを決定するために試される。もし含まれるな らば、route.class がイントラ領域に等しい以外の経路は破棄され る。さもなくば、ルータはパケットの宛先がローカル領域として設 定されたアドレス範囲にあるか否かをチェックする。もしあるなら ば、候補の経路の全体のセットが削除される。さもなくば、候補の 経路のセットは、route.class がインター領域に等しいものを含む か否かを決定するために試される。もし含まれるならば、 route.class がインター領域に等しい以外の経路は破棄される。さ もなくば、候補の経路のセットは、route.class がタイプ 1 の外部 領域に等しいものを含むか否かを決定するために試される。もし含 まれるならば、route.class がタイプ 1 の外部領域に等しい以外の 経路は破棄される。 o IS-IS 経路クラス IS-IS 経路クラスは OSPF と同等に作用する。しかし、統合 IS-IS によって定義されたクラスの組みは異なる。IS-IS 経路クラスと OSPF 経路クラス間に一対一のマッピングは存在しない。統合 IS-IS によって使用される経路クラスは、(最も望ましい経路から最も望ま しくない経路の順番で) イントラ領域、インター領域、外部領域で ある。 統合 IS-IS 内部クラスは、OSPF 内部クラスに相当する。その上、 統合 IS-IS 外部クラスは OSPF のタイプ 2 外部クラスに相当する。 しかし、統合 IS-IS はインター領域と内部メトリックを持つ外部領 域経路を区別せず、両方ともインター領域経路と見なされる。従っ て、OSPF は内部メトリックを持つ外部経路よりも真のインター領域 経路を好み、統合 IS-IS はこの二つのタイプの経路に等しい優先度 を付与する。 o IDPR ポリシー ポリシーの特定のケース。IETF のドメイン間ポリシールーティング ワークグループは、インターネットにおける真のポリシーベースの ルーティングをサポートする、ドメイン間ポリシールーティング (IDPR) と呼ばれるルーティングプロトコルを考案している。ヘッダ 属性 (送信元と宛先アドレスの特定の結合か特殊な IDPR 送信元経 路オプション) のある結合を持つパケットは、IDPR プロトコルによっ て提供された経路を使用する必要がある。従って、他のポリシー枝 刈り規則とは違って、IDPR ポリシーは基本照合を除く他の枝刈り規 則の前に適用しなければならないだろう。 特に、IDPR ポリシーはその属性はポリシーベースの経路を使用して 転送する必要があるか否かを確かめるために転送されたパケットを 試す。もしそうならば、IDPR ポリシーは IDPR プロトコルによって 提供されていない全ての経路を削除する。 E.3 幾つかの経路検索アルゴリズム このセクションは、使用されているか提案されている幾つかの経路検索 アルゴリズムを考察する。各々、使用する枝刈り規則の順序を示すこと によって説明されている。各アルゴリズムの強度や弱度が提供されてい る。 E.3.1 改訂されたクラシックアルゴリズム 改訂されたクラシックアルゴリズムは、セクション [E.1] で論じられ た伝統的なアルゴリズムの形式である。このアルゴリズムのステップは 以下の通り。 1. 基本照合 2. 最長照合 3. 最善メトリック 4. ポリシー ある実装はポリシーのステップを省略する。というのも、経路が (異な るルーティングドメインからそれらを知ったので) 等しくないメトリッ クを持つ場合にしか必要ないからである。 このアルゴリズムの長所は、 (1) 広く実装されている。 (2) ポリシーのステップ (実装者は任意に複合して選択できる) を除い て、そのアルゴリズムは理解するのも実装するのも簡単である。 その短所は、 (1) IS-IS や OSPF 経路クラスを扱わず、そのために統合 IS-IS や OSPF を使用できない。 (2) TOS や他のパス属性を扱わない。 (3) ポリシーメカニズムはいすせれにせよ標準化されておらず、従って 大抵実装特定である。これは、実装者 (適切なポリシーメカニズム を発明しなければならない人) やユーザ (そのメカニズムの使い方 を知らなければならない人) に余分な作業を引き起こす。標準化さ れたメカニズムの欠如により、異なるベンダによるルータの一貫し た設定を形成することも難しい。これにより、マルチベンダの相互 運用性に重要な実践的相違がもたらされている。 (4) ベンダによって現在提供されている専用のポリシーメカニズムは、 インターネットの複雑な部分で不適切である。 (5) そのアルゴリズムは、一般的に利用可能なドキュメントや標準で書 かれていない。それは実際、インターネット民間伝承の一部である。 E.3.2 ルータ要件アルゴリズムの変形版 あるルータ要件ワーキンググループのメンバは、セクション [5.2.4.3] に記述されたアルゴリズムを若干変更して提案した。この変更版では、 要求されたサービスタイプの照合は、宛先アドレスの照合よりも重要で ないと見なされるのではなく、より重要であると見なされる。例えばこ のアルゴリズムは、デフォルトのサービスタイプを持つネット経路より も、正しいサービスタイプを持つデフォルト経路を好むだろう。 一方、[5.2.4.3] のアルゴリズムは、その反対の選択を行う。 このアルゴリズムのステップは、 1. 基本照合 2. 弱い TOS 3. 最長照合 4. 最善メトリック 5. ポリシー このアルゴリズムと正規のルータ要件アルゴリズムの提案者間の議論に より、そのアルゴリズムは、同様で他のアルゴリズムが行うものよりも 直観的なルーティングを導く場合を、各々のサイドが示せることを提案 している。最長照合に基づく枝刈りの前に弱い TOS に基づく枝刈りを 行うため、標準的なルータ要件アルゴリズムよりも、このアルゴリズム は OSPF や統合 IS-IS との互換性が低くなっていることを除き、この 変形版は [5.2.4.3] と同じ長所と短所を持つ。 E.3.3 OSPF アルゴリズム OSPF は、OSPF 経路クラスを考慮するという一つの決定的な相違を除い て、ルータ要件アルゴリズムと事実上等しいアルゴリズムを使用する。 このアルゴリズムは、 1. 基本照合 2. OSPF 経路クラス 3. 最長照合 4. 弱い TOS 5. 最善メトリック 6. ポリシー サービスタイプのサポートは常に存在するわけではない。もしそれが存 在しなければ、四番目のステップは無論省略される。 このアルゴリズムは、改訂されたクラシックアルゴリズムよりも幾つか の利点を持つ。 (1) サービスタイプルーティングをサポートする。 (2) その規則は、単なるインターネット民間伝承の一部ではなく実際に 書かれている。 (3) それは、OSPF と (明白に) 動作する。 しかし、このアルゴリズムは改訂されたクラシックアルゴリズムの短所 の幾つかが残ったままである。 (1) サービスタイプ以外のパス特性 (例えば MTU) は無視される。 (2) 改訂されたクラシックアルゴリズムと同様に、ポリシーステップの 詳細 (あるいは拡張さえも) は実装者の裁量に任される。 OSPF アルゴリズムは、更なる短所 (改訂されたクラシックアルゴリズ ムによって共有されていない) も持っている。OSPF 経路が宛先アドレ スと一致するビットが少ない場合でさえ、他のルーティングプロトコル から学んだ経路よりも OSPF 内部 (イントラ領域かインター領域) 経路 が常に優先であると見なす。これは、あるネットワークでは不適切なポ リシー決定である。 最後に、OSPF アルゴリズムの TOS のサポートは、0 でない TOS 値を 持つパケットを転送する時に、TOS をサポートするルーティングプロト コルが暗黙的に好まれる点で、欠陥を被ることを指摘する価値はある。 E.3.4 統合 IS-IS アルゴリズム 統合 IS-IS は、OSPF アルゴリズムと似ているが、全く同じではないアル ゴリズムを使用する。統合 IS-IS は異なる経路クラスのセットを使用し、 サービスタイプの扱いが若干異なる。このアルゴリズムは、 1. 基本照合 2. IS-IS 経路クラス 3. 最長照合 4. 弱い TOS 5. 最善メトリック 6. ポリシー 統合 IS-IS は弱い TOS を使用するが、そのプロトコルは IP ヘッダ中の TOS フィールドで有り得る値のうち、小さい特定のサブセットの経路を運 ぶ能力しか持っていない。TOS フィールド中に他の値を含んでいるパケッ トは、デフォルト TOS を使用して振り分けられる。 サービスタイプのサポートはオプションであり、もし使用不可ならば、四 番目のステップは省略される。OSPF と同様に、この規定はポリシーステッ プを含まない。 このアルゴリズムは、改訂されたクラシックアルゴリズムよりも幾つかの 長所を持つ。 (1) サービスタイプルーティングをサポートする。 (2) その規則は、単なるインターネット民間伝承の一部ではなく実際に書 かれている。 (3) それは、統合 IS-IS と (明白に) 動作する。 しかし、このアルゴリズムは改訂されたクラシックアルゴリズムの短所の 幾つかが残ったままである。 (1) サービスタイプ以外のパス特性 (例えば MTU) は無視される。 (2) 改訂されたクラシックアルゴリズムと同様に、ポリシーステップの詳 細 (あるいは拡張さえも) は実装者の裁量に任される。 (3) IS-IS 経路クラスと OSPF 経路クラス間の相違により、これは OSPF と共に動作しない。さらに、IS-IS は有り得る TOS 値のサブセットし かサポートしないため、統合 IS-IS のある明白な実装は TOS の OSPF との相互運用をサポートしないだろう。 統合 IS-IS アルゴリズムは、更なる短所 (改訂されたクラシックアルゴリ ズムによって共有されていない) も持っている。IS-IS 経路が宛先アドレ スと一致するビットが少なく、要求されたサービスタイプを提供しない場 合でさえ、他のルーティングプロトコルから学んだ経路よりも IS-IS 内部 (イントラ領域かインター領域) 経路が常に優先であると見なす。これは、 あらゆる場合に不適切であるとは限らないポリシー決定である。 最後に、IS-IS アルゴリズムの TOS のサポートは、OSPF アルゴリズムで 注記されたものと同じ欠陥を被ることを指摘する価値はある。 セキュリティの考慮 このドキュメントの焦点はセキュリティよりも相互運用にあるが、ネット ワークセキュリティに幾つか分岐する多くのセクションが、このドキュメ ントに明白に存在する。 セキュリティは様々な人々で様々なものを意味する。ルータの観点からの セキュリティは、自身のネットワーク運用を保つことを補助するものであ り、加えてインターネット全体を健全に保つことを補助するものである。 このドキュメントの目的では、関心のあるセキュリティサービスはサービ スの拒否、完全性、その二つに適用される認証である。セキュリティサー ビスのプライバシは重要であるが、ルータに関しては補助的なものでしか ない。少なくとも、このドキュメントの作成時点ではそうである。 このドキュメントの幾つかの場所で、セキュリティの考慮というタイトル が付けられている。これらのセクションは、議論中の一般的なトピックに 適用される特定の考慮について論じている。 このドキュメントは、これを行えばルータ/ネットワークが安全であるとい うことはほとんど述べていない。これを述べることは良い考えであり、そ うすればインターネットやローカルシステムの通常のセキュリティを改善 するかもしれない。 不幸にも、現在これは最高水準のものである。ルータが関心のあるネット ワークプロトコルが、効率的で組込み型のセキュリティ機能をほとんど持っ ていない。工業やプロトコル設計者は、これらの問題にずっと苦慮し続け ている。進展はあるが、BGP や OSPF ルーティングプロトコルで利用可能 なペアツーペア認証等、小さい赤子のステップでしかない。 特にこのドキュメントは、ネットワークセキュリティの開発や拡張におけ る現在の研究を注記している。この作成が進行中 (1993 年 12 月) である 研究や開発、技術の特定の分野は、IP セキュリティや SNMP セキュリティ、 共通認証技術である。 上記にもかかわらず、ルータのセキュリティを改善するためにベンダとユ ーザの両者が行うことのできるものがある。ベンダは、信頼できるコンピュ ータシステム解釈 [INTRO:8] のコピーを入手すべきである。たとえベンタ がこれらのポリシーに基づく公式の確認のためにデバイスを提供しないこ とを決定したとしても、その出版物はコンピューティングデバイスに対し て、一般的なセキュリティ設計や実践に関する優れたポリシーを提供する。 付録 F: 歴史的なルーティングプロトコル あるルーティングプロトコルはインターネットで共通であるが、このドキュ メントの作者は良心的に使用することを推奨できない。それらが正しく動 作しないからではなく、その設計 (単純ルーティング、ポリシー無し、共 通の管理の下での単一の "コアルータ" ネットワーク、複雑さの制限、ネッ トワークの規模制限) において想定されたインターネットの特徴が、今日 のインターネットの属性ではないからである。それらを依然使用している インターネットの部分は、一般的に制限された複雑性を持つ制限された " 外辺的" ドメインである。 実際の問題としては、その実装に関する冷静な思慮がこのセクションに記 録される。 F.1 外部ゲートウェイプロトコル - EGP F.1.1 導入 外部ゲートウェイプロトコル (EGP) は、同じか異なる自律システムのルー タ間で、到達性情報を交換するために使用される EGP を規定する。EGP は、 EGP 更新メッセージ中の距離フィールドにおいて標準的な解釈 (例えばメ トリック) が存在しないため、ルーティングプロトコルとはみなされない。 よって、距離は同じ AS のルータ内でしか比較できない。しかし、それは 隣接者ルータと非隣接者ルータの両方に関して、高品質な到達性情報を提 供するために設計される。 EGP は [ROUTE:6] によって定義されている。実装者は、ほぼ確実に [ROUTE:7] と [ROUTE:8] も読みたいだろう。それらは、有効な説明や背景 資料を含んでいる。 DISCUSSION 既存の EGP 規約は重大な制限があり、最も重要な制限は、ルータがル ータの自律システム内から到達可能なネットワークのみを通知すること に制限されることである。サードパーティの EGP 情報を通知すること に対するこの制限は、長期生存ルーティングループを妨げることである。 これは EGP を 2 レベルの階層に効果的に制限する。 RFC-975 は EGP 規約の一部ではなく、無視すべきである。 F.1.2 プロトコルウォークスルー 間接隣接者 : RFC-888, ページ 26 EGP の実装は間接隣接者のサポートを含まなければならない (MUST)。 間隔チェック : RFC-904, ページ 10 ハローコマンド再送間の間隔とポール再送間の間隔は設定可能にす べき (SHOULD) だが、定義された最小値が存在しなければならない (MUST)。 実装が ハローコマンドとポールコマンドに応答する間隔は、設定可 能にすべき (SHOULD) だが、定義された最小値が存在しなければな らない (MUST)。 ネットワーク到達性 : RFC-904, ページ 15 実装は、他の自律システム内のルータの外部リストを提供しないことをデ フォルトにしなければならない (MUST)。ルータを通じて到達可能なネット と一緒にルータの内部リストのみを更新応答/間接パケットに含むべきであ る。しかし、実装は外部リストの提供を可能にする設定オプションを提供 することを選択してもよい (MAY)。実装は外部リスト中に、、別の自律シ ステム中のルータによって提供された外部リストを通じて知ったルータを 含めてはならない (MUST NOT)実装は、ネットワークをそれを知った自律シ ステムに送信し戻してはならず (MUST NOT)、自律システムレベルで水平分 割しなければならない (MUST) 。 もし 255 以上の内部、あるいは 255 以上の外部ルータをネットワーク到 達性更新で指定する必要があるならば、リスト化できないルータからの到 達性更新は、リスト化されたルータの一つのリストに統合しなければなら ない (MUST)。この目的でリスト化されたルータのどれが選択されるかは、 ユーザで設定可能にすべき (SHOULD) だが、デフォルトは生成される EGP 更新の送信元アドレスにすべきである (SHOULD)。 EGP 更新はネットワーク番号の一連のブロックを含み、各ブロックは特定 のルータを通じて特定の距離で到達可能なネットワーク番号のリストを含 む。特定のルータを通じて特定の距離で到達可能なネットワーク番号が 255 個以上あるならば、それらは (全て同じ距離を持つ) 複数のブロック に分割される。同様に、特定のルータを通じて到達可能なネットワークを リスト化するのに必要なブロックが 255 個以上あるならば、更新内に全て のブロックを含めるために必要な個数分ルータのアドレスがリスト化され る。 非要請更新: RFC-904, page 16 もしネットワークが相手と共有されているならば、もし送信元ネットワー クが共有されたネットワークであれば、実装体は非要請更新をアップ状態 のエントリに送信しなければならない (MUST)。 隣接者到達性 : RFC-904, ページ 6, 13-15 j と k の値 (隣接者アップとダウンの発端) を記述している 6 ページ目 の表は誤りである。以下に正しく記述する。 Name Active Passive Description ----------------------------------------------- j 3 1 隣接者アップの発端 k 1 0 隣接者ダウンの発端 受動的モードでの k の値はさらに RFC-904 で誤って規定されている。14 ページ目の括弧内の値は、以下のように読むべきである。 (j = 1, k = 0, and T3/T1 = 4) 最適化として、実装体はポールのためのハローコマンド送信を抑制できる。 もし実装体がそうするならば、この最適化を不能にするユーザ設定オプショ ンを提供すべきである (SHOULD)。 アボートタイマ : RFC-904 ページ 6, 12, 13 EGP 実装体はアポートタイマのサポート (RFC-904 セクション 4.1.4 でド キュメント化されているように) を含まなければならない (MUST)。実装体 は、プロトコルマシンを再開するために自動的に開始イベントを発行する アイドル状態で、アポートタイマを使用すべきである (SHOULD)。推奨値は 重大エラー (管理上禁止、プロトコルエラー、パラメタ問題) については P4 で、他の全てのケースでは P5 である。アボートタイマは、停止イベン トを手動で起動した時 (例えばネットワーク管理プロを通じて) は開始す べきでない (SHOULD NOT)。 アイドル状態で受信した中止コマンド : RFC-904 ページ 13 EGP 状態マシンがアイドル状態にある時、中止コマンドに対して中止肯定 応答で返答しなければならない (MUST)。 ハローポーリングモード : RFC-904 ページ 11 EGP 実装体は、積極的と受動的ポーリングモードの両方のサポートを含ま なければならない (MUST)。 隣接者獲得メッセージ : RFC-904 ページ 18 注記したように、ハローとポール間隔は要求と確認メッセージでのみ提供 すべきである。従って、EGP 隣接者獲得メッセージの長さは要求か確認メッ セージでは 14 バイトで、拒否、中止、中止肯定メッセージでは 10 バイ トである。実装体は、拒否、中止、中止肯定メッセージで 14 バイト送信 してはならない (MUST NOT) が、これらのメッセージで 14 バイトの送信 を可能にしておかなければならない (MUST)。 シーケンス番号 : RFC-904 ページ 10 S と等しくないシーケンス番号を持って受信した応答か指示パケットは破 棄しなければならない (MUST)。送信シーケンス番号 S はポールコマンド を送信する直前に加算し、それ以外は加算しない。 F.2 ルーティング情報プロトコル - RIP F.2.1 導入 RIP は [ROUTE:3] で規定されている。RIP はインターネットで依然として 極めて重要であるが、洗練されたアプリケーションでは、上記に記述され ているようなより近代的な IGP に置き換わりつつある。RIP を実装してい るルータは、CODR 経路をサポートしているので RIP バージョン 2 [ROUTE:?] を実装すべきである (SHOULD)。予備アクセスネットワーキング を使用するならば、RIP を実装するルータは需要 RIP [ROUTE:?] を実装す べきである (SHOULD)。 RIP のもう一つの共通的な使用は、ルータ検出プロトコルである。セクショ ン [4.3.3.10] がこの主題について詳細に触れている。 F.2.2 プロトコルウォークスルー トポロジ変更の取り扱い : [ROUTE:3] ページ 11 RIP の実装体は経路をタイムアウトする手段を提供しなければならな い (MUST)。メッセージは時々消失するので、実装体は一度の更新損 ないに基づいて経路を無効にしてはならない (MUST NOT) 実装体は経路を無効にする前に、更新間隔をデフォルトで 6 回待た なければならない (MUST)。ルータは、この値を変更するための設定 オプションを持ってもよい (MAY)。 DISCUSSION RIP 自律システムにおける全てのルータが、経路を無効にするために同 じようなタイムアウト値を使用することは、ルーティングの安定性にとっ て重要である。従って、実装体が RIP 規約で規定されたタイムアウト 値をデフォルトとすることは重要である。 しかし、そのタイムアウト値は、パケット損失が相応に希な環境では保 守的過ぎる。そうした環境では、ネットワーク管理者は障害からの素早 い復旧を促進するために、タイムアウト間隔を減らせることを望むかも しれない。 IMPLEMENTATION タイムアウトになった後で即座に経路を無効にする要件を適えるために 使用してよい、非常に簡単なメカニズムが存在する。ルータが、経路が タイムアウトになったか否かをチェックするためにルーティングテーブ ルを走査する時は常に、まだタイムアウトになっていない最も以前に更 新された経路の時間にも注意する。タイムアウト間隔からこの時間を引 くと、ルータがタイムアウト経路チェックで再びテーブルの走査を必要 とするまでの時間の総計を得られる。 水平分割 : [ROUTE:3], ページ 14-15 RIP の実装体は水平分割を実装しなければならない (MUST)。水平分割とは、 更新情報中に、それを送信したルータから教わった経路を含むことによっ て引き起こされる問題を回避するために使用されるスキームである。 RIP の実装体は有毒な逆を持つ水平分割を実装すべきである (SHOULD)。有 毒な逆を持つ水平分割とは、ルータに送信する際、そのルータから教わっ た経路を含むが、そのメトリックを無限に設定することである。有毒な逆 を持つ水平分割を実装することによって被るかもしれないルーティング負 荷のため、実装体は有毒な逆を有効にするか否かを選択するオプションを 含んでもよい (MAY)。実装体は、無限メトリックで逆経路を送信する回数 を制限すべきである (SHOULD)。 IMPLEMENTATION 以下のアルゴリズムの各々は、有毒な逆を経路に適用する時間を制限す るために使用される。最初のアルゴリズムはより複雑であるが、有毒な 逆を必要な場合にのみ制限する、より緻密な仕事をする。 両方のアルゴリズムの目標は、以前の経路が同じ出力インタフェースを 使用していたことを確かめられないならば、最後の経路生存時間 (通常 180 秒) 内に経路が変わった宛先に対してのみ有毒な逆を行うことを保 証することである。経路生存時間は、RIP が古い経路を陳腐であると宣 言するまで保持する総時間なので、それが使用される。 以下のアルゴリズムで使用される時間間隔 (と派生する変数) は、次の 通り。 Tu : 更新タイマ。RIP 更新間の秒数。 これは通常デフォルトで 30 秒である。 Rl : 秒単位の経路生存時間。これ経路が適切で更新を必要としない時 間の総計。通常デフォルトで 180 秒である。 Ul : 更新損失。RIP がその経路を削除する前に、損失か失敗しなけれ ばならない連続した更新の個数。Ul は (Rl / Tu) + 1 で算出さ れる。それが起動された後、最初に ifcounter が減算される時が Tu 秒以下だろうという事実を考慮するために、+1 を行う。通常、 Ul は 7 : (180 / 30) + 1 である。 In : 新たに宛先を知った時に ifcounter に設定する値。この値は Ul - 4 であり、それは RIP のガーベジコレクションタイマ / 30 で ある 一番目のアルゴリズムは、 - 以下で ifcounter と呼ばれるカウンタに各々の宛先を割り当てる。 宛先の ifcounter が 0 より大きい経路に対して有毒な逆を行う。 - 規則的な (要求に対するトリガか応答ではない) 更新を送信した後、 0 でない全ての ifcounter を 1 減算する。 - 宛先への経路が生成された時、その ifcounter は以下のように設定 される。 - もし新しい経路が正当な経路に取って代わり、古い経路が異なる (論理的な) 出力インタフェースを使用していたならば、 ifcounter を Ul に設定する。 - もし新しい経路が陳腐な経路に取って代わり、古い経路が異なる (論理的な) 出力インタフェースを使用していたならば、 ifcounter を MAX (0, Ul - INT (経路が陳腐になっている秒数 / Ut)) に設定する。 - もしその宛先への以前の経路が存在しないならば、ifcounter を In に設定する。 - さもなくば、ifcounter を 0 に設定する。 - RIP はさらに、以下で resettimer と呼ばれるタイマも保持する。 resettimer が満了していない場合は常に (ifcounter の値に関わら ず)、全ての経路に対して有毒な逆を行う。 - RIP ば開始、再開始、リセット、ルーティングテーブルをクリアした 時に、resettimer を Rl 秒に設定する。 二番目のアルゴリズムは以下を除いて一番目と同じである。 - ifcounter を 0 でない値に設定する規則が、常に Rl / Tu に設定に 変更される。 - resettimer は削除。 トリガ更新 : [ROUTE:3], page 15-16; page 29 トリガ更新 (フラッシュ更新とも呼ばれる) は、ルータが経路を追加/ 削除した時やメトリックを変更した時に、ルータの隣接者に即座に通知 するメカニズムである。ルータは経路が削除されたか、メトリックが増 加した時、トリガ更新を送信しなければならない (MUST)。ルータは経 路が追加されたか、メトリックが減少した時、トリガ更新を送信しても よい (MAY)。 トリガ更新は極端なルーティング負荷を引き起こし得るので、実装体は トリガ更新の頻度を制限するために以下のメカニズムを使用しなければ ならない (MUST)。 (1) ルータがトリガ更新を送信する時、タイマを将来的な 1 〜 5 秒の 間のランダムな時間に設定する。このタイマが満了する前に、ルー タは追加のトリガ更新を生成してはならない。 (2) もしこの間にルータがトリガ更新を生成しようとするならば、ルー タはトリガ更新が望まれることを示すフラグを設定する。ルータは さらにトリガ更新を望んだことをログに採取する。 (3) トリガ更新タイマが満了した時、ルータはトリガ更新フラグをチェッ クする。もしフラグが設定されているならば、ルータはログに採取 された全ての変更を含む単一のトリガ更新を送信する。そして、ル ータはフラグをクリアし、トリガ更新が送信されてからこのアルゴ リズムを再開する。 (4) 規則的な更新を送信する時は常にフラグもクリアする。 トリガ更新は、最も最近規則的な (非トリガ) 更新を送信してから変更 した全ての経路を含むべきである (SHOULD)。トリガ更新は、最も最近 規則的な更新を送信してから変更されていない経路を含んではならない (MUST NOT)。 DISCUSSION 数多くのインターネットルーティングテーブルの巨大なサイズにより、 かなりの帯域をトリガ更新で浪費する結果になるので、最近変更したか 否かに関わらず全ての経路を送信することは、トリガ更新では受け入れ られない。 UDP の使用 : [ROUTE:3] ページ 18-19 IP ブロードキャストアドレスに送信される RIP パケットは、1 に設定さ れた初期 TTL を持つべきである (SHOULD)。 このメモのセクション [6.1] 従うために、ルータは起動する RIP パケッ ト中の UDP チェックサムを使用すべきであり (SHOULD)、不正な UDP チェッ クサムを持って受信された RIP パケットを破棄しなければらない (MUST) が、UDP チェックサムを含んでいないという理由だけで受信した RIP パケッ トを破棄してはならない (MUST NOT)。 アドレス付けの考慮 : [ROUTE:3] ページ 22 RIP 実装体はホスト経路をサポートすべきである (SHOULD)。もしサポート していなければ、ルータは ([ROUTE:3] のページ 27 に記述されているよ うに) 受信した更新のホスト経路を無視しなければならない (MUST)。ルー タは無視したホスト経路をログ採取してもよい (MAY)。 特別なアドレス 0.0.0.0 は、デフォルト経路を示すために使用される。デ フォルト経路は、最終手段の経路として (すなわち、特定のネットへの経 路がルーティングテーブル中に存在しない時) 使用される。ルータは、ア ドレス 0.0.0.0 の RIP エントリを生成できなければならない (MUST)。 入力処理 - 応答 : [ROUTE:3] ページ 26 更新を処理する時、以下の正当性チェックを実行しなければならない。 o 応答は UDP ポート 520 からでなければならない (MUST)。 o 送信元アドレスは、正当であるためには直接接続されたサブネット (あ るいは直接接続された非サブネット化ネットワーク) 上になければなら ない (MUST)。 o 送信元アドレスは、ルータのアドレスの一つであってはならない (MUST NOT)。 DISCUSSION 幾つかのネットワーク、媒体、インタフェースは、送信側ノードがブロ ードキャストするパケットの受信を可能にする。ルータは自身のパケッ トを正しいルーティング更新として受け入れ、それを処理してはならな い。最後の要件は、ルータが自身のルーティング更新を受け入れて処理 することを避ける (ネットワーク上の幾つかの他のルータによって送信 されるという仮定に基づいて)。 実装体は、もし受信されたメトリックが既存のメトリックと等しいならば、 以下の自発的判断に従うことを除いて、既存の経路と置き換えてはならな い (MUST NOT)。 実装体は、上記の状況を扱うために以下の自発的判断の実装を選択しても よい (MAY)。通常、もし両方とも同じメトリックで通知されるならば、あ るルータから別のルータへの経路を変更することは無駄である。しかし、 ルータの一つによって通知されている経路はタイムアウトの処理中かもし れない。その経路がタイムアウトするのを待つ代わりに、指定された時間 分経過した後、新しい経路を使用できる。もしこの自発的判断を実装する ならば、新しい経路が導入される前の満了点の少なくとも半分は待たなけ ればならない (MUST)。 F.2.3 特定の問題 RIP シャットダウン RIP の実装体は、以下のステップを使用して上品なシャットダウンを提 供すべきである (SHOULD)。 (1) 入力処理を終了 (2) 四つの更新が 2 〜 4 秒の間のランダムな間隔で生成され、これら の更新は以前にアナウンスされた全ての経路を含むが、幾つかのメ トリック変更を望む。無限のメトリックでアナウンスされている経 路は、このメトリックの使用を継続すべきである。無限でないメト リックを持ってアナウンスされている経路は、15 のメトリックを持っ てアナウンスされるべきである (無限 - 1)。 DISCUSSION 上記のために使用されるメトリックは、実際には 16 (無限) であるべ きである。15 に設定することは、RIP プロトコルを盗聴するある古い ホストの中断を避けるためのクラッジである。もしホストが宛先までの 経路を持たない (RIP が宛先までの代替パスを選択する間、たとえホス トが経路を持たない時間がほんの数秒であっても) コネクション上にデ ータグラムを送信しようとしたら、そのようなホストは、TCP コネクショ ンを (誤って) アボートするだろう。 RIP 水平分割と静的経路 水平分割は、デフォルトの静的経路に適用されるべきである (SHOULD)。実 装体は、静的経路に毎にこの経路に水平分割を適用しないことを指定する 方法を提供すべきである (SHOULD)。 F.3 ゲートウェイツーゲートウェイプロトコル - GGP ゲートウェイツーゲートウェイプロトコルは廃止されたと見なし、実装す べきでない (SHOULD NOT)。 謝辞 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 このメモは、IETF のルータ要件ワーキンググループの生産物である。この 種のメモは、必然的にここにリスト化できない程数多くの人々の作業によ るものである。多様なベンダ、ネットワーク管理者、インターネット社会 からの他の専門家が、このメモの質を改善するために時間と叡智を丁重に 寄与してくれた。作者は彼ら全てに多大な感謝を誠実に望んでいる。 現在の編者はまた、特にこのドキュメントの創始者である Philip Almquist に、心からの感謝と慰労の気持ちを申し上げたい。創始者として、 そしてワーキンググループの議長としての Philip の作業が無ければ、こ のドキュメントは作成されなかったであろう。さらに、前の編者 Frank Kastenholz に深く心からの感謝を申し述べたい。Frank は、元のドキュメ ントを情報の集合体から IP テクノロジーの役立つ説明に変更した。彼の 言葉を借りると 1991 年のテクノロジーの "スナップショット" である。 1994 年のテクノロジーのこの "スナップショット" が明確であることを望 むだけである。 Philip Almquist, Jeffrey Burgan, Frank Kastenholz, Cathy Wittbrodt の銘々は、このメモの主要なチャプタを執筆した。他にドキュメントに主 要な寄書を提供した人々は、Bill Barns, Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve Knowles, Yoni Malachi, Michael Reilly, Walt Wimer である。 追加テキストは 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 に よって提供され、他の人々によって任意にチェックされた。 このメモの幾つかのテキストは、(恥知らずに) 以前のドキュメントから盗 用している最も顕著なのは Bob Braden やホスト要件ワーキンググループ による RFC-1122 と、Bob Braden や Jon Postel による RFC-1009 である。 これらの以前の作者の作業に多大に感謝する。 Jim Forster は以前の会議の間ルータ要件ワーキンググループの協同議長 であり、適切なスタートを切るために働いてくれた。Jon Postel, Bob Braden, Walt Prue は更に、グループの最初の会議以前に豊富な適切なア ドバイスを提供することにより、成功に寄与した。その後、Phill Gross, Vint Cerf, Noel Chiappa が皆、価値あるアドバイスとサポートを提供し た。 Mike St. Johns は、ワーキンググループがセキュリティ社会と協調するこ とを調整し、Frank Kastenholz はネットワーク管理分野との協調を調整し た。Allison Mankin と K.K. Ramakrishnan は、輻輳制御と資源割り当て の問題に関する専門的知識を提供した。 ここにリスト化し記入できない程多くの人々が、ルータ要件ワーキンググ ループの審議に電子メールを通じてや、会議に出席することによって参加 した。しかし、経路選択や経路漏れの難しい問題をまとめた Ross Callon と Vince Fuller の取り組みに対しては特に感謝したい。 編者は、1994 スナップショットを執筆するのに必要な時間を費やすことを 許可してくれた、雇用者である Cisco Systems 感謝する。 編者のアドレス このドキュメントの現在の編者のアドレスは以下の通り。 Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 USA Phone:+1 805-681-0115 EMail: fred@cisco.com