7. アドレス解決と近隣到達不能検出 (Address Resolution and Neighbor Unreachability Detection)

このセクションでは、アドレス解決と近隣到達不能検出について説明します。アドレス解決は、ノードがIPアドレスのみを与えられた近隣ノードのリンク層アドレスを決定するプロセスです。近隣到達不能検出 (Neighbor Unreachability Detection, NUD) は、近隣ノードへのパスの到達可能性状態を追跡するプロセスです。

7.1. アドレス解決 (Address Resolution)

アドレス解決は、オンリンクであると判断されたアドレスに対してのみ実行されます。マルチキャストアドレスに対しては実行されません。

ノードが送信するIPv6パケットを持っている場合、まず宛先キャッシュを調べて、宛先のネクストホップアドレスを決定します。宛先キャッシュに宛先のエントリが含まれていない場合、ノードはネクストホップ決定アルゴリズム (セクション5.2を参照) を使用してネクストホップアドレスを決定します。

ネクストホップIPアドレスが判明すると、送信者は近隣キャッシュを調べて、ネクストホップに関するリンク層情報を探します。エントリが存在しない場合、送信者はエントリを作成し、その状態をINCOMPLETEに設定し、アドレス解決を開始し、アドレス解決の完了を待つ間、データパケットをキューに入れます。

マルチキャストパケットの場合、ネクストホップは常に (マルチキャスト) 宛先アドレスであり、オンリンクと見なされます。マルチキャストIPアドレスに対応するリンク層アドレスを決定する手順は、特定のリンクタイプ上でIPを操作することをカバーする別の文書 (例えば、[IPv6-ETHER]) で説明されています。

ユニキャストパケットの場合、アドレス解決は次のように実行されます。送信者は、ネクストホップアドレスの近隣キャッシュエントリを作成し (まだ存在しない場合)、その状態をINCOMPLETEに設定し、ターゲットアドレスに対応する要請ノードマルチキャストアドレスに近隣要請メッセージを送信してアドレス解決を開始します。要請は、要請が送信されるインターフェースに割り当てられたアドレスから送信されます。

近隣要請のターゲットアドレスは、ネクストホップアドレスに設定されます。送信者が近隣要請を送信するインターフェースに割り当てられたアドレスを持っている場合、送信元リンク層アドレスオプションを含めるべきです (SHOULD)。送信者が要請を送信するインターフェースに割り当てられたアドレスを持っていない場合 (例えば、初期化中)、送信者は送信元リンク層アドレスオプションを含めてはなりません (MUST NOT)。

アドレス解決の完了を待つ間、送信者は、各近隣ノードに対して、アドレス解決の完了を待つパケットの小さなキューを保持しなければなりません (MUST)。キューは少なくとも1つのパケットを保持しなければならず (MUST)、それ以上を含んでもよいです (MAY)。ただし、近隣ノードごとにキューに入れられたパケットの数は、ある小さな数に制限されるべきです (SHOULD)。アドレス解決が完了すると、ノードはキューに入れられたパケットを送信します。

アドレス解決の完了を待つ間、送信者は近隣要請の送信を続けます。アドレス解決のための近隣要請は、近隣広告が受信されるまで、または近隣要請の最大数 (MAX_MULTICAST_SOLICIT) が送信されるまで、RetransTimerミリ秒ごとに送信されます。MAX_MULTICAST_SOLICIT要請の後に近隣広告が受信されない場合、アドレス解決は失敗しています。送信者は、パケットのキャッシュされたコピーを解放しなければならず (MUST)、アドレス解決を待つキューに入れられた各パケットに対して、コード3 (Address Unreachable) のICMP宛先到達不能指示を返すべきです (SHOULD)。

7.2. 近隣到達不能検出 (Neighbor Unreachability Detection)

7.2.1. 到達可能性確認 (Reachability Confirmation)

ノードが近隣ノードに最近送信されたパケットがそのIP層によって受信されたという確認を最近受信した場合、近隣ノードは到達可能であると見なされます。肯定的な確認は、2つの方法で収集できます: 接続が「フォワードプログレス (forward progress)」を行っていることを示す上位層プロトコルからのヒント、または近隣要請メッセージへの応答である近隣広告メッセージの受信。

