课题研究 IPv6演进安全 子课题06 · 第02页 / 共8页
06子课题 · IPv6-only演进安全实践与评估

IPv6-only演进安全实践与评估第02页：IPv6-only目标架构与翻译技术体系

IPv6-only不是简单的"关掉IPv4"，而是以翻译技术族（NAT64/DNS64/464XLAT、DS-Lite/lw4o6/MAP）承接残余IPv4依赖的目标架构重构。本页系统解构三种收敛形态（翻译接入型/翻译出口型/隧道承载型）的安全语义差异，给出翻译技术族完整RFC谱系（RFC 6144/6145→7915/6146/6147/6052/8215/6877/7050/8880/8781/6333/7596/7597/7599/7755/6296），深度剖析DNS64解析链的合成机理、三种部署模式的安全语义差异与DNSSEC冲突问题，梳理地址规划（PD、ULA、/64纪律、PREF64决策）与协议能力等价性边界。架构选择的每个决策点都直接决定后续安全基线的形态——翻译信任链的长度、网关单点位置、日志贯通方式在此页定型。

464XLATNAT64DNS64SIITDS-Litelw4o6MAP-T/ERFC 6052RFC 8215RFC 8781ipv4only.arpa研究状态：研究中
所属专题互联网基础设施安全 › IPv6演进安全
目标受众网络与安全架构师、IPv6演进负责人、SOC与蓝队、运营商/高校/企业网运维团队
全文结构8页：总览 → 目标架构 → 风险再评估 → 分层基线 → 兼容治理 → 成熟度评估 → 场景实践 → 治理路线
‹ 上页：第01页 研究总览与背景定位
子课题分页12345678
下页：第03页 安全收益与新增风险的再评估 ›

01 · IPv6-only的目标架构形态

1.1 三种收敛形态

实践中的IPv6-only并非单一形态，而是按"残余IPv4依赖的处理位置"分为三类收敛路径，安全语义各不相同：

收敛形态机理典型场景安全语义要点
形态A：翻译接入型（464XLAT）终端CLAT将本机IPv4流量翻译为IPv6，网络侧PLAT（NAT64）翻译回IPv4；DNS64合成AAAA引导纯IPv6应用走翻译路径移动运营商网络（T-Mobile美国为公开先例）、企业无线办公网信任链最长：DNS64合成→CLAT无状态翻译→PLAT有状态翻译；日志需贯通双翻译点才能溯源
形态B：翻译出口型（NAT64/DNS64）终端纯IPv6；出口NAT64网关统一翻译访问IPv4互联网；DNS64完成记录合成数据中心出口、校园网出口、固定宽带网关成为高价值单点；DNS64架构模式（递归侧合成/权威侧代答）决定投毒面大小
形态C：隧道承载型（DS-Lite/lw4o6/MAP家族）IPv4流量经隧道汇聚至运营商AFTR/MAP边界节点，由共享IPv4地址池翻译出口固定宽带运营商、有线电视网络隧道封装掩盖内层IPv4五元组，边界节点的解封与审计策略是治理核心

1.2 形态选择的决策要素

  • 终端能力：终端是否内置CLAT（Android自4.x时代起内置clatd类CLAT能力；iOS依赖应用层兼容与系统级DNS64支持——具体版本能力以厂商文档为准）决定形态A的可行性；纯IoT/哑终端环境常被迫保留双栈或采用形态B/C。
  • 地址资源：运营商侧IPv4地址枯竭程度决定翻译网关容量规划；464XLAT的PLAT共享地址池规模直接影响会话表容量与DDoS韧性。
  • 合规与溯源：翻译点日志留存（IPv6地址↔IPv4地址+端口映射、时间戳）是许多法域的合规要求，形态选择必须预判日志架构。
  • 故障域偏好：翻译型（A/B）故障影响"出网访问IPv4"；隧道型（C）故障影响"全部IPv4业务"——单点影响面评估应前置。
形态A（464XLAT）端到端数据面
两次翻译的关键控制点示意
依据RFC 6877（464XLAT）与RFC 6146（NAT64）机理绘制；DNS64（RFC 6147）负责引导不含CLAT能力的纯IPv6应用经同一PLAT访问IPv4资源。

