8. 代替可能な機能の動作

通常、6LoWPANマルチホップネットワークでは、RAメッセージを使用して、ルートオーバーポロジのすべての6LRにプレフィックスとコンテキスト情報を配布します。すべてのルーターがそのような情報配布に代替メカニズムを使用するように構成されている場合、6LoWPAN-NDメカニズムの残りの使用は代替仕様によって管理されます。

6LRがDARおよびDACメッセージを使用して、ルートオーバーポロジ内の6LBRに対して（EUI-64から派生していないIPv6アドレスの）マルチホップDADを実行するオプションもあります。これは、DHCPv6 [RFC3315]などの一意のアドレスを割り当てる他の方法があるか、マルチホップDADに他の将来のメカニズムを使用する可能性があるため、代替可能です。繰り返しになりますが、この場合、6LoWPAN-NDメカニズムの残りの使用は代替仕様によって管理されます。

明確にするために：実装は、実装が他の仕様からの代替（「substitute」）をサポートしない限り、セクション8.1および8.2で説明されている機能をサポートする必要があります（MUST）。

8.1. マルチホッププレフィックスとコンテキストの配布

マルチホップ配布は、ルーター間で送信されるRSメッセージとRAメッセージに依存し、ABROバージョン番号を使用して、RAで送信される情報（プレフィックスとコンテキスト情報）の伝播を制御します。

このマルチホップ配布メカニズムは、任意の数の6LBRからの任意の情報を処理できます。ただし、コンテキスト情報のセマンティクスでは、圧縮パケットを送信、転送、または受信するかどうかにかかわらず、すべての6LNが同じ情報を使用する必要があります。したがって、6LBRの管理者は、コンテキスト情報が6LBR間で同期していることを何らかの方法で確認する必要があります。これはさまざまな方法で処理できます。それを確実にするための1つの可能な方法は、コンテキストとプレフィックス情報を論理的または仮想的なソースから発信されたものとして扱うことです。これは本質的に、情報が単一のソースから配布されているように見えることを意味します。

6LBRのセットが単一のものとして動作し（このドキュメントの範囲外のメカニズムを使用して）、プレフィックスとコンテキスト、およびABROバージョン番号がすべての6LBRから同じになる場合、それらの6LBRはABROで使用する単一のIPアドレスを選択できます。

8.1.1. ルーターアドバタイズメントを送信する6LBR

マルチホッププレフィックスとコンテキスト配布をサポートする6LBRは、それぞれのRAにABROを含める必要があります（MUST）。ABROバージョン番号フィールドは、セクション7.2のガイドラインとともに、LoWPAN全体でプレフィックスとコンテキスト情報の一貫性を保つために使用されます。PIOまたは6COのセット内の情報が変更されるたびに、ABROバージョンは1つ増加します。

これには、古いバージョン番号が6LRによって静かに無視されるため、6LBRがPIO、6CO、およびABROバージョン番号を安定したストレージで維持する必要があります。

8.1.2. ルーター要請を送信するルーター

6LoWPANでは、代替されない限り、マルチホップ配布はRAメッセージを使用して行われます。したがって、インターフェイスの初期化時に、ルーター（6LR）は、[RFC4861]でホスト用に指定されたルールに従ってRSメッセージを送信する必要があります（MUST）。これにより、ルーターはRAメッセージで応答し、それを使用してプレフィックスとコンテキスト情報を最初にシードできます。

8.1.3. ルーターアドバタイズメントを処理するルーター

マルチホップ配布がRAメッセージを使用して行われない場合、ルーターは[RFC4861]に従います。これには、一貫性チェックを行うだけであると記載されています。この場合、セクション8.1の内容は適用されません。それ以外の場合、ルーターは受信したRAからのプレフィックスとコンテキスト情報をチェックして記録し、その情報を次のように使用します。

受信したRAにABROが含まれていない場合、RAは静かに無視する必要があります（MUST）。

