Summary

  • draft-acee-lsr-ospfv3-deprecate-ah-00 建议新的 OSPFv3 实现不再实现 IPsec AH，并建议运营者迁往 ESP 空加密或 OSPFv3 Authentication Trailer；第 00 版仍是个人 Internet-Draft，不是已经批准的标准。
  • “建议停用”不是“已经迁移”。一个 OSPFv3 接口上的所有路由器必须认同同一种认证机制；必须先让每台设备都能接收新机制，再改变发送方式，最后在邻接、链路状态数据库和转发均有回执后关闭旧路径。

维护窗口开始后，A 先发出了采用新机制的 Hello。B 已有新密钥，却没有正确的入站 SA；C 的软件版本支持新机制，但接口上尚未启用；D 仍只接受 AH。“deprecated”这个标签不能协调这四种状态，第一个报文却会立刻揭示差异。

这正是 2026 年 9 月 30 日发布的 Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication 第 00 版最重要的运行含义。它是拟走 Standards Track 的个人草案，并注明若获批准将更新 RFC 4552；它不是 RFC，也不能证明工作组、厂商或运营者已经采取行动。

提案的范围很窄。RFC 4552 要求 OSPFv3 支持 ESP，并允许使用 AH。新草案建议新实现不再为 OSPFv3 认证实现 AH；现有实现可为兼容继续支持，但应提示配置已被建议停用；运营者则应改用 ESP 空加密或 RFC 7166 的 OSPFv3 Authentication Trailer。

两种替代方案都可提供完整性保护，并证明发送方持有相应密钥材料。ESP 空加密在这里不提供保密性。若一台已经持有共享密钥的路由器被攻陷，两种方案都不能把它变回不受信任的外部节点。

标准状态不是链路状态

草案认为，AH 在 OSPFv3 中采用有限，RFC 8221 已把 AH 列为可选实现，许多 IPsec 实现也不再支持；同时保留 AH 与 ESP 两套代码、配置和运维流程，会增加复杂度。普通 OSPFv3 报文使用链路本地地址，Hop Limit 为 1，因此 AH 对不可变 IPv6 头字段的额外覆盖价值受到限制；Authentication Trailer 则把 IPv6 源地址纳入摘要。

这些属于草案作者的理由，不是产品市场普查。更关键的是，它们都不是线上协商。文档可以改变采购优先级，却不会自动安装密钥、建立 SA、扩大入站接受范围或替邻居选择发送机制。

第 00 版明确指出：OSPFv3 接口或虚链路配置一种认证机制，链路上的所有路由器都必须一致。因此变更的安全单位是整条链路，而不是单台设备的工单。

单方面切换不是渐进采用，而是把一条新的报文验证规则强加给尚未准备好的邻居。Authentication Trailer 的 SA ID、认证类型或摘要不一致，会阻止邻接建立；IPsec 策略或 SA 集不匹配，也会在 OSPFv3 能把报文视为正常交换之前将其丢弃。

先准备接收，再改变发送

RFC 4552 的换钥流程给出了很好的顺序。第一步，在每台路由器上增加新的入站 SA；第二步，等所有设备都能接收新状态后，再替换出站 SA；第三步，确认所有设备均用新 SA 发送后，才删除旧入站 SA。

从 AH 迁往 ESP 并不等同于同一机制内换钥，但“先接收新、再发送新、最后退役旧”的纪律仍然成立，而且每一步都需要全链路证据。

新草案给出两种部署形态：在维护窗口内为所有路由器预配置替代机制与密钥；或者仅在实现确实支持过渡期同时接收多种机制时分阶段切换。不能因为同属一个产品系列，就推定第二种能力存在。

重叠窗口有代价。过短会把邻接图切开；过长则让旧接受路径或较宽松的路径超过必要期限继续存在。窗口必须有责任人、起止时间、完整的链路成员清单，以及任何设备缺少回执时停止切换的条件。

RFC 4552 对 OSPFv3 的 IPsec 用法仍只规定手工密钥。其流程要求全部设备先完成新入站 SA，再开始新出站 SA；全部设备完成发送切换后，才删除旧入站 SA。具体间隔由运营者决定，因为网络规模与实现行为各不相同。

两种替代方案不是同一个后备开关

ESP 空加密仍位于 IPsec 架构内，沿用 RFC 4552 的 SA 与手工密钥模型。Authentication Trailer 则随 OSPFv3 报文携带，使用自己的 SA 标识和严格递增的 64 位加密序列号，并在摘要中保护 IPv6 源地址。

RFC 7166 还定义了可选兼容模式：路由器发送带 Authentication Trailer 的报文，同时继续接收不带它的报文。这能让旧邻居保持连接，但 RFC 也明确提醒，过渡期间可能暴露于未经认证的数据。

这不是反对过渡，而是要求把交换条件写清楚：连续性是通过暂时扩大接受范围换来的。只显示“邻接 Full”的监控面板，无法说明报文究竟通过了新机制、旧机制，还是兼容模式下的未认证路径。

同样，摘要验证成功只能说明发送方能够使用共享密钥；它不能确认具体操作者身份，不能证明设备未被攻陷，也不能为它发布的每条 LSA 自动授权。

邻接恢复只是检查点

完整迁移应留下分层回执：准确的草案版本与替代方案；每台链路设备实际运行的支持版本；全部入站 SA 或 Trailer 状态、算法和密钥纪元；仅在接收集合齐备后改变出站；按目标机制通过认证的 Hello 与 Database Description；所有必要邻居稳定达到 Full；链路状态数据库收敛；FIB 与限定流量测试通过；最后关闭 AH 或宽松过渡接受，再重复验证。

任何一层都不能代替下一层。Full 邻接可能仍经旧路径维持；LSDB 收敛不证明 FIB；在旧接受路径尚未关闭时业务成功，也不能证明新机制真正承载了它。

最后的关闭不是清理工作，而是迁移本身。只要旧路径没有按计划退出，或者没有带责任人与期限地明确保留，网络就还没有进入宣称的兼容集合。

Heng Lu 关于“最小初始规范、未来决策本地化、自愿采用与运行代码优先”的框架在这里很实用。共同层只规定互通所需的报文、算法、密钥与序列行为；运营者自行选择替代机制、维护范围和过渡窗口。但采用是否完成，必须由真实报文、邻接、数据库与转发结果证明。

真正的领导问题不是“AH 是否已被标记为停用”，而是“链路上的每台路由器是否能对同一个新报文、同一个密钥纪元给出同样的接受结果，以及旧路径是否真的关闭”。

Sources