02 · 翻译技术族谱系与RFC对照

IPv4/IPv6翻译与隧道承载构成一个完整的"标准族"，每个组件都有明确的现行RFC编号与废弃状态。下表为本课题维护的谱系对照（全部可在RFC Editor查证）：

技术核心RFC定位与要点状态/演进
翻译框架RFC 6144IPv4/IPv6翻译的总体框架与术语，定义有状态/无状态两类翻译现行（2011）
SIIT无状态翻译RFC 6145→RFC 7915IP/ICMP无状态翻译算法（IP/ICMP Translation Algorithm），464XLAT中CLAT侧与SIIT-DC的核心算法6145已被7915（2016）更新，引用时以7915为准
NAT64有状态翻译RFC 6146有状态IPv6/IPv4网络地址与端口翻译，464XLAT的PLAT侧现行（2011）
DNS64RFC 6147合成AAAA记录（将A记录内嵌IPv4地址并加前缀），支持exclude名单（RFC 6147定义 well-known 名单机制）现行（2011）；DNSSEC交互见第2.3节
IPv4嵌入式地址RFC 6052定义IPv4地址嵌入IPv6地址的格式族（/32../96共5种前缀长度）；知名前缀64:ff9b::/96仅限全局可达场景现行（2010）
本地使用前缀RFC 8215定义64:ff9b:1::/48本地使用前缀，避免与全局WKP混淆现行（2017）
464XLATRFC 6877CLAT+PLAT两次翻译方案，含与DNS64的协作规则现行（2013）
NAT64前缀发现RFC 7050＋RFC 8880客户端查询A记录发现NAT64前缀与翻译可用性；RFC 8880将查询域名规范为特殊用途域名ipv4only.arpa（同时更新了RFC 6147/7050相关用法）现行（2013/2020）
PREF64选项RFC 8781RA消息携带翻译前缀选项，客户端无需DNS探测即可获知PREF64现行（2020）
DS-LiteRFC 6333/6334IPv4-in-IPv6隧道＋运营商AFTR翻译；RFC 6334处理组播注意事项现行（2011）
lw4o6RFC 7596轻量级双栈过渡（共享v4地址的隧道+有状态翻译），降低AFTR状态压力现行（2015）
MAP-T / MAP-ERFC 7597/7599（7598为DHCPv6参数）基于算法规则共享v4地址的无状态/轻状态方案，消除集中式状态表现行（2015）
SIIT-DCRFC 7755/7756数据中心场景的无状态翻译与"双翻译"部署方案现行（2016）
NPTv6RFC 6296IPv6到IPv6无状态前缀转换现行但受限制：IAB（RFC 5902）与运营实践均不鼓励在IPv6-only目标架构中使用，仅在多归属地址不被接受等特殊场景审慎评估
IPv6-only偏好选项RFC 8925DHCPv4选项108，终端向网络声明"偏好IPv6-only"，是IPv6-mostly模式的开启信号现行（2020）
CE路由器IPv4aaS要求RFC 8585家庭/企业网关支持IPv4即服务（含464XLAT CLAT能力）的最低要求现行（2019）
NAT64/464XLAT部署指南RFC 8683面向运营商与企业网的NAT64/464XLAT补充部署指南（前缀规划、DNS协作、日志与排障）现行（2019）
IPv4aaS技术对比评估RFC 9313对DS-Lite/lw4o6/MAP-T/MAP-E/464XLAT等IPv4即服务技术方案的优缺点对比评估现行（2022）

引用纪律提示：技术文档引用SIIT算法时应标注RFC 7915而非已停用的RFC 6145；引用NAT64探测域名时应使用ipv4only.arpa（RFC 8880）而非早期草案或示例域名；WKP 64:ff9b::/96仅用于全局可达翻译（RFC 6052），内网场景应使用本地前缀64:ff9b:1::/48（RFC 8215）——三者混淆是IPv6-only地址规划中的高频错误。

03 · DNS64解析链深度解构

3.1 合成机制与解析路径

