摘要

  • RFC 9747 观察的是经过相邻 IP 转发设备的单跳闭环。目的 IP、状态和区分符都来自本地，对端没有签发 BFD 健康声明。
  • 精确的 TTL/Hop Limit 验收、回送条件和本地检测预算决定测试是否成立，不能替代远端 IP、应用或下游业务的证据。
  • 检测器可以触发事先批准的接口动作，却不能自行取得业务切换权限；回包恢复也不是自动回切的充分条件。

测试对象藏在目的地址里

如果运营报告写着“B 已恢复”，读者自然会以为 B 作出了某种回应。RFC 9747 的包确实经过 B，但它的目的 IP 地址属于发送方 A。B 所做的是普通 IP 转发，把这个包送回 A。收到的并非对端应用的回答，甚至不是对端某个 IP 地址可用的证明。

RFC 9747 第一节 明确限定：这种机制监测通往设备的特定接口连接性，不验证该设备上某个特定 IP 地址的可用性。它是 2025 年 3 月发布、更新 RFC 5880 的 IETF 标准轨道文件，适用于 IPv4 或 IPv6 的单 IP 跳。标准发布说明一种行为已有规范，不说明多少网络已部署，更不说明停机时间已经下降。

这项改动的实际价值，是降低对端承担协议的门槛。A 支持 BFD，B 只需具备回送所需的 IP 转发能力。无法或不宜建立双端 BFD 控制会话的场景因此获得一个局部检测工具。把它称为整个服务的健康认证，反而掩盖了这种简化的代价。

状态是自己的，时钟也是自己的

非关联 Echo 使用 BFD Control 包格式，发送到 Echo 的 UDP 目的端口 3785。B 不拦截包来建立 BFD 会话，不解析其中字段，也不维护对端 BFD 状态。A 按规定应用相应的异步处理、验证和认证程序，但两端之间没有协议状态协调。

于是，A 的状态机读到的是自己生成、经 B 回送的状态。Down、Init、Up 可以描述本地测试的推进，不能被读成 B 对维护意图的独立确认；AdminDown 在这里不使用。本地区分符的走向同样清楚：My Discriminator 由 A 配置，Your Discriminator 起初为零，再填入回送的 My Discriminator。启动时按源 IP 或 UDP 源端口解复用，此后只按 Your Discriminator。它们负责选择本地会话，不负责证明对端身份。第二节 给出了这些程序。

包里看似可以“协商”的间隔字段，也不承担协商。Desired Min TX Interval 和 Required Min RX Interval 必须填确定值，推荐 1,000,000 微秒；Required Min Echo RX Interval 推荐零。这样做首先防止未初始化内存泄露。接收方必须忽略三个字段，前两个不得参与 Detection Time 计算。

Up 状态的发包间隔和 Detect Mult 实际由 A 配置。启动及 Down 后恢复使用慢速发送，按 RFC 描述不快于每秒一包，进入 Up 后才使用配置速率。Up 时连续缺失达到规定数量的预期 Echo，A 必须转为 Down，LocalDiag 置为 2，即 Echo Function Failed。“间隔乘漏包数”可以帮助解释名义预算，却不是实测收敛承诺。发送抖动、本地接收调度、客户端响应、转发表更新和用户成功恢复，各有自己的时钟。

单跳门槛不能换成身份结论

每个包发送时 TTL 或 IPv6 Hop Limit 必须为 255，收到时必须恰好为 254，否则必须丢弃。即使使用认证，也不能免除 RFC 9747 的这个条件。254 验证的是规定的跳数条件，不是一张 B 的身份证；它依赖正常的转发递减以及具体网络条件。存在隧道或特殊转发行为时，需要另行验证，而不是放宽规则来保住绿灯。

这也不是多跳探针。第一跳便会把目的地址属于 A 的包送回，后面的预期路径没有被走过。用这个闭环声称下游可达，缺失的不是更漂亮的图表，而是根本没有发生的测量。

“无需 BFD”并不等于“无需准备”

B 必须实际执行 IP 转发；主机可能没有默认开启它，如何在 B 上配置回送也不由 RFC 9747 规定。A 则要确保发往自身地址的包确实离开本地，走向指定接口与 B，而不是被本机投递吸收。多访问链路还要选择正确的数据链路目的地址。检查指定接口上的真实发包，比仅凭一个写着邻居名称的配置项更有说服力。

继承的 RFC 5881 封装规则 还要避免 IP Redirect：发送接口子网内地址或 IPv6 link-local 源地址，除非已知不会触发重定向，否则不适合这样使用。RFC 9747 的安全章节指出，单播严格反向路径检查可能阻断回送。RFC 3704 解释了这一检查的工作方式。合理处置是让有限的 Echo 路径与入口反欺骗措施兼容，而不是在整个网络关闭防护。

远端不说 BFD，也就不会通过这个机制给出维护状态。B 的管理员改变过滤、转发或接口配置，A 看到的可能只是回包消失。单边测试把协议依赖拿掉了，却把约定测试条件、识别条件变化的责任交给了运营者。

两种容易被错读的结果

第一种是闭环仍为 Up，B 的管理 IP 或下游应用却失败。Echo 可能完全符合规范，错误的是“服务健康”这一更大的推断。第二种是过滤规则变化、测试绑定失配或 A 的接收调度压力令 Echo Down，而业务交易仍成功。相对于业务声明，这是误报故障；相对于受约束的测试，未必是状态机判错。讨论假阳性、假阴性前，必须先说清服务对象和观察窗口。

认证也不改变这个逻辑。RFC 9747 推荐加入 RFC 5880 的 Authentication Section，因为 Echo 可以被伪造。但是，认证内容由 A 产生，B 没有成为独立认证的发言者。验证本地包的回返，可以按所选认证方案保护测试，不能凭空证明 B 的身份、意图或业务健康。跳数、认证、应用检查回答的是不同问题。

可成立的结论因而很具体：在本地预算内，经过邻接转发设备的闭环通过了本地验收条件。这个证据值得使用，也值得保持原样。把它压缩成一盏代表所有服务的绿灯，才是风险开始扩散的地方。

来源

规范、继承规则与当前状态: RFC Editor, RFC 9747, IETF Datatracker, RFC 5880, RFC 5881, RFC 5882, RFC 5082, RFC 3704, RFC 9747 — errata.

署名分析框架: Lu Heng — Note 65, Lu Heng — Note 64, Lu Heng — Note 36.