リモートピアから受信したパケットが、そのピアに最近送信されたパケットが実際にそのピアに到達している場合にのみ到着できる場合、接続は「フォワードプログレス」を行っています。たとえば、TCPでは、(新しい) 確認応答の受信は、以前に送信されたデータがピアに到達したことを示します。同様に、新しい (重複していない) データの到着は、以前の確認応答がリモートピアに到達していることを示します。パケットがピアに到達している場合、それらはピアのIP層にも到達しているはずであり、これが近隣到達不能検出の要件です。

オフリンク宛先の場合、フォワードプログレスは、ファーストホップルーターが到達可能であることを意味します。そのような確認が存在する場合、実装は、ファーストホップルーターの近隣キャッシュエントリを更新し、その到達可能性状態をREACHABLEに設定してもよいです (MAY)。実装がフォワードプログレスを追跡しない場合、リモートピアからパケットが受信され続けるときに、フォワードプログレスが行われていると仮定すべきです (SHOULD)。

近隣到達不能検出は、パケットを送信しているアプリケーションと並行して動作します。近隣ノードにパケットを送信しても、その到達可能性は確認されません。対応する確認応答の受信が確認します。実装は、近隣ノードが積極的に使用されているという理由だけで、近隣ノードが到達可能であると結論付けてはなりません (MUST NOT)。

ノードが近隣アドレスに対してアドレス解決を実行する必要があるが、すでにSTALE状態のアドレスの近隣キャッシュエントリを持っている場合、ノードは状態をINCOMPLETEではなくDELAYに更新し、到達可能性を確認するために近隣要請を送信します。次に、ノードはDELAY_FIRST_PROBE_TIME秒待ちます。その時間内に到達可能性確認が受信されない場合、エントリの状態はPROBEに変更され、近隣到達不能検出が開始されます。

7.2.2. 近隣キャッシュエントリの状態 (Neighbor Cache Entry States)

トラフィックが送信されている近隣ノードの近隣キャッシュエントリは、5つの可能な状態のいずれかになります:

INCOMPLETE (不完全) - エントリに対してアドレス解決が現在実行されています。具体的には、近隣要請がターゲットの要請ノードマルチキャストアドレスに送信されましたが、対応する近隣広告がまだ受信されていません。

REACHABLE (到達可能) - 最後のReachableTimeミリ秒以内に、近隣ノードへのフォワードパスが正常に機能していることの肯定的な確認が受信されました。REACHABLE状態の間、パケットが送信されても特別なアクションは実行されません。

STALE (古い) - フォワードパスが正常に機能していることの最後の肯定的な確認が受信されてから、ReachableTimeミリ秒以上が経過しています。古い状態の間、パケットが送信されるまでアクションは実行されません。

STALE状態は、キャッシュされたリンク層アドレスを更新する要請されていない近隣探索メッセージを受信したときに入ります。そのようなメッセージの受信は到達可能性を確認せず、STALE状態に入ることで、パス障害が迅速に検出されることが保証されます。ただし、到達可能性は、エントリが使用されるまで実際には検証されません。

DELAY (遅延) - フォワードパスが正常に機能していることの最後の肯定的な確認が受信されてから、ReachableTimeミリ秒以上が経過し、最後のDELAY_FIRST_PROBE_TIME秒以内にパケットが送信されました。DELAY状態に入ってからDELAY_FIRST_PROBE_TIME秒以内に到達可能性確認が受信されない場合、ユニキャスト近隣要請を送信し、状態をPROBEに変更します。

DELAY状態は、最近のトラフィックの欠如により最後の確認からReachableTimeミリ秒が経過した場合に、上位層プロトコルが到達可能性確認を提供するための追加時間を与える最適化です。この最適化がなければ、トラフィックの途絶後にTCP接続を開くと、その後の3ウェイハンドシェイクがほぼ即座に到達可能性確認を提供するにもかかわらず、プローブが開始されます。

