走向IPv6，阿里巴巴IPv6规模化部署实践

作者：IPv6项目组

IPv6是互联网升级演进的必然趋势，我国主流APP也正式进入到IPv4和IPv6的双栈时代。本文将从APP及云产品的角度，和大家分享一下我们在这个过程中的经验积累，为进一步推动IPv6规模化部署提供参考。

一、前言

细心的人可能已经发现，我们在首次打开淘宝、天猫、支付宝以及国内主流APP的时候，都能看到“IPv6”的标示，这个“IPv6”意味着我国主流APP正式进入到IPv4和IPv6的双栈时代。本文将从APP及云产品的角度，和大家分享一下我们在这个过程中的经验积累，为进一步推动IPv6规模化部署提供参考。在正式介绍经验之前我们先简单介绍一下IPv6的一些基本信息。

1.1 什么是IPv6？

IPv6是Internet Protocol Version 6的缩写，其中Internet Protocol译为“互联网协议”。IPv6是IETF（互联网工程任务组，Internet Engineering Task Force）设计的用于替代现行版本IP协议（IPv4）的下一代IP协议，IPv6将IPv4中32位的地址长度扩展到了128位，使用IPv6，可以让全世界的每一粒沙子都能分配到一个IP地址。

IPv6的设计初衷是用以解决IPv4地址枯竭问题，同时对IPv4进行大量改进，并最终取代IPv4。然而由于NAT等技术的广泛应用，IPv4在互联网流量中长期占据主要地位，IPv6的使用增长缓慢。

1.2 IPv6的国家战略价值

IPv6是互联网升级演进的必然趋势、网络技术创新的重要方向、网络强国建设的基础支撑。当前，全球范围内IPv6网络建设与应用创新持续加速，主要发达国家和地区均出台了IPv6发展规划和政策指导，大型网络运营商和应用服务商也在开展IPv6大规模商用部署。同时，随着5G和IoT技术的逐渐成熟，万物互联的时代即将到来，苹果AppStore审核要求全面支持IPv6等，使得市场上对IPv6的呼声不断升高。

IPv6对我国数字化、支撑网络强国建设有重要的意义。这方面我国推进IPv6规模部署专家委主任邬贺铨院士对此有比较充分的论述。

1.3 IPv6的社会价值

在大家的印象中，IPv6可能仍然处在部署的初期，各大运营商还在进行网络改造，全面普及似乎离个人还是一件很遥远的事情。但根据国家IPv6发展监测平台的数据，目前全国IPv6互联网活跃用户总数达到了6.83亿，全国IPv6互联网活跃用户占比达到了66.18%，IPv6已经不知不觉地融入到大家的生活中。随着IPv6的规模化部署，它会给我们带来哪些变化呢？

随着5G时代的到来，物联网、工业互联网、云计算、人工智能和大数据等新兴领域的快速发展，移动互联网对于IP地址的需求日益增加，IPv4已经无法满足当前网络环境。IPv6和5G是相辅相成的，它们的目标都是尽可能将更多的设备互联，实现万物互联的最终境界。结合IPv6海量公网地址的技术属性和5G高速率低延迟网络的核心优势，为万物互联网络提供质量保障。

普通用户将会逐步进入全面告别内网的时代，目前运营商大部分都使用了NAT技术，这让用户在远程监控、游戏联机、P2P视频、设备公网互联等方面，体验不太稳定，也制约了这些技术的进一步发展。IPv6拥有无穷无尽的公网IP地址，从而实现真正的万物互联互通。未来我们看的优酷视频可能就是自己邻居分享的，我们使用的钉钉视频会议也会因为IPv6变的更快更清晰，我们的家用监控也因支持IPv6而变的丝滑流畅，这一切将会在IPv6全面普及后逐步实现。

1.4 IPv6规模化部署过程中遇到的困难与挑战？

1.4.1 超大工程的管理挑战

• IPv6改造涉及运营商线路和地址申请、网络/计算/存储等IT基础设施新建或升级、应用程序代码逻辑更改等事项，升级难度大、复杂度高，如何保障业务连续性？需要满足业务平滑升级、减少业务中断时间，甚至避免业务中断的核心诉求。

• 国家推进IPv6规模部署行动提速，企业网站系统、互联网APP等需要在较短时间完成IPv6改造工作，如何在保证业务稳定性前提下，快速完成升级是不得不面临的挑战。

• 应用软件需要进行大范围改造，同时也会带来运营商线路费用、IT 基础设施软/硬件新购或升级费用、集成服务费用等综合成本，如何提升改造效率，同时实现持续性成本可控可预期也是非常关键的点。

1.4.2 新场景下的技术难题

• 从IPv4单栈到IPv4和IPv6双栈环境，对应底层表象会增加双倍的工作，如何稳定高效的支撑业务发展，这是首先要解决的难题。

• 双栈网络环境增加了测试的复杂度，如何建立便捷的测试工具，方便日常的测试工作同时能够及时发现异常。

• 随着双栈的部署终端面临的环境更加复杂，如何在复杂网络环境中确保用户体验，这是规模化部署过程中必须要解决的技术难题。

1.4.3 常态化运营体系建立

• 规模化部署不是最终目标，IPv6需要从能用走向好用，需要持续运营下去。互联网技术迭代更新是非常快速的，一到两周就会进行一次版本的迭代发布，如何保证后续的迭代升级中不会影响规模化部署的进程，这需要将这部分工作融入到日常常态化的运营体系中。

