摘要

  • RFC 3316 建议蜂窝主机利用 TCP 新确认、RTCP 接收报告和 SIP 响应，证明近期出站流量已经穿过第一跳路由器，从而减少专门的邻居不可达探测。
  • 这项推断有严格边界：远端继续向前推进，可以说明邻居刚才可达，却不能证明应用已经完成、连接会持续，也不能把任意入站流量当成前向路径的健康证明。

在早期蜂窝 IPv6 会话里，昂贵的报文不一定承载业务。有时，它只是重复询问一个主机已经从别处得到答案的问题。

IPv6 的邻居不可达检测（NUD）维护下一跳最近是否可达的判断。信心过期而主机仍在发送流量时，它可以发出单播 Neighbor Solicitation，等待一条带有响应语义的 Neighbor Advertisement。在以太网里，这套过程很自然地和地址解析放在一起。RFC 3316 面对的 GPRS、UMTS 链路却不同：它近似点到点连接，蜂窝主机在这个接口上只有一台默认路由器，链路也没有普通的二层地址。地址解析可以省去，但第一跳失效仍会把包送进死路。

RFC 3316 因而换了一个问法：别的协议是不是已经证明，近期某个出站包确实向前走通了？

通用的 Neighbor Discovery 规则提供了逻辑基础。TCP 收到一条新的确认，意味着先前发送的数据已经到达远端。若远端不在本链路上，那份数据不可能绕过本机的第一跳路由器直接抵达。端到端确认于是同时携带一条本地事实：该数据穿过第一跳时，邻居是可达的。主机可以用这条事实刷新 Neighbor Cache，而不必再发一个专门探测路由器的报文。

RFC 3316 又把同样的推理搬进当时大量使用 UDP 的蜂窝应用。UDP 本身没有交付确认，应用层就必须暴露一条具有正确因果含义的信号。对 RTP 媒体而言，RTCP 接收报告块若说明对端收到过一部分包，就能成为依据。对 SIP 而言，请求获得响应，说明请求向外抵达；当蜂窝主机处于 SIP 服务端一侧时，仅仅发出响应通常还不够，但随后收到 ACK，可以证明先前对 INVITE 的响应到过另一端。

这些信号不是可以互换的“绿灯”。它们都必须能反推出近期发出的流量已经送达。无关的入站数据报不算；未经请求的 Router Advertisement 也不算。后者只能说明报文可以从路由器走到主机，而 NUD 需要确认相反方向——主机发出的流量能否穿过下一跳。区别就在于，是观察到网络有动静，还是证明了正在检验的路径。

由此得到的状态也不是永久证书。上层确认可以让邻居缓存条目在有限时间内进入 REACHABLE。若不再出现新的确认，它会老化成 STALE；继续发送流量后可进入 DELAY，最终到 PROBE，届时专门的 Neighbor Solicitation 会重新出现。RFC 3316 没有废除 NUD，只是在应用流量已经给出有效答案时，避免重复发问。

这一点重要，是因为空口信令并非免费。文件明确指出蜂窝带宽有限，用户还可能按流量付费。删掉无谓报文既可能保护容量，也可能减少用户承担的费用。不过 RFC 3316 没有给出节省报文、功耗或账单的实测数据。它只是依据链路拓扑和活跃会话中已有的证据，给出实现配置。

这种机制后来没有消失。2013 年取代 RFC 3316 的 RFC 7066 把模型更新到包含 EPS，保留 TCP、RTCP 和 SIP 的例子，还把 DNS 响应列为另一种可能的应用层确认。文字延续说明这种推断仍被认为有用，却不能证明哪些设备实现过、又有多少探测因此被省掉。

这段历史不是说应用可以替路由器做决定，而是说明：只有当因果关系写得足够明确，一个状态机才能安全复用另一层的证据。远端反馈能证明第一跳，是因为近期的出站包必经第一跳；结论必须停在这里。RTCP 报告不证明媒体质量良好，SIP 响应不证明通话完成，路由器可达也不证明服务可用，而一个包的证据更不能为下一个包担保。

来源：RFC 3316、RFC 2461、RFC 4861、RFC 7066、RFC 7849、RFC 8504、RFC 3550 与 RFC 3261。