| Prev |
|
以下に示す制約に従って、ホストは送信元経路中の中間ホップとして振る舞い、指定された次のホップに送信元経路付きのデータグラムを転送することができてもよい (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)。
この付録は、このメモで使用された特定の用語を定義する。また、興味があるかもしれない一般目的の用語についても定義する。定義のより多くの一般的なセットについては [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 ヘッダ中のフィールド。これは、ホップ数とタイマ値を兼ねる。
この付録は、このドキュメントの将来の改訂で取り上げたい作業を一覧化する。
ルータ要件を準備するにあたり、我々は幾つかの他の体系的な問題に突き当たった。これらの各々は、ある程度このドキュメントで取り扱っているが、依然として IP 体系におけるオープンな問題として分類すべきである。
ここに挙げられているトピックの大半は概して、技術がまだ比較的新しく、社会がまだ運用上の経験を十分に積んでいないため、特定の要件を作成することが適切でない分野を示す。
他のトピックは進行中の研究の分野を表しており、慎重な開発者が綿密に検討するであろう分野を示す。
マルチキャストは、インターネットプロトコルファミリの中で比較的新しい技術である。
それはまだ広く普及しておらず、一般にはまだ使用されていない。しかしその重要性は、年が経つに連れて増しつつある。
この付録は、インターネットを通じたルーティングマルチキャストを調査している技術の幾つかを示している。
勤勉な実装者は、正確にマルチキャスト設備を開発するために、この分野を並行して発展させるだろう。
この付録はいかなる標準も要件も規定しない。
マルチキャストルーティングプロトコルは、TCP/IP インターネットを通じた IP マルチキャストデータグラムの転送を可能にする。通常、これらのアルゴリズムは、送信元と宛先アドレスに基づいてデータグラムを転送する。加えて、データグラムを複製して複数のインタフェースに送出する必要がある度に、幾つかのマルチキャストグループメンバにデータグラムを転送する必要がある。
マルチキャストルーティングプロトコルの状態は、IP ユニキャストの転送で利用できるプロトコルほど発達していない。三つの実験的なマルチキャストルーティングプロトコルが、TCP/IP でドキュメント化されている。各々は、マルチキャストグループメンバシップを監視するために IGMP プロトコル (セクション [4.4] で論じられている) を使用する。
[ROUTE:9] でドキュメント化されている DVMRP は、距離ベクトルかベルマンフォード技術に基づいている。それはマルチキャストデータグラムのみを振り分け、単一の自律システムの中でそれを行う。DVMRP は [ROUTE:10] で説明された、除去された逆パスブロードキャストアルゴリズムの実装である。加えて、それは非マルチキャストルーティング能力がある IP ドメインを通じた、IP マルチキャストのトンネル化を規定する。
現在開発中の MOSPF は、自律システムの中で IP マルチキャストとユニキャストの両方の転送を可能にする、OSPF の下位互換のある追加である。MOSPF ルータは、ルーティングドメインの中で OSPF ルータと混在することができ、それらはユニキャストの転送で相互運用可能だろう。OSPF はリンク状態、あるいは SPF ベースのプロトコルである。
グループメンバシップを正確に指し示すリンク状態通知を追加することによって、MOSPF ルータはデータグラム送信元で振り分けられるトリーとして、マルチキャストデータグラムのパスを算出できる。グループメンバを含まないそれらの分岐は破棄でき、不要なデータグラム転送ホップを除去できる。
現在開発中の PIM は、既存のユニキャスト基盤上で動作するマルチキャストルーティングプロトコルである。PIM は密集と分散両方のグループメンバシップを提供できる。分散グループでは明示的な結合モデルを使用するので、それぞれのプロトコルは異なっている。結合は共有トリー上で発生し、送信元トリー毎に切り替えることができる。バンド幅が豊富でグループメンバシップが密集している場合、データを全てのリンクに大量に送出し、後でグループメンバの無い例外を刈り込むことによってオーバヘッドを減少させることができる。
セクション [5.2.4.3] は、ルータがパケットの次ホップ選択の時に使用すべきアルゴリズムを規定している。
この付録は、次ホップ選択問題の歴史的な総体見地を提供する。さらに、インターネットで見られる幾つかの追加の除去規則と次ホップ選択アルゴリズムを提供する。
この付録は、Philip Almquist による以前の非公開の作業、次ホップに関する要件からの資料の引用を提供する。
この付録は、如何なる標準や要件も規定しない。
そのトピックの歴史を簡潔に振り返ることは有効であり、ルータがどのようにルーティング決定を行うかについての"クラシックモデル"と時々呼ばれるものから始まった。このモデルは IP に先行する。このモデルでは、ルータは例えば RIP のような、ある単一のルーティングプロトコルを話す。そのプロトコルは、ルータの転送情報ベース (FIB) の内容を完全に決定する。ルータ検索アルゴリズムは些細なものであり、ルータは、パケットの宛先アドレスのネットワークプレフィクス部に宛先属性が正確に一致する経路を FIB の中に探す。もし一つ見つかったらそれを使用し、もし見つからなかったら、その宛先は未到達である。ルーティングプロトコルは各々の宛先に対してほとんど一つの経路を保持するので、同じ宛先に一致する経路が複数存在する時に何をすべきかという問題が起こり得ない。
年が経つにつれて、このクラシックモデルは少しずつ拡張された。デフォルト経路やサブネット、ホスト経路の実装で、幾つかの意味で宛先に一致する一つ以上のルーティングテーブルエントリを持つことが可能になった。これは、経路の階層が存在するという意見の一致により容易に解決した。ホスト経路はサブネッと経路よりも好まれ、サブネッと経路はネット経路よりも好まれ、ネット経路はデフォルト経路よりも好まれるべきである。
可変長サブネットマスク (可変長ネットワークプレフィクス) をサポートする技術の実装で、その記述は少し複雑になったけれども通常のアプローチは同じで、ネットワークプレフィクスは体系の意識的な簡略化と規則化として導入された。我々は今、ネットワークプレフィクス経路への各経路は、それに割り当てられたプレフィクス長を持つと言う。このプレフィクス長はプレフィクスのビット数を示す。それは、古典的なサブネットマスクを使用して表現してもよい。もしルータのネットワークプレフィクス中の各々意味のあるビットが、パケットの宛先アドレス中の対応するビットに一致しなければ、そのパケットを振り分けるためにその経路を使用できない。マスクにより多くのビットセットを持つ経路はマスクにより少ないビットセットを持つ経路よりも好まれる。これは上記に記述されている経路の階層の単純な一般化であり、このメモの残りでは最長照合を好むことによって経路を選択することで参照されるだろう。
クラシックモデルが拡張されたもう一つの方法は、ルーティングプロトコルはルーティングテーブルの内容上で制御を完了するという考えを少し緩和することによる。最初に静的経路が導入された。まず第一に、同時に二つの経路 (一つは動的でもう一つは静的) を持つことが有り得る。これが起きた時、静的経路と動的経路のどちらをより好むかについてルータはポリシー (ある場合は設定可能で、またある場合はルータのソフトウェア作成者によって選択される) を持たなければならない。しかし、このポリシーは最長照合がユニークに使用すべき経路を決定しなかった時の均衡破りとしてのみ使用される。従って、例えばたとえポリシーが動的経路よりも静的経路を望んでも、静的デフォルト経路は動的ネット経路よりも決して好まれることはなかった。
クラシックモデルは、ドメイン間ルーティングプロトコルが発明された時、更に拡張しなければならなかった。伝統的なルーティングプロトコルは "内部ゲートウェイプロトコル" (IGP) と呼ばれるようになり、各々のインターネットサイトでは "外部ゲートウェイ" と呼ばれる一風変わった新しいものが存在し、EGP を幾つかの "BBN コアゲートウェイ" に話すルータ (当時インターネットバックボーンを形成するルータ) は、同時に IGP をそのサイトの他のルータに話した。両方のプロトコルは、ルータのルーティングテーブルの内容を決定することを望んだ。理論的に、これはルータに同じ宛先への三つの経路 (EGP. IGP, 静的) を結果的に持たせた。当時のインターネットトポロジのため、それは、ルータは IGP 経路を EGP 経路よりも好むというポリシーによることが最善であることで、ほとんど議論されることも無く解決された。しかし、最長照合の高さが問題視されていなかったので、IGP から学んだデフォルト経路は、EGP から学んだネット経路よりも決して好まれることはなかった。
インターネットトポロジや必然的にインターネットにおけるルーティングは、その時からかなり発展したけれども、クラシックモデルのこのわずかな拡張バージョンは、(BGP が EGP に置き換わったことを除き) インターネットに今日そのまま生き残っている。概念的に (しばしば実装において)、各々のルータは一つのルーティングテーブルを持ち、一つ以上のルーティングプロトコルプロセスを持つ。これらのプロセスの各々は、望ましいエントリを追加したり、作成したエントリを削除したり修正することができる。パケットを振り分ける時、ルータは最長照合を使用して最善経路を抽出し、同評価から決定するためのポリシーメカニズムで補う。この拡張されたクラシックモデルは我々の目的にうまく適っているが、以下の数多くの欠点を持っている。
セクション [5.2.4.3] は、FIB から経路を選択するために使用する幾つかの枝刈り規則を定義した。他にも使用できる規則は存在する。
・OSPF 経路クラス
内部と外部の領域を持つか、二者を区別するルーティングプロトコルは、経路を算出するために使用される情報のタイプによって、経路をクラスに分割する。もしどれも使用可能ならば、経路は最も望ましいクラスから常に選択され、それが使用できない場合は二番目に望ましいクラスから選択される。OSPF
では、(最も望ましい経路から最も望ましくない経路の順番で) クラスはイントラ領域、インター領域、タイプ
1 外部 (外部メトリックを持つ外部経路)、タイプ 2 外部領域である。追加案としては、ルータは何のアドレスがイントラ領域経路を使用してアクセス可能であるべきかを知るために設定され、利用可能なイントラ領域経路がない場合でもこれらの宛先に到達するためにインター領域か外部経路を使用しないだろう。
より正確には、各々の経路は route.class と呼ばれるクラス属性を持つと仮定する。それはルーティングプロトコルによって割り当てられる。候補の経路のセットは、route.class がイントラ領域に等しいものを含むか否かを決定するために試される。もし含まれるならば、route.class がイントラ領域に等しい以外の経路は破棄される。さもなくば、ルータはパケットの宛先がローカル領域として設定されたアドレス範囲にあるか否かをチェックする。もしあるならば、候補の経路の全体のセットが削除される。さもなくば、候補の経路のセットは、route.class がインター領域に等しいものを含むか否かを決定するために試される。もし含まれるならば、route.class がインター領域に等しい以外の経路は破棄される。さもなくば、候補の経路のセットは、route.class がタイプ 1 の外部領域に等しいものを含むか否かを決定するために試される。もし含まれるならば、route.class がタイプ 1 の外部領域に等しい以外の経路は破棄される。
・IS-IS 経路クラス
IS-IS 経路クラスは OSPF と同等に作用する。しかし、統合 IS-IS によって定義されたクラスの組みは異なる。IS-IS 経路クラスと
OSPF 経路クラス間に一対一のマッピングは存在しない。統合 IS-IS によって使用される経路クラスは、(最も望ましい経路から最も望ましくない経路の順番で)
イントラ領域、インター領域、外部領域である。
統合 IS-IS 内部クラスは、OSPF 内部クラスに相当する。その上、統合 IS-IS 外部クラスは OSPF のタイプ 2 外部クラスに相当する。しかし、統合 IS-IS はインター領域と内部メトリックを持つ外部領域経路を区別せず、両方ともインター領域経路と見なされる。従って、OSPF は内部メトリックを持つ外部経路よりも真のインター領域経路を好み、統合 IS-IS はこの二つのタイプの経路に等しい優先度を付与する。
・IDPR ポリシー
ポリシーの特定のケース。IETF のドメイン間ポリシールーティングワークグループは、インターネットにおける真のポリシーベースのルーティングをサポートする、ドメイン間ポリシールーティング
(IDPR) と呼ばれるルーティングプロトコルを考案している。ヘッダ属性 (送信元と宛先アドレスの特定の結合か特殊な IDPR 送信元経路オプション)
のある結合を持つパケットは、IDPR プロトコルによって提供された経路を使用する必要がある。従って、他のポリシー枝刈り規則とは違って、IDPR
ポリシーは基本照合を除く他の枝刈り規則の前に適用しなければならないだろう。
特に、IDPR ポリシーはその属性はポリシーベースの経路を使用して転送する必要があるか否かを確かめるために転送されたパケットを試す。もしそうならば、IDPR ポリシーは IDPR プロトコルによって提供されていない全ての経路を削除する。
このセクションは、使用されているか提案されている幾つかの経路検索アルゴリズムを考察する。各々、使用する枝刈り規則の順序を示すことによって説明されている。各アルゴリズムの強度や弱度が提供されている。
改訂されたクラシックアルゴリズムは、セクション [E.1] で論じられた伝統的なアルゴリズムの形式である。このアルゴリズムのステップは以下の通り。
ある実装はポリシーのステップを省略する。というのも、経路が (異なるルーティングドメインからそれらを知ったので) 等しくないメトリックを持つ場合にしか必要ないからである。
このアルゴリズムの長所は、
その短所は、
あるルータ要件ワーキンググループのメンバは、セクション [5.2.4.3] に記述されたアルゴリズムを若干変更して提案した。この変更版では、要求されたサービスタイプの照合は、宛先アドレスの照合よりも重要でないと見なされるのではなく、より重要であると見なされる。例えばこのアルゴリズムは、デフォルトのサービスタイプを持つネット経路よりも、正しいサービスタイプを持つデフォルト経路を好むだろう。一方、[5.2.4.3] のアルゴリズムは、その反対の選択を行う。
このアルゴリズムのステップは、
このアルゴリズムと正規のルータ要件アルゴリズムの提案者間の議論により、そのアルゴリズムは、同様で他のアルゴリズムが行うものよりも直観的なルーティングを導く場合を、各々のサイドが示せることを提案している。最長照合に基づく枝刈りの前に弱い TOS に基づく枝刈りを行うため、標準的なルータ要件アルゴリズムよりも、このアルゴリズムは OSPF や統合 IS-IS との互換性が低くなっていることを除き、この変形版は [5.2.4.3] と同じ長所と短所を持つ。
OSPF は、OSPF 経路クラスを考慮するという一つの決定的な相違を除いて、ルータ要件アルゴリズムと事実上等しいアルゴリズムを使用する。
このアルゴリズムは、
サービスタイプのサポートは常に存在するわけではない。もしそれが存在しなければ、四番目のステップは無論省略される。
このアルゴリズムは、改訂されたクラシックアルゴリズムよりも幾つかの利点を持つ。
しかし、このアルゴリズムは改訂されたクラシックアルゴリズムの短所の幾つかが残ったままである。
OSPF アルゴリズムは、更なる短所 (改訂されたクラシックアルゴリズムによって共有されていない) も持っている。OSPF 経路が宛先アドレスと一致するビットが少ない場合でさえ、他のルーティングプロトコルから学んだ経路よりも OSPF 内部 (イントラ領域かインター領域) 経路が常に優先であると見なす。これは、あるネットワークでは不適切なポリシー決定である。
最後に、OSPF アルゴリズムの TOS のサポートは、0 でない TOS 値を持つパケットを転送する時に、TOS をサポートするルーティングプロトコルが暗黙的に好まれる点で、欠陥を被ることを指摘する価値はある。
統合 IS-IS は、OSPF アルゴリズムと似ているが、全く同じではないアルゴリズムを使用する。統合 IS-IS は異なる経路クラスのセットを使用し、サービスタイプの扱いが若干異なる。このアルゴリズムは、
統合 IS-IS は弱い TOS を使用するが、そのプロトコルは IP ヘッダ中の TOS フィールドで有り得る値のうち、小さい特定のサブセットの経路を運ぶ能力しか持っていない。TOS フィールド中に他の値を含んでいるパケットは、デフォルト TOS を使用して振り分けられる。
サービスタイプのサポートはオプションであり、もし使用不可ならば、四番目のステップは省略される。OSPF と同様に、この規定はポリシーステップを含まない。
このアルゴリズムは、改訂されたクラシックアルゴリズムよりも幾つかの長所を持つ。
しかし、このアルゴリズムは改訂されたクラシックアルゴリズムの短所の幾つかが残ったままである。
統合 IS-IS アルゴリズムは、更なる短所 (改訂されたクラシックアルゴリズムによって共有されていない) も持っている。IS-IS 経路が宛先アドレスと一致するビットが少なく、要求されたサービスタイプを提供しない場合でさえ、他のルーティングプロトコルから学んだ経路よりも IS-IS 内部 (イントラ領域かインター領域) 経路が常に優先であると見なす。これは、あらゆる場合に不適切であるとは限らないポリシー決定である。
最後に、IS-IS アルゴリズムの TOS のサポートは、OSPF アルゴリズムで注記されたものと同じ欠陥を被ることを指摘する価値はある。
このドキュメントの焦点はセキュリティよりも相互運用にあるが、ネットワークセキュリティに幾つか分岐する多くのセクションが、このドキュメントに明白に存在する。
セキュリティは様々な人々で様々なものを意味する。ルータの観点からのセキュリティは、自身のネットワーク運用を保つことを補助するものであり、加えてインターネット全体を健全に保つことを補助するものである。このドキュメントの目的では、関心のあるセキュリティサービスはサービスの拒否、完全性、その二つに適用される認証である。セキュリティサービスのプライバシは重要であるが、ルータに関しては補助的なものでしかない。少なくとも、このドキュメントの作成時点ではそうである。
このドキュメントの幾つかの場所で、セキュリティの考慮というタイトルが付けられている。これらのセクションは、議論中の一般的なトピックに適用される特定の考慮について論じている。
このドキュメントは、これを行えばルータ/ネットワークが安全であるということはほとんど述べていない。これを述べることは良い考えであり、そうすればインターネットやローカルシステムの通常のセキュリティを改善するかもしれない。
不幸にも、現在これは最高水準のものである。ルータが関心のあるネットワークプロトコルが、効率的で組込み型のセキュリティ機能をほとんど持っていない。工業やプロトコル設計者は、これらの問題にずっと苦慮し続けている。進展はあるが、BGP や OSPF ルーティングプロトコルで利用可能なペアツーペア認証等、小さい赤子のステップでしかない。
特にこのドキュメントは、ネットワークセキュリティの開発や拡張における現在の研究を注記している。この作成が進行中 (1993 年 12 月) である研究や開発、技術の特定の分野は、IP セキュリティや SNMP セキュリティ、共通認証技術である。
上記にもかかわらず、ルータのセキュリティを改善するためにベンダとユーザの両者が行うことのできるものがある。ベンダは、信頼できるコンピュータシステム解釈 [INTRO:8] のコピーを入手すべきである。たとえベンタがこれらのポリシーに基づく公式の確認のためにデバイスを提供しないことを決定したとしても、その出版物はコンピューティングデバイスに対して、一般的なセキュリティ設計や実践に関する優れたポリシーを提供する。
あるルーティングプロトコルはインターネットで共通であるが、このドキュメントの作者は良心的に使用することを推奨できない。それらが正しく動作しないからではなく、その設計 (単純ルーティング、ポリシー無し、共通の管理の下での単一の "コアルータ" ネットワーク、複雑さの制限、ネットワークの規模制限) において想定されたインターネットの特徴が、今日のインターネットの属性ではないからである。それらを依然使用しているインターネットの部分は、一般的に制限された複雑性を持つ制限された "外辺的" ドメインである。
実際の問題としては、その実装に関する冷静な思慮がこのセクションに記録される。
外部ゲートウェイプロトコル (EGP) は、同じか異なる自律システムのルータ間で、到達性情報を交換するために使用される EGP を規定する。EGP は、EGP 更新メッセージ中の距離フィールドにおいて標準的な解釈 (例えばメトリック) が存在しないため、ルーティングプロトコルとはみなされない。よって、距離は同じ AS のルータ内でしか比較できない。しかし、それは隣接者ルータと非隣接者ルータの両方に関して、高品質な到達性情報を提供するために設計される。
EGP は [ROUTE:6] によって定義されている。実装者は、ほぼ確実に [ROUTE:7] と [ROUTE:8] も読みたいだろう。それらは、有効な説明や背景資料を含んでいる。
DISCUSSION
既存の EGP 規約は重大な制限があり、最も重要な制限は、ルータがルータの自律システム内から到達可能なネットワークのみを通知することに制限されることである。サードパーティの
EGP 情報を通知することに対するこの制限は、長期生存ルーティングループを妨げることである。これは
EGP を 2 レベルの階層に効果的に制限する。
RFC-975 は EGP 規約の一部ではなく、無視すべきである。
間接隣接者 : 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 はポールコマンドを送信する直前に加算し、それ以外は加算しない。
RIP は [ROUTE:3] で規定されている。RIP はインターネットで依然として極めて重要であるが、洗練されたアプリケーションでは、上記に記述されているようなより近代的な IGP に置き換わりつつある。RIP を実装しているルータは、CODR 経路をサポートしているので RIP バージョン 2 [ROUTE:?] を実装すべきである (SHOULD)。予備アクセスネットワーキングを使用するならば、RIP を実装するルータは需要 RIP [ROUTE:?] を実装すべきである (SHOULD)。
RIP のもう一つの共通的な使用は、ルータ検出プロトコルである。セクション [4.3.3.10] がこの主題について詳細に触れている。
トポロジ変更の取り扱い : [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 である。
一番目のアルゴリズムは、
二番目のアルゴリズムは以下を除いて一番目と同じである。
トリガ更新 : [ROUTE:3],
ページ 15-16; ページ 29
トリガ更新 (フラッシュ更新とも呼ばれる)
は、ルータが経路を追加/削除した時やメトリックを変更した時に、ルータの隣接者に即座に通知するメカニズムである。ルータは経路が削除されたか、メトリックが増加した時、トリガ更新を送信しなければならない
(MUST)。ルータは経路が追加されたか、メトリックが減少した時、トリガ更新を送信してもよい
(MAY)。
トリガ更新は極端なルーティング負荷を引き起こし得るので、実装体はトリガ更新の頻度を制限するために以下のメカニズムを使用しなければならない (MUST)。
トリガ更新は、最も最近規則的な (非トリガ) 更新を送信してから変更した全ての経路を含むべきである (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
更新を処理する時、以下の正当性チェックを実行しなければならない。
DISCUSSION
幾つかのネットワーク、媒体、インタフェースは、送信側ノードがブロードキャストするパケットの受信を可能にする。ルータは自身のパケットを正しいルーティング更新として受け入れ、それを処理してはならない。最後の要件は、ルータが自身のルーティング更新を受け入れて処理することを避ける
(ネットワーク上の幾つかの他のルータによって送信されるという仮定に基づいて)。
実装体は、もし受信されたメトリックが既存のメトリックと等しいならば、以下の自発的判断に従うことを除いて、既存の経路と置き換えてはならない (MUST NOT)。
実装体は、上記の状況を扱うために以下の自発的判断の実装を選択してもよい (MAY)。通常、もし両方とも同じメトリックで通知されるならば、あるルータから別のルータへの経路を変更することは無駄である。しかし、ルータの一つによって通知されている経路はタイムアウトの処理中かもしれない。その経路がタイムアウトするのを待つ代わりに、指定された時間分経過した後、新しい経路を使用できる。もしこの自発的判断を実装するならば、新しい経路が導入される前の満了点の少なくとも半分は待たなければならない (MUST)。
RIP シャットダウン
RIP の実装体は、以下のステップを使用して上品なシャットダウンを提供すべきである
(SHOULD)。
DISCUSSION
上記のために使用されるメトリックは、実際には
16 (無限) であるべきである。15 に設定することは、RIP
プロトコルを盗聴するある古いホストの中断を避けるためのクラッジである。もしホストが宛先までの経路を持たない
(RIP が宛先までの代替パスを選択する間、たとえホストが経路を持たない時間がほんの数秒であっても)
コネクション上にデータグラムを送信しようとしたら、そのようなホストは、TCP
コネクションを (誤って) アボートするだろう。
RIP 水平分割と静的経路
水平分割は、デフォルトの静的経路に適用されるべきである
(SHOULD)。実装体は、静的経路に毎にこの経路に水平分割を適用しないことを指定する方法を提供すべきである
(SHOULD)。
ゲートウェイツーゲートウェイプロトコルは廃止されたと見なし、実装すべきでない (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.
このメモは、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
| Prev |