3. プロトコル概要 (Protocol Overview)

本プロトコルは、同じリンクに接続されたノード間の相互作用に関連する一連の問題を解決します。以下の各問題を解決するためのメカニズムを定義します:

ルーター探索 (Router Discovery): ホストが接続されたリンク上に存在するルーターを見つける方法。

プレフィックス探索 (Prefix Discovery): ホストが、接続されたリンクに対してどの宛先がオンリンクであるかを定義するアドレスプレフィックスのセットを発見する方法。(ノードはプレフィックスを使用して、オンリンクに存在する宛先と、ルーターを介してのみ到達可能な宛先を区別します。)

パラメータ探索 (Parameter Discovery): ノードが、送信パケットに配置するリンクパラメータ (リンクMTUなど) またはインターネットパラメータ (ホップ制限値など) を学習する方法。

アドレス自動構成 (Address Autoconfiguration): ノードがステートレス方式でインターフェースのアドレスを構成できるようにするために必要なメカニズムを導入します。ステートレスアドレス自動構成は [ADDRCONF] で指定されています。

アドレス解決 (Address resolution): 宛先のIPアドレスのみが与えられた場合に、ノードがオンリンク宛先 (例えば、近隣ノード) のリンク層アドレスを決定する方法。

ネクストホップ決定 (Next-hop determination): IP宛先アドレスを、宛先へのトラフィックを送信すべき近隣ノードのIPアドレスにマッピングするアルゴリズム。ネクストホップは、ルーターまたは宛先自体の場合があります。

近隣到達不可能性検出 (Neighbor Unreachability Detection): ノードが近隣ノードが到達不可能になったことを判定する方法。ルーターとして使用される近隣ノードの場合、代替のデフォルトルーターを試すことができます。ルーターとホストの両方について、アドレス解決を再度実行できます。

重複アドレス検出 (Duplicate Address Detection): ノードが、使用したいアドレスが既に別のノードによって使用されているかどうかを判定する方法。

リダイレクト (Redirect): ルーターが、特定の宛先に到達するためのより良い最初のホップノードをホストに通知する方法。

近隣探索は、5つの異なるICMPパケットタイプを定義します: ルーター要請 (Router Solicitation) とルーター広告 (Router Advertisement) メッセージのペア、近隣要請 (Neighbor Solicitation) と近隣広告 (Neighbor Advertisement) メッセージのペア、およびリダイレクト (Redirect) メッセージ。メッセージは次の目的を果たします:

ルーター要請 (Router Solicitation): インターフェースが有効になったとき、ホストは、ルーターが次のスケジュールされた時刻ではなく直ちにルーター広告を生成することを要求するルーター要請を送信することができます (MAY)。

ルーター広告 (Router Advertisement): ルーターは、定期的に、またはルーター要請メッセージに応答して、さまざまなリンクおよびインターネットパラメータとともにその存在を広告します。ルーター広告には、別のアドレスが同じリンクを共有しているか (オンリンク決定) および/またはアドレス構成を決定するために使用されるプレフィックス、推奨されるホップ制限値などが含まれます。

近隣要請 (Neighbor Solicitation): 近隣ノードのリンク層アドレスを決定するため、またはキャッシュされたリンク層アドレスを介して近隣ノードがまだ到達可能であることを確認するために、ノードによって送信されます。近隣要請は、重複アドレス検出にも使用されます。

近隣広告 (Neighbor Advertisement): 近隣要請メッセージに対する応答。ノードは、リンク層アドレスの変更を通知するために、要請されていない近隣広告を送信することもできます (MAY)。

リダイレクト (Redirect): ルーターによって使用され、宛先へのより良い最初のホップをホストに通知します。

マルチキャスト対応リンクでは、各ルーターは、その可用性を通知するルーター広告パケットを定期的にマルチキャストします。ホストは、すべてのルーターからルーター広告を受信し、デフォルトルーターのリストを構築します。ルーターは、ホストが数分以内にその存在を学習するのに十分な頻度でルーター広告を生成しますが、広告の不在に依存してルーターの障害を検出できるほど頻繁ではありません。別個の近隣到達不可能性検出アルゴリズムが障害検出を提供します。

