要約

  • RFC 5121 は IPv6 用の会聚サブレイヤーをリンクごとに最大一つ選ばせるが、その合意は休止、ルータ情報、マルチキャスト状態、配送結果まで保証しない。
  • 端末と基地局の間には複数の CID があり得る一方、L3 リンクはアクセスルータまでの接続と、必要なら端末別またはサービスフロー別のトンネルで構成される。
  • 正しい監視は「制御パケットがない」を結論にせず、休止遷移、ページング、最終 RA、MLD、プレフィックス、MTU、実パケットを別々に記録する。

移動端末が idle mode に入ると、無線リンクは解放される。ネットワークが端末へ届ける必要が生じたときにはページングが使われる。ここで通常の有線リンクと同じ頻度で Router Advertisement を送り続ければ、端末を起こし、空中インターフェースの資源を消費する。

RFC 5121 はこの事情に合わせ、RA の間隔を大きくできるようにし、休止中のホストへアクセスルータが周期的な MLD query を送らないことを勧める。制御トラフィックの減少は欠陥ではなく設計目的である。それでも「何も見えない」という観測だけでは、正常な休止か、状態消失かを判別できない。

サイレンスには遷移の証拠が要る

休止を正しく説明するには、少なくとも idle への遷移時刻、ページング制御の状態、最後に受理した RA、プレフィックスと lifetime、MLD membership、復帰時に再検証する条件が必要である。これらがなければ、監視は二つの誤りを犯す。正常な省電力を障害として起こし続けるか、到達不能と古い membership を「静かで正常」と判断するかである。

この問題は単なるモバイル特有の例外ではない。現実の層を分けずに欠如を意味へ変換する典型例だ。観測がないことと、対象がないことは同じではない。制御面は自分が観測した範囲だけを語るべきである。

一つの会聚サブレイヤーは一つの選択にすぎない

IEEE 802.16 には、IP 固有の Packet CS と Ethernet 系の経路を通じて IPv6 を運ぶ選択肢がある。端末と基地局は登録時に能力を交換し、動的サービス接続を作る際に、その接続が使う会聚サブレイヤーを示す。

両者が IP CS を扱えるなら、それが既定である。両者が IP CS と Ethernet CS の双方を示す場合も IP CS を使う。そして一つのリンクで交渉する IPv6 会聚サブレイヤーは最大一つである。共通方式に合意できなければ接続は作られず、その経路で IPv6 を送受信できない。

これは重要な相互運用上の境界だが、後続状態を代理しない。実装が規格上の encapsulation を備えること、現場設定で有効なこと、今回選ばれたこと、サービスフローが作られたこと、パケットが正しい接続を通ったことは別である。RFC は基地局実装に Standards Track の方式を支援するよう求める一方、設定で一部を無効にできることも認める。supported という一語では足りない。

CID の数は IPv6 リンクの数ではない

IP CS の分類器は IPv6 アドレス、Next Header、traffic class、ポート範囲などを使い、パケットをサービスフローと transport connection に対応付ける。その connection は CID で識別され、同じ端末と基地局の間に複数存在できる。

アクセスルータと基地局が同居する場合、一台の端末に向かう connection の集合が一つのリンクを形成する。両者が離れている場合、RFC 5121 は端末単位、またはそれより細かいサービスフロー単位のトンネルを推奨する。トンネルと無線側 connection の組み合わせが、端末とアクセスルータの点対点リンクになる。

したがって CID を一つの L3 リンクとして数えると、存在しないリンクを作ってしまう。逆に複数端末を粗いトンネルへまとめ、端末別リンクだと報告すれば、分離の前提を失う。台帳は端末から全 CID とトンネルを引け、任意の CID から一つの端末・ルータ文脈へ戻れる必要がある。

同じ基地局でもプレフィックスは共有しない

RFC 5121 のモデルでは各端末が異なるリンクに属し、各端末/ホストリンクへ固有の IPv6 プレフィックスを割り当てる。通常は一つ以上の /64 を割り当て、on-link flag を付けて広告する。端末が複数ホストを収容する CPE であっても、隣の加入者まで同じサブネットになるわけではない。

プレフィックスの証拠には、値だけでなく、広告したアクセスルータ、受信した端末文脈、flag、lifetime、委譲方式が要る。DHCP や AAA による委譲は配送手段の違いであり、帰属の曖昧さを許すものではない。

DAD を省略できる可能性も条件付きである。広告プレフィックスがそのリンクに固有であり、アクセスルータが同じプレフィックスから自分の global address を作らないという二条件が必要だ。点対点というラベルだけで自動的に DAD を切れば、最適化の前提を失う。

アドレスの作り方とリンクの定義を分ける

原文は 48-bit MAC から modified EUI-64 IID を作ることを求め、privacy extension のランダム IID も認めた。後の RFC 8064 は RFC 5121 を更新し、安定したリンク層アドレスを安定 IID に埋め込まないよう勧告した。

変更されたのは IID 生成方針であり、端末別リンクや固有プレフィックスのモデルではない。デバイス ID、IID、IPv6 address、CID、リンク ID を一つのキーに融合すると、規格更新のたびに歴史を破壊する。分離しておけば、新しい privacy 方針を採用しながらリンクの連続性を保てる。

MTU は設定、広告、実測で分かれる

IPv6 MTU の既定推奨値は 1500 octets である。異なる値を使うなら、アクセスルータは ND の MTU option で知らせる。Path MTU Discovery はさらに先の経路制約を示し得る。設定値と広告値と通過できたサイズは、それぞれ別の証拠になる。

原文には 11-bit Len field から MAC PDU size を 2048 bytes とする記述がある。Errata 1768 は最大値を 2047 とするが、状態は Verified ではなく “Held for Document Update” である。報告は計算だけを採用して手続きを消しても、原文だけを引用して既知の指摘を隠してもいけない。両方の出所を残す。

実運用の結論は controlled packet、Packet Too Big、境界 capture から得る。設定画面の 1500 はパケットの成功ではない。

小さな共通契約と、反証できる台帳

必要なのは万能な中央制御ではない。共通契約は、選んだ表現、L3 リンクの端点、フロー・CID・トンネル・プレフィックスを結ぶ識別子、証拠の export に限定できる。分類、節電、アドレス管理の実装はローカルで交換可能なままでよい。

ただし各 receipt を一つの ready flag に潰してはいけない。能力は可能性、交渉は選択、CID は connection、RA は設定、capture は現実、利用者結果はサービスを語る。休止中の沈黙を正しく理解するためにも、この境界が必要である。

出典