DNS64（RFC 6147）的工作机理：当IPv6-only客户端查询某域名AAAA记录且权威侧仅返回A记录时，部署了DNS64的递归解析器合成AAAA记录——将A记录中的IPv4地址按PREF64前缀（如64:ff9b::/96或网络自定义前缀）嵌入构造IPv6地址并返回。此后客户端向该合成地址发起连接，流量经NAT64完成翻译。关键推论：DNS64是翻译信任链的策略入口——它决定"哪些域名走翻译路径、以何种前缀走"，其配置正确性与防护强度直接决定全网IPv4可达性的安全基线。

3.2 DNS64架构模式与安全语义差异

部署模式机理安全语义
递归侧合成运营商/组织自有递归解析器执行合成（主流模式）合成面集中在可控递归，便于统一exclude名单与审计；但递归本身成为高价值目标，须纳入重点防护与变更管控
权威侧代答权威DNS直接发布合成AAAA（较少见，多用于受控区域）减少递归依赖，但合成记录全球可见、难以按接入网差异化；且权威侧承担额外构造责任
客户端本地合成主机获PREF64后自行合成（RFC 7050/8781）去中心化、无递归单点；但每客户端行为一致性差，故障定位复杂，监测可见性下降

3.3 必须正视的三个DNS64安全问题

  • DNSSEC冲突：合成AAAA记录无法通过DNSSEC端到端验证（原始A记录的签名不覆盖合成AAAA）。RFC 6147第6节讨论了该问题；工程对策包括仅对未签名区域合成、验证器侧合成（保留签名链）或明确接受"签名域不合成就失败"的行为——选择须由安全架构显式决策，而非默认。
  • exclude名单治理：RFC 6147定义了不应合成的域名名单机制（如已具备原生IPv6可达的域名），名单维护失效会导致"绕远翻译"或更糟的"错误翻译路径"，须纳入配置基线核查。
  • 探测域名依赖：客户端按RFC 7050探测ipv4only.arpa以确认NAT64可用性；若该探测被劫持或伪造应答（宣称无翻译可用），客户端将错误回退——该探测链必须纳入监测与演练。

3.4 PREF64发现机制对比

机制标准优点局限
DNS探测（查询ipv4only.arpa的A记录）RFC 7050/8880不依赖RA扩展，跨网络通用依赖DNS通路；探测结果被伪造/拦截的风险需治理
RA选项（PREF64）RFC 8781链路本地、无DNS依赖、可与其他RA配置联动依赖网络设备与终端支持度；链路欺骗面与RA同源（须RA-Guard防护）
手工/策略下发（企业NAC、MDM）运营实践确定性强、可审计运维成本高，仅适合受管终端
综合发现流程（主机侧）RFC 98722025年发布的综合指南，明确推荐主机在可用时优先从RA选项（RFC 8781）获取翻译前缀，并与探测结果交叉验证现行（2025），新部署应遵循

04 · IPv6-only地址规划与编号要点

  • 前缀获取与委托：站点应通过DHCPv6前缀委托（PD，RFC 8415）或归属运营商分配获得可聚合前缀，避免动态地址依赖NAT式的隐性"地址复用"思维；下游子网分配应遵循可汇聚、可溯源原则。
  • ULA的定位：唯一本地地址（RFC 4193，fc00::/7）适合内部基础设施互访（管理网、带外网），不得作为访问IPv4互联网的翻译源地址（翻译前缀须用GUA或RFC 6052/8215定义的前缀体系）；ULA与GUA混用须经地址选择策略（RFC 6724）显式管理。
  • /64纪律：按RFC 8200，链路最小MTU语境下/64是SLAAC的前提；移动场景下"3GPP接口/64前缀扩展至局域网"由RFC 7278规范。偏离/64（如/65、/127点到点）会破坏SLAAC与DAD，仅在明确无SLAAC需求的链路审慎使用。
  • 翻译前缀规划：PREF64选择应在RFC 6052（全局WKP）与RFC 8215（本地前缀）之间显式决策并文档化；禁止手工拼造语义不明的"类ff9b"前缀——地址语义混乱将直接污染日志、ACL与威胁检测规则。
  • 嵌入式地址的可读性：IPv4嵌入式地址使日志中可直接读出目标IPv4地址（如64:ff9b::0102:0304对应1.2.3.4），审计与溯源应利用该特性自动化提取，而非丢弃该结构信息。