PROBE (プローブ) - 到達可能性確認が受信されるまで、またはプローブの最大数 (MAX_UNICAST_SOLICIT) が送信されるまで、RetransTimerミリ秒ごとにユニキャスト近隣要請を再送信することによって、到達可能性確認が積極的に求められています。MAX_UNICAST_SOLICIT要請を送信した後に応答が受信されない場合、再送信は停止し、エントリは削除されるべきです (SHOULD)。その近隣ノードへのその後のトラフィックは、エントリを再作成し、再度アドレス解決を実行します。

すべての近隣要請は、近隣ノードごとにレート制限されることに注意してください。ノードは、RetransTimerミリ秒ごとに1回よりも頻繁に同じターゲットに近隣要請を送信してはなりません (MUST NOT)。

7.2.3. ノードの動作 (Node Behavior)

近隣到達不能検出アルゴリズムは、エントリがパケットの転送に使用されているかどうかによって異なる動作をします。

到達可能性確認が受信されると (上位層のアドバイスまたは要請された近隣広告のいずれかを通じて)、エントリの状態はREACHABLEに変わります。唯一の例外は、上位層のアドバイスがINCOMPLETE状態のエントリ (例えば、リンク層アドレスがキャッシュされていないエントリ) には影響しないことです。

ノードがSTATE状態のエントリを持つ近隣ノードにパケットを送信すると、ノードはエントリの状態をDELAYに更新し、DELAY_FIRST_PROBE_TIME秒後に期限切れになるタイマーを設定します。タイマーが期限切れになったときにエントリがまだDELAY状態にある場合、エントリの状態はPROBEに変わり、ユニキャスト近隣要請が送信されます。近隣要請は、キャッシュされたリンク層アドレスを使用して送信されます。その後の要請 (もしあれば) は、同じキャッシュされたリンク層アドレスを使用して送信されます。近隣要請は、到達可能性確認が受信されるまで、またはMAX_UNICAST_SOLICIT要請が送信されるまで、RetransTimerミリ秒ごとに再送信されます。

ユニキャスト近隣要請への応答として近隣広告が受信され、近隣広告のSolicitedフラグが設定されている場合、エントリの状態はREACHABLEに変わります。Solicitedフラグが設定されていない場合、エントリはPROBE状態のままです。

PROBE状態で到達可能性確認が受信された場合、エントリの状態はREACHABLEに変わります。到達可能性確認を受信せずにプローブの最大数が送信された場合、エントリは削除されるべきであり (SHOULD)、その近隣ノードへの将来のトラフィックは、再度アドレス解決を実行する必要があります。実装は、いつでも古いエントリをガベージコレクトしてもよいです (MAY)。ただし、INCOMPLETE状態のエントリは、アドレス解決が失敗するまで (つまり、MAX_MULTICAST_SOLICIT近隣要請が送信され、応答が受信されていない) 削除されるべきではありません (SHOULD NOT)。

7.3. 近隣到達不能検出プロトコル (Neighbor Unreachability Detection Protocol)

このセクションでは、近隣到達不能検出アルゴリズムがどのように動作するかの概要を説明します。

7.3.1. 到達可能性確認イベント (Reachability Confirmation Events)

以下のイベントにより、キャッシュされたリンク層アドレスがREACHABLEとして再確認されます:

1. INCOMPLETE以外の任意の状態のエントリに対する要請された近隣広告の受信。

2. INCOMPLETE以外の任意の状態のエントリに対する上位層到達可能性確認 (例えば、肯定的なTCP確認応答) の受信。

3. STALE、DELAY、またはPROBE状態のエントリに対して、近隣要請を送信し、要請された近隣広告を受信すること。

7.3.2. 状態遷移 (State Transitions)

状態遷移は次のように発生します:

INCOMPLETE -> REACHABLE: ターゲットリンク層アドレスオプションを含む有効な近隣広告が受信されたとき。

INCOMPLETE -> (削除): アドレス解決が失敗したとき (つまり、MAX_MULTICAST_SOLICIT近隣要請が応答なしで送信されたとき)。

REACHABLE -> STALE: 到達可能性確認を受信せずにReachableTimeミリ秒が経過したとき。

STALE -> DELAY: STALE状態の近隣ノードにパケットが送信されたとき。

