摘要

  • L2-LinkUp.indication 只在链路技术所定义的边界上报告 Link Up；在 RFC 5184 的 Wi-Fi 示例中，这一边界是与接入点完成关联，而不是地址、路由或业务已经可用。
  • 一份可信的切换收据必须分开记录触发信号、LinkConnect 的 Ack、实际链路事件、L3 状态和双向业务结果。

监控面板收到 LinkUp，立刻把终端标成“业务已恢复”。地址仍在验证，缺省路由还未建立，新接入路由器也没有确认终端存在。绿色徽章是真的收到了事件，却对事件说了规范从未说过的话。

RFC 5184 的价值恰在于阻止这种语义升级。它规定的是跨层原语，不是一个从无线信号直达用户体验的万能完成位。

四类原语保留时间顺序

RFC 5184 是 MobOpts 研究组形成共识的实验性文档，并非 IETF 互联网标准。它定义 Request、Confirm、Indication 与 Response 四类原语，使 L3 能以相对独立于具体链路技术的方式与 L2 协作。

类型 1 通过 Request/Confirm 获取当前信息，例如 LinkStatus 与候选 PoA 列表。类型 2 先用 Request/Confirm 注册，事件发生后再异步发出 Indication，包括 PoAFound、PoALost、LinkUp、LinkDown 和 LinkStatusChanged。类型 3 则让上层请求连接或断开动作。

类型 3 的 Ack 或 Nack 会立即随 Confirm 返回。L2-LinkConnect 在 Ack 之后才开始操作；L2-LinkDisconnect 也是如此。Ack 证明请求越过了一个接口，不证明状态已经抵达目标。

LinkUp 仍然只属于链路层

规范明确说，“链路已连接”的含义取决于链路类型。其 IEEE 802.11 基础设施模式示例在与 AP 关联建立后发出 LinkUp。这个事件有用，但它不自动证明认证的所有环节、IP 地址、路由、绑定更新或用户流量。

RFC 4907 进一步指出，LinkUp 不必导致网络层配置变化，也不应被假定为双向低丢包。应用更应等待“IP 地址已配置”之类的网络层事件。RFC 4957 对以太网的分析也说明：物理状态正常并不保证桥域已经转发；主机未必能收到生成树完成的明确通知。

因此，同一个 LinkUp 字符串必须附带技术、驱动版本和发出边界。将 Wi-Fi 关联、以太网载波与蜂窝注册直接映射成同一业务状态，会丢掉差异最大的那部分事实。

从 Ack 到可用性至少还隔着三道门

RFC 5184 的示例顺序很清楚：L3 发出 LinkConnect，请求得到 Confirm 后 L2 才开始切换；L2 切换完成时发出 LinkUp；然后 L3 执行自己的切换动作。

在真实系统中，还需验证链路认证与关联、地址和路由状态，以及首个成功的双向业务交换。RFC 5568 也把链路切换延迟与 Mobile IPv6 的 IP 协议操作分开。提前建立隧道并不保证终端一附着就能收到包，新接入路由器仍需探测终端。

面板可以显示这些阶段，而不必等待最后一步才提供信息。诚实的进度比过早的绿色更适合自动化，因为它告诉恢复逻辑应在哪一层工作。

抽象质量不是通用测量单位

Condition 把可用带宽和链路质量抽象为 EXCELLENT、GOOD、FAIR、BAD、NONE。算法取决于硬件与软件，不同设备的等级彼此独立。规范直言，依据这些指标决策容易出错，不能保证选到最优链路。

原始 RSSI、重传、采样窗口、平均方式、阈值和滞回策略因此必须进入操作收据。否则升级驱动后，同一个 GOOD 可能表示完全不同的物理条件，而历史报表仍把它们当作同一数据。

PoA 列表也只是候选观察。出现一个接入点不等于它获准接入、上游可达或具有可用容量。

规范没有假装提示永远正确

实验中出现过 AP 之间的乒乓切换。阈值会随部署场景改变，配置不当会产生误导性 Indication。RFC 5184 说 LinkStatusChanged 有时并不可信，因为链路质量难以抽象；错误事件可能触发冗余切换。

恢复不是异常补丁，而是设计组成。上层可在收到变化事件后重新读取 LinkStatus，若当前 AP 仍最合适就取消切换。RFC 4907 建议把链路事件视为需要验证的提示，而不是必须执行某一动作的命令。

这让快速与审慎并不冲突。系统可以用早期提示并行准备，但只有在本地提交条件满足时才释放旧路径。

合法事件也可能源自攻击者的观察面

伪造的 beacon 可以使恶意 AP 触发 PoAFound，随后终端可能向它发出 LinkConnect。攻击者交替制造强弱 RSSI，还能让 PoAFound 与 PoALost 反复出现，形成拒绝服务。

语法标准化并未认证无线环境。候选来源、链路认证、驱动状态、策略许可、速率限制、阻尼和后续可达性共同决定事件能获得多大权限。

一次实验不能替整支设备队列签 SLA

RFC 5184 的附录在一个实现中以十毫秒间隔发送 ICMP 请求，观察到切换期间丢失零或一个响应。这是有坐标的实验事实，不是对所有无线芯片、认证方式、负载和移动协议的普遍保证。

运营指标应拆成触发到决策、决策到 Ack、Ack 到 LinkUp、LinkUp 到 IP 就绪、IP 就绪到首个双向业务成功。哪一段变慢、丢失或超时，决定应由哪个团队与哪个组件处理。

最终收据保存操作 ID、接口、PoA、构建版本、原始信号、阈值、事件序列、决策、请求、Confirm、认证、LinkUp、地址、路由、数据包与回滚。缺失步骤不得被一个总状态补写。

按照 Heng Lu 的现实分层，标准化符号只属于它所在的层；运行中的驱动、IP 栈和真实流量拥有更高的事实优先级。LinkUp 可以真实而有用，同时仍不足以证明“业务已恢复”。

来源

  1. RFC 5184 HTML
  2. RFC 5184 纯文本
  3. RFC Editor 信息页
  4. IETF Datatracker 文档页
  5. IETF Datatracker 历史
  6. IETF Datatracker 引用
  7. RFC 5184 勘误
  8. RFC 4907 链路提示的架构影响
  9. RFC 4907 信息页
  10. RFC 4957 链路层事件通知
  11. RFC 5568 Mobile IPv6 快速切换
  12. RFC 5568 信息页
  13. RFC 5944 IPv4 移动性支持
  14. RFC 6275 IPv6 移动性支持
  15. RFC 4140 分层 Mobile IPv6
  16. RFC 3819 子网设计建议
  17. RFC 4968 IPv6 链路模型分析
  18. Heng Lu：现实分层
  19. Heng Lu：最小初始规范与自愿采用
  20. Heng Lu：运行代码优先