摘要

  • RFC 9872 建议终端在可用时从 RFC 8781 的路由器通告选项取得 PREF64；RFC 7050 的 DNS 发现只在没有该选项或兼容旧终端时作为后备。
  • 多宿主环境真正需要保存的不是前缀本身，而是有时限的“前缀—通告路由器—源地址—下一跳—翻译结果”证据链。

设想故障发生时，所有单项检查都显示绿色。PREF64 格式正确，IPv6 源地址有效，默认路由存在，目的地址也能成功合成。数据包仍然失败，因为前缀来自上游甲，系统却选择了上游乙的源地址和下一跳；对应的 NAT64 翻译器根本不在那条路上。

RFC 9872 把这类组合错误写成部署建议。这份 2025 年 9 月发布的 IETF 信息类共识文件建议：终端应先尝试 RFC 8781 规定的路由器通告 PREF64 选项，部署 NAT64 的运营商也应在通告中提供它。只有通告没有该信息，或者旧系统不会解析时，才退回 RFC 7050 的 DNS 机制。

PREF64 是把 IPv4 目的嵌入 IPv6 地址的合成前缀，其格式来自 RFC 6052。知道它可以在终端执行 RFC 6147 的本地 DNS64，支撑 RFC 6877 的 464XLAT/CLAT，也可处理 RFC 8305 讨论的 IPv4 字面地址。这些是能力声明，不是路径证明。

RFC 7050 通过 ipv4only.arpa. 的合成 AAAA 回答推导前缀，RFC 8880 则要求对这个特殊名称做专门处理。问题在于，发现依赖网络提供的 DNS64，或依赖应用和本地解析器正确识别例外。用户改用其他递归解析器，或分流 VPN 只替换 DNS 而没有接管全部流量，都可能让发现失效或脱离本地路径。

多宿主把缺口放大。不同 ISP 的 DNS64 可以返回不同 PREF64，但 DNS 回答无法可靠指出每个前缀对应哪条上游、哪个 IPv6 源前缀和哪个默认网关。终端可能拥有全部正确数据，却拼出一个没有意义的组合。此时错误不在某个字段，而在字段之间缺少可执行关系。

路由器通告把这段关系留在首跳。RFC 4861 本来就用 RA 发布路由器存在及链路参数；RFC 8781 增加前缀和缩放后的有效期。终端可以记录“谁通告了什么”，并在收到零有效期时停止使用前缀。它仍不是证书：RA 可能伪造或配置错误，路由和翻译器也可能在通告后失效。

两种方式对撤回权的分配也不同。DNS 发现要等网络栈配置后再做一次查询，并把结果留到 TTL 过期；使用外部 DNS64 时，接入运营商甚至不能主动缩短 TTL。新的 RA 可以立刻更新或撤回前缀。因此关键差别不是少一次往返，而是谁能及时终止错误状态。

安全风险只是换了位置。从 RA 获取前缀会避开伪造 DNS 回答这一入口，却让首跳防护变得更重要。RFC 6105 描述 RA-Guard，但不能证明所有获准 RA 都正确。RFC 9463 可通告网络指定的加密解析器；加密能保护 DNS 会话，不能自动补上前缀与出口的绑定。

迁移期允许重叠。遵循规范的新终端应优先采用 RFC 8781，旧终端仍可能依赖 RFC 7050。RFC 9872 还明确提醒：移动操作系统可能已经支持选项，移动网络设备却未必能把它放入 RA。官方记录 证明文件已经发布，不证明任何具体网络已经部署。

以 Heng Lu 的运行代码优先来看，最终裁决应是可复现的路径与应用结果，而不是配置页面。他的最小初始规范允许共同层只规定一个窄信号，把采用和执行留给本地。他对永久双栈税的批评，则要求管理层看见解析器、首跳安全、翻译器和旧机制并存的完整成本。

RFC 9872 没有把 PREF64 升格为权威；它只是让前缀重新带上足以做本地判断的出处。发现完成之后，路由选择、翻译到达和应用完成仍要分别证明。

来源