摘要

  • RFC 9872 建议终端首先通过 RFC 8781 定义的 PREF64 路由器通告选项取得 NAT64 地址合成前缀。
  • 这种安排传递的不只是前缀值，还把有效期、接入链路和翻译器上游关系保留在同一运行语境中。

真正困难的时刻发生在第一个翻译数据包之前。终端已经加入仅 IPv6 网络，也知道目标 IPv4 地址，但本地合成 IPv6 目的地址时，需要一个当前网络的 NAT64 翻译器能够识别的前缀。在错误网络学到的合法前缀，会生成格式正确却无法抵达的地址。

RFC 9872 将这项配置置于接入过程。终端应先按照 RFC 8781 从路由器通告取得 PREF64，部署 NAT64 的运营者也应在通告中提供它。只有通告未携带该选项，或终端无法处理时，才使用 RFC 7050 的 DNS 方法。

通告同时规定范围与时间

RFC 8781 为 PREF64 分配邻居发现选项类型 38。选项包含前缀位、前缀长度代码和以八秒为单位的有效期。有效期为零表示停止使用该前缀。规范不建议让 PREF64 有效期短于默认路由器有效期，否则路由器仍看似可用时，翻译前缀可能已经过期。

终端必须把前缀视为所接收网络的专属信息；支持 Provisioning Domain 时，还必须关联到相应 PvD。若通告给出多个非零有效期前缀，可以选用其中之一；若同时存在多种发现机制，RFC 8781 建议只选一个信息来源，避免混合互不一致的答案。

多宿主场景让这种绑定更重要。用某个上游的前缀合成的流量，必须发往能够服务该前缀的翻译器。只保存前缀字符串而丢掉接口和上游关系，会破坏正确选路所需的证据。

DNS 的视角可能离开接入网络

RFC 7050 通过向 DNS64 解析器查询特定的仅 IPv4 名称，再从合成的 AAAA 答案提取 PREF64。加密 DNS、VPN 或手动配置可能使实际解析器位于接入网络之外，因此它未必知道本地翻译器的前缀。

缓存也会延迟变更。DNS 发现受 TTL 约束；路由器通告则能在链路上直接发布新前缀，或用零有效期撤销旧前缀。提供转发路径的网络由此也能控制使该路径可寻址的参数。

核心建议见 RFC 9872，选项格式与主机处理见 RFC 8781，DNS 后备见 RFC 7050。RFC 6052 和 RFC 7915分别定义地址格式与无状态翻译。这些规范不证明当前部署率、厂商支持或翻译器健康状态。

发现 PREF64 也不等于认证了路由器通告，不证明翻译器可达，不证明已经部署或具备某种性能，更不表示 RFC 6052 的 Well-Known Prefix 适用于所有 NAT64 网络。这五项判断都需要独立证据。