1.5 阿里巴巴对IPv6的整体思考和改造方案

不论从政策导向、市场需求，还是聚焦于技术演进，IPv6都将开始进入规模部署阶段，正是基于此背景，阿里巴巴率先全面进入“IPv6时代”。集团在2017年成立集团IPv6项目组，主流APP均进入到IPv6规模化部署中。

• 2018年启动阶段一：应用接入层改造。

• 2021年启动阶段二：内网应用IPv6升级试点，探索IPv6演进的最佳实践方案。

• 2022年启动阶段三：IPv6 Only试点。

本文重点会和大家分享阿里巴巴成熟的应用接入层改造经验，后续会逐步为大家分享内网应用IPv6升级和IPv6 Only试点的改造经验。IPv6规模化部署是一个超级工程项目，更是一个技术创新项目。

接下来我们将会以四个维度展开：

1. 整体规划；

2. 从云、管、端（服务端、客户端）4个层面剖析这个超级复杂工程；

3. 为克服新场景困难而打造的三个核心技术；

4. 为IPv6常态化运营打造的常态化运营体系。

二、整体改造方案

2.1 战略规划

IPv6的整体发展，我们可以将其总结为三个战略阶段：

第一个战略阶段是IPv6发展的初期，更多是孤岛式的实验环境。

第二个战略阶段是IPv6与IPv4共存阶段，这个阶段又分为IPv4主导和IPv6主导两个阶段，这两个阶段侧重点略有差异。IPv4主导阶段我们重点提升公网IPv6流量占比，由于涉及的面非常大，而且短时间内没有业务价值，因此需要有较强的政策牵引。到达IPv6主导阶段，企业自主驱动力会增强，端到端改造将会是重点。我们现在就处于第2个战略阶段中的IPv4主导向IPv6主导演进的过程中，因此当前比较急迫的是推进IPv6规模化部署，让IPv6流量占比实现较大的提升，进入IPv6主导阶段。

第三个战略阶段是IPv6成熟阶段，我们需要逐步关停IPv4，全面进入IPv6 Only时代。

复杂的问题总会让人望而生畏，将问题拆解，逐个击破是很好的规划思路。基于这三个战略阶段的划分，我们可以分阶段进行改造，隔离相互间的依赖，既能做到快速的实现公网流量的提升同时确保业务的稳定性连续性，又能分步进行创新探索。

1）战略推进：有了长远的战略规划就可以更加清晰进行项目的推进，接下来我们将重点聚焦在IPv6流量提升和规模化部署部分。具体到执行阶段，我们大体上遵循“三步走”的策略，每个阶段都需要经历这三个步骤，这是确保我们业务稳定运行的重要保障。

• 步骤一：应用试点，首先需要通过一个应用，跑通整个改造流程，打通云、管、端的依赖。

• 步骤二：小规模上线，实操起来需要具备精细化的灰度策略，按照省份、运营商、比例的精细度，逐步上量。

• 步骤三：需要形成可复制的解决方案，在集团内部进行大规模的推广部署。

2）组织保障：为更好落地整体战略规划，集团成立了一个强有力的执行项目组，根据阿里巴巴主流的APP，成立24个子项目（PM、端、测试、开发的同学组成），再加上云产品的子项目（PM、SA和各个产品的PD开发组成），组建了阿里巴巴IPv6（基石）项目组。

3）资金支撑：

• 改造过程会涉及到硬件改造以及硬件和平台费用，同时项目组体量比较大，我们涉及到少量的运营费用，这些都需要提前做好预算规划。

• 涉及到硬件设备及测试手机等设备，需要提前采买好相关的设备

2.2 超大工程

接下来我们将会进入实际改造的环节，IPv6改造是一个系统性的工程，尤其是对阿里巴巴来说，我们涉及的范围非常大。为了项目的高效推进，我们从全局纬度将其分为“云管端”三大部分，其中端的改造又分为服务端和客户端，我们把这个两个单独拆解开来，最终我们会从云，管，端-服务端、端-客户端这四个部分来进行阐述。

2.2.1 云产品改造

为了更好的完成公网流量提升（服务端双栈改造依赖部分不在这里讨论），我们需要全面完成企业互联网域名服务器IPv6改造，支持AAAA记录和IPv6域名解析请求，主要核心业务域名全部配置A及AAAA记录。使用阿里云HTTP DNS服务，支持移动端的IPv4/IPv6双栈及IPv6 Only环境下的域名解析能力。

云产品改造会以更好的支撑APP IPv6改造为首要任务，最终达成IPv6用户数和公网流量提升的目标。可以分为三期来进行，首期是在用户访问的公网入口及安全管控处进行了IPv6的支持，包括DNS、http DNS、CDN、SLB、DDoS、WAF、ACL、IP地址库等，这些产品支持了IPv6，就意味着用户可以基于这些产品提供安全、高效的IPv6服务。接下来阿里云还将在内部网络进行双栈的支持，实现端到端的IPv6流量贯通。最后，未来的演进目标是IPv6 Only。

⍟ 云解析DNS支持IPv6

要使用IPv6服务，首先需要DNS支持IPv6解析。我们都知道，当用户访问互联网时，访问的请求会最先到达DNS，DNS会根据访问域名查询并返回正确的IP地址。IPv6时代，阿里云解析DNS依然作为云计算服务的入口，同时支持IPv4和IPv6双栈（即一个域名解析两个地址，一个IPv4地址，一个IPv6地址）解析，继续提供强大稳定的解析调度入口。