STALE -> REACHABLE: 到達可能性確認が受信されたとき。

DELAY -> PROBE: 到達可能性確認を受信せずにDELAY_FIRST_PROBE_TIME秒が経過したとき。

DELAY -> REACHABLE: 到達可能性確認が受信されたとき。

PROBE -> REACHABLE: 到達可能性確認が受信されたとき。

PROBE -> (削除): 到達可能性確認を受信せずにMAX_UNICAST_SOLICITプローブが送信されたとき。

7.3.3. 近隣要請の送信 (Sending Neighbor Solicitations)

近隣到達不能検出の目的で近隣要請メッセージを送信する場合、以下のルールが適用されます:

• 近隣要請のターゲットアドレスは、到達可能性が確認されている近隣ノードのIPアドレスに設定されなければなりません (MUST)。

• 近隣要請は、キャッシュされたリンク層アドレスを使用してユニキャストパケットとして送信されなければなりません (MUST)。

• 近隣要請の送信元アドレスは、近隣要請が送信されるインターフェースに割り当てられたアドレスでなければなりません (MUST)。

• 近隣要請には、送信元リンク層アドレスオプションを含めるべきです (SHOULD)。

7.3.4. 近隣要請の受信 (Receiving Neighbor Solicitations)

近隣要請が受信されると、受信者は自分が要請のターゲットであるかどうかを確認します。その場合、受信者は送信者の近隣キャッシュエントリを作成または更新すべきです (SHOULD)。送信者の近隣キャッシュエントリがすでに存在する場合、受信者はエントリのリンク層アドレスを (異なる場合) 更新し、エントリの状態を次のように設定します:

• エントリが任意の状態にあり、受信した近隣広告のOverrideフラグが設定されている場合、エントリのリンク層アドレスが更新されます。

• エントリがINCOMPLETE状態にある場合、エントリのリンク層アドレスは送信元リンク層アドレスオプション (存在する場合) の値に設定され、状態はSTALEに設定されます。

• エントリがINCOMPLETE以外の任意の状態にあり、受信した送信元リンク層アドレスがキャッシュされたリンク層アドレスと異なり、Overrideフラグが設定されている場合、キャッシュされたリンク層アドレスは受信したアドレスに置き換えられ、エントリの状態は変更されません。

7.4. 近隣広告の送信 (Sending Neighbor Advertisements)

ノードは、近隣要請に応答して近隣広告を送信し、リンク層アドレスが変更されたときに要請されていない近隣広告も送信します。

7.4.1. 近隣要請への応答 (Responding to Neighbor Solicitations)

近隣要請が受信されると、ターゲットノードは近隣広告で応答すべきです (SHOULD)。近隣広告は、近隣要請の送信元アドレスが未指定アドレスでない場合は、近隣要請の送信元アドレスに送信されます。それ以外の場合、近隣広告は全ノードマルチキャストアドレスに送信されます。

近隣広告のターゲットアドレスは、近隣要請のターゲットアドレスからコピーされます。Solicitedフラグは、近隣広告が近隣要請への応答として送信される場合は1に設定されます。それ以外の場合は、0に設定されます。

ターゲットリンク層アドレスオプションが近隣要請に含まれており、リンク層アドレスが受信ノードのリンク層アドレスと異なる場合、Overrideフラグは1に設定されます。それ以外の場合は、状況に応じて設定されます。

7.4.2. 要請されていない近隣広告 (Unsolicited Neighbor Advertisements)

ノードは、リンク層アドレスの変更を通知するために、要請されていない近隣広告を送信できます (MAY)。ノードがリンク層アドレスが変更されたことを検出した場合 (例えば、イーサネットインターフェースのホットスワップ後)、近隣ノードの近隣キャッシュエントリを迅速に更新するために、全ノードマルチキャストアドレスにいくつかの近隣広告をマルチキャストすべきです (SHOULD)。

要請されていない近隣広告の場合、Overrideフラグは、近隣ノードがキャッシュされたリンク層アドレスを更新することを保証するために1に設定されるべきです (SHOULD)。Solicitedフラグは、要請されていない近隣広告では0に設定されなければなりません (MUST)。

---