摘要

  • draft-nir-ipsecme-big-payload 第 08 版于 2026 年 9 月 10 日发布；与第 07 版相比，变化仅涉及日期、到期时间、一处词语订正和 Classic McEliece 参考文献更新，并非重新设计。
  • 草案把一个保留位定义为 L：在 IKE_SA_INIT 中收到 LARGE_PAYLOAD_SUPPORTED 后，单个通用载荷头的长度字段可由 16 位改为 32 位。
  • 这项通知没有携带最大载荷、交换类型、内存、计算量或并发额度。草案反而明确允许实现为 DELETE 等载荷设置合理上限。
  • Datatracker 当前仍把它列为 IPSECME 的活跃候选 Internet-Draft，状态为“Call For Adoption By WG Issued”，没有 shepherd 和 IESG 批准；IANA 现行注册表也没有所申请的通知值。

报文会读，不等于资源已批

接收端面对 Large 位时，需要先做一个格式判断：后面的载荷长度究竟按两个八位组还是四个八位组解释。LARGE_PAYLOAD_SUPPORTED 足以把这项能力告诉对端。它回答的是“解析器认识这种格式吗”。

但资源治理的问题带有单位。一次最多接收多少字节？哪些交换和载荷类型可以放大？重组可占多少内存？密码运算与验证可以持续多久？同时允许多少个大对象处于处理中？系统压力升高时是否收紧？当前通知对这些问题一概没有字段。

因此，不能把一个布尔值推导成“凡是 32 位长度能表示的对象都必须接收”。那会凭空替接收方写入一份资源承诺。

草案要解决的编码矛盾是真实的。RFC 7296 的完整 IKE 消息头用四个八位组表示总长度，而每个通用载荷头只用两个八位组表示自身长度。整条消息的格式容得下更大的数，单个载荷却不能达到 65,536 个八位组。提案把此前保留的一个位命名为 L；置位后，载荷长度改用四个八位组。它扩大的是可表达空间，不是设备的物理容量。

能力还具有方向性

草案要求对端在 IKE_SA_INIT 期间发送一个不带数据的状态通知。不过，大载荷本身不能放进这次初始交换。如果初始密钥交换材料过大，文本建议采用 RFC 9242 的 IKE Intermediate Exchange。

两端能力不必对称。发送通知的一方表示自己能处理扩展格式；如果它没有收到对方相同的通知，就不能反向发送大格式载荷。这是一份逐方向的解析能力记录，并不是双方共同预留了一块同等大小的内存池。

接收规则也区分格式错误与其他限制。实现先比较载荷声明长度和 IKE 消息中实际剩余的字节。如果声明超过剩余内容，就按草案返回 INVALID_SYNTAX。如果字节足够，则应像处理其他载荷一样继续，不能仅仅因为该长度原本可以塞进短格式就拒绝它。

这些规则保证线上语义一致。它们没有要求实现对每个格式正确的对象都无限分配资源。格式验证之后仍然需要一扇本地接纳门。

DELETE 的 262,150 字节只证明“装得下”

草案用 DELETE 载荷说明为何需要更长的字段。此类载荷可以列出 IPsec SPI，每个 SPI 占四个八位组。计数字段可以表示 65,535 个 SPI，但短载荷长度无法把它们一次装下。按提案格式，这份完整列表会达到 262,150 个八位组。

这个例子证明旧编码存在边界，却没有证明所有接收方都必须为最大列表留出空间。草案明确说，实现可以对 DELETE 中 SPI 的数量设置合理限制。相同原则也适用于其他大载荷：认识头部和同意承担处理成本是两件事。

如果运营者不把上限显式记录，发送方只能靠超时、笼统错误或性能恶化去猜。一次有意的防护可能被误报为“不支持 Large”，而真正的解析缺陷也可能伪装成容量不足。能力位本来用于消除一种歧义，错误解读却会制造另一种更难排查的歧义。

分片和 TCP 解决不了预算问题

RFC 7383 的 IKE 分片让加密消息在单个 IP 包过大的路径上仍可传递。RFC 9329 在 UDP 受阻或表现不佳时允许 IKEv2 和 IPsec 走 TCP。两者改变的是承载方式，不会替接收方宣布应用层状态预算。

分片仍需接收、重组、验证和处理。TCP 可以可靠地送达更多字节，也可能把工作持续推给资源紧张的节点。Large 位、分片与 TCP 分别对应长度表达、网络传送和路径适配；到底接纳多少，依旧是第四个独立判断，不能从前三者自动推出。

第 08 版的变化很小，流程状态却要完整叙述

官方 diff 显示，第 08 版更新日期和到期信息，把一个 than 改成 that，并刷新 Classic McEliece 引用。它没有增加数值上限、拒绝码或资源协商。9 月 10 日这次发布是维护性修订，不应描述成新的制度安排。

流程记录出现了需要并列报告的表述。Datatracker 把文档关联到 IPSECME，当前工作组状态是“Call For Adoption By WG Issued”。历史页显示，7 月 22 日完成工作组和 IETF stream 设置并发起采纳征询；邮件把意见截止日定在 8 月 15 日。第 08 版的自动 I-D 公告又称它“is a work item” of IPSECME。

与此同时，当前文档页仍标为 Candidate，没有 shepherd，IESG 状态只是“I-D Exists”，没有负责的 Area Director 和 telechat。文件名 draft-nir 可以作为个人草案沿革的旁证，却不是采纳决定。负责任的报道应保留这些记录之间的张力，而不是替工作组宣布结论。

草案正文说拟走 Standards Track，并称若获批准将更新 RFC 7296；Datatracker 的 intended status 当前却显示“(None)”。这只是一处元数据差异。IANA 的 IKEv2 Notify Message Status Types 注册表目前也没有 LARGE_PAYLOAD_SUPPORTED：申请编号不等于编号已经分配。在所审阅的资料里，还没有 IETF 共识、IESG 批准、RFC 发布、实现、互操作测试、部署或事故证据。

来源