⍟ 负载均衡SLB支持IPv6

公网入口会优先支持IPv6，快速提升公网流量占比，负载均衡SLB长期以来都是关键业务系统的公网入口，它可以对多台ECS进行流量分发，提高业务系统的可用性和处理能力。

负载均衡SLB支持IPv6从产品上看主要有两点：首先，采用了独立的IPv6类型SLB。独立的IPv6类型的SLB实例和IPv4的SLB实例性能和功能没有差异。用户只需要在购买SLB时选择IPv6类型，就可以快速创建一个IPv6的SLB实例。其次，IPv6类型的SLB和后端的ECS通信还采用IPv4私网地址。

⍟ CDN服务

CDN内容分发网络（Content Delivery Network），解决跨地域跨运营商网络性能问题，提供稳定快速的加速服务。CDN是互联网的流量入口，阿里云CDN团队从2017年起就启动了IPv6的改造，积极持续地在IPv6改造中投入相关资源，从节点部署、节点网络架构改造、IPv6功能支持、IPv6调度能力完善、IPv6全链路监控方案、IPv6质量评测体系建设等方面持续打磨，投入物理资源、人力资源，推动IPv6整体能力不断向IPv4靠近。截止到目前累计完成了近千个节点的IPv6改造升级，IPv6合规率超过90%，超过工信部的验收标准，在产品化上，基础的CDN产品和全站加速产品率先通过由全球IPv6 Forum论坛发布的IPv6 Enabled CDN。

阿里云CDN将各地域各运营商已经改造完成的IPv6 CDN节点加入到调度域，用户在阿里云控制台开启IPv6功能，并配置图片域名的灰度比例。可以从流量入口上控制IPv6的灰度总量，确保不会出现IPv6资源不足或者无资源可调度的问题。

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

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

⍟ WAF服务

当用户以IPv6进行通信时，还有一个关键的云服务即Web应用防火墙，它负责对网站或者APP的业务流量进行恶意特征识别及防护，将正常、安全的流量回源到服务器。当我们运行IPv6协议时，必须升级到对IPv6/IPv4双栈的防护能力，避免网站服务器被恶意入侵，保障业务的核心数据安全，解决因恶意攻击导致的服务器性能异常问题。阿里云WAF已经支持一键升级IPv6功能，在WAF控制台的被防护域名下，直接打开IPv6状态开关即可。

⍟ DDoS服务

同样重要的还有阿里云DDoS防护服务，它是以阿里云覆盖全球的DDoS防护网络为基础，结合阿里巴巴自研的DDoS攻击检测和智能防护体系，向用户提供可管理的DDoS防护服务。同样需要增加IPv6的防护能力，自动快速地缓解网络攻击对业务造成的延迟增加、访问受限、业务中断等影响，从而减少业务损失，降低潜在DDoS攻击风险。如需对IPv6地址进行DDoS防护，可以开通DDoS防护包中的IPv6协议，防护对象设置为IPv6转换服务的地址。

⍟ ACL黑白名单及安全策略

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

⍟ 其他云产品支持IPv6

除了上面提到产品外，还有很多其它产品也已经完成了支持或即将支持，如对象存储OSS、数据库RDS、DTS、API网关等。

2.2.2 管道改造

接下来我们将进入另外一个重点改造的场景即“管道改造”，对于阿里来说我们重点需要完成IDC网络和IT网络的全面改造。

全面完成集团级数据中心核心网络、互联网出口IPv6网络改造。

1）改造步骤

• 首先为了更好的支持云产品改造，实现Internet提供IPv6的域名解析、负载均衡及安全服务服务，核心网、安全清洗、MC、BSW、LSW优先支持，然后是ANAT、XGW的4to6的地址翻译以及LVS、CDN。

• 然后对IDC集群内部的DSW、PSW、ASW、NC进行改造，支持ECS、Docker服务。

• 最后开始进行IPv6 Only尝试，全面进入IPv6时代。

2）方案介绍

• 核心网支持双栈，主要有两种技术方向选择：物理机双栈和MPLS 6PE/6vPE。物理机双栈是在现有的IPv4路由器和链路上，使能IPv6和路由协议，IPv6报文和IPv4报文一样，直接封装在链路层上转发；MPLS 6PE/6vPE则是保持现有的MPLS网络不变，在PE上将IPv6报文封装到MPLS中进行转发。这种方式可以在PE设备按需变更支持。

• 阿里核心网已经开启MPLS功能，后续整体演进方向是全面MPLS化，P结点设备成为BGP-free Core以大幅减少对设备的功能要求和降低功耗，这对于节省Capex和Opex成本都有很大帮助。

• 基于阿里核心网的实际情况以及后续整体演进方向，在IPv6的演进方案上，我们选择6PE/6vPE的方案，通过升级PE路由器来支持双栈，不需要对现有核心网P路由器做更改。只需PE设备使能IPv6，P设备不需要使能IPv6，整体实施成本低。IPv6作为MPLS的一个新业务承载，对现有运营维护冲击小，IPv6维护范围只在PE，充分发挥现有的高效运维体系能力。AZ内则主推物理机双栈，两种技术结合实现高效推进。

