要約

  • RFC 1883 以来、IPv6 の TLV Option Type の上位2ビットは、処理中のノードがそのタイプを知らない時の結果を定めてきた。読み飛ばして続行する、パケットを捨てる、または捨てたうえで原因のタイプを指す ICMPv6 を返す、という四通りである。
  • その次のビットは Option Data が経路上で変化し得るかを示す。これは未知に対する処置と認証計算の境界であり、全ルーターの処理、middlebox の通過、内容の信頼性を保証する印ではない。

未知の意味と未知の長さは別問題だった

宛先が Destination Options ヘッダーを認識し、その中で未実装の TLV に出会ったとする。Value の意味は分からなくても、Type と Opt Data Len は読める。次のオプションが始まる位置まで失う必要はない。

1995年12月の RFC 1883 は、さらに処置を Type の1オクテットへ組み込んだ。先頭2ビットは非認識時の action、続く1ビットはデータの経路上の可変性を表す。残る5ビットもタイプ識別に参加する。

新しいオプションの作者が得たのは、古いノードを支配する権利ではない。未知の場合に守るべき最小の結果を、古い実装にも読める形で提示する手段だった。

2ビットは危険度ではなく四つの結果を示した

00 は長さ分だけ読み飛ばしてヘッダー処理を続ける。01 はパケットを破棄する。10 は破棄し、Source Address へ ICMPv6 Parameter Problem Code 2 を送り、pointer で未知の Option Type を示す。11 も同様だが、Destination Address が multicast なら ICMP を送らない。

これを安全性の順位と読むと誤る。00 の内容がローカルポリシーにとって無害とは限らない。11 のオプションも、理解できれば正当な機能かもしれない。ビットが語るのは、解釈できない状態で保持できる意味の範囲である。

ICMP の pointer は障害箇所を一つのオクテットまで絞る。しかし返答自体は失われ、制限され、別のフィルターに止められ得る。届けば一つの処理点の証拠になるが、届かないことはパス全体の対応を証明しない。

multicast の時だけ報告境界が分かれた

10 は宛先が multicast でも報告し、11 はその場合だけ報告を抑える。この違いにより、multicast 失敗から返信トラフィックが生じる可能性を Type から監査できる。

それでも rate limit と資源保護は運用者の責任である。ビットは multicast を攻撃と判定せず、エラーの到達も約束しない。どの報告動作がそのタイプに属するかだけを固定する。

可変ビットは変化する値を不変だと偽らなかった

3番目のビットは別の問いに答える。ゼロなら Option Data は経路上で変化せず、1なら変化し得る。Authentication Header がある場合、可変とされた Option Data は認証値の計算・検証で全ゼロのオクテットとして扱う。

正当な途中更新を許す値まで不変として認証すれば、正常な変更を改ざんと誤認する。IPv6 はその矛盾を避けた。ただし、可変ビットが誰にでも書換権を渡すわけではない。変更主体と手順は個別オプションの仕様が決める。

上位3ビットもタイプそのものだった

RFC 2460 は、上位3ビットを下位5ビットの番号に付く別ポリシーとして扱ってはならないと明記した。8ビット全体で一つの Option Type であり、下位5ビットが同じでも上位が違えば別タイプである。

Hop-by-Hop Options と Destination Options はタイプ空間を共有するが、個別仕様は置けるヘッダーを制限できる。さらにオプションは出現順に処理する。前方の未知 TLV を保留して、後ろの既知 TLV だけ先に実行することは許されない。

順序は因果を守る。先のオプションが破棄を要求した後で、後ろの理解可能な情報がパケットを遡って正当化することはない。

未知オプションは未知 Extension Header ではない

action ビットが働くのは、認識済みの Hop-by-Hop Options または Destination Options の中にある未知 TLV である。Next Header が未知の Extension Header タイプを指す場合に、そのまま同じ規則を使えるわけではない。

RFC 6564 は、既存の Destination Options で表せる新情報なら新しい Extension Header を作らないことを優先し、今後どうしても必要なヘッダーには共通の長さ形式を求めた。過去の全形式が一様になったわけではない。

RFC 7045 は役割も分けた。宛先ホストは未知 Extension Header を含むパケットを破棄する。一方、転送ノードは自分が新しいヘッダーを知らないという理由だけで通常は破棄すべきではない。ヘッダーを検査するなら、登録済みタイプへの知識を更新する責任を負う。これは、既知のコンテナ内で action ビットを読む処理とは別である。

middlebox は自己記述だけでは足りないことを示した

firewall や load balancer は transport header の port まで探す。長いチェーン、未知形式、Hop-by-Hop 処理は fast path の範囲を超え、再循環や制御プレーン負荷を招き得る。

RFC 8200 は四つの action と可変ビットを維持しつつ、転送ノードの Hop-by-Hop 処理を明示的な設定に結び付けた。RFC 9098 は、必要な上位情報を見つけられない装置が、検査せず通す、捨てる、または高価な処理経路へ送るという選択に直面することを記録した。

Type の自己記述は処理資源を増やさない。すでにその TLV まで到達した実装の無知を限定するだけである。

三つのビットが認可しなかったもの

00 は通行権でも安全証明でもない。11 は攻撃判定ではない。可変ビットは任意書換えの許可ではない。登録済みタイプも経路対応を証明せず、ICMP も送信者の身元や意図を認証しない。

この仕組みは権限が小さいからこそ機能する。共通仕様が結果を定義し、各ノードがローカルに適用し、実際のパケットが導入状況を示す。

情報源と証拠の限界

起点は RFC 1883、8ビットタイプの明確化は RFC 2460、現行コア規則は RFC 8200 にある。新規ヘッダー形式と転送境界は RFC 6564、7045、運用上の制約は RFC 9098 に基づく。これらは現在の全製品・全経路の対応率を示す統計ではない。