メインコンテンツまでスキップ

8. リダイレクト機能 (Redirect Function)

リダイレクトメッセージは、ルーターがホストに宛先へのより良いファーストホップを通知するために使用されます。ルーターは、ルーターによって転送されるパケットに対してのみリダイレクトメッセージを送信します。ホストは、セクション8.1で指定されたすべての妥当性チェックを満たさない受信したリダイレクトメッセージを黙って破棄しなければなりません (MUST)。

8.1. リダイレクトメッセージの検証 (Validation of Redirect Messages)​

ホストは、以下のすべての妥当性チェックを満たさない受信したリダイレクトメッセージを黙って破棄しなければなりません (MUST):

  • リダイレクトのIP送信元アドレスが、指定されたICMP宛先アドレスの現在のファーストホップルーターと同じである。

  • IPホップ制限フィールドの値が255である。つまり、パケットがルーターによって転送された可能性はない。

  • ICMPチェックサムが有効である。

  • ICMPコードが0である。

  • ICMP長 (IP長から導出) が40オクテット以上である。

  • リダイレクトのIP送信元アドレスがリンクローカルアドレスである。ルーターは、ホストがルーターを一意に識別できるように、リダイレクトメッセージの送信元としてリンクローカルアドレスを使用しなければならない。

  • リダイレクトメッセージのICMP宛先アドレスフィールドにマルチキャストアドレスが含まれていない。

  • ICMPターゲットアドレスが、リンクローカルアドレス (ルーターにリダイレクトされる場合) またはICMP宛先アドレスと同じ (オンリンク宛先にリダイレクトされる場合) である。

  • 含まれるすべてのオプションの長さがゼロより大きい。

予約済みフィールドおよび認識されないオプションの内容は、無視されなければなりません (MUST)。プロトコルへの将来の後方互換性のある変更では、予約済みフィールドの内容を指定したり、新しいオプションを追加したりする場合があります。後方互換性のない変更では、異なるコード値を使用する場合があります。

リダイレクトメッセージで使用されるように指定されていない定義済みオプションの内容は無視され、パケットは通常どおり処理されなければなりません (MUST)。表示される可能性のある定義済みオプションは、ターゲットリンク層アドレスおよびリダイレクトヘッダオプションのみです。

8.2. ルーター仕様 (Router Specification)​

ルーターは、レート制限の対象として、明示的に自分宛でないパケットを転送するたびに、以下の場合にリダイレクトメッセージを送信すべきです (SHOULD):

  • パケットの送信元アドレスフィールドが近隣ノードを識別し、かつ

  • ルーターが、パケットの宛先アドレスに対して、送信ノードと同じリンク上により良いファーストホップノードが存在すると判断し、かつ

  • パケットの宛先アドレスがマルチキャストアドレスでない。

送信されるリダイレクトメッセージには以下が含まれます:

  • ターゲットアドレスフィールド: 宛先への後続のパケットが送信されるべきアドレス。ターゲットがルーターの場合、そのルーターのリンクローカルアドレスを使用しなければなりません (MUST)。ターゲットがホストの場合、ターゲットアドレスフィールドは、呼び出しIPパケットの宛先アドレスと同じ値に設定されなければなりません (MUST)。

  • 宛先アドレスフィールド: 呼び出しIPパケットの宛先アドレス。

  • オプション:

    • ターゲットリンク層アドレスオプション: ターゲットのリンク層アドレス。(既知の場合) 含めるべきです (SHOULD)。NBMAリンクでは、ホストがリンク層アドレスを持たない場合があり、その場合はオプションを含めることができないことに注意してください。

    • リダイレクトヘッダ: リダイレクトパケットが [IPv6] で指定されているIPv6をサポートするために必要な最小MTUを超えない範囲で、転送されたパケットのできるだけ多くの部分。

ルーターは、送信元がリダイレクトに正しく応答しない場合にリダイレクトメッセージによって発生する帯域幅と処理コストを制限するために、リダイレクトメッセージが送信されるレートを制限しなければなりません (MUST)。ICMPエラーメッセージのレート制限の詳細については、[ICMPv6] を参照してください。

8.3. ホスト仕様 (Host Specification)​

リダイレクトを受信したホストは、パケットを調べて、以下の妥当性チェックを実行します。これらのチェックのいずれかが失敗した場合、ホストはリダイレクトメッセージを黙って破棄しなければなりません (MUST)。