阿里巴巴办公网改造

办公网的改造也是一个复杂的过程，不仅涉及到改造的成本，同时也需要投入大量的人力，因此这是一个比较漫长的过程。为了更好的满足业务需求，我们也分为两个步骤来实现。

• 步骤一：两个过渡方案，先通过点状部署，满足大家的测试需求。然后通过改造我们的Vpn客户端和网关，通过拨入Vpn获取IPv6地址，满足开发测试需求。

• 步骤二：在经历一年的测试准备后，2022年初我们在全国21个园区开始逐步进行IPv6改造，预计在2023年3月底完成国内主要园区的双栈改造升级。

在全国核心城市部署园区网汇聚POP节点，该汇聚点下联城市各园区核心出口设备，上联阿里云对应region接入点，实现园区网所需资源在云上快速拉起部署，借助云上资源IPv6能力快速组建新一代园区网双栈运维系统，如DNSv6服务、DHCPv6服务、双栈堡垒机等，免去线下自行搭建付出的巨大人力和资金成本。

2.2.3 应用端改造

我们组织集团20多款APP同步进行IPv6双栈改造，改造内容更加聚焦，效率也会高很多。下面我们先介绍一下服务端改造工程。

⍟ 新建应用改造

1）环境准备

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

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

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

2）业务应用改造

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

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

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

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

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

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

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

3）依赖改造

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

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

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

⍟ 存量应用改造

1）环境改造

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

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

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

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

2）业务应用、依赖改造及降级能力构建

• 参考上述新建应用的改造、依赖改造及降级能力构建即可，对存量业务逻辑进行排查，存在上述场景的需要进行业务代码的重构，业务逻辑的修改，使存量业务满足IPv6环境下运行需求。

⍟ 回归测试

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

⍟ 验收环节

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

2.2.4 客户端改造

接下来我们将会进入客户端功能改造部分，客户端有分为手机、电脑等场景，全部需要支持IPv4/IPv6双栈及IPv6-only环境下的网络通信能力。IPv6双栈环境测试IPv6流量占比不低于80%，并逐步引导IPv6-only模式。

⍟ Windows/mac端IKU应用

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

⍟ 安卓/iPhone/iPad 手机客户端

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

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

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

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

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

2.3 创新技术

通过前面的介绍，相信大家已经对四个板块（云，管道，服务端，客户端）的庞大改造工程有所了解。如前面所说，作为一个创新技术项目，接下来重点介绍三个关键的创新技术方向，在应用的双栈改造过程中对我们流量的提升和服务质量保障起到了至关重要的作用。首先我们会介绍一下核心的全链路双栈技术，这里重点从核心网、硬件和系统三个大的技术方向中选出AliBGP、双栈智能网卡及Linux内核三个点做一个简单的介绍，然后会介绍保障测试效率的TMQ-Monkey技术，最后会介绍提升用户体验的EQM及T-happyeyeballs技术。

2.3.1 关键双栈技术

⍟ 负载均衡网关支持IPv4、IPv6双栈平滑演进

双栈支持，在业务向IPv6迁移升级过程中，做到无缝切换，有效降低用户使用网络的复杂度。通过DNAT vxlan封装或者FNAT携带TCP option，后端内核模块获取访问SLB的IPv6客户端源地址。 

• 负载均衡网关支持IPv4、IPv6双栈后端平滑演进的技术

IPv6的改造难度大、周期长，一般涉及从原有IPv4服务平滑过渡到IPv6。阿里云负载均衡网关通过支持前后端IPv4/IPv6双栈session技术提供NAT64和NAT66 session以及IPv4/IPv6后端混挂能力，满足用户平滑演进的需求：初期可通过负载均衡NAT64能力的过渡方案，IPv4后端在不改造或微改造的情况下可通过IPv6负载均衡快速对外提供IPv6服务；后期通过支持挂载IPv4、IPv6混布能力的IPv6 SLB，逐步切换到IPv6后端服务，再逐步减少IPv4后端比例，增加IPv6后端比例，最终切换到纯IPv6。

• 获取客户端IPv6源地址

在原有IPv4场景中，后端服务一般有需要获取到客户端IPv4源地址需求。IPv4到IPv6的改造过程中，获取客户端IPv6源地址的需求也是显而易见的。在NAT64场景下，由于源地址被转换为IPv4地址，原始IPv6源地址信息只能考虑通过其他方式携带给后端，阿里云SLB通过自定义TCP option方式中携带IPv6地址信息的方式携带源地址给后端，后端通过特定内核模块解析tcp option并保存在sock中，用户调用getpeername来获取IPv6源地址。

⍟ AliBGP大规模IPv6路由控制方案

IPv6网络构建是IPv6商业部署的基础设施。而IPv6网络构建中的重要一环是IPv6路由系统的搭建，其主要包括路由管控和路由快速收敛两部分。在IPv6网络中，发布什么路由，学习什么路由，以及在网络抖动时快速收敛，是IPv6网络稳定可用的重要课题。

在IPv4网络中，C段的大小是8bit，即256个IP地址；而在IPv6网络中，C段的大小是64bit，最大IP地址数可大2的64次方。在网络中，除了正常转发数据用到的路由，还需要发布防攻击的黑洞路由，容灾用到的不同长度不同优先级的网段和明细路由。为此，单设备中学习和发布的IPv6路由条目数可达10K甚至100K级别，再叠加原先IPv4的32K路由，整网路由收敛能力需要有数倍增加。同时需要对IPv6路由进行更细致的管理，以避免因误发布或者误学习路由造成网络数据包的丢失。

