Summary

  • IETF 第 10 版草案拟允许 NAT64 公认前缀 64:ff9b::/96 表示私有及共享 IPv4 地址；草案仍在 IESG 最终征求意见阶段，截止 2026 年 11 月 23 日。
  • 草案要求无人管理的客户端翻译器默认翻译此类流量；受管理的服务端翻译器须能关闭该功能，已有设备升级时宜保留原先的丢弃默认值。
  • 一条前缀可同时服务外部和内部 IPv4 目的地，但进入私网的资格必须由路由、ACL 和防火墙明确决定。

某些网络的“防火墙”写在 RFC 的地址格式规则里。RFC 6052 第 3.1 节禁止用 NAT64 公认前缀拼出非全球可达的 IPv4 地址，并要求翻译器丢弃这类数据包。运营者即使没有写过一条针对内部服务的访问规则，也可能因这项强制丢弃而享有隔离效果。现在，IETF 正讨论撤掉这道免费门槛。

旧禁令有充分理由。RFC 1918允许不同企业重复使用私有地址。甲公司的 10.0.0.1 和乙公司的同号主机没有共同身份。把这个号码塞入一条人人看得懂的 IPv6 前缀，不能凭空确定包究竟该去哪个行政域。然而一刀切的拒绝也挡住了正当业务：IPv6 单栈终端可能必须访问仍只有 IPv4 的内部服务。RFC 6598规定的运营商共享地址空间又增加了一类非全球地址。

草案的核心选择是让同一公认前缀承担两种目的地。它节省了客户端在公网和私网间选择翻译前缀的麻烦，也把“能翻译”与“该放行”拆成两道必须有人负责的决定。

两条前缀为何不是简单答案

在白板上，公网 IPv4 用公认前缀，私网 IPv4 用网络专用前缀，看起来干净。DNS64 若替客户端生成 AAAA 记录，可以依目的地挑选答案。问题是 CLAT 等客户端翻译器常直接拿到应用里的 IPv4 字面地址，自行合成 IPv6 目的地址，根本不会向 DNS64 询问这次该走哪条路。

IETF 草案指出，RFC 7050 发现机制与 RFC 8781 的路由器通告能告诉终端有哪些前缀，却不提供“哪段 IPv4 对应哪条前缀”的分配表。终端同时学会两条前缀后，甚至可能为同一个公网地址生成两套 IPv6 目的地址。过滤规则、故障日志和回程路由也随之分叉。RFC 8215 的本地使用前缀与公认前缀并用时，同样缺少这张选择表。

于是草案直接改写 RFC 6052 的硬规则：公认前缀对非全球 IPv4 地址从“不得”变为“可以”；无人管理的 CLAT 对这种包默认翻译；受管理的 PLAT 除非另行配置，否则也翻译，并必须提供关闭开关。这几个规范性动词决定了权力交接：过去由标准一律否决的流量，今后交给具体网络的配置来裁决。

升级软件不能顺手升级权限

草案安全章节承认，有些运营者把旧标准的强制丢弃当作私网屏障。因此它建议现有合规的受管理 PLAT 升级时维持丢弃默认值。真正想开放的管理员应检查本地安全政策，再开启翻译。路由要指向正确的私网域，ACL 或防火墙还得限定来源、目的地址与端口。翻译成功只说明协议转换完成，绝不自动证明访问获得授权。

一个合并后的企业可能同时拥有两个 10.0.0.1。两边各自编号都正确，连起来后才发生冲突。若统一 NAT64 前缀接上错误路由，流量会“成功”抵达错误主机。这里的关键不是 IPv6 比 IPv4 更安全或更危险，而是谁拥有那条路由、谁审核访问名单、谁能在事故后解释一次连接的去处。

草案还记录了 CLAT 实现分歧：有的依旧丢弃私网目的地，有的早已翻译。文件没有给出两类设备的数量。运营者真正缺的证据是自己的终端和服务清单：哪些客户端在本地合成地址，哪些翻译器丢包，哪些私网号码在哪个路由域代表什么服务。没有这张表，“打开私网 NAT64”就像给一栋楼装新门，物业却没有房间号。

截至 11 月 3 日，这仍是征求意见中的草案，不是新 RFC。它所揭示的治理问题已经足够具体：通行能力可以由协议提供，通行权必须由运营者承担。便宜的旧禁令曾替组织省下一次正式决定；新规则若获通过，省掉的决定会连本带息回来。

IETF 草案 · RFC 6052 · RFC 1918 · RFC 6598