要約

  • ipv6ExtensionHeadersLimit=false は上限によって報告が部分的になったことを示し、true は内包された拡張ヘッダー全体と報告が一致することを示す。名前から真偽を逆に読んではいけない。
  • RFC 9740 は種類、同種の連続出現、順序、チェーン長を分けて記述する。表現できることは、配備済み装置で観測できることや受信端末で正常処理されたことの証明ではない。
  • 欠測や部分観測は、根拠のあるゼロと別に扱う必要がある。更新後の検出増加は、トラフィックではなく観測範囲の変化かもしれない。

同じ表示が異なる証拠を隠す

IPv6 の長いチェーンの後方に HIP がある場合を考える。ある装置は最後まで解析する。別の装置は HIP の位置に届く前に止まる。さらに別の装置は HIP を表せない古いフィールドを使う。後二者を「HIP なし」と表示すれば、未観測と不在の違いが消える。これは仮定の比較であり、特定製品の実測ではない。

2025年3月の標準化過程文書 RFC 9740 は、IPFIX に12の情報要素と unsigned256 型を追加した。従来の ipv6ExtensionHeaders（64）は表現可能な集合が固定され、HIP（139）、Shim6（140）、実験用拡張ヘッダーなどを含められなかった。順序、繰り返し、チェーン長、全体か部分かという明示的な意味も不足していた。tcpOptions（209）は TCP Option Kind 63 までしか表せず、253と254を共有する実験を識別できなかった。両要素は非推奨となったが、過去の列名を変更しても当時の観測能力は変わらない。

上限の宣言が意味する範囲

第3.5節 の要素517は、通常ハードウェアやソフトウェアの制約によって到達できた部分だけを報告する場合に false となる。True は内包された拡張ヘッダー全体に一致する報告である。517がないことを、完全報告の肯定的な宣言とみなすことはできない。

符号化にも落とし穴がある。RFC 7011 第6.1.5節 では IPFIX の boolean は true が1、false が2で、それ以外は未定義である。生の0を通常のプログラムの偽値として解釈しても、規格上の false にはならない。これは正しく符号化されたビットマップのゼロとは別の問題だ。

完全という宣言にも境界がある。RFC 7011 の Flow は、一定期間に特定の観測点で共通の性質を持つパケットの集合である。観測したパケットの拡張ヘッダー全体を記述できても、リンクの全パケットを選んだこと、別経路も同じであること、世界全体で使われていないことは証明しない。選択方式と分母を別途確認する必要がある。

部分報告は破棄の証拠でもない。RFC 8883 は、拡張ヘッダーの長さ、総チェーン長、個数などの処理上限と ICMP 診断を扱う。解析、転送判断、エクスポートは分けて観察すべきだ。ICMP は失われたり、フィルタリングや送信頻度の制限を受けたりするため、その沈黙も正常処理の証明にはならない。

種類、並び、長さを一つの値にしない

RFC 8200 の IPv6 拡張ヘッダーは Next Header によって上位層まで連結される。RFC 9740 の ipv6ExtensionHeaderType（513）は観測した種類のコードを、ipv6ExtensionHeaderCount（514）は同じ種類の連続出現数を記述する。514はパケット数でも、利用者数でも、採用率でもない。

ipv6ExtensionHeaderTypeCountList（516）は種類と個数の組を順序どおり保持する。Hop-by-Hop、Destination Options、Fragment、Destination Options という例では、二つの Destination Options は Fragment の前後で別の位置として残る。同一 Flow に異なるチェーンがあれば別々に報告する。観測した未知の種類を拡張ヘッダーと判定できた場合、機能を実装していなくても正確なコードを報告しなければならない。未知の Next Header が拡張か上位層かという判定自体は、別の問題として残る。

ビットマップ ipv6ExtensionHeadersFull（515）は、観測対象 Flow のいずれかのパケットにその種類があったことを表し、順序を復元しない。ビット位置は IANA IPFIX 登録表 に従う。Destination Options のプロトコル番号60はビット0、Hop-by-Hop の0はビット1、HIP の139はビット10であり、番号をそのまま位置にしてはいけない。No Next Header は拡張ヘッダーではないが特例として含まれる。515と516の同時エクスポートは禁止されている。

ipv6ExtensionHeadersChainLength（518）は全拡張ヘッダーの長さをオクテットで合計し、IPv6 基本ヘッダーと上位層ヘッダーを除外する。個数ではない。ipv6ExtensionHeaderChainLengthList（519）は515と518を組にして異なるチェーンを分ける。519を使う場合、その異なるチェーンのビットマップをまとめてはならない。使わない場合には規格が許す集合的な記述もある。種類と長さの組が、順序や未検査の残りを再現するわけではない。

計測系列が更新をまたぐとき

TCP の tcpOptionsFull（520）は0から255の Kind を直接ビット位置にする。未対応の機能でも観測した種類を表現できる。一方、IPv6 の新しい種類は IPFIX 表の次の空きビットに対応づけられ、別の動作ビットが必要な例外は Expert Review による。登録表の更新は、すべての配備済みソフトウェアの更新を意味しない。

論理上256ビットでも、常に32オクテットを送るとは限らない。縮小サイズ符号化では許された先頭のゼロを省略でき、Template が実際の長さを示す。正しく短縮された存在する要素を、欠測と扱ってはならない。大きな整数を保存するデータベースも、上流の解析深度を証明しない。

RFC 6994 は共用 Kind 253、254の実験を16または32ビットの ExID で区別する。RFC 9740 の ExID リストが Flow にある場合、その正の情報が優先され、共用 Kind の汎用ビットはゼロにしなければならない。ビットマップだけの集計は実験の存在を見落としうる。自律的な識別と幅の判定には、実装側で有効な ExID リストを維持するという前提がある。

旧64や209からの移行、解析範囲の拡大、対応表の更新は、同じトラフィックから多くの種類を検出させることがある。反対に、集計が横ばいでもチェーンの複雑化によって死角が増えている可能性がある。比較可能な母集団と重複期間の観測があれば、変化の原因を確かめやすい。なければ系列の切れ目と未解決の差を明記する。過去の表現不能部分や未検査部分をゼロで埋めれば、滑らかな線と引き換えに証拠を作ってしまう。本稿の根拠は規格の意味であり、現在の世界的な普及率や端末の成功率ではない。

出典