传统IPv6网络实际部署业务规模不大，网络路由量也不大，传统的商用交换机的路由学习和收敛能力较低，性能大致为1.4K条目每秒，不能适应阿里业务网络路由量的需求。

AliBGP广泛应用于高性能转发网关、自研交换机、网络业务服务器平台之上。高性能优化，路由收敛性能达到10K条目每秒。实现了大规模快速收敛、故障范围控制、快速倒换等方面的能力。

可靠性方面，支持添加路由发布和学习总条目数控制、指定设备路由平滑隔离和恢复、IPv6路由热重启、远程控制API等功能，改善了IPv6路由精细化管理能力。

• 高性能：ALIBGP采用开源的FRR路由软件，并在上面做了大量的功能开发和性能提升开发。实现了用户态IPv6 BGP协议，并引入了IPv4 BGP协议中的Dynamic Update Peer-Groups和Next-Hop tracking两大特性功能，实现以Group方式的发布和学习路由条目，在路由震荡时跟踪next-hop状态刷新路由下一跳；同时特别优化了IPv6 ECMP路由与内核的交互过程。这些优化极大提升了IPv6路由学习和发布效率，以及收敛速度。

• 高可靠：强大的路由控制能力，IPv6的route-map的配置渲染能力，能根据用户规则，精细控制每个路由条目的学习和发布。

高性能IPv4/IPv6双栈智能网卡

双栈支持，在业务向IPv6迁移升级过程中，做到无缝切换，有效降低用户使用网络的复杂度。

• 后端支持IPv4、IPv6混合部署

IPv6的改造是一个复杂的系统工程，既要保障用户现有IT投资，又要紧跟网络发展趋势，从实际来看，IPv4/IPv6双栈将长期存在。短期来看，IPv6转换服务会是一个经济适用的过渡方案；但长期来看，无缝支持IPv4/IPv6双栈将是终极解决方案。基于此，我们在AVS转发阶段即考虑完全兼容IPv4/IPv6双栈，从底层有效解决IPv4、IPv6混布的问题。IPv4/IPv6双栈全面支持TCP、UDP、GRE、ICMP等各种报文类型，通过自动识别报文版本号、报文类型，提取报文五元组等关键信息实现报文自动转发。

• FPGA硬件加速，极大提升网络性能

通过使用自研FPGA板卡进行AVS硬件加速，将AVS转发路径下沉硬件，自主定制开发IPv4/IPv6转发引擎，实现双栈无差别加速，极大提升IPv4/IPv6转发速率。单机性能从软转发的5Mpps（4core），提升至30Mpps；端到端单向延时从60us，降低至25us，达到业界领先水平。既节省了主机CPU，又提高了报文处理的效率，有效降低了IPv6改造过程中的巨大经济成本。

• 自定义会话压缩技术，支持千万级别会话流表

通过使用外挂ddr，将流表转发信息转移到外部存储。同时，针对IPv6转发信息位宽大的特点，采用自定义数据压缩技术，在有限空间内，无缝存储IPv4/IPv6转发信息，极大提高了流的会话数量。session数从内存模式的几兆提升到几十兆，将单机会话数量提高了一个数量级。为防止外部存储数据错误，自行开发了一套接口信号检错、纠错机制，有效保证整张卡的接口稳定性。

⍟ Linux内核优化

1）IPv6内核协议栈bugfix

• IPv6 路由cache优化

当核心网和物理机网卡已经高效支持IPv6后，接下来我们还剩下一个非常关键的优化点，那就是操作系统。我们早期在试点IPv6应用的过程中发现IPv6流量会引起的大规模CPU软中断飙高以及宕机现象，所有的IPv6请求受到了影响，而且会有宕机风险，这也会对同一台机器上的IPv4服务产生影响。因此，Linux内核的优化就是摆在我们内核工程师面前重点方向。

通过分析发现主要原因是gc拥堵，造成了同一个TCP连接会在tcp_v6_rcv函数里的socket spinlock那里spin，而不同连接则会在fib6_run_gc函数里的gc spinlock那里spin 。为什么IPv4没有问题而IPv6就会有问题呢？

IPv4地址大概有43亿个，去掉广播、组播、私有地址等，系统需要路由处理的地址完全是在哈希、树这种传统数据结构的处理能力之内。但IPv6最大的特点就是地址数多了很多，这意味着处理逻辑会变的更加复杂。

经过我们工程师的测试验证，最终选择关闭IPv6的路由cache，看起来只是通过修改配置就能解决，实际上由于IPv6的所有路由项都在同一棵树里，所以拆分起来还是有难度的。

• IPv6 代码优化 

IPv6 sysctl的数据指针是一对一设置的，不利于维护，尤其是使用 kconfig。我们通过补订实现了简化处理，达到了和IPv4一样的效果。

• IPv6协议栈传输机制优化

IPv6 mtu优化，经过长达一年多的大范围持续验证，最终拟定了IPv6 MTU1450，在阿里CDN的场景下，最大化的兼顾IPv6传输性能和业务可用性。

拥塞控制和丢包恢复算法的优化。拥塞控制是协议栈心脏，控制着协议栈的功能启停；丢包恢复系统是免疫系统，负责异常修复，CDN设计了CUPLUS和PBR两大核心算法保障IPv6协议栈的内容分发效率。

