作者：吴灵晓(盖优)

演进路线

阶段一（2020 年末）

本阶段完成线上所有服务的 IPv6 改造，全面支持 IPv6 双栈的访问支持；融入阿里云的 IPv6 生态体系，内网环境全面支持 IPv4/IPv6 双栈；提升用户端侧 IPv6 流量占比，IPv6 流量占比不低于总量的 40%。

• 管：全面完成优酷主站广域网、集团级数据中心核心网络、互联网出口 IPv6 网络改造，IPv6 在多地域多运营商开通。汰换无法通过升级支持 IPv6 的核心路由器，交换机。建立 CDN 专属资源池，全部选用支持 IPv4/IPv6 的 CDN 节点。引入 IPv6-only 的专线链路，适时降低 IPv6 接入成本；

• 云：全面完成企业互联网域名服务器 IPv6 改造，支持 AAAA 记录和 IPv6 域名解析请求，主要核心业务域名全部配置 A 及 AAAA 记录。使用阿里云 HTTPDNS 服务，支持移动端的 IPv4/IPv6 双栈及 IPv6-only 环境下的域名解析能力。优酷相关的服务及接口全面上云，新增的 ECS，CDN 等资源全部选用支持 IPv6 区域的资源产品；

• 端：各手机端应用 APP 以及 web 浏览器端全部支持 IPv4/IPv6 双栈及 IPv6-only 环境下的网络通信能力。尝试引入用户功能体验引导方案，让用户可以直观地体验到 IPv6 带来的收益。端侧测试 IPv6 流量占比不低于总量的 40%；

• 安全：全面完成优酷互联网出口安全防护系统的 IPv6 改造，应用内的安全防护插件全面支持 IPv6 环境，确保整体安全防护能力不下降。建立 IPv6 下独立的监控体系，覆盖基础监控及应用监控，具备和 IPv4 相同的监控能力。

阶段二（2021-2022 年）

本阶段全面支持 IPv6-only 的访问支持；全部融入阿里云的 IPv6-only 生态体系，内网环境全面支持 IPv6-only 双栈；IPv6 双栈+only 比例不低于 80%， IPv6 流量占比不低于总量的 60%。

• 管：全面完成主站机房及 CDN 节点机房的 IPv6 出口改造，包括所有内地以及热门海外节点。IPv6 流量全面跑在专用链路上，全面实现 IPv6 下的流量收益能力；

• 云：全面完成企业互联网域名服务器 IPv6 改造，支持 AAAA 记录和 IPv6 域名解析请求，所有业务域名全部配置 A 及 AAAA 记录。优酷相关的服务及接口全部使用 IPv6 环境的资源产品，内部网络环境全部切换到 IPv4/IPv6 双栈模式；

• 端：全端全站支持 IPv6-only 访问，用于体验无差异化。用户产品体验设计上全面倾向 IPv6，引导用户汰换老设施老终端。IPv6 双栈用户比例不低于 80%，并逐步引导 IPv6-only 模式；

• 安全：进一步强化 IPv6 的网络安全能力，全面提升防护等级，及时发现并解决 IPv6 环境下衍生出的新业务形态的安全挑战。对边缘计算、物联网、车联网、云游戏等新领域，具备全网同等级别的安全保障能力。

阶段三（2023-2025 年）

本阶段全面完成所有机房及 CDN 节点的改造，全部支持 IPv6-only 的访问；IPv6-only 比例不低于 80%， IPv6 流量占比不低于总量的 80%。

• 管：全面完成 IPv6-only 改造；

• 云：全部使用云上产品，所有产品都支持 IPv6-only；

• 端：IPv6-only 比例不低于 80%，淘汰双栈模式。对不足 20%的 IPv4 用户提供最小功能集的降级服务，鼓励升级到 IPv6-only；

• 安全：进一步强化 IPv6-only 场景下的安全防护、安全监管、灾难备份与恢复等能力，提升 IPv6 环境下娱乐网、物联网、车联网、云计算、云游戏、VR/AI 智能等领域安全保障能力。

实施指南

网络

机房互联网出口

建设改造中心机房 IPv6 互联网出口