ルーター広告には、オンリンク決定および/または自律アドレス構成に使用されるプレフィックスのリストが含まれています。プレフィックスに関連付けられたフラグは、特定のプレフィックスの意図された使用法を指定します。ホストは、広告されたオンリンクプレフィックスを使用して、パケットの宛先がオンリンクかルーターの先かを決定する際に使用されるリストを構築および維持します。宛先は、広告されたオンリンクプレフィックスでカバーされていない場合でも、オンリンクである可能性があることに注意してください。そのような場合、ルーターは、宛先が近隣ノードであることを送信者に通知するリダイレクトを送信できます。

ルーター広告 (およびプレフィックスごとのフラグ) により、ルーターはホストにアドレス自動構成の実行方法を通知できます。例えば、ルーターは、ホストがDHCPv6および/または自律 (ステートレス) アドレス構成を使用すべきかどうかを指定できます。

ルーター広告メッセージには、ホストが送信パケットで使用すべきホップ制限などのインターネットパラメータや、オプションでリンクMTUなどのリンクパラメータも含まれます。これにより、ルーターで設定でき、接続されたすべてのホストに自動的に伝播される重要なパラメータの集中管理が容易になります。

ノードは、ターゲットノードにそのリンク層アドレスを返すように要求する近隣要請をマルチキャストすることによって、アドレス解決を実現します。近隣要請メッセージは、ターゲットアドレスの要請ノードマルチキャストアドレスにマルチキャストされます。ターゲットは、ユニキャスト近隣広告メッセージでそのリンク層アドレスを返します。開始側とターゲットの両方が互いのリンク層アドレスを解決するには、単一の要求-応答パケットペアで十分です。開始側は、近隣要請にそのリンク層アドレスを含めます。

近隣要請メッセージは、複数のノードに同じユニキャストアドレスが割り当てられているかどうかを判定するためにも使用できます。重複アドレス検出のための近隣要請メッセージの使用は、[ADDRCONF] で指定されています。

近隣到達不可能性検出は、近隣ノードの障害または近隣ノードへのフォワードパスの障害を検出します。そのためには、近隣ノードに送信されたパケットが実際にその近隣ノードに到達し、そのIP層によって適切に処理されているという肯定的な確認が必要です。近隣到達不可能性検出は、2つのソースからの確認を使用します。可能な場合、上位層プロトコルは、接続が「フォワードプログレス」を行っている、つまり以前に送信されたデータが正しく配信されたことがわかっている (例えば、新しい確認応答が最近受信された) という肯定的な確認を提供します。そのような「ヒント」を通じて肯定的な確認が得られない場合、ノードは、ネクストホップからの到達可能性確認として近隣広告を求めるユニキャスト近隣要請メッセージを送信します。不要なネットワークトラフィックを減らすために、プローブメッセージは、ノードがアクティブにパケットを送信している近隣ノードにのみ送信されます。

上記の一般的な問題への対処に加えて、近隣探索は以下の状況も処理します:

リンク層アドレス変更 (Link-layer address change) - そのリンク層アドレスが変更されたことを知っているノードは、無効になったキャッシュされたリンク層アドレスを迅速に更新するために、いくつかの (要請されていない) 近隣広告パケットをすべてのノードにマルチキャストできます。要請されていない広告の送信は、パフォーマンス向上のみである (例えば、信頼性がない) ことに注意してください。近隣到達不可能性検出アルゴリズムは、すべてのノードが新しいアドレスを確実に発見することを保証しますが、遅延はやや長くなる場合があります。

インバウンド負荷分散 (Inbound load balancing) - 複製されたインターフェースを持つノードは、同じリンク上の複数のネットワークインターフェース間で着信パケットの受信を負荷分散したい場合があります。そのようなノードには、同じインターフェースに複数のリンク層アドレスが割り当てられています。例えば、単一のネットワークドライバが、複数のリンク層アドレスを持つ単一の論理インターフェースとして複数のネットワークインターフェースカードを表現できます。近隣探索により、ルーターは、ルーター広告パケットから送信元リンク層アドレスを省略することで、自分宛てのトラフィックの負荷分散を実行できます。これにより、近隣ノードは近隣要請メッセージを使用してルーターのリンク層アドレスを学習する必要があります。返される近隣広告メッセージは、例えば誰が要請を発行したかに応じて異なるリンク層アドレスを含むことができます。本仕様では、ホストが着信パケットを負荷分散できるメカニズムは定義されていません。[LD-SHRE] を参照してください。

