摘要

  • 2026 年 9 月 4 日，IESG 批准有状态 NAT64 修订稿成为 Internet Standard。这是对协议成熟度和广泛实践的判断，不是对某一产品、容量配置、过滤策略或故障切换结果的认证。
  • 有状态 NAT64 把有限的 IPv4 地址与端口临时分配给大量 IPv6 客户端。若要证明容量、连续性或归因，必须分别保存 BIB 绑定、会话、计时、过滤、复制和应用结果。

IESG 公告确认，draft-ietf-v6ops-rfc6146-bis-16 已于 9 月 4 日获批成为 Internet Standard。它将取代 RFC 6146，并被列入 STD 103。Datatracker 页面显示“批准公告已发送”，IANA 工作仍在进行；本次研究所见记录尚未给出最终 RFC 编号。

这个状态边界不应含混。技术决定已经完成，正式出版流程尚未结束。把它称作仍待表决的提案会低估事实；把它称作已有最终编号的 RFC 又会超出证据。

升级的是共同规则，不是某台设备

获批的第 16 版说明了修订范围：解决两项不改变协议行为的勘误，更新引用，澄清端口奇偶保持规则，并增加非规范性的运行考虑。核心行为仍以 RFC 6146 为基础，RFC 6144则给出 IPv4/IPv6 翻译的总体框架。

文档列出了许多商业产品、开源实现、云服务和操作平台。这是成熟度证据的一部分，却不是合规名单。文档明确说，清单来自公开资料，不构成 IETF 背书，也没有为了此次出版逐一做正式互通确认。RFC 7942对实现状态章节的定位同样有限：帮助标准工作判断现实进展，而非发放认证。

因此，名称出现不能证明正在运行第 16 版，不能证明某项可选行为已启用，更不能证明地址池容量、日志完整性或状态复制已经达标。Lu Heng 的运行代码优先恰好提供了顺序：标准约束实现，运行中的实现和可观察结果才证明具体服务。

稀缺单位不是一枚地址

有状态 NAT64 让仅支持 IPv6 的客户端访问 IPv4 服务器。翻译器用少量公网 IPv4 地址承载大量客户端，实际分配的通常是“IPv4 传输地址”：IPv4 地址加 UDP 或 TCP 端口，或者地址加 ICMP 标识符。

这是一项有期限的使用权。端口和地址在一个时段映射给某个 IPv6 传输地址；状态释放后，同一组合可以交给另一方。只保存公网 IP，就像只记录一栋办公楼而不记录房间、时间和租户。

协议在资源允许时尽量保持端口区间和奇偶性。若找不到合适的传输地址，翻译器可以返回 ICMPv6 错误；本地策略也可以让错误静默。用户看到超时，无法据此单独判断地址池耗尽。过滤、路由、翻译、IPv4 服务器或应用都可能是终点。

共享提升了 IPv4 使用效率，也提高了账本密度。RFC 6269讨论地址共享对归因和应用假设的影响，RFC 6888给出大规模翻译器的通用日志要求。第 16 版也承认，按需使用更多端口可以缩小公网地址池，却会产生更大的日志。

一笔合格记录至少要有公网地址、端口或标识符、协议、内部 IPv6 传输地址、分配与释放时间、时钟误差、翻译器实例、地址池代次和准入规则。公网 IP 不是身份；它只是这条链的一个字段。

BIB 绑定与会话不能合并

规范分别维护 UDP、TCP、ICMP 查询三类绑定信息库，也就是 BIB。BIB 把一个 IPv6 传输地址绑定到一个 IPv4 传输地址。系统还分别维护三类会话表，记录实际通信双方和协议状态。

一个端点无关的绑定可以服务多个目的地址和多个会话。手工配置的绑定可能根本没有会话，而且只能显式删除。会话可以先过期，绑定仍然存在。TCP 还经历暂态、已建立和关闭等不同计时阶段。把它们统称为“NAT 表项”，会失去权利对象和行为对象之间的区别。

运行账本应给 BIB 与会话分别编号，再保存它们的关联、配置代次、创建原因、刷新包和终止原因。故障切换后，如果备用节点重建了一行新状态，也应保留继承关系，而不是让新行冒充原来的见证人。

这正是现实分层的用途。“已启用 NAT64”属于配置层；BIB 是翻译器的权利记录；会话是协议状态；翻译后的包是观测；用户交易完成则属于应用结果。上一层为真，不能自动填满下一层。

映射方式不等于返回许可