ホストがリダイレクトメッセージが有効であることを確認した後、次のようにメッセージを処理します:

  • ターゲットアドレスが宛先アドレスと同じでない場合、ホストは宛先キャッシュ内の宛先アドレスの現在のエントリを、ターゲットアドレスを指すエントリに置き換えます。エントリは、パスMTU情報と近隣到達不能検出状態に関して、古いエントリの状態を継承すべきです (SHOULD)。ホストが新しい宛先キャッシュエントリを作成する場合、エントリはセクション5.2で説明されているように初期化されます。

  • ターゲットアドレスが宛先アドレスと同じ場合、受信ホストは宛先のプレフィックスリストエントリに対して以下の操作を実行します:

    • エントリが存在しない場合、ホストは宛先をオンリンク宛先としてプレフィックスリストに追加します。
    • 宛先のエントリがプレフィックスリストにすでに存在する場合、ホストはエントリを更新して、宛先がオンリンクであることを示します。

両方の場合において、ホストは宛先の宛先キャッシュエントリを更新して、ターゲットアドレスを指すようにします。宛先キャッシュエントリが存在しない場合、ホストは新しいエントリを作成します。ホストがすでに異なるファーストホップ近隣ノードを指定するキャッシュエントリを持っている場合でも、エントリを更新すべきです (SHOULD)。なぜなら、ルーターは適切なファーストホップ近隣ノードを決定するのにより良い立場にあるためです。

リダイレクトにターゲットリンク層アドレスオプションが含まれている場合、ホストはターゲットの近隣キャッシュエントリを作成または更新します。どちらの場合も、オプション内のリンク層アドレスが使用されます。ターゲットの近隣キャッシュエントリはSTALE状態に設定されます。ターゲットの近隣キャッシュエントリが作成される場合、その到達可能性状態はセクション7.3.3で指定されているようにSTALEに設定されなければなりません (MUST)。キャッシュエントリがすでに存在し、異なるリンク層アドレスで更新される場合、その到達可能性状態もSTALEに設定されなければなりません (MUST)。

ホストは、ターゲットアドレスを宛先キャッシュに追加しなければなりません (MUST)。エントリのネクストホップアドレスは、リダイレクトのターゲットアドレスに設定されます。宛先の宛先キャッシュエントリがすでに存在していた場合、ターゲットアドレスをネクストホップとして使用するように更新されます。ホストはターゲットが到達可能であることを検証しないことに注意してください。リダイレクトメッセージの妥当性はルーターの責任です。

リダイレクトメッセージは、送信元アドレスフィールドが近隣ノードを識別し、ルーターが宛先のより良いファーストホップノードを決定する、ルーターによって転送されるパケットに応答して、ルーターによって送信されるべきです (SHOULD)。ルーターがリダイレクトを送信できるレートは、ホストに対するブロードキャストストームまたはサービス拒否攻撃を防ぐために制限されなければなりません。

8.4. 例 (Example)​

ホストがデフォルトルーターR1を介して宛先にパケットを送信するが、同じリンク上の別のルーターR2が宛先へのより良いファーストホップである場合を考えます。パケットを転送する際、R1はホストにリダイレクトを送信し、R2がより良い選択であることを通知します。リダイレクトにはR2のリンクローカルアドレスが含まれます。

      +------+
      | Host |
      +------+
         |
         | (1) 宛先へのパケット
         |
         v
      +----+              +----+
      | R1 |  --------->  | R2 |
      +----+   Redirect   +----+
         |                  |
         |                  |
         +------------------+
                Link
  1. ホストがR1 (デフォルトルーター) を介して宛先にパケットを送信
  2. R1がパケットを転送し、ホストにリダイレクトを送信し、R2がより良いことを示す
  3. ホストがこの宛先にR2を使用するように宛先キャッシュを更新
  4. 宛先への後続のパケットはR2に直接送信される

8.5. リダイレクトループの防止 (Redirect Loop Prevention)​

リンク上の複数のルーターが宛先への最良のファーストホップについて意見が一致しない場合、リダイレクトメカニズムはリダイレクトループの影響を受けやすくなります。ただし、そのようなループは通常、以下の理由により短命です:

  • ルーターは、転送するパケットに対してのみリダイレクトを送信します。ルーターが自分が最良のファーストホップであるパケットを受信した場合、リダイレクトを送信しません。

  • 同じ宛先に対して異なるルーターを指す複数のリダイレクトを受信したホストは、最近受信したリダイレクトを使用します。時間が経つにつれて、システムは安定した状態に収束するはずです。

  • 近隣到達不能検出アルゴリズムは、最終的にルーターが到達不能であることを検出し、ホストが別のルーターにフォールバックするようにします。

これらの緩和策にもかかわらず、実装はリダイレクトループの可能性を認識しておく必要があり、リダイレクトに応答して宛先キャッシュエントリが更新されるレートを制限するなどの追加の保護を実装する場合があります。

に最終更新