ルーターは、ABROの6LBRアドレスフィールドを使用して、以前に6LBRから情報を受信したことがあるかどうかを確認します。そのような情報が見つからない場合は、6LBRアドレス、バージョン、有効期間、および関連するプレフィックスとコンテキスト情報を記録するだけです。6LBRが以前にわかっている場合、バージョン番号フィールドを、その6LBRの記録されたバージョン番号と比較する必要があります（MUST）。パケットで受信したバージョン番号が保存されているバージョン番号より小さい場合、RA内の情報は静かに無視されます。それ以外の場合は、記録された情報とバージョン番号が更新されます。

8.1.4. 情報の保存

ルーターは、ABROで確認した各6LBRの状態を保持します。これには、バージョン番号、有効期間、およびPIOと6COの完全なセットが含まれます。プレフィックスは、PIOの有効期間に基づいてタイムアウトします。コンテキストプレフィックスは、6COの有効期間に基づいてタイムアウトします。

プレフィックスとコンテキスト情報がルーターに保存されている間、それらの有効期間と推奨期間は時間の経過とともに減少します。これにより、ルーターが後で送信するRAでその情報をアドバタイズするときに、「有効期限」が誤ってさらに未来に移動することがなくなります。たとえば、有効期間が10分の6COが時間Tに受信され、ルーターが時間T+5分に送信するRAにこれを含める場合、送信する6COの有効期間はわずか5分になります。

8.1.5. ルーターアドバタイズメントの送信

RAメッセージを使用してマルチホップ配布を実行する場合、ルーターは、ABROがそのABROで受信したプレフィックスとコンテキスト情報と常に一緒に留まるようにする必要があります（MUST）。したがって、ルーターがある6LBRからのものであるというABROを含むプレフィックスP1と、別の6LBRからのプレフィックスP2を受信した場合、ルーターは同じRAメッセージに2つのプレフィックスを含めてはなりません（MUST NOT）。プレフィックスP1は、最初の6LBRからのABROを含むRAに含まれている必要があります（MUST）。複数の6LBRが同じプレフィックスとコンテキスト情報をアドバタイズする場合がありますが、それでもそれらをアドバタイズした6LBRに関連付ける必要があることに注意してください。

ルーターは、[RFC4861]のように定期的にRAを送信します。これは、プレフィックスとコンテキスト情報を受信する他のルーターのためです。ルーターは、RAメッセージをユニキャストすることでRSにも応答します。どちらの場合も、ABROを「その」プレフィックスとコンテキスト情報と一緒に保つという上記の制約が適用されます。

ルーターが6LBRから新しい情報を受信した場合、つまり、新しい6LBR（ABRO内の新しい6LBRアドレス）から受信するか、既存の6LBRのABROバージョン番号が増加した場合、いくつかのトリガーされた更新を送信すると便利です。推奨事項は、[RFC4861]で説明されているように、インターフェイスがアドバタイズインターフェイスになったときと同じように動作すること、つまり最大3つのRAメッセージを送信することです。これにより、新しい情報がすべての6LRに迅速に伝播されます。

8.2. マルチホップ重複アドレス検出

AROは、6LRにアドレスを登録することに加えて、6LRに知られている他のホストによってアドレスが使用されていないことを6LRに検証させるために使用できます。ただし、これはルートオーバーポロジ（または複数の6LBRを持つLoWPAN）では十分ではありません。別の6LRに接続されているホストが同じアドレスを使用している可能性があるためです。将来、6LRがそのような重複アドレス検出を調整するためのさまざまな方法があるかもしれません。または、割り当ての一部として一意性を検証するDHCPv6サーバーを使用してアドレスを割り当てることができます。

この仕様は、DARおよびDACメッセージ内のAROからの情報を再利用するDADを実行するための、6LRおよび6LBR向けの代替可能な単純な手法を提供します。この手法は、アドレス内のインターフェイスIDがEUI-64に基づいている場合は必要ありません。これらはグローバルに一意であると想定されているためです。この手法は、6LRがすべての6LBRに登録するか、ネットワークが範囲外のメカニズムを使用して6LBR内のDADテーブルを同期させることを前提としています。