有状态 NAT64 要求端点无关映射：在绑定有效期内，同一 IPv6 传输地址访问不同目标时，可以保持同一个外部 IPv4 传输地址。这有助于应用和点对点场景。

安全性却由过滤决定。没有过滤时，任何能到达有效映射的 IPv4 来源都可能穿过翻译器；采用地址相关过滤时，返回流量可被限制为客户端此前访问过的 IPv4 地址。RFC 4787给出 UDP 的概念与行为，RFC 5382覆盖 TCP 行为和计时基础。

所以，“端点无关映射”不是安全结论。验收材料必须同时写明映射模式、过滤模式、默认规则、例外、静态绑定、配置版本，并从允许和不允许的来源实际发包验证。

哪一侧被标记为外网也有实质影响。为了阻止外部流量无限续命，运营者可以选择不让来自“Internet 一侧”的包刷新状态。如果接口角色标错，防护就在错误方向生效。接口名称只是符号，路由和实际刷新行为才是证据。

计时器在分配连续性

动态权利都受时间约束。UDP、ICMP 会话有寿命；TCP 在暂态、已建立、关闭之间转换，并使用不同超时；分片队列占用受限内存并等待有限时长。到期意味着端口与内存可以再分配。

超时太短，会切断合法但暂时沉默的连接；太长，则稀缺端口被占用更久，也给恶意续命更多空间。运行考虑特别指出，QUIC 依赖合理的 UDP 会话寿命，同时不能把 QUIC Connection ID 当作 NAT 状态键。

因此不能只看“当前会话数”。还要按协议、状态和配置代次观察新建率、刷新来源、年龄、预计到期、提前删除、分配失败、静默错误、分片内存、SYN 状态与端口区间压力。会话数骤降可能是清理，也可能是事故；必须用原因和应用结果区分。

翻译器是被设计出来的集中点

安全章节明确列出有限资源：公网 IPv4 地址与端口、内存、CPU、链路容量。攻击者可以变换 IPv6 源传输地址来占用绑定，也可以用分片或 SYN 消耗内存，或周期性发包延长状态。

这些是风险模型，不是当前攻击证据。本文没有发现某家运营者已经耗尽或遭受事故。规范告诉管理者应当测量哪些面：可用地址、各协议端口、BIB、会话、分片内存、分配延迟、拒绝与告警。

RFC 9693规定了有状态 NAT 网关的基准测试方法。测试数字必须绑定设备、软件、配置、流量构成、包长与方法，不能从一个型号转借给另一张网络，更不能直接换算为通用“每地址用户数”。

标准没有给统一地址池大小，这是合理的克制。Lu Heng 的最小初始规范与本地未来决策说明：共同层只规定互通所必需的内容，拓扑、容量和风险选择留给本地。留给本地并不等于无人负责。

高可用首先是状态连续

备用翻译器通过健康检查，只能证明它还活着。它是否知道主节点刚分配的端口、当前会话和剩余计时，需要另一份证据。RFC 7269与 RFC 8683汇集 NAT64 部署经验并讨论高可用，但没有替某个集群证明复制成功。

切换前应保存主备代次、复制水位、遗漏 BIB 与会话、计时偏差和地址池所有权。切换后分别测试既有 UDP、TCP、ICMP 通信，记录哪些继续、哪些重建、哪些失败。

双活失调会带来更危险的情况：两个健康节点同时认为自己拥有同一地址池，可能发出冲突权利。备用节点若拒绝所有未复制状态，可以保护唯一性，却牺牲连续性。这个取舍必须由责任人事先决定，不能藏在产品默认值里。

归因必须带上时钟和代次

RFC 8158定义用于 NAT 资源管理的 IPFIX 信息元素，可显示消耗、阈值和事件。它们很有用，但不会自动连接 BIB、会话、内部身份、翻译包与应用审计。

调查必须双向可重建：给定外部地址、端口、协议和时间，找到当时的地址池、实例、代次、BIB、会话与内部 IPv6 上下文；给定客户端，也能重现它在某一时段拥有的外部权利。每次跨系统关联都应携带时钟偏差与不确定性。两条路径不一致时，保留“不确定”，不要强行指定一个人。

Internet Standard 可以规范翻译行为，却不会自动赋予运营日志法律或事实上的最终权威。它不能证明某个自然人执行了操作，不能证明应用接受了命令，也不分配责任。

这并不削弱 IETF 的决定。相反，成熟的共同规范让本地证据可以被更严格地提问。地址池、过滤器、计时器、备用节点和日志都仍是本地权力。权力留在哪里，账本就必须写到哪里。

来源