双栈与过渡技术安全第04页：翻译技术安全（NAT64/DNS64/464XLAT）

01 · 翻译技术体系与框架

1.1 从隧道到翻译：思路的根本转变

隧道技术"保留报文、套上外壳"，翻译技术则直接改写报文：在IPv6-only网络与IPv4-only服务之间，由翻译设备将IPv6报文转换为IPv4报文（或反之），ICMP消息亦同步转换。IETF在RFC 6144（2011）中系统定义了IPv4/IPv6翻译框架，其动机正是废弃隧道后的治理收敛：隧道把复杂性藏在边界两侧，翻译把复杂性集中在少数可信网元——安全治理对象从"全网终端"收窄为"翻译设施本身"。

1.2 核心标准谱系

1.3 翻译信任链的三层结构

02 · NAT64安全分析（RFC 6146）

2.1 工作机制要点

NAT64网关维护IPv6↔IPv4会话状态：IPv6侧地址为"PREF64前缀+内嵌的IPv4地址"（格式见RFC 6052；当使用Well-Known Prefix时为64:ff9b::/96），IPv4侧使用地址池复用。ICMPv6/ICMPv4错误消息按RFC 7915算法转换——ICMP错误消息的忠实转换对PMTUD至关重要，处理不当将制造"TCP黑洞"类故障（与RFC 4890的ICMPv6治理要求呼应）。

2.2 主要安全风险

2.3 地址格式与过滤要点

RFC 6052定义多种IPv4嵌入格式（/96、/64、/56、/48、/40、/32前缀），运营中应统一前缀长度并显式过滤他人PREF64前缀：组织边界不应放行来源为外部PREF64前缀（如64:ff9b::/96之外的网络特定前缀）的入站流量，防止地址语义混淆型攻击。内部使用网络特定前缀（NSP）而非Well-Known Prefix，可天然获得过滤便利性。

03 · DNS64安全分析（RFC 6147）

3.1 合成机制

DNS64与递归解析器协同工作：收到AAAA查询后，若权威侧无AAAA但有A记录，则按PREF64+IPv4地址合成AAAA应答（合成记录的TTL取原A记录TTL与配置上限的较小值）。此后IPv6-only客户端即向合成地址发起连接，由NAT64完成转换。DNS64由此成为翻译信任链的第一环：解析结果决定全部流量走向。

3.2 与DNSSEC的交互限制

合成AAAA记录无法获得有效DNSSEC签名（签名属于原始AAAA记录，而原始记录并不存在）。其后果：启用DNSSEC验证的客户端会对合成记录验证失败——这是DNS64长期存在的标准化限制。RFC 6147的处理思路是让DNS64与验证协同：对带DO位/CD位的查询谨慎合成，由网络侧明确策略（如纯DNS64场景下引导客户端关闭对合成域名的严格验证，或由验证感知型解析器分层处理）。运营含义：部署DNS64前必须评估网内DNSSEC验证策略，否则会出现"安全功能互相否决"的解析故障。

3.3 DNS64作为关键基础设施的防护要求

• 等同于递归解析器的安全等级：DNS64承载全部IPv6-only用户的解析，其可用性与完整性等同核心DNS服务，需纳入防DDoS、源端口随机化、RRL等基线。
• 合成策略白名单化：仅对明确的AAAA缺失场景合成，避免对恶意域名的大量合成放大解析器负载。
• PREF64一致性监测：DNS64使用的PREF64必须与网络NAT64实际前缀一致——不一致将导致流量绕行或黑洞；PREF64变更需纳入变更管理流程。
• 与DNSSEC/DoT/DoH的协调：终端若绕过网络DNS64自行解析（如DoH至公共解析器），将无法获得合成记录——464XLAT场景下表现为CLAT路径退化。缓解路径有二：策略层面引导终端使用网络指定解析器；协议层面部署IETF已标准化的DDR（RFC 9462）与DNR（RFC 9463）机制，使终端经DHCP/RA自动发现网络指定的加密解析器——这正成为IPv6-only网络DNS治理的推荐范式。

04 · 464XLAT安全分析（RFC 6877）

4.1 架构与部署现实

464XLAT在终端侧部署CLAT（将应用的IPv4流量翻译为IPv6，再经IPv6网络传输），在网络侧部署PLAT（即NAT64）完成第二跳转换。该架构使IPv4-only应用无需改造即可运行在IPv6-only网络上，成为全球移动运营商的主流选择——T-Mobile US、Reliance Jio等的IPv6-only移动网络公开采用此方案（以各运营商官方技术披露为准）；Android系统内置CLAT支持，Wi-Fi场景亦可复用。

4.2 安全语义变化

• 双层翻译的可见性：应用看到的仍是IPv4语义，网络实际承载IPv6——v4安全策略（如v4 IPS规则）在接入网段不再生效，安全控制必须上移到CLAT之后与PLAT之上。
• 状态双重放大：CLAT与PLAT各自维护会话状态，状态规模与超时配置不匹配时会引入诡异故障（典型表现为特定应用间歇性断连）。
• MTU/MSS钳制：翻译开销降低有效MTU，ICMP翻译失败将直接表现为TCP卡顿——需按RFC 6146/7915要求保障ICMP错误消息的端到端传递。
• 取证路径变化：会话日志分散在CLAT（终端）与PLAT（网络）两处，事件关联依赖时间同步与映射记录（见第6页）。

4.3 治理要点

对运营者的核心建议：①把PLAT纳入与核心路由器同级的变更与监控管理；②CLAT能力纳入终端基线核查（是否具备、版本是否受支持）；③对464XLAT用户群单独建立"应用兼容性台账"，标注依赖ALG的应用及其替代方案；④映射日志（第6页）是464XLAT网络审计的生命线。

05 · 翻译技术风险矩阵与部署检查表

5.1 风险矩阵（汇总）

5.2 部署检查表（摘要）

• □ PREF64统一规划（建议使用网络特定前缀），边界过滤外部PREF64；
• □ DNS64与递归解析器同等级防护；合成策略与TTL上限文档化；
• □ DNSSEC验证策略与合成策略完成兼容性评估；
• □ NAT64会话配额、状态水位告警、ICMP错误处理验证；
• □ 映射日志字段（内v6五元组+外v4五元组+时间戳+用户标识）完整留存；
• □ 应用兼容性台账（依赖ALG应用清单及替代方案）；
• □ 464XLAT场景CLAT基线核查与双层状态规模评估；
• □ PREF64变更纳入变更管理，DNS64与NAT64同步更新。

06 · 研究边界小结

• 本章机制描述以RFC 6144/6146/6147/6052/7050/6877/7915为准；运营商部署细节以官方披露为准，本课题不作未证实断言。
• 翻译技术治理的本质：用关键基础设施级的防护与审计，换取全网不再需要隧道——这是IPv6-only演进期最值得投入的安全工程。
• 下一页转入Happy Eyeballs与双栈路径安全——客户端路径选择行为的安全语义分析。

本节参考来源（第4页）

以下均为真实可查的权威来源，用于支撑本页事实性表述。