LinkedIn从IPv4迁移到IPv6（第1篇）

IPv6

摘要：

本文是系列文章的第一篇。这一系列文章将介绍从IPv4迁移至IPv6需要考虑的各种问题，尤其是诸如LinkedIn这样的大型企业在迁移过程中可能遇到的各种挑战。

正文：

为庆祝一年一度的世界IPv6日（始于2011年6月6日），LinkedIn希望用一种别具含义的方式纪念这一天。过去多个月以来，我们忙于在自己的数据中心内启用IPv6，为此我们设计了全新的体系结构，并在网络、系统、工具等方面做好充分的准备，最终于6月6日在一个过渡（Staging）环境中成功启用了IPv6。此番举措是在所有数据中心内实现全功能IPv4/IPv6双堆栈的一个重要里程碑，在顺利实现这一目标后，下一步将彻底弃用IPv4。

在这一系列文章中，我们将介绍从IPv4迁移至IPv6需要考虑的问题，尤其是诸如LinkedIn这样的大型企业在迁移过程中可能遇到的各种挑战。但首先我们想介绍一些有关IPv4和IPv6的基本信息，以及迁移过程中需要考虑的基本原则。

IPv6简史

IPv6的整个发展史与IPv4的发展密不可分。IPv4于1981年被互联网工程任务组（IETF）正式确立，1992年，互联网社区提议对IPv4寻址方案进行扩展。IETF为此创建了一个工作组；1996年，一系列名为请求注解（RFC）的文档正式确立了IPv6（每个文档名称以RFC开头，后跟用于区分不同文档的编号）。

与此同时为了缓解IPv4地址空间即将耗尽的问题，他们为内部私有网络保留了三个公用IPv4地址段（RFC1597）。大部分组织只需要将少量服务暴露到互联网，因此对公用IP空间的需求其实并不大。通过在组织内部使用私有IPv4地址段，进而将对公用IP空间的需求降至最低，即可减少所需IPv4地址的数量。业界通过这种方式将公用IPv4地址空间耗尽的那一天推迟了多年。

1996年，IETF正式颁布了RFC1918文档，该文档是对RFC1597的改进，其中谈到了使用私有或公用地址空间的设备相互通信的不同需求。三年后，1999年发布的RFC2633中提出的网络地址转换（NAT）技术可以自动对来自私有网络的互联网数据包进行转换，将其转发至公用互联网，并将从公用互联网收到的响应转换到私有网络。内部设备可以借助NAT与公用网络中的设备通信，但无法实现反向通信。但是NAT造成了一些新问题。例如当两家公司合并时，由于在合并前使用了相同的私有IPv4地址段，有时可能需要解决内部路由冲突问题。所有私有IPv4流量有时候看起来都像是来自同一个公用IPv4地址，因此作为公用服务供应商，如果阻止某个IPv4地址的通信，可能会影响到数千个设备或用户。

1995年底发布的RFC1883意味着IPv6时代正式开始。IPv6最初只部署在实验室内某些操作系统和路由器中，随后以此为基础构建了一些公用的实验性网络。随着更多RFC陆续发布，解决了越来越多的实现和其他问题后，IPv6网络逐渐达到生产环境中使用的质量要求，但直到2008年2月，互联网编号分配机构（IANA）将IPv6地址加入域名系统（DNS）的根区域后IPv6才算正式登场，随后IETF在同年三月的会议中进行了一次IPv4停用实验。在大概一小时的实验过程中，工程师测试了在不使用IPv4的情况下可以在互联网上执行的操作。此次实验后，很多软件都发布了相应的补丁。

2011年6月6日，Internet Society发起了“世界IPv6日”活动，很多大公司在24小时的活动期间测试了自己网站在IPv6（作为对IPv4的补充）环境下的表现。此次活动一年后的同一天被称作“IPv6发布日”，很多公司在这一天里将自己的网站切换至IPv6并一直沿用至今。LinkedIn的网站在2014年开始正式可以通过IPv6访问。

今天，IPv6流量已经占到全球互联网流量的10%以上，一些国家的占比更高，例如美国已经达到30%以上，比利时超过了50%。一些移动网络已经以IPv6为主，占到流量总数80%以上。Apple也已宣布所有移动应用必须能够支持纯IPv6网络，并使用NAT64（与NAT类似，但用途是将IPv6数据包转换为IPv4格式）访问互联网上依然使用IPv4的部分。Facebook、Akamai以及LinkedIn还分别发现在IPv6环境下端到端使用应用程序（尤其是移动应用程序）的速度也有了很大提升。

