01 · 研究背景与意义
1.1 从"要不要IPv6"到"何时收敛为IPv6-only"
IPv6规模部署正在全球进入深水区。Google官方IPv6采纳度统计显示，2025年全球约43%—47%的用户访问经由IPv6完成，2026年3月28日单日占比首次突破50%；CNNIC第55次《中国互联网络发展状况统计报告》（2025年1月发布）显示，截至2024年12月我国IPv6活跃用户数达8.22亿；《中国IPv6发展报告（2026）》显示，截至2025年12月我国IPv6活跃用户数达8.69亿，移动网络IPv6平均流量占比达70.85%、固定网络达32.38%。在此背景之下，一个结构性问题浮出水面：当IPv6流量占比越过某个临界点，继续为日渐萎缩的IPv4流量维护一整套独立的路由、安全策略、地址管理与排障体系，其成本将高于收益——IPv6-only（单栈IPv6）从早期的"激进实验"转变为规模运营者眼中的"务实收敛路线"。2023年中央网信办、国家发展改革委、工业和信息化部联合印发的《深入推进IPv6规模部署和应用两年行动计划（2024—2025年）》已将"IPv6-only试点取得积极成效"列为目标之一；IETF v6ops工作组持续收录全球IPv6-only部署案例，表明该路线已获得国际工程社区的广泛实践积累。
1.2 演进三阶段模型
- 阶段一：双栈共存（长期态）。IPv4/IPv6双协议栈并行运行，网络与主机同时维护两套配置。该阶段的主要安全问题是双栈等价性失衡——IPv6侧防护与审计覆盖落后于IPv4侧（对应子课题01、03）。
- 阶段二：双栈优选（过渡期）。Happy Eyeballs（RFC 8305，取代RFC 6555）成为客户端连接竞速的事实标准，流量逐渐向IPv6倾斜，但IPv4兜底链路依然存在。该阶段的主要安全问题是竞速与回退行为对静态安全策略的扰动。
- 阶段三：IPv6-only收敛（目标态）。新接入网络或新业务仅启用IPv6，经翻译技术（NAT64/DNS64/464XLAT，详见第2页）访问残余IPv4资源。该阶段安全问题从"两套攻击面"转化为"高度集中的单栈信任链"——这正是本子课题的核心研究对象。
1.3 为什么IPv6-only是独立研究对象
IPv6-only并非"把IPv6侧留下、把IPv4侧关掉"这么简单。其一，绝大多数现存业务与互联网资源仍有IPv4依赖，收敛必须借助翻译技术族完成，而翻译链路本身构成新的信任边界与安全故障域；其二，单栈化消除了"选弱栈攻击"的双栈等价性问题，却把安全性高度集中于邻居发现协议（NDP）防护、DNS64/翻译信任链、ICMPv6治理三个支点，任一支点失效的影响面大于双栈时代；其三，IPv6-only使主机地址模型、应用兼容性行为（Happy Eyeballs竞速、CLAT合成地址）发生可观测的变化，传统监测与审计手段需要重新校准。因此，本子课题与子课题03（双栈与过渡技术安全）构成"演进两端"的对偶研究：03研究"如何安全地共存"，06研究"如何安全地收敛"。
02 · 事实勘误与高危误配置认知
为什么把"误配置认知"放在总览位置：IPv6-only演进中的多数安全事故并非源于高深攻击，而是源于对翻译技术语义、协议栈行为的系统性误解。以下说法在工程实践中反复出现，均被RFC标准或公开实践明确证伪。本课题全部章节以RFC原文与官方文档为唯一事实依据。
| 流传说法 | 事实与依据 |
|---|---|
| "IPv6-only就是不用任何过渡技术" | 错误。在IPv4资源长期残余的现实下，IPv6-only网络访问IPv4互联网依赖翻译技术（NAT64/DNS64/464XLAT等，RFC 6146/6147/6877）。IPv6-only改变的是"主机与接入网"的协议形态，而非"全网不再需要协议转换"。混淆两者会导致对翻译网关安全边界的忽视。 |
| "NAT64和家里的NAT44一个性质，有经验直接照搬" | 错误。IETF在RFC 5902（2010，IAB关于IPv6网络地址转换的思考）中明确提示：翻译/转换机制改变了端到端模型的安全语义。NAT64将IPv4目的地址编码进IPv6地址（RFC 6052），与DNS64合成记录联动（RFC 6147），形成"域名→合成AAAA→翻译映射"的复合信任链，其日志留存、会话审计与攻击面均不同于无状态或少状态的NAT44/NAPT。 |
| "关掉双栈后，Rogue RA之类的问题就消失了" | 错误且危险。Rogue RA（RFC 6104）攻击的是NDP/SLAAC信任模型（RFC 4861/4862），与是否双栈无关。IPv6-only网络中主机获取的全部配置权威（默认路由、DNS、前缀）都来自RA——链路欺骗的后果不是"变弱"而是"更加集中"：一次成功的RA投毒可同时劫持转发与解析路径。 |
| "DNS64只是DNS团队的活儿，安全不用管" | 错误。DNS64合成记录直接决定客户端访问IPv4资源的翻译路径，是翻译信任链的入口：DNS64被投毒或故障，全部IPv4可达性随之异常；且合成记录破坏DNSSEC端到端签名验证（RFC 6147第6节讨论），安全团队必须参与其部署架构设计（递归侧合成vs权威侧代答等模式的取舍）。 |
| "应用能在双栈环境跑，进IPv6-only环境就天然没问题" | 错误。苹果自2016年起要求App Store应用必须支持IPv6-only网络（含NAT64/DNS64环境），恰恰说明大量应用存在IPv4字面量、IPv4 API、地址族假设等隐性依赖。双栈环境下这些缺陷被IPv4兜底掩盖，单栈化后立即暴露（详见第5页兼容治理）。 |
03 · 研究目标与关键问题
- 架构目标：系统解构IPv6-only目标架构的协议组件与信任边界，形成"架构组件—安全语义—基线控制"三元对照表（第2、4页）。
- 风险目标：定量定性结合地刻画IPv6-only的安全收益（攻击面收敛、策略一致性）与新增风险（NDP单点化、翻译信任链、隐私—审计张力），输出再评估模型（第3页）。
- 兼容目标：建立应用与协议兼容性障碍分类学、检测方法与改造验收标准，服务"先兼容、后收敛"的实施纪律（第5页）。
- 评估目标：构建"部署度—安全度—运行度"三维度成熟度评估框架，与国家政策指标（移动网络IPv6流量占比70%目标等）对标衔接（第6页）。
- 实践目标：研究移动运营商、高校校园网、数据中心/企业内网、物联网四类场景的公开实践，提炼可迁移的经验与教训（第7页），汇总为六步实施路线与分层核查基线（第8页）。
3.1 三个关键研究问题（KQ）
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 风险再集中化的可观测性 | 单栈化之后，原先分散在双栈两侧的风险集中于NDP防护、DNS64/翻译信任链、ICMPv6治理三支点——这些支点的失效模式能否被现有监测体系完整覆盖？需要新增哪些遥测指标与演练科目？ | 第3、4页 |
| KQ-2 | 翻译信任链的量化评估 | "DNS64合成正确性、翻译映射一致性、前缀可信性"构成的信任链如何被量化评估与持续校验？464XLAT双翻译（CLAT+PLAT）场景下，端到端一致性验证的自动化方法是什么？ | 第2、3、5页 |
| KQ-3 | 成熟度指标的效度 | "部署度—安全度—运行度"三维指标能否真实预测演进风险（而非沦为形式化打分）？指标如何自动采集、如何避免口径漂移？ | 第6页 |
04 · 生态参与方与演进时间线
4.1 生态参与方与职责
| 角色 | 在IPv6-only演进中的职责/产出 | 代表 |
|---|---|---|
| 标准组织 | 翻译技术族、IPv6-only运营要求的规范化与废弃治理 | IETF 6man/v6ops；RFC 6146/6147/6877/9099、RFC 8504等 |
| 操作系统与终端厂商 | CLAT/464XLAT客户端能力、IPv6-only下的协议栈行为 | Android内置CLAT能力（clatd，自4.x时代起）；iOS自2016年起强制应用支持IPv6-only环境（App Store审核要求） |
| 运营商 | 移动网络IPv6-only+464XLAT规模化部署的先行者，产出大量公开实践 | T-Mobile美国自2014年前后起在LTE网络规模化部署IPv6-only＋464XLAT（IETF/业界会议公开分享，表述为约数） |
| 大型互联网企业 | 数据中心与办公内网IPv6-only化实践 | Google（内部网络长期IPv6化并公开发表实践）、Facebook（2018年前后公开分享数据中心IPv6-only实践）、LinkedIn（2020年前后公开IPv6-only推进经验）——均为公开演讲/博客层面的描述，具体规模以各公司官方披露为准 |
| 测量与治理机构 | 部署度监测、政策基线、能力评估 | CNNIC国家IPv6发展监测、中国信通院、APNIC Labs、Google IPv6 Statistics |
4.2 领域演进关键时间线
| 时间 | 事件（均可公开查证） |
|---|---|
| 2010—2011 | IAB发布关于IPv6地址转换的思考（RFC 5902，2010）；IPv4/IPv6翻译框架（RFC 6144）、无状态翻译SIIT（RFC 6145，2016年被RFC 7915更新）、有状态NAT64（RFC 6146）、DNS64（RFC 6147）相继标准化，翻译技术族成型 |
| 2011—2013 | DS-Lite标准化（RFC 6333/6334，2011）；464XLAT标准化（RFC 6877，2013）；NAT64前缀发现（RFC 7050，2013）；IPv4嵌入式地址与知名前缀（RFC 6052，2010） |
| 2013—2016 | 464XLAT进入规模商用（T-Mobile美国移动网络IPv6-only演进，公开会议分享，约2014年起）；多归属架构（RFC 7157，2014）；轻量级翻译lw4o6（RFC 7596）、MAP-T/MAP-E（RFC 7597/7599，2015） |
| 2015—2016 | 苹果WWDC 2015宣布App Store应用须支持IPv6-only网络（2016年6月起实施），客户端生态兼容性治理全面启动 |
| 2017—2020 | 本地使用前缀64:ff9b:1::/48（RFC 8215，2017）；ipv4only.arpa特殊用途域名（RFC 8880，2020）；RA中携带PREF64选项（RFC 8781，2020）；SIIT-DC数据中心方案（RFC 7755/7756，2016）；IPv6节点要求（RFC 8504，2019）；Happy Eyeballs v2标准化（RFC 8305，2017）；DHCPv4携带IPv6-only偏好选项（RFC 8925，2020） |
| 2021—2023 | IPv6运营安全考虑汇总（RFC 9099，2021；扩展头运营影响见RFC 9098）；企业IPv6部署指南（RFC 9386，2023）；IPv4即服务过渡技术对比评估（RFC 9313，2022）；中国《深入推进IPv6规模部署和应用两年行动计划（2024—2025年）》（2023年，含IPv6-only试点目标）；工业和信息化部等八部门《关于推进IPv6技术演进和应用创新发展的实施意见》（2023年） |
| 2024—2026 | 6to4任播中继废弃（RFC 7526）后，受管网络应禁用6to4/Teredo/ISATAP自动隧道（RFC 7123运营建议；Teredo无专门废弃RFC，表述以RFC原文为准）；IPv6-only从"先锋实践"进入"规模化前夜"——2025年末移动网络IPv6流量占比70%目标已实现（国家IPv6发展监测平台：70.85%）；《深化互联网协议第六版（IPv6）技术创新和融合应用实施方案（2026—2030年）》（中央网信委2026年7月印发）提出到2030年"加快向IPv6单栈演进"，雄安IPv6单栈部署行动同期启动 |
05 · 术语速查与常见误区
| 术语 | 释义 |
|---|---|
| IPv6-only | 网络接入与转发仅启用IPv6协议栈的形态；经翻译技术访问残余IPv4资源。注意与"全网无翻译"概念区分（见勘误） |
| 464XLAT（RFC 6877） | 两次翻译方案：客户端侧CLAT（IPv4→IPv6无状态翻译）+网络侧PLAT（NAT64有状态翻译），使仅支持IPv4的应用在IPv6-only网络中运行 |
| CLAT / PLAT | 464XLAT中的客户端翻译组件与网络侧翻译组件；PLAT即NAT64网关 |
| DNS64（RFC 6147） | 为仅含A记录的域名合成AAAA记录（内嵌IPv4地址），引导IPv6-only客户端走翻译路径 |
| PREF64（RFC 8781） | RA消息中携带的"用于IPv4/IPv6翻译的IPv6前缀"选项，使客户端可发现网络部署的NAT64前缀 |
| ipv4only.arpa（RFC 8880） | IANA预留的特殊用途域名，客户端按RFC 7050查询其A记录以发现NAT64前缀及可用性 |
| WKP / 本地前缀 | 知名前缀64:ff9b::/96（RFC 6052）与本地使用前缀64:ff9b:1::/48（RFC 8215），用于构造IPv4嵌入式IPv6地址 |
| SIIT / SIIT-DC | 无状态IP/ICMP翻译算法（RFC 6145，经RFC 7915更新）；SIIT-DC（RFC 7755/7756）面向数据中心的扩展方案 |
| DS-Lite / lw4o6 / MAP | 面向固定/移动运营商的隧道+翻译家族：DS-Lite（RFC 6333/6334）、轻量级lw4o6（RFC 7596）、MAP-T（RFC 7597）与MAP-E（RFC 7599） |
| PvD（RFC 7556） | 多提供域机制：主机可区分不同网络提供域的配置（如多个RA来源），支持多归属与受控策略选择 |
| Happy Eyeballs（RFC 8305） | 双栈连接竞速算法，取代RFC 6555；在IPv6-only环境中其"合成地址优先级"等规则影响应用连接路径 |
| 成熟度评估（本课题） | "部署度—安全度—运行度"三维度五级量表，用于度量组织IPv6-only演进准备度与收敛质量（第6页） |
术语使用纪律：本课题严格区分"IPv6-only（单栈形态）""翻译技术（协议转换手段）""双栈（双协议栈形态）"三个概念；凡引用数据均标注来源与统计口径，"约"字表述为区间或约数；涉及企业部署规模的内容一律注明"以官方披露为准"，避免将会议演讲中的个案数据外推为行业结论。
06 · 研究范围与合规边界
- 对象范围：IPv6-only目标架构及其翻译信任链的安全基线、应用兼容治理、成熟度评估与场景实践；覆盖移动接入网、固定宽带、校园网、数据中心与企业内网、物联网四类典型环境。
- 深度边界：做到"架构解构＋风险再评估＋基线治理＋成熟度评估"层面；具体设备渗透测试方法、应用层代码改造指南、无线网络专项安全不在本子课题范围。
- 协同边界：翻译技术族各协议的攻击面机理继承自子课题03；NDP/RA防护机制细节属子课题02；本子课题聚焦"收敛形态下"这些机制的集成基线与评估方法，不重复展开单点机理。
- 时效声明：所引RFC均为现行有效版本（RFC 6145已被RFC 7915更新、6to4/Teredo已废弃等状态变化均已注明）；政策文件以正式发布文本为准。
合规与伦理声明：①本课题为防御研究，遵守《网络安全法》《数据安全法》《个人信息保护法》及相关测评规范；②文中攻击链路仅在概念层面描述原理与检测思路，不提供可直接复用的攻击配置；③主动探测、兼容性压测与演练活动应限定于自有或获得书面授权的网络环境；④涉及企业案例的描述均来自公开演讲、官方博客或标准会议记录，不构成对任何厂商的商业评价。
07 · 与课题体系的协同关系
| 协同子课题 | 数据/方法交换内容 |
|---|---|
| 01 IPv6攻击面与威胁建模 | 本子课题复用其攻击面清单与STRIDE适配规范，聚焦"收敛形态"子集；反向输出IPv6-only架构下风险再集中化的实证材料，充实其威胁本体 |
| 02 NDP安全与防护 | NDP防护（RA-Guard/SAVI）在单栈形态下从"双栈之一"升格为"唯一信任根基"，本子课题输出全端口覆盖、RDNSS受控使用等收敛态配置基线，为其防护效能评估提供目标环境定义 |
| 03 双栈与过渡技术安全 | 对偶关系：03研究共存期风险，本子课题研究收敛期风险；共享翻译技术（NAT64/DNS64/464XLAT）的安全语义分析，本子课题将其转化为收敛态治理基线 |
| 04 地址空间测绘与态势感知 | IPv6-only下影子资产治理依赖其测绘方法；本子课题的成熟度"安全度"指标引用其资产台账口径，反向提供"收敛后资产边界清晰化"的验证场景 |
| 05 扩展头与分片安全 | 翻译网关的扩展头/分片处理一致性直接继承其设备基线结论；IPv6-only报文路径更单一，为其"中间设备一致性测试"提供更干净的测量环境 |
08 · 预期成果与交付物
- 《IPv6-only目标架构与翻译信任链白皮书》（组件—安全语义—基线三元对照表，第2页）
- 《IPv6-only安全收益—风险再评估报告》（含STRIDE矩阵、翻译链路攻击树、失效模式分析，第3页）
- 《IPv6-only分层安全基线v1.0》（五层、42个可核查配置项，第4页）
- 《应用兼容性障碍清单与验收标准》（六类障碍、检测方法、改造验收表，第5页）
- 《IPv6-only成熟度评估工具包》（三维度指标定义、自动采集规范、L1—L5评分卡，第6页）
- 《重点场景实践研究报告》与《六步实施路线》（第7、8页）
本节参考来源（第1页）
以下均为真实可查的权威来源（IETF RFC官方档案、政府部门公开文件、权威统计机构），用于支撑本页事实性表述。
IETF RFC 8200（IPv6标准，2017）：rfc-editor.org/rfc/rfc8200；RFC 8504（IPv6节点要求，2019）：rfc-editor.org/rfc/rfc8504。
IETF RFC 9099（IPv6网络运营安全考虑，2021）：rfc-editor.org/rfc/rfc9099；RFC 9098（IPv6扩展头运营影响，2021）：rfc-editor.org/rfc/rfc9098；RFC 9386（企业IPv6部署指南，2023）：rfc-editor.org/rfc/rfc9386。
IETF RFC 6146（NAT64）、RFC 6147（DNS64）、RFC 6877（464XLAT）、RFC 7050（NAT64前缀发现）、RFC 8880（ipv4only.arpa）：rfc-editor.org/rfc/rfc6877、rfc-editor.org/rfc/rfc7050、rfc-editor.org/rfc/rfc8880。
IETF RFC 5902（IAB关于IPv6 NAT的思考，2010）：rfc-editor.org/rfc/rfc5902；RFC 7157（无NAT的IPv6多归属，2014）：rfc-editor.org/rfc/rfc7157；RFC 7556（PvD，2015）：rfc-editor.org/rfc/rfc7556；RFC 8305（Happy Eyeballs v2，2017）：rfc-editor.org/rfc/rfc8305。
中央网信办、国家发展改革委、工业和信息化部《深入推进IPv6规模部署和应用两年行动计划（2024—2025年）》（2023年）：cac.gov.cn；工业和信息化部等八部门《关于推进IPv6技术演进和应用创新发展的实施意见》（2023年）：miit.gov.cn。
CNNIC第55次《中国互联网络发展状况统计报告》（2025年1月，IPv6用户约8.22亿）：cnnic.cn；Google IPv6 Statistics（2025年约43%—47%区间）：google.com/intl/en/ipv6/statistics.html；APNIC Labs：labs.apnic.net。
Apple Developer关于支持IPv6-only网络的应用要求（WWDC 2015宣布，2016年6月起实施）：developer.apple.com。