マルチホップDADメカニズムは、アドレスが特定の6LRに最初に登録されるときに同期的に使用されます。つまり、6LBRに対してマルチホップDADが完了するまで、AROはホストに返されません。6LR内の既存の登録の場合、6LBR内のアドレスのエントリがタイムアウトしないように、6LBRに対してマルチホップDADを繰り返す必要がありますが、これはホストへの応答と非同期で行うことができます。これを実現する1つの方法は、6LRが6LBRに登録したライフサイクルの残りを追跡し、このライフサイクルが切れそうになったときに6LBRに再登録することです。

同期マルチホップDADの場合、6LRはいくつかの追加チェックを実行して、6LBRから応答を受信したときにホストへの応答に使用できるNCEがあることを確認します。これには、異なるEUI-64を持つ登録済みアドレスの既存の（仮または登録済み）NCEを確認することが含まれます。そのような登録済みNCEが存在する場合、6LRはアドレスが重複していると応答する必要があります（SHOULD）。そのような仮のNCEが存在する場合、6LRはAROを静かに無視し（SHOULD）、それによってホストがAROを再送信することに依存する必要があります。これは、複数のホストが同時に同じIPv6アドレスを登録しようとした場合を処理するために必要です。NCEが存在しない場合、6LRはEUI-64とSLLAOを使用して仮のNCEを作成する必要があります（MUST）。このエントリは、6LBRが肯定的に応答したときにホストに応答を送信するために使用されます。

6LRがゼロ以外の登録ライフサイクルを持つAROを含むNSを受信し、既存の登録済みNCEがない場合、このメカニズムにより、6LRは同期マルチホップDADを呼び出します。

6LRは、1つ以上の6LBRにDARメッセージをユニキャストします。DARには、登録済みアドレスフィールドにホストのアドレスが含まれています。DARは6LBRに到達するまで6LRによって転送されます。したがって、6LBRによって受信されたとき、そのIPv6ホップ制限フィールドは255にはなりません。6LBRはDACメッセージで応答します。DACメッセージは、6LRに到達したときに255未満のホップ制限を持ちます。

6LRが6LBRからDACを受信すると、一致する（同じIPアドレスとEUI-64）（仮または登録済み）NCEを探します。そのようなエントリが見つからない場合、DACは静かに無視されます。エントリが見つかり、DACのステータス=0の場合、6LRは仮のNCEを登録済みにマークします。すべての場合において、エントリが見つかると、6LRはホストにNAで応答し、ステータスフィールドとEUI-64フィールドをDACからNA内のAROにコピーします。ステータスがエラーの場合、NAの宛先IPアドレスはDACのEUI-64フィールドから派生します。

別のホストがIPv6アドレスを登録しようとすることができるように、仮のNCEは作成されてからTENTATIVE_NCE_LIFETIME秒後にタイムアウトする必要があります（SHOULD）。

8.2.1. DARおよびDACのメッセージ検証

ノードは、次の有効性チェックの少なくとも1つが満たされていない受信DARおよびDACメッセージを静かに破棄する必要があります（MUST）。

• メッセージにIP認証ヘッダーが含まれている場合、メッセージは正しく認証されます。
• ICMPチェックサムが有効です。
• ICMPコードは0です。
• ICMP長（IP長から派生）は32バイト以上です。
• 登録済みアドレスはマルチキャストアドレスではありません。
• 含まれるすべてのオプションの長さはゼロより大きいです。
• IP送信元アドレスは未指定アドレスではなく、マルチキャストアドレスでもありません。

予約フィールドの内容および認識されないオプションは無視する必要があります（MUST）。プロトコルへの将来の下位互換性のある変更により、予約フィールドの内容が指定されたり、新しいオプションが追加されたりする場合があります。下位互換性のない変更では、異なるコード値が使用される場合があります。

