5. ホストの動作 (Host Behavior)
5. ホストの動作
LoWPAN のホストは, 送信する NS メッセージ内の ARO を用いてルータの近隣キャッシュ (Neighbor Cache) を維持し, アドレス解決のためにマルチキャスト NS を使用する必要を取り除く。[RFC4861] と異なり, ホストはルータ広告 (RA) で受信する情報が失効する前にルータ要請 (RS) を送信して, RA で受信する情報の更新を開始する。最後に, NUD が 1 つまたはすべてのデフォルトルータが到達不能になったことを示すと, ホストは RS を用いて新しいデフォルトルータ集合を見つける。
5.1. 禁止される動作
ホストは NS メッセージを MUST NOT マルチキャストしてはならない。
5.2. インタフェース初期化
ホスト上のインタフェースが初期化されるとき, [RFC4861] の仕様に従う。リンクローカルアドレスは, [RFC4944] または当該リンクに対する適切な IP-over-foo 文書に従って, インタフェースに割り当てられた EUI-64 識別子 [EUI64] に基づき形成され, その後ホストは [RFC4861] 第 6.3.7 節で述べられるとおり RS メッセージを送信する。
この種のネットワークでは誰も NS をマルチキャストしないため, 要請ノード (solicited-node) マルチキャストアドレスに参加する必要はない。ホストは all-nodes マルチキャストアドレスに MUST 参加しなければならない。
5.3. ルータ要請 (Router Solicitation) の送信
RS は [RFC4861] で規定されるとおりに整形され, IPv6 の全ルータ (all-routers) マルチキャストアドレスへ送信される(詳細は [RFC4861] 第 6.3.7 節参照)。応答としてユニキャスト RA を可能にするため, 送信元リンク層アドレスオプション (Source Link-Layer Address Option, SLLAO) MUST が含まれなければならない。RS メッセージでは 未指定 (unspecified) の送信元アドレス MUST NOT を使用してはならない。
リンク層が, 何らかの all-routers anycast リンク層アドレスへパケットを送信する方法をサポートするなら, その方法 MAY を用いてこれらのパケットをルータへ運ぶことができる。
ホストはマルチキャスト RA に依存してルータを発見しないため, デフォルトルータリストが空であるとき, デフォルトルータの 1 つが到達不能になったとき, または直前の RA におけるプレフィックスおよびコンテキストの lifetime が失効しようとしているときには, ホストは RS を賢く再送する必要がある。再送率として RECOMMENDED なのは, まず [RFC4861] で規定されるとおり少なくとも 10 秒(RTR_SOLICITATION_INTERVAL)間隔で最大 3 回(MAX_RTR_SOLICITATIONS)の RS を送信し, その後より遅い再送へ切り替えることである。初期再送の後, ホストは各後続再送について, 再送タイマに対して切り詰めた二進指数バックオフ(truncated binary exponential backoff) [ETHERNET] を SHOULD 実行し, 再送タイマの増加を 60 秒(MAX_RTR_SOLICITATION_INTERVAL)で打ち切る。いずれの場合も, RA を受信したときに RS 再送を終了する。プロトコル定数は第 9 節参照。
5.4. Router Advertisement の処理
RA の処理は [RFC4861] と同じであるが, 6CO の取り扱いと, 新しいアドレスが構成されたときにアドレス登録をトリガする点が追加される。さらに, RA には SLLAO MUST を含めなければならない。[RFC4861] と異なり, RA の Router Lifetime フィールドの最大値は 0xFFFF(約 18 時間)まで MAY である。
ホストが誤って L (リンク上 (on-link)) フラグが設定された PIO を受信した場合, その PIO MUST は無視されなければならない。
5.4.1. アドレス構成
アドレス構成は [RFC4862] に従う。EUI-64 から導出されないアドレスに対して, RA の M フラグがアドレスをどのように構成できるかを決定する。RA で M フラグが設定されている場合, DHCPv6 [RFC3315] MUST を用いてアドレスを割り当てなければならない。M フラグが設定されていない場合, アドレスは他の任意の手段で構成できる(重複検出は登録手続きの一部として実行される)。
アドレスが一度構成されると, 1 つ以上のルータへ ARO を含む NS をユニキャストすることで登録される。
5.4.2. コンテキストの格納
ホストは, ルータから受信するコンテキスト情報のための概念的データ構造を維持する。この構造はコンテキストテーブル (context table) と呼ばれる。これには CID, プレフィックス(6CO の Context Prefix フィールドから), Compression ビット, Valid Lifetime が含まれる。Compression ビットがクリアされているコンテキストテーブル (context table) エントリは, パケット受信時の伸長に使用されるが, パケット送信時の圧縮には MUST NOT 使用されてはならない。
RA で 6CO を受信すると, context table の情報を追加または更新するために使用される。6CO の CID フィールドが既存の context table エントリに一致する場合, そのエントリは 6CO の情報で更新される。6CO の Valid Lifetime フィールドが 0 の場合, エントリは直ちに削除される。
context table に一致するエントリがなく, Valid Lifetime フィールドが 0 でない場合, 新しいコンテキストが context table に追加される。6CO は作成されたエントリを更新するために使用される。
6LBR がコンテキスト情報を変更した場合, ホストは直ちに気づかないかもしれない。最悪の場合, ホストは古いコンテキスト情報を保持し得る。この理由から, 6LBR はコンテキストのライフサイクルを慎重に管理するために第 7.2 節の推奨を使用する。ノードは 6CO を含む RA メッセージでヘッダ圧縮を使用することに注意すべきである。
5.4.3. プレフィックスおよびコンテキスト情報の維持
プレフィックス情報は [RFC4861] で規定されるとおりにタイムアウトする。context table エントリの Valid Lifetime が失効すると, エントリは受信専用(receive-only)モードに置かれる。これは, そのコンテキストに対して C=0 の 6CO を受信することと等価である。エントリは受信専用モードで既定の Router Lifetime の 2 倍の期間保持され, その後エントリは削除される。
ホストは, 情報の更新を要求するために次にいつ RS 送信を開始すべきかを判断するため, さまざまな lifetime を調べるべきである。重要となる lifetime は, 既定の Router Lifetime, PIO の Valid Lifetime, 6CO の Valid Lifetime である。ホストは, これらの lifetime のうち最も短いもの(すべてのプレフィックスおよびすべてのコンテキストにわたり)が失効するより十分前に, ルータへ 1 つ以上の RS をユニキャストすることを SHOULD 行い, ユニキャストに応答がない場合はマルチキャスト RS メッセージへ切り替える。RS の再送動作は第 5.3 節で規定される。
5.5. 登録と Neighbor Unreachability Detection
ホストは, IPv6 アドレスを登録するためにユニキャスト NS メッセージを送信し, またデフォルトルータがなお到達可能であることを検証するために NUD も行う。登録は, ホストが送信する NS に ARO を含めることで実行される。ホストに送信すべきデータがなくても, 他者がホストへパケットを送信しようとすることが期待される場合, ホストはルータ内の NCE を維持する必要がある。これは, Registration Lifetime が失効するより十分前に, ARO を含む NS メッセージをルータへ送信することで行われる。ホストは, ARO を含む NA メッセージを受信するまで, 最小タイムアウトを RETRANS_TIMER として最大 MAX_UNICAST_SOLICIT 回まで NS メッセージを再送する。
複数のデフォルトルータから RA メッセージを受信するホストは, ネットワークの堅牢性を高めるため, それらのうち 1 台より多くに登録を試みることを SHOULD とする。
NUD プローブは, [RFC4861] で規定されるとおり, トランスポートプロトコルまたはアプリケーションからの到達性確認により抑止できることに注意すること。
ホストが, 登録しているルータをもはや使用しないことを知っている場合, lifetime が 0 の ARO を含む NS を送信してルータから登録解除すべきである(SHOULD)。ホストが不本意にデフォルトルータとの接続性を失う場合に対処するため, ホストは適切に低い Registration Lifetime を SHOULD 使用すべきである。
5.5.1. Neighbor Solicitation の送信
ホストは, 新しいアドレスが構成されたとき, 新しいデフォルトルータを発見したとき, または Registration Lifetime が失効するより十分前に, ARO を含む NS メッセージの送信をトリガする。そのような NS は, ルータがホストのリンク層アドレスを記録する必要があるため, SLLAO MUST を含めなければならない。NS メッセージでは unspecified の送信元アドレス MUST NOT を使用してはならない。
5.5.2. Neighbor Advertisement の処理
ホストは [RFC4861] で規定されるとおり NA メッセージを処理するが, ARO を処理するための追加のロジックが本節に記述される。
NA およびそのオプションに対する通常の検証に加えて, ARO(存在する場合)は次のとおり検証される。Length フィールドが 2 でない場合, オプションは黙って無視される。EUI-64 フィールドがインタフェースの EUI-64 と一致しない場合, オプションは黙って無視される。
Status フィールドが 0 の場合, アドレス登録は成功した。ホストは, lifetime が失効するより十分前に新しい NS をトリガするために, ARO から Registration Lifetime を保存する。Status フィールドが 0 に等しくない場合, アドレス登録は失敗した。
5.5.3. 失敗からの回復
近隣ノードに関する到達性情報を維持する手順は, アドレス解決が実行されない例外を除き, [RFC4861] 第 7.3 節と同じである。
アドレス登録手順は 2 つの理由で失敗し得る: NS に応答がない(NUD 失敗), または失敗 Status (Status > 0) を持つ ARO を受信する場合である。NUD 失敗の場合, そのルータのエントリは削除される。したがって, アドレス登録はもはや重要ではない。Status フィールドが 0 でない ARO を受信した場合, そのアドレスの登録が失敗したことを示す。失敗 Status が 1 の場合, 重複アドレスが検出されたことを示し, [RFC4862] 第 5.4.5 節で記述される手順に従う。ホストは登録しようとしたアドレスを MUST NOT 使用してはならない。ホストが他のルータで有効な登録を持つ場合, それらはそれぞれに対して ARO lifetime を 0 にして登録することで MUST 削除されなければならない。
Status コード 2 は, そのルータの Neighbor Cache が満杯であることを示す。この場合, ホストはこのルータをデフォルトルータリストから削除し, 別のルータへ登録を試みることを SHOULD とする。ホストのデフォルトルータリストが空である場合, 第 5.3 節で規定されるとおり RS の送信に戻る必要がある。
将来の文書で他の失敗コードが定義される場合がある。
5.6. 次ホップ決定
宛先に対する次ホップの IP アドレスは次のとおり決定される。リンクローカルプレフィックス(fe80::)への宛先は常にその宛先へリンク上で送信される。リンクローカルアドレスは第 5.2 節で規定されるとおり EUI-64 から形成され, アドレス解決は実行されないと仮定される。リンクローカル宛先へのパケットは, [RFC4291] 付録 A の手順を逆にすることで送信される。
マルチキャストアドレスは on-link と見なされ, [RFC4944] または適切な IP-over-foo 文書で規定されるとおり解決される。[RFC4944] は LoWPAN ヘッダにおけるマルチキャスト宛先アドレスの表現方法のみを定義することに注意すること。link-local より大きいマルチキャストスコープをサポートするには適切なマルチキャストルーティングアルゴリズムが必要である。
他のすべてのプレフィックスは off-link [RFC5889] と仮定される。Anycast アドレスは常に off-link と見なされる。したがって, それらはデフォルトルータリスト内のいずれかのルータへ送信される。
LoWPAN ノードは, パケットがアドレス解決を待つ間にキューイングされないため, [RFC4861] で規定される近隣ごとの最小 1 バッファを維持する必要はない。
5.7. アドレス解決
アドレス登録機構と RA メッセージに含まれる SLLAO は, IPv6 アドレスをそれに関連付けられたリンク層アドレスへ解決するための十分な事前状態をルータおよびホストに提供する。リンクローカルプレフィックスとマルチキャストアドレスを除くすべてのプレフィックスは常にリンク外 (off-link) と仮定されるため, 近隣間でのマルチキャストベースのアドレス解決は不要である。
近隣のリンク層アドレスは NCE [RFC4861] に格納される。LoWPAN 圧縮を達成するため, ほとんどのグローバルアドレスはリンク層アドレスを用いて形成される。したがって, ホストは, このケースに最適化し, IPv6 アドレスの Interface ID に対応するリンク層アドレスと異なる場合にのみリンク層アドレス情報を格納することで, メモリ使用量を削減できる(すなわち, on-link/global ビットの反転以上に異なる場合)。
5.8. スリープ
LoWPAN の電池駆動ホストにとって低いデューティサイクルを維持することはしばしば有利である。本書で述べられる最適化は, 本節でさらに述べられるとおり, ホストがスリープすることを可能にする。ルータはスリープしているホスト宛てのトラフィックをキャッシュしたいかもしれないが, そのような機能は本書の範囲外である。
5.8.1. 適切な Registration Lifetime の選択
すべての ND メッセージがホストにより開始されるため, これによりホストは NS/NA メッセージ交換の間でスリープするか, または到達不能になり得る。NS メッセージに付随する ARO は, そのアドレスの NCE を Registration Lifetime フィールドの期間だけ有効に保つようルータに示す。ホストは, エネルギー特性に適したスリープ時間を選択し, 登録が成功裏に更新されることを保証するため, Registration Lifetime をスリープ時間より大きく設定すべきである(例えば, クロックドリフトや再登録の潜在的な再送のための追加時間を考慮する)。ホストの外部構成は, スリープ時間(ひいては Registration Lifetime)を選ぶ際に, ネットワークの安定性(トポロジがどれだけ速く変化するか)も考慮すべきである。動的なネットワークでは, ルータが無効な NCE をノードのために必要以上に保持しないよう, より短いスリープ時間が必要である。
5.8.2. 起床時の動作
ホストがスリープ期間から起床したとき, 次の起床までにタイムアウトする現在のアドレス登録を SHOULD 更新する。これは第 5.5.1 節で記述されるとおり ARO を含む NS メッセージを送信することで行われる。ホストはまた, 新しいユニキャスト RS を送信してプレフィックスおよびコンテキスト情報を更新する必要があるかもしれない(最大 Router Lifetime は約 18 時間であるのに対し, 最大 Registration Lifetime は約 45.5 日である)。起床後にホストが(NUD を使用して)以前のデフォルトルータの一部またはすべてが到達不能になったと判断した場合, ホストは新しいデフォルトルータを発見してアドレス登録手続きを再開始するためにマルチキャスト RS を送信する。