|
Network Working Group Request for Comments: 1812 Obsoletes: 1716, 1009 Category: Standards Track |
Next F. Baker, Editor Cisco Systems June 1995 |
このドキュメントは、インターネット社会のためのインターネット標準トラックプロトコルを規定し、改善のための議論や提案を要求する。このプロトコルの標準化状態と状況については、「インターネット公式プロトコル標準」(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 Saving Changes
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
謝辞
編者のアドレス
このメモは 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 を注意深く読んだ後作成されたプロトコルの信頼性のある実装は、このメモの要件とわずかな点しか異ならないはずである。そうした実装を作成する際、インターネット技術社会との協調作業がしばしば必要であり、適切な通信ソフトウェアエンジニアリングの実践に従わなければならない。多くの場合、このドキュメントの要件は、既に標準プロトコルドキュメントで言及されているか含まれている。従って、それらをここに含めることは冗長である。幾つかの過去の実装が誤った選択を行っており、相互接続性やパフォーマンス、頑強性に問題がある場合は、ここに含めている。
このメモは、多くの要件や推奨についての議論と説明を含んでいる。要件を単に一覧化することは危険である。なぜなら、
しかしこのメモの規定は、インターネットの多様性や複雑性に渡って、任意のルータと相互接続を可能にする一般的な目標を適えるために従わなければならない。最近の実装は、あるものはマイナーな、またあるものはメジャーな様々な点においてこれらの要件に適合していないが、この規定は我々が向かうべき理想である。
これらの要件は、現在のインターネットアーキテクチャのレベルに基づいている。このメモは、追加説明を提供する必要がある場合や、規定が更に進歩してある範囲における追加情報が必要な場合に更新されるだろう。
このメモは、[INTRO:2] と [INTRO:3] で用いられている層構成に習っている。そして、チャプタ 2 はインターネットアーキテクチャで見られる層について説明している。チャプタ 3 はリンク層をカバーしている。チャプタ 4 と 5 は、インターネット層プロトコルと転送アルゴリズムに関係している。チャプタ 6 はトランスポート層をカバーしている。上位層プロトコルは、チャプタ 7,8,9 に区分けされている。チャプタ 7 は、ルータがお互いに経路情報を交換するのに使用するプロトコルについて論じている。チャプタ 8 はネットワーク管理について論じている。チャプタ 9 は、他の上位層プロトコルについて論じている。最後のチャプタは、操作や保守の特徴をカバーしている。この構成は、単純かつ明確で、ホスト要件の RFC と一貫性を持たせるために選択された。このメモの付録は、参考図書、用語、ルータの標準の将来の方向性についての推測を含んでいる。
要件を記述する際、我々は実装体がプロトコルの層分けを厳密に反映していると仮定する。しかし厳密な層分けは、プロトコルスイートや推奨された実装アプローチの両方にとって不完全なモデルである。異なる層のプロトコルは複雑に、時には微妙な方法で相互作用し、ある特定の機能はしばしば複数の層を巻きこんでいる。実装における設計の選択肢は数多く存在し、それらの多くは厳密な層分けの創造的な破壊を伴っている。全ての実装者は、[INTRO:4] と [INTRO:5] を読むことが推奨される。
このメモの各々の主要なセクションは、以下のサブセクションから構成される。
このメモの数多くの個々のトピックの下に、DISCUSSION や IMPLEMENTATION という記述で示された挿入文がある。この文は前述の要件のテキストを正当化、明確化、説明することを意図している。実装の挿入文は、実装者が考慮したいかもしれない提案されたアプローチを含んでいる。DISCUSSION と IMPLEMENTATION のセクションは、この標準の一部ではない。
このメモでは、各々の特定の要件の重要性を定義するために使用する単語は大文字で記述される。これらの単語は、
MUST
この単語は、その項目がこの規定の絶対的な要件であることを意味する。この要件に反することは重大なエラーであり、正当化されるケースは存在しない。
MUST IMPLEMENT
このフレーズは、この規定ではその項目が実装される必要があることを意味するが、デフォルトで使用可能にする必要はない。
MUST NOT
このフレーズは、その項目がこの規定の絶対的な禁止であることを意味する。
SHOULD
この単語は、ある事情においてこの項目を無視する正当な理由が存在してもよいことを意味する。しかし、完全な実装が理解され、異なる方向を選択する前に注意深く熟慮しなければならない。
SHOULD IMPLEMENT
このフレーズは SHOULD
の意味と同様であるが、ある特徴を提供することは推奨するが、デフォルトで使用可能とすることを推奨してはいない時に使用される。
SHOULD NOT
このフレーズは、規定された振る舞いは受諾可能または有効であるような事情で正当な理由が存在してもよいことを意味する。たとえそうであっても、完全な実装を理解し、この記述で説明された振る舞いを実装する前に注意深く熟慮しなければならない。
MAY
この単語は、この項目は全く任意であることを意味する。あるベンダは特定の市場で必要だからその項目を含む、あるいは製品を拡張することを選択するかもしれないし、またあるベンダは同じ項目を省略するかもしれない。
ある幾つかの要件は、全てのルータにあてはまる。また別の要件は、特定の機能かプロトコルを実装する場合にのみあてはまる。以下のパラグラフでは、関連する内容は、全てのルータにあてはまる要件と、一組の機能やプロトコルを実装したことによる特定のルータにあてはまる一組の要件と合わせて適用される。
全ての関連要件が直接このメモで述べられているとは限らない。このメモの様々な部分は、ホスト要件規定 [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 の世界でいうプロファイルに近いものである。例えば、このメモは数多くのプロトコルが実装されることを要求している。それらのプロトコル規定の大半の内容はこのメモでは繰り返さないが、実装者はそれでもなお、それらの規定に従ってプロトコルを実装することを求められる。
プロトコル規定と標準の状態をチェックするための幾つかの参照ドキュメントが存在する。
INTERNET OFFICIAL PROTOCOL STANDARDS
このドキュメントはインターネット標準プロセスを記述し、プロトコルの状態を一覧化している。このメモが作成された時は、このドキュメントの現在のバージョンは
STD 1, RFC1780 [ARCH:7]
である。このドキュメントは定期的に再発行されている。RFC
の保管場所を常に調べ、このドキュメントの最新の版を使用すべきである。
Assigned Numbers
このドキュメントは、様々なプロトコルで使用されるパラメタの値割当てをリスト化している。例えば、IP
プロトコルのコードや TCP のポート番号、Telnet のオプションコード、ARP
のハードウェアタイプ名がある。このメモが作成された時は、このドキュメントの現在のバージョンは
STD 2, RFC1700 [INTRO:7]
である。このドキュメントは定期的に再発行されている。RFC
の保管場所を常に調べ、このドキュメントの最新の版を使用すべきである。
Host Requirements
この一組のドキュメントはホストに適用する規定をレビューし、指針や曖昧部分の説明を提供している。これらの要件はこのメモで規定されたもの以外を除いて、ルータにも適用される。このメモが作成された時、このドキュメントの現在のバージョンは
RFC1122 と RFC1123 (STD 3) [INTRO:2] と [INTRO:3] である。
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/
インターネットソフトウェアのベンダが知っておくべき、また新たなベンダが深慮すべき幾つかの重要な教訓がある。
インターネットの莫大な成長は、大きなデータグラムパケット通信システムにおける管理や規模の問題を表面化させた。これらは問題として位置づけられ、結果的にこのメモで規定されている規約は、進化し続けるだろう。新しいルーティングプロトコル、アルゴリズム、アーキテクチャは、永続的に進化する。新しいインターネット層プロトコルや既存のプロトコルの更新によってもまた、永続的に改訂されていくだろう。ルータは、インターネットにおいて重要な役割を持ち、インターネットで開発されたルータの数はホストの数よりもずっと少ない。従って、ベンダはルータの標準はホストの標準よりもずっと早く進化し続けていくと予期すべきである。ベンダやネットワークの取り扱いに責任のある組織によるこの計画には、多数の参加者がいるので、これらの変更は慎重に計画され管理されるだろう。
発展、進化、改訂は今日のコンピュータネットワークプロトコルの特徴であり、こうした状態は数年続くだろう。インターネットプロトコルスイート (あるいは他のいかなるプロトコルスイートも!) のためのコンピュータ通信ソフトウェアを開発し、変更される規約に対してソフトウェアを保守、更新することができないベンダは、不幸な消費者を残して去ってしまうかもしれない。インターネットは大規模な通信ネットワークであり、ユーザは絶え間無くインターネットを通じて交信する。経験的に、ベンダソフトウェアの欠陥に関する情報はインターネット技術社会を通じて即座に広がるようだ。
プロトコルの全ての層において、アプリケーションが頑強性と相互接続性に莫大な利益をもたらす一般的な規則が存在する (Jon Postel の [TRANS:2] より)。
自ら行うことには保守的であれ、
他から受けることには革新的であれ。
ソフトウェアは、たとえ起こりそうに無くても、考えられる全ての異常を扱うよう記述すべきである。結局、パケットは異常や属性の特定のコンビネーションで入ってくる。もしソフトウェアがそれに対して準備されていなければ、混沌が起こり得る。ネットワークは、最悪の事象を起こすよう設計されたパケットを送信する、悪意を持ったエンティティで満ちていると仮定することが最善である。この仮定は適切な防御設計につながるだろう。インターネットにおける最も重大な問題は、人間の悪意ですらそんな遠回りな道筋を辿らないような起きそうにもないイベントがトリガとなる、不測のメカニズムによって引き起こされるものである！
変更への順応性は、ルータソフトウェアの全てのレベルで設計しなければならない。簡単な例として、例えばタイプフィールドやポート番号、エラーコードといった特定のヘッダフィールドの列挙値を含むプロトコル規定を考える場合、この列挙は不完全であると仮定しなければならない。もしプロトコル規定が四つのあり得るエラーコードを定義しているならば、ソフトウェアは五つ目のコードが定義されたときに壊れてはならない。未定義のコードはログに採取してもよいが、失敗の要因になってはならない。
指針の二番目の部分も同様に重要である。ホストや他のルータ上のソフトウェアは、正しいが曖昧なプロトコル機能を利用することを不得策にする欠陥を含んでいるかもしれない。厄介な事象が別の場所に生じないよう、明確さや簡潔さからかけ離れて脱線するのは賢明ではない。この結果は誤動作するホストを警戒することであり、ルータソフトウェアは誤動作するホストが存在する中で生き残る準備をしておくべきである。インターネットにおけるルータの重要な機能は、そうしたホストが共有された通信設備に及ぼす混乱の量を制限することである。
インターネットは様々なシステムを含み、各々が多くのプロトコルやプロトコル層を実装している。これらの幾つかは、インターネットプロトコルソフトウェア中にバグや誤った機能を含んでいる。複雑さや多様性、機能の分散の結果、問題の診断は大抵非常に困難である。
もしルータが異常や奇妙なイベントのログを採取するために慎重に設計された機能を含んでいれば、問題の診断は助けになるだろう。エラーのログを採取する際、できる限り多くの診断情報を含むことは重要である。特に、エラーを引き起こしたパケットのヘッダを記録することはしばしば有効である。しかし、エラーログの採取により、極端に高価な量の資源を消費しないことや、ルータの処理を妨げないことを保証するよう注意しなければならない。
異常だが無害なプロトコルイベントが、エラーのログファイルを溢れさせる傾向がある。これは循環ログを使用するか、既知の障害を診断する場合にしかログ採取を有効にしないことによって回避できる。重複した成功メッセージをフィルターにかけたり、数えたりすることは有効かもしれない。上手く作用しそうな戦略は、以下の両方である。
このトピックは、さらに [MGT:5] で論じている。
理想的な世界では、ルータは設定が容易で、恐らく完全に自動設定さえ行われるだろう。しかし、現実世界の実際の経験では、これが不可能な目標であることを示唆しており、設定を容易にしようとするベンダの試みは、実際には消費者の悲嘆を防ぐよりはむしろ助長させている。極端な例を挙げれば、設定情報を全く必要とせずに起動され開始するよう設計されたルータは、ほぼ確実に幾つかの誤ったパラメタを選択し、恐らくそれを接続するのに不適切なネットワーク上で重大な問題を引き起こしている。
しばしばこのメモは、パラメタが設定可能なオプションであることを要求する。これには幾つかの理由がある。あるケースでは、最適値について不確かで同意されていないことが現在存在し、将来推奨値を更新する必要があるかもしれない。また他のケースでは、値は実際には外的要因、例えば通信負荷の分散や隣接ネットワークの速度やトポロジに依存し、自己チューニングアルゴリズムが利用できなかったり、不十分でありえる。あるケースでは、管理上の要件のために設定可能である必要がある。
最後に、ある設定オプションは、インターネットの多くの部分でまだ使用されている、ソース無しで配布された、時代遅れや正しくないプロトコル実装と通信するために必要である。正しいシステムをこれらの欠陥システムと共存させるために、管理者は時折、正しいシステムに誤りを含む設定をしなければならない。この問題は、欠陥システムが撤廃されるにつれて徐々に正されるだろうが、ベンダは無視できない。
パラメタが設定可能であると宣言する場合は、その値を明示的に設定ファイルから、ブート時に毎回読み込む必要があることを意図していない。多くのパラメタにとって、最も一般的でない状況を除き、適切な一つの値が存在する。そのような場合、もし明示的に設定されていなければ、その値をパラメタのデフォルト値とすることは極めて効率的である。
このメモは、あるケースでそうしたデフォルトのための特定の値を要求する。設定項目が既存の欠陥システムへの適応を制御する場合、デフォルトの選択は繊細な問題である。もしインターネットが相互接続性を完遂する方向に収束するならば、実装体に作り込まれたデフォルト値は、欠陥実装に適応するための誤った設定ではなく、公式的なプロトコルを実装しなければならない。商用を考慮すると、ベンダは誤った設定のデォルト値を選択したいかもしれないが、我々はベンダが標準に適合したデフォルト値を選択することを強く推奨する。
最後に、ベンダは全ての設定パラメタの制限や効果について、十分なドキュメントを提供する必要があることに注意されたい。
このメモの幾つかの場所で、ルータが従うべき特定のアルゴリズムが規定されている。これらのアルゴリズムはルータの要件ではない。ルータは、このメモに書かれてある各々のアルゴリズムを実装する必要は無い。むしろ実装体は、厳密的で文字通りの、規定されたアルゴリズムの実装と同じ動作を外部世界に提供しなければならない。
アルゴリズムは、優れた実装体が実装するのとは異なる方法で規定されている。解説目的のために、簡潔さや明確さ、実装の詳細に依存しないことを強調したスタイルが選択されている。優れた実装体は、これらのアルゴリズムと同じ結果を生み出すが、より効率的であったり、一般的でないアルゴリズムや実装方法を選択する。
効率的なルータの実装技術は、このメモの適用外であることに注意されたい。
このチャプタは、如何なる要件も含まない。しかし、インターネットとルータの一般的なアーキテクチャについての有効な背景情報を含む。
インターネットアーキテクチャとサポートするプロトコルスイートの一般背景や議論は、DDN プロトコルハンドブック [ARCH:1] に見ることができる。背景については、例えば [ARCH:2], [ARCH:3], [ARCH:4] を参照されたい。インターネットアーキテクチャとプロトコルは、例えば [ARCH:5], [ARCH:6] といった、絶えず増え続けているテキストブックでカバーされている。
インターネットシステムは、インターネットプロトコルを使用したホストコンピュータ間の通信をサポートしている、数多くの相互接続パケットネットワークから構成されている。これらのプロトコルは、インターネットプロトコル (IP)、インターネット制御メッセージプロトコル (ICMP)、インターネットグループ管理プロトコル (IGMP)、これらと独立した多様なトランスポートやアプリケーションプロトコルである。セクション [1],[2] に記述されているように、インターネット技術運営グループは、全てのインターネットプロトコルを一覧化している公式プロトコルのメモを定期的に発行している。
全てのインターネットプロトコルは、基本データ転送メカニズムとしてIPを使用する。IP はデータグラムで、コネクションレスの相互ネットワークサービスであり、アドレス付けやサービスタイプ指定、分割、組立、セキュリティを含む。ICMP と IGMP はアーキテクチャ上は IP 上に位置するが、IP の一部として必要な部分と見なされる。ICMP は、エラー通知、フロー制御、第一ホップルータリダイレクション、その他の保守や管理機能を提供する。IGMP は、ホストとルータが IP マルチキャストグループに加入したり、離脱するためのメカニズムを提供する。
信頼性のあるデータ配送は、インターネットプロトコルスイートでは、エンドツーエンドの再送、再順序付け、コネクション制御を提供する転送制御プロトコル (TCP) 等のトランスポート層プロトコルによって提供される。トランスポート層のコネクションレスサービスは、ユーザデータグラムプロトコル (UDP) によって提供される。
インターネットシステムを使用して通信するために、ホストはインターネットプロトコルスイートを構成するプロトコルの層に分けられたセットを実装しなければならない。ホストは一般に、各々の層に対して少なくとも一つのプロトコルを実装しなければならない。
インターネットアーキテクチャで使用されるプロトコルの層は以下の通り [ARCH:7]。
アプリケーション層
アプリケーション層は、インターネットプロトコルスイートの最上位層である。幾つかのアプリケーション層プロトコルが内部に存在するが、インターネットスイートはアプリケーション層を更に分割しない。インターネットスイートは、OSI
参照モデル [ARCH:8] の上位の二つの層 - プレゼンテーションとアプリケーション -
の機能を本質的に結合している。インターネットプロトコルスイートのアプリケーション層は、OSI
参照モデルのセション層に属する幾つかの機能も含む。
我々は、アプリケーション層プロトコルの二つのカテゴリを区別する。それは、直接ユーザにサービスを提供するユーザプロトコルと、共通のシステム機能を提供するサポートプロトコルである。最も一般的なインターネットユーザプロトコルは、
- Telnet (リモートログイン)
- FTP (ファイル転送)
- SMTP (電子メール配送)
他の標準化されたユーザプロトコルや私的ユーザプロトコルは、数多く存在する。
ホスト名のマッピング、ブート、管理で使用されるサポートプロトコルは、SNMP,BOOTP,TFTP,ドメイン名システム (DNS) プロトコル、様々なルーティングプロトコルを含む。
ルータに関係するアプリケーション層プロトコルは、このメモのチャプタ 7,8,9 で論じられている。
トランスポート層
トランスポート層は、エンドツーエンドの通信サービスを提供する。この層は、OSI 参照モデルのトランスポート層におおよそ等しいが、OSI トランスポート層は
OSI のセション層の確立/破棄機能の幾つかとも協調している点は除く。
現状、二つの主要なトランスポート層プロトコルが存在する。
- 転送制御プロトコル (TCP)
- ユーザデータグラムプロトコル (UDP)
TCP は、エンドツーエンドの信頼性、再順序付け、フロー制御を提供する、信頼性のあるコネクション型トランスポートサービスである。UDP は、コネクションレス(データグラム)のトランスポートサービスである。その他のトランスポートプロトコルは研究団体によって開発されており、公式インターネットプロトコルのセットは、将来拡張されるかもしれない。
ルータに関係するトランスポート層プロトコルは、チャプタ 6 で論じられる。
インターネット層
全てのインターネットトランスポート層プロトコルは、送信元ホストから宛先ホストにデータを運ぶためにインターネットプロトコル
(IP) を使用する。IP はコネクションレスまたはデータグラムの相互ネットワークサービスであり、エンドツーエンドの配送の保証は提供しない。IP
データグラムは、破損したり、重複したり、順序通りで無く宛先ホストに到着するかもしれないし、あるいは全く到着しないかもしれない。IP
上の層は、必要であれば、信頼できるサービスを提供する責任がある。IP プロトコルはアドレス付けの提供、サービスタイプの指定、分割、組立、セキュリティを含む。
IP のデータグラムでコネクションレスの特性は、インターネットアーキテクチャの基礎であり、特徴的な性質である。
インターネット制御メッセージプロトコル (ICMP) は、アーキテクチャ上は IP の上に位置し、データをエンドツーエンドに運ぶために IP を使用するが、IP の一部として必要な部分と見なされる制御プロトコルである。ICMP は、エラー通知、輻輳通知、第一ホップルータリダイレクションを提供する。
インターネットグループ管理プロトコル (IGMP) は、IP マルチキャストの動的なホストグループを確立するために使用されるインターネット層プロトコルである。
インターネット層プロトコルの IP,ICMP,IGMP は、チャプタ 4 で論じられる。
リンク層
直接接続されたネットワーク上で通信するために、ホストはそのネットワークにインタフェースするために使用される通信プロトコルを実装しなければならない。我々はこれをリンク層プロトコルと呼ぶ。
幾つかの古いインターネットドキュメントは、この層をネットワーク層と呼んでいるが、OSI 参照モデルのネットワーク層と同じではない。
この層はインターネット層の下で、物理層 (媒体接続、通常電気的か光学的、メッセージを符号化して転送する) の上の全てを含む。その責任は、メッセージの正しい配送であり、その中では区別は無い。
この層のプロトコルは通常、インターネット標準化の範囲外であり、インターネットは (意図的に) 可能であれば必ず既存の標準を使用する。従って、インターネットリンク層標準は大抵、アドレス解決や特定のリンク層プロトコル上で IP パケットを運ぶための規則のみ扱っている。インターネット層標準は、チャプタ 3 で論じられている。
インターネットシステムのネットワーク構成要素は、パケット (コネクションレス) 転送を提供する必要があるだけである。IP サービス規定に従い、データグラムの送信は順序通りでない、損失または重複、エラーが含まれる可能性がある。
IP を使用するプロトコル (例えば TCP) の効率的なパフォーマンスのために、ネットワークの損失割合は非常に低くあるべきである。コネクション型サービスを提供するネットワークでは、仮想回線によって提供される余分な信頼性はエンド/エンドのシステムの頑強性を高めるが、インターネット処理では必要ない。
ネットワーク構成要素は通常、二つのクラスに分割される。
ローカルエリアネットワーク (LAN)
LAN は多様な設計を持つ。LAN は通常、地理上の小規模なエリア
(例えば一つのビルや工場) をカバーし、遅延の少ない高帯域を提供する。LAN は受動的 (イーサネットと同様) かもしれないし、能動的 (例えば ATM) かもしれない。
ワイドエリアネットワーク (WAN)
地理的に散在したホストや LAN
はワイドエリアネットワークによって相互接続され、遠距離転送ネットワークとも呼ばれる。これらのネットワークは回線/パケット交換の複雑な内部構造を持つか、あるいはポイントツーポイントと同じ位単純かもしれない。
インターネットモデルでは、ネットワーク構成要素はルータ又は IP ルータと呼ばれる IP データグラムの転送によって相互に接続される。このドキュメントでは、ルータという用語は全て、IP ルータに相当する。多くの古いインターネットドキュメントは、ルータをゲートウェイと呼んでいる。
歴史的に、ルータは汎用的な CPU 上で実行されるパケット交換ソフトウェアで実現されてきた。しかし、カスタムハードウェア開発が安価になり、より高いスループットが求められるようになったので、専用的なハードウェアがますます一般的になりつつある。この規約は、ルータがどのような実装であるかに関わらず適用される。
ルータは、IP サブネットやアンナンバードのポイントツーポイント回線 (セクション [2.2.7] で論じられる) によって表わされる、二つ以上の論理的なインタフェースに接続する。従って、ルータは少なくとも一つの物理インタフェースを持っている。IP データグラムの転送では通常、ルータは次ホップのルータか、(最終ホップとして) 宛先ホストに関連するアドレスとインタフェースを選択する必要がある。この選択は、ルータ内部の経路データベースに依存したリレー、または転送と呼ばれる。経路データベースはルーティングテーブル、または転送テーブルとも呼ばれる。"ルータ" という用語は、この経路データベースを生成するプロセス、つまりルーティングプロトコルやルーティングと呼ばれるプロセスにおける設定動作に由来する。
ルーティングデータベースは、インターネットシステムの現在のトポロジを反映するために動的に維持されるべきである。ルータは通常、他のルータとの分散ルーティング、到達性アルゴリズムに参加することによってこれを実現する。
ルータはデータグラム転送のみを提供し、ルーティングの融通性や頑強性のために、このサービスを支えるのに必要な状態情報を最小化することが求められる。
パケット交換デバイスはまたリンク層で処理してもよく、そのようなデバイスは通常ブリッジと呼ばれる。ブリッジによって接続されたネットワークセグメントは、単一の IP サブネットを形成する同じ IP ネットワークプレフィクスを共有する。これらの他のデバイスは、このドキュメントの適用外である。
自律システム (AS: Autonomous System) はネットワークトポロジの接続されたセグメントであり、一組の経路によって相互接続されたサブネットワーク (と所属するホスト) の集合体で構成される。サブネットワークとルータは、単一の運用と保守 (O&M: operations and maintenance) 組織の管理下にあることが予想される。AS の中では、ルータは一つ以上の内部ルーティングプロトコルを使用してよく、時にはメトリックの複数の組みを使用してもよい。AS は、内部ルーティング計画の明確な外観と、AS を通じて到達可能な宛先の一貫した構図を他の AS に提供することが期待される。AS は、自律システム番号によって識別される。
AS の概念は、インターネットルーティングにおいて重要な役割を演じる (セクション 7.1参照)。
IP データグラムは32ビットの送信元/宛先アドレスを運び、その各々は二つの部分 - ネットワークプレフィクスとそのネットワーク上のホスト番号の構成要素 - に区切られる。記号では、
IP-address ::= { <Network-prefix>, <Host-number> }
最後にデータグラムを配送するために、そのパスの最後のルータは、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] で説明されているサブネット拡張は、インターネットアーキテクチャの必要な部分である。その基本的な考え方は、<Host-number> フィールドを二つの部分、サブネット番号とサブネット上の真のホスト番号に区切ることである。
IP-address ::= { <Network-number>, <Subnet-number>, <Host-number> }
組織内の相互接続された物理ネットワークは同じネットワークプレフィクスを持つが、サブネット番号は異なる。サブネット化されたネットワークのサブネット間の区別は、通常そのネットワークの外側には見えない。従って、インターネットの残りのルーティングは、IP 宛先アドレスの <Network-prefix> 部のみを使用する。ネットワークの外側のルータは、<Network-prefix> と <Host-number> の両方を、32 ビット IP アドレスの解釈されていない残りの部分として扱う。サブネット化されたネットワーク内では、ルータは以下の拡張されたネットワークプレフィクスを使用する。
{ <Network-number>, <Subnet-number> }
この拡張ネットワーク部を含んでいるビット位置は、歴史的にサブネットマスクと呼ばれる 32 ビットマスクによって識別されてきた。<Subnet-number> ビットは、<Network-number> と <Host-number> フィールドの間に連続して存在すべきである (SHOULD)。より最近のプロトコルはサブネットマスクとは呼ばず、プレフィクス長と呼んでいる。アドレスの "プレフィクス" 部は、上位ビットが全て 1 で残りが 0 のサブネットマスクによって選択されるものである。プレフィクスの長さは、サブネットマスクの 1 の個数に等しい。このドキュメントは、全てのサブネットマスクがプレフィクス長で表現可能であると仮定している。
サブネットメカニズムの発明者は、組織のネットワークの各々の部分が一つのサブネット番号しか持たないと仮定していた。実際は、複数のサブネットに一つの物理ケーブルを共有させることが必要であり、有効であることが判明している。そのため、ルータは同一の物理インタフェース上で、複数のサブネットを構成できるべきであり、(ルーティングや転送の見地から) あたかも別の物理インタフェースであるかのようにそれらを扱うべきである。
インターネットの爆発的な成長により、アドレス割当て方法の見直しを余儀なくされた。IP の 32 ビットアドレス空間をより効率的に利用できるようにするために、汎用 (クラス A, B, C) ネットワークの伝統的な使用方法が修正された。クラスレスドメイン間ルーティング (CIDR: Classless Inter Domain Routing) [INTERNET:15] は、この付加効率の目的を達成するために、現在インターネットバックボーンで展開中の方法である。CIDR は任意の大きさのネットワークへの展開とルーティングに依存する。このモデルでは、ホストとルータはインターネットのアドレスの付け方について何も仮定しない。クラス D (IP マルチキャスト) とクラス E (実験) アドレス空間については、本来は割当て方法であるが、変更無く残されている。
定義によると、CIDR は三つの要素から構成される。
ネットワークとサブネットを使うことは、それらを記述するために使用される言語は現在使われ続けてはいるが、今や過去のものである。それらは、より扱いやすいネットワークプレフィクスの概念に置き換えられつつある。定義によると、ネットワークプレフィクスは、一組のシステムを定義するアドレスの上端のビットの連続したセットであり、ホスト番号はそれらのシステムの中から選択される。インターネット全体がネットワークプレフィクスを統一的に使用する要件はない。ルーティング情報を崩すために、インターネットをアドレスの付いたドメインに分割することは有効である。そのようなドメインの中ではネットワーク構成についての詳細な情報が取得でき、その外側には共通のネットワークプレフィクスしか通知されない。
旧来の IP アドレス体系は、ホスト番号とネットワークプレフィクスを区別するためにアドレスとサブネットマスクを使用した。ネットワークプレフィクスでは、プレフィクス中のビット数を示すだけで十分である。両方の表現は共通して使用される。体系的に正しいサブネットマスクは、プレフィクス長の記述を使用した表現が可能である。それらは、以下のあり得るビットパターン全てのサブセットを構成する。
ルータは経路を常にネットワークプレフィクスとして扱うべきであり (SHOULD)、そのモデルに矛盾する設定やルーティング情報を拒否すべきである (SHOULD)。
IP-address ::= { <Network-prefix>, <Host-number> }
CIDR を使用することの影響は、ルーティングテーブルの中でアドレスプレフィクスと結び付けられた一組の宛先は、サブセットの関係を示すかもしれないことである。より小さな宛先の組 (プレフィクスが長い) を示す経路は、より大きな宛先の組 (プレフィクスが短い) を示す経路よりも特定的であると言われる。同様に、より大きい宛先の組 (プレフィクスが短い) を示す経路は、より小さな宛先の組 (プレフィクスが長い) を示す経路よりも非特定的であると言われる。ルータはトラフィックを転送するとき、最も特定的な一致経路 (一致するネットワークプレフィクスが最も長い) を使用しなければならない。
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 はマルチキャストルーティングプロトコルについて論じている。
伝統的に、IP ホストかルータ上の各々のネットワークインタフェースは、自分自身の IP アドレスを持つ。これは、全てのホイントツーポイント回線に IP ネットワークプレフィクスの割当てを強いるので、不足した IP アドレス空間の使用効率が悪い。
この問題を解決するために、多くの人々が番号を付けないポイントツーポイント回線の概念を提案し実装した。番号を付けないポイントツーポイント回線は、それに割り当てられたネットワークプレフィクスを全く持たない。結果的に、番号を付けないポイントツーポイント回線に接続されたネットワークインタフェースは、IP アドレスを持たない。
IP 体系は伝統的に全てのインタフェースが IP アドレスを持つと仮定してきたので、これらの番号無しインタフェースはいくつかの興味深いジレンマを引き起こす。例えば、ある IP オプション (例えば経路記録) は、ルータがそのオプションにインタフェースアドレスを挿入しなければならないと規定しているが、番号無しインタフェースは IP アドレスを持たない。より根本的な問題は (チャプタ 5 にあるように)、経路は次ホップルータの IP アドレスを含むことである。ルータは、ルータが接続されている IP (サブ) ネット上にこの IP アドレスがあることを期待する。この仮定は、コネクションが番号を付けないポイントツーポイント回線しかなければ無論破られる。
これらの問題を解決するために、二つのスキームが考案された。一つ目のスキームは、番号の付かないポイントツーポイント回線によって接続された二つのルータは、実際には二つのルータではなく、二つで一つの仮想ルータを構成する半分のルータと考えることである。番号の付かないポイントツーポイント回線は、その仮想ルータの内部バスと本質的に見なされる。仮想ルータを成す二つの半分は、実際に一つのルータのように振舞うよう作業を協調しなければならない。
このスキームは IP 体系にうまく適応するが、二つの重要な欠点を持つ。一つ目の欠点は、一本の番号無しポイントツーポイント回線の一般的なケースには対応できるが、ルータと番号無しポイントツーポイント回線のメッシュ構成のケースに対応するために容易に拡張できないことである。二つ目の欠点は、半分のルータ間の相互動作はかなり複雑であり標準化もされておらず、番号無しポイントツーポイント回線を使用する異なるベンダ製の装置の接続を、実質的に妨げることである。
これらの欠点があるため、このメモは別のスキームを採用した。これは何度か創案されているが、恐らく元は Phil Karn によるものである。このスキームでは、番号無しのポイントツーポイント回線を持つルータは、特殊な IP アドレスも持つ。このメモでは、それをルータ ID と呼ぶ。ルータ ID は、ルータの IP アドレス (ルータは少なくとも一つの IP アドレスを持つ必要がある) の一つである。このルータ ID は、あたかも全ての番号無しインタフェースの IP アドレスであるかのように使用される。
ルータは、IP ルータ機能専用のスタンドアロンコンピュータシステムであってもよい。また、二つ以上のネットワークへの接続をサポートするホストオペレーティングシステムに、ルータ機能を組み込むことも可能である。組み込まれたルータコードを持つオペレーティングシステムの最も良く知られた例は、バークレイ BSD システムである。組み込みルータ機能は、ネットワークを容易に構築するようにみえるが、数多くの隠れた落とし穴がある。
ローカルエリアネットワークとワイドエリア (遠距離) ネットワークをインターネットで相互接続する場合、二つの基本的なモデルが存在する。一つ目は、ローカルエリアネットワークがネットワークプレフィクスを割り当てられ、インターネット中の全てのルータは、そのネットワークへのルーティング方法を知らなければならない。二つ目は、ローカルエリアネットワークが、ワイドエリアネットワークのアドレス空間 (の少しの部分) を共有する。この二つ目のモデルをサポートするルータは、アドレス共有ルータ、あるいはトランスペアレントルータと呼ばれる。このメモの焦点は一つ目のモデルをサポートするルータであるが、トランスペアレントルータの使用を除外することは意図していない。
トランスペアレントルータの基本的な考え方は、そうしたルータの後方にあるローカルエリアネットワーク上のホストが、ルータの前方にあるワイドエリアネットワークのアドレス空間を共有することである。ある状況ではこれは非常に有効なアプローチであり、その制限が重大な欠点をもたらすことはない。
前方や後方という単語はこのアプローチの制限の一つを示す。相互接続のこのモデルは、地理的に (トポロジ的に) 限定されたスタブ環境にのみ適切である。ワイドエリアネットワークのネットワークレベルのアドレス付けにおいて、論理的なアドレス付けの形式がいくつか必要である。ローカル環境の IP アドレスは、ワイドエリアネットワークの幾つかの (大抵は一つの) 物理アドレスにマッピングされる。これは、ワイドエリアネットワーク全体で使用される { IPアドレス <-> ネットワークアドレス } のマッピングと整合する方法でマッピングされる。
マルチホーミングは一つのワイドエリアネットワーク上で可能であるが、もしインタフェースが地理的かトポロジ的に切り離されたら、ルーティングの問題をもたらすかもしれない。二つ (以上) のワイドエリアネットワーク上のマルチホーミングは、アドレスの混乱により問題である。
もしトランスペアレントルータが通常のワイドエリアネットワークのサービスを完全にエミュレートできなければ、ホストが明らかに同じネットワークにある他のホストから見た振る舞いが異なるかもしれない。例えば ARPANET は、オフラインのホストに送信する試みに対する応答で、宛先デッド指示を提供するリンク層プロトコルを使用した。しかし、もし ARPANET とイーサネットの間にトランスペアレントルータが存在したら、ARPANET 上のホストはイーサネット上ののホストに対する宛先デッド指示を受信しないだろう。
インターネットルータは、以下の機能を実現する。
ルータベンダは特定のルータ製品に対して能力、複雑性、機能性で沢山の選択肢がある。インターネットシステムは、同質のものでも完全に一貫したものでもないと認識することは有効的かもしれない。技術や地理的な理由により、インターネットは LAN のはずれ周辺を加えたグローバルな相互接続システムにまで大きくなりつつある。これらの外辺の LAN がますます数多く相互接続されるに従って、除外される LAN はますます減り、ルータへの要求がますます高くなる。
グローバルな相互接続システムの中にあるルータは一般に以下を必要とする。
進歩したルーティングと転送アルゴリズム
これらのルータは高度に動的で、処理と通信負荷を最小限とし、サービスタイプのルーティングを提供するルーティングアルゴリズムを必要とする。輻輳はまだ完全に解決された問題ではない
(セクション [5.3.6] 参照)。研究団体はこれらの問題に対して活発に検討しており、これらの分野での改善が期待される。
高可用性
これらのルータは信頼性が高く、1 日 24 時間、1 週間 7 日のサービスを提供する必要がある。装置やソフトウェアの障害は、広範囲 (時にはグローバル)
への影響を引き起こす可能性がある。障害が発生した場合、即刻回復しなければならない。如何なる環境、極端な輻輳状態やネットワーク資源の障害といった劣化した状態でも、ルータは極めて頑強でかつ運用できなければならない。
進歩した O&M の機能
インターネットルータは通常、無人モードで運用される。ルータは通常、中央監視センタから遠隔操作される。ルータは、監視やトラフィックの計測、他のイベントや障害診断のための洗練された手段を提供する必要がある。
高いパフォーマンス
インターネットにおける遠距離回線は今日、大半が全二重 56 Kbps、DS1(1.544Mbps)、DS3(45Mbps)
の速度である。LAN は半二重のマルチアクセスメディアであり、通常イーサネット (10Mbps)、規模は小さいが FDDI (100Mbps)
である。しかし、ネットワークメディア技術は絶えず成長しており、将来はより高速になるだろう。
LAN 周り (例えばキャンパスネットワーク) で使用されるルータは、ローカルネットワークの要求に強く依存している。これらは高度あるいは中度のパフォーマンスデバイスで、おそらく複数の異なるベンダから競札で調達し、内部組織 (例えばキャンパスコンピュータセンタ) によって運用される。これらのルータの設計は、遅延やサービスタイプを意識した資源管理と共に、平均応答時間が短く、適切なバーストパフォーマンスを重視すべきである。この環境では正規の O&M は少ないが、重要性は低くない。高度に動的なルーティングメカニズムの必要性は、ネットワークが複雑で相互接続が増すにつれてより重要になるだろう。利用者は、グローバルな相互接続の速度のために、ローカル接続からより多くを要求するだろう。
ネットワークが大きくなるにつれ、そして古い機器が徐々に撤去される程ネットワークが古くなるにつれて、ルータが他ベンダ製のルータと相互運用することは、ますます避けられなくなる。
たとえインターネットシステムが完全に相互接続されていなくとも、システムの多くの部分は冗長な接続性を持つ必要がある。豊富な接続性は、通信回線やルータの障害にもかかわらず信頼できるサービスを可能にし、インターネット経路を短縮することによって、そして付加的な収容能力を提供することによってサービスを改善することもできる。不幸にも、このより高度なトポロジは、特定の宛先への最善経路の選択を非常に難しくする。
現在のインターネット体系は、通信システムに関する一連の仮定条件に基づいている。最もルータに関連する仮定条件は、以下のものである。
・インターネットはネットワークのネットワークである。
各々のホストは幾つかの特定のネットワークに直接接続されており、インターネットとの接続は単なる概念上のものである。同一ネットワーク上の二つのホストは、離れたネットワーク上のホストと通信するために使用する同一セットのプロトコルを使用して、お互いに通信する。
・ルータはコネクション状態情報を保存しない
通信システムの頑強性を改善するため、ルータは状態無しで設計され、他のパケットとは独立して各々の IP
パケットを転送する。結果的に、ルータとネットワーク間で障害が発生しても頑強なサービスを提供できるようにするために、冗長的なパスを活用することができる。
エンドツーエンドのフロー制御と信頼性に必要な全ての状態情報は、ホストのトランスポート層かアプリケーションプログラムで実装される。従って、全てのコネクション制御情報は通信の両終端で保持され、一方の終端に障害が起きた場合にのみその情報が失われる。ルータはパケットを落とすかネットワーク遅延を増やすことにより、間接的にしかメッセージフローを制御できない。
将来のプロトコルの発達により、ルータに幾つかの状態が組み込まれるようになるかもしれないことに注意されたい。これはマルチキャストルーティングや資源予約、フローベースの転送で特に起こりそうである。
・ルーティングの複雑さはルータ内にあるべきである。
ルーティングは複雑で難しい問題であり、ホストではなくルータによって実現されるべきである。重要な目的は、インターネットルーティング体系の避けられない発展によりもたらされる変更から、ホストソフトウェアを保護することである。
・システムは広範囲なネットワークの多様性を許容しなければならない。
インターネット設計の基本的な目的は、広範囲なネットワーク特性、例えば帯域や遅延、パケット損失、パケットの再順序、最大パケット長等を許容することである。もう一つの目的は、個々のネットワークやルータやホストの障害に対し、利用可能な帯域がまだある限り使用する頑強性である。最後に、目標は完全なオープンシステムの相互接続であり、インターネットルータは様々なインターネット経路に渡って、他のいかなるルータあるいはインターネットホストとも、頑強かつ効率的に相互運用できなければならない。
時々、実装者は望ましくない目標のために設計することがある。例えば、LAN 環境は通常インターネットよりも全体的に非常に優しく、LAN のパケット損失や遅延は低く、パケットを再順序化することも少ない。幾つかのベンダは、単一の LAN 環境に適した実装体を擁したが、一般的な相互運用では上手く動作しなかった。ベンダは、限定された LAN マーケットの範囲内では経済的であるとして、そのような製品を正当化している。しかし、孤立した LAN が長い間孤立したままであることはめったにない。それらは間もなくお互いに接続され、組織単位で相互接続され、最終的に世界的なインターネットシステムに接続されるだろう。結局のところ、不完全で標準以下のルータが消費者やベンダの要求を満たすことはない。
このドキュメントの要件は、完全な機能を有するルータに対して設計されている。完全に準拠されたルータは、インターネットのほぼいかなる部分にあっても利用できることを意図している。
[INTRO:1] はリンク層の標準 (ARP 等の様々なリンク層上の IP) をカバーしているが、このドキュメントでは、リンク層に関連する内容は別のリンク層要件のドキュメントでカバーされるだろうと期待している。リンク層要件のドキュメントは、ホストとルータの両方に適用できるだろう。従って、このドキュメントは [INTRO:1] のリンク層の内容を扱っている部分を廃止してはいない。
ルータは、他のインターネットシステムと同様に、本質的にリンク層プロトコル要件を持つ。これらの要件は、インターネットゲートウェイ要件 [INTRO:1] のチャプタ 3 に示されている。ルータはその要件に従わなければならず (MUST)、その推奨に従うべきである (SHOULD)。そのドキュメントの幾つかの内容は古くなったので、幾つかの要件と説明を以下に含めている。
DISCUSSION
インターネット社会がインターネットリンク層のための標準を作成し、このチャプタと [INTRO:1] の
"インターネット層プロトコル" とタイトル付けされたチャプタに取って代わることが期待される。
このドキュメントは、リンク層とその上位層間のインタフェースを規定するつもりはない。しかし、このドキュメントの他のパート、特にチャプタ 5 は、この層境界で渡すべき様々な種類の情報を要求していることに注意されたい。
このセクションは以下の定義を使用する。
送信元物理アドレス
送信元物理アドレスはパケットをどこから受信したかを示す、ホストかルータのリンク層アドレスである。
宛先物理アドレス
宛先物理アドレスはパケットをどこへ送信したかを示すリンク層アドレスである。
各々の受信パケットについて、リンク層からインターネットワーク層に渡さなければならない情報は、
各々の送信パケットについて、インターネットワーク層からリンク層に渡さなければならない情報は、
加えて、インターネットワーク層は以下も渡すべきである。
また、もし送信されたパケットがリンク層の優先度関連の異常を引き起こしたら、リンク層はインターネットワーク層に通知しなければならない [5.3.3.3]。
10メガビットのイーサネットに接続できるルータは、[LINK:1] で規定されているトレイラカプセル化を使用してカプセル化されたイーサネットパケットを送受信できてもよい (MAY)。しかし、ルータはトレイラカプセル化されたパケットを発行すべきではない (SHOULD NOT)。ルータは、パケットの直接の宛先がトレイラカプセル化されたパケットの受信に同意し受信可能であることを、[INTRO:2] で規定されているメカニズムを使用して最初に検証せずに、トレイラカプセル化されたパケットを発行してはならない (MUST NOT)。
ARP を実装しているルータは、[INTRO:2] の要件に準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。
リンク層は、宛先未到達エラーを IP に単独で通知してはならない (MUST NOT)。なぜなら、その宛先に対する ARP キャッシュエントリが存在しないからである。リンク層は、ARP 要求/応答シーケンスを実行する間、少数のデータグラムを一時的にキューイングし、これが効果が無いと判明した場合にのみ、キューイングされたデータグラムの一つに対して、宛先が未到達であると応答すべきである (SHOULD)。
ルータは、別のホストかルータのリンク層アドレスがブロードキャストやマルチキャストアドレスであると主張する如何なる ARP 応答も信じないようにしなければならない (MUST)。
10 MBのイーサネットに接続できるルータは、[INTRO:2] のイーサネット要件に準拠しなければならず (MUST)、無条件に準拠すべきである (SHOULD)。
各々の論理インタフェースの MTU は、そのインタフェースに対して正しい MTU の範囲内で設定可能でなければならない (MUST)。
多くのリンク層プロトコルは、送信してもよい最大フレーム長を定義している。そのような場合、ルータはリンク層プロトコルで許されているサイズよりも大きいフレームの送信を可能にするような MTU の設定を許してはならない (MUST NOT)。しかし、ルータはたとえ MTU よりも大きくとも、最大フレーム長と同じ大きさのパケットの受信を同意すべきである (SHOULD)。
これは、[INTRO:2] でホストに課せられている、各々の物理インタフェースの MTU を設定可能にすることを求める要件よりも厳しい要件であることに注意されたい。
もしネットワークがリンク層の最大フレーム長よりも小さい MTU を使用しているならば、ルータは設定の誤ったホストや不完全に初期化されたホストから、MTU よりも大きいパケットを受信してもよい。頑強性の原則は、ルータは可能ならばこれらのパケットを正常に受信すべきであることを指示している。
[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)。
このセクションは、ルータ実装者に、同期/非同期回線上で PPP を使用する他のルータとの相互接続性を保証するためのガイドラインを提供する。
実装者がオプション折衝メカニズムを理解することは重要である。オプションは、ローカルデバイスがリモートの相手から何を受諾し何を送信して欲しくないかを、ローカルデバイスがリモートの相手に示す手段である。ローカルデバイスが受諾できると主張したオプションセットの制限の中で、何を送信するのが最も効率的であるかを決定することはリモートの相手次第である。従って、たとえリモートの相手がそれらのオプションの幾つかをサポートしていなくても、リモートの相手が LCP 通信設定要求 (CR) で指示された全てのオプションに ACK を送信することは、完全に受諾できるし、一般的である。また、オプションは単にいずれかのデバイスが何を受諾するかを相手に示すメカニズムであり、必ずしも何を送信するかを示すわけではない。
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)。
ルータは IP アドレス折衝の実行を申し出てもよい (MAY)。ルータは相手からの IP アドレス折衝を実行することに対する拒否 (REJect) を受諾しなければならない (MUST)。
19200bps かそれ以下の回線速度で運用するルータは、Van Jacobson ヘッダ圧縮の実行を実装し提供すべきである (SHOULD)。VJ 圧縮を実装するルータは、VJ 圧縮を利用可/不可にする管理制御を実装すべきである (SHOULD)。
ルータは、物理インタフェースがパケット送信で利用可能か否かを、ルーティングソフトウェアが決定するためのメカニズムを持たなければならない (MUST)。限定された一連の隣接者に対して永久的な仮想回線がオープンされている多重化インタフェース上では、ルータは仮想回線が利用できるか否かを決定できなけばならない (MUST)。ルータは、ルーティングソフトウェアが物理インタフェースの品質を判断するためのメカニズムを持つべきである (SHOULD)。ルータは、管理上の動作のためのパケット送信で物理インタフェースが利用可能になる時、あるいは利用不可になる時に、ルーティングソフトウェアに通知するメカニズムを持たなければならない (MUST)。ルータは、何らかの理由でリンクレベルインタフェースが利用可能になったこと、あるいは利用不可になったことを検出した時に、ルーティングソフトウェアに通知するメカニズムを持たなければならない (MUST)。
DISCUSSION
ルータが、そのネットワークコネクションが正常に機能していることを決定するために動かせるメカニズムを持つことは重要である。リンク損失を検出しないか、問題を検出したときに適切な動作を実行しないことは、ブラックホールを招く可能性がある。
ネットワークコネクションの問題を検出するために利用できるメカニズムは、使用するリンク層プロトコルやインタフェースハードウェアによってかなり異なる。その目的は、障害を検出する能力をリンク層の制約の中で最大限に活用することである。
|
| Next |