摘要

  • draft-ietf-ippm-stamp-ext-hdr-14 新增第 3.3 节：出口节点的数据面处理发送端探测包后，必须把收到的 IP 与 IPv6 扩展报头提供给本机反射器；双向测量时，入口节点的反向数据面也必须向发送端提供回包报头。
  • 草案尚非 RFC，也未证明设备已采用。报头长度与前缀选择、无法反射时返回 C 标志等机制，第 13 版已有实质内容；本次真正可独立报道的是内部交接责任被明确化。

一台设备可以同时给出两种看似矛盾的记录：端口显示探测包已到，测量程序却没有可供回传的扩展报头。两种记录未必有谁造假。报文进入转发面，与报头进入 STAMP 反射器，是相邻但不同的事件。9 月 18 日的第 14 版将两者之间的接口从隐含前提推进为规范性语句。

新增第 3.3 节规定，出口节点的数据面若处理了 Session-Sender 的测试报文，必须向该节点上的 Session-Reflector 提供收到的 IP 报头与 IPv6 扩展报头。若采用双向测量，另一端同样不能只凭“回包已到”作结：入口节点的反向数据面必须向 Session-Sender 提供从反射器回包收到的对应报头。这是草案对未来实现的要求，不是对某厂商现网缺陷的发现。

报头选择本身并非此次才出现。请求字段非零时，反射器要按长度和前八个字节识别 IPv6 扩展报头，固定 IP 报头则看前四个字节；请求字段为零时，按长度选第一个匹配报头。找不到请求的报头，返回的 TLV 置 C（符合性）标志。第 14 版把这些条件集中写进处理步骤，措辞也更清楚；第 13 版的字段定义已经载有零值选择、前缀匹配和无法使用 TLV 时的 C 标志，并把数据面无法提供报头列为可能情形。把这些旧规则称作“新增错误机制”，会掩盖真正变化。

新的交接要求把测量证据的边界照亮了。一个成功反射的 TLV，只能说明某个请求在反射器实际取得的数据中选到了报头；它不是路径上所有扩展报头的清单，更不能自动证明每个中间节点的 IOAM 数据完整。反过来，C=1 也不会单独指出是请求匹配失败、设备内部没有交付报头，还是其他约束。旧文 dk-gov-380 讨论的是 MTU、速率和总量限制共用 C 标志的出处问题；本篇关注转发面与测量端之间的交接。

第 14 版还明确，计算路径 MTU 时要把 IP、UDP、STAMP 与反射报头 TLV 一并计入完整测试包。之前已有不能超出 MTU 的保护，这只是把计数边界写得更精确。IETF Datatracker 目前将此稿列为活跃的 Internet-Draft，处于 AD Evaluation 并已提交 IESG；最终标准决议、互通测试与部署范围仍待证实。

来源