摘要

  • Linkova 在 RIPE 93 回忆，2019 年办公室访客网改为纯 IPv6 后，主管的手机连接要等七秒。排查指向 Neighbor Discovery 状态机的一个缺口。
  • RFC 9131 允许第一跳路由器通过未经请求的 Neighbor Advertisement 学到新分配的 IPv6 地址。Linkova 说 Android 和几家厂商实现了方案；RIPE 逐字稿没有列出设备与路由器的测试矩阵。

七秒暴露的不是耐心问题，而是协议状态问题

手机连 Wi‑Fi 要等七秒，用户不会先问邻居缓存里发生了什么。Jen Linkova 在 2026 年 RIPE 93 的演讲中回忆，2019 年她把办公室访客网络迁到了纯 IPv6。主管抱怨手机接入太慢：七秒。其他人也遇到了不满。

Linkova 和同事排查后，将原因归到 Neighbor Discovery 状态机。IPv6 设备靠它发现链路上的下一跳，并维护本地可达状态。手机刚拿到新的全局 IPv6 地址后，可以通过默认路由器访问外部目的地；但第一跳路由器未必已经为手机的新地址建立 Neighbor Cache 项。

RFC 9131 把这段空窗写得很清楚：路由器可能等到返回流量抵达时，才开始为这台主机解析地址。解析期间，它只保留很少的排队数据包，之后到达的包可能被丢弃。设备明明已连上网络，第一次真正使用连接时却可能先卡住、再丢包。

Linkova 把故障带进 IETF。她在 RIPE 93 说，自己提出问题后，草案被工作组接纳；Android 和几家厂商实现了提案，约两年后文件成为 RFC。她还说 Android 的实现更早落地，主管不再遇到七秒延迟。

RFC 9131 允许主机在获得新的全局 IPv6 地址时，主动向第一跳路由器发送 Neighbor Advertisement。路由器可以在返回流量触发地址发现前，先创建 Neighbor Cache 项。文件还分别规定了缓存项已存在、处于 incomplete 状态或完全缺失时的处理。它于 2021 年 10 月成为 IETF Standards Track 文档，并更新 RFC 4861。

这段经历的价值，在于它把办公室里的一张故障单变成了多方可以实现的机制。Linkova 本可以只找一家厂商修她的网络。她说自己转向 IETF，是因为邻居发现状态变化影响多个系统；单个网络有效的改动，可能在别的场景里制造问题。跨领域审查让这个修复有了共同文本和可复核的边界。

RFC 不会告诉我们今天有多少手机和路由器已经支持这项变化。RIPE 逐字稿提到 Android 和“几家厂商”，没有产品版本、数据包轨迹或测试数量。若要判断七秒问题解决到了什么范围，需要一张公开的版本矩阵：客户端与路由器如何处理 Neighbor Advertisement，首次连接时延又是多少。

这就是投诉进入互联网标准后的变化：投诉指出故障，数据包揭示机制，真实实现决定修复有没有离开会议室。

来源