跟随阿里集团整体节奏，核心服务所在的中心机房全部完成互联网出的改造，支持 IPv6。在五大城网出口所在地的中心机房，全部完全 IPv6 改造。优先选用 BGP 对接方式，方便互联网出口域内域外路由协议的统一规划。提前做好 IPv6 降费提速准备，优先调度 IPv6 流量，提高 IPv6 流量令牌优先级，在同等环境下优先路由。

建设改造 CDN 节点机房 IPv6 互联网出口

由阿里云进行统筹安全改造地域与时间节点，业务同步做好按地域引流工作。

改造升级骨干网 VIP+LVS

替换不支持通过升级支持 IPv6 的老旧设施，包括大量的核心路由器，交换机及负载均衡设备。对互联网出口部分的硬件防火墙、入侵检测设备等安全防护设备进行更新，不支持更新进行替换。优化路由配置，路由配置及缓存使用配比，使改造后的 IPv4 网络性能不下降的同时，IPv6 网络性能略优于 IPv4。各安全防护能力达到与 IPv4 出口等同或者优于 IPv4 环境下的防护能力。

改造升级应用服务测试环境

通过隧道方式打通生产机房与测试机房之间的 IPv6 链路，升级企业跳板机代理服务器支持 IPv6，支持 IPv6 环境下登录测试环境满足业务需求。

改造企业园区网络 VPN 系统

携同阿里企业智能网团队进行 IT 办公网络的改造，接入 IPv6 互联网出口，升级园区内路由器交换机以及 VPN 设备。升级 VPN 客户端，支持 IPv6 环境下的用户远程登录，完善远程接入环境 IPv6 安全防护策略，强化 IPv6 安全防护能力。

域名解析 DNS/HTTPDNS 及回落

业务域名网络双栈设计及开启

DNS 核心升级：对业务域名开启多 CNAME 能力。业务域名分别配置 IPv4-only 及 IPv6 双栈的 CNAME 域名，具备权重调节能力。可以按地域按运营商自由地控制 IPv4 及 IPv6 双栈折解析比例。对走 localdns 的 PC/H5 端进行 IPv6 的灰度流量控制，实现 IPv4 协议和 IPv6 协议共存。IPv6->IPv4 的回落能力由浏览器提供，部分过旧的浏览器不支持快速回落能力。

HTTPDNS 核心升级：HTTPDNS 服务本身部署在 IPv6 环境，具备 IPv6 互联网出口，提供 IPv6 VIP 及域名 AAAA 解析保障。同时，升级 HTTPDNS 服务本身，可以根据请求客户端的网络状态，以及用户请求参数，对请求的域名下发 AAAA 解析记录，确保客户端运行在 IPv6 环境中，可以正常解析到业务域名的 AAAA 记录。

HTTPDNS 的快速回落：HTTPDNS 在获取到客户端支持 IPv6 时，会把域名的 AAAA 记录及 A 记录同时下发给客户端。当客户端建联 IPv6 不成功时，会同时开始建立 IPv4 连接，以确保用户体验无影响。

同时，针对一些特殊的业务域名，例如：没有实现 PC 端降级以及对降级产生的延迟无法容忍。可以去掉权威 DNS 中业务域名的 AAAA 记录，将 AAAA 记录只配置在 HTTPDNS 中，可以满足客户端走 IPv6，PC 端走 IPv4，既满足了 IPv6 的需求又可以让 PC 业务无损。

动态 IPv6 比例控制能力

IPv6 建设初期，建连成功率低于 IPv4，RT 也高于 IPv4，导致业务无法整体切换到 IPv6。同时，已经切过去的部分，也可能因为网络变更影响网络质量，需要临时关闭 IPv6。这些切换操作，如果都由运维同学手动操作的话，那么像优酷这样有几十上百个域名的，完成一次操作需要花上 1-2 天的时间，时率上不可接受。因为需要建设一套包含 DNS 以及 HTTPDNS 的域名切换系统，可以批量切换域名及 HTTPDNS 的配置，做到 PC 和移动端的业务同步。同时，切换时要具备弹性能力，IPv6 从 100%降到 0%，不能一下子切掉，需要 90%-80%-70%----0%执行，确保不会给网络设备和服务器以及网络出口带来跳变。同时，需要获取业务成功率的监控数据，如果切换过程中，成功率出现下跌的话，系统能够中止切换或者自动回滚到上一级比例，发出报警让运维同学介入排查。

