7. ボーダールーターの動作

6LBRは、上記のセクション6で指定されているように、RAの送信とホストからのNSの処理を処理します。6LBRは、送信するRAに常にABROを含め、それ自体を6LBRアドレスとしてリストする必要があります（SHOULD）。これには、6LBRが安定したストレージでバージョン番号を維持し、RAの一部の情報が変更されたときにバージョン番号を増やす必要があります。変更がバージョンに影響する情報は、PIO（プレフィックスまたはそのライフタイム）と6CO（プレフィックス、CID、またはライフタイム）にあります。

さらに、6LBRは、[RFC4861]のように、LoWPANに割り当てられたプレフィックスまたはプレフィックスのセットで何らかの方法で構成され、それらをRAでアドバタイズします。ルートオーバーの場合、これらのプレフィックスは、セクション8.1で説明されている手法を使用してすべての6LRに配布できます。ただし、ルートオーバーポロジでのプレフィックス配布の代替として使用できる、このドキュメントの範囲外のメカニズムが存在する場合があります（セクション1.4を参照）。

6LoWPANがコンテキスト付きのヘッダー圧縮[RFC6282]を使用する場合、6LBRはCIDを管理し、RAに6COを含めることでRAでそれらをアドバタイズして、直接接続されたホストにCIDについて通知する必要があります。以下では、6LBRがコンテキスト情報を追加、削除、または変更する必要がある場合に考慮すべき事項を指定します。ルートオーバーの場合、コンテキスト情報は、別の仕様がこのマルチホップ配布の代替を提供しない限り、セクション8で説明されている手法を使用してすべての6LRに配布されます。

7.1. プレフィックスの決定

LoWPANで使用されるプレフィックスは、手動で構成するか、DHCPv6プレフィックス委任[RFC3633]を使用して取得できます。ネットワークから恒久的または一時的に隔離されているLoWPANの場合、6LBRは[RFC4193]を使用してULAプレフィックスを割り当てることができます。ULAプレフィックスは、6LBRの障害後も同じプレフィックスが使用されるように、安定したストレージに保存する必要があります。LoWPANに複数の6LBRがある場合、それらは同じプレフィックスセットで構成する必要があります。プレフィックスのセットは、[RFC4861]で指定されているようにRAメッセージに含まれます。

7.2. コンテキストの構成と管理

6LoWPANがコンテキスト付きのヘッダー圧縮[RFC6282]を使用する場合、6LBRはコンテキスト情報と関連するCIDで構成する必要があります。LoWPANに複数の6LBRがある場合、それらは同じコンテキスト情報とCIDで構成する必要があります（MUST）。[RFC6282]で述べられているように、コンテキスト情報の一貫性を維持することは、パケットが正しく解凍されることを保証するために不可欠です。

RAメッセージで伝送されるコンテキスト情報は6LBRで発生し、LoWPAN内のすべてのルーターとホストに配布する必要があります。RAには、コンテキストごとに1つの6COが含まれます。

6COを使用したコンテキスト情報の配布には、LoWPAN全体でコンテキスト情報が同期されたままであることを保証するために、厳密なライフサイクルを使用する必要があります（SHOULD）。新しいコンテキスト情報は、このコンテキスト情報に基づいてヘッダー解凍を実行する必要があるすべてのノードに確実に認識されるように、C=0でLoWPANに導入する必要があります（SHOULD）。この情報が正常に配布されたと想定するのが妥当な場合にのみ、C=1のオプションを送信して、圧縮のためのコンテキスト情報の実際の使用を有効にする必要があります（SHOULD）。

逆に、ノードが以前のコンテキスト値を使用するパケットを送信する状況（これは、最近変更されたコンテキストを使用するパケットを受信したときに曖昧さを生じさせる可能性があります）を回避するために、新しい値がこの特定のコンテキストに割り当てられる前に、コンテキストの古い値をしばらく使用から外す必要があります（SHOULD）。つまり、コンテキスト情報の変更に備えて、その配布は少なくともMIN_CONTEXT_CHANGE_DELAYの間、C=0で継続する必要があります（SHOULD）。コンテキストが無効になったという事実が正常に配布されたと想定するのが妥当な場合にのみ、CIDを配布から外すか、別のコンテキストプレフィックスフィールドで再利用する必要があります。後者の場合、新しい値の配布は、上記のように再びC=0で開始する必要があります（SHOULD）。