要約

  • RFC 5175 の Expanded Flags Option は、RA ヘッダーの 8 ビットに 48 の位置を加え、将来の拡張を未知のまま読み飛ばせる仕組みを定めた。
  • キャプチャ上の 1 は送信者の表明である。受信実装が意味を知り、フィルターを通り、関連オプションを満たし、ポリシーが許し、状態が変わったことは別の証拠を要する。

標準の寿命は一斉更新によって支えられているのではない。新旧が同じリンクに存在できるから長く使える。RFC 5175 は ICMPv6 オプション Type 26 に 48 の追加位置を置き、その共存を可能にした。位置 0〜7 は元の RA ヘッダーに残り、8〜55 が拡張側にある。

長さは未来への逃げ道

Length は 8 オクテット単位で、定義された形式では 1 となる。しかし受信側は将来の長い形式を想定して値を確認する。1 未満ならオプションを無視し、理解できないデータやフラグも無視する。

ここで重要なのは、無視が失敗ではない点だ。古い実装にとっては期待された互換動作である。したがって監視画面にエラーがなくても、新機能が動いたとは限らない。同じパケットが、ある端末では制御入力、別の端末では意味のない新記号になり得る。

IANA 表も能力台帳ではない。位置と名称と根拠文書を衝突なく結び付ける台帳である。調査時点の S ビットは進行中の Internet-Draft を参照している。この状態は日付付きで記録すべきで、公開済み RFC や普及済み機能へと言い換えてはならない。

二つ目は上書きではない

送信側は Expanded Flags Option を RA にだけ、最大一回入れる。セットする既知の拡張ビットがなければ省略する。複数あった場合、受信側が処理するのは最初だけで、後続は無視される。

この規則はログ設計を試す。解析基盤が全インスタンスのビットを合成すれば、実際のホストが採用しない架空の状態を作る。最後の値を最新版として扱うのも誤りである。パケットの順序、最初に採用されたオプション、宣言長と捕捉長を保持しなければならない。

さらに拡張フラグは、それに関連する追加オプションより前に置かれる。ビットだけをイベント化して後続を捨てると、意味を検証する材料が失われる。主張とパラメータは同じ証拠単位に残す必要がある。

割当が変えたもの、変えなかったもの

RFC 5075 はほぼ同じ形式を示していたが、タイプは暫定だった。RFC 5175 は正式な 26 を記入した。これにより独立した実装が同じ線上表現を使えるようになったが、既存端末にコードが配布されたわけではない。

ゆえに報告は「割当済み」「送信で観測」「受信側が認識」「信頼または許可」「状態へ適用」「通信で確認」を分けるべきだ。SEND は Neighbor Discovery の認可面を補い、RA-Guard は L2 で通過を制御する。どちらもビットそのものとは別の領収書である。

RFC 6105 は RA-Guard が効くための経路とトポロジー条件を示す。RFC 7113 は一部実装の回避可能性と、IPv6 ヘッダーチェーンを十分に解析する必要を記録した。機能名が設定画面にあるだけでは、対象パケットの判定を証明しない。

SNAC Router Flag の現行ドラフトも、未知の端末はビットを静かに無視し、フィルターによって下流へ届かない場合があるとする。これは採用率の証明ではなく、送信から効果までに複数の境界があることの好例である。

出典