464XLAT:核心网中的 IPv4 兼容
文档仍在编辑中,内容可能与实际版本有出入。
这是一篇补充阅读。正常配置 Flet’H 时不需要使用 464XLAT;如果你想分清 IPv4-in-IPv6 封装和 IPv4/IPv6 地址翻译,可以从这里开始。
先记结论:464XLAT 不会把完整的 IPv4 包装进 IPv6 隧道。它先在用户侧把 IPv4 包翻译成 IPv6,经过 IPv6-only 网络后,再由运营商侧翻译回 IPv4。
用户侧能看到什么
Section titled “用户侧能看到什么”对大多数终端用户而言,464XLAT 几乎没有可感知的区别,原有的 IPv4 应用仍然可以正常联网。少数能直接看到的线索之一,是手机或终端上出现一个仅供本机 IPv4 兼容使用的地址;部分实现会显示为 192.0.0.2,看起来和 DS-Lite 很相似。
这是因为 464XLAT 和 DS-Lite 都可以使用 192.0.0.0/29 这段 IPv4 Service Continuity 地址。该地址不会作为公网 IPv4 发到线路上,看到它也不代表 464XLAT 与 DS-Lite 使用了相同的传输机制。
运营商如何让手机启用 464XLAT
Section titled “运营商如何让手机启用 464XLAT”464XLAT 通常不是用户手动打开的功能。移动运营商会通过运营商配置向终端下发 464XLAT 能力;当网络实际提供 IPv6-only 数据会话时,终端可以启用 CLAT,网侧则提供 PLAT/NAT64。
在 iOS 上,这类终端能力配置会包含在运营商设置包(.ipcc)里。解包后可以在 carrier.plist 的 APN 项中看到类似配置:
<key>apn</key><string>spmode.ne.jp</string><key>DefaultProtocolMask</key><integer>3</integer><key>AllowedProtocolMask</key><integer>3</integer><key>enableXLAT464</key><true/>这是 🍄 的 spmode.ne.jp 配置。协议掩码 3 表示该 APN 同时允许 IPv4 和 IPv6,并没有强制所有连接使用 IPv6-only;enableXLAT464 则为 iOS 预置了 464XLAT 能力。当实际网络只分配 IPv6 时,终端才可按需启动本机 CLAT。终端配置只负责这一侧,运营商网络仍需提供 PLAT/NAT64。
464XLAT 如何工作
Section titled “464XLAT 如何工作”464XLAT 组合了两个功能不同的翻译器:
[ 私有 IPv4 客户端 ] -- IPv4 --> [ CLAT ] -- IPv6 --> [ PLAT ] -- IPv4 --> [ IPv4 互联网 ] 无状态翻译 有状态 NAT64- CLAT(Customer-side translator) 位于终端或用户侧路由器。它按固定规则在 IPv4 与 IPv6 之间做无状态的一对一翻译。
- PLAT(Provider-side translator) 位于运营商网络。它通过有状态 NAT64,在多个 IPv6 用户与运营商的 IPv4 地址池之间建立映射。
回程流量按相反顺序经过 PLAT 和 CLAT。原生 IPv6 流量则直接走 IPv6,不需要经过这两次翻译。
RFC 6877 将 464XLAT 定位为“有限的 IPv4 连接”:它适合客户端主动访问 IPv4 服务器,但不能替代可从互联网直接访问的公网 IPv4 地址,也不提供完整的入站 IPv4 或点对点连接能力。
CLAT 与 DNS64 的关系
Section titled “CLAT 与 DNS64 的关系”只有 NAT64 和 DNS64 时,支持 IPv6 的应用可以通过合成的 AAAA 记录访问仅有 IPv4 的服务器。但下面这些情况仍然需要一个本地 IPv4 兼容入口:
- 应用直接连接 IPv4 字面地址,例如
192.0.2.1。 - 应用只会创建 IPv4 socket。
- CLAT 后方还有只支持 IPv4 的设备。
CLAT 会先接住这些 IPv4 流量,再翻译成 IPv6 送往 PLAT。因此,464XLAT 本身不依赖 DNS64;部署 DNS64 后,支持 IPv6 的应用可以绕过 CLAT,只在 PLAT 做一次 NAT64 翻译。
和其他 IPv4 over IPv6 方式的区别
Section titled “和其他 IPv4 over IPv6 方式的区别”| 方式 | IPv6 网络中传输的内容 | 主要状态位置 | Flet’H 当前支持 |
|---|---|---|---|
| DS-Lite | 外层 IPv6 封装的完整 IPv4 包 | 运营商 AFTR | 是 |
| MAP-E | 外层 IPv6 封装的完整 IPv4 包;IPv4 地址和端口集由规则决定 | 映射本身不需要运营商保存每条连接状态 | 是 |
| IPIP6H / IPIP6HP | 外层 IPv6 封装的完整 IPv4 包 | 取决于运营商的固定 IP 服务 | 是 |
| 464XLAT | 翻译后的 IPv6 包,不保留原始 IPv4 头 | 运营商 PLAT 的 NAT64 | 否 |
DS-Lite、MAP-E 和 IPIP6 会保留原始 IPv4 包,再加上外层 IPv6 头。464XLAT 则重写 IP 头,让 IPv6 段只传输翻译后的 IPv6 包。它们都能利用 IPv6 网络提供 IPv4 连接,但封装、地址语义和运营商需要保存的状态并不相同。
和 Flet’H 的关系
Section titled “和 Flet’H 的关系”464XLAT 和 Flet’H 没有直接关系。
- RFC 6877: 464XLAT: Combination of Stateful and Stateless Translation
- RFC 7335: IPv4 Service Continuity Prefix
- RFC 7849: An IPv6 Profile for 3GPP Mobile Devices
- RFC 8683: Additional Deployment Guidelines for NAT64/464XLAT
- RFC 9313: Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service
- JANOG30:IPv6時代のIPv4を考える ~第二章~ 464XLAT 事前公開資料
- IPv6 Summit in TOKYO 2022:NTT ドコモ「IPv6シングルスタックの導入とその後の動向」
- Apple CDN: Docomo_jp iPhone
.ipcc配置