网络质量数据获取设计

客户端埋点上报支持 IPv6

在手机客户端以及 PC 端中，通常会使用埋点技术将端侧运行数据及错误情况，上报至采集服务器。大部分的数据上报中，并不会主动将客户端的 IPv4 及 IPv6 都带上，导致服务端并没有可靠的数据来源去分析 IPv6 下的业务情况。所以，需要改造采集服务端，支持和客户端进行 IPv6 建连，确保在 IPv6 双栈及 IPv6-only 环境下埋点数据可以正常上报。同时，在 app 启动，用户鉴权，网络变化等场景发生时，主动从服务端的应答结果中取到客户端的出口 IP，并把这些信息存储在本地缓存中，在埋点上报时带上 IP 地址。这样采集端就可以收集到客户端的真实出口 IP，如果的双栈的话，还可以同时收集到 IPv4,IPv6 地址并自动关联。从根本上解决了双栈环境时，服务端无法同时获取 IPv4,IPv6 的问题，有助于网络质量数据分析。

资源管理、运维系统改造

实现 IPv4,IPv6 资源区分管理能力

随着 IPv6 深入改造及政策支持，对使用 IPv6 环境的资源设备，流量带宽，调度引流等，将出现区别于 IPv4 环境的使用场景和计量计费规则。慢慢地 IPv6 将会在某些应用场景上出现成本上的优势，而现有的资源管理系统上新建网络管理、应用性能管理、认证服务器、DNS/DHCP 等支撑系统推荐采用 IPv6 单栈建设，存量支撑系统推荐进行双栈化改造，具备对 IPv6 设备、应用或用户的基于机器学习、知识图谱、神经网络等 AI 加持的智能运维、终端识别、应用识别、智能调优、智能漫游、大数据安全分析等管理能力，待网元设备、应用或用户完成 IPv6 单栈改造后，支撑系统需同步完成 IPv6 单栈切换。

实现 IPv6 环境独立运维能力

改造并开启运维系统双栈协议，使系统具备在 IPv6 网络环境下对双栈服务器、网络设备、应用容器、监控采集、数据库缓存中间件、配置远程推送及用户数据的管理能力。对于暂时不支持 IPv6 的系统及设备，提供 NAT 地址转换、降级 IPv4 等方式，来进行管理，待改造完成上线后，逐步开启 IPv6 能力。

应用与服务

接口服务及 PC 端页面

新建应用

新建应用的部署，选用支持 IPv6 的主站机房资源或者阿里云地域，机房出口到负载均衡使用双栈标准。

1. Web 容器环境：选用支持 IPv6 协议的最新版本 Tengine，安装 toa 模块，支持透传 IPv6 头信息至应用服务。

2. 开发环境及 OS 系统：应用的开发编译选用支持 IPv6 协议的操作系统，如 Windows server 2003 以上版本、MAC OS 10 以后，以及 Linux 系统的 CentOS 7 或者 Alios 7U 等。

3. 测试环境：办公网环境与测试机房通过 IPv6 专线打通，办公网提供 IPv6 的无线/有线接入点，同时保留了原来的 IPv4 接入点。开发同学可以接入 IPv6 接入点进行日常开发和办公事务处理，需要访问不支持 IPv6 的公网服务时，可以切换到 IPv4 网络环境。

4. 业务场景 1 IP 地址库：使用 IP 地址库服务对用户归属地进行定位判断处理的，需要升级到最新版本的 IP 地址库数据服务，并具备定期升级能力。确保 IPv6 地域归属判断的准确性。

5. 业务场景 2 IP 地址格式统一：因为 IPv6 地址可以略写的原因，导致直接按字符串进行判断的话，会把有略写和无略写的 IPv6 判断成不是一个 IP 地址，从而导致业务处理出现偏差。同时，部分浏览器请求会自动略写 IPv6 地址，JAVA 网络包,CURL 等，不会主动略写 IPv6 地址，这会增长服务端处理的复杂性，所以需要前置一个公共处理，将所有的 IPv6 地址都经过公共处理进行标准化，统一业务处理逻辑，减少业务间不一致问题。