• IPv6协议栈数据体系建设

在IPv6上量规模化过程中，为了建立对IPv6网络的基础认知、优化IPv6传输机制和监控IPv6服务的稳定性，我们构建了IPv6协议栈的网络数据中心，数据中心设计了两个大板块的功能：

① 网络链路质量监控：监控IPv6的网络链路质量与IPv4的差异性，实现了重传率（字节和报文个数两个维度统计）、TCP连接建连时间、响应时间（服务器视角）、平滑RTT、最小RTT、RTT方差和IPv6总传输流量等维度统计；

② 业务质量监控：监控IPv6协议栈提供的业务质量与IPv4的差异性，实现了请求失败率千分比、平均请求大小、下载速度三个维度统计。产品化能力支持了TCP连接粒度和域名维度的数据监控能力。

2.3.2 TMQ-Monkey技术

Android系统原生支持Monkey能力，通过adb命令即可触发monkey操作，从而对指定应用进行随机的点击操作。为了更好的提升集团APP的IPv6浓度占比，我们采用Android原生Monkey能力进行测试，经过使用后，发现原生Monkey能力存在一些痛点，无法满足我们建设自动化测试平台的需求：

• 点击效率低：由于原生Monkey完全基于屏幕大小生成随机行为，对页面内容和元素不感知，仅通过快速生成随机坐标进行点击，较多的点击行为是无效的。

• 容易陷入相同页面：原生Monkey对页面内容和路径没有记录，完全幂等的行为，导致在相同业务如果退出的出口较少情况下，无法退出业务页面，长期位于同一页面，效率低下。

• 策略较少：原生Monkey完全依赖随机策略，不支持针对情况调整页面策略，对于部分场景支持度不高。

• 不支持自定义能力：对于业务需求的页面不支持重点的定制化。

以上痛点导致IPv6自动化项目中，原生Monkey能力跑出数据量不足，流量不达标且跑到的页面量不足，IPv6流量测试效果不佳。为了解决这部分问题，与淘宝TMQ团队，通过结合openatx的UI自动化和优化过的Android Monkey能力来支持IPv6自动化测试能力。在保留Android底层直接驱动的快速效果的同时，也能利用UI自动化能力支持自定义能力。

TMQ-Monkey提供了独立的Python SDK，封装依赖的Monkey驱动能力和自动化调度能力，支持一键部署和运行，实现IPv6项目低成本的接入和维护。

⍟ TMQ-Monkey系统技术结构

TMQ-Monkey基于Python封装各类依赖和管理Monkey运行任务，主要实现能力如下：

• 生命周期管理：对于每次执行的Monkey任务，及时在服务端创建相关信息用于任务记录，并管理Monkey运行期间的设备运行、设备状态、插件运行等相关行为，统筹整个运行期间的设备行为。

• 自动化设备接口：基于openatx提供Android和iOS的设备接口，用于处理monkey运行前的前期准备和运行期间的自定义行为。

• 依赖管理：处理Monkey驱动层相关的依赖下发和配置。

• 配置管理：通过配置管理中心，对各类运行参数、插件信息、运行数据等内容进行管理。

• Monkey驱动层：主要用于基于Android Monkey的底层驱动能力。

• 事件管理机制：Monkey运行期间的整个驱动层的事件管理，通过事件生成器生成的随机事件，对设备进行运行，并处理各类异常情况。

• 事件生成器：通过策略中心、配置中心、异常识别结合生成最终Monkey事件，从而驱动Monkey运行。

• 策略中心：按照用户输入的策略选择，依据策略生成相应的事件生成方案。

• 配置中心：处理用户定义的黑白名单和下发的各类场景处理的配置，用于优化Monkey执行效果。

• 异常识别能力：有效对运行期间各类异常状态：Crash、假死、跳出等场景进行识别，并处理。

• 插件中心：执行运行期间的其他运行能力。

• 数据收集器：对Monkey运行期间的页面信息进行收集，上报服务端，用于数据统计和后续策略优化。

• 自动跳转插件：集团部分支持自动跳转能力的应用，可以通过用户下发常见页面，支持直接跳转后运行Monkey，有效提高Monkey的效果。

• 运行数据监控：有效对运行期间的SDK本身的运行情况进行监控，将异常和错误及时记录并上报。

2.3.3 EQM与T-happyeyeballs

另一个影响规模化部署的因素就是用户体验保障技术，面临着IPv6基础生态发展的不平衡性带来复杂性挑战，以及复杂生产环境中IPv6的大规模应用挑战。

• 双栈覆盖（不同运营商、不同省份）发展不平衡

• 公网IPv6质量参差不齐

• 移动设备及网络环境的复杂性

⍟ 故障自动发现体系建设

从IP调度的角度，任何一个IP对某一个端侧设备是好还是坏，主要看以下两个核心指标：

• 连接成功率越高越好

• 请求耗时越低越好

通过这两个指标，结合以下多维度观测，理论上我们可以形成一个智能的调度平台，该平台可以自动发现问题并及时自动最优化调度：

图：故障监控维度覆盖

事实上，我们的“反馈监控—>故障发现—>自动调度”这个过程演进，经过了两个阶段：第一阶段是故障自动发现告警，人工及时干预调度；第二阶段是故障自动发现并实时自动调度。

