このセクションは、パケットの転送プロセスについて規定している。
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) ルータは、IP データグラムの処理のどのように継続すべきかを決定するために、セクション [5.2.3] に記述されているように 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] に記述されているような非番号回線) に対しては、IP 宛先アドレスへの回線の他方の終端のルータ ID を比較する。もしそれが正確に一致しているならば、そのパケットはこのインタフェースを通じて転送できる。
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 宛先アドレスを含む NFRP 要求パケットを作成する。このメッセージは、そのインタフェースに設定された NHRP サーバに送信される。これは論理的にルータ自身の別のプロセス、又はエンティティであってもよい。
(c) NHRP サーバは、そのデータグラムと、同じ宛先への後続するデータグラムの送信に使用するのに適切なリンク層アドレスで応答するだろう。システムは、NHRP 応答を待つ間、従来の「次ホップ」ルータにそのデータグラムを送信してもよい (MAY)。
EDITORS+COMMENTS
ルータは、IP
宛先アドレスが隣接しているか否かを決定するために、前のセクションのアルゴリズムを適用する。もし隣接しているならば、次ホップアドレスは
IP 宛先アドレスと同じである。隣接していなければ、直接の宛先に到達するために、そのパケットを別のルータを通じて転送しなければならない。このルータの選択が、このセクションの主題である。
もしパケットが SSRR を含むならば、ルータはそのパケットを破棄し、ICMP 不正送信元経路エラーで応答しなければならない (MUST)。さもなくば、ルータは適切な次ホップアドレスを決定するために、自分のルーティングテーブル中に IP 宛先アドレスを検索する。
DISCUSSION
IP 規定につき、制限された送信元経路は、パケットが横切らなければならない一続きのノードを指定しなければならず、そのパケットは送信元経路の一つのノードから次へと、中間のネットワークのみを横切って渡らなければならない。従って、もしルータが送信元経路の次のステップに隣接していなければ、送信元経路を遂行できない。よって、ルータはそのようなパケットを
ICMP 不正送信元経路エラーで拒否する。
次ホップ選択処理の目標は、ルータの転送情報ベース (FIB: Forwarding Information Base) 中にエントリを検査し、FIB 中の利用可能な経路からそのパケットにとっての最善経路を (もし存在するならば) 選択することである。
概念的に、経路検索アルゴリズムは、FIB の全体の内容から成る一セットの候補の経路から開始する。アルゴリズムは、そのセットから経路を破棄する一連のステップから構成される。これらのステップは削除規則と呼ばれる。通常、アルゴリズムが完了するとき、そのセットにおいて残った丁度一つの経路が存在する。もしそのセットにおってずっと空ならば、そのパケットは宛先が未到達なので破棄される。そのセットにおいて一つ以上の経路が残っているときに、アルゴリズムが完了することも有り得る。この場合、ルータはそれらのうち一つ以外の全てを任意に破棄してよいし、最近最も使用されていない経路を選択することによって「負荷分散」を実行してもよい。
規則 3 (弱い TOS) の例外で、ルータはパケットの次ホップを選択する際、次の削除規則を使用しなければならない (MUST)。ルータが次ホップを決定する際 TOS を考慮するならば、以下に示された順番で規則 3 を適用しなければならない。これらの規則は (概念的に)、出現した順番で FIB に適用しなければならない (MUST)。(歴史的な見地や、追加の削除規則や他の共通の使用アルゴリズムについては、付録 E を参照されたい)。
DISCUSSION
規則 3 は、ルータは転送決定を行うとき TOS のみを考慮すべき (SHOULD)
であると述べているセクション [5.3.2]
ではオプションである。
(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.length と呼ばれる宛先属性を持つと仮定する。route.length は route.dest のどのビットに意味があるかを示す対応するプレフィクス長である。転送されるパケットの 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 がサポートされる方法の欠陥に気づく価値もある。TOS をサポートするルーティングプロトコルは、0
でない TOS 値を持つパケットを転送するときに暗黙的に好まれる。
基本照合と最大長照合の削除規則は、数多くの経路の特定のタイプの扱いを一般化する。これらの経路は以下の減少、優先順位で選択される。
(1) ホスト経路 : これは特定の終端システムへの経路である。
(2) 階層的なネットワークプレフィクス経路
: これは特定のネットワークプレフィクスへの経路である。FIB
がお互いを包含する複数のネットワークプレフィクスへの経路を含むかもしれないことに注意されたい
(一つのプレフィクスは追加ビットを持つ他のプレフィクスである)。これらは、プレフィクス長を減少させる順番で選択される。
(5) デフォルト経路 : これは明示的な経路が無い全てのネットワークへの経路である。それは、プレフィクス長が 0 である経路の定義による。
もし削除規則の適用後に経路のセットが空 (すなわち経路が見つからない) ならば、そのパケットを破棄して、適切な ICMP エラー (もし IP 宛先アドレスが送信元経路オプションからのものならば ICMP 不正送信元経路、さもなくばセクション [4.3.3.1] に示されているように、ICMP 宛先ホスト到達不可か宛先ネットワーク到達不可のどちらも適切である) を生成しなければならない (MUST)。
ベンダ指針削除規則の一つの提案されるメカニズムは、管理上の優先を使用することである。それは、簡単な優先度アルゴリズムである。この考えは、複数の中から一つを選択する必要がある経路の優先度を手動で付けることである。
各々の経路は、経路の様々な属性に基づいてそれに優先値を割り当てる (優先値の割当ての特定のメカニズムは以下に提案されている)。この優先値は、[0...255] の範囲の整数値で、最も優先度の高いものが 0、最も優先度の低いものが 254 である。255 は、その経路は決して使用されないことを意味する特別な値である。ベンダ指針削除規則の第一ステップは、最も優先度の高い経路を除く、全ての経路を破棄することである (優先度の値が 255 である経路は常に破棄する)。
この指針は、簡単に誤って使用され、ルーティングループが生成されるという点で安全ではない。ルータに設定される優先度が、その隣接者に設定される優先度と一貫することを保証するプロトコルは存在しないので、ネットワーク管理者が優先度を設定する際、注意をしなければならない。
・アドレス照合
宛先の指定されたセットの幾つかへの全ての経路 (同一のルーティングドメインから教わった)
に、単一の優先度値を割り当てることができることは有効である。そこでは、宛先のセットが指定されたネットワークプレフィクスに一致する全ての宛先である。
・経路クラス
区別を維持するルーティングプロトコルにとって、指定された経路クラス
(イントラ域、インター域、内部メトリクスを持った外部、外部メトリクスを持った外部)
を持つ全ての経路 (同一のルーティングドメインから教わった)
に、単一の優先度値を割り当てることができることは有効である。
・インタフェース
パケットがルータの特定の論理インタフェース (複数の IP
アドレスが、それに割り当てられた複数の論理インタフェースを持つことを除いて、論理インタフェースは通常、ルータのネットワークインタフェースに
1 対 1 でマッピングされる) に振り分けられる全ての経路 (同一のルーティングドメインから教わった)
に、単一の優先度値を割り当てることができることは有効である。
・送信元ルータ
ルータのセットの幾つかから知った全ての経路 (同一のルーティングドメインから教わった)
に、単一の優先度値を割り当てることができることは有効である。そこでは、ルータのセットは、その更新が特定のネットワークプレフィクスと一致する送信元アドレスを持つものである。
・起動側 AS
情報を提供するルーティングプロトコルにとって、別の特定のルーティングドメインで起動した全ての経路(同一のルーティングドメインから教わった)に、単一の優先度値を割り当てることができることは有効である。BGP
経路では、起動側 AS は経路の AS_PATH 属性にリスト化された最初の AS である。OSPF
外部経路では、もしタグの自動ビットが設定され、タグのパス長が 3
でないならば、起動側 AS は経路の外部経路タグの低次 16 ビットと見なされるかもしれない。
・外部経路タグ
外部経路タグが指定された値のリストに一致する全ての OSPF 外部経路
(同一のルーティングドメインから教わった)
に、単一の優先度値を割り当てることができることは有効である。外部経路タグは構造化された値を持つかもしれないので、タグの特定のサブフィールドと照合する能力を提供することは有効であろう。
・AS パス
AS パスが指定された値のセットに「一致する」全ての BGP 経路
(同一のルーティングドメインから教わった)
に、単一の優先度値を割り当てることができることは有効である。何の種類の照合が最も有効であるかは、未だはっきりと明確になっていない。簡単なオプションは、特定の
AS 番号が現われる (あるいは現われない) 全ての経路の照合を可能にすることである。より一般的だがより難しい代替方法は、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 も定義している。これらのコードは、U.S 軍事機関で使用されるエンドツーエンドの暗号デバイスで使用することを意図している。もしパケットを管理上フィルタにかけるならば、ルータは新たに定義されたコード 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
経路記録オプションと同様に、タイムスタンプオプションはネットワークのトポロジに関する情報を明らかにし得る。ある人は、これをセキュリティの懸案と見なしている。