| Prev | Next |
このセクションは、パケットの転送プロセスについて規定している。
IP における転送機能の別の規定は存在しない。代わりに、転送はインターネット層プロトコルのプロトコル規定 ([INTERNET:1], [INTERNET:2], [INTERNET:3], [INTERNET:8], [ROUTE:11]) によってカバーされている。
主要なプロトコルドキュメントはどれも転送アルゴリズムを詳細に説明していないので、ここでそれを提供する。これは単に一般的な概要であり、例えば輻輳の扱いといった重要な詳細は略している。それらは後のセクションで扱っている。
実装体は、セクション [5.2.1.1],[5.2.1.2],[5.2.1.3] に記述されているアルゴリズムに正確に従う必要はない。ルータソフトウェアを書く挑戦の大半は、アルゴリズムと同じ効果を依然として達成しながらも、ルータがパケットを転送できる割合を最大化することである。それを行う方法の詳細は、ルータのアーキテクチャに強く依存する部分であるので、このドキュメントの適用範囲を超えている。その代わり、以下のステップの順序に従うことを指摘するだけである。
このセクションは、一般的な転送アルゴリズムをカバーしている。このアルゴリズムは転送するパケットの全ての形式、ユニキャスト、マルチキャスト、ブロードキャスト、に適用される。
(1) ルータはリンク層から IP パケット (とセクション [3.1] に記述されているような、それに関する追加情報)を受信する。
(2) ルータは、セクション [5.2.2] で規定されているように IP ヘッダを評価する。ステップ (4) のローカル配送のためにキューイングされた IP フラグメントを除いて、IP の組み立ては行わないことに注意されたい。
(3) ルータは、IP オプションの大半の処理を実行する。セクション [5.2.4] で規定されているように、幾つかの IP オプションはルーティングの決定を行った後で追加の処理を必要とする。
(4) ルータはセクション [5.2.3] で規定されているように、IP データグラムの処理をどのように継続すべきかを決定するために、IP データグラムの宛先 IP アドレスをチェックする。起こりえることは三つある。
ローカル配送の場合は、[INTRO:2] によって十分にカバーされているので、以下は IP データグラムが転送のためにキューイングされているものと仮定する。もし、その宛先が IP ユニキャストアドレスならば、
(5) 転送者は、通常ルータのルーティングテーブルにパケットの宛先を検索することによって、そのパケットに対し次のホップの IP アドレスを決定する。この手続きは、セクション [5.2.4] で詳細に規定されている。この手続きは、パケットを送信するのにどのネットワークインタフェースを使用するかも決定する。
(6) 転送者は、パケットの転送が許されているかを検証する。送信元と宛先アドレスは、セクション [5.3.7] とセクション [5.3.4] で規定されているように、正しいべきである。もしルータが転送において、例えばセクション [5.3.9] に規定されているような管理上の制約をサポートしているならば、それらの制約を満たさなければならない。
(7) 転送者は、セクション [5.3.1] で規定されているようにパケットの TTL を減らし (少なくとも 1)、チェックする。
(8) 転送者は、ステップ 3 で完了できなかった IP オプションの処理を全て実行する。
(9) 転送者は、セクション [4.2.2.7] で規定されているように必要な IP 分割を実行する。このステップは出力インタフェースの選択 (ステップ 5) の後で発生するので、同じデータグラムの全てのフラグメントは同じインタフェースに送出されるだろう。
(10) 転送者はパケットの次ホップのリンク層アドレスを決定する。これを行うメカニズムは、リンク層依存である (チャプタ 3 参照)。
(11) 転送者は、IP データグラム (あるいはその各々のフラグメント) を適切なリンク層フレームでカプセル化し、ステップ 5 で選択されたインタフェース上に出力するためにキューイングする。
(12) 転送者は、セクション [4.3.3.2] で規定されているように、必要ならば ICMP リダイレクトを送信する。
もし宛先が IP マルチキャストならば、以下のステップを実施する。
IP ユニキャストの転送と IP マルチキャストの転送との主要な相違点は、
IP マルチキャストの転送は、まだ若干実験的である。結果として、以下に提供されているアルゴリズムは必須ではなく、単なる例としてのみ提供されることに注意されたい。
(5a) データグラムヘッダにある IP 送信元と宛先アドレスに基づいて、ルータはデータグラムを転送のための適切なインタフェース上で受信したか否かを決定する。もし否ならば、そのデータグラムを黙って破棄する。適切な受信インタフェースを決定する方法は、使用するマルチキャストアルゴリズムに依存する。最も簡単なアルゴリズムの一つの逆経路転送 (RPF: reverse path forwarding) では、適切なインタフェースはデータグラムの送信元にユニキャストで転送するために使用する一つである。
(6a) データグラムヘッダにある IP 送信元と宛先アドレスに基づいて、ルータはデータグラムを出力するインタフェースを決定する。IP マルチキャストの拡張リング検索を実装するために ([INTERNET:4] 参照)、最小の TTL 値が各々の出力インタフェースとして指定される。マルチキャストデータグラムのコピーは、最小の TTL 値がデータグラムヘッダ中の TTL 値以下である各々の出力インタフェースに、各々のインタフェース上で残りのステップを別個に適用することによって転送される。
(7a) ルータはパケットの TTL を一つ減らす。
(8a) 転送者は、ステップ(3)で完了していない全ての IP オプション処理を実行する。
(9a) 転送者は、セクション [4.2.2.7] で規定されている必要な IP 分割を実行する。
(10a) 転送者は、リンクレベルのカプセル化で使用するリンク層アドレスを決定する。これを行うためのメカニズムは、リンク層依存である。LAN 上では、データグラムの IP マルチキャストアドレスのアルゴリズム変換として、リンク層マルチキャストかブロードキャストが選択される。詳細については、様々な xxx 上の IP 規定を参照されたい。
(11a) 転送者は、パケット (あるいはその各々のフラグメント) を適切なリンク層フレームにカプセル化し、適切なインタフェース上に出力するためにキューイングする。
ルータは如何なる IP パケットも処理が可能になる前に、ヘッダが意味あることを保証するために、パケットの IP ヘッダに対して以下の基本的な評価チェックを実施しなければならない (MUST)。もしパケットが以下のテストに失敗したら、ルータは黙って破棄しなければならず (MUST)、そのエラーはログに採取すべきである (SHOULD)。
ルータは、これらのテストを不能にする設定オプションを持ってはならない (MUST NOT)。
もしパケットが二番目と三番目のテストに通過し、その IP ヘッダ長フィールドは少なくとも 4 で、IP 全体長とリンク層によって通知されるパケット長が両方とも少なくとも 16 ならば、上記の規則にも関わらず、ルータはポインタが IP ヘッダ長フィールド (もし四番目のテストに失敗したら) を指すか、IP 全体長フィールド (もし五番目のテストに失敗したら) を指す、ICMP パラメタ問題メッセージで応答してもよい (MAY)。しかし、ルータはそのパケットを破棄しなければならず (MUST)、依然としてログに採取すべきである (SHOULD)。
これらの規則 (とこの全体のドキュメント) は、インターネットプロトコルのバージョン 4 にのみ適用される。これらの規則を、ルータが IP の他のバージョンをサポートすることを禁じていると解釈すべきではない。さらに、もしルータが IP の他の幾つかのバージョンとして正しくパケットを分類できるならば、このメモのコンテキストの範囲内でそのパケットを異常として扱うべきではない。
IMPLEMENTATION
常に完全に可能であるとは限らないが、エラー通知の目的で何故ヘッダが不正であるかを決定することが望ましい。以下の四つの理由がありえる。
この順番が最もエラーの原因を正しく分類すると思われるので、記述された順序通りに実行することが恐らく望ましいだろう。エラー通知の目的で、これらのテストに失敗したパケットが IPng か ST-II を示す IP バージョン番号を持っているか否かをチェックすることも望ましいかもしれない。これらは関連する規約に従って取り扱うべきである。
加えて、ルータはリンク層によって通知されるパケット長が、少なくともパケット IP ヘッダに記録された IP 全体長の大きさであることを検証すべきである (SHOULD)。もしパケットが落とされているようならば、そのパケットを破棄しなければならず (MUST)、エラーをログに採取すべきであり (SHOULD)、ポインタが IP 全体長フィールドを指す ICMP パラメタ問題メッセージで応答すべきである (SHOULD)。
DISCUSSION
データが最終宛先に到達した時に、データの改変に関係する何らかの上位層プロトコルが、パケットデータが落ちていることを検出するので、ルータが上記で提案されているプロトコルの正当性を維持するためのチェックを実行することは、絶対的に必要であるというわけではない。しかし、このチェックを行うことによって、ルータは経路中のどのホップがそのパケットを落としたかを決定する作業を、かなり簡単にすることができる。また、下流のシステムはそのパケットを扱う必要が無いので、そのルータから下流の資源を減らすことにもなる。
最後に、IP ヘッダ中の宛先アドレスがルータのアドレスの一つでないならば、ルータはパケットが厳密な送信元と記録経路オプションを含まないことを検証すべきである。もしパケットがこのテストに失敗したら (厳密な送信元経路オプションを含むならば)、ルータはそのエラーをログに採取すべきであり (SHOULD)、ポインタが問題のあるパケットの IP 宛先アドレスを指す、ICMP パラメタ問題エラーで応答すべきである (SHOULD)。
DISCUSSION
ある人は、ルータはパラメタ問題メッセージではなく、不正な送信元経路メッセージで応答すべきであると提案するかもしれない。しかし、不正な送信元経路は送信元ホストが存在しないものを、あるいはネットワークを通って壊れたパスを要求したことを示すのに対して、パケットがこのテストに失敗した時は通常、直前のホップのルータによるプロトコルエラーを示す。
ルータが IP パケットを受信した時、ルータはそのパケットがルータ宛てである (そしてローカルに配送すべき) か、別のシステム宛てである (そして転送者によって扱うべき) かを決定しなければならない。ある IP ブロードキャストや IP マルチキャストが、ローカルに配送されるのと転送されるのと両方ある混成ケースも存在する。ルータは以下の規則を使用して、これらの三つのケースのどれに当てはまるかを決定しなければならない (MUST)。
DISCUSSION
四番目の段落の最後のセンテンスの要件の目的は、同じ物理ケーブル上の別のネットワークプレフィクスへの直接ブロードキャストを扱うことである。通常、これは送信者がリンク層ユニキャストとしてルータにブロードキャストを送信したと想定して動作する。ルータはそれがユニキャストとして到着したことに示し、従って送信者が送信したのとは異なるネットワークプレフィクス宛てに向けなければならない。従って、ルータはそのパケットが到着した所と同じ
(物理) インタフェースに、リンク層ブロードキャストとして安全に送信できる。しかし、もしルータがそのパケットをリンク層ユニキャストとして受信したか否かを通知できないならば、そのセンテンスは、安全でないが正しいことよりはむしろ安全だが誤っていることをルータが行うことを保証している。
IMPLEMENTATION
セクション [5.3.4] で規定されているように、リンク層ブロードキャストとして受信したパケットは一般的には転送されない。そのセクションの規則のため、後で破棄されるパケットを転送者に渡すことを避けることは都合がよいかもしれない。
幾つかのリンク層は、(ハードウェアのためかドライバの特殊コードのためかのいずれかにより) 全てのリンク層ブロードキャストや送信されたマルチキャストのコピーをルータに配送できる。この機能を使用すると、パケットを転送者に渡してローカルにも配送するケースの実装を簡素化できる。なぜなら、パケットを転送することにより自動的にルータがパケットのコピーを受信でき、その後でローカルに配送することができる。これらの環境では、受信したループバックパケットを、受信した (そして転送規則に適う等) 通常のパケットとして扱うことを避けるよう注意しなければならない。
ローカルに配送されたパケットに対して組み立ては実行するが、転送するパケットには実行しないので、フラグメントには注意しなければならないが、たとえそのようなリンク層でなくても、無論、転送とローカル配送の両方に対してキューイングするために、パケット全体のコピーを作成する必要はほとんど無い。一つの簡単なスキームは、ルータの出力キュー上にある各々のパケットに、そのパケットを送信した後にローカル配送のためにキューイングすべきか否かを示すフラグを割り当てることである。
ルータがパケットを転送する時、その宛先に直接送信するか、別のルータを通して渡す必要があるかを決定しなければならない。もし後者ならば、どのルータを使用するかを決定する必要がある。このセクションは、どのようにこれらの決定を行うかを説明している。
このセクションは、決定に際して以下を使用する。
もし、
次の IP 宛先アドレスは、そのオプションによって指されたアドレスである。もし、
そのメッセージは、そのメッセージを解析するシステム宛てである。
ルータはパケットの扱い方を決定する際、最終の宛先アドレス (送信元経路オプションの最終アドレス) ではなく、IP 宛先アドレスを使用しなければならない (MUST)。
データグラムに一つ以上の送信元経路オプションが現われることはエラーである。もしルータがそのようなデータグラムを受信したら、ルータはパケットを破棄し、ポインタが二番目目の送信元経路オプションの始めを指す ICMP パラメタ問題メッセージで応答すべきである (SHOULD)。
セクション [5.2.3] で規定された規則に従って IP パケットを転送する必要があると決定した後、隣接した宛先が直接アクセス可能か否かを決定する ([INTERNET:2] 参照) ために、以下のアルゴリズムを使用しなければならない (MUST)。
(1) IP アドレスが割り当てられていない各々のネットワークインタフェース (セクション [2.2.7] に記述されているようなアンナンバードの回線) に対しては、回線の他方の終端のルータ ID を IP 宛先アドレスと比較する。もしそれが正確に一致しているならば、そのパケットはこのインタフェースを通じて転送できる。
DISCUSSION
言い換えると、回線のリモート側の終端のルータかホストは、パケットの宛先か、送信元経路付きのパケットの送信元経路中の次のステップである。
(2) ルータに割り当てられた各々の IP アドレスに対して、一番目のステップでネットワークインタフェースが選択されなかったならば、
(a) インタフェースによって使用されるネットワークプレフィクスを抜き出す。
IMPLEMENTATION
この処理の結果は、大抵初期化の間に既に算出され保持されているだろう。
(b) パケットの IP 宛先アドレスから対応する一連のビットを抜き出す。
(c) 結果とした割り出したネットワークプレフィクスを比較する。もしそれらがお互いに等しいならば、対応するネットワークインタフェースを通じてそのパケットを送信できる。
(3) もし宛先がアンナンバードインタフェース上の隣接者のルータ ID でも、直接接続されたネットワークプレフィクスのメンバでもないならば、IP 宛先は他の幾つかのルータを通じてしかアクセスできない。ルータと次ホップの IPアドレスの選択については、セクション [5.2.4.3] で規定されている。ルータでないホストの場合、これは設定されたデフォルトルータであるかもしれない。
IETF [ARCH:9, NRHP] での継続中の作業では、例えば複数の IP (サブ) ネットワークが同じリンク層ネットワーク上に存在する時といった、幾つかのケースを考慮している。ポリシーによる制限が無ければ、共通のリンク層ネットワークを使用しているホストやルータは、もし適切な情報が提供されているならば、たとえ同じ IP (サブ) ネットワークに存在しなくとも直接通信することができる。次ホップルーティングプロトコル (NHRP: Next Hop Routing Protocol) は、IP エンティティが、リモートの宛先に向けてリンク層ネットワークを横切るために使用する「最適な」リンク層アドレスを決定することを可能にする。
(4) もし選択された「次ホップ」が、NHRP を使用するよう設定されたインタフェースを通じて到達可能ならば、以下の追加ステップが適用される。
(a) IP 宛先アドレスを NHRP キャッシュ中の宛先アドレスと比較する。もしアドレスがキャッシュ中のアドレスならば、そのデータグラムを対応するキャッシュされたリンク層アドレスに送信する。
(b) もしアドレスがキャッシュ中のアドレスでないならば、IP 宛先アドレスを含む NHRP 要求パケットを作成する。このメッセージは、そのインタフェースに設定された NHRP サーバに送信される。これは論理的にルータ自身の別のプロセス、又はエンティティであってもよい。
(c) NHRP サーバは、そのデータグラムと、後に続く同じ宛先へのデータグラムを送信するために使用する適切なリンク層アドレスをもって応答するだろう。システムは、NHRP 応答を待つ間、伝統的な「次ホップ」ルータにそのデータグラムを送信してもよい (MAY)。
EDITORS+COMMENTS
ルータは、IP 宛先アドレスが隣接しているか否かを決定するために、前のセクションのアルゴリズムを適用する。もし隣接しているならば、次ホップアドレスは
IP 宛先アドレスと同じである。隣接していなければ、そのパケットを別のルータに転送して、それの隣接した宛先に到達させなければらない。このルータの選択が、このセクションの主題である。
もしパケットが SSRR を含むならば、ルータはそのパケットを破棄し、ICMP 不正送信元経路エラーで応答しなければならない (MUST)。さもなくば、ルータは適切な次ホップアドレスを決定するために、自分のルーティングテーブル中に IP 宛先アドレスを検索する。
DISCUSSION
IP 規定により、厳密な送信元経路はパケットが横切らなければならない一続きのノードを指定しなければならならない。つまり、そのパケットは送信元経路の一つのノードから次へ、間にネットワークのみを媒介して横切らなければならない。従って、もしルータが送信元経路の次のステップに隣接していなければ、送信元経路を満たすことができない。よって、ルータはそのようなパケットを
ICMP 不正送信元経路エラーで拒否する。
次ホップ選択処理の目標は、ルータの転送情報ベース (FIB: Forwarding Information Base) 中にエントリを検査し、FIB 中の利用可能な経路からそのパケットにとっての最善経路を (もし存在するならば) 選択することである。
概念的に、経路検索アルゴリズムは、FIB 全体の内容を構成する一組の候補の経路から開始する。アルゴリズムは、その組みから経路を破棄する一連のステップで構成される。これらのステップは枝刈り規則 (Pruning Rules) と呼ばれる。通常、アルゴリズムが完了する時、ちょうど一つの経路がその組みの中で残る。もしその組みが空になったら、そのパケットは宛先が未到達なので破棄される。また、その組みで一つ以上の経路が残っている時にアルゴリズムが完了することも有り得る。この場合、ルータはそれらのうち一つ以外の全てを任意に破棄してよいし、最も最近使用されていない経路を選択することによって「負荷分散」を実行してもよい。
規則 3 (弱い TOS) の例外で、ルータはパケットの次ホップを選択する際、次の枝刈り規則を使用しなければならない (MUST)。ルータが次ホップを決定する際 TOSを考慮するならば、以下に示された順番で規則 3 を適用しなければならない。これらの規則は (概念的に)、出現した順番で FIB に適用しなければならない (MUST)。(歴史的な見地や、追加の枝刈り規則や他の一般アルゴリズムの使用については、付録 E を参照されたい)。
DISCUSSION
セクション [5.3.2] は転送を決める時ルータのみが TOS を考慮すべき (SHOULD) であると述べているので、規則 3 は任意である。
(1) 基本照合
この規則は、パケットの IP 宛先アドレス以外の宛先への経路を全て破棄する。例えば、もしパケットの IP 宛先アドレスが 10.144.2.5
ならば、このステップはネットワークプレフィクス 10.0.0.0/8 や 10.144.0.0/16 への経路やデフォルト経路は残すが、ネット 128.12.0.0/16 への経路は破棄する。
より正確に言えば、各々の経路は route.dest と呼ばれる宛先属性と、route.dest のどのビットに意味があるかを示す route.length と呼ばれる対応プレフィクス長を持つと仮定する。転送されるパケットの IP 宛先アドレスは、ip.dest である。この規則は、route.dest と ip.dest の最上位の route.length ビットが等しいものを除いて、一組の候補から全ての経路を破棄する。
例えば、もしパケットの IP 宛先アドレスが 10.144.2.5 で、10.144.1.0/24, 10.144.2.0/24, 10.144.3.0/24 のネットワークプレフィクスが存在するならば、この規則は 10.144.2.0/24 のみを残す。それは、プレフィクスがパケットの IP 宛先アドレス中の対応ビットと同じ値を持つ唯一の経路である。
(2) 最長照合
最長照合は、上述されている基本照合の改善である。基本照合による枝刈りを実施した後、アルゴリズムは残った経路を検査して、どれが最長の
route.length 値を持つかを決める。これらを除く全ては破棄する。
例えば、もしパケットの IP 宛先アドレスが 10.144.2.5 で、10.144.2.0/24 と 10.144.0.0/16 と 10.0.0.0/8 のネットワークプレフィクスが存在するならば、この規則はそのプレフィクス長が最長なので、一番目 (10.144.2.0/24) のみを残す。
(3) 弱い TOS
各々の経路は route.tos と呼ばれるサービス属性のタイプを持ち、その有り得る値は IPヘッダの TOS フィールドで使用される値と同じであると仮定する。TOS
情報を配送するルーティングプロトコルは、route.tos を FIB に追加する経路に適切に記入する。他のルーティングプロトコルによる経路は、デフォルト TOS (0000)
を持つものとして扱う。振り分けようとしているパケットの IP ヘッダ中の TOS フィールドは ip.tos と呼ばれる。
経路の候補の組みは、route.tos = ip.tos である経路を含むか否かを決定するために検査される。もし含むならば、route.tos = ip.tos を除く全ての経路が破棄される。もし含まないならば、route.tos = 0000 を除く全ての経路が候補の組みから破棄される。
弱い TOS に基づくルーティングの追加の議論は、[ROUTE:11] にある。
DISCUSSION
この規則の効果は、パケットで要求された TOS に一致する TOS
を持つ経路のみを選択することである。そのような経路が存在しない場合は、デフォルトの
TOS を持つ経路が考慮される。パケットで要求されてなくデフォルトでない
TOS を持つ経路は、たとえパケットの宛先へ行くのにその経路しか利用可能な経路がなくとも決して使用されない。
(4) 最善メトリック
各々のメトリックは、route.metric と呼ばれるメトリック属性と、route.domain
と呼ばれるルーティングドメイン識別子を持つ。候補経路の組みの各々のメンバは、その組みの他の各々のメンバと比較される。もし route.domain
が二つの経路で等しく、route.metric
が一方と比較して厳密に劣っているならば、劣ったメトリックを持った方の経路は、その組みから破棄される。幾つかのプロトコルはより複雑な比較を必要とする構造化されたメトリックを持つかもしれないが、劣っているかを決める方法は通常単純な算術比較である。
(5) ヘンダポリシー
ベンダのポリシーは、前に一覧化されている規則ではありえる経路から選択するのに不適切であることが多いという事実を補うための、ある種のキャッチオールである。ベンダポリシーの枝刈り規則は、極めてベンダ固有である。セクション
[5.2.4.4] を参照されたい。
このアルゴリズムには、以下の二つの異なる欠点がある。恐らくルータ実装者は、これらの欠点を扱うための技術を開発し、ベンダポリシーの枝刈り規則の一部にするかもしれない。
(1) IS-IS と OSPF 経路クラスは、全く扱われない。
(2) サービスタイプ以外のパスプロパティ (例えば MTU) が無視される。
TOS がサポートされる方法の欠陥に気づく価値もある。0 でない TOS 値を持つパケットを転送する時に、TOS をサポートするルーティングプロトコルが暗黙的に選ばれる。
基本照合と最長照合の枝刈り規則は、経路の数多くの特定のタイプの扱いを一般化する。これらの経路は以下の減少、優先順位で選択される。
(1) ホスト経路 : これは特定の終端システムへの経路である。
(2) 階層的なネットワークプレフィクス経路: これは特定のネットワークプレフィクスへの経路である。FIB がお互い
(あるプレフィクスは付加ビットを持った他のプレフィクスである)
を包含するネットワークプレフィクスへの複数の経路を含むかもしれないことに注意されたい。これらは、プレフィクス長の短い順序で選択される。
(5) デフォルト経路 : これは明示的な経路が無い場合の全てのネットワークへの経路である。それは、定義上プレフィクス長が 0 の経路である。
もし枝刈り規則の適用後に経路の組みが空 (すなわち経路が見つからない) ならば、そのパケットを破棄して、適切な ICMP エラーを生成しなければならない (MUST)。(もし IP 宛先アドレスが送信元経路オプションのものならば ICMP 不正送信元経路、さもなくばセクション [4.3.3.1] で規定されているように、ICMP 宛先ホスト到達不可か宛先ネットワーク到達不可のどちらも適切である) 。
ベンダポリシーの枝刈り規則として提案されているメカニズムは、管理上の優先度を使用することである。それは、単純な優先順位付けアルゴリズムである。この考えは、複数の中から一つを選択する必要がある経路の優先度を手動で付けることである。
各々の経路は、経路の様々な属性に基づいて優先値を割り当てる (優先値の割当ての特定のメカニズムは以下に提案されている)。この優先値は、[0...255] の範囲の整数値で、 0 が最も優先度が高く、254 が最も優先度が低い。255 は特別な値であり、その経路は決して使用すべきでないことを意味する。ベンダポリシーの枝刈り規則の第一ステップは、最も優先度の高い経路を除く、全ての経路を破棄することである (優先度の値が 255 である経路は常に破棄する)。
このポリシーはたやすく誤って用いられ、ルーティングループを引き起こしえる点で安全ではない。ルータに設定される優先度が、その隣接者に設定される優先度と矛盾が無いことを保証するプロトコルは存在しないので、ネットワーク管理者が優先度を設定する際は注意しなければならない。
・アドレス照合
宛先の特定の組みへの (同一のルーティングドメインから教わった)
経路全てに、一つの優先度値を割り当てられることは便利である。その場合、宛先の組みは特定のネットワークプレフィクスと一致する全ての宛先である。
・経路クラス
区別を維持するルーティングプロトコルにとって、特定の経路クラス (イントラ域、インター域、内部メトリクスを持った外部、外部メトリクスを持った外部)
を持つ (同一のルーティングドメインから教わった) 経路全てに、一つの優先度値を割り当てられることは便利である。
・インタフェース
パケットがルータの特定の論理インタフェース (複数の IP
アドレスが、それに割り当てられた複数の論理インタフェースを持つことを除いて、論理インタフェースは通常、ルータのネットワークインタフェースに 1 対 1 でマッピングされる) に振り分けられる
(同一のルーティングドメインから教わった) 経路全てに、一つの優先度値を割り当てられることは便利である。
・送信元ルータ
ルータの幾つかの組みから教わった (同一のルーティングドメインから教わった)
経路全てに、一つの優先度値を割り当てられることは便利である。その場合、ルータの組みは、その更新が特定のネットワークプレフィクスと一致する送信元アドレスを持つものである。
・起動側 AS
情報を提供するルーティングプロトコルにとって、別の特定のルーティングドメインで起動した (同一のルーティングドメインから教わった) 経路全てに、一つの優先度値を割り当てられることは便利である。BGP
経路の場合、起動側 AS は経路の AS_PATH 属性で一覧化されたうちの一番目の AS である。OSPF
外部経路の場合、もしタグの自動ビットが設定され、タグのパス長が 3 でないならば、起動側 AS は経路の外部経路タグの下位 16 ビットと見なしてもよい。
・外部経路タグ
外部経路タグが特定の値のリストに一致する (同一のルーティングドメインから教わった)
OSPF 外部経路全てに、一つの優先度値を割り当てられることは便利である。外部経路タグは構造化された値を持ってもよいので、タグの特定のサブフィールドと照合する機能を提供することは便利かもしれない。
・AS パス
AS パスが特定の値の組みに "一致する" (同一のルーティングドメインから教わった)
BGP 経路全てに、一つの優先度値を割り当てられることは便利である。どのような種類の照合が最も効果的であるかは、まだはっきりと明確になっていない。単純なオプションは、経路の AS_PATH 属性のどこかに出現する
(あるいは出現しない) 全ての経路の照合を可能にすることである。より一般的だがより難しい代替手段は、AS パスが特定の正規表現に一致する全ての経路の照合を可能にすることである。
次ホップ選択処理の最後で、複数の経路がまだ残るかもしれない。この場合、ルータは幾つかの選択肢がある。ルータは経路の幾つかを任意に破棄してもよい。ルータは、同等とみなされないルーティングドメインからの経路のメトリクスを比較することによって、代表経路の数を減らしてもよい。ルータは一つ以上の経路を保持し、それらの中でトラフィックを配分する負荷分散メカニズムにかけてもよい。おそらく、この選択肢の相対的な利点について言えるのは、負荷分散がある状況では効果的であり、また別の状況では効果的でないということだけである。従って、負荷分散を実装する賢い実装者は、ネットワーク管理者がそれを無効にする方法も提供するだろう。
IP ヘッダは、サービスタイプフィールドとフラグフィールドの中に幾つかの予約ビットを含む。ルータは、単にこれらのビットの一つ以上が 0 でないという理由だけで、パケットを落としてはならない (MUST NOT)。
ルータはこれらの予約ビットの値を無視しなければならず (MUST)、値を変更せずに渡さなければならない (MUST)。もしルータがパケットを分割するならば、これらのビットを各々のフラグにコピーしなければならない (MUST)。
DISCUSSION
IP プロトコルの将来の改訂は、これらのビットを使用するかもしれない。これらの規則は、インターネット中の全てのルータを同時にアップグレードすることなく、これらの改訂が展開できることを保証することを意図している。
セクション [4.2.2.7] で論じられているように、ルータは IP 分割をサポートしなければならない (MUST)。
ルータは、転送する前に如何なるデータグラムも組み立ててはならない (MUST NOT)。
DISCUSSION
何人かの人々は、ルータによるデータグラム通過時の再組み立てが、パフォーマンスを改善するようなトポロジーがあるかもしれないことを提案した。フラグメントが宛先へ異なるパスを通るかもしれないという事実は、そのような機能の安全な使用を妨げる。
このセクションは、ルータによってリンク層の機能として実行される分割、組み立てを制御、あるいは制限すると解釈すべきでない。
同様にもし IP データグラムが別の IP データグラムにカプセル化され (例えばトンネル化)、そのデータグラムが代わりに分割されるならば、そのフラグメントは元のデータグラムを転送するために組み立てなければならない。このセクションは、これを除外していない。
一般的な要件は、セクション [4.3] で論じられている。このセクションは、ルータによって送信される ICMP メッセージについてのみ論じる。
ICMP 宛先未到達メッセージは、宛先 (あるいは次ホップ) が到達不可か、サービスが利用不可であるために転送できないパケットに対する応答として、ルータによって送信される。このようなケースの例では、そこにおらず、それ故に ARP 要求に応答しないホスト宛てのメッセージや、ルータが正しい経路を持っていないネットワークプレフィクス宛てのメッセージを含む。
ルータは、ICMP 宛先未到達メッセージを生成できなければならず (MUST)、そのメッセージを生成した理由に最も近い応答コードを選択すべきである (SHOULD)。
以下のコードは、[INTERNET:8] と [INTRO:2] で定義されている。
0 = ネットワーク未到達 - 宛先ネットワークへの転送パス (経路) が利用できない場合に、ルータによって生成される。
1 = ホスト未到達 - 直接接続されたネットワーク上で宛先ホストへの転送パス (経路) が利用できない (ARP に応答しない) 場合に、ルータによって生成される。
2 = プロトコル未到達 - データグラムで指定されたトランスポートプロトコルが、最終宛先のトランスポート層でサポートされていない場合に生成される。
3 = ポート未到達 - 指定されたトランスポートプロトコル (例えば UDP) が、最終宛先のトランスポート層でデータグラムを逆多重化できないが、それを送信側に通知するメカニズムをプロトコルが持たない場合に生成される。
4 = 分割が必要で DF が設定 - ルータがデータグラムを分割する必要があるが、DF フラグが設定されているために分割できない場合に生成する。
5 = 送信元経路失敗 - ルータが送信元経路オプションの次ホップにパケットを転送できない場合に生成される。
6 = 未知の宛先ネットワーク - これは、ルータとしては宛先ネットワークが存在しないことを暗黙的に意味するので、このコードは生成すべきでない (SHOULD NOT)。(コード 6 の代わりにネットワーク未到達コードの 0 を使用すべきである (SHOULD))。
7 = 未知の宛先ホスト - ルータが、宛先ホストが存在しないことを (リンク層の通知より) 決定できない場合にのみ生成する。
11 = サービスタイプに対するネットワーク未到達 - 要求された、あるいはデフォルトの TOS を持つ宛先ネットワークへの転送パス (経路) が利用できない場合に、ルータによって生成される。
12 = サービスタイプに対するホスト未到達 - 宛先への経路がデータグラムで要求された TOS か、デフォルト TOS (0) のいずれかに一致しないためにパケットを転送できない場合に、ルータによって生成される。
以下の追加コードがここに定義される。
13 = 管理上禁止された通信 - ルータがパケットを管理上のフィルタにより転送できない場合に生成される。
14 = ホスト優先度違反。要求された優先度が送信元/宛先ホスト、ネットワーク、上位層プロトコル、送信元/宛先ポートの特定の組み合わせに対して許可されていないことを示すために、そのホストへの第一ホップのルータによって送信される。
15 = 優先度による遮断結果。ネットワーク運用者が、運用において必要な優先度の最小レベルを課し、データグラムがこのレベルを下回って送信された。
注記: [INTRO:2] は、分離された送信元ホストとしてコード 8 を定義している。ルータはコード 8 を生成すべきでなく (SHOULD NOT)、コード 0 (ネットワーク未到達) とコード 1 (ホスト未到達)のどちらか適切なコードを代わりに使用すべきである (SHOULD)。[INTRO:2] は、管理上禁止された宛先ネットワークとの通信に対してコード 9 と、管理上禁止された宛先ホストとの通信に対してコード 10 も定義している。これらのコードは、米国軍事機関で使用されるエンドツーエンドの暗号デバイスで使用することを意図している。もしパケットを管理上フィルタにかけるならば、ルータは新たに定義されたコード 13 (管理上禁止された通信) を使用すべきである (SHOULD)。
ルータは、コード 13 (管理上禁止された通信) のメッセージを生成しない通信オプションを持ってもよい (MAY)。このオプションが可の場合、転送が管理上禁止されているという理由で落とされたパケットの応答として、ICMP エラーメッセージは送信されない。
同様にルータは、コード 14 (ホスト優先度違反) とコード 15 (優先度による遮断結果) のメッセージを生成しない通信オプションを持ってもよい (MAY)。このオプションが可の場合、優先度違反の理由で落とされたパケットの応答として、ICMP エラーメッセージは送信されない。
ルータは、同じ宛先ネットワーク上の他のホストが到達可能であるかもしれない時は、ホスト未到達か未知の宛先ホストを必ず使用しなければならない (MUST)。さもなくば、送信元ホストはそのネットワーク上の全てのホストが未到達であると誤って結論づけ、そのケースではないかもしれない場合がある。
[INTERNET:14] は、コード 4 (分割が必要で DF が設定) を含む宛先未到達メッセージの形式のわずかな修正を規定している。ルータはコード 4 の宛先未到達メッセージを生成する時、この修正された形式を使用しなければならない (MUST)。
ICMP リダイレクトメッセージは、トラフィックのあるクラスに対し異なる次ホップのルータを使用すべきであることを、ローカルホストに通知するために生成される。
ルータは、[INTERNET:8] で規定されているネットワークのためのリダイレクトか、ネットワークとサービスタイプのためのリダイレクトメッセージ (コード 0 と 2) を生成してはならない (MUST NOT)。ルータは、[INTERNET:8] で規定されたホストのためのリダイレクトメッセージ (コード 1) を生成できなければならず (MUST)、サービスタイプとホストのためのリダイレクトメッセージ (コード 3) を生成できるべきである (SHOULD)。
DISCUSSION
もし直接接続されたネットワークが (古典的な意味で)
サブネットでないならば、ルータは通常、特定のリモートネットワーク上の全てのホストに適用するネットワークリダイレクトを生成できる。ホストリダイレクトの代わりにネットワークリダイレクトを使用することは、ネットワークトラフッィクやホストのルーティングテーブル領域にとって、わずかに経済的かもしれない。しかし、その節約は重要なものではなく、サブネットは、ネットワークリダイレクトを解釈するために使用されるサブネットマスクに関する曖昧性を生む。CIDR
環境では、ネットワークリダイレクトが使用されるケースを正確に特定することが難しい。従って、ルータはホスト
(またはホストとサービスタイプ) リダイレクトのみを送信しなければならない。
コード 3 (ホストとサービスタイプのためのリダイレクト) メッセージは、リダイレクトの要因となったパケットが、ルータによって選択されたパスが要求された TOS に (部分的に) 依存する宛先を持つ場合に生成される。
コード 3 リダイレクト (ホストとサービスタイプ) を生成できるルータは、コード 3 リダイレクトの代替としてコード 1 (ホスト) リダイレクトを利用可能にするために、設定オプション (デフォルトがオン) を持たなければならない (MUST)。もしそのオプションがそのように設定されているならば、ルータはコード 3 リダイレクトの代わりにコード 1 リダイレクトを送信しなければならない (MUST)。
もしルータがコード 3 リダイレクトを生成できないならば、コード 3 リダイレクトを要する時に、その代替としてコード 1 を生成しなければならない (MUST)。
ルータは以下の条件が適わないならば、リダイレクトメッセージを生成してはならない (MUST NOT)。
ICMP リダイレクトで使用される送信元アドレスは、宛先アドレスと同じ論理 (サブ) ネットワークに属さなければならない (MUST)。
(静的ルーティング以外の) ルーティングプロトコルを使用するルータは、パケットを転送する際に、ICMP リダイレクトから知ったパスを考慮してはならない (MUST NOT)。もしルータがルーティングプロトコルを使用していないならば、ルータは、もし設定されたら、パケットを転送する時に、ICMP リダイレクトを通じて知った経路を考慮することを可能にするような設定を持ってもよい (MAY)。
DISCUSSION
ICMP リダイレクトは、ルータがルーティング情報をホストに伝達するためのメカニズムである。ルータはルーティング情報を知るために他のメカニズムを使用すので、リダイレクトに従う理由はない。ルータの他の情報に反するリダイレクトを信じることにより、ルーティングループを引き起こすかもしれない。
一方、ルータがルータとして振る舞わないならば、ホストに要求された動作に従わなければならない (MUST)。
ルータは、TTL フィールドの満了によりパケットを破棄する時、時間超過メッセージコード 0 (通過中) を生成しなければならない (MUST)。ルータは、インタフェース上でこれらのメッセージの生成を不可にするためのオプションをインタフェース毎に持ってもよい (MAY)。しかし、そのオプションはデフォルトで、そのメッセージの生成を可能にしなければならない (MUST)。
IGMP [INTERNET:4] は、単一の物理ネットワーク上で、特定のマルチキャストグループ内のホストのメンバシップを確立するための、ホストとマルチキャストルータ間で使用されるプロトコルである。マルチキャストルータは、インターネットを渡る IP マルチキャスト転送をサポートするために、マルチキャストルーティングプロトコルと共にこの情報を使用する。
ルータは、IGMP のマルチキャストルータ部を実装すべきである(SHOULD)。
IP ヘッダの生存時間 (TTL) フィールドは、データグラムの生存時間を限定するタイマとして定義されている。それは 8 ビットフィールドで単位は秒である。パケットを処理する各々のルータ (あるいは他のモジュール) は、たとえ経過した時間が 1 秒よりもずっと小さくても、TTL を少なくとも 1 減らさなければならない (MUST)。大抵はこのケースなので、TTL は、インターネットを通じてデータグラムを伝達させることができる有効なホップ数の制限である。
ルータがパケットを転送する時、TTL を少なくとも 1 減らさなければならない (MUST)。もしルータが 1 秒以上パケットを保持するならば、各秒につき 1 ずつ TTL を減らしてもよい (MAY)。
もし TTL が 0 (以下) に減らされるならば、そのパケットを破棄しなければならず (MUST)、もし宛先がマルチキャストアドレスでないならば、ルータは ICMP 時間超過メッセージ、コード 0 (通過中に TTL 超過) メッセージを送信元に送信しなければならない (MUST)。ルータは、0 でない TTL を持つ IP ユニキャストかブロードキャストパケットを、単に、そのパケットの最終宛先へのパス上の別のルータが TTL を 0 に減らすことを予測できるという理由で破棄してはならない (MUST NOT)。しかしルータは、IP マルチキャストの拡張リング検索アルゴリズム ([INTERNET:4] 参照) をより効率的に実装するために、IP マルチキャストに対してはそうしてもよい (MAY)。
DISCUSSION
IP TTL は、ホップ数制限と時間制限の両方として幾らか支離滅裂に使用される。そのホップ数機能は、ルーティングの問題によりネットワーク内でパケットの無限ループを引き起こすことによるネットワークの崩壊が起きないことを保証するために重要である。時間制限機能は、例えば
TCP のようなトランスポートプロトコルによって、信頼できるデータ転送を保証するために使用される。多くの現在の実装は、TTL
を純粋なホップ数として扱う。時間制限機能は、それを必要とするトランスポートプロトコルが代わりに実行すべきであるという強い意見が、インターネット社会の一部にはある。
この規約では、時間制限機能はオプションであるべきというルータベンダ間の強い信念に従うことに不本意ながら決定した。彼らは、時間制限機能の実装は現在一般に行われておらず、かなり難しいものであることを主張した。彼らは更に、この近道によって TCP のデータ破壊が引き起こされるケースは証拠資料が無いことを指摘した (もちろんこの問題が発生することは希で、再現することは困難であると予想される。 従って、証拠資料が無いというのは、記録に残されていないケースはほとんど起こらないことを示しているわけではない)。
拡張リング検索のような IP マルチキャストの考えは、TTL を純粋なホップ数として扱わなければ、期待通りに動作しないかもしれない。traceroute についても同じ事が言える。
ICMP 時間超過メッセージは、traceroute 診断ツールがこれに依存しているので必要である。
従って、もし除かなければ二つの非常に便利なツールにとって害になることと、全く発生しないかもしれない非常に希で一時的なデータ転送の問題を回避することとのトレードオフである。我々は、ツールを残すことを選択した。
IP ヘッダ中のサービスタイプのバイトは、三つのセクションに分割される。それは、優先度フィールド (上位 3 ビット)、慣例的にサービスタイプ、または
"TOS" と呼ばれるフィールド (次の 4 ビット)、予約ビット (下位ビット) である。予約ビットを管理する規則は、セクション
[4.2.2.3]
で規定されている。優先度フィールドは、セクション [5.3.3]
で論じられる。TOS フィールドとその使用についてのより広範な議論は、[ROUTE:11] で見ることができる。
ルータは転送方法を決定する時、パケットの IP ヘッダ中の TOS フィールドを考慮すべきである
(SHOULD)。このセクションの残りは、この要件に従うルータに適用される規則を規定する。
ルータは、ルーティングテーブルの各々の経路に対して、TOS 値を保持しなければならない (MUST)。TOS をサポートしていないルーティングプロトコルを通じて知った経路は、0 の TOS (デフォルト TOS) を割り当てなければならない (MUST)。
宛先への経路を選択するために、ルータは以下と同等のアルゴリズムを使用しなければならない (MUST)。
DISCUSSION
TOS は過去ほとんど使用されていないが、ホストによるその使用はインターネットホスト要件の
RFC ([INTRO:2] と
[INTRO:3])
では義務である。ルータでの TOS のサポートは、将来
MUST になるかもしれない。しかし、我々がより多くの経験を積み、利益と代価の両方をより良く判断できるまで、SHOULD
とする。
様々な人が、TOS は転送機能の他の面に作用すべきであると提案している。例えば、
これらのアイデアは [INTERNET:17] でより詳細に調査されているが、この分野に要件を設けるにはそのようなスキームについてまだ十分な経験が無い。
このセクションは、ルータにおける IP 優先度フィールドの適切な処理についての要件とポリシーを規定する。優先度は、異なるトラフィックフローの相対的な重要性に基づいた、ネットワークでの資源の割当てのためのスキームである。IP 規約は、トラフィックの様々なタイプに対して、このフィールドで使用する特定の値を定義している。
ルータにおける優先度処理の基本的なメカニズムは優先的な資源割当てであり、優先順序化されたキューサービスと優先度に基づく輻輳制御の両方と、リンク層の優先権機能の選択を含む。ルータは、ルーティングやルータが元となるトラフィックの管理と制御のための IP 優先度も選択する。IP 優先度のより拡張された議論とその実装については [FORWARD:6] を参照されたい。
優先度順序キューサービスは、このセクションで論じられているように、転送処理のためのキューと出力リンクのためのキューを含むが、それに限定してはいない。これは、優先度をサポートしているルータは、例えばパケットバッファやリンク層コネクションといった固定の資源を割り当てる点においても、優先度指示を使用すべきであることを意図している。一連のそうした点は、実装に依存する。
DISCUSSION
優先度フィールドは元々、大きなトラフィックの急増やネットワークへの主要な障害が本来の脅威であると見なされる DOD
システムで使用するために提供されたが、それは、多くの非軍事 IP
ネットワークでも効果的に適用できる。ネットワークのトラフィック制御能力は、近年非常に大規模になったけれども、ユーザのトラフィック生成能力もまた大きくなり、ネットワーク負荷状態は依然として時々発生する。IP
ベースのルーティングや管理プロトコルは、インターネットの継続的な運用にとってますます不可欠になりつつあるので、負荷は以下の二つの付加的な危険をネットワークにもたらす。
優先度メカニズムの実装と適切な使用は、これらの問題の両方を軽減する。
ルータは優先度順序キューサービスを実装すべきである (SHOULD)。優先度順序キューサービスは、パケットが (論理) リンク上の出力のために選択されるとき、キューイングされた優先度の最も高いパケットが、そのリンクに対して送信される。優先度順序キューサービスを実装しているルータは、インターネット層で優先度順序キューサービスを抑制するための設定オプションも持たなければならない (MUST)。
如何なるルータも、厳密な順序付け以外の結果をもたらす他のポリシーに基づくスループット管理手続きを実装してもよい (MAY) が、それを抑制する (すなわち厳密な順序付けを使用する) よう設定できなければならない (MUST)。
セクション [5.3.6] に詳述されているように、優先度順序キューサービスを実装しているルータは、輻輳制御目的で、高優先度のパケットを破棄する前に低優先度のパケットを破棄する。
先取り (処理の割り込みやパケットの転送) は、インターネット層の機能として想定されていない。他の層における幾つかのプロトコルは、先取り機能を提供してもよい。
優先度順序キューイングをサポートするルータは、下位層優先度マッピングを実装しなければならず (MUST IMPLEMENT)、サポートしないルータは下位層優先度マッピングを実装すべきである (SHOULD IMPLEMENT)。
下位層優先度マッピングを実装するルータは、
DISCUSSION
幾つかの調査により、幾つかのリンク層プロトコルの優先度機能の動作は疑わしく、幾つかのネットワークにはリンク層優先度メカニズムの実装に欠陥があるかもしれない。そのような問題がネットワークに見られる場合、回避メカニズムを提供することは賢明であるようだ。
一方、マルチメディア帯域の予約や低遅延サービスといった特別なサービスを実装するために、斬新なキューイング戦略を使用する提案がある。それらをサポートする特殊なサービスやキューイング戦略は現在の研究テーマであり、標準化の作業中である。
実装者は、IP 優先度の正しいリンク層マッピングが、DOD ネットワークで使用される TCP/IP システムのための DOD ポリシーによって要求されることを考慮したいかもしれない。その要件は、より良いインターネットサービスを全てのユーザに提供することを期待して、優先度機能の使用を推奨 (強制ではない) する意図があるので、優先度順序キューサービスをサポートするルータは、要求されたサービスタイプに関わらず、デフォルトで厳密な優先度順序を維持すべきである。
ルータは (優先度順序キューサービスを用いるか否かに関わらず):
(1) 管理上でそうしない設定がなされていないならば、全ての優先度レベルのトラフィックを正常に受諾し、処理しなければならない (MUST)。
(2) 特定のトラフィック源による優先度レベルの使用を管理上制限する評価フィルタを実装してもよい (MAY)。もし提供するならば、このフィルタは次の ICMP エラーメッセージの類を除外したり、落としてはならない (MUST NOT): 宛先未到達、リダイレクト、時間超過、パラメタ問題。もしこのフィルタを提供するならば、アドレスによるパケットフィルタに必要な手続きは、このフィルタにも必要とされる。
DISCUSSION
優先度フィルタは特定の送信元/宛先 IPアドレスの組み合わせやプロトコル、特定のポート等に適用できるべきである。
もし設定での選択で抑制されていないならば、評価フィルタによってパケットを落とした時は、コード 14 を持つ ICMP 宛先未到達メッセージを送信すべきである (SHOULD)。
(3) 指定されたレベルよりも低い優先度を持つトラフィックを拒否したり、落とすような設定をルータで可能にする、遮断機能を実装してもよい (MAY)。この機能は、管理作業や自発的診断による実装によって作動させもよいが、人間の干渉無しで運用する自発的診断メカニズムを不可にする設定オプションを持たなければならない (MUST)。もし設定での選択で抑制されていないならば、遮断機能によってパケットを落とした時、コード 15 を持つ ICMP 宛先未到達メッセージを送信すべきである (SHOULD)。
ルータは、単に優先度遮断を理由に IP 優先度 6 (内部ネットワーク制御) か 7 (ネットワーク制御) を持つデータグラムの転送を拒否してはならない (MUST NOT)。しかし、高優先度トラフィックをフィルタにかけるために、優先度遮断と組み合わせて別の基準を使用してもよい。
DISCUSSION
無制限の優先度遮断は、ルーティングやトラフィック制御の意図しない遮断を結果として招き得る。一般的な場合、ホストトラフィックは 5 (CRITIC/ECP)
の値かそれ以下に制限すべきであるが、これは要件ではなく、あるシステムでは正しくないかもしれない。
(4) 起動していないパケットの優先度設定を変更してはならない (MUST NOT)。
(5) (どの優先度値を使用しなければならないかを規定する OSPF 等のプロトコルを除いて) サポートされている各々のルーティングや管理プロトコルで使用する優先度値とは別の値を設定できるべきである (SHOULD)。
(6) 各アドレスの組み合わせに対し、独立してルーティングや管理トラフィックの優先度を設定できてもよい (MAY)。
(7) リンク層の優先度関連エラー指示に、提供された所で適切に応答しなければならない (MUST)。もし設定での選択で抑制されていないならば、優先度関連の条件によりリンクが受諾できないためにパケットが落ちた時、コード 15 を持つ ICMP 宛先未到達メッセージを送信するべきである (SHOULD)。
DISCUSSION
(3) に記述されている優先度遮断メカニズムについては議論されている。遮断によって影響を受けるエリアのトポロジ上の位置に依存して、通過トラフィックはパケットが落とされる場合、ルーティングプロトコルによって遮断のエリアに向けられるかもしれない。遮断によって影響を受けない別のパスが通信ポイント間に存在する場合に、唯一問題がある。この問題を避けるのに提案されている方法は、たとえ負荷状態であっても最小限の帯域を全ての優先度レベルに提供することや、遮断情報をルーティングプロトコルで通知することを含む。この問題に対して広く受け入れられた
(実装された) 解決方法が無い中、通過ネットワークで遮断メカニズムを動作させる際は、十分注意することが推奨される。
トランスポート層中継は、上記 (4) で禁止された機能を合法的に提供できる。優先度レベルの変更は、TCP とおそらく他のプロトコルに微妙な相互作用を及ぼすかもしれない。正しく設計することは重要な作業である。
(5) と (6) (とセクション [4.3.2] の ICMP メッセージ中の IP 優先度の議論) の意図は、このルータが他の方法でそれらのビットに基づいて動作するか否かに関わらず、IP 優先度ビットを適切に設定すべきであるということである。ルーティングプロトコルやネットワーク管理プロトコルの将来の規約で、それらのプロトコルによって送信されるメッセージに対して IP 優先度をどのように設定すべきかが規定されることを期待する。
(7) の適切な応答は、使用するリンク層プロトコルに依存する。通常、ルータはある期間その宛先への攻撃的なトラフィックの送信の試みを止めるべきであり、コード 15 (要求された優先度のためのサービスが利用不可) を持つ ICMP 宛先未到達メッセージを、そのトラフィックの送信元へ返却すべきである。ルータはまた、先取りされたリンク層コネクションの再確立をしばらくの間試みるべきでもない。
(PPP を除く) 大半のリンク層プロトコルでの IP パケットのカプセル化は、受信側が単純にリンク層のプロトコルヘッダ (最も共通的には、リンク層宛先アドレス) を調べることによって、ブロードキャストとマルチキャストをユニキャストから区別することを可能にする。このセクションにおけるリンク層ブロードキャストを参照する規則は、ブロードキャストの区別を可能にするリンク層プロトコルにのみ適用される。また、リンク層マルチキャストを参照する規則は、マルチキャストの区別を可能にするリンク層プロトコルにのみ適用される。
もし IP マルチキャストアドレスに向けられていないならば、ルータはリンク層ブロードキャストとして受信した如何なるパケットも転送してはならない (MUST NOT)。後者のケースでは、あるものは効果的なマルチキャストサービスが無いためにリンク層ブロードキャストが使用されたと推測するだろう。
もしパケットの宛先アドレスが IP マルチキャストアドレスでないならば、ルータはリンク層マルチキャストとして受信した如何なるパケットも転送してはならない (MUST NOT)。
ルータは、リンク層ブロードキャストによって受信したパケットを黙って破棄すべきである (SHOULD) が、IP マルチキャストか IP ブロードキャスト宛先アドレスかの特定はしない。
ルータがリンク層ブロードキャストとしてパケットを送信する時、IP 宛先アドレスは正しい IP ブロードキャストか IP マルチキャストアドレスでなければならない (MUST)。
IP ブロードキャストアドレスには、二つの主要なタイプが在る。それは、限定ブロードキャストと直接ブロードキャストである。加えて、直接ブロードキャストには三つのサブタイプが在る。それは、特定のネットワークプレフィクスに向けられたブロードキャスト、特定のサブネットに向けられたブロードキャスト、特定のネットワークの全てのサブネットに向けられたブロードキャストである。ルータによるブロードキャストのこれらのカテゴリの一つへの分類は、ブロードキャストアドレスと、宛先ネットワークのサブネット構造のルータの理解 (もしあれば) に依存する。同じブロードキャストは、異なるルータによって別々に分類される。
限定 IP ブロードキャストアドレスは、全て 1 : { -1, -1 } か 255.255.255.255 であると定義される。
ネットワークプレフィクス直接ブロードキャストは、ローカル部が全て 1 の IPアドレスのネットワークプレフィクス、あるいは { <Network-prefix>, -1 } で構成される。例えば、クラス A ネットワークのブロードキャストアドレスは net.255.255.255 であり、クラス B ネットワークのブロードキャストアドレスは net.net.255.255 であり、クラス C ネットワークのブロードキャストアドレスは net.net.net.255 である。net は、ネットワークアドレスの 1 バイトである。
全サブネット直接ブロードキャストは CIDR 環境ではうまく定義されておらず、このメモのバージョン 1 で反対された。
セクション [4.2.3.1] に記述されているように、ルータは以下の非標準の IP ブロードキャストアドレスに遭遇するかもしれない。
そのセクションに記述されているように、これらのアドレスのどれかのアドレスを持つパケットは黙って破棄すべきである (SHOULD) が、もしそうでないならば、上記で説明されたブロードキャストアドレスの廃止されていない形式のアドレスを持つパケットに適用される同じ規則に従って扱わなければならない (MUST)。これらの規則は、次の 2, 3 セクションで規定される。
限定ブロードキャストは転送してはならない (MUST NOT)。限定ブロードキャストは破棄してはならない (MUST NOT)。限定ブロードキャストは、限定ブロードキャストで十分の場合、直接ブロードキャストの代わりに送信してもよく (MAY)、送信すべきである (SHOULD)。
DISCUSSION
幾つかのルータは、(ユニキャストか直接ブロードキャストとして)
要求を他のサーバに再送する機能を持つ UDP
サーバを含む。この要件は、そのようなサーバを禁じていると解釈すべきではない。しかし、そのようなサーバはもし誤って構成されたら、簡単にパケットループを引き起こすことに注意されたい。従って、そのようなサーバの提供者はおそらく、注意深くセットアップすることや送信パケットの
TTL を慎重に考慮すべきであることを、ドキュメントで十分に忠告するだろう。
ルータは、全ての正しい、リモートネットワークあるいは接続されたサブネット化されていないネットワーク宛ての直接ブロードキャストを、ネットワークプレフィクス直接ブロードキャストとして分類しなければならない (MUST)。CIDR の観点では、それはネットワークプレフィクス内のホストアドレスとして現れることに注意されたい。我々は、そのようなネットワークプレフィクスのホスト部の点検を除外する。経路が与えられ、最優先のポリシーが無いならば、ルータはネットワークプレフィクス直接ブロードキャストを転送しなければならない (MUST)。ネットワークプレフィクス直接ブロードキャストは送信してもよい (MAY)。
ルータは、あるインタフェース上で、ネットワークプレフィクス直接ブロードキャストの受信を不可にするオプションを持ってもよく (MAY)、ネットワークプレフィクス直接ブロードキャストの転送を不可にするオプションを持たなければならない (MUST)。これらのオプションはデフォルトで、ネットワークプレフィクス直接ブロードキャストの受信や転送を許さなければならない (MUST)。
DISCUSSION
直接ブロードキャストを転送するか転送しないかについて、幾つかの議論がなされている。このメモでは、ルータの宛先ネットワークプレフィクスの知識に従って転送するという決定をした。この知識無しで、ルータはメッセージがユニキャストか直接ブロードキャストかを決定することはできない。メッセージを転送するか転送しないかの決定は、最終ホップのルータでのみ可能な定義である。
このメモの最初の版は、古典的なネットワーク番号の全てのサブネットへの直接ブロードキャストを配送するためのアルゴリズムを説明した。このアルゴリズムは "壊れた" と明記され、ある失敗ケースが示された。
CIDR ルーティングドメインでは、古典的な IP ネットワーク番号は意味を持たず、全サブネット直接ブロードキャストの概念もまた意味を持たない。ワーキンググループの認識では、その設備は決して実装されないし提供されず、現在歴史のごみ箱に捨てられている。
このメモの最初の版は、サブネッと直接ブロードキャストを扱うための手続きを説明した。CIDR ルーティングドメインでは、これらはネットワーク直接ブロードキャストと識別できない。従って、この二つはセクション [5.3.5.2 直接ブロードキャスト] で一緒に扱われ、ネットワークプレフィクス直接ブロードキャストとして見るべきである。
ネットワークにおける輻輳は、リソースの需要 (大抵帯域か CPU 時間) が許容量を超えた状態として大雑把に定義されている。輻輳回避は許容量を超える需要を防ぐ試みで、輻輳回復は適切な運用状態に回復する試みである。ルータがこれらのメカニズムの両方に貢献することは可能である。その問題の検討には多大な労力が費やされた。読者は、この作業を調べるために [FORWARD:2] を読むことが望ましい。その主題についての重要な紙面は、他の中でも [FORWARD:6]、[FORWARD:4]、[FORWARD:5]、[FORWARD:10]、[FORWARD:11]、[FORWARD:12]、[FORWARD:13]、[FORWARD:14]、[INTERNET:10] を含む。
ホストが [FORWARD:5] で説明されているような効率的な輻輳ポリシーを用いる時に、ルータが一時的な需要のピークを扱うために利用可能にすべき記憶装置の量は、パスがリンクを使用するフローを遅延させるリンク時間と帯域の積の機能である。従って、この帯域×遅延の積が増えるに従って記憶装置を増やすべきである。破棄する可能性に関係する記憶装置の許容量の正確な機能は未知である。
ルータが記憶装置の許容量を超えてパケットを受信した時、そのパケットか、他の幾つかのパケットを破棄しなければならない (規定ではなく定義による)。どのパケットを破棄するかは要検討項目であるが、不幸にもこれまでのところほとんど合意を得られていない。これまでの最善の叡智は、データストリームから最も大量にリンクを使用しているパケットの破棄を提案する。しかし、トラフィックの優先度や活性帯域の予約、そのパケットの選択に関連した複雑性を含め、数多くの追加要因が関係するかもしれない。
ルータは単に受信したパケットを破棄してもよい (MAY)。これは最も簡単であるが最善のポリシーではない。理想的には、もし適用可能なサービス品質ポリシーがこれを許すならば、ルータは最もひどくリンクを乱用しているセッションの一つからパケットを選択すべきである。
FIFO キューを使用するデータグラム環境で推奨されるポリシーは、キューから選択したパケットをランダムに破棄することである ([FORWARD:5] 参照)。公正なキューを使用しているルータと同等のアルゴリズムは、最も長いキューから破棄することか、あるいは最も大きい仮想時間 ([FORWARD:13] 参照) を使用することである。ルータは、どのパケットを破棄するかを決定するために、これらのアルゴリズムを使用してもよい (MAY)。
もしルータが、適格なパケットのプールから破棄するためのパケットを選択する破棄ポリシー (例えばランダムドロップ) を実装するならば:
輻輳制御の進歩した方法は公正さの概念を含む。そのため、パケットを失うことによって罰則を科せられた 'ユーザ' は最も輻輳の一因となったものである。帯域輻輳制御を扱うためにどんなメカニズムが実装されていても、消費される CPU の負荷は、ルータが CPU の輻輳にも追いこまれない程十分に小さいことが重要である。
セクション [4.3.3.3] で説明されているように、このドキュメントは、ルータが破棄したパケットの送信側に送信元抑制を送信すべきでない (SHOULD NOT) ことを推奨する。ICMP 送信元抑制は非常に弱いメカニズムである。従って、ルータはそれを送信する必要はないし、ホストソフトウェアはそれを輻輳を示すものとして全面的に使用すべきではない。
IP 送信元アドレスは、もしセクション 4.2.2.11 や 5.3.7 で定義されているような特別な IP アドレスか、ユニキャストアドレスでないならば不正である。
IP 宛先アドレスは、セクション 4.2.3.1 の違反した宛先として定義されたものの中にあるか、クラス E アドレス (255.255.255.255 を除く) ならば不正である。
ルータは、不正な IP 送信元アドレスか、ネットワーク 0 の送信元アドレスを持つ如何なるパケットも転送すべきでない (SHOULD NOT)。ルータは、ループバックインタフェースを除き、ネットワーク 127 の送信元アドレスを持つ如何なるパケットも転送すべきでない (SHOULD NOT)。ルータは、ネットワーク管理者がこれらのチェックを不可にすることを可能にするスイッチを持ってもよい (MAY)。もしそのようなスイッチを提供するならば、そのデフォルトはチェックを実行するようにしなければならない (MUST)。
ルータは、不正な IP 宛先アドレスかネットワーク 0 の宛先アドレスを持つ如何なるパケットも転送すべきでない (SHOULD NOT)。ループバックインタフェースを除き、ネットワーク 127 の宛先アドレスを持つ如何なるパケットも転送すべきでない (SHOULD NOT)。ルータは、ネットワーク管理者がこれらのチェックを不可にすることを可能にするスイッチを持ってもよい (MAY)。もしそのようなスイッチを提供するならば、そのデフォルトはチェックを実行するようにしなければならない (MUST)。
もしルータがこれらの規則が故にパケットを破棄するならば、少なくとも IP 送信元アドレス、IP 宛先アドレスを、そしてもし問題が送信元アドレスにあるならば、パケットを受信した物理インタフェースとパケットを受信したホストかルータのリンク層アドレスをログに採取すべきである (SHOULD)。
ルータは、パケットの送信元アドレスとパケットを受信した論理インタフェース用の転送テーブルの比較に基づいて、トラフィックをフィルタする能力を実装すべきである (SHOULD IMPLEMENT)。もしこのフィルタが利用可能ならば、ルータはもしパケットを受信したインタフェースが、送信元アドレスに含まれているアドレスに到達させるためにパケットを転送するインタフェースでないならば、そのパケットを黙って破棄しなければならない (MUST)。同様に、もしルータがこのアドレスを含むパケットを、特定のインタフェースを通じて振り分けないならば、このインタフェースから読み込んだアドレス中の送信元アドレスとして現われているならば、そのアドレスを信じるべきではない。
もしこの機能を実装するならば、デフォルトでは不可にしなければならない (MUST)。
DISCUSSION
この機能は、ある状況で有効なセキュリティ改善を提供できるが、パスが非対称である状況では正しいパケットを誤って破棄し得る。
ネットワークの部分を通じてセキュリティとトラフィック制限を提供する手段として、ルータはパケットを選択して転送する (フィルタする) 機能を提供すべきである (SHOULD)。もしこの機能を提供するならば、パケットのフィルタは全パケットを転送するか、送信元と宛先のプレフィクスに基づいてそれらを選択して転送するかを設定可能にすべきであり (SHOULD)、他のメッセージ属性に基づいてフィルタしてもよい (MAY)。各送信元と宛先アドレスは、任意のプレフィクス長の指定を可能にすべきである (SHOULD)。
DISCUSSION
この機能によりある程度のプライバシーを提供でき、境界の外側のシステムが境界の内側のシステムとのあるプロトコルの交換を許可しない、あるいはどのシステムと通信してもよいかを制限することができる。また、境界の外側のシステムが境界の内側のシステムに成りすましたり、そのセッションを真似るような、ある種のセキュリティ破りを防ぐことができる。
もしサポートするならば、ルータは以下の一つを許可するよう設定可能にすべきである (SHOULD)。
この文脈における「メッセージ定義」は送信元と宛先のネットワークプレフィクスを示し、IP プロトコルタイプや TCP ポート番号等の他の識別情報を含んでもよい。
ルータは、包含リストや除外リストやそれと同等の制御間での選択を可能にする設定スイッチを提供してもよい (MAY)。
如何なるアドレスとも一致する値 (例えばエニイのキーワード、全て 0 のマスクを持つアドレス、長さが 0 であるネットワークプレフィクス) を、送信元と宛先アドレスとして許さなければならない (MUST)。
アドレスのペアに加えて、ルータはトランスポートやアプリケーションプロトコル、送信元と宛先ポートの指定を可能にしてもよい (MAY)。
ルータはパケットを黙って破棄する (すなわち ICMP エラーメッセージを送信しない) ことを可能にしなければならない (MUST)。
ルータは、パケットを破棄する時、適切な ICMP 未到達メッセージの送信を可能にすべきである (SHOULD)。ICMP メッセージは、宛先未到達の理由として通信管理上禁止 (コード 13) を指定すべきである (SHOULD)。
ルータは、指定を許可されたアドレスペア、プロトコルタイプ、ポートの各々の組み合わせに対して、ICMP 宛先未到達メッセージ (コード 13) の送信を設定可能にすべきである (SHOULD)。
ルータは転送しないパケットを数えるべきであり (SHOULD)、ログの採取を選択できるべきである (SHOULD)。
IP ルータは、IP マルチキャストパケットの転送を、静的マルチキャスト経路か、マルチキャストルーティングプロトコル (例えば DVMRP [ROUTE:9]) によって動的に決定された経路のいずれかに基づいてサポートすべきである (SHOULD)。IP マルチキャストパケットを転送するルータは、マルチキャストルータと呼ばれる。
各々の物理インタフェースに対して、ルータは転送がそのインタフェース上で可能にするか否かを指定する、設定オプションを持つべきである (SHOULD)。インタフェース上で転送が不可の場合、ルータは、
DISCUSSION
この機能により、ネットワーク管理者は本質的にインタフェースを閉じるが、ネットワーク管理のためにアクセス可能なままにすることが可能である。
理想的には、その制御は物理インタフェースではなく、論理インタフェースに適用される。論理インタフェースと物理インタフェースが 1 対 1 対応でない場合、パケットが到着した論理インタフェースをルータが決定する一般的な方法は存在しない。
ルータの稼動中に、インタフェースが異常になるか手動で使用不可になるかもしれないし、ルータによって使用が可能になるかもしれない。同様に、転送が特定のインタフェースやルータ全体で使用不可かもしれないし、(再度) 使用可能かもしれない。そのような変化は (通常) 珍しいが、ルータがそれらを正しく処理することは重要である。
ルータが転送を止める時、サードパーティ経路を除いて全てのルータへの通知を止めなければならない (MUST)。受信と、自分のルーティングドメイン内の他のルータからの経路の使用は継続してもよい (MAY)。もし転送データベースが保持されるならば、ルータは転送データベース中の経路のタイマ計測を止めてはならない (MUST NOT)。もし他のルータから受信した経路を記憶しているならば、覚えている経路のタイマ計測を止めてはならない (MUST NOT)。転送不能の間にタイマが満了した経路は、転送可能だった場合と同じように破棄しなければならない (MUST)。
DISCUSSION
ルータが転送を止める時、ルータが本質的にルータであることを止める。ルータは依然としてホストであり、ホスト要件
[INTRO:2]
の要件の全てに従わなければならない。しかしながら、ルータは依然として一つ以上のルーティングドメインの受動的なメンバであってもよい。その場合、そのルーティングドメイン中の他のルータをリッスンすることによって、転送データベースを保持することが可能である。しかし、ルータ自身は転送を実行しないので、転送データベース中の如何なる経路も通知しなくてよい。この規則の唯一の例外は、ルータが他のルータのためだけに使用する経路を通知する場合であり、このルータは通知することが求められる。
ルータは、ICMP 宛先未到達 (ホスト未到達) メッセージを転送できないパケットの送信者に送信してもよい (MAY)。ルータは、ICMP リダイレクトメッセージを送信すべきでない (SHOULD NOT)。
DISCUSSION
ICMP 宛先未到達 (ホスト未到達)
を送信することは、ルータの動作である。このメッセージは、ホストが送信すべきでない。ホストに対するこの規則の例外は許されており、それにより最短時間で再振り分け可能になるかもしれないし、ブラックホールを避けられるかもしれない。
ルータが転送を開始する時、ルータは正常に経路情報を交換する全てのルータへ、新しい経路情報を手早く送信すべきである (SHOULD)。
もしインタフェースが障害か使用不可である時、ルータはそのインタフェースを使用する転送データベース中の全ての経路を削除し、通知を止めなければならない (MUST)。ルータは、そのインタフェースを使用する全ての静的経路を使用不可にしなければならない (MUST)。もし同じ宛先と TOS の他の経路をルータによって知らされ覚えているならば、そのルータは最善の代替を選択し、転送データベースに追加しなければならない (MUST)。ルータは、インタフェースが使用不可になったことによって転送できない全てのパケットに対する応答として、適宜 ICMP 宛先未到達か ICMP リダイレクトメッセージを送信すべきである (SHOULD)。
もし使用不能なインタフェースが使用可能になった時、ルータはそのインタフェースを使用する全ての静的経路を再度使用可能にしなければならない (MUST)。もしルータがその経路をルータによって知らされたら、これらの経路を他の全ての認識している経路と共に評価し、転送データベース中にどの経路を置いておくべきかを決定しなければならない (MUST)。どのようにこの決定を下すかの詳細情報について、実装者はチャプタ [7] アプリケーション層 - ルーティングプロトコルを参照されたい。
ルータが転送を開始する時、ルータは正常に経路情報を交換する全てのルータへ、新しい経路情報を手早く送信すべきである (SHOULD)。
経路記録やタイムスタンプ等の幾つかのオプションは、パケットを転送する時にルータが自身のアドレスを挿入するスロットを含む。しかし、各々のそうしたオプションはスロットの固定番号を持ち、そのために自身のアドレスを挿入できる空きスロットが存在しないことがあるかもしれない。挿入する残りのスロットが無いオプションに、ルータがアドレスを挿入する必要があると解釈すべき要件は、以降のリストにはない。セクション [5.2.5] は、オプションに挿入する自身のアドレスをどのようにルータが選択しなければならないかを論じている。
転送パケット中の認識できない IP オプションは、変更せずにパススルーしなければならない (MUST)。
ある環境では、全てのパケットにセキュリティオプションを必要とする。そうした要件は、このドキュメントや IP 標準規約の適用外である。しかし、[INTERNET:1] と [INTERNET:16] で規定されているセキュリティオプションは廃止されていることに注意されたい。ルータは、[INTERNET:5] で規定されている改訂版セキュリティオプションを実装すべきである (SHOULD IMPLEMENT)。
DISCUSSION
複数のセキュリティレベルを持つネットワークで使用することが意図されたルータは、IPSO
(RFC-1108) ラベルに基づくパケットフィルタをサポートすべきである。このサポートを実装するために、ルータは低次セキュリティ制限
(例えば分類無し) と高次セキュリティ制限 (例えば秘密)
の両方を、ルータ管理者が各々のインタフェースに設定することを可能にする必要があるだろう。二つの制限が同じである
(例えば単一レベルインタフェース) ことは普通だが常にそうとは限らない。範囲外であるために
IPSO フィルタに捉えられるパケットは黙って落とされるべきであり、カウンタは
IPSO ラベルの範囲外のために落とされたパケットの個数を控えておくべきである。
このオプションは廃止された。もしストリーム識別子オプションがルータによって転送されるパケットに存在したら、そのオプションを無視して、変更せずにパススルーしなけれはならない (MUST)。
ルータは、転送パケット中の送信元経路オプションのサポートを実装しなければならない (MUST)。ルータは、使用可で設定されている場合に送信元経路付きのパケットを全て破棄する設定オプションを実装してもよい (MAY)。しかし、そのオプションはデフォルトでは使用可にしてはならない (MUST NOT)。
DISCUSSION
インターネットを通じた送信元経路データグラムの能力は、様々なネットワーク診断ツールのために重要である。しかし、送信元ルーティングをネットワーク内のバイパス管理やセキュリティ制御で使用してもよい。特に、パケットフィルタ等の他の方法の代わりに管理上の分離を提供するためにルーティングテーブルの操作が用いられる場合、送信元経路付きのパケットによって害を被りやすいかもしれない。
EDITORS+COMMENTS
もし送信元経路付きのパスの最終区間を除く全てのルータに適用されるならば、パケットフィルタは送信元ルーティングによっても無効になりえる。経路もパケットフィルタも、セキュリティのための完全な解決にはならない。
ルータは、転送パケット中の経路記録オプションのサポートを実装しなければならない (MUST)。
ルータは、もし使用可ならばルータが転送パケットで記録経路オプションを無視する (すなわち変更せずにパススルーする) 設定オプションを提供してもよい (MAY)。もし提供するならば、そのオプションはデフォルトで経路記録を使用可にしなければならない (MUST)。このオプションは、ルータ自身によって受信されたデータグラム中の経路記録オプションの処理に影響してはならない (特に ICMP エコー要求中の経路記録オプションは、依然としてセクション [4.3.3.6] に従って処理される)。
DISCUSSION
経路記録はネットワークのトポロジについての情報を明らかにするので、セキュリティ上問題であると考える人はいる。従って、このドキュメントは使用不可にすることを許している。
ルータは、転送パケット中でタイムスタンプオプションをサポートしなければならない (MUST)。タイムスタンプ値は [INTRO:2] の規則に従わなければならない (MUST)。
もしフラグフィールド = 3 ならば (タイムスタンプと事前指定アドレス)、ルータはもし事前指定アドレスがルータの IP アドレスのいずれかと一致するならば、タイムスタンプを追加しなければならない (MUST)。事前指定アドレスは、パケットの到着したインタフェース上のアドレスか、パケットを送信しようとしているインタフェース上のアドレスのいずれかである必要はない。
IMPLEMENTATION
タイムスタンプオプションに含まれるタイムスタンプの有用性を最大限に活用するために、パケットがルータに到着した時間と実際に近い時間を挿入することが提案されている。ルータが生成するデータグラムの場合、挿入されるタイムスタンプは、送信するためにデータグラムをネットワーク層に渡した時間と実際に近い時間であるべきである。
ルータは、もし使用可ならば、フラグワードが 0 (タイムスタンプのみ) か、1 (タイムスタンプと登録された IP アドレス) である場合、転送されるデータグラム中のタイムスタンプオプションを無視する (すなわち変更せずにパススルーする) 設定オプションを提供してもよい (MAY)。もし提供するならば、そのオプションはデフォルトでオフ (すなわちルータはタイムスタンプを無視しない) でなければならない (MUST)。このオプションは、ルータ自身が受信したデータグラム中のタイムスタンプの処理に影響すべきでない (特に、ルータは自分が受信したデータグラム中のタイムスタンプオプションにタイムスタンプを挿入するだろう。そして、ICMP エコー要求は依然としてセクション [4.3.3.6] に従って処理される)。
DISCUSSION
経路記録オプションと同様に、タイムスタンプオプションはネットワークのトポロジに関する情報を明らかにする。ある人は、これをセキュリティの懸案と見なしている。
| Prev | Next |