摘要

  • IESG 已批准有状态 NAT64 第 16 版草案成为 Internet Standard，但获批文本明确区分端点无关映射与入站过滤。
  • 运营方需要一份双轨证据：一轨证明外部元组如何分配和复用，另一轨证明特定协议、方向与来源实际受到何种过滤。

一次验收可以既精确又得出错结论。测试人员让同一个 IPv6 地址和端口依次连接多个 IPv4 服务器，翻译器在绑定有效期内始终分配同一个外部 IPv4 地址和端口。这个结果足以证明端点无关映射。

报告模板却顺手把“入站受保护”也勾成通过。测试没有从未被内部主机访问过的 IPv4 地址发送报文，没有读取默认动作，也没有保存设备安装后的过滤规则。真正发生的事不是技术失败，而是证据越权：描述元组复用的试验，被拿去证明来源准入。

2026 年 9 月 4 日，IESG 批准第 16 版草案 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers 成为 Internet Standard，并要求 RFC Editor 将其纳入 STD 103。公告称该技术已得到广泛实现与部署，文件将取代 RFC 6146，工作组过程未出现重大争议。

批准并不等于最终 RFC 已经刊发。截至本文截点，Datatracker 文件页仍显示第 16 版位于 RFC Editor 队列，因等待作者输入而处于阻塞状态。历史记录证明了流程进展，却不能提供尚未产生的继任 RFC 编号。

这次批准也不应被包装成协议突然改变。公告认为对勘误 4756 与 8416 的处理属于编辑性或澄清性修正，不改变协议行为或互操作性。第 16 版附录 A 明确说两项勘误都不产生协议影响；RFC 6146则保留了即将被取代的历史基线。值得治理的不是一个虚构的新防火墙，而是长期存在却常被混写的两项决策。

映射回答“用哪个外部元组”

有状态 NAT64 通过绑定信息库与会话表，把 IPv6 传输地址关联到 IPv4 传输地址。对 TCP 和 UDP 而言，传输地址由 IP 地址与端口组成。流量停止并超过计时器后，动态绑定释放，稀缺的 IPv4 地址与端口可以再次使用。

所谓端点无关映射，是指同一 IPv6 源地址和端口在绑定窗口内访问不同 IPv4 目的地时，继续使用同一外部 IPv4 地址和端口。RFC 4787为 UDP NAT 规定这一行为，目的在于提高应用透明度与穿越能力；它同时强调，各种映射方式不决定 NAT 的安全属性，真正的决定来自过滤。

RFC 5382把这一原则扩展到 TCP：应用可以稳定地学习并公布外部元组，但外部对端能否连接仍受 NAT 安全策略约束。因此，“无关”只描述外部目的地是否影响元组分配，绝不等于所有外部来源都获准进入。

获批草案要求翻译器必须提供端点无关映射，也允许实现地址相关映射。能力清单可以表明设备支持什么，运行证据则必须表明当前接口和协议选择了什么。仅凭映射试验，无法读出默认拒绝、允许来源或过滤规则是否成功安装。

过滤回答“谁能穿过现有状态”

第 16 版给出的对照很清楚：已经存在端点无关映射但没有过滤时，任何把报文发往该外部传输地址的 IPv4 节点，都可能经 NAT64 转到对应 IPv6 传输地址。这里的可达性来自“有映射且无过滤”这一组合，而不是映射名称自身。

映射方式不变，增加动态地址相关过滤后，翻译器可以只允许内部 IPv6 主机此前联系过的 IPv4 地址返回。明确拒绝或默认拒绝会丢弃其他来源。同一个公网元组，因过滤决策不同而呈现完全不同的入站表面。

不能把更严格简单等同于更正确。RFC 4787 在 UDP 场景中给出真实取舍：应用透明度优先时推荐端点无关过滤，约束优先时推荐地址相关过滤，而且允许由管理员配置。RFC 5382 进一步允许 TCP 与 UDP 采用不同的过滤行为。于是，“设备符合标准”仍然不是某个协议所用策略的答案。

ICMP 更不能被套进统一表格。RFC 5508使用查询标识符承担类似端口的会话识别作用。勘误 4756 澄清，在相关处理阶段，ICMP 不存在 TCP/UDP 意义上的地址相关过滤规则。这不是说 ICMP 无需任何策略，而是提醒测试人员：不要把 UDP 的判断矩阵机械复制到另一类报文。

静态绑定让证据缺口更危险

安全章节提醒，在某些静态映射中，只按五元组过滤可能容易被猜中。翻译器可以额外跟踪 TCP 序列号，检查 SYN 与 FIN 的顺序，但这只是可选能力。一次成功翻译既不能证明该能力启用，也不能证明升级或故障切换后仍保持原状。

有状态翻译还受有限资源约束，包括 IPv4 传输地址、绑定与会话表、分片缓存和链路容量。草案讨论了限制分片存储，也要求在某些状态寿命防护中准确指定哪一侧面向互联网。若报告不记录方向、协议、计时器以及绑定来自静态配置、动态创建还是 PCP，单独的“EIM 通过”几乎无法支撑风险判断。

RFC 7269总结 NAT64 部署经验，涵盖高可用与安全；RFC 8683提供 NAT64/464XLAT 的进一步部署指南。它们共同说明翻译器属于一个有路由、冗余与运维边界的系统，但没有任何一份文件把元组复用写成防火墙证明。

建立映射—过滤决策回执

Daniel Kade 提议建立一份映射—过滤决策回执。记录头部应包括翻译器与软件版本、接口及方向、协议；随后分别保存映射模式、过滤模式、默认动作、绑定的静态/动态/PCP 来源、绑定与会话计时器、策略版本与批准人、资源上限以及例外到期时间。

执行证据也必须分开。第一组试验用多个目的地验证同一内部元组是否获得预期外部元组。第二组从获准和未获准来源发包，验证入站决策。已安装规则、计数器、告警与切换后复测，把纸面意图连接到设备结果。

这不是整机认证，更不是永不过期的安全保证。它只形成一个可核查的小结论：在这个版本、接口和协议上，映射这样复用，过滤这样执行，例外如下。软件升级、接口角色变化、策略编译、计时器调整、故障切换或新增静态绑定，都会让相应证据失效。

The Policy Mirror要求找到规则真正获得效力的位置：映射在元组分配处生效，过滤在入站判断处生效。Running-Code Primacy要求分别证明两处都按预期运行。Reality, Not Advocacy则限定结论：标准文本可以揭示控制边界，却不能替代对具体运营网络的审计。

来源