摘要

  • RFC 3316 将 GPRS 和 UMTS 描述为 IPv6 点对点链路：完成路由器发现后，主机在该链路上的唯一邻居是默认路由器，而且链路上没有需要解析的链路层地址。
  • 这省去了地址解析，却没有消除确认路由器可达的需要。邻居不可达检测（NUD）仍然重要；TCP、RTCP 或 SIP 的反馈有时能提供有限的双向可达证据，从而避免重复探测。

分析

IETF 在 2003 年发布 RFC 3316 时，标题谨慎地限定为“部分”第二代和第三代蜂窝主机。它是一份面向 GPRS 和特定 UMTS 版本实现者的信息性指导，不是新的 IPv6 标准，也不是适用于每种无线接入、笔记本电脑或蜂窝路由器的统一清单。引言明确提醒：没有经过细致分析，不应把它当作其他蜂窝链路的功能清单。

这个范围很重要，因为 IPv6 的常见主机流程要适配一种不同的链路。在共享以太网上，主机可能先把邻居的 IPv6 地址解析为链路层地址，才能发送数据包。RFC 3316 对 GPRS 和 UMTS 的描述却是：链路类似点对点连接，主机只有默认路由器这一个邻居，而路由器发现已经识别了它。接口上没有链路层地址，因此地址解析和下一跳判定都无事可做。

但不能由此推出另一个结论：既然没有 MAC 地址可查，主机也就不必维护邻居状态。RFC 3316 并没有这么说。同一节仍要求主机支持 IPv6 邻居发现体系中的邻居不可达检测（NUD）。地址解析问的是如何构造链路层目的地址；NUD 问的是一个已知邻居现在是否仍然可达。第一个问题可以消失，第二个问题却仍在。

原因是实际运行需要。要访问本地链路之外的目的地，主机仍需要可用的下一跳。点对点承载告诉它另一端是哪台路由器，却不能保证这台路由器此后一直可达。路由器发现、地址配置、链路层解析和邻居可达性彼此相关，却不是可以互相替代的证据。

蜂窝带宽也让重复的控制报文值得商榷。RFC 3316 建议：如果主机已经能确认双向 IP 通信，可以利用上层协议给出的可达性确认。TCP 可以依照邻居发现规范中描述的机制提供这种确认。对于由 UDP 承载的 RTP，RTCP 接收报告若显示收到了数据包，就可以说明数据确实到达对端，也因此到达邻居。SIP 响应可以确认请求到达了另一端；在一个更窄的服务器场景中，收到 SIP ACK 可以表明此前的响应已经送达。UDP 本身则不能提供这样的确认。

这不是说应用层流量让 NUD 过时。网络上已经存在的一条有效响应，可能足以回答有限的可达性问题，无须再发一个探测报文。但每种证据都有边界：RTCP 报告说明了数据包接收情况，SIP 响应说明了某次 SIP 交互。它们都不能证明应用操作已完成、所有路径都健康，或用户拿到了服务。不能因为链路没有 MAC 地址，就把无回应的 UDP 流当作成功证明。

RFC 中其他蜂窝适配也体现了这一点。关于 PPP 上 IPv6 的部分讨论了移动终端向所连接设备建议链路本地接口标识符；它并未禁止后者为全局地址或隐私地址使用其他标识符。无状态配置部分也依赖在各自范围内唯一的前缀，因此蜂窝接口无须执行重复地址检测。这些是不同协议层上的具体调整，不是笼统取消 IPv6 检查。

2013 年，RFC 7066 取代 RFC 3316，把所述 3GPP 范围从 GPRS 和 UMTS 扩展到演进分组系统。它保留了“没有链路层地址”的解释以及对 NUD 的要求，并进一步指出 GGSN 或 PGW 可能根本不回应地址解析请求。这个后续版本显示的是 3GPP 适用范围如何随时间调整，并不能说明有多少设备实现了某种行为。如今通用 IPv6 主机要求由 RFC 8504 讨论，因此不能把 RFC 3316说成当前完整的主机要求清单。

更持久、也更具体的工程教训是：一种链路可以让通用协议中的某个操作变得多余，却仍留下原先要回答的问题。在这里，主机不用发现链路层地址，但仍需获得邻居可达的证据。上层反馈有时能减少重复信令，却不能因此成为整个服务正常的证明。

来源

这些 RFC 描述的是协议指导，并未测量信令节省、无线可靠性、电池续航、部署比例或用户体验。