摘要

  • RFC 4957 将链路层通知定位为发现网络附着的输入，而非完成的 IP 或服务结果。
  • 更换接入点未必意味着更换子网；IP 配置变化也可能在没有新链路事件时发生。

“link up”很容易被听成结论：无线关联已完成，Wi-Fi 终端已连入接入点，或以太网口已能发送帧。在故障看板上，它常被顺手改写成“网络恢复”。RFC 4957 要求把这两种说法分开。

这份信息性 RFC 由 Suresh Krishnan 等人编撰，罗列的是设备改变附着点时，各类接入技术可以交给 IP 层的信息。它们的用途是让 IP 更快地核查配置，不是证明地址已可用、默认网关可达或应用服务已经可用。

RFC 的表述很克制：新的链路层连接可以促使主机寻找更多线索，例如发送路由器请求。单独一条链路层通知并不提供网络附着检测过程所需的全部输入。通告前缀、默认网关的可达性以及其他 IP 证据仍然必要。因此，这个信号启动状态机，却不是状态机的终态。

Wi-Fi 漫游最能说明问题。设备可以从一个接入点转到另一个接入点，同时仍在同一个 IP 子网内。若把每一次关联都当作 IP 重配置，既会制造无谓动作，也会扭曲统计。反方向同样成立：IPv6 重新编号可能需要更新 IP 配置，却不一定产生新的链路上线通知。

RFC 还承认“非确定性”的链路上线：接口已准备好，但网络中仍可能有条件阻断数据传输。即使随后出现确定性通知，它描述的仍是实现所定义的链路层条件。它不能证明 SLAAC 或 DHCP 已完成，不能证明策略放行、DNS 解析、远端服务响应，更不能证明用户看到了结果。

对运营者而言，关键首先是证据设计。link_up 可以是很强的本地观测：接口、附着点、时间以及可能的技术上下文。它不应被改名为 online，不应作为应用恢复的计数，也不应独自关闭事故单。每多加一个标签，都是对该信号未曾观察到的事实作出更宽的断言。

更可靠的是证据阶梯：链路事件、地址和前缀状态、网关探测、解析器结果、已认证的服务响应，最后才是客户可见的确认。每一级都有不同的观察者、故障域和责任价值。分布式系统中的任何一方，都不应无证替另一方声明结果。

RFC 4957 留下的教训并不宏大：链路事件只证明链路事件。它的价值在于触发下一项测试；若被包装成路径、服务或客户体验的回执，就越过了它从未观察过的边界。

来源