摘要

  • IPv4 即服务没有消除 IPv4 依赖，而是把依赖转移到 DNS64、前缀发现、CLAT、PLAT 状态和共享端口上。
  • 原生 IPv6 可以保持健康，只有纯 IPv4 名称、字面地址或已建立的长连接失败，因此一个普通可用性探针无法定位控制面。
  • 运营证据应把解析结果、Pref64、CLAT 路径、PLAT 状态、切换、时点归因和不支持的入站场景放进同一份收据。

用户在家庭网关上换了 DNS 解析器。原生 IPv6 服务照常打开；一个只有 A 记录的站点却不再获得合成的 AAAA 地址，仿佛从互联网上消失。另一台设备仍能访问同一站点，因为它的 CLAT 接收 IPv4 数据包，并通过别的机制得知运营商的转换前缀。两家的宽带指示灯都是绿色，故障边界却完全不同。

这正是 IPv4-as-a-Service（IPv4aaS）的运营含义。运营商可以让接入网或核心网只承载 IPv6，再用转换保留对 IPv4 服务器的访问。公共 IPv4 不再端到端分配给一个用户，兼容性也不再是单一属性，而是由解析器、终端、家庭网关、路由和运营商转换器共同完成。

合成地址只是对路径的一项承诺

RFC 6147 定义 DNS64。当客户端查询 AAAA，而目标只有 A 记录时，DNS64 可以把 IPv4 地址嵌入 IPv6 转换前缀 Pref64::/n，返回合成 AAAA。客户端随后向该 IPv6 地址发包。

这份答案只有在同一前缀能被路由到正确的 NAT64 时才有意义。DNS64 与转换器不会为每次查询重新协商参数。一次成功的 DNS 回复只能证明地址已被合成，不能证明 PLAT 有容量、使用相同前缀，或能延续既有会话。

DNSSEC 让责任边界更加清楚：合成会改变 DNS 回答，而 DNSSEC 正是用来发现未经授权的改变。验证与合成可以经过有意识的部署而共存，但“启用 DNS64”不是完整策略。收据需要写明解析器、A/AAAA 集合、DNSSEC 结果与实际 Pref64。

CLAT 保存部分旧假设，并非完整 IPv4

RFC 6877 描述 464XLAT。位于终端或客户边缘的无状态 CLAT 把 IPv4 包变成 IPv6；运营商侧有状态的 PLAT 再把它转换到 IPv4。通过名称访问的应用可以使用 DNS64，只经过一次有状态转换；使用 IPv4 字面地址或旧 API 的应用，则要靠 CLAT 补上第一步。

因此，更换解析器不会产生统一症状。RFC 8683 指出，只有 NAT64 而没有 CLAT 的网络，在用户改用不做 DNS64 的外部解析器后，可能失去 IPv4-only 目标。464XLAT 客户端即使没有 DNS64，也常能通过双重转换继续工作，前提是 CLAT 能发现正确的 Pref64。若解析器合成的是另一个前缀，流量仍可能离开预定 PLAT。

464XLAT 也不是完整原生 IPv4 的替身。RFC 6877 的基本范围是客户端访问有全球 IPv4 地址的服务器，并不自动提供通用的 IPv4 入站或任意点对点通信。产品说明若只写“兼容 IPv4”，却不写这些边界，支持团队最终会把设计限制误判为偶发故障。

Pref64 会被发现，也会过期

RFC 8781 为 IPv6 路由器通告定义 PREF64 选项，其中包含前缀长度和有效期。有效期为零意味着主机不应继续使用。主机应把前缀限定在接收它的接口；若支持 Provisioning Domain，还要限定在相应 PvD。路由器应检查同一链路上的 PREF64 是否一致，并记录冲突。

所以，值得保存的不是一句“设备知道 Pref64”，而是发现方式、前缀、剩余有效期、接口或 PvD，以及通告一致性。旧前缀可能指向已经退役的转换器，过短的有效期则可能在下一次有效通告到来前耗尽。

设备切换不等于会话状态恢复

RFC 6146 定义有状态 NAT64。PLAT 必须保存绑定与会话状态，返回包才能找到原来的 IPv6 客户端。它还必须限制分片占用的资源，防止状态耗尽攻击。但标准并没有让两台转换器天然共享活动会话。

主备切换后，新连接可能立即成功，原有下载、支付会话或隧道却被重置。只在切换后新建 TCP 的健康检查会给出“已恢复”。真正的证据要让同一会话跨过切换，并记录活动 PLAT、状态容量余量、切换事件及既有映射的预期结果。

RFC 9099 补充了安全边界：有状态转换面临状态耗尽，DNS64 与 DNSSEC 相互作用，而大多数 IPsec 部署除非使用 UDP 封装，否则会受到 NAT64 影响。464XLAT 可以不用 DNS64，从而避开特定的合成问题，但不会消除其他转换风险。

地址效率把账本移到了运营商侧

RFC 9313 比较五种 IPv4aaS 技术。在 464XLAT 中，运营商的 NAT64 保存逐流状态并动态分配公共端口。这样可以更细地共享 IPv4 地址，同时集中状态容量、故障恢复与日志压力。

多个用户共用一个公共地址后，归因必须回答“哪一时刻的哪个端口”。逐会话记录最详细，但成本高；在一段时间内分配端口块可减少日志，却降低端口池使用效率。这既是工程选择，也受当地法律影响，RFC 没有规定全球统一的保留期限。

运营商侧状态也不会自动给客户一个公开入站端口。某些服务器场景需要 PCP 或显式映射。该边界应在销售、配置和事件分类中一致表达。

这些 RFC 没有给出 2026 年全球采用率、普遍性能收益或典型故障率。它们给出了可测试的控制链，这已足以定义一项服务。

来源

  1. RFC 6146 — 有状态 NAT64
  2. RFC 6147 — DNS64
  3. RFC 6877 — 464XLAT
  4. RFC 8683 — NAT64/464XLAT 部署指南
  5. RFC 8781 — 在路由器通告中发现 PREF64
  6. RFC 9099 — IPv6 网络运营安全
  7. RFC 9313 — IPv4aaS 技术比较