6. 业务场景 3 IP 地址保存：一般服务端日志落库，用户信息落库等常规处理中，会把用户 IP 保存到数据库等存储中，对于严格限制数据类型和长度的数据库，需要依据存储型号进行定义，原来的 IPv4 只需要 32 位字符串或者长整型数据就可以保存，而 IPv6 需要扩大到 128 位，同时长整型也存不下，需要高 64 位和低 64 位拆分存储等方式进行处理。

7. 业务场景 3 接口传递：某些使用 http get 方式将多个用户 IP 通过参数形式传递时，需要注意 get 的 1024B 的上限，原来传递 IPv6 时 10 个用户一起传递没有问题，但现在改用 IPv6 时 10 个用户的 IP 长度就会超过 get 上限，需要改用 post 或者调低上限。

8. 业务场景 4 存在 IP 地址的 hardcopy：不能把上下游调用接口的 IP 地址直接写在代码中或者配置文件中，因为上下游完成 IPv6 改造的时间并不完全一致，上线时间也不一致，会导致出现线上故障。需要全部改为域名方式调用。

9. 客户端 IP 出口地址的取得方式：在双栈环境中，同一请求，你只能从请求头部中获取到 IPv4 IPv6 地址中的一个，不可能两个都获取。如果希望同时获取 IPv4 或者 IPv6 地址，那么只能选择重复请求，或者是通过参数将客户端地址传上来。需要扩展请求字段，将 v4,v6 分成两个字段提交，同时服务端也需要做接收改造处理。

10. 日志分析逻辑：众所周知，为了方便日志分析和拆解，所有的业务日志都会定义一个统一的格式，日志输了的各个字段之间统一使用||等分隔符分隔或者按字段长度固定。使用分隔符的，需要考虑到不能再使用:了，因为 IPv6 中带了这个符号。使用固定长度分隔的，也需要考虑到对 IP 地址不能再固定 32 位长度了，要调整到 128 位，同时要向下兼容 IPv4，IPv4 也要补齐到 128 位。

11. 第三方库的更新：选用支持 IPv6 协议的第三方 SDK 版本，如果三方库不再更新支持 IPv6，那就需要寻找置换方案。

12. 安全部署环境：接入层安全控件，限流插件，ACL 白名单插件等应用安全服务应支持 IPv6 协议。

13. 降级能力：需要从业务逻辑上原生考虑 IPv6 网络不可用时，如何降级至 IPv4 来继续提供服务。

存量应用改造

存量应用可进行代码 IPv6 重构开发或双栈支持接口开发。对于不支持 IPv6 改造或者暂时无法改造的，需要单独划定小集群区域，来提供 IPv4-only 的服务能力。

1. 接入层改造：制定 IPv6 升级计划，申请 IPv6 的 VIP，将负载均衡的 RS 指向新的 IPv6 接入层，确保 IPv4 与 IPv6 的流量隔离。

2. 基础镜像升级：原业务使用过旧，版本过低的 OS 镜像打包时，需要升级到最新支持 IPv6 的基础镜像，并用最新的 OS 进行编辑打包。

3. 业务系统改造：依据上述新建应用的业务场景梳理内容，对存量业务逻辑进行排查，存在上述场景的需要进行业务代码的重构，业务逻辑的修改，使存量业务满足 IPv6 环境下运行需求。

4. 替换 Web 容器环境：升级最新版本 Tengine，升级最新 toa 模块，支持透传 IPv6 头信息至应用服务。

5. 升级开发环境及 OS 系统：应用的开发编译选用支持 IPv6 协议的操作系统，如 Windows server 2003 以上版本、MAC OS 10 以后，以及 Linux 系统的 CentOS 7 或者 Alios 7U 等。

进行 IPv6 测试环境下的回归测试

存量应用一般都经过严格的 IPv4 环境下测试，但不能保证在 IPv6 下一定是没有问题。所以需要在 IPv6 的测试环境下，对存量应用以及新建应用进行回归测试。包括对所有有改动功能点的全量测试，以及没有改动但属于核心功能点的覆盖性测试。

验收