エニーキャストアドレス (Anycast addresses) - エニーキャストアドレスは、同等のサービスを提供するノードのセットのいずれかを識別し、同じリンク上の複数のノードが同じエニーキャストアドレスを認識するように構成される場合があります。近隣探索は、ノードが同じターゲットに対して複数の近隣広告を受信することを期待することで、エニーキャストを処理します。エニーキャストアドレスのすべての広告は、非オーバーライド広告としてタグ付けされます。非オーバーライド広告は、別の広告によって送信された情報を更新または置換しないものです。これらの広告については、近隣広告メッセージのコンテキストで後述します。これにより、潜在的に複数の広告のうちどれを使用すべきかを決定する特定のルールが呼び出されます。

プロキシ広告 (Proxy advertisements) - 近隣要請に応答できないターゲットアドレスに代わってパケットを受け入れる意思のあるノードは、非オーバーライド近隣広告を発行できます。プロキシ広告は、Mobile IPv6ホームエージェントによって使用され、モバイルノードがオフリンクに移動したときにモバイルノードのアドレスを防御します。ただし、例えばこのプロトコルを実装していないノードを処理するための一般的なメカニズムとして意図されていません。

3.1. IPv4との比較 (Comparison with IPv4)

IPv6近隣探索プロトコルは、IPv4プロトコルのアドレス解決プロトコル [ARP]、ICMPルーター探索 [RDISC]、およびICMPリダイレクト [ICMPv4] の組み合わせに対応します。IPv4では、近隣到達不可能性検出に関して一般的に合意されたプロトコルまたはメカニズムはありませんが、ホスト要件文書 [HR-CL] は、デッドゲートウェイ検出のための可能なアルゴリズム (近隣到達不可能性検出が取り組む問題のサブセット) をいくつか指定しています。

近隣探索プロトコルは、IPv4プロトコルセットに対する多数の改善を提供します:

• ルーター探索は基本プロトコルセットの一部です。ホストがルーティングプロトコルを「スヌープ」する必要はありません。

• ルーター広告にはリンク層アドレスが含まれます。ルーターのリンク層アドレスを解決するための追加のパケット交換は必要ありません。

• ルーター広告にはリンクのプレフィックスが含まれます。「ネットマスク」を構成するための別個のメカニズムを持つ必要はありません。

• ルーター広告はアドレス自動構成を可能にします。

• ルーターは、ホストがリンクで使用するMTUを広告でき、明確に定義されたMTUを欠くリンクですべてのノードが同じMTU値を使用することを保証します。

• アドレス解決マルチキャストは1600万 (2^24) のマルチキャストアドレスに「分散」され、ターゲット以外のノードでのアドレス解決関連の割り込みが大幅に削減されます。さらに、非IPv6マシンは全く割り込まれるべきではありません。

• リダイレクトには新しい最初のホップのリンク層アドレスが含まれます。リダイレクトを受信したときに別個のアドレス解決は必要ありません。

• 複数のプレフィックスを同じリンクに関連付けることができます。デフォルトでは、ホストはルーター広告からすべてのオンリンクプレフィックスを学習します。ただし、ルーターは、ルーター広告から一部またはすべてのプレフィックスを省略するように構成される場合があります。そのような場合、ホストは宛先がオフリンクであると仮定し、トラフィックをルーターに送信します。次に、ルーターは必要に応じてリダイレクトを発行できます。

• IPv4とは異なり、IPv6リダイレクトの受信者は、新しいネクストホップがオンリンクであると仮定します。IPv4では、ホストは、リンクのネットワークマスクに従ってオンリンクでないネクストホップを指定するリダイレクトを無視します。IPv6リダイレクトメカニズムは、[SH-MEDIA] で指定されたXRedirect機能に類似しています。これは、ノードがオンリンク宛先のすべてのプレフィックスを知ることが望ましくない、または不可能な非ブロードキャストおよび共有メディアリンクで有用であると期待されます。

• 近隣到達不可能性検出は基本の一部であり、障害のあるルーター、部分的に障害のあるリンクまたはパーティション化されたリンク、またはリンク層アドレスを変更するノードの存在下でパケット配信の堅牢性を大幅に向上させます。例えば、モバイルノードは、古いARPキャッシュによる接続の損失なしにオフリンクに移動できます。

• ARPとは異なり、近隣探索は (近隣到達不可能性検出を使用して) ハーフリンク障害を検出し、双方向接続がない近隣ノードへのトラフィックの送信を回避します。

