一、网络基石升级的挑战
网络是互联网的水电煤，而IP 是网络基石。因此，我们将 IPv6 到 IPv4的演进称为网络基石的升级。
阿里 IPv6 升级的过程中，首先面临的是超大业务规模的影响，影响范围覆盖了电商、文娱、物流等 20 多个业务、集团内外 5000+ App 数量以及10w+云产品和基础设施的基础网元设备。而以上影响会导致数百亿级别的资损、用户体验损伤以及服务崩溃。
同时，技术上也会面临非常复杂的规模，从端到管到云到用，南北向涉及全链路、全栈的演进，东西向涉及到不同业务系统，影响规模非常之广。
此外，我们还需面对复杂的网络生态环境。网络生态既有设备端、网络环境，也有基础运营商。设备端会面临不同平台、不同厂商的网络环境下保障设备的应用问题，另外，我们需要磨平不同运营商和地域之间的差异，保障用户体验的统一性，以及避免IPv6统一升级之后带来新的网络风险。
IPv6的升级不仅仅是地址从32位升级到128位，还包括三个更深层次的含义：
第一，国家强网战略。希望在网络规模、用户规模以及流量规模上全部实现全球第一。
第二，地址资源的经济收益。升级到 IPv6 后，可以产生数十亿级别的经济收益。
第三，万物互联的基石。下一代网络多为5G、AI、IoT、大数据等，对于地址的需求呈指数级增长，因此IPv6也是下一代网络互联的基石。
二、全栈异步平滑演进
针对大规模业务、全栈技术演进以及复杂网络生态，我们的升级策略为南北向贯通异步演进，东西向解耦平滑升级。
南北向主要针对云、管、端三个层面，东西向主要针对不同业务做横向解耦，并进行常态化的运营支撑。
云底座是 IPv6 贯通的核心，因此，首先要打造高性能的IPv6云底座。云底座涉及底层机房、物理层、虚拟网络层，每一层需要改造的内容均十分繁杂。
比如，首先要解决高性能的负载均衡网关。IPv4向IPv6演进的过程中，有很长一段时间为IPv6和IPv4并存，需要对两者同时提供支持。因此负载均衡网关要支持双栈挂载，支持4-6平滑演进，而这增加了路由负担。
容器化和 FaaS 化是未来的业界趋势，多租户挑战下，大规模路由信息如何保障？双栈路由会导致会话表规模翻番，长度扩大、资源不足的情况下，如何得到高性能的虚拟网卡？针对以上问题，我们实现了硬件加速的双栈智能虚拟网卡。路由时，从原先VM 的 CPU 下放到 FPGA ，增加虚拟网卡在路由时的速度和性能，并扩充了多级缓存技术，加快路由速度。无论是大规模高性能网关还是硬件加速的虚拟网卡，最终都需要落实到具体的路由协议进行控制。
因此，我们实现了大规模 IPv6 路由控制方案AliBGP，能够实现动态分组，将同组地址聚合到一起，降低1/N 的时延和耗时，能够实现快速流量切换。调度时能够实现业务租户之间的隔离，也能实现流量隔离，同时支持软件的热修复。
云底座升级后，第二个挑战在于如何面对大规模恶意 IPv6 流量的安全问题。流量安全是 IPv6 规模化应用的保障。首先面临的是如何解决大规模、高精度的IPv6 地址信息系统问题。一切安全都基于 IPv6地址库，我们将 IPv6地址基于用户特征、账户特征和行为特征的属性做聚类，与原先的IPv4地址库进行同源配比，基于 IPv4 地址库快速建立海量 IPv6 地址库，构建 IPv6 地址库的地理信息系统。
针对 IPv6应用层的恶意流量清洗以及防 IPv6 DDos攻击，我们通过人工智能深度学习以及自动反馈建立了智能的流量清洗系统。
IPv6部署初期，基础网络发展不平衡是必经之路，不同路径、不同运营商的IPv6双栈覆盖度不高，且持续演进变化。另外，不同运营商、不同地域、不同网络制式下的网络成功率、时延等质量参数不稳定。为了保障用户体验，我们必须解决管道质量的可测量、可观测，这也是应用层实现高可靠的基础。
针对以上问题，我们实现了面向管道的大规模主动拨测。选择合适的应用、地域、机型、用户、设备以更好地支持 IPv6，提前为设备做好质量测量标准。并在此基础之上建立了全景式管道质量观测平台，更好地支撑业务规模化。
从端侧协议栈到业务接入层的IPv6贯通与双栈平滑演进是IPv6应用的最后一公里。
客户端侧，存在IPv6因报文头过大，IP包MSS降低导致大包穿透性降低的问题。统一接入层存在IPv6基础能力缺失，比如 IPv6 to 6 NAT 以及运维方面IPv6地址编码和解析等问题。客户端的痛点主要通过客户端融合网络协议栈来解决，统一接入层在控制面将IPv6的能力补齐，实现管道端到端的IPv6贯通。
端侧，我们提供了高性能的基础网络库，解决移动端高性能网络的诉求。移动端高性能网络库是终端用户IPv6体验的保障，因此我们需要解决复杂的网络体验以及浓度与体验并重的问题。
首先，需要解决如何在端上判断IPv6是单栈还是双栈支持。发包探测会对用户体验带来极大影响，因此必须实现本地快速判断，我们通过本地 UDPBinding的方式实现了判断。但本地UDP Binding的判断存在误差，需要解决纠偏问题。我们通过系统原生状态通知、网关地址判断以及 DNS 地址判断实现了本地快速判断。
另外，发生问题时，我们提供了诊断能力。内置了 HTTP协议、PIN协议、 TCP 协议等不同维度判断 IPv6 的本地质量和支持性问题。
同时，实现了多连接、多通道的能力。调度时采用 v6、v4 双地址下发，建联时优先使用IPv6，如果无法在 200毫秒以内完成，则使用IPv4建联。过程中，参数会根据具体的网络情况做细微的智能化调整。并在多连接的基础上实现了多通道能力，主要包含两个维度。其一为mptcp能力；其二，在业务应用层也建立了两条通道，在不同情况下会选取不同的实现。mptcp 需要服务端的支持，而当前国内大部分业务对此并未提供很好的支持，因此在应用上更多的是使用上层双连接实现多通道的突破。
端、管、云均已支持IPv4到IPv6的平滑演进。但是对于业务应用而言，想要保障应用的高可靠、高可用，仅仅依靠每一层的双栈支持依然不够，需要更完整、更可靠的控制面的控制。因此，我们实现了精细化实时IP 调度系统，使东西向解耦彻底可控，逐步实现业务的平滑演进。
该系统可以针对不同业务场景、不同设备类型以及不同网络环境做精细控制。针对大规模精细化实时调度，可以基于设备维度、应用维度、用户维度、版本维度、地域维度等精细化维度实现调度。最初的调度需要依靠人力，后续可逐步演进为自反馈系统。
针对大规模业务灾备恢复时间过长的问题，我们基于业务探针在高频业务插入了旁路指令。需要调度时，可将调度指令通过高频业务携带给端侧、终端，终端快速响应调度服务，最快可达秒级响应。
另外，我们基于PaaS的核心能力基座实现了端到端的完整解决方案，以支撑集团大量 App 快速迁移，包括网络、环境感知、策略体验、融合数据产品以及云端调度服务。
实现了南北向贯通，东西向解耦后，下一步需要实现常态化运营支撑，保证用户浓度和用户体验，并解决日常业务迭代对IPv6带来的冲击。
研发期我们在端侧建立了IPv6环境模拟以及线下工具验证。发版前，基于自研 T-Monkey平台实现了自动化验收。线上运营期，对浓度和体验进行监测。最终实现对研发全生命周期的管控。
同时在内网， IPv6也实现了逐步覆盖。对于大量小业务的长尾域名进行逐步清空，并实现流量路径全覆盖，确保IPv6 高浓度不回退，用户体验不劣化。
三、规模与体验 
IPv6在阿里巴巴的发展可分为四个阶段：
第一阶段：2016年，IPv6 主要解决苹果 App store 的上架审核问题。
第二阶段：2017 年中办发布 IPv6规模化部署行动计划，阿里巴巴也在 2018 年首次提出了 IPv6 MAU 达 1 亿的目标。2019年，阿里巴巴集团应用淘宝APP MAU首次破亿。
第三阶段：从面向用户规模转向面向流量占比，重点围绕提升 IPv6 的实际应用占比展开，集团淘宝 IPv6 流量占比首次超过60%。
第四阶段：提出了IPv6常态化诉求。要求存量业务 IPv6 浓度必须达到80%，增量业务全量支持 IPv6，目前已全面实现并超越目标。
目前，MAU已达13亿+，最高浓度95%以上，集团内 App 超200。耗时相比于IPv4降低11.4%。IPv6成功率已达3个9。
四、未来与展望
未来，IPv6的演进主要包含以下三个方面：
第一，IPv6-only进行规模化突破。
第二，IPv6 下 P2P 的应用。IPv4 的最大弊端在内网和外网之间单向导通，其核心障碍为地址数不够，中间加了NAT无法直接访问，无法为每一个设备做公网定位。而有了IPv6之后，突破了地址的限制，也可以实现 P2P的大突破。
第三，解决应用层大量HTTP/3over IPv6 的问题。
