6. 6LR と 6LBR のルータ動作 (Router Behavior for 6LRs and 6LBRs)
6. 6LR と 6LBR のルータ動作
6LR と 6LBR は, ホストから受信する NA メッセージ内の ARO, 他ノードからの ND パケット, そして(潜在的に) 第 3.5 節で概説する 6LoWPAN で使用されるルーティングプロトコルに基づいて近隣キャッシュ (Neighbor Cache) [RFC4861] を維持する。
ルータは, Registration Lifetime が失効するまで保持する必要があるため, 登録済み NCE (Registered NCE) (第 3.4 節参照)をガベージコレクションすることを SHOULD NOT とする。同様に, ルータ上の NUD が([RFC4861] の論理に基づいて)ホストが UNREACHABLE になったと判定した場合も, NCE は削除すべきではなく, Registration Lifetime が失効するまで保持することを SHOULD NOT とする。更新された ARO はキャッシュエントリを STALE としてマークすべきである。したがって, 6LoWPAN ルータにおいて近隣キャッシュ (Neighbor Cache) はキャッシュのように振る舞わない。代わりに, ルータに接続されたすべてのホストアドレスのレジストリとして振る舞う。
ルータは デフォルトルータ優先度 (Default Router Preference, Prf) 拡張 [RFC4191] を実装し, それを用いてホストに対してルータが 6LBR か 6LR かを示してもよい(MAY)。これが実装される場合, ボーダールータへの経路を持たない 6LR は Prf を (11) の低優先度に MUST 設定し, その他の 6LR は Prf を (00) の通常優先度に MUST 設定し, 6LBR は Prf を (01) の高優先度に MUST 設定する。
6.1. 禁止される動作
ルートオーバー (route-over) トポロジにおいてルータがホストと別のターゲットの両方に到達できる場合でも, 無線伝搬のため, ホストが別のターゲットへ直接到達できるかどうかを一般に知ることはできない。したがって, リダイレクト (Redirect) がホストから別のホストへの経路で実際に機能するとは仮定できない。よって, Redirect メッセージを送信することを SHOULD NOT とする。この "SHOULD NOT" の唯一の潜在的な例外は, 配備/実装がホストが意図したターゲットへ到達する方法を知る手段を持つ場合である。したがって, 実装はデフォルトでは Redirect を送信しないことが RECOMMENDED であるが, 配備が必要とする場合には設定可能であり得る。対照的に, メッシュアンダー (mesh-under) トポロジでは Redirect に関する考慮は [RFC4861] と同様である。
ルータは PIO において L (リンク上 (on-link)) フラグを設定してはならず(MUST NOT), それはホストにマルチキャスト NS を送信させる可能性がある。
6.2. インタフェース初期化
6LBR のルータインタフェース初期化動作は [RFC4861] と同じである。しかし, 動的構成シナリオ(第 8.1 節参照)では, 6LR は非ルータとして起動し, 自身のインタフェースアドレスを構成するための広告をまず受信するまで待ってから, そのインタフェースを広告インタフェースに設定してルータへ移行する。
6.3. ルータ要請 (Router Solicitation) の処理
ルータは [RFC4861] に従って RS メッセージを処理する。差分は, RA メッセージに ABRO を含めることと, ユニキャスト RA の排他的使用に関するものである。6LR が 6LBR から ABRO を受信している場合, そのオプションを変更せずに RA メッセージに含める。さらに, 6LR が異なる 6LBR から(同一または異なるプレフィックス/コンテキスト情報を含む)RA を受信している場合, 6LR が送信する RA が ABRO とプレフィックス/コンテキスト情報の関連付けを維持できるよう, それらのプレフィックスとコンテキスト情報を別々に保持する必要がある。ルータは ABRO の 6LBR Address フィールドから, どの 6LBR がプレフィックス/コンテキスト情報を起源としたかを判別できる。ルータが複数の ABRO に紐付く情報を持つ場合, 単一の RS に対して異なる ABRO をそれぞれ含む複数の RA が返される。
ある 6LBR に関連付けられた ABRO Valid Lifetime がタイムアウトした場合, その 6LBR に関連するすべての情報は MUST 削除されなければならない。実装上の注意として, 1 回の RA 欠落で 6LBR に関連するすべての情報が削除されないよう, ABRO Valid Lifetime より十分に高い頻度で RA を送信することが推奨される。
登録がまだ行われていないホストから RS を受信する可能性がある。したがって, ルータは RS の SLLAO に基づいて既存の NCE を変更してはならない(MUST NOT)。しかし, ルータは SLLAO に基づいて Tentative NCE を作成してもよい(MAY)。その Tentative NCE は, 登録によって Registered NCE に変換されない限り, TENTATIVE_NCE_LIFETIME 秒でタイムアウトさせることを SHOULD とする。
6LR または 6LBR は, 送信する RA に SLLAO を MUST 含めなければならない。これはホストがルータのリンク層アドレスを知るために必要である。[RFC4861] と異なり, RA の Router Lifetime フィールドの最大値は 0xFFFF(約 18 時間)まで MAY である。
[RFC4861] がマルチキャスト RA を示唆するのと異なり, 本仕様は RS に応答して常にユニキャストで RA を返すことで交換を改善する。これは, RS が常に SLLAO を含み, ルータがそれを用いて RA をユニキャストできるためである。
6.4. 周期的なルータ広告 (Router Advertisement)
ホストは lifetime が失効する前に RS を送って更新情報を要求するため, ルータは周期的な RA メッセージを送信する必要はない。
ただし, ルータが route-over トポロジにおいて RA を用いてプレフィックスおよび/またはコンテキスト情報を分配する場合, 周期的な RA が必要になることがある。そのような RA は [RFC4861] に従って, 設定可能な MinRtrAdvInterval と MaxRtrAdvInterval を用いて送信される。
6.5. Neighbor Solicitation の処理
ルータは [RFC4861] に従って NS メッセージを処理し, ARO を扱うために本節で述べる追加の論理を適用する。
NS とそのオプションの通常の検証に加え, ARO(存在する場合)は次のように検証される。Length フィールドが 2 でない, または Status フィールドが 0 でない場合, NS は黙って無視される。
NS の送信元アドレスが unspecified アドレスである, または SLLAO が含まれない場合, 含まれる ARO は無視され, すなわち ARO を含まないかのように NS が処理される。
6.5.1. 重複の確認
NS が有効な ARO を含む場合, ルータは到着インタフェース上の Neighbor Cache を調べて重複かどうかを確認する。次の場合は重複ではない: (1) NS の IPv6 送信元アドレスに対する NCE がない, または (2) その NCE が存在し EUI-64 が同一である。その他の場合は重複アドレスである。multihop DAD(第 8.2 節)が使用される場合, Tentative NCE を考慮して検査がわずかに異なる点に注意する。重複アドレスの場合, ルータは第 6.5.2 節で述べるように ARO Status を 1(重複を示す)に設定したユニキャスト NA で応答する。この場合, Neighbor Cache は変更されない。
6.5.2. アドレス登録エラーの返却
L2 アドレス衝突の可能性があるため, アドレス登録エラーは NS の送信元アドレスには返されない。代わりに, NA は [RFC4944] に従って ARO の EUI-64 フィールドから導出された Interface ID 部分を持つリンクローカル IPv6 アドレスに送信される。特に, universal/local ビットを反転させる必要がある。NA は NS の ARO をコピーして整形されるが, Status フィールドは適切なエラーを示す値に設定される。
エラーは EUI-64 から導出された Interface ID を持つリンクローカルアドレスに送信される。したがって, ARO が短いアドレスのためのものであった場合, ARO エラーを含む NA の L2 宛先アドレスは 64 ビットのユニークアドレスになる。
6.5.3. 近隣キャッシュ (Neighbor Cache) の更新
前述のとおり重複アドレスが検出されない場合, Registration Lifetime が 0 でなければ, ルータは NS の IPv6 送信元アドレスに対する NCE を作成(存在しない場合)または更新(存在する場合)する。近隣キャッシュ (Neighbor Cache) が満杯で新しいエントリ作成が必要な場合, ルータは第 6.5.2 節で述べるように ARO Status を 2(ルータの近隣キャッシュ (Neighbor Cache) が満杯)に設定したユニキャスト NA で応答する。
Registration Lifetime と EUI-64 は NCE に記録される。その後, NS に応答してユニキャスト NA が送信される。この NA は ARO のコピーを SHOULD 含み, Status フィールドを 0 に設定する。[RFC4861] の TLLAO (Target Link-Layer Address Option) は, ホストが RA からルータのリンク層アドレスを既に知っているため, NA に必須ではない。
ARO が 0 の Registration Lifetime を含む場合, NS の IPv6 送信元アドレスに対する既存の NCE は MUST 削除され, 前述のとおり NA が送信される。
NCE の Registration Lifetime が失効した場合, ルータはキャッシュエントリを MUST 削除する。
Registered NCE の追加と削除はルーティングプロトコルへ通知されることになる。
注意: substitutable multihop DAD(第 8.2 節)が使用される場合, Tentative NCE のため Neighbor Cache の更新はわずかに異なる。
6.5.4. 次ホップ決定
ルータに登録された 6LN 宛のパケットを配送するため, 次ホップ決定はホスト(第 5.6 節参照)とは少し異なる。ルーティングテーブルを参照して次ホップ IP アドレスを決定する。Registered NCE は次ホップ IP アドレスが on-link かどうかを決定する。登録済み隣接ノードに関する on-link 情報を維持するのはルータのルーティングプロトコルの責任である。Tentative NCE は登録済みノードの on-link 状態決定に MUST NOT 使用される。
6.5.5. ルータ間のアドレス解決
ルータが互いのリンク層アドレスを発見する仕組みがどこかに必要である。ルータ間で使用されるルーティングプロトコルがこれを提供するなら, ルータ同士で ARO を使用する必要はない。そうでなければ, ルータは ARO を SHOULD 使用する。ルータが ARO を用いて互いに登録し, かつ multihop DAD(第 8.2 節)が使用されている場合, 各ルータが隣接ルータから ARO を聞くたびに ARO 搭載メッセージが 6LBR へ洪水のように送られないよう注意が必要である。このシナリオの詳細は本書の範囲外である。
ルータは [RFC4861] と同様にマルチキャスト NS を用いて互いのリンク層アドレスを解決してもよい(MAY)。したがって, 例えば何らかのルーティングプロトコル更新を受信した結果として, ルータは他のルータに対して NS をマルチキャストしてもよい。ルータはマルチキャスト NS に MUST 応答しなければならない。これは, ルータが [RFC4861] に従って 要請ノード (solicited-node) マルチキャストアドレスに MUST 参加しなければならないことを意味する。