|
Network Working Group Request for Comments: 2453 Obsoletes: 1723, 1388 STD: 56 Category: Standards Track |
G. Malkin Bay Networks November 1998 |
このドキュメントは、インターネット社会の為のインターネット標準トラックプロトコルを規定し、改善の為の議論や提案を求めている。標準化の状況とこのプロトコルの状態については、現在の版の「インターネット公式プロトコル標準」(STD1) を参照されたし。このメモの配布は、制限されない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
このドキュメントは、[1] で定義された経路情報プロトコル(RIP: Routing Information Protocol)の拡張を規定し、RIP メッセージで運ばれる便利な情報の量を拡張し、セキュリティの手段を追加している。
同系のドキュメント [2] は、RIP-2 用の SNMP MIB オブジェクトを定義する。追加ドキュメント [3] は、RIP-2 向けの暗号のセキュリティ改善を定義する。
RIP-2 プロトコルを改善するに当たり助力してくれた、IETF RIP ワーキンググループに感謝したい。距離ベクトルプロトコルについての背景の議論や、RIP の操作の説明の幾つかのテキストの大半は、C. Hedrick による "経路情報プロトコル" [1] から得ている。ドキュメントの最終的な編集は、Scott Bradner が行ってくれた。
Table of Contents
1. 正当化
2. 現在の RIP
3. 基本プロトコル
3.1 導入
3.2 プロトコルの制限
3.3 このドキュメントの構成
3.4 距離ベクトルアルゴリズム
3.4.1 トポロジの変更の取り扱い
3.4.2 不安定性の防止
3.4.3 水平分割
3.4.4 トリガ更新
3.5 プロトコル規定
3.6 メッセージ形式
3.7 アドレス付けの考慮
3.8 タイマ
3.9 入力処理
3.9.1 要求メッセージ
3.9.2 応答メッセージ
3.10 出力処理
3.10.1 トリガ更新
3.10.2 応答メッセージの生成
4. プロトコル拡張
4.1 認証
4.2 経路タグ
4.3 サブネットマスク
4.4 次ホップ
4.5 マルチキャスティング
4.6 キュエリ
5. 互換性
5.1 互換性の切り替え
5.2 認証
5.3 より大きい無限
5.4 アドレス無しリンク
6. バージョン 1 とパージョン 2 間の相互動作
7. セキュリティの考慮
付録 A
参照
作者のアドレス
完全なコピーライト宣言
OSPF や IS-IS の出現で、RIP はもう使われないと信じる人がいる。より新しい IGP 経路プロトコルが RIP よりも優れていることは正しいが、RIP にも利点はある。特に小範囲のネットワークでは、RIP は使用される帯域や構成、管理時間の観点においてオーバヘッドが非常に小さいのである。また、RIP は、特に最近の IGP に比べると実装が非常に容易である。
加えて、RIP の実装は OSPF や IS-IS よりもずっと多くのフィールドに存在する。まだ数年は残るものと思われる。
ある期間の間は、RIP は便利であることを考慮すると、RIP の有効性を増やすことは効果的である。拡張は変更のコストよりもずっと有効的なので、これは特に真である。
現在の RIP-1 メッセージは、ルータがネットワークを通じてメッセージをルーティングするのに必要な最小限の情報を含んでいる。また、送信元が所有していた、大量の未使用空間も含んでいる。
現在の RIP-1 プロトコルは、独立したシステムと IGP/EGP 相互動作やサブネット [11] や認証を考慮していない。なぜなら、これらを実装すると RIP-1 の出荷が遅れるからである。サブネットマスクが無いことは、ルータにとって深刻な問題になっている。というのも、ルータは経路の決定の仕方を知る為にサブネットマスクを必要とするからである。もし RIP-1 の経路がネットワークの経路 (非ネットワークのビットが全て 0) ならば、サブネットマスクはネットワークマスクと等しい。しかし、もし非ネットワークのビットの幾つかが設定されたら、ルータはサブネットマスクを決定することが出来ない。さらに悪いことに、ルータは RIP-1 経路がサブネット経路かホスト経路かを決定することが出来ない。現在は、あるルータは経路が通知された所のインタフェースのサブネットマスクを単純に選択し、それから経路のタイプを決定している。
RIP は Bellman-Ford (または距離ベクトル) アルゴリズムに基づいている。このアルゴリズムは、ARPANET の初期以来、コンピュータネットワークのルーティング算出で使用されている。ここで規定されている特定のパケットフォーマットとプロトコルは、UNIX のバークレイ配布版に含まれている "routed" プログラムに基づいている。
例えばインターネットの様な相互接続システムでは、ネットワーク全体で単一のルーティングプロトコルを使用することは有り得ないことである。むしろ、ネットワークは自律システム (AS: Autonomous Systems) の集合体として組織され、各自律システムは通常、単一のエンティティによって管理されるだろう。各々の自律システムは独自のルーティング技術を持っており、これは異なる自律システムの間で異なっているかもしれない。自律システムの範囲内で使用されるルーティングプロトコルは、内部ゲートウェイプロトコル (IGP: interior gateway protocol) と呼ばれる。それとは別のプロトコルが、自律システム間でルーティング情報を転送するのに使用され、それは外部ゲートウェイプロトコル (EGP: Exterior Gateway Protocol) と呼ばれる。RIP は適度なサイズの自律システムの中で、IGP として動作するよう設計された。RIP は、より複雑な環境下での使用を意図していない。RIP-1 に適していると期待されるコンテキストに関する詳細情報は、Braden と Postel [6] を参照されたい。
RTP は、"距離ベクトルアルゴリズム" として知られたアルゴリズムのクラスの一つを使用する。アルゴリズムのこのクラスの最も古い記述は、Ford and Fulkerson [8] によって書かれたものである。その為、それらは時々 Ford-Fulkerson アルゴリズムとして知られている。Bellman-Ford という用語もまた使用され、これはこの公式が Bellman's 方程式 [4] に基づいているという事実から来る。このドキュメントのプレゼンテーションは、ほぼ [5] に基づいている。このドキュメントはプロトコル規定を含んでいる。ルーティングアルゴリズムの数学を導入するために、[1] ほ参照されたい。このプロトコルで使用されている基本的なアルゴリズムは、ARPANET の 1969年と同じ時期にコンピュータルーティングで使用されていた。しかし、このプロトコルの特定の祖先は、Xerox ネットワークプロトコルの中にある。PUP プロトコル [7] は、経路情報を交換するためにゲートウェイ情報プロトコルを使用した。このプロトコルの幾つかの更新版が、経路情報プロトコル [9] という名前で、Xerox ネットワークシステム (XNS: Xerox Network Systems) アーキテクチャに採用された。バークレイの routed は、大部分において経路情報プロトコルと同じであり、XNS アドレスが、IPv4 や他のタイプのアドレスを扱うことのできる、より一般的なアドレス形式に置き換わり、ルーティングの更新が 30 秒に 1 回に制限された。この類似性のために、経路情報プロトコル (あるいは単に RIP) という用語は、XNS プロトコルと routed で使用されるプロトコルの両方を呼ぶのに使用される。
RIP は IP ベースのインターネットの中で使用されることを意図している。インターネットは、ルータとして知られている特定の目的を持つゲートウェイによって接続された数多くのネットワークの中に組織されている。ネットワークは、ポイントツーポイントかより複雑なネットワーク、例えばイーサネットやトークンリングのいずれかであるかもしれない。ホストとルータは、IP データグラムアドレスを持って幾つかのホストに提供される。ルーティングとは、ホストかルータがどこにデータグラムを送信するかを決定する方法である。もし宛先が、ホストかルータに直接接続されたネットワークの一つの上にあるならば、その宛先にデータグラムを直接送信することが可能である。しかし、興味深いケースは、宛先が直接到達可能な場所にいない時である。この場合、ホストやルータは、宛先により近いルータにデータグラムを送信しようと試みる。ルーティングプロトコルの目標は非常に簡単である。ルーティングを行うために必要な情報を供給することである。
このプロトコルは、全てのルーティング問題を解決していない。上記で言及しているように、適切なサイズのネットワークにおける IGP として使用することを基本的に意図している。加えて、以下の特定の制限について触れなければならない。
このドキュメントの本文は、以下の 2 つのセクションを占める 2 つの部分で構成される。
これらの各 2 セクションは、大半それ自身で成り立っている。セクション 3.4 は、アルゴリズムを数学的に補強する為の情報提供を試みている。それは、"スパイラル" 方式に従っている。初歩の、まさに単純なアルゴリズムが説明されている。その後、継続するセクションでその改良が追加されている。セクション 3.5 は、実際のプロトコル規定である。セクション 3.4 に向けられた特定の参照を除いて、セクション 3.5 に記述された規定だけで、完全に RIP を実装できるはずである。
ルーティングとは、送信元から望まれた宛先へのパスを見つける作業である。IP "インターネットモデル" では、これは送信元と宛先ネットワーク間の一連のルータを見つける問題を主に減らす。メッセージかデータグラムが単一のネットワークかサブネットに残る限り、いかなる転送の問題もそのネットワークに特定の技術によって解決される。例えば、イーサネットと ARPANET はそれぞれ、全ての送信者が一つのネットワークの中で指定されたあらゆる宛先に話ができる方法を定義している。IP ルーティングは、ネットワーク上の送信者から、異なるネットワーク上の宛先にメッセージが行かなければならない時に主に発生する。そのような場合、メッセージはネットワークに接続されている一つ以上のルータを通過しなければならない。もしネットワークが隣接していなければ、複数の中間ネットワークやそれに接続しているルータを通過してもよい。一旦、メッセージが宛先と同じネットワーク上にあるルータに到達したら、宛先に到達させるために、そのネットワーク自身の技術が使用される。
このセクションを通じて、"ネットワーク" という用語は、概して単一のブロードキャストネットワーク (例えばイーサネット) か、ポイントツーポイント回線、ARPANET をカバーする為に使用される。着目すべき点は、ネットワークが IP によって単一のエンティティとして扱われることである。何ら転送決定が必要ない (ポイントツーポイント回線等の場合) か、IP に透過的なある方法で転送が実行されても、IP が単一の完全に接続されたシステム (イーサネットや ARPANET のように) としてネットワーク全体を扱うことを可能にする。注記: "ネットワーク" という用語は、IP アドレス付けにおいては、多少異なる方法で使用される。サブネットのアドレス付けが使用される場合は、サブネットを参照するために "ネットワーク" という用語を使用している。
ネットワーク間の経路を見つけるためのアプローチは数多く存在する。これらのアプローチをカテコライズするひとつの効果的な方法は、ルータが経路を見つけるために交換が必要な情報のタイプに基づくことである。距離ベクトルアルゴリズムは、少量の情報のみの交換に基づいている。ルーティングプロトコルに参加している各々のエンティティ (ルータやホスト) は、システム内の宛先全てに関する情報を保持しているものと想定する。通常、一つのネットワークに接続された全てのエンティティについての情報は、単一のエンティティによって要約され、それはそのネットワーク上の全ての宛先への経路を示す。IP に関する限りネットワーク内のルーティングは見えないので、この要約が可能である。この経路データベース中の各々のエントリは、そのエンティティ宛てのデータグラムが送信される次のルータを含んでいる。加えてこのエントリは、エンティティへの総距離を計測した "メトリック" を含む。この距離は、ある程度一般的なコンセプトであり、メッセージがエンティティに到達する際の遅延時間や、メッセージを送信する為のドル立てのコスト等をカバーしてもよい。距離ベクトルアルゴリズムは、交換される唯一の情報がこれらの距離のリストである時、最適な経路を算出することが可能であるという事実からその名前を得ている。さらに情報は隣接するエンティティ内、すなわち共通のネットワークを共有するエンティティ内で交換されるだけである。
ルーティングは、大部分において共通してネットワークに関する情報に基づくが、個々のホストへの経路の足跡を保持することが時々必要になる。RIP プロトコルは、ネットワークとホストを形式的に区別しない。RIP は、ネットワークかホストのどちらでもよい単に宛先に関する情報の交換を規定する。(しかし、実装者がホスト経路をサポートしないよう選択することは可能である。セクション 3.2 参照) 事実、数学上の発展は、あるホストやルータから別のホストやルータへの経路に関して最も都合よく考えられる。そのアルゴリズムを抽象的な言葉で論じる時、ネットワークの経路エントリを、そのネットワークに接続されたエンティティの全ての経路エントリの略称として考えることは最も良い。この種の略称は、ネットワークを IP レベルで目に見える内部構造を持たないものとして考えているからこそ、意味をなす。従って、与えられたネットワークの全てのエンティティに対しては、同一の距離を通常割り当てる。
上記で、各エンティティは、一つのエントリにつきシステムにおいて全てのあり得る宛先をもつ経路データベースを持つと述べた。実際の実装では、各宛先に関する以下の情報を保持する必要がありそうである。
- アドレス: これらのアルゴリズムの IP 実装では、これはホストかネットワークの IP アドレスになるだろう。
- ルータ: 宛先への経路の中で、一番最初にあるルータ。
- インタフェース: 一番最初のルータに到達する為に使用しなければならない物理ネットワーク。
- メトリック: 宛先までの距離を示す数。
- タイマ: エントリが最後に更新されてからの総時間。
加えて、様々なフラグや他の内部情報が、恐らく含まれるだろう。このデータベースは、システムに直接接続されているエンティティの記述で初期化される。そしてこれは、隣接するルータから受信したメッセージの情報に従って更新される。
ホストとルータで交換される最も重要な情報は、更新メッセージで運ばれるものである。ルーティングに参加している各々のエンティティは、現在そのエンティティに存在する経路データベースを記した更新メッセージを送信する。隣接するエンティティから得られる情報だけを使用して、システム全体の最適な経路を維持することは可能である。そこで使用されるアルゴリズムについては、次のセクションで説明されている。
上記で言及したように、ルーティングの目的は、データグラムを最終の宛先に到達させる方法を見つけることである。距離ベクトルアルゴリズムは、システムにおける全ての宛先への最善経路を一覧化している、各ルータ内のテーブルに基づいている。勿論、どの経路が最善かを定義する為に、善さを測る何らかの方法を持たなければならない。これが、"メトリック" と呼ばれるものである。
単純なネットワークでは、いくつのルータを通過しなければならないかを単に数えただけのメトリックを使用することが普通である。より複雑なネットワークでは、メトリックはメッセージが被る遅延総数、送信コスト、最小化してもよい量を表す為に選択される。主要な要件は、メトリックを個々のホップにかかる "コスト" の合計として表すことが可能でなければならないということである。
形式的に、もしエンティティ i からエンティティ j まで直接得ることができるならば (例えば、別のルータを通過しない等)、そのコスト d(i,j) は、i と j 間のホップと関連付けられる。ネットワーク上の全てのエンティティは同一と通常見なされる場合、d(i,j) は、与えられたネットワーク上の全ての宛先と同値であり、ネットワークを使用するコストを表す。完全な経路のメトリックを取得するには、経路を示す個々のホップのコストを単純にカウントアップする。このメモの目的では、コストは正の整数値であると仮定する。
D(i,j) は、エンティティ i からエンティティ j までの最善経路のメトリックを表すものとする。これは、エンティティの全てのペアを定義しなければならない。d(i,j) は個々のステップのコストを表す。形式的に、d(i,j) はエンティティ i からエンティティ j まで直接行く際のコストを表すものとする。もし i と j が直接隣接していないならば、それは固定ではない。(d(i,i) は固定ではないことに注意されたい。すなわち、ノードから自身への直接のコネクションが存在すると考えない)。コストは加算されるので、最善のメトリックは以下のように示さなければならないことを示すのは容易である。
D(i,i) = 0, all i
D(i,j) = min [d(i,k) + D(k,j)], otherwise
k
最善経路は、i から d(i,k) + D(k,j) が最小値を持つような隣接する k に行くことによって始まる。(これらは、経路におけるステップ数の帰納法によって表すことができる)。二番目の式は、i の直接の隣接者である k に制限できることに注意されたい。その他の場合、d(i,k) は無限であり、それを含む間は最小では有り得ない。
メトリックをこれに基づく単純なアルゴリズムによって算出できることは明白である。エンティティ i は、宛先 j までの距離見積もりを隣接者 k に送信させる。i が k から見積もりを取得したら、i は各々の数に d(i,k) を追加する。これは、単に i と k 間のネットワークを横切るコストである。そして、i は全隣接者から取得した値を比較し、最も小さい値を抽出する。
このアルゴリズムは将来トポロジの変更が無ければ、D(i,j) の正しい見積もりに収束するだろうということが、[2] で証明されている。著者は、エンティティがお互いに情報を送信する順番や、分を再計算する時についてはほとんど仮定していない。基本的には、エンティティは更新情報の送信やメトリックの再計算を停止することはできず、ネットワークはメッセージを永久に遅延させることは出来ない。(ルーティングエンティティの破壊は、トポロジーの変更である)。また、その証明は非否定でなければならないことを除いて、D(i,j) の初期見積もりについて仮定していない。これらのかなり弱い仮定は十分に適切であるという事実は重要である。いつ更新情報を送信するかについて仮定する必要が無いので、そのアルゴリズムを非同期に動作させることが安全に行える。すなわち、各々のエンティティは、自分自身のクロックに従って更新情報を送信することができる。更新情報は全て落ちない限り、ネットワークによって落ちてもよい。開始状態について仮定する必要が無いので、そのアルゴリズムが変更を扱うことができる。システムが変更された時、ルーティングアルゴリズムは新しい均衡に向けて移行し始め、古いものは開始点として使用される。開始点が何であれ、アルゴリズムが有限の時間に収束することは重要である。さもなくば、ある種の変更が非収束的な振る舞いを導くかもしれない。
上記に記述されたアルゴリズムの言明 (とその証明) は、各々のエンティティが各隣接者から来た見積もりのコピーを保持し、時々隣接者の全ての最小値を得るものと仮定している。実際は、真の実装体ではそれをする必要はない。それらは単に、これまで見られた最善のメトリックと送信した隣接者のアイデンティティを覚えているだけである。そして、より良い (より小さい) メトリックを見つける度に、この情報を置き換える。それにより、全隣接者からのデータを格納せずに、最初値を徐々に計算することが可能である。
テキストで記述されたアルゴリズムと、RIP のようなプロトコルで実際に使用されているアルゴリズムとの間には、もう一つ別の相違がある。上記の説明は、0 の距離を示す自分自身のエンティティを含む各々のエンティティを持つ。実際は、これは通常なされない。ネットワーク上の全てのエンティティは通常、ネットワークの単一のエントリによって要約されることを思い起こしてほしい。ネットワーク A に接続されているホストかルータ G の状態を考慮する。C はネットワーク A を使用するコストを表す (通常はメトリック 1)。(ネットワークの内部構造は IP には見えず、従ってネットワーク A 上の二つのエンティティ間を行くコストは同じであることを思い起こしてほしい)。原理的には、G はネットワーク A 上の他の全てのエンティティ H からメッセージを取得すべきであり、0 のコストは自分自身へのエントリからの取得を表す。そして、G は H までの距離として C + 0 を計算するだろう。G はこれらの個々のメッセージを全てチェックせずに、テーブルにネットワーク A に対するエントリを作成し、それに C のメトリックを割り当てることによって単に開始すればよい。ネットワーク A に対するこのエントリは、ネットワーク A 上の他の全てのエンティティを要約していると考えるべきである。ネットワーク A 上の共通のエントリで要約できない唯一のエンティティは、G 自身である。というのは、G から G まで行くコストは C ではなく 0 だからである。しかし、0 エントリは必要ないので、単にネットワーク A の単一のエントリに安全に従うことができる。この戦略のもう一つの意味についての注記: 0 エントリを使用する必要はないので、ルータとして機能しないホストは、更新メッセージを送信する必要はない。明確にルータとして機能しないホスト (すなわち、一つのネットワークにしか接続されていないホスト) は、、自身のエントリ D(i,i)=0 以外に提供する有効な情報を持っていない。それらは一つのインタフェースしか持たないので、そのインタフェースを通った他のネットワークへの経路はそのインタフェースに単に行って、そこからすぐに戻るだけであると見ることは容易である。従って、そのような経路のコストは少なくともCによる最善のコストよりも大きいだろう。0 エントリは必要としないので、非ルータはルーティングプロトコルに全く参加する必要が無い。
ホストやルータ G が行うことを要約しよう。システムにおける各々の宛先に対して、G はその宛先に対するメトリックの現在の見積もり (すなわち、そこに至る全体のコスト)と、そのメトリックが基づくデータを持った隣接するルータの識別子を保持する。もし宛先が G に直接接続されているネットワーク上にあるならば、G はネットワークを使用するコストを示すエントリと、その宛先に達するのに何のルータも必要ないという事実を単に使用するだけである。一旦計算が正しいメトリックに収束したら、この技術によって記録された隣接者は、実際宛先までのバス上の一番最初のルータであることを示すことは容易である。(もし複数の適切なパスが存在するならば、それらのうちの一つが一番最初のルータである)。宛先、メトリック、ルータのこの結合は、そのルータを使用した、そのメトリックを持った宛先までの経路として通常参照される。
4.ne 既存のメトリックはより小さい値が表れるまで保持され、メトリックを下げる方法はそれしかない。初期見積もりが小さ過ぎることも有り得る。従って、メトリックを上げる方法も存在しなければならない。次の規則を適用すれば十分であることが分かる: 宛先までの現在の経路がメトリック D を持ち、ルータ G を使用するものとする仮定する。G 以外の別の送信元から新しい情報のセットが到着したら、もし新しいメトリックが D よりも良いならばその経路を更新するだけである。しかし、もし G 自身から新しい情報のセットが到着したら、必ず D を新しい値に更新する。この規則で、逐次的な更新処理は、全ての隣接者からの最新の情報を記憶し、明確な最小値を割り出す計算と同じ経路を生成することを示すことは容易である。(これまでの議論では、ネットワークの構成が静的であると仮定していることに注意されたい。それは、システムが失敗する可能性を考慮していない)。
要約すると、それまで発展してきた基本的な距離ベクトルアルゴリズムがここにある。(注:これは RIP プロトコルの言明ではない。まだ追加すべき幾つかの改善がある)。ルーティングプロトコルに参加する全てのエンティティによって、以下の手続きが実現される。これは、システムの全てのルータを含まなければならない。ルータではないホストもまた参加してよい。
上記の議論は、ネットワークのトポロジが固定であることを仮定している。実際は、ルータや回線はしばしば異常がおき、そして復旧する。この可能性を扱うために、若干アルゴリズムを修正する必要がある。アルゴリズムの理論上の版は、直接の隣接者全ての最小値を含んでいた。もしトポロジが変わったら、隣接者のセットが変わる。従って次のタイミングで計算が行われ、その変更が反映される。しかし上述したように、実際の実装体は最小値の算出で逐次的な版を使用する。与えられた宛先の最善の経路しか覚えていないのである。もしその経路に含まれたルータがクラッシュしているか、そこへのネットワークコネクションが切断されていたら、その計算は決して変更を反映しないだろう。これまで示されていたアルゴリズムは、メトリックが変わったか否かを隣接者に通知するルータに依存している。もしそのルータがクラッシュしたら、変更を隣接者に通知する方法が無いのである。
この種の問題を扱うために、距離ベクトルプロトコルはタイムアウトの経路に対する準備を施さなければならない。その詳細は、特定のプロトコルに依存している。例えば、RIP ではルーティングに参加する全てのルータは、30 秒毎に更新メッセージを全ての隣接者に送信する。ネットワークNの現在の経路がルータ G を使用するとする。もし G から 180 秒間何も受信しないならば、そのルータがクラッシュしたか、そこに接続しているネットワークが利用できなくなったと想定する。よって、その経路は無効であるとマークする。別の隣接者から有効な N までの経路を受信した時、有効な経路が無効な経路に置き換わる。各隣接者から 30 秒毎に受信することを期待していても、経路のタイムアウトまで 180 秒間待つことに注意されたい。不幸にも、メッセージは時々ネットワークによって欠損する。従って、単一のメッセージの失敗で経路を無効化することは、おそらく適切な考えではないだろう。
以下で述べるが、あるネットワークへの有効な経路が現在存在しないことを隣接者に通知する方法があると便利である。RIP は、このクラスの他の幾つかのプロトコルと一緒に、通常の更新メッセージを通じて、そのネットワークは到達不能とマークすることによってこれを実施する。特定のメトリック値は、到達不能な宛先を示すために選択される。そのメトリック値は、期待されるメトリックの最大値よりも大きい値である。既存の RIP の実装体では、16 が使用されている。メトリックの最大値よりも大きいので、この値は通常 "無限" と呼ばれる。16 は驚くほど小さい数に見えるかもしれない。これから述べる理由により、この小さい値が選択される。大半の実装体では、経路が無効であるとマークするために、同じ慣習が内部で使用されている。
これまで述べられてきたアルゴリズムは、ホストかルータが常に正しいルーティングテーブルを計算するのを可能にする。しかし、実際に便利にするにはまだ極めて不十分である。上記で参照されている証明は、ルーティングテーブルは有限の時間で正しい値に収束するだろうということを示しているにすぎない。この時間が、十分便利であるほど小さいことを保証していないし、アクセス不能になったネットワークのメトリックに何が起きるか言及していない。
アクセス不能になった経路を扱うために、算数を拡張することは十分に容易である。上記で提案された慣習はそれをするだろう。我々は、"無限" を表すために大きなメトリック値を使うことを選択する。この値は、実際のメトリックがかつてそこまで大きくなったことは無いくらい十分に大きい。これを例示するために、値 16 を使うことにする。ネットワークがアクセス不能になったと仮定する。直接隣接している全てのルータはタイムアウトとなり、そのネットワークのメトリックに 16 を設定する。分析するために、全ての隣接しているルータが、16 のコストを持つ消滅したネットワークに直接接続するハードウェアの新しい部品を持ったと仮定できる。それは消滅したネットワークへの唯一のコネクションなので、システム中の他の全てのルータは、それらのルータのうちの一つを通じて行く新しい経路に収束するだろう。一旦収束が起きたら、全てのルータは消滅したネットワークに対して少なくとも 16 のメトリックを持つだろうと見ることは容易である。元の隣接者から 1 ホップ離れたルータは、少なくとも 17 のメトリックで終了し、2 ホップ離れたルータは少なくとも 18 で終了するだろう。これらのメトリックは最大のメトリック値よりも大きいので、それらは皆 16 に設定する。システムが全てのルータで、消滅したネットワークに対して 16 のメトリックに新たに収束することは明白である。
不幸にも、収束するのにどのくらい時間がかかるかという質問は、ごく簡単な答えを得られていない。先に進む前に、例を見ることは有効だろう ([2] から抜粋)。ここで示そうとしているものは、正しい RIP の実装体では起らないだろうということに注意されたい。ある特徴が必要とされる理由を示そうとしているのである。以下の例では、文字がルータに該当し、線がネットワークに該当する。
A-----B \ / \ \ / | C / C から D に直接接続されているネットワークが | / コスト 10 を持つのを除いて、他の全てのネット |/ ワークはコスト 1 を持つ。 D |<=== ターゲットネットワーク
各ルータは、各ネットワークへの経路を示すテーブルを持つ。
しかし、この図の目的では、各々のルータから図の下部にマークされたネットワークまでの経路のみを示す。
D: 直接接続されており、メトリック 1
B: D を経由し、メトリック 2
C: B を経由し、メトリック 3
A: B を経由し、メトリック 3
B から D までの線が故障したと仮定する。経路は、C から D の線を使用するよう補正しなければならない。不幸にも、これを行うにはしばらく時間がかかる。B が D までの経路がもう利用できないことに気づいた時、ルーティングの変更が始まる。簡単にするために、以下のチャートでは、全てのルータは更新情報を同じ時間に送信するものと仮定する。そのチャートは、各々のルータのルーティングテーブルに表れる、ターゲットネットワークに対するメトリックを示している。
time ------>
| D | dir, 1
| dir, 1
| dir, 1
| dir, 1
| ...
| dir, 1
| dir, 1
|
| B | unreach C
| C, 4
| C, 5
| C, 6
| ...
| C, 11
| C, 12
|
| C | B, 3
| A, 4
| A, 5
| A, 6
| ...
| A, 11
| D, 11
|
| A | B, 3
| A, 4
| C, 5
| C, 6
| ...
| C, 11
| C, 12
|
dir = 直接接続されている
unreach = 到達不能
ここに問題がある。B はタイムアウトメカニズムを使用して、故障した経路を取り除くことができるが、その痕跡はしばらくの間システム中に残り続ける。最初、A と C は、D まで B 経由で行けるとまだ思っている。よって、A と C は 3 のメトリックをリスト化した更新情報を送信する。次の繰り返しで、B は A か C のいずれかを使用して D に到着することができると主張する。もちろんそれはできない。A と C によって主張されていた経路は、現在無くなっている。しかし、まだそのことを認識する方法が無い。B を経由した経路が無くなったことを発見したときでさえ、その他を経由した利用可能な経路が存在すると各々が思っている。最終的には、全ての算数がしなければならないと主張した時にシステムは収束する。しかし、そうなるまである程度時間がかかり得る。最悪のケースは、ネットワークがシステムのある部分から完全にアクセス不能になる時である。その場合、それらが最終的に無限に達するまで、メトリックは上記のようなパターンでゆっくりと加算される。この理由から、その問題は "無限まで継続" と呼ばれる。
なぜ "無限" に可能な限り小さい値が選択されるのか理解できるはずである。もしネットワークが完全にアクセス不能になったら、可能な限り早く止まるよう無限値まで数えたいのである。無限値は、実際の経路がそこまで大きくない程十分大きくなければならない。しかし、必要以上に大きくなるべきではない。従って無限値の選択は、ネットワークサイズと無限値まで数えることが起きた場合の収束速度とのトレードオフである。RIP の設計者は、このプロトコルは直径 15 以上の大きさのネットワークでは実践的ではなさそうであると信じていた。
この様な問題を避けるために行えることはいくつかある。RIP で使用されているものは、"有毒な逆を持つ水平分割 (split horizon with poisoned reverse)" と "トリガ更新 (triggered updates)" である。
上記の問題の幾つかは、A と C が相互に虚偽のパターンで結びついているという事実に起因していることに注意されたい。各々が、一方を経由して D に到達することができると主張している。これは、どこの情報が送信されたかについて少し注意深くなることで避けることができる。特に、経路情報を教わった隣接者への宛先ネットワークへの到達性を主張することは有効ではない。"水平分割" は、教わったルータに送信する更新情報の中に、経路を含むことに起因する問題を避けるための方策である。"単純水平分割" の方策は、その隣接者に送信する更新情報の中にある一つの隣接者から、教わった経路を省略する。"有毒な逆を持つ水平分割" はそのような経路を更新情報の中に含むが、そのメトリックを無限に設定する。
もし A が C を経由して D に到達できると思っていたら、C へのそのメッセージは D は到達不可であると示すべきである。もし C を通る経路が真実であれば、C は D に直接接続されているか、ある別のルータを通じて接続されているかのいずれかである。ループを形成してしまうため、C の経路は恐らく A に戻れない。D が到達不能であると C に告げることによって、C が混乱して、A を通じた経路が存在すると信じるかもしれない可能性を簡単に防ぐことができる。これは、ポイントツーポイント回線でも明白である。しかし、A と C がイーサネットのようなブロードキャストネットワーク接続され、そのネットワーク上に別のルータが存在する可能性を考慮されたい。もしAがCを通じた経路を持っているならば、Aはそのネットワーク上にある別のルータと話をする時、Dが到達不可であることを示すべきである。そのネットワーク上の他のルータは、C自身に到達しえる。それらは、Aを経由してCに到達する必要は決してない。もしAの最善経路が実際にCを通るならば、そのネットワーク上の他のルータは、AがDに到達できることを知る必要が無い。C のために使用された同じ更新メッセージが、同じネットワーク上の他の全てのルータでも使用できることを意味するので、これは幸いである。従って、更新メッセージはブロードキャストによって送信できる。
もし A が C を経由して D に到達できると思っていたら、C へのそのメッセージは D は到達不可であると示すべきである。もし C を通る経路が真実であれば、C は D に直接接続されているか、ある別のルータを通じて接続されているかのいずれかである。ループを形成してしまうため、C の経路は恐らく A に戻れない。D が到達不能であると C に告げることによって、C が混乱して、A を通じた経路が存在すると信じるかもしれない可能性を簡単に防ぐことができる。これは、ポイントツーポイント回線でも明白である。しかし、A と C がイーサネットのようなブロードキャストネットワーク接続され、そのネットワーク上に別のルータが存在する可能性を考慮されたい。もし A が C を通じた経路を持っているならば、A はそのネットワーク上にある別のルータと話をする時、D が到達不可であることを示すべきである。そのネットワーク上の他のルータは、C 自身に到達しえる。それらは、A を経由して C に到達する必要は決してない。もし A の最善経路が実際に C を通るならば、そのネットワーク上の他のルータは、A が D に到達できることを知る必要が無い。C のために使用された同じ更新メッセージが、同じネットワーク上の他の全てのルータでも使用できることを意味するので、これは幸いである。従って、更新メッセージはブロードキャストによって送信できる。
通常、有毒な逆を持つ水平分割は単純な水平分割よりも安全である。もし二つのルータがお互いを指している経路を持っていたら、16 のメトリックを持つ逆の経路を伝播すると、即座にループを壊すだろう。もし逆の経路が単に伝播されなければ、異常な経路はタイムアウトを待って除去されなければならない。数多くのことなる建物に接続されているキャンパスバックボーンのケースについて考慮してみる。各々の建物には、バックボーンをローカルネットワークに接続するルータが存在する。バックボーンネットワーク上でルータがブロードキャストすべきルーティング更新情報が何かを考慮されたい。残りのネットワークが各々のルータについて知る必要があるものは、そのルータが接続されているローカルネットワークが何かである。単純な水平分割を使用すると、バックボーンネットワークへの経路のみが、ルータによって送信される更新メッセージの中に現われる。もし有毒な逆を持つ水平分割が使用されたら、ルータはバックボーンから教わった全ての経路を、メトリック 16 として言及しなければならない。もしシステムが大規模ならば、これはほとんど全てのエントリが到達不可を示す大きな更新メッセージを結果として生じ得る。
静的な方法では、メトリック 16 を持つ逆経路を伝播することは、何の付加情報も提供しない。一つのブロードキャストネットワーク上に多くのルータが存在するならば、これらの余分なエントリは重要な帯域を使用し得る。その理由は動的な振る舞いを改善することである。トポロジが変わったとき、ルータを通過すべき経路だけでなく、通過すべきでない経路について言及することにより、収束速度を速めることができる。しかしある状況では、ルーティングのオーバヘットを最小化するために、ネットワーク管理者がより遅い収束を望むかもしれない。従って、実装体は有毒な逆を持つ水平分割ではなく、単純な水平分割をオプションで実装してもよい。あるいは、ネットワーク管理者がどの動作を使用するかを選択できる構成オプションを提供してもよい。ある逆経路は 16 のメトリックを持ち、その他は省略するという混成スキームを実装することも許される。そうしたスキームの例として、それらを巻き込むルーティングの変更後、ある時間の間は逆経路に対して 16 のメトリックを使用し、その後で更新情報からそれを省略するという方法がある。
ルータ要件 RFC [11] は、全ての RIP の実装体は水平分割を使用しなければならず、有毒な逆を不能にするためのノブは存在してもよいが、有毒な逆を持つ水平分割も使用すべきであると規定している。
有毒な逆を持つ水平分割は、二つのルータだけを巻き込むルーティングループを防ぐだろう。しかし、三つのルータが相互の虚偽で結びつくパターンで起きることは依然として有り得る。例えば、A は B を通じた経路、C を通じた B、A を通じた C の経路があると信じるかもしれない。水平分割は、そのようなループを停止することができない。このループは、メトリックが無限に達して、巻き込まれたネットワークが到達不可と宣言された時にのみ解決できる。トリガ更新は、この収束を早めるための試みである。トリガ更新を取得するために、ルータが経路に対するメトリックを変更する場合は必ず、たとえ規則的な更新メッセージの送信時間に達していなくても、ほとんど直ぐに更新メッセージを送信する必要があるという規則を単に追加する。(そのタイミングの詳細はプロトコル毎に異なるだろう。RIP を含む幾つかの距離ベクトルアルゴリズムは、トリガ更新が極端なネットワークトラフィックを生み出すのを避けるために小さい遅延時間を規定する)。これが、どのように新しいメトリックを算出するための規則と結合するかに注意されたい。宛先 N までのルータの経路がルータ G を通過すると仮定する。もし更新情報が G 自身から到着したら、その新しいメトリックが古いものより高くあれ低くあれ、受信側のルータはその新しい情報を信じる必要がある。その結果、もしメトリックが変更されたら、受信側ルータは自分に接続されている全てのホストやルータにトリガ更新を送信するだろう。代わってそれらは、各々お互いに自分の隣接者に更新情報を送信するだろう。その結果はトリガ更新のカスケードである。どのホストやルータが、そのカスケードに巻き込まれているかを示すことは容易である。ルータ G が宛先 N までの経路をタイムアウトすると仮定する。G は自分の隣接者全てにトリガ更新を送信する。しかし、新しい情報を信じる唯一の隣接者は、N までの経路が G を通過するルータである。他のルータやホストは、既に使用している経路よりも悪い新しい経路についての情報としてこれを見て、無視するだろう。その経路が G を通過する隣接者はそのメトリックを更新し、自分の隣接者全てにトリガ更新を送信する。また、その経路はそれらを通過する隣接者のみが注意を払う。従って、トリガ更新はメトリックを無限に更新しながら、ルータ G につながる全てのパスに沿って後方に波及する。この波及は、宛先 N までの経路として別のパスを採用するネットワークの部分に到達すると止まるだろう。
もし、トリガ更新のカスケードが起きる間、システムが黙っていられたら、無限値まで数えることは起きないことを証明することは可能である。悪い経路は必ず即座に削除されるので、ルーティングループは形成されないのである。
不幸にも、物事はそう上手くいかない。トリガ更新が送信される間、規則的な更新情報が同時に送信されるかもしれない。トリガ更新をまだ受信していないルータは、もはや存在しない経路に基づく情報をまだ送出しているかもしれない。トリガ更新がルータを通過した後、まだ一言かけられていないこれらのルータの一つから通常の更新情報を受信することは有り得る。これは、欠陥のある経路の残存を再確立し得る。もしトリガ更新が十分素早く行われたら、これは極めて起こりにくい。しかし、無限まで数えることは依然として起こり得る。
ルータ要件 RFC [11] は、全ての RIP の実装体は削除された経路のためにトリガ更新を実装しなければならず、新しい経路か変更された経路のためにトリガ更新を実装してもよいことを規定している。さらに、RIP 実装体はトリガ更新を送信してもよい割合を制限しなければならない (セクション 3.10.1 参照)。
RIP は、ホストとゲートウェイが IPv4 ベースのネットワークを通じた経路を算出する為の情報の交換を可能とすることを意図している。RIP を使用するルータは、一つ以上のネットワークへのインタフェースを持つものと想定され、持たないものは真のルータではない。これらは直接接続されたネットワークと呼ばれる。プロトコルは、これらの各々のネットワークに関するある情報へのアクセスに頼っており、最も重要なのはそのメトリックである。ネットワークの RIP メトリックは 1 〜 15 の整数である。それは、このプロトコルでは規定されていない幾つかの方法で設定されるが、パス制限の最大値は 15 であり、通常は 1 の値が使用される。実装体は、システム管理者が各々のネットワークのメトリックを設定することを可能にすべきである。メトリックに加えて、各ネットワークは IPv4 宛先アドレスとそれに割り当てられたサブネットマスクを持つだろう。これらはシステム管理者によって、このプロトコルでは規定されていない方法で設定される。
RIP を使用するホストは、一つ以上のネットワークへのインタフェースを持つことが想定される。これらは "直接接続されたネットワーク" と呼ばれる。プロトコルは、これらのネットワークの各々に関するある情報へのアクセスに頼る。最も重要な点はメトリック、又は "コスト" である。ネットワークのメトリックは 1 〜 15 の間の整数である。これは、このプロトコルで規定されない方法で設定される。最も普及している実装では、常にメトリックとして 1 の値を使用している。新たに作成する実装は、システム管理者が各々のネットワークのコストを設定できる様にしなければならない。コストに加えて、各々のネットワークは IPv4 のネットワーク番号と、それに割り当てられたサブネットマスクを持つ。これらはシステム管理者により、このプロトコルで規定されない方法で設定される。
注記: 3.7 節で規定された規則は、各々の IPv4 ネットワークに適用される単一のサブネットマスクが存在し、直接接続されたネットワークの為のサブネットマスクだけが認識されているものと想定している。単一ネットワークの範囲内で、異なるサブネットで異なるサブネットマスクを使用するシステムが存在するかもしれない。システムが遠隔ネットワークのサブネットマスクを知ることを望むインスタンスもまた存在するかもしれない。もしネットワーク中の全てのルータが、このドキュメントで提供されている拡張を実行しているなら、異なるサブネットマスクを含むルーティング情報のネットワーク全体の配布は許される。しかし、もしネットワーク中の全てのルータが、これらの拡張を実行しているわけではないならば、異なるサブネットマスクを含んでいるルーティング情報の配布は、相互運用性の問題を避けるために制限しなければならない。サブネットの配布を決定する規則については、セクション 3.7 と 4.3 を参照されたい。
RIP を実装する各ルータは、経路テーブルを持つと想定される。このテーブルは、RIP を運用するシステムを経由して到達可能な全ての宛先の為の一個のエントリを持つ。各エントリは、少なくとも以下の情報を含む。
直接接続されたネットワークのエントリは、このプロトコルで規定されていない手段によって増やされる情報を使用して、ルータによって設定される。直接接続されたネットワークのメトリックは、そのネットワークのコストに設定される。既に述べたように、1 が通常のコストである。その場合、RIP メトリックは単純にホップ数に減らされる。より複雑なメトリックは、例えば帯域や信頼性の為に、あるネットワークの優先度を示すことが望まれる時使用してもよい (例えば、帯域と信頼性の相違を示す)。
このドキュメントで詳述されている拡張をサポートするために、各エントリは追加でサブネットマスクを含まなければならない。そのサブネットマスクにより、ルータが (宛先の IPv4 アドレスと共に) 離れたネットワークのサブネットマスクだけでなく、単一ネットワーク内の異なるサブネットを識別することも可能になる。
実装者は、システム管理者が追加経路を入力できることを選択してもよい。これらは、ルーティングシステムのスコープ外のホストかネットワークへの経路に最もありえる。それらは "静的経路" と呼ばれる。これらの初期の宛先以外の宛先エントリは、以下の節で説明されているアルゴリズムによって追加、または更新される。
完全な経路情報を提供するプロトコルの為に、AS 中の全てのルータがそのプロトコルに参加しなければならない。複数の IGP が使用されている場合は、プロトコル間に経路情報を漏らすことができるルータが少なくとも一つは存在しなければならない。
RIP は UDP ベースのプロトコルである。RIP を使用する各ルータは、UDP ポート番号 520 上でデータグラムを送受信するルーティングプロセスを持つ。別のホストの RIP プロセッサに接続された全ての通信は、ポート 520、RIP-1/RIP-2 ポートに送信される。別のルータの RIP プロセス向けを意図した全ての通信は、RIP ポートに送信される。全ての経路更新メッセージは RIP ポートから送信される。望まれれない経路更新メッセージは、送信元と宛先ポートの両方とも RIP ポートに等しい。要求に対する応答として送信されるこれらの更新メッセージは、要求が来たポートに送信される。特定のキュエリは、RIP ポート以外のポートから送信してもよいが、ターゲットマシンの RIP ポートに向けなければならない。
RIP パケット形式は以下の通り。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | command (1) | version (1) | must be zero (2) | +---------------+---------------+-------------------------------+ | | ~ RIP Entry (20) ~ | | +---------------+---------------+---------------+---------------+
1 〜 25 までの RIP エントリが存在してもよい。RIP-1 エントリは以下の形式である。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address family identifier (2) | must be zero (2) | +-------------------------------+-------------------------------+ | IPv4 address (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | metric (4) | +---------------------------------------------------------------+
フィールド長は、オクテット単位で付与される。もし他に指定されていなければ、フィールドはバイナリ整数を、最上位オクテットが最初に来る (ビッグエンディアン) ネットワークオーダで含む。各チックマークは、1 ビットを表わしている。
全てのメッセージは、コマンド、バージョン番号から成る RIP ヘッダを含む。ドキュメントのこのセクションは、プロトコルのバージョン 1 について記述しており、セクション 4 はバージョン 2 拡張を記述している。コマンドフィールドは、このメッセージの目的を指定する為に使用される。バージョン 1 と 2 で実装されるコマンドは、以下のものである。
1 - request
経路テーブルの全て又は一部を送信してほしいという、応答側システムに対する要求
2 - response
送信側の経路テーブルの全て又は一部を含んでいるメッセージ。このメッセージは要求に対する応答で送信してもよいし、あるいは送信側によって生成された要請されていないルーティング更新情報かもしれない。
これらのメッセージタイプの各々において、バージョン 1 では、そのデータグラムの残りは経路エントリ (RTE: Route Entry) のリストを含む。このリスト中の各々の RTE はアドレスファミリ識別子 (AFI: Address Family Identifier)、宛先 IPv4 アドレス、その宛先に到達するためのコスト (メトリック) を含む。
AFI はアドレスのタイプである。RIP-1 では、AF_INET (2) のみが通常サポートされる。
メトリックフィールドは 1 〜 15 までの値を含み、宛先向けの現在のメトリックを示す。値 16 (無限) は、宛先が到達不可であることを示す。
距離ベクトルルーティングは個々のホストかネットワークへの経路を示すのに使用できる。RIP プロトコルは、これらの可能性のいずれかを可能にする。要求と応答メッセージに表れる宛先は、ネットワーク、ホスト、デフォルトアドレスを示すために使用される特殊なコードである。通常、実際に使用される経路の種類は、特定のネットワークで使用されるルーティング方式に依存する。多くのネットワークは、個々のホストのための経路情報が必要無いようセットアップされている。もし、与えられたネットワークかサブネット上の全てのホストが同じルータを通じてアクセス可能ならば、ルーティングテーブル中の個々のホストについて言及する理由はない。しかし、ポイントツーポイント回線を含むネットワークは、あるノードへの経路の足跡を保持するために、時々ルータを必要とする。この機能が必要か否かは、そのシステムで使用されるアドレス付けとルーティングのアプローチに依存する。従って、幾つかの実装体はホスト経路をサポートしないことを選択してもよい。もしホスト経路がサポートされていなければ、応答メッセージで受信した時、それらは落される (セクション 3.7.2 参照)。
RIP-1 パケット形式は、様々なアドレスのタイプを区別しない。"アドレス"
とラベルが付けられたフィールドは、以下を含む。
ホストアドレス、サブネット番号、ネットワーク番号、0 (デフォルト経路)
RIP-1 を使用するエンティティは、データグラムをルーティングする時に利用可能な最も特定の情報を使用すると仮定される。すなわち、データグラムをルーティングする時、その宛先アドレスをノードアドレスのリストに対して、一番最初にチェックしなければならない。そして、知っているサブネットかネットワーク番号と一致するか否かチェックしなければならない。最後に、一致するものが無かったら、デフォルトの経路が使用される。
ノードが RIP-1 を経由して受信した情報を評価する時、アドレスの解釈はそのネットに適用するサブネットマスクを知っているか否かに因る。もし知っているならば、アドレスの意味を決定することが可能である。例えば、ネット 128.6 について考える。それは、255.255.255.0 のサブネットマスクを持っているとする。従って、128.6.0.0がネットワーク番号であり、128.6.4 がサブネット番号であり、128.6.4.1 がノードアドレスである。しかし、もしノードがサブネットマスクを知らなければ、アドレスの評価が曖昧になるかもしれない。もし 0 でないノード部があるならば、そのアドレスがサブネット番号を表しているのか、ノードアドレスを表しているのかを決定するための明確な方法が無い。サブネット番号は、サブネットマスク無しでは有効でないので、アドレスはこの状況ではノードを表すものと仮定する。この種の曖昧さを避けるために、バージョン 1 を使用する場合は、ノードは適切なサブネットマスクを知ることを期待できないノードにサブネット経路を送信してはならない。通常ホストは、直接接続されたネットワークのサブネットマスクを知るだけである。従って、もし特別な用意がなされていないならば、サブネットへの経路はサブネットが一部分であるネットワークの外側に送信してはならない。RIP-2 (セクション 4 参照)は、ルーティングエントリ中にサブネットマスクを含めることによって、サブネット/ホストの曖昧さを取り除く。
この "サブネットフィルタリング" は、サブネット化されたネットワークの "境界" でルータによって実行される。これらは、ネットワークを他の幾つかのネットワークに接続するルータである。サブネット化されたネットワークの範囲内で、各々のサブネットは別個のネットワークとして扱われる。各サブネットのルーティングエントリは、RIP によって算出される。しかし、境界のルータは、他のネットワークのノードにネットワーク全体で単一のエントリのみを送信する。これは、境界のゲートウェイは異なる隣接者に異なる情報を送信することを意味する。サブネット化されたネットワークに接続されている隣接者のために、ルータは直接接続されている全てのサブネットのリストを、サブネット番号を使用して生成する。他のネットワークに接続されている隣接者のために、ネットワーク全体として単一のエントリを作成し、そのネットワークに関連したメトリックを示す。このメトリックは通常、ルータが接続されているサブネットで最も小さいメトリックである。
同様に境界のルータは、直接接続されたネットワークの一つの中のノードのホスト経路を、他のネットワークにメッセージで言及してはならない。それらの経路は、ネットワーク全体の一つのエントリに包含される。
ルータ要件 RFC [11] は、RIP の全ての実装体はホスト経路をサポートすべきであるが、もしサポートしていないならば、受信したホスト経路は全て無視しなければならないと規定している。
特別なアドレス 0.0.0.0 は、デフォルト経路を示すのに使用される。デフォルト経路は、RIP の更新情報で全ての有り得るネットワークをリスト化することが効率的でない時や、システムで一つ以上近くに接続されたルータが、明示的にリスト化されていないネットワークへのトラフィックを扱う準備がされている時に使用される。これらのルータは、あたかも自分が接続しているネットワークであるかのように、アドレス 0.0.0.0 の RIP エントリを作成しなければならない。ルータが 0.0.0.0 のエントリを作成する方法についての決定は、実装者に任される。最も共通的に、システム管理者は、どのルータが 0.0.0.0 のエントリを作成するかを指定する方法を提供されるだろうが、他の方法も可能である。例えば、BGP を話すルータは全てデフォルトルータとして宣言すべきであると、実装者は決定するかもしれない。ネットワーク管理者が、これらのエントリで使用されるメトリックを選択することは有効かもしれない。もし一つ以上のデフォルトルータが存在するならば、他よりも上の優先度の表現を可能にするだろう。0.0.0.0 のエントリは、このネットワークのアドレスが実際に存在するかのように、RIP によって全く同じ方法で扱われる。システム管理者は、0.0.0.0 への経路が意図した以上に流布されないことを保証するよう注意しなければならない。一般的に、各々の自律システムは自分が望むデフォルトルータを持つ。従って、0.0.0.0 を含む経路は通常、自律システムの境界を残すべきではない。
このセクションは、タイマがトリガとなる全てのイベントを説明する。
30 秒毎に、完全なルーティングテーブル (水平分割のセクション 3.9 参照) を含む要請されていない応答メッセージを、隣接する全てのルータに送信するために RIP プロセスが呼び出される。単一のネットワーク上に多くのルータが存在する時、同時に更新情報を発行するように、お互いに同期をとる傾向がある。これは、30 秒タイマがシステム上の処理負荷に影響される時は常に起こり得る。ブロードキャストネットワーク上に不必要な衝突を導き得るので、更新メッセージが同期をとることは望ましくない。従って、実装体は二つの警戒のうち一つを採用する必要がある。
各々の経路に割り当てられた二つのタイマが存在する。"タイムアウト" と "ガーベージコレクション" 時間である。タイムアウトが満了すると、その経路はもはや有効ではない。しかし、それはテーブルに短時間保持され、それによって隣接者に経路が落ちたことを通知できる。ガーベージコレクションタイマが満了したとき、その経路は最終的にルーティングテーブルから削除される。
タイムアウトは、経路が確立される時と、経路に対する更新メッセージを受信した時に初期化される。タイムアウトが最後に初期化されてから 180 秒経過したら、その経路は満了したと見なされ、以下で説明される削除プロセスがその経路に対して開始される。
削除は、二つの理由の一つにより発生し得る。タイムアウトの満了と、現在のルータから受信した更新情報のためにメトリックが 16 に設定される場合である。(他のルータからの更新情報の処理については、セクション 3.7.2 を参照されたい)。いずれかのケースで、以下のイベントが起きる。
ガーベージコレクションタイマが満了するまで、その経路はこのホストから送信される全ての更新情報に含まれる。ガーベージコレクションタイマが満了した時、その経路はテーブルから削除される。
もしガーベージコレクションタイマが作動中に、この経路への新しいネットワークが確立されたら、その新しい経路は削除されようとしている経路から置き換わる。この場合、ガーベージコレクションタイマをクリアしなければならない。
トリガ更新も小さいタイマを使用するが、これについてはセクション 3.9.1 で最もよく説明されている。
このセクションでは、RIP ポート上で受信されたデータグラムの扱いについて説明する。処理はコマンドフィールドの値に依存する。
バージョン番号の扱いについての詳細は、セクション 4.6 と 5.1 を参照されたい。
要求は、のルーティングテーブルの全て、又は一部を含む応答を求めるために使用される。通常、要求はちょうど立ち上がって、ルーティングテーブルを可能な限り早く作成したいルータによって、RIP ポートからブロードキャスト (RIP-2 ではマルチキャスト) で送信される。しかし、単一のルータだけのルーティングテーブルが必要な状況 (例えばルータ監視) があるかもしれない。この場合、要求は RIP ポート以外の UDP ポートから、そのルータに直接送信すべきである。もしそのような要求を受信したら、そのルータは要求側のアドレスとポートに直接送信する。
要求はエントリ毎に処理される。もしエントリが存在しなければ、応答は返さない。特殊なケースが一つ存在する。もし、要求の中にエントリが一つだけ存在し、そのエントリが 0 のアドレスファミリ識別子と無限のメトリック (すなわち 16) を持っているならば、これはルーティングテーブル全体を送信してほしいという要求である。その場合、出力プロセスを呼び出して、要求側アドレス/ポートにルーティングテーブルを送信する。この特殊なケースを除いて、処理は極めて単純である。RTE のリストを一つずつ検査する。各々のエントリに対して、ルータのルーティングデータベース中の宛先を調べる。もし経路が存在するならば、その経路のメトリックを RTE のメトリックフィールドに入れる。もし指定された宛先へ明示的な経路が存在しないならば、メトリックフィールドに無限を入れる。全てのエントリが埋まったら、コマンドを要求から応答に変更して、そのデータグラムを来た要求側に返送する。
その要求が特定かテーブル全体かによって、メトリックの扱いに相違があることに注意されたい。もし要求が完全なルーティングテーブルに対してならば、通常の出力処理が行われ、水平分割 (セクション 3.9 水平分割参照) を含む。もし要求が特定のエントリに対してならば、ルーティングテーブル内を調べて情報を返却し、水平分割の処理は行われない。この区別の理由は、これらの要求が異なる目的で使用されるだろうという期待による。ルータが最初に立ち上がった時、そのルータは完全なルーティングテーブルのために、要求を接続されている全てのネットワークにマルチキャストする。完全なルーティングテーブルは、要求側のルーティングテーブルを更新するために使用すると想定される。そのため水平分割を行わなければならない。さらに、特定のネットワークに対する要求は、診断ソフトウェアによってのみ行われ、ルーティングには使用されないと想定される。この場合、要求者はルーティングデータベースの正確な内容を知りたがり、隠蔽された、あるいは修正された情報は望まないだろう。
応答は、幾つかの異なる理由により受信され得る。
応答がどのような理由で生成されたにせよ処理は同じである。
応答の処理は、ルータのルーティングテーブルを更新するかもしれないので、正当性のチェックは注意深く行わなければならない。応答は、RIP ポートから来ていなければ無視しなければならない。IPv4 送信元アドレスは、そのデータグラムが正しい隣接者からのものであるかチェックすべきである。データグラムの送信元は、直接接続されたネットワーク上にいなければならない。応答がルータ自身のアドレスの一つから来たかをチェックすることも価値がある。ブロードキャストネットワーク上のインタフェースは、自分のブロードキャスト/マルチキャストのコピーを即座に受信するかもしれない。もしルータが自分自身の出力を新しい入力として処理したら、混乱が起きるかもしれない。よって、そのようなデータグラムは無視しなければならない。
データグラム全体を評価したら、その応答中の RTE を一つずつ処理する。そして再び評価を実施することによって開始する。不正なメトリックや他の形式のエラーは大抵、行儀の悪い隣接者を示し、恐らく管理者の注意を引き起こすべきである。
例えば、もしメトリックが無限よりも大きいならばそのエントリは無視するが、そのイベントをログに採取する。基本的な正当性チェックは、
もしチェックが失敗したら、そのエントリを無視して次を処理する。また、エラーをログに採取することは恐らく良い考えである。
エントリの評価が完了したら、メッセージが到着したネットワークのコストを追加することによってメトリックを更新する。もしその結果が無限よりも大きいならば、無限を使用する。すなわち、
メトリック = MIN (メトリック + コスト, 無限)
そして、宛先アドレスの明示的な経路が既に存在するか否かを見るためにチェックする。もしそのような経路が存在しなければ、メトリックが無限でなければこの経路をルーティングテーブルに追加する (使用不可の経路を追加する性質はない)。ルーティングテーブルへの経路の追加は、以下で構成される。
更新情報をトリガ送信するプロセスに通知する。(セクション 3.8.1参照)
もし既存の経路が存在するならば、次ホップアドレスをデータグラムが来たルータのアドレスと比較する。もしこのデータグラムが既存の経路と同じルータからのものならば、タイムアウトを再初期化する。次にメトリックを比較する。もしそのデータグラムが既存の経路と同じルータからのもので、新しいメトリックが古いものとは異なっている、あるいは新しいメトリックが古いものよりも小さいならば、以下の動作を実行する。
もし新しいメトリックが無限ならば、その経路に対して削除処理が始まり、その経路はもはやパケットのルーティングで使用されない。削除処理は、メトリックが初めてに無限に設定される時にのみ開始される。もしメトリックが既に無限ならば、削除処理は開始しない。
もし新しいメトリックが古いものと同じならば、最も簡単なことは何も実行しないことである (上述したように、タイムアウトの再初期化は除く)。しかし、適用可能な自発的診断は存在する。通常、新しい経路が既存の経路と同じメトリックを持つ経路を変更することは無意味である。これにより経路の差し戻しが起きて、耐え難い数のトリガ更新を生成するかもしれない。しかし、もし既存の経路がタイムアウトの兆候を示しているならば、タイムアウトの発生を待つよりも、メトリックの等しい代替経路に即座に切り替えることはより良いかもしれない。従って、もし新しいメトリックが古いものと同じならば、既存の経路のタイムアウトをチェックする。もしそれが少なくとも満了点の半分ならば、新しい経路に切り替える。この自発的診断はオプションであるが、強く推奨される。
これらのテストが失敗したエントリは、現在の経路ほど優れていないので無視される。
このセクションは、ルーティングテーブルの全てあるいは一部を含む応答メッセージを作成する処理について説明する。この処理は、以下の事象がトリガとなって実行される。
応答が全ての隣接者に送信される (例えば、定期更新かトリガ更新) とき、応答メッセージは各々接続されたポイントツーポイント回線の遠くの終端のルータに送信され、応答はブロードキャストをサポートしている全ての接続されたネットワーク上でブロードキャストされる (RIP2 ではマルチキャスト)。従って、各々の直接接続されたネットワークに対して一つの応答が用意され、対応するアドレス (直接またはブロードキャスト/マルチキャスト) に送信される。ほとんどのケースでは、これは全ての隣接ルータに到着する。しかし、幾つかのケースで、これでは十分でない場合が存在する。これはブロードキャストをサポートしていないネットワーク (例えば ARPANET) や、ダムルータを含む状況に由来する。そのようなケースでは、隣接するルータの実リストを指定し、その各々に明示的にデータグラムを送信する必要があるかもしれない。そのようなメカニズムが必要であるか否かの決定や、リストの指定方法の定義については実装者に任される。
トリガ更新は、二つの理由のために特殊な操作を必要とする。第一にトリガ更新は、制限された容量を持つか、その上に多くのルータを持つネットワークに過度の負荷を引き起こし得ることが、経験上分かっている。従って、プロトコルは、実装体がトリガ更新の頻度を制限する機能を含むことを必要とする。トリガ更新を送信した後、タイマを 1 〜 5 秒のランダムな間隔に設定すべきである。もし、タイマが満了する前に他の変更がトリガ更新を発生したならば、タイマが満了したとき単一の更新のトリガとする。その後タイマを別の 1 〜 5 秒のランダムな値に再設定する。もしトリガ更新を送信する際に定期更新が行われたら、トリガ更新を抑止すべきである。
第二に、トリガ更新はルーティングテーブル全体を含む必要はない。原則的には、含める必要があるのは変更があった経路だけである。従って、トリガ更新の一部として生成されたメッセージは、少なくとも経路更新フラグが設定された経路を含まなければならない。実装者の裁量で追加経路を含んでもよいが、全体のルーティング更新を行わないことが強く推奨される。トリガ更新を処理する時、全ての直接接続されたネットワークに対してメッセージを作成すべきである。水平分割処理は、通常の更新 (セクション 3.9 参照) だけでなくトリガ更新の生成時も行われる。もし指定されたネットワークの水平分割処理後、変更された経路がそのネットワーク上で変更されていない (例えば無限のメトリックである) ならば、その経路は送信する必要が無い。もしそのネットワーク上で何の経路も送信する必要が無いならば、その更新は省略してもよい。一旦トリガ更新の全てが生成されたら、経路変更フラグをクリアすべきである。
もし出力情報が生成されている間に入力処理が許されているならば、適切な相互ロックを実施しなければならない。経路変更フラグは、トリガ更新メッセージが生成されている間の入力処理の結果で変更すべきではない。
トリガ更新と他の更新メッセージの唯一の相違は、変更されない経路の省略が可能であることである。次のセクションで規定されている残りのメカニズムは、全ての更新に適用しなければならない。
このセクションは、ある特定の直接接続されたネットワークに対して生成される応答メッセージの生成方法について説明する。
バージョン番号を 1 か 2 のどちらかに設定する。送信するバージョンを決定するメカニズムは実装依存であるが、もしこれが要求に対する応答ならば、応答バーションは要求バージョンに一致すべきである。"must be zero" というラベルが付いたバイトには 0 を設定する。RTE の設定を開始する。応答には 25 RTE の制限があることを思い出してほしい。もしそれ以上存在するならば、新しいものを開始する。応答を形成するデータグラムの個数の制限は定義されていない。
RTE を設定するために、ルーティングテーブルの各々の経路をチェックする。もしトリガ更新が生成されたら、経路変更フラグが設定されている経路のエントリのみ含める必要がある。もし、水平分割処理後に経路を含めるべきでないならば、それをスキップする。もし経路が含めるならば、宛先アドレスとメトリックを RTE に設定する。たとえメトリックが無限であっても、データグラム中に経路を含めなければならない。
このセクションは RIP プロトコル自体を変更しない。むしろ、ルータが重要な付加情報を共有できるようにするメッセージフォーマットの拡張を提供する。
RIP-1 と RIP-2 メッセージで同じヘッダ形式 (セクション 3.4 参照) が使用される。RIP-2 の 20 オクテットの経路エントリ (RTE) の形式は、以下の通り。
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family Identifier (2) | Route Tag (2) | +-------------------------------+-------------------------------+ | IP Address (4) | +---------------------------------------------------------------+ | Subnet Mask (4) | +---------------------------------------------------------------+ | Next Hop (4) | +---------------------------------------------------------------+ | Metric (4) | +---------------------------------------------------------------+
アドレスファミリ識別子、IP アドレス、メトリックについては全て、セクション 3.4 で定義された意味を持つ。バージョンフィールドは、認証を使用するか新たに定義されたフィールドで情報を運ぶ RIP メッセージに対し、バージョン番号 2 を指定する。
認証はメッセージ機能毎であり、メッセージヘッダフィールドで利用できる 2 オクテットフィールドが一つしかなく、効率的な認証スキームは 2 オクテット以上必要とされるので、RIP バージョン 2 における認証スキームは RIP エントリ全体の空間を使用する。もしメッセージ中のアドレスファミリ識別子の最初のエントリ (最初だけ) が 0xFFFF ならば、エントリの残りは認証を含む。これは、メッセージの残りに最大 24 個の RIP エントリが存在し得ることを意味する。もし認証が使用されないならば、メッセージ中のエントリは、0xFFFF のアドレスファミリ識別子を持つべきではない。認証エントリを含む RIP メッセージは、以下の形式で始まるだろう。
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command (1) | Version (1) | unused | +---------------+---------------+-------------------------------+ | 0xFFFF | Authentication Type (2) | +-------------------------------+-------------------------------+ ~ Authentication (16) ~ +---------------------------------------------------------------+
現在、唯一の認証タイプは単なるパスワードであり、そのタイプは 2 である。残りの 16オクテットは、プレインテキストのパスワードを含む。もしパスワードが 16 オクテット以下ならば左詰され、右側にはヌル (0x00) でパディングされる。
経路タグ (RT: Route Tag) フィールドは、保存され経路とともに再度伝播しなければならない経路に割り当てられた属性である。経路タグの意図的な使用は、"内部の" RIP 経路 (RIP ルーティングドメイン内のネットワークの為の経路) を、EGP か別の IGP からインポートされた "外部の" RIP 経路と区別する方法を提供することである。
RIP 以外のプロトコルをサポートしているルータは、異なる送信元からインポートされた経路kのための経路タグの設定を許可するよう設定可能にすべきである。例えば、EGP か BGP からインポートされた経路は、任意の値か少なくとも経路を教えた自律システムの数のどちらかを設定した経路タグを持てるようすべきである。
RIP ドメイン中の全ての経路が首尾一貫している限り、経路タグを他に使用することも正しい。これにより、透過ネットワークでルーティングを同期させる方法を規定する、BGP-RIPプロトコルの相互動作のドキュメント化を可能にする。
サブネットマスクフィールドは、アドレスの非ホスト部分を生み出すために、IP アドレスに適用されるサブネットマスクを含む。もしこのフィールドが 0 ならば、このエントリにはサブネットマスクが含まれていない。
RIP-1 ルータが RIP-2 ルーティングエントリの情報を聞いたり操作するインタフェースでは、次の規則が適用される。
この経路エントリによって指定された宛先へのパケットを転送すべき直次のホップの IP アドレス。このフィールドに 0.0.0.0 の値を指定することは、ルーティングは RIP 伝播の起動元を経由すべきであることを示す。次ホップとして指定されたアドレスは、強制的に、伝播される論理的なサブネット上で直接到達可能でなければならない。
次ホップフィールドの目的は、システム中の余分なホップを通過する経路を持つパケットを除くことである。RIP がネットワーク上の全てのルータで動作しているとは限らない時には特に有効である。簡単な例が付録 A に示されている。次ホップは "助言" のフィールドであることに注意されたい。すなわち、もし提供された情報が無視されたら、恐らく次に最適な、しかし絶対的に正当な経路が採用されるかもしれない。もし、受信した次ホップが直接到達可能でないならば、それは 0.0.0.0 として扱わなければならない。
RIP-2 メッセージをリッスンしていないホストへの不必要な負荷を減らすために、IP マルチキャストアドレスが、定期的なブロードキャストで使用される。その IP マルチキャストのアトレスは、224.0.0.9 である。これらは転送されないルータ間メッセージなので、IGMP は必要ない。
NBMA ネットワークではユニキャストアドレスが使用されるかもしれない。しかし、もし RIP-2 マルチキャストアドレスのアドレスを持つ応答を受信したら、受諾すべきである。
下位互換を維持するために、セクション 5.1 で説明されているように、マルチキャストアドレスの使用を設定可能にするだろう。もしマルチキャスティングが使用されるなら、それをサポートしている全てのインタフェースで使用すべきである。
もし RIP-2 ルータが RIP-1 要求を受信したら、RIP-1 応答で応答すべきである。もしルータが RIP-2 メッセージだけを送信するよう設定されていたら、RIP-1 要求に対して応答すべきでない。
RFC [1] はバージョン番号の扱いを規定する際、かなりの慎重さを示した。バージョン 0 の RIP メッセージは破棄すべきで、バージョン 1 の RIP メッセージは、もし 0 でなければならないフィールド (MBZ: Must Be Zero) が 0 でないならば破棄すべきで、1 よりも大きいバージョン番号の RIP メッセージは、単に MBZ フィールドが 0 以外の値を含むというだけでは破棄すべきでないと規定している。これは、RIPの新しいバージョンは、規約のこの部分に則した既存の RIP 実装と全体的に下位互換がとれていることを意味する。
互換性の切り替えは、二つの理由により必要である。一つに、フィールドで、上記で説明されているような RFC [1] に従っていない RIP-1 の実装体が存在する。二つに、マルチキャスティングの使用は、RIP-1 システムが RIP-2 の更新メッセージを受信することを防ぐ (それはある場合に望ましい特徴である)。この切り替えは、インタフェース毎に設定可能にすべきである。
切り替えには 4 つの設定がある。RIP-1: RIP-1 メッセージだけが送信される。RIP-1 互換: RIP-2 メッセージがブロードキャストされる。RIP-2: RIP-2 メッセージがマルチキャストされる。none: RIP メッセージを送信不能にする。デフォルト設定は RIP-1 か RIP-2 のいずれかが推奨され、RIP-1 互換は推奨されない。これは、あるトポロジ上で発生する潜在的な問題のためである。RIP-1 互換は、ネットワーク管理者がそれを使用した結果として起き得る全てを理解した場合に限り使用すべきである。
完全にするために、ルータは受け入れるのが RIP-1 のみ、RIP-2 のみ、両方とも、両方受け入れないかを決定する受信制御切り替えも実装すべきである。それは、インタフェース毎に設定可能にもすべきである。そのデフォルトは、更新情報送信で選択されたデフォルトと互換性を持つことが推奨される。
RIP メッセージを認証するために、以下のアルゴリズムを使用すべきである。もしルータが RIP-2 メッセージを認証するよう設定されていなければ、RIP-1 と認証されない RIP-2 メッセージは受け入れ、認証される RIP-2 メッセージは破棄すべきである。もしルータが、RIP-2 メッセージを認証するよう設定されていたら、RIP-1 メッセージと認証テストを通過した RIP-2 メッセージは受け入れ、認証されないか認証に失敗した RIP-2 メッセージは破棄すべきである。最大のセキュリティでは、認証を使用する際 RIP-1 メッセージは破棄すべきである (セクション 4.1 参照)。さもなくば、認証されるメッセージからのルーティング情報は、認証しない方法で RIP-1 ルータによって伝播されるだろう。
認証エントリは 0xFFFF のアドレスファミリ識別子でマークされ、IP 以外のアドレスファミリに属すので、RIP-1 システムはこのエントリを無視するだろう。従って、認証を使用することによって、RIP-1 システムが RIP-2 メッセージを見ることを防げるわけではないことに注意すべきである。もし望むならば、セクション 4.5 と 5.1 で説明されているように、マルチキャストを使用してこれを行ってもよい。
互換性の目的がある一方、人々が要求する一つの項目がある。それは無限の増加である。これが実施できない主要な理由は、下位互換に反することである。より大きい無限は、明白に
RIP の旧バージョンに混乱を来すだろう。最善なのは、16 のメトリックを無視するようにその経路を無視することである。メトリックを単一オクテットにして、上位の
3 オクテットを再使用するという提案もある。しかし、これはメトリックを
4 オクテットのエンティティとして扱っている実装を壊すだろう。
RIP-1 と同様、アドレス無しリンクは RIP-2 ではサポートしない。
バージョン 1 のパケットはサブネット情報を含まないので、バージョン 1 とバージョン 2 ネットワークの両方を含むネットワーク上のルータが用いるセマンティクスは、バージョン 1 のものに限定すべきである。さもなくば、ブラックホール経路 (例えば存在しないネットワークへの経路) を生成するか、バージョン 1 環境でルーティング情報を過剰に生み出すことが有り得る。
幾つかの実装体は、隣接経路のグループを単一のエントリに自動的に要約しようと試みる。その目的は、エントリの総数を減らすことである。これは自動要約と呼ばれる。
特に、バージョン 1 とバージョン 2 の両方を一つのネットワーク内で使用する場合、ネットワーク全体を通じて一つのサブネットマスクを使用すべきである。加えて、こうしたネットワークでは自動要約メカニズムを不使用にすべきであり、実装体は自動要約を不可にするメカニズムを提供しなければならない。
基本的な RIP プロトコルは安全なプロトコルではない。RIP-2 をより近代的なルーティングプロトコルを持つ回線に導入するために、拡張可能な認証メカニズムがプロトコル拡張に取り込まれた。このメカニズムは、セクション 4.1 と 5.2 で説明されている。セキュリティは、[3] で説明されているメカニズムによって更に拡張される。
これは、RIP エントリの次ホップフィールドを使用する簡単な例である。
----- ----- ----- ----- ----- ----- |IR1| |IR2| |IR3| |XR1| |XR2| |XR3| --+-- --+-- --+-- --+-- --+-- --+-- | | | | | | --+-------+-------+---------------+-------+-------+-- <-------------RIP-2------------->
IR1,IR2,IR3 は全て、IGP として RIP-2 の使用を選択した 1 つの管理 (例えばキャンパス) の下にある "内部" ルータであると仮定する。一方、XR1,XR2,XR3 は別の管理 (例えば、キャンパスがメンバである地域ネットワーク) の下にあり、ある別のルーティングプロトコル (例えば OSPF) を使用しているものとする。XR1,XR2,XR3 は、それらの間でルーティング情報を交換し、例えばネットワーク N1,N2 への最善経路は XR1 を経由し、N3,N4,N5 へは XR2 を経由し、N6,N7 へは XR3 を経由することを知る。次ホップフィールドを正しく設定する (N3/N4/N5 向けは XR2 へ、N6/N7 向けは XR3 へ) ことによって、XR1を通過する追加ホップ無しで発生するルーティングのために、XR1 だけが RIP-2 経路を IR1/IR2/IR3 と交換すればよい。次ホップが無いと (例えばもし RIP-1 が使用されたら)、XR2 と XR3 は余分なホップを除くために、RIP-2 プロトコルにも参加する必要があるだろう。
[1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
[2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC1389, January 1993.
[3] Baker, F., and R. Atkinson, "RIP-II MD5 Authentication", RFC2082, January 1997.
[4] Bellman, R. E., "Dynamic Programming", Princeton University Press, Princeton, N.J., 1957.
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-Hall, Englewood Cliffs, N.J., 1987.
[6] Braden, R., and Postel, J., "Requirements for Internet Gateways", STD 4, RFC 1009, June 1987.
[7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., "Pup: An Internetwork Architecture", IEEE Transactions on Communications, April 1980.
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", Princeton University Press, Princeton, N.J., 1962.
[9] Xerox Corp., "Internet Transport Protocols", Xerox System Integration Standard XSIS 028112, December 1981.
[10] Floyd, S., and V. Jacobson, "The synchronization of Periodic Routing Messages," ACM Sigcom '93 symposium, September 1993.
[11] Baker, F., "Requirements for IP Version 4 Routers." RFC 1812, June 1995.
Gary Scott Malkin
Bay Networks
8 Federal Street
Billerica, MA 01821
Phone: (978) 916-4237
EMail: gmalkin@baynetworks.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
(このドキュメントと翻訳は全体または一部を、如何なる種類の制限無しで、上記のコピーライト記述を提供し、このパラグラフを全てのコピーや派生作業に含めて、他者へコピーや供給してもよく、コメントしたり、別途説明したり、実装を援助するといった派生作業を準備、コピー、出版、配布してもよい。しかし、このドキュメント自身は、インターネット標準プロセスで定義された手続きに従わなければならず、インターネット標準を開発する目的で必要な場合や、英語以外の言語に翻訳するために必要な場合を除いて、コピーライト記述やインターネット社会、他のインターネット組織への参照等を、如何なる方法でも修正してはならない。
上記で認められた制限された許可は永久的であり、インターネット社会や継承者や割当て者によって無効にされることはないだろう。)
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.