过渡技术是什么
从 IPv4 到 IPv6 不是一次性切换，而是一段长期共存的过程。最稳的默认做法是双栈：网络与主机同时承载两种协议，应用按 RFC 8305 的 Happy Eyeballs 并行发起连接、择快使用。当只有 IPv6 的客户端要访问只有 IPv4 的服务时，用 NAT64 配合 DNS64 做协议转换；早期还有各种把 IPv6 报文封装进 IPv4 的隧道方案，如今多用于特定互联与运营商场景。
基本信息
| 推荐默认做法 | 双栈共建，两种协议同时可用 |
|---|---|
| 客户端择路 | Happy Eyeballs（RFC 8305）并行尝试 |
| 跨协议访问 | NAT64 转换加 DNS64 合成 AAAA |
| 隧道方案 | 把一种协议封装在另一种里，用于过渡互联 |
| 必要配套 | AAAA 记录、防火墙双栈策略、双栈健康检查 |
技术对照
| 技术 | 原理 | 适用场景 |
|---|---|---|
| 双栈 | 同一接口同时跑 v4 与 v6 | 推荐默认做法 |
| NAT64 / DNS64 | 让纯 v6 客户端访问 v4 目标 | 运营商与云迁移 |
| 6in4 / GRE 隧道 | 把 v6 包封进 v4 传输 | 过渡期互联 |
| 464XLAT | 在客户端侧做转换 | 移动网络 |
| 6rd | 运营商把 v6 前缀与用户 v4 地址绑定后隧道传输 | 运营商早期部署 |
测试与验证
测试与验证
curl -6 -sI https://example.com | head -1 # 单独走 v6
curl -4 -sI https://example.com | head -1 # 单独走 v4
ping6 -c 2 2400:3200::1 # 典型公共 v6 地址
ss -tln | grep -E '\[::\]|:::' # 确认服务监听在 v6 地址上典型使用场景
- 对外服务发布前的准入检查：v4 与 v6 两条链路都要端到端验证
- 负载均衡与 CDN 配置：确认后端池与健康检查覆盖两种协议
- 安全策略同步：防火墙、WAF 与限速规则在 v6 侧同样存在，不能只配 v4
- 日志与审计：确认访问日志记录了真实来源地址，转换场景下注意源地址形态变化
- 应用兼容性：检查代码里对地址字面量的解析、存储与去重逻辑是否支持冒号格式
Happy Eyeballs 让客户端并行尝试两种协议并择快使用，这意味着两条链路都必须真正可用。若 v6 只做到「能解析不能通」——例如 AAAA 记录已发布但防火墙未放行——客户端会先尝试 v6、超时后才回退，用户体验反而是变慢，而不是走 v4 正常。