要約

  • RFC 9710はIANA IPFIXレジストリのforwardingStatusをunsigned8からunsigned32へ訂正した。ただし現行版はreduced-size encodingで1オクテットとして出力する。
  • Data Record上の実長は有効なIPFIX Templateが宣言する。1オクテットの値は、4オクテットの抽象上限と矛盾しない。
  • レジストリ訂正だけでは、配備済みコレクタ、過去のFlow、パケットが実際に転送・破棄された事実は更新されない。

四バイトの型、一バイトの現行表現

Information Element 89はFlowの転送状態と理由を運ぶ。現在意味が割り当てられているのは最下位バイトだけで、上位2ビットがUnknown、Forwarded、Dropped、Consumedを示し、残る6ビットが理由である。RFC 7270は抽象型をunsigned32としたが、旧IANA行はunsigned8だった。RFC 9710は前者にそろえ、現行構造は1バイトに縮小して送ると明記した。

ここでは二つの幅が別の仕事をする。抽象型は将来の上位ビットを含む最大表現を定め、TemplateのField Lengthは後続Data Recordの符号化長を定める。RFC 7011は、値が収まる符号なし整数から先頭のゼロを省くことを認める。したがって、型が4バイトでTemplate長が1という組合せが正しい。

Element IDだけを見て1バイトに固定した実装は将来の拡張に備えられない。逆に、レジストリだけを見て常に4バイト読む実装は、現行の正しいレコードで後続フィールドをずらす。コレクタにはInformation Element、Template ID、Observation Domain、Transport Sessionを結んだ解釈が必要になる。

RFC 9710は、IANA値を定期ジョブなどで自動抽出し、新しいIEや値をコレクタが解釈できるようにする目的も記す。つまりレジストリは閲覧資料であるだけでなく、ビルド入力になり得る。取得URL、時刻、ハッシュ、生成器、成果物、配備先を残さなければ、「最新対応」という表示を再現できない。

Droppedが証明しないこと

現行バイトでは0x40がForwarded／追加情報なし、0x89がDropped／bad TTLである。後者の説明はRFC 7270の検証済みErrata 5262で訂正された。正しい理由コードは重要だが、その値はExporting ProcessがObservation PointからFlowについて述べた内容にとどまる。

宛先の受領、全経路の状態、個々のパケット履歴、唯一の原因、SLA違反までは含まれない。運用判断には、元のTemplateとData Set、エクスポータ設定、インターフェース計数、独立キャプチャ、下流観測、判断権限を接続しなければならない。

過去データも同じである。今日の表を適用しても、当時のバイトやソフトウェアは変わらない。文脈を残さず再解釈すれば、確度を上げるのではなく作り出してしまう。RFC 5610のインライン型レコードはセッション限定で、コレクタ内部定義を置換できず、IANA追随の代替でもない。

出典