摘要

  • RFC 9868 利用 UDP Length 与 IP 载荷长度之间的边界，在已声明的 UDP 用户数据之后创建选项区；它是扩展信封，而不是应用内容。
  • 选项校验失败时，默认处理是丢弃选项区而交付校验正确的用户数据。若要更严格地拒绝数据，应用或其库必须明确作出该政策决定。

UDP 的价值一部分来自它的少言。它的头部给出端口、差错检测校验和长度，却不建立会话、不协商语义，也不证明远端是谁。对于已大规模部署、又需要靠近传输层的附加能力的应用，这种极简既是优势也是约束。2025 年 10 月发布的 RFC 9868 从 UDP 原有的一个事实出发：UDP Length 可以在 IP 载荷结束之前就声明用户数据结束。

RFC 把后面的空隙称为 surplus area（剩余区）。它位于 UDP 用户数据之后、IP 数据报结束之前，用作传输选项的尾部空间。位置本身是一条边界：这些字节不被塞入应用消息，也不能因为出现了就被解释为应用接受了新的语义。UDP Length 仍然标出用户数据的终点；剩余字节按自己的解析和完整性规则处理。

这不是把 UDP 改造成另一种传输协议。RFC 把它称为 UDP 的柔性控制面，同时明确 UDP 仍然无状态、单向，选项只是框架而不是完整协议。一项选项可以定义能力，但不会凭空产生双向协商、持久对等关系或普遍的成功条件。具体协议和采用它的端点仍须分别定义这些内容。

兼容性决定了这套机制如何落地。SAFE 选项设计为：不理解它的接收端可以忽略它，而不会改变 UDP 用户数据或其所代表的意义；能识别选项的接收端会静默忽略未知或畸形的 SAFE 选项。UNSAFE 选项可能改变数据意义，因此有更严格的传输限制：存在此类选项时，普通 UDP 用户数据必须为空，传输载荷要放进 RFC 定义的 FRAG 选项中。

选项校验和让分界可被验证。它单独保护剩余区，区别于覆盖已声明数据的 UDP 校验和。若接收端无法验证选项校验和，必须忽略全部选项并静默丢弃剩余区；如果 UDP 用户数据的校验和正确，仍须像没有选项时一样交付数据。这里得到的是“扩展信封失败”的证据，而不是对应用消息的自动裁决。

默认行为特意偏向旧系统兼容。除分片情形外，即使选项校验、认证或解密失败，接收包通常仍会交给用户。应用若希望这些失败阻断或改变交付，必须明确覆盖默认规则。传输解析器能够说明某个选项无效，却不能自行判断 DNS 解析器、遥测接收器或工业控制器是否应拒绝其他方面仍有效的用户数据。

因此，事件记录不能只写“UDP 包到达”。它应保留 IP 载荷长度与 UDP Length、选项种类和顺序、解析结果、存在时的 OCS/APC/AUTH/UENC 结果、接收端政策以及应用结果。一个正确校验和不能证明发送者身份或授权；出现认证选项也不能证明某次部署启用了它，或应用接受了这次交易。

对 Touch 的归因同样要有边界。IETF 公开资料支持其长期的 RFC 与评审工作；RFC 9868 只支持共同作者这一具体贡献。它们都不赋予他对每个 UDP 实现、中间盒或应用政策的控制权。该设计的力量正来自不假装拥有那些权力：它使信封可见，保留数据边界，并把后果留给真正了解业务含义的端点应用。

来源