IPv4和IPv6的主要差异

IPv4地址包含32位，IPv6地址包含128位。由于地址更“大”，IPv6标头也更大，但其长度是固定的，IPv4标头封包长度是可变的。更重要的是IPv6不再需要校验，一般来说校验工作是在硬件层面或上层实现的。这种设计有助于降低路由器的负载。最后，在IPv6中路由器不需要拆分数据包，如果需要传递的数据包太大，路由器会向发送方发出一个ICMPv6 Packet Too Big（PTB）信息，让发送方以恰当的大小重新发送该数据包。这些改进降低了路由器处理每个数据包时的负荷，进而提高了路由器工作效率。

IPv6的体系结构确保了设备无需集中化服务，即可通过无状态地址自动配置（Stateless Address AutoConfiguration，SLAAC）技术获得自己的IPv6地址。IPv6有两种主要类型：链路范围（Link scope）和全球范围（Global scope）。本地IPv6地址只能在当前网段内使用，全球地址通常来自路由器所宣告的网络，并会结合接口的MAC地址。IPv6中也存在一种集中化的服务：DHCPv6，该服务基于动态主机配置协议（DHCP），但为了与SLAAC共存进行了少量改动。

迁移至IPv6

迁移至IPv6的过程中产生了一种有趣的“22条军规（Catch-22）”：为了顺利迁移必须将最流行的网站迁移至IPv6，但通常来说小规模网站迁移至IPv6的过程要比大型网站的迁移容易得多。IPv6网络上一台服务器可手工配置并快速完成，但大型网站通常包含很多面向IPv4的路由器、负载平衡器、防火墙、监控工具，以及各种设备和软件，这些东西需要进行相应的转变才能用于IPv6。

通过顺利迁移大型网站通常需要的各种特殊设备和软件，世界IPv6日和世界IPv6发布日帮助互联网社区解决了很多问题。路由器、负载平衡器，以及防火墙逐渐应用了各种修复程序，地理位置的分部也逐渐完善。支持IPv6的Web缓存服务越来越多，Packet too big（PTB）信息已经可以由安全筛选器处理，启用IPv6的DNS基础结构可以实现更快速的响应，除此之外还有很多其他改进。

然而将内部网络转换为IPv6则是一个截然不同的故事：这一过程需要很多其他组件相互配合并需要能够伸缩。对于大规模部署，就算RFC1918空间也不足以对所有内部网络需求进行寻址。每个国家的办公室都需要有自己的网络，云平台也需要大量计算机，因此对于大型网络来说，就算10.0.0.0/8也显得不够大，地址空间的重叠也会成为一个麻烦事。使用诸如NAT等解决方案对地址空间进行转换可以缓解此类问题，但这种解决方案也会产生一系列新问题，例如应用程序内嵌入的IP地址，通过伸缩处理更大数量的转换，以及由于引入“NAT防火墙”造成的各种安全问题。

在现实环境中，可以直接关闭路由器的IPv4功能并启用IPv6，但大部分情况下这种做法并不可行。我们认为内部网络进行过渡的最佳策略是首先迁移至双堆栈环境，并通过妥善制定的“淘汰”策略彻底弃用IPv4。这样大家可以有更多时间熟悉IPv6，并将自己的工具、软件，以及流程逐步迁移至IPv6，经过这样的步骤，只有很少一部分流量需要通过IPv4处理。然而这种方式最大的不足在于，为双堆栈环境提供支持不仅更复杂，而且维持两个网络的大量运维工作会拖累新服务的部署速度，如果两种协议未能同步还可能造成新的问题。IP地址的管理也会变成一种复杂的任务，因为IPv4和IPv6地址空间的映射通常还需要很多其他功能，例如ACL的实现、路由汇总、负载平衡器等。

因此有必要面向未来做好准备并尽快着手IPv6的迁移，随后即可按部就班将越来越多的流量顺利迁移至IPv6。由于为两个网络栈提供支持会导致工作复杂度提升将近一倍，一旦迁移至IPv6还需要尽快彻底弃用IPv4。

