摘要

  • draft-ietf-ippm-stamp-ext-hdr-15 允许 Session-Reflector 把去程测试包中实际收到的固定报头或 IPv6 扩展报头复制进 STAMP TLV；这只是 R1 端的一次观察。
  • 双向模式另外要求反射器为回程包生成同类 IPv6 扩展报头。草案明确说它们不必逐字节复制，长度与内容由反射器本地决定。
  • 收到响应不证明字节对称、路由对称、中间节点处理一致或 IOAM 记录完整。数据面可见性、匹配、MTU、披露策略、完整性与限速都会改变证据。

最容易误导人的测量图通常非常整齐：S1 发出带扩展报头的测试包，R1 发回一个看似相同的包，两个方向之间画着同一条线。图形暗示“报头走了一个来回”。

修订版 15 实际定义了两件事。第一件是把 R1 收到的去程报头复制到 STAMP 负载中的反射数据 TLV。第二件是在发送响应时，为回程本地生成一个同类报头。副本描述过去发生的接收；新报头是一次新的构造。它们可以出现在同一个响应中，却不是同一个对象。

负载中的副本与线路上的报头

RFC 8762 定义 STAMP 的往返与时间戳，RFC 8972 定义可选 TLV。发送端先把反射数据区域清零。请求 IPv6 扩展报头时，它填写长度，并在需要消歧时携带前八个字节；固定 IPv4/IPv6 报头使用前四个字节。反射器从数据面收到的对象中匹配目标，再把其余字节复制进 TLV。

回程报头由另一个控制项触发。IPv6 Extension Header Control Sub-TLV 要求 R1 按接收时的类型顺序添加本地生成的匹配报头，但草案不要求逐字节一致，也不要求重建发送端专用的路由报头。

因此日志至少需要五个对象：去程发送报头、R1 收到的报头、TLV 中的副本、R1 生成的回程报头、S1 最终收到的响应。一个布尔值无法承载这些关系。

“双向”只描述构造，不描述拓扑

草案纯文本 明确允许响应走同一路径，也允许走不同路径；回程不要求经过同一个中间节点。这里的单向与双向，只表示 R1 是否为回程添加对应扩展报头。

在单向模式下，R1 仍可把去程接收报头复制进响应负载，却不在回程 IP 包上添加同类报头。在双向模式下，它添加的是新构造。bidirectional=true 不能被翻译成“链路、节点或字节镜像”。

选择哪一个报头本身也要留痕

如果多个报头长度相同，前八或前四个字节负责消歧。方案假定这些字节到达 R1 之前不会改变；全零则选择第一个同长度对象。系统必须记录请求长度、判别字节、命中序号和返回摘要。

多个报头从外层开始依次处理。固定报头 TLV 与扩展报头 TLV 同时出现时，顺序也必须映射包内逻辑顺序。长度不符、顺序错误、不支持、无效或数据面无法上送时，反射器按 RFC 10052 的 C 标志流程返回，某些情况下不会复制任何数据。响应存在不等于请求完成。

转发看见，不等于测量进程看见

草案要求出口数据面把收到的扩展报头交给 Session-Reflector；双向测量时，S1 的入口数据面也要把回包扩展报头交给 Session-Sender。缺少这条接口，设备可以正确转发或处理选项，却无法为 STAMP 提供副本。

RFC 9197 定义 IOAM 数据字段，RFC 9486 定义它们在 IPv6 选项中的承载。返回记录只证明 R1 最终收到哪些字段，不证明每个预期节点都参与。缺失可能来自空间、能力、采样、不同路径或不暴露。

RFC 8250 限制途中插入或删除 IPv6 扩展报头；修订版 15 将沿途改变存在性或长度排除在范围外。不能把它宣传成对所有报头改写的通用探针。

MTU 与本地政策会有意减少证据

IP、UDP、STAMP 与全部 TLV 必须落在适用的路径 MTU 内。超过时，要删除一个或多个反射 TLV。缺少字段可能是符合规范的裁剪，而不是网络把数据弄丢。

运营者还可配置 R1 不返回收到的报头，以免内部网络信息泄露给发送端。正确状态至少应区分：未观察、观察并返回、观察但因政策保留、因 MTU 删除、无法访问。把它们都写成空值，会把治理选择伪装成物理事实。

零校验和不是免费的捷径

修订版 15 为 IPv6 UDP 零校验和规定了受限例外。RFC 6936 与 RFC 8085 说明为什么普通校验和仍是默认值。零校验和只能用于明确启用的 STAMP 端口，必须校验地址，限定在单一管理域，并由运营者接受残余损坏风险。需要负载完整性时，建议使用认证模式。

RFC 8200 给出 IPv6 基线，RFC 9740 提供可用于验证扩展报头接收的机制。TLV 解析成功不能自动升级为“包未损坏”。

保护控制面的丢弃会伪装成链路丢包

STAMP 处理消耗 CPU 与内存，反射器必须限速防御拒绝服务。草案承认 punt path 上的限速丢弃，在 STAMP 结果中与真实网络丢包不可区分。必须把本地 policer 计数与失败通知关联。

有用的漏斗是 发送 / 数据面接纳 / R1 上送 / 解析 / 匹配 / 复制 / 生成回程报头 / 发出 / S1 接收。仅看最后一项，无法判断路径失败还是防护机制生效。

Last Call 不是运行结果

Datatracker 显示修订版 15 处于 IETF Last Call，截止 2026 年 10 月 15 日。历史页 记录 9 月 30 日提交与公告，邮件记录 记录分发机制。这些都不是 RFC 或部署凭据。

版本差异、早期评审 与 IANA STAMP 注册表 中尚待分配的值，说明文本仍可能变化。Teaparty 提交 是指定功能的运行代码证据，不代表独立互操作或生产覆盖。

最终凭据应包含包摘要、报头顺序、请求与判别字节、数据面上送、匹配位置、接收报头与 TLV 摘要、C 标志及原因、MTU 裁剪、披露决定、回程报头摘要、接口、校验和、认证、限速、实际路径证据与分析结论。

Running-Code Primacy 要求查看真实字节和状态转换。The Policy Mirror 揭示 MTU、披露与本地构造中的权力。Reality Layers 则防止“已反射”这个符号替代观察、构造与结果。

来源