05 · 与IPv4功能等价性的边界

IPv6-only收敛必须正视"协议能力不对等"清单——以下IPv4能力在翻译路径上不存在或严重受限，须逐一业务评估：

能力IPv6-only下的状态治理建议
入站连接（公网可达服务）NAT64映射公网IPv4入站到内网的能力受限；DNS64合成仅面向出方向入站服务保留双栈或独立IPv4出口；明确"出网翻译、入网例外"策略
IPsec端到端保护NAT64破坏端到端IPsec（AH完全不可行；ESP受端口映射影响）敏感业务迁IPv6原生IKEv2/IPsec；或改用TLS层保护
组播/广播依赖业务翻译技术不承载组播（DS-Lite组播由RFC 6334专门处理）；IPv4广播无等价物识别组播依赖清单（媒体流、行情推送等），专项迁移
ALG敏感协议（FTP/SIP等）应用层网关在翻译路径上能力不一致，行为难以预测优先协议现代化（FTP→SFTP/HTTPS，SIP over IPv6原生）
P2P/游戏直连NAT64端口分配策略影响直连成功率；对称型映射使打洞困难终端能力探测、IPv6原生P2P改造
分片与大MTU路径翻译减小了有效MTU；PMTUD依赖ICMPv6 Packet Too Big全程可达网关默认安全MTU策略＋PMTUD黑洞监测（第4、6页）

架构决策输出物：组织在实施IPv6-only前，应完成《协议能力等价性评估表》与《残余IPv4依赖清单》两份文档，作为收敛范围（哪些网段先收敛、哪些业务例外保留双栈）的正式决策依据——这是第8页"六步实施路线"中第二步的前置输入。

本节参考来源（第2页）

[1]

IETF RFC 6144（翻译框架）、RFC 6145（SIIT，已被RFC 7915更新）、RFC 7915（2016）：rfc-editor.org/rfc/rfc7915、rfc-editor.org/rfc/rfc6144。

[2]

IETF RFC 6146（NAT64）、RFC 6147（DNS64）：rfc-editor.org/rfc/rfc6146、rfc-editor.org/rfc/rfc6147。

[3]

IETF RFC 6052（IPv4嵌入式地址/WKP）、RFC 8215（本地使用前缀64:ff9b:1::/48）：rfc-editor.org/rfc/rfc6052、rfc-editor.org/rfc/rfc8215。

[4]

IETF RFC 6877（464XLAT）、RFC 7050（NAT64前缀发现）、RFC 8880（ipv4only.arpa）、RFC 8781（PREF64 RA选项）：rfc-editor.org/rfc/rfc6877、rfc-editor.org/rfc/rfc8781。

[5]

IETF RFC 6333/6334（DS-Lite）、RFC 7596（lw4o6）、RFC 7597（MAP-T）、RFC 7598（MAP DHCPv6参数）、RFC 7599（MAP-E）：rfc-editor.org/rfc/rfc6333、rfc-editor.org/rfc/rfc7597。

[7]

IETF RFC 8925（IPv6-only偏好选项）、RFC 8585（CE路由器IPv4aaS要求）、RFC 8683（NAT64/464XLAT部署指南）、RFC 9313（IPv4aaS技术对比评估）、RFC 9872（地址合成前缀发现建议）：rfc-editor.org/rfc/rfc8925、rfc-editor.org/rfc/rfc9313、rfc-editor.org/rfc/rfc9872。

[6]

IETF RFC 7755/7756（SIIT-DC）、RFC 6296（NPTv6）、RFC 5902（IAB关于IPv6 NAT的思考）、RFC 7157（无NAT多归属）：rfc-editor.org/rfc/rfc7755、rfc-editor.org/rfc/rfc5902。

[7]

IETF RFC 7278（3GPP接口/64前缀扩展至LAN）、RFC 8415（DHCPv6，含前缀委托）、RFC 4193（ULA）、RFC 6724（地址选择）：rfc-editor.org/rfc/rfc7278、rfc-editor.org/rfc/rfc8415。

‹ 上页：第01页 研究总览与背景定位
子课题分页12345678
下页：第03页 安全收益与新增风险的再评估 ›