在第一阶段，因为人工调度无法关注粒度太细的维度，我们主要关注以下三个维度的指标：地理位置（精确到地市）、运营商、平台类型，一旦实时统计发现某个IP在上述三个维度上有明显“偏差”（即从成功率与耗时两个指标上，与IPv4相比劣化明显），立即给运维人员发送警告短信和邮件，运营人员及时在发现故障的维度上把该IP给摘除，控制故障扩散，收敛故障影响。

在第二阶段，因机器可实现高频细粒度调度，我们通过基于拨测记录与业务结果反馈形成的数据，通过智能学习，在发现某个IP在某个维度上有明显“偏差”后，自动实现在故障的维度上把该IP给摘除，控制故障扩散，收敛故障影响。同时，相比人工告警的方式的，自动调度情况下系统关注维度的粒度与广度要高得多。

图：大规模智能调度示意图

前置网络质量探测

当前业界并无可供直接参考的无线IPv6质量数据，在无参考数据的情况下，应用侧直接灰度放量，样本质量波动大、噪点数据多，放量决策价值不高。在业务正式上线前，必须对整个网络有端到端的全景式观测，为业务放量、调度做到有效可靠支撑。

针对现有基础网络IPv6发展不平衡的问题，设计了主动式大规模网络质量拨测系统。通过调度大规模端侧设备对指定IPv6地址提前探测，实现对基础网络IPv6质量的提前测量；通过在大规模移动端实现ping6、traceroute6等拨测指令，满足对网络的细粒度全景测量。在该体系基础上，通过对不同省份、不同运营商、不同设备类型、不同无线环境多维度分析，实现基于用户侧的无线端到端大数据全景测量。

其中，拨测指令包含以下内容：

构建全球首个大规模无线IPv6监控体系，同时为国内运营商提供了可靠的问题发现与度量系统，进一步推动了国内IPv6演进速度。在应用侧为业务安全定向灰度放量提供可靠决策依据。

移动端业务EQM（端到端质量检测）

前置探测并不能代表实际业务质量，因规模大、影响面广，业务运行期实时监控也是必不可少的环节。且实际运维中，故障的发现与原因排查，后续网络部署的优化与演进，均需要有效数据支撑。

PC端业务EQM（端到端质量检测）

当前PC端的性能监控方案主要是基于js采集浏览器performance.timing接口数据上报汇总计算实现的，因为浏览器并没有对js暴露当前是基于v4还是v6建立的连接，所以单纯通过js无法实现区分v4和v6的性能监控。

我们制定了一个通过后端应用tengine配合增加一个不影响页面展示v6访问特征，js通过判断特征实现区分v4和v6访问，并且为v6设置单独的采样率，最终生成v6独立的性能报表。

⍟ 大规模精准化实时IP调度应用

针对现有公网DNS在IPv6流量调度风险不可控问题，设计了私域大规模精细化实时IP调度体系。通过对单个设备直接下发IP来满足风险控制需求；通过直接对端侧IP识别实现精准调度需求。在该体系基础上，通过单个设备的多维度信息识别，可在地域、运营商、终端类型等多个维度实现细粒度精准调度。并在发现IPv6业务故障后，云上大数据分析服务，通过端侧实时反馈，快速感知问题区域，实现流量的智能调度与恢复。

我们通过高频业务的旁路指令，调度指令下发由拉变推，实现基于“探针模式”的快速调度。

应用侧从原来的基于Local-DNS的间接调度升级为基于端侧设备直接调度，调度精度与时效大幅上升。产业侧为IPv6在应用上大规模落地扫清了障碍，极大加快了整个IPv6的发展进程。

T-happyeyeballs基于移动应用的多IP&多协议无损切换技术的应用

针对移动网络环境的复杂性及低可靠性，开发了移动应用的多IP&多协议无损切换技术。通过多IP并行建连技术，满足端侧在IPv6下快速Fall-back需求。基于该技术，端侧具备快速的黑洞逃逸能力，能够在不依赖调度体系情况下快速的自愈。同时根据拨测与业务反馈上报到控制中心调整判断参数（比如某些型号、版本、某网络差的城市），依据综合指标进行不同滑落惩罚的时长。

在手机淘宝应用中，IPv6失败率在iOS/Android双端分别只有0.4%+/0.6%+。支撑集团IPv6活跃设备从0至全量过程中0故障。

在我们内部实验过程中，还进一步使用了多网卡切换技术。通过在Wi-Fi网络下强制数据连接到蜂窝网的能力，实现了在局部固网IPv6故障下用户新的无感迁移数据通道能力。

⍟ 应用体验保障实践效果（IPv6体验指标体系建立）

经过多年沉淀，我们面向海量移动终端与云的IPv6商用部署与规模化应用，应对移动网络环境复杂性时不断增强IPv6 inside的终端网络架构及技术能力，支撑了IPv6端到端规模化创新应用，持续沉淀领域数据、引领IPv6体验&质量标准。通过打造终端网络诊断工具、体系化数据平台，实现了IPv6的高质量体验。线上应用最新数据表明，淘宝的IPv6应用，在基础网络指标上已经全面优于IPv4。

当然，用户面临的网络环境愈加复杂，例如家庭AP设备驳杂，地域/小运营商/城域网v6接入配置标准和启用程度参差不齐，会不断产生新的未知体验问题，这些都将是影响IPv6体验的不确定因素，我们将持续创新实践，确保IPv6体验质量不断破障。

