Summary

  • IETF 于 11 月 2 日就 NAT64 草案第 10 版发起 Last Call，意见截至 11 月 23 日。草案拟把 64:ff9b::/96 对私有及共享 IPv4 地址的统一丢弃规则改为可放行。
  • 第 10 版新增建议：受管理的转换器应暴露其处理非全球可达地址的默认动作。现有按 RFC 6052 丢包的受管理 PLAT，草案建议升级时保留该默认设置。

旧规则是一扇焊死的门

RFC 6052 第 3.1 节给 NAT64 的知名前缀 64:ff9b::/96 划了硬线：不能用它表示私有等非全球可达的 IPv4 地址；碰到这种组合，转换器必须丢包。企业若想让纯 IPv6 终端访问内部 IPv4 服务，就得另找前缀或通路。

11 月 2 日的 Last Call把另一种规则交给全体审查。按第 10 版草案，知名前缀可表示 RFC 1918 私有地址及 RFC 6598 共享地址。无人管理的客户端转换器 CLAT 默认必须转换；运营方管理的 PLAT 则必须转换，除非配置另有规定，而且必须提供禁用选项。一个写在标准里的丢包决定，拟移到运营方的配置席位。

草案给出的困难很具体：客户端本地合成目标 IPv6 地址时，现有广泛部署的 NAT64 前缀发现机制不会告诉它“这个前缀只管哪一段 IPv4”。同时发现知名前缀和企业前缀，客户端可能把两个前缀都用于全球 IPv4 目标。草案也称现有 CLAT 行为不一致：有的遵旧规丢包，有的照样转换。这些是作者写入草案的运营观察，没有给出可核算的产品占比。

第 10 版补上的不是另一把开关

第 9 版已经有放行与配置开关的核心提议。第 10 版新增第 4.3 节，要求人们正视一个更实在的问题：值班员能否看见设备默认会做什么？它建议受管理转换器暴露处理非全球可达地址的默认值，并建议运营方用明确配置或监测办法核对实际行为。放行还得有相应的路由策略。

旧设备也有自己的历史。草案安全章节说，现有遵守 RFC 6052、默认丢包的受管理 PLAT 不宜在升级时暗中改成放行。新规则的方向与旧设备的默认值因此可能不同。靠“厂商实现 NAT64”五个字，运维团队无法知道哪台机器会开门。

这正是治理问题落到机柜里的样子：规则制定者可以挪动默认线，承担内网暴露后果的却是网络运营方。可操作的记录应写明设备版本、默认值、显式配置、目标路由与 ACL，再用一次可复核的测试确认私有地址流量究竟在何处被放行或阻断。草案没有给出任何特定网络的配置与测试结果；拿到它们，才能判断那张网的风险。

Sources