应用改造完成后，进行线上灰度验收，按照国家网站/应用 IPv6 升级改造验收督查指标相关要求进行测试验证，在域名 IPv6 支持度、页面 IPv6 可达性、业务 IPv6 支持度、应用服务质量、IPv6 安全防护等方面开展测试。

移动终端及 APP

Windows/mac 端 IKU 应用

接入 HTTPDNS 服务，在客户端集成 HTTPDNS 服务 SDK 包，IKU 应用具备手机移动客户端相同的 IPv6 引流灰度能力。替换 IKU 应用端中的网络包，具备 IPv6 的网络通信能力。开发在 IPv6 弱网条件下的降级能力，在用户可以接受的延迟时间内，切换到 IPv4 通信，保障用户体验无损。逐步关闭低 OS 版本的使用许可，关闭低版本应用的上线使用，推动用户端进行 OS 或者设备的升级，提高 IPv6 使用率。

安卓/Iphone/Ipad 手机客户端

这块占比最大，同时用户设备类型也是最丰富的，需要通过不断的版本更新，来降低旧版本的占有率，达到提升 IPv6 使用率的目标。

1. 终端 IPv6 支持度评估：将安装优酷 APP 的终端按照机型，OS 版本，性能， IPv6 下通信能力分类。对新上市机型进行逐台验证，分别进行 IPv6 支持度评估。

2. 客户端 APP 基础套件升级：基础网络包 NetworkSDK 等集团二方包进行升级，实现支持 IPv6 的协议栈解析以及基础降级能力。使用第三方网络库的，例如：libcurl，需要升级到最新版本，同时通过业务逻辑弥补上缺失的自动降级能力。

3. 升级 IP 地址：部分 APP 中集成有小型的 IP 地址库，因为数据包大小的问题，基本上小型 IP 库都没有包含 IPv6 的数据。需要重新评估 IP 库数据包大小与 APP 整体包大小的关系，如果集成支持 IPv6 IP 库数据包过大的话，那需要通过服务端判断的方式来替代本地的 IP 库。

4. 端侧埋点服务的改造：埋点的正常上报，是整体评估 IPv6 下业务可用性和用户体验一致性保障的前提。特别是在弱网、断网、降级回落的情况下，数据可以正常上报。IPv6 下埋点是否正确检测出网络环境的变化，网络切换导致的 RT 变化等，需要根据业务逻辑和用户操作场景，进行埋点的改造。

大屏 OTT 端

大屏端的硬件汰换率低于手机端，大量不支持 IPv6 的老设备还在继续使用着。大屏端 APP 使用的基础架构需要和安卓手机端进行统一，在 APP 层面上支持 IPv6 网络环境下的正常使用，参考上述安卓手机端进行改造。对于硬件部分，能通过升级 OS 固件方式来支持 IPv6 的，要积极推动硬件厂商进行并推送更新。无法通过升级方式来支持，考虑到硬件的整体使用周期及寿命，逐步提醒更新。

云及 CDN

云产品的选型

新建场景

跟据阿里云的 IPv6 改造计划，选用已经完成改区域的云产品，使用业务原生支持 IPv6 环境。

存量场景

因为云产品支持 IPv6 后需要对原产品进行升级或者置换后，才能开启 IPv6 支持，所以对于存量使用的云产品，有一个迁移的过程。需要把流量迁到已经改造完成的地域后，对原有地域的云平台进行双栈化改造，包括 ECS，ENV 容器集群控制中心、容器编排系统、VPC/虚拟网关、负载均衡等进行 IPv6 支持改造，释放原有资源重新申请新的 IPv6 资源，来快速获取 IPv6 支持能力。改造完成后再把流量逐步切回，释放掉临时资源。

CDN 的 IPv6 支持

普通加速域名

依据阿里云 CDN 改造计划，将各地域各运营商已经改造完成的 IPv6 CDN 节点加入到调度域。调度算法需要支持 IPv6 VIP，当区域内 IPv6 节点资源不足或者没有 IPv6 节点时，是进行跨省跨区域调度，还是降级 IPv4。从用户体验角度来说，IPv6 资源不足时降级 IPv4 是对用户没什么影响的。也可以通过计算支持 IPv6 的 CDN 带宽与总带宽的比例，并确定各地域的 IPv6 引流比例。阿里云控制台开启 IPv6 功能，并配置图片域名的灰度比例。从流量入口上就控制处 IPv6 的灰度总量，确保不会出现 IPv6 资源不足或者无资源可调度的问题。

