要約

  • RFC 9870 の SAFE／UNSAFE フィールドは、Flow にまとめられたパケット群で各 Kind が少なくとも一度観測されたかを表す。
  • 実験用 ExID リストは EXP／UEXP の一般ビットより優先され、識別子を残すが、パケット列や出現回数は残さない。
  • 解釈には観測点、Flow の区切り、選択方法、Template、Exporting Process、Collector の受領が要る。観測は相手側の処理証明ではない。

パケットの動詞を集合の名詞にする

UDP オプションはパケットごとに現れ、Flow の途中でも挿入できる。RFC 9870 はその動的な出来事を、検索しやすい集合へ写す。ElementID 525 の udpSafeOptions は SAFE Kind 0〜191、ElementID 526 の udpUnsafeOptions は UNSAFE Kind 192〜255 に対応するビットを持つ。

条件は単純である。Flow 内で一度でも観測すれば一、観測しなければゼロ。一度と千度、最初と最後、連続と散発は同じ値になる。二つのオプションが同じパケットに載ったか、離れたパケットに載ったかも分からない。

この単純化は用途が狭い限り強い。大規模な種類の把握や探索では、全パケットの複製よりはるかに扱いやすい。ところが下流の規則が一を「常時利用」、あるいは「問題の瞬間にも存在」と読み替えると、圧縮された情報より判断の方が大きくなる。

実験番号の優先規則

RFC 9868 は SAFE の EXP と UNSAFE の UEXP を予約した。RFC 9870 はさらに 16 ビットの udpExID と、SAFE 用・UNSAFE 用の二つのリストを定義する。同時に走る実験を一つの旗に潰さないためである。

リストがある場合、その存在自体が EXP または UEXP の観測を示す。Exporter は同じ Flow の一般ビットを重ねて一にしてはならない。したがって Collector や分析器は、ビットマップだけでなくリストも読む必要がある。一般ビットがゼロでも、リスト側に肯定的証拠が移っている場合がある。

それでもリストは時系列ではない。どの ExID が何個のパケットにあり、どちらが先で、同時だったかは保存しない。受信側が実験を理解したかも示さない。識別の曖昧さを減らす規則と、出来事の履歴は別物である。

ゼロを全体へ広げない

RFC 7011 の Flow は、ある Observation Point を一定期間通過し、定義された性質を共有するパケット集合である。つまり RFC 9870 のゼロは、その観測範囲で該当 Kind を見なかったという主張にすぎない。

観測点、Flow キー、active／idle timeout、選択やサンプリング、Metering Process の能力が不明なら、ゼロをネットワーク全体の不在へ広げられない。別の区間、別の時刻、選ばれなかったパケットには存在し得る。

一も同様に境界を持つ。測定面が少なくとも一度見たことは示すが、宛先からの受領書ではない。SAFE／UNSAFE の分類、Export Session の保護、Collector の受信、エンドポイントの解析、アプリケーション結果は、それぞれ独立に確かめる必要がある。

数値だけでは読めない

SAFE フィールドは RFC 9740 の unsigned256 を使い、上位のゼロを落とす reduced-size encoding が可能である。ExID リストは RFC 6313 の basicList に依存する。Template、フィールド長、IE 番号、登録上の意味を失えば、保存したバイト列だけから元の主張を確定できない。

IANA は 525〜529 の IE と UDP Kind／ExID を登録する。登録は共通の識別を可能にするが、実装、導入、観測、相手側の処理を認定するものではない。

情報源