要約

  • draft-ietf-ippm-stamp-ext-hdr-15 は、Session-Reflector が往路 packet で受け取った固定ヘッダーまたは IPv6 extension header を STAMP TLV にコピーする手順を定める。
  • bidirectional mode は別の制御で、復路 packet に locally generated matching header を追加する。byte-for-byte copy は不要で、長さと内容は R1 のローカル判断である。
  • reply の到着は、byte、route、midpoint、IOAM 記録の対称性を証明しない。data-plane access、matching、MTU、開示方針、完全性、rate limit が証拠を変える。

測定図では、S1 から R1 へ同じ線が引かれ、reply が反対向きに戻る。同じ extension header の名前が両側に書かれると、一つのヘッダーが往復したように見える。

改訂15 が定義するのは、受信した往路ヘッダーを TLV に保存する行為と、復路用ヘッダーを新しく作る行為である。前者は R1 での観測、後者は R1 の実行であり、同じ reply に存在しても同じ byte 列ではない。

TLVの中とwireの上

RFC 8762 の STAMP に RFC 8972 の TLV が加わる。IPv6 extension header の request は長さと先頭8 octet、固定 header は長さと先頭4 octetを識別に使う。reflector は data plane が渡した受信 header を照合し、残りを返却 TLV にコピーする。

復路では IPv6 Extension Header Control Sub-TLV が matching header の生成を求める。種類の順序は合わせるが、内容と長さは local decision である。sender 固有の routing header は再現対象から外せる。

記録すべき対象は、往路送信 header、R1 受信 header、TLV copy、復路生成 header、S1 受信 reply の五つである。

bidirectionalは対称という意味ではない

plain text は、reply が同じ path を通る場合と異なる path を通る場合を認め、同じ midpoint を通過する必要もない。bidirectional は reverse direction に matching header を加えるかどうかだけを表す。

unidirectional でも往路観測の copy は返せる。bidirectional では新しい header を作る。monitor が bidirectional=true を route symmetry と表示するのは、仕様にない主張である。

matchingの前提を隠さない

同じ長さの header が複数あるとき、先頭 byte が識別子になる。R1 到着までその部分が変わらないことが前提で、zero 値なら最初の同じ長さの header を選ぶ。要求長、識別 byte、ordinal、返却 digest を保存すべきである。

複数 header は外側から処理され、fixed-header TLV と extension-header TLV の順序にも制約がある。長さ不一致、誤順序、非対応、無効、data plane から取得不能の場合、RFC 10052 の C flag 手順が使われ、data がコピーされないこともある。reply があるだけでは成功ではない。

forwardingの可視性と測定の可視性

data plane は受信 extension header を STAMP process に渡す必要がある。機器が option を forwarding できても、endpoint API が byte を公開しなければ reflector は返せない。

RFC 9197 は IOAM field、RFC 9486 は IPv6 option を定義する。返された記録は R1 に届いた field を示すが、期待した全 node の参加を証明しない。空欄は capacity、space、sampling、別経路、非公開のいずれでもあり得る。

RFC 8250 の制約により、途中の extension header 挿入・削除は自由ではない。存在や長さが途中で変わる use case は本 draft の scope 外である。

MTUと開示方針

IP、UDP、STAMP、TLV を含む packet は path MTU に収まらなければならない。必要なら reflected TLV を削除する。欠落は packet loss ではなく、適合する縮小かもしれない。

operator は内部情報の露出を避けるため、received header をコピーしない local policy も設定できる。not observed、observed and returned、observed but withheld、removed for MTU、inaccessible を区別しなければならない。

zero checksumは条件付きの例外

IPv6 UDP zero checksum は狭い条件で許される。RFC 6936 と RFC 8085 に従い、通常 checksum が default である。例外は特定 STAMP port、address validation、単一管理 domain、残存 corruption risk の受容を必要とする。payload integrity が必要なら authenticated mode が推奨される。

RFC 8200 は IPv6 baseline、RFC 9740 は extension header 受信を確認する選択肢を与える。parse 成功だけで packet integrity は証明できない。

rate limitはnetwork lossに見える

STAMP 処理は CPU と memory を消費する。control-plane punt path の policing drop は、測定結果では実際の network loss と区別できない。local counter と failure notification の相関が必要である。

sent / delivered / parsed / matched / copied / generated / emitted / received の funnel を残す。最後の値だけでは原因が消える。

Last Callの位置づけ

Datatracker は改訂15を 2026年10月15日までの IETF Last Call とする。history は9月30日の提出、email record は配布を示す。RFCでもdeploymentでもない。

diff、early review、IANA registry の TBA は変更可能性を残す。Teaparty commit は listed function の running code であり、独立した相互運用や本番普及を示さない。

packet digest、header order、request、data-plane handoff、match、C flag、MTU omission、開示判断、reverse header digest、interface、checksum、authentication、policer、route evidence、analytic verdict を一つの chain として保存する。

Running-Code Primacy は実際の byte と transition を見る。The Policy Mirror は local choice の authority を示す。Reality Layers は「reflected」という記号と観測・生成・効果を分離する。

情報源