LinkedIn的IPv6迁移

双堆栈环境可以帮助你循序渐进地将服务器迁移至IPv6。一些应用程序的迁移难度可能略低，例如某些核心UNIX服务的迁移就是一种唾手可得的工作。

6月6日，我们决定开始迁移自己的某个过渡环境，尤其是LinkedIn用于在发布“新”服务前进行测试使用的过渡环境。我们计划为该环境中所有系统添加一个全球IPv6地址，并对尽可能多的核心服务进行迁移，借此提高IPv6网络流量的比例。

我们需要确保此番迁移不会破坏尚未测试的服务，为了实现必要的控制，我们利用了IP双堆栈环境的一些基本特性。例如，我们的大部分软件是通过Java开发的，默认情况下Java应用程序在运行时需要通过一个声明（Declaration）宣告自己在使用IPv6。因此我们无需担心软件突然发现IPv6并自行开始使用该环境。我们还决定不为任何使用全球IPv6地址的计算机的主机名添加AAAA DNS记录，这样使用其他语言发起的连接就不会通过IPv6运行。借此可以确保其他软件、工具，以及实用程序可以像以前一样继续通过IPv4运行，整个环境不受任何干扰。

从那天下午开始，我们在几分钟内为超过1500个系统添加了静态的全球IPv6地址。对于任何此种规模的系统，自动化机制都非常重要，可以帮助我们快速将变更部署给整个系统。在确认通过IPv6正常运行没遇到任何错误后，我们为这些主机增加了AAAA记录，借此这些操作系统将首选使用IPv6而非IPv4。所有这些工作完成后，开始将某些核心基础结构服务（DNS、syslog、SMTP、NTP、集中身份验证等）的流量从IPv4迁移至IPv6。在大概一个小时内，我们通过受控的方式将基础结构内的多个此类服务切换至IPv6网络中。未来几个月里，还将继续将更多基础结构服务迁移至IPv6，同时也将努力让Rest.li等自行开发的软件框架优先选择使用IPv6而非IPv4。

除了上述工作，为了向成员提供服务，我们目前还在建设一个全新数据中心。这个数据中心在设计伊始就充分考虑了IPv4和IPv6双堆栈，此外还包含其他很多先进技术。这个数据中心在LinkedIn内部被称之为Project Altair，之前的很多博客文章中曾经进行过介绍。

借助启用IPv6的过渡环境和生产环境，我们可以将越来越多的内部流量迁移至IPv6。在6月6日的首轮工作成功实现后，对于将其他内部环境迁移至IPv6我们也更加自信。

一旦适应IPv6流量后，该开始考虑弃用IPv4并让数据中心运行在纯IPv6环境下。这个目标并不遥远，我们计划在2017年内全面实现。同时为IPv4和IPv6提供支持意味着需要付出将近两倍的工作量，因此一旦决定采用IPv6，需要确保过渡过程尽可能短。然而很多供应商和软件产品目前并不能全面支持IPv6，为了实现我们最终的迁移目标，还需要针对这种情况采取必要的措施。

LinkedIn内部成立了由“IPv4处理专家”组成的“AAAA团队”。这是一个很赞的技术项目，我们也希望能有更多类似我们这样的组织将自己的数据中心迁移至IPv6，只有通过这种集体合作的方式才能顺利解决妨碍数据中心和云环境全面采用IPv6的遗留问题。请加入我们一起为最终目标贡献自己的力量。

致谢

本文撰写过程中得到了AAAA团队下列成员的巨大帮助：

Zaid Ali、Sriram Akella、Andrey Bibik、Donaldo Carvalho、Bo Feng、David Fontaine、Prakash Gopinadham、David Hoa、Sanaldas KB、Henry Ku、Prasanth Kumar、Vikas Kumar、Tommy Lee、Leigh Maddock、Navneet Nagori、Marijana Novakovic、Ved Prakash Pathak、Stephanie Schuller、Chintan Shah、Harish Shetty、Andrew Stracner、Veerabahu Subramanian、Shawn Zandi、Andreas Zaugg、David Paul Zimmerman、Paul Zugnoni。

作者：Tim Crofts，阅读英文原文：IPv6 at LinkedIn Part I, "ChippIn'" Away at IPv4