2.4 运营体系

讲完了庞大的改造工程以及创新的技术亮点，我们技术分享又步入了另外一个重点的领域。IPv6改造是一个长期的事情，需要有一套完善的机制确保其一直有效的运营下去。所以我们还需要重点介绍一下我们的流程体系，我们需要建立一套常态化的IPv6运营方案，IPv6的技术已经纳入到阿里巴巴的技术文化中，不断的自我演进和迭代。

2.4.1 新增云产品及APP url管控体系建设

项目组在推进IPv6改造的过程中，业务也在快速的发展，会不停的有新增的url和云产品上线，上线之后改造的成本也会增加很多，为了更加高效的解决这个问题，我们会对新增云产品进行IPv6评审，为新增url上线时默认启动双栈。

2.4.2 版本发布测试体系

阿里的APP发版涉及到众多团队，原来已经完成改造的url，可能会因为一次发布，而导致不支持IPv6的情况发生。为了更好的做到IPv6流量占比稳步提升，我们将IPv6流量占比测试纳入到日常发布测试流程体系中，这样在新版本上线之前就可以通过测试及时发现异常，然后更好的修复。

2.4.3 监控测试体系

主要分为两个大的方向，即全局监控和体验监控。全局监控重点检测IPv6占比监控和异常告警、降级率监控和异常告警，然后对异常情况进行及时的分析和解决。体验监控重点关注IPv6耗时监控和告警、长尾数据分析以及用户舆情监控。

✪ 故障管理体系

我们把IPv6流量占比异常下跌纳入到整体故障管理体系中，从故障前的故障等级定义、监控体系，到故障中的应急响应，再到故障后的复盘、演练。每次异常下跌都会明确原因，责任到人，持续改进，最终实现稳步提升。

✪ 奖励体系

我们通过建立阿里巴巴IPv6“基石”奖，鼓励各APP及云产品进行规模化部署，同时鼓励项目组成员在IPv6技术创新及大规模应用上面做出贡献。

三、未来计划

今年我们同步启动了IPv6 Only的试点应用，为第三阶段IPv6成熟阶段做好技术储备。接下来我们还将尝试打造在用户上云的过程中同步实现双栈改造，这样会对企业的IPv6改造效率实现极大的提升。

面向未来的持续创新

P2P的大规模推广，目前受制于WiFi终端IPv6支持度不高，在P2P的视频会议、通话及长短视频应用领域，IPv6均无法很好的施展开来，随着规模化部署的推进，最终会迎来这一技术的大量普及和创新。

HTTP3与IPv6的强强联合，rfc9114使用QUIC协议作为传输层协议，可以有效地降低网络卡顿率和首包延迟。QUIC是基于UDP协议实现网络通信，为了实现对QUIC协议的支持， SLB上需要支持DNAT转发模式（注：在UDP通信中SLB的FNAT转发模式无法携带客户端IP信息）。DNAT转发模式中，IPv6的流量只能做6 to 6的地址转换，不支持6 to 4的地址转换。Aserver进行ipv6双栈升级后，完成了在IPv6网络链路中DNAT转发模式的后端支持，从而实现了整个ipv6网络链路上完整地支持HTTP3协议。

手淘客户端发起IPv6的HTTP3请求，源目的IP分别是（CIP，SIP），SLB通过DNAT转换将请求的源目的IP转换成（CIP，RIP），转发给Aserver；Aserver获取HTTP响应数据后，封装源目的IP（RIP，CIP），将HTTP3响应发送到SLB上，SLB将源目的IP转换成(SIP，CIP)后，将HTTP3响应数据发送给手淘客户端。

总之，IPv6的发展是一次难得的机会，当然整个过程非常艰难，但如果我们克服这些困难，会为未来在互联网领域的持续创新积累下丰富的经验，打下扎实的基础，创造良好的环境。

参考文献

[01] 关于加快推进互联网协议第六版（IPv6）规模部署和应用工作的通知

http://www.gov.cn/zhengce/zhengceku/2021-07/23/content_5626963.htm

[02] 邬贺铨：加快IPv6规模部署支撑网络强国建设

http://www.cac.gov.cn/2022-03/30/c_1648522019215113.htm

[03] Linux 3.10内核锁瓶颈描述以及解决-IPv6路由cache的性能缺陷

https://blog.csdn.net/dog250/article/details/91046131

[04] Department of State Internet Protocol Version 6 (IPv6) Policy Statement - United States Department of State

https://www.state.gov/department-of-state-internet-protocol-version-6-ipv6-policy-statement/

[05] ipv6: Use math to point per net sysctls into the appropriate struct net https://patchwork.ozlabs.org/project/netdev/patch/20200303065434.81842-1-cambda@linux.alibaba.com/

[06] https://nvd.nist.gov/vuln/detail/CVE-2022-1678

[07] IPv6详解 卷一：核心协议实现【M】，北京：人民邮电出版社，2009.

[08] 一种流量控制方法及装置，CN106603256B

[09] 一种流量隔离方法及装置，CN106528362A

[10] 服务限流系统、方法、装置及电子设备，CN111367651A

[11] 速率控制方法、装置及电子设备，CN110278160A

[12] 一种流量控制方法、装置及设备，CN111385214A

[13] 压测过程中的流量调度方法、调度平台和调度系统，CN107872397A