• IPv4ルーター探索とは異なり、ルーター広告メッセージには優先フィールドが含まれていません。優先フィールドは、異なる「安定性」のルーターを処理するために必要ありません。近隣到達不可能性検出がデッドルーターを検出し、動作しているルーターに切り替えます。

• リンクローカルアドレスを使用してルーターを一意に識別すること (ルーター広告およびリダイレクトメッセージの場合) により、サイトが新しいグローバルプレフィックスを使用するように再番号付けされた場合でも、ホストがルーターの関連付けを維持することが可能になります。

• ホップ制限を255に設定することにより、近隣探索は、誤ってまたは意図的にNDメッセージを送信するオフリンク送信者に対して免疫があります。IPv4では、オフリンク送信者はICMPリダイレクトとルーター広告メッセージの両方を送信できます。

• アドレス解決をICMP層に配置することで、プロトコルがARPよりもメディアに依存しなくなり、必要に応じて汎用IP層認証およびセキュリティメカニズムを使用することが可能になります。

3.2. サポートされるリンクタイプ (Supported Link Types)

近隣探索は、異なる特性を持つリンクをサポートします。特定の特性の存在下では、NDプロトコルメカニズムのサブセットのみが本文書で完全に指定されています:

ポイントツーポイント (point-to-point) - 近隣探索は、そのようなリンクをマルチキャストリンクと同じように処理します。(マルチキャストはポイントツーポイントリンクで簡単に提供でき、インターフェースにリンクローカルアドレスを割り当てることができます。)

マルチキャスト (multicast) - 近隣探索は、本文書で説明されているように、マルチキャスト対応リンク上で動作します。

非ブロードキャストマルチアクセス (non-broadcast multiple access, NBMA) - リダイレクト、近隣到達不可能性検出、およびネクストホップ決定は、本文書で説明されているように実装されるべきです (SHOULD)。NBMAリンク上でのアドレス解決、およびルーター要請と広告を配信するメカニズムは、本文書では指定されていません。ホストがデフォルトルーターのリストの手動構成をサポートしている場合、ホストはリダイレクトメッセージから近隣ノードのリンク層アドレスを動的に取得できることに注意してください。

共有メディア (shared media) - リダイレクトメッセージは、共有メディアリンクでのプロトコルの使用を簡素化するために、[SH-MEDIA] のXRedirectメッセージをモデルにしています。

本仕様では、ルーターにのみ関連する共有メディアの問題には対処していません。例えば:

• ルーターが共有メディアリンクで到達可能性情報を交換する方法。
• ルーターが、ホストにリダイレクトメッセージを送信するために必要なホストのリンク層アドレスを決定する方法。
• ルーターが、受信したパケットの最初のホップルーターであることを決定する方法。

プロトコルは (新しいオプションの定義を通じて) 拡張可能であるため、他の解決策が将来可能になる可能性があります。

可変MTU (variable MTU) - 近隣探索により、ルーターはリンクのMTUを指定でき、すべてのノードがそれを使用します。マルチキャストが適切に機能するためには、リンク上のすべてのノードが同じMTU (または最大受信ユニット) を使用しなければなりません (MUST)。そうしないと、マルチキャスト時に、どのノードがパケットを受信するかを知ることができない送信者は、すべての受信者が処理できる (または最大受信ユニット) 最小パケットサイズを決定できません。

非対称到達可能性 (asymmetric reachability) - 近隣探索は、対称的な到達可能性の不在を検出します。ノードは、対称的な接続性を持たない近隣ノードへのパスを回避します。

近隣到達不可能性検出は、通常、そのようなハーフリンクを識別し、ノードはそれらの使用を控えます。

プロトコルは、おそらく将来、反射的および推移的接続性を欠く環境で実行可能なパスを見つけるために拡張できます。

3.3. 近隣探索メッセージのセキュリティ (Securing Neighbor Discovery Messages)

近隣探索メッセージは、さまざまな機能に必要です。いくつかの機能は、ホストがアドレスの所有権またはリンク層アドレスとIP層アドレス間のマッピングを確認できるように設計されています。近隣探索に関連する脆弱性については、セクション11.1で説明されています。近隣探索を保護するための一般的なソリューションは、本仕様の範囲外であり、[SEND] で説明されています。ただし、セクション11.2では、IPsec認証ヘッダー (Authentication Header, AH) またはカプセル化セキュリティペイロード (Encapsulating Security Payload, ESP) を使用して近隣探索を保護する方法と、どのような制約の下で使用できるかを説明しています。

---