IPv6-only演进安全实践与评估第05页：应用与协议兼容性治理

01 · 兼容性障碍分类学

苹果2015年WWDC宣布自2016年6月起App Store应用必须支持IPv6-only网络（含NAT64/DNS64环境），是兼容性治理进入主流视野的标志事件——它揭示了双栈环境掩盖的大量隐性IPv4依赖。本课题将兼容性障碍归纳为六类：

02 · 客户端协议栈行为：收敛环境连接决策

2.1 Happy Eyeballs在IPv6-only语境下的行为要点

Happy Eyeballs（RFC 8305，取代RFC 6555）在双栈环境并行竞速v4/v6连接；在IPv6-only环境（配合DNS64）其规则简化为：优先使用原生IPv6地址；当仅有合成AAAA（DNS64产物）时，尝试合成地址经翻译路径连接，失败后可按实现策略重试。安全与工程启示：①合成地址应被客户端正确识别为"较低优先级/可回退"路径，应用不应将其失败永久缓存（E6类障碍的机理根源）；②DNS64合成策略变化（如exclude名单更新）会改变客户端连接路径，网络侧变更须评估对存量客户端行为的影响。

2.2 PvD与多提供域（RFC 7556）

多提供域（Provisioning Domain）机制使主机可区分来自不同RA/配置源的网络信息——在IPv6-only校园网/企业网存在多归属（生产网＋访客网＋物联网专网）时，PvD帮助终端避免"混用配置"（如访客终端误用生产网RDNSS）。PvD的部署使收敛态下的配置边界更清晰，建议多网段环境评估启用。

2.3 CLAT终端行为

2.4 IPv6-mostly与RFC 8925：粒度化的收敛信号

IPv6-mostly是介于双栈与IPv6-only之间的精细过渡形态：终端通过DHCPv4选项108（RFC 8925）向网络声明"偏好IPv6-only"，网络据此为单栈就绪终端停止下发IPv4地址、为未就绪终端保留IPv4——收敛节奏从"网段粒度"细化到"终端能力粒度"。对安全治理的意义：①攻击面收缩可按终端就绪度渐进推进，降低"一刀切"收敛的兼容性回退风险；②选项108宣告行为本身须纳入终端审计（伪造宣告或宣告静默失效都会影响策略一致性）；③IPv4aaS各技术路线的取舍可参照RFC 9313的对比评估，避免为"形态正确"选择维护成本过高的翻译方案。该机制可与第8页六步路线中"试点网段"步骤组合使用，作为单栈就绪终端的先行收敛手段。

03 · 兼容性检测方法体系

NAT64/DNS64 最小测试床参考拓扑（概念示意）
┌─────────┐   ┌──────────────┐   ┌─────────────┐   ┌──────────┐
│ 被测终端 │──▶│ DNS64递归    │──▶│ NAT64网关   │──▶│ IPv4目标  │
│ (v6-only)│   │ (合成+名单)  │   │ (PREF64)    │   │ 服务集群  │
└─────────┘   └──────────────┘   └─────────────┘   └──────────┘
验收流量集：①纯v6目标（原生AAAA）②仅v4目标（合成AAAA路径）
          ③exclude名单域名（不应合成）④DNSSEC签名域名（按既定策略）
          ⑤CLAT承载的v4-only应用 ⑥大报文/分片路径（PMTUD验证）

04 · 特殊协议问题清单

05 · 应用改造清单与验收标准

验收标准对齐苹果App Store IPv6-only审核要求与IETF相关最佳实践；组织可据业务风险增设等保/行业附加项。

本节参考来源（第5页）