302 调度域名

302 域名跳转时，会有前述 IPv6 地址缩写的问题，浏览器访问时会自动用缩写后的 IPv6 地址跳转，APP 内使用 libcurl 等网络库时，并不会触发自动缩写，以获取到的 IPv6 地址原样进行请求。需要 302 节点配置缩写前和缩写后两套 IPv6 的 VIP，确保任何场景下都可以跳转。在 HTTPS 的 VIP 证书中，需要加签 IPv6 的 VIP，确保 https 下也可以正常跳转。

免流域名

免流调度域需要分配 IPv6 的 VIP 组，将需要向运营商报备的免流节点 IP 都划入进去，并且具备 IPv6 功能的开启和关闭能力，确保在运营商报备完成前不启用 IPv6 节点，运营商报务完成后又能及时启用节点，避免出现免流失效或者免流调度域水位过高的问题。

安全

IPv6 网络安全整体原则：配合 IPv6 演进的不同阶段，明确网络、服务、应用 app 以及新业务场景下，IPv6 网络安全的能力范围和保障方案，强化 IPv6 安全防护能力以及多端共享、边缘计算、云游戏、物联网等新型业务场景下的安全防护能力。

限流能力

限流能力需要具备 IPv4/IPv6 双栈场景下的应用能力，能够对总流量进行限制，也可以分别对 IPv4,IPv6 进行限制。具备在系统能力饱和的情况下，怎么样优先让 IPv6 的请求能力尽快得到处理并响应，保障 IPv6 优先的用户体验。

ACL 黑白名单及安全策略

确保 IPv6 安全体系防护的完整性与高效性，对防火墙、入侵检测、行为审计、流量清洗等网络安全设备，进行统一升级以支持 IPv6 环境下的正常工作。随着 IPv6 的发展，IPv6 的地址数量将远远超过 IPv4，现有的 ACL 黑白名单容量将无法满足，需要提前进行扩容改造。对于 IPv6 安全防护能力存在风险的节点，应进行网络安全设备升级或替换。从应用业务层面以及安全管理层面进行 IPv6 安全策略制定与配置，保证 IPv6 的安全策略包含了所有的 IPv4 策略。

IPv6+创新

IPv6+5G

随着移动互联网的发展，越来越多的设备接入到移动网络中，从某种程度上来讲，5G 和 IPv6 是相辅相成的，目标是一致的，都是尽可能将更多的设备互联，达到万物互联的境界。IPv6 解决了万物互联上设备数量受限的问题，因为地址数量不足，IPv4 可能无法满足每一个人都接入 10 设备。接入 IPv6 的话，别说每个人 10 个设备，10 亿个也没有问题。同时，5G 是解决了万物互联质量上的问题，高速率低延迟是 5G 网络的核心优势。量和质的问题，被 IPv6+5G 一起给解决了，移动设备的需求爆炸式增长的时代还会不到来吗？5G 的技术应用得到了极大的满足，当成本降至合适程度时，IPv6+5G 可以替代 wifi，不再需要 NAT 地址转换，不需要切换流量。只要安全能力满足，你和世界都是实时联通的。

IPv6+P2P 分享

可以想象，今后家中每个带电的设备都会成为计算中心，娱乐中心，看优酷将不再受限于客户端设备，走到哪里看到哪里，每个人都会是内容的消费者同时也会是内容的生产者，片段化的时间能够最合理的利用，最大程度解放双手，随时随地享受娱乐盛宴。

那么这就代表着一个终端既是服务提供方，又是服务消费方，既要为其它设备提供请求入口，又要主动请求其它服务。现有 IPv4+NAT 方案，限定了 P2P 分享的范围，最终能共享到的资源及数据很少，IPv6 下理想状态是全网都不再需要 NAT，任何设备不需要做地址转换都可以直接请求到网内的所有设备。这样就极大的推展了 P2P 可达范围，资源及数据几乎可以全覆盖。我为人人，人人为我，全面符合我们的政治远景。

关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践 &干货给你思考！