摘要

  • 探测确认只能证明一个带有明确标识、明确大小的报文，经当时所用路径到达远端分包层。
  • RFC 8201 把路径 MTU 视为随拓扑变化的状态；RFC 8899 要求重新确认，并在支持多路径或多归属时为每条路径维护状态机。
  • 可审计回执必须绑定端点、流或路径身份、封装开销、探测反馈、时间以及代表性业务交付结果。

一次绿色结果遇上两种有效 MTU

设想一个数据报服务把探测报文填充到 1450 字节。接收端确认了这一个探测，发送端于是提高当前 PLPMTU。随后，一份同样大小的业务数据报落到另一条 ECMP 成员。那条成员多了一层隧道开销，或者经过 MTU 更小的链路，报文不再到达。

第一次观测仍然真实：特定探测在特定时刻沿其实际路径完成了交付。它没有测量所有并行成员，也没有测量路由或封装变化后的路径。若系统只保存“MTU 已通过”，就会丢掉探测标识、流键、路由代次、开销和确认年龄，而这些恰好决定结论适用范围。

IPv6 PMTUD 维护的是估计值

RFC 8201 将路径 MTU 定义为源和目的之间路径上最小的链路 MTU。源节点可从第一跳链路 MTU 开始，在验证 ICMPv6 Packet Too Big 消息后降低估计值。更小的瓶颈可能位于更远处，因此一次发现过程可能经历多轮报文与 PTB 反馈。

拓扑会变，路径 MTU 也会变。PTB 用于发现下降；若要发现上升，源节点必须周期性尝试更大的报文。发生下降后，RFC 8201 建议尝试上调的频率不要高于每五分钟一次。缓存中的数值因此带有老化和重新验证规则，而不是目的地址的永久属性。

即使 PTB 已验证，它也只说明相关发送报文遇到某个限制，不能单独解释哪条路由发生变化、哪层隧道增加了开销，也不能证明所有并行路径上限相同。

正向确认究竟证明什么

RFC 8899 把数据报的发现逻辑放在分包层。发送端选择探测大小，并需要反馈证明那一份特定探测到达远端分包层。确认后，探测大小可成为当前 PLPMTU，搜索再继续。

这比根据沉默推断成功更可靠，但范围依旧很窄。一次丢包不足以证明 MTU 故障，因为拥塞、误码和乱序也会造成探测缺失。反过来，一次确认也不会让 Search Complete 成为永久证书。缺少其他交付证据的未确认型分包层，需要借助确认计时器复查当前大小是否仍然可用。

RFC 8899 还要求算法能处理路径变化、信息不一致、乱序、延迟、复制，以及流量分散到多条网络路径的情况。如果支持多路径或多归属，就应为每条路径维护一套状态机。这与“每个目的地址一个永久绿色状态”完全不同。

分包大小不等于线上 MTU

应用可用负载和网络层 MTU 不是同一个数字。IP、扩展头、传输层、安全封装和隧道都会消耗空间。物理链路 MTU 没变，新增封装也可能降低应用能安全发送的消息大小。

所以记录必须注明测量层级与头部预算。与大小相关的连续丢失可以触发保守降档，却不能直接完成原因归属；策略过滤、拥塞、接收端状态和普通丢包仍需单独排查。

来源