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

为庆祝一年一度的世界 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

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。