摘要

  • draft-ietf-bfd-rfc5883-bis 第 02 版把多跳 BFD Echo 的全面禁令改成条件规则：若封装或转发可能让中间节点提前回送报文，仍然禁止；只有环境能够保证不会发生这种回送时，才允许使用。
  • 这仍是工作组 Internet-Draft，不是已经批准的 RFC 5883 替代标准。新加入的 HPE 实现表是未经 IETF 核验的贡献者自报，不能证明新规则已经部署或实现互通。

收到回应，不等于走完了路。

在多跳路径上，Echo 报文可能被中间路由器提前送回发送端。会话看起来仍然存活，但真正需要检查的后半段路径可能根本没有被触达。这正是 RFC 5883 在 2010 年全面禁止多跳使用 BFD Echo 的理由。

拟替代该 RFC 的草案第 01 版保留了这一绝对规则。8 月 19 日可用的第 02 版则把判断标准从“是否多跳”推进到“中间节点能否提前回送”。

新文本保留了禁止条款：如果报文封装或转发方式可能导致中间节点把 Echo 报文送回发端，就 MUST NOT 使用。与此同时，它增加了有限许可：只有环境能够确保中间节点不会回送时，才 MAY 使用。草案以源路由封装为例，说明报文可以被约束沿指定路径前进；这只是示例，并不是适用于所有网络的安全配方。

因此，这次变化不能简化为“IETF 允许多跳 Echo”。它把许可绑定到一项必须持续成立的运行属性：回应之前，报文确实经过完整预期路径。只要这一点无法证明，Echo 回应仍可能是一条误导性的存活信号。

对第 01 和 02 版官方 XML 做结构化比较，Echo 段落是正文中唯一的规范性变化。第 02 版还加入了一份 HPE 实现状态说明，与此前已有的 ZTE 条目并列。它们能够帮助工作组理解已有实现，却不能替代独立测试。

HPE 把一套专有的 Junos OS BFD Implementation 标为 Mature，并自报已实现任意路径、封装和认证。带外鉴别符信令以及单向链路只被标为部分实现，而且仅适用于 MPLS LSP；表格没有提供实现经验。

草案自己的前言给出了使用边界：IETF 没有核验贡献者提供的信息；列入表格不代表背书；该章节也不是产品目录。因此，Mature 是贡献者的描述，不是 IETF 认证、市场采用率，也不是跨厂商互操作证明。

此前的 ZTE 条目进一步说明了为什么必须区分规范和自报。它描述一种 unaffiliated BFD Echo 实现，把 Echo 报文放入 Segment Routing Header，并称这样可以跨越多个节点。当时同一草案的规范段落仍然无条件禁止多跳 Echo。第 02 版现在改成环境条件，但现有材料没有说 ZTE 报告直接促成了这次修改。

同一天，通用 BFD 应用草案也更新到第 02 版。它的实质变化是新增另一份 HPE/Junos 实现表：多数条目自报已实现，OSPF Virtual Links 则明确未实现，也没有提供实现经验。两张表可以供审阅者对照通用 BFD 与多跳能力，却不能证明不同产品之间已经互通。

多跳草案和通用应用草案目前都是 BFD 工作组的活跃 Internet-Draft，IESG 状态为 I-D Exists。标题页所写的是“若获批准”才分别取代 RFC 5883 和 RFC 5882。当前已发布标准没有因此自动失效。

其他运行约束也没有改变。BFD 属于网络运行、管理与维护机制，不是跨互联网的普通应用健康检查。报文发送速率必须合理配置，否则拥塞本身可能制造错误故障判断。多跳还扩大了伪造攻击面，因此草案继续强调强加密认证。

这组官方材料没有证明新条件已经在产品中启用、在独立实现之间测试，或在生产路径上改善可用性和收敛。它也没有定义一种通用安全封装。下一份真正有价值的证据，应是一条端到端报文轨迹：回应从远端产生，而且在改路、故障和策略变化之后，中间节点仍无法冒充完整路径。

来源