摘要

  • 发送端在 REQ 中放入四字节令牌，并用 EOL 填充至目标包长；收到匹配 RES，便能确认这一枚探针抵达远端 UDP Options 接收器。
  • 结论受 5-tuple、具体路径与时间约束。ECMP、多路径和多宿主环境必须分别维护状态，现有 PLPMTU 还要定期复验。
  • 没有及时回包并非只有“正向路径太小”一种解释；等待搭载反向流量、限速或回程丢包，都可能让可用路径显得偏小。

令牌把结论钉在一次试验上

RFC 9869 把 RFC 8899 的 DPLPMTUD 方法落到 UDP Options。发送端把令牌写入 REQ，以 EOL 和填充构造选定尺寸的探针，再等待接收端用 RES 回显最后收到的令牌。探针可以高于当前 PLPMTU 估计，却不能超过接口 MTU；IP 层不得将它分片，IPv4 场景按要求设置 DF。

匹配成功的含义很精确：远端 UDP Options 接收器收到了这一包。它没有证明应用数据已交付、解析或接受，也没有测出反向路径能承载多大的包。下一包即使沿用相同地址与端口，也可能被路由到另一条链路。

因此，用于提高 PLPMTU 的探针不应携带应用数据。测试过大候选而丢包本来就是发现过程的一部分。零负载探针不会交给上层；携带应用数据的包可以确认或复验已用尺寸，却不宜承担向上探索。

复用令牌会混淆历史

同一 5-tuple 内，令牌在 Maximum Segment Lifetime 期间必须唯一，窗口内不得重用。随机初值和不可预测的后续令牌能降低路径外伪造的机会。但若记录只留下最终的 PLPMTU，就丢掉了推导依据：令牌、目标尺寸、两端地址端口、路径选择、收发时间、重试与实现版本。

双方应用还必须明确启用该服务，接收端在启用前不得回复 RES。如果传输服务层和上层协议同时运行 DPLPMTUD，它们要协调令牌或使用不同空间，否则真实回包也可能被错误状态机认领。

该机制主要面向单播，不支持组播。接收端可以生成零负载回包来推进探测，但这种主动响应必须限速；协议证据从一开始就带着资源约束。

一条路径不能替另一条签字

在 ECMP、多路径或多宿主环境中，RFC 9869 要求每条路径独立维护 DPLPMTUD 状态。瓶颈属于实际经过的路由，而不是远端名称的永久属性。把一条路径的成功值复制给其他路径，相当于用已测证据替未测对象作答。

时间也会改变权限。路由切换、隧道加入或临时限制消失，都会让旧值失效。周期验证不是附属清理，而是阻止历史成功永久掌权的控制环。RFC 1191、8085 与 8201 同样把 PMTU 视为会随路径变化的状态。

沉默不只代表正向丢包

接收端可以等到本来就要发送的反向数据报，再搭载 RES。若等待期间来了多个探针，它可能只确认最新令牌；更早的探针明明抵达，却在发送端看来失败。反向流量稀少时，发现过程可能停在低于实际容量的值，甚至最低 PLPMTU。

专门生成回包能缩短等待，却受限速约束。所以超时可能来自正向丢包、接收策略、排队、限速或反向丢包。状态机可以保守退让，分析人员却不能把退让结果写成唯一原因。

ICMP Packet Too Big 处理是可选项。若采用，必须验证被引用包的协议背景，并应尽可能核对 REQ 令牌；无法验证就必须忽略。不可预测令牌主要抵御路径外注入，无法阻止路径上的参与者丢弃或篡改流量。

来源