6LRと6LBRの間でDARおよびDACメッセージが転送されるため、これらのICMPv6メッセージタイプの受信時にホップ制限チェックがないことに注意してください。

8.2.2. 概念データ構造

マルチホップDADを実装する6LBRは、ネイバーキャッシュとは別にいくつかの状態を維持する必要があります。この概念データ構造をDADテーブルと呼びます。これはIPv6アドレス（DAR内の登録済みアドレス）によってインデックス付けされ、そのアドレスを使用しているホストのEUI-64と登録ライフサイクルが含まれています。

8.2.3. 重複アドレスリクエストを送信する6LR

マルチホップDADを実装する6LRがホストからNSを受信し、上記のチェックに従うと、6LRは少なくとも1つの6LBRにDARを作成して送信します。DARには次の情報が含まれています。

• IPv6送信元アドレスには、6LRのグローバルアドレス。
• IPv6宛先アドレスには、6LBRのアドレス。
• IPv6ホップ制限には、MULTIHOP_HOPLIMIT。
• ステータスフィールドはゼロに設定する必要があります（MUST）。
• EUI-64と登録ライフサイクルは、ホストから受信したAROからコピーされます。
• 登録済みアドレスは、ホスト（つまり、トリガーとなるNSの送信者）のIPv6アドレスに設定されます。

6LRが登録ライフサイクルがゼロのNSをホストから受信した場合、セクション6で指定されているようにホストのNCEを削除することに加えて、上記のようにDARが6LBRに送信されます。

ルーターは、DARを受信した結果としてネイバーキャッシュを変更してはなりません（MUST NOT）。

8.2.4. 重複アドレスリクエストを受信する6LBR

代替可能なマルチホップDADを実装する6LBRが6LRからDARを受信すると、セクション8.2.1で指定されているメッセージ検証を実行します。DARが有効な場合、6LBRはDADテーブルで登録アドレスの検索に進みます。エントリが見つかり、記録されたEUI-64がDAR内のEUI-64と異なる場合、ステータスが1（「重複アドレス」）に設定されたDAC NAを返します。それ以外の場合は、ステータスがゼロに設定されたDACを返し、ライフサイクルを更新します。

DADテーブルにエントリが見つからず、登録ライフサイクルがゼロ以外の場合、エントリが作成され、DARからのEUI-64と登録済みアドレスがそのエントリに保存されます。

DADテーブルにエントリが見つかり、EUI-64が一致し、登録ライフサイクルがゼロの場合、エントリはテーブルから削除されます。

上記のどちらの場合も、6LBRはDARからコピーされた情報でDACを形成し、ステータスフィールドはゼロに設定されます。DACは6LR（つまり、DARの送信元）に返送されます。IPv6ホップ制限はMULTIHOP_HOPLIMITに設定されます。

8.2.5. 重複アドレス確認の処理

マルチホップDADを実装する6LRがDACメッセージを受信すると、まずセクション8.2.1に従ってメッセージを検証します。有効なDACの場合、登録済みアドレスとEUI-64に一致する仮のNCEがない場合、DACは静かに無視されます。それ以外の場合、DACと仮のNCE内の情報は、ホストに送信するNAを形成するために使用されます。ステータスコードはDACからホストに送信されるAROにコピーされます。DACがエラー（ステータスがゼロ以外）を示している場合、NAはセクション6.5.2で説明されているようにホストに返され、登録済みアドレスの仮のNCEは削除されます。それ以外の場合は、登録済みNCEになります。

ルーターは、IPv6アドレスとEUI-64に一致する仮のNCEがない限り、DACを受信した結果としてネイバーキャッシュを変更してはなりません（MUST NOT）。

8.2.6. 障害からの回復

RETRANS_TIMER [RFC4861]の後に6LBRからの応答がない場合、6LRはDARを最大MAX_UNICAST_SOLICIT [RFC4861]回6LBRに再送信します。その後、6LRはステータスがゼロのAROでホストに応答する必要があります（SHOULD）。