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

合作者： Tim Crofts

在这一系列文章的第1 篇中，我们介绍了将内部网络迁移至IPv6 的原因。领英（LinkedIn）网站从2014 年起即可通过IPv6 公开访问，而我们的员工在这之前早已可以通过IPv6 访问公众互联网。虽然很早以前我们网络中的大部分组件就已支持IPv6，但直到最近内部数据中心依然运行在IPv4 下。本文我们将从网络运维的角度介绍为什么需要创建同时包含IPv4 和IPv6 的全球网络，以及开始在自己的数据中心内启用双堆栈环境，并期待着有朝一日能彻底弃用IPv4 的过程中所面临的挑战。

网络设计：回到未来

除了链路本地（Link-local）地址和现已废除的站点本地（Site-Local）地址等例外情况，所有IPv6 地址均已全球可路由。通过IPv4 RFC1918 空间我们已经知道使用这种地址的私有网络是不会“泄露”到互联网的。然而在IPv6 网络中这一点还无法保障，因为所有全局IPv6 空间都是全球可路由的。现在设计数据中心时需要实施更稳健的安全策略，因为流量可能同时源自内部和外部。现在已无法通过某些简单的策略只允许或只拒绝RFC1918 地址。

当所有地址都全球可路由时，数据包可能会通过不同路径到达同一个目的地。如果转发路径（Forward path）的设计不够谨慎，可能导致数据包通过一个防火墙出站，通过另一个防火墙返回的情况。防火墙是有状态的，这意味着它们会记住内部计算机与外部计算机之间的连接状态，这样才能自动允许返回的流量通过防火墙。但是跨防火墙分享状态这种做法很难实现，并且可能不够安全。更重要的是，路径中的某些部分可能会通过安全性不那么高的公众互联网传输，而非通过内部网络进行。

使用IPv6 时无法轻易通过查看目标IP 地址是否包含在RFC1918 空间来确定流量是内部还是外部的。内部和外部流量哪怕是虚拟的，也依然需要隔离。为了实现这种隔离，必须重新沿用NAT 技术诞生前的网络设计思路。换句话说，我们“回到未来”了。

NAT 使得深藏于数据中心内的计算机可以直接访问互联网，从本质上来说这需要建立一对一的 NAT 连接。我们决定在自己的数据中心内设置一块不公告到互联网的 IPv6 地址段，这也意味着所有位于这个地址段内的计算机必须通过 DMZ 中设置的一系列代理或网关访问互联网。为确保整个体系结构尽可能简单，我们不希望内部计算机在无法通过 IPv6 直接访问互联网的情况下可以通过 IPv4 直接访问。由于打算实施双堆栈，需要禁用 IPv4 上的所有 NAT。这样内部的所有计算机无论使用 IPv4 或 IPv6，都必须成为多宿主（Multi-homed）计算机。

通过使用边界网关协议（Border Gateway Protocol，BGP），可以将一个路由器所知道的 IPv4 和 IPv6 路由通过 IPv4 或 IPv6 连接公告给周围其他路由器。由于领英的最终目标是彻底弃用 IPv4，我们决定不让公告跨越网络堆栈，我们的 IPv6 路由公告都将只通过基于 IPv6 的 BGP 会话对外公告。

增加新的网络堆栈要求安全性至少要与原本的 IPv4 环境相当。此时一种方法是使用筛选器拒绝所有 IPv6 流量并从这里入手。然而一旦设备可以感知 IPv6，当它无法通过 IPv6 到达目的地，并且应用程序无法“优雅”回退至 IPv4，或无法及时实现回退时服务可能会中断。因此我们选择了另一种方法。

另一种方法是将现有的访问控制列表（ACL）直接从 IPv4 转换为 IPv6。这种方法的效果到底有多大不同？举例来说，将 ICMP 筛选器转换为 ICMPv6 筛选器即可让 Ping 数据包直接到达目标计算机，但正如这一系列文章的第1 篇中提到的，ICMPv6 的Packet Too Big（PTB）信息是IPv6 独有的，这种信息对通过封装隧道（Encapsulating tunnel）进行的，或使用了巨型帧的通信至关重要。以太网IP 数据包通常最大只能达到1,500 字节，但隧道技术会将一个数据包封装到另一个数据包内（例如 NAT64 ），而为了通过高速链路实现更快速的传输，可能需要使用巨型帧（超过 1,500 字节）数据包。为避免遇到难以诊断的网络连接问题，必须确保能够顺利生成、接收和处理 PTB 信息。由于 IPv4（以及其他类似情况）没有 PTB 的概念，因此不能直接将现有 ACL 转换为 IPv6 版本，否则将无法提供对 PTB 信息进行授权的规则。

最终我们成功实现了通过访问控制列表（ACL）为环境、计算机等提供保护这一目标。在 IPv6 网络上启用两个设备并创建双堆栈之前，如果不创建与 IPv4 规则等价的 IPv6 ACL 规则，设备间的通信可能会中断。

另外我们还使用虚拟 IP（VIP）将客户端通过一个 IP 地址连接到多个服务器。IPv4 和 IPv6 网络中这些 VIP 的配置略有差异。例如为了正确发送到最终的目标服务器，一些处理 VIP 的负载平衡器被配置为重写数据包的以太网部分。无论 IPv4 或 IPv6，这个服务器必须能用自己的原生协议处理数据包。因此如果某个 VIP 是双堆栈的，这意味着该 VIP 代表的所有计算机都必须是双堆栈的。在负载平衡器的配置中，IPv4 和 IPv6 的 VIP 配置是两个不同的配置选项，但我们不希望在 DNS 中为 VIP 设置不同名称。同理为了避免产生其他技术债，由于最终目标是完全使用纯 IPv6 环境，我们也不希望使用诸如 vipname-v6 这样的主机名。因此在 DNS 端，当服务器可以开始处理 IPv6 流量后，会给 VIP 名称增加一条 AAAA 记录。

通过上述问题我们意识到，为设备创建 IPv6 地址架构可以帮助我们在并非所有计算机的主机名都有 DNS AAAA 记录（或反向 DNS 记录，如果需要的话）时实现很多目的，例如根据不同机器之间的互访需求定义 IP 规则。

为设备提供怎样的 IPv6 地址？

正如在第 1 篇中提到的，我们不想为主机名添加 DNS AAAA 记录，因为在添加该记录后，到这些服务器的连接将首选使用 IPv6。我们必须首先确定所有软件都支持 IPv6，随后才能启用双堆栈服务器。

另外我们也不希望将 IPv4 地址嵌入 IPv6 地址（例如：2620:abcd:efef::192.168.1.1），原因在于：

1. 上述例子中的地址在接口上将被表示为 2620:abcd:efef::c0a8:0101；
2. IPv4 地址空间枯竭的问题还没有成功解决；
3. 弃用 IPv4 将造成技术债。

为了轻松地将 IPv4 ACL 转换为 IPv6 ACL，我们依然需要能在没有为主机名添加 AAAA 记录的前提下，通过计算机的 IPv4 地址知道它的 IPv6 地址。（ACL 决定了哪些计算机获得了授权，可以访问某一特定计算机。）

对于这个问题，我们的解决方案是将每个 IPv4 网络与 IPv6 网络配对，并使用 IPv4 地址最后两个位组（Octest）的十六进制格式作为 IPv6 地址的最后一个 Quibble（IPv6 地址用 Quibble 表示，每个 Quibble 为 4 字节 /16 比特，用冒号分隔）。选择使用最后 2 个位组的原因在于，这样的话我们一些最小规模的 IPv4 网络就可以与使用 /23 掩码的 IPv6 网络配对（为了放入同一个机柜中，大部分此类网络都是 /24 或 /25 规模的）。我们使用了与 IP 地址管理系统（IPAM）中相同的子网配对选项。通过这种方式，即可针对特定 VLAN 当前分配的 IPv4 子网获得 IPv6 子网。

为了简化 ACL、路由聚合，以及内外部网络边界等问题，我们决定为目前和未来的所有数据中心使用一个足够大的 IPv6 网络。这样做也可以简化内部 IPv6 流量的识别工作，因为只需要查看地址的来源块（Block）就够了。

为了进一步简化这一系列过程，我们还决定为所有与服务器连接的路由器接口设置 fe80::1 作为链路本地 IPv6 地址。在领英的所有数据中心内，服务器始终会使用 eth0 接口访问默认网关，因此默认网关始终可通过 eth0 接口的 fe80::1 地址，即“fe80::1%eth0”的方式访问。不需要使用路由器公告信息即可建立默认网关。我们的所有 IPv6 地址都是静态的（因为动态 IPv6 地址需要在 DNS 中维护），因此客户端总能找到要连接的服务器。由于服务器数量众多，全天时间内会发生多次主要为静态形式的服务器更新。通过将 FE80::1 作为网关，使用特殊脚本或工具解析路由表即可知道任何网段均已不需要默认网关。对于 IPv6 地址或默认网关来说，任何动态架构都必须通过持续广播有关网络的信息让系统保持动态的状态。但使用静态状态后，无须确保必须及时将信息广播给服务器和设备就可以让它们维持自己的网络状态。我们的服务器 IP 就使用了这样的架构。我们的网络设备使用了更传统的架构，其中点对点链路通过更大的地址块组成了一个独特网络，而环回（Loopback）地址则来自专用的 IPv6 地址空间。

对于服务器，我们使用了静态的 IPv4 和 IPv6 IP 地址。我们会使用上文提到的 IPAM 工具记录所有网络和主机名。这样在供应设备时就可以知道每台主机位于哪个机柜，使用哪个端口连接。IPAM 信息会纳入 DNS 中，这样就不需要使用动态 DNS 将 IP 与主机名映射。此外我们的应用程序堆栈会通过发现服务将服务映射为主机名。考虑到这些因素，使用静态 IP 地址的做法更合理，确保了我们可以控制 IP 的分配不会改变，并且应用程序堆栈也可以使用持续不变的名称和 IP 地址对应关系。

与 IPv4 策略的差异之处在于，无须使用 NAT66 为代理和其他 DMZ 功能提供支持，即可通过 IPv6 访问互联网。DMZ 中所有主机将使用多宿主连接在数据中心提供内部 IPv6 连接，并通过防火墙提供到互联网的外部 IPv6 连接。

为了支持领英实现纯 IPv6 数据中心这一最终目标，我们需要确保终端访问控制器访问控制系统（Terminal Access Controller Access Control System，TACACS）、网络时间协议（NTP）、系统日志（Syslog）、简单网络管理协议（SNMP），以及 sFlow 等其他服务均可支持 IPv6 源地址，并在功能方面能与 IPv4 看齐。也就是说应用程序层需要支持 IPv6，用于管理所有这些设备的工具也需要支持 IPv6。最终所有设备需要能通过纯 IPv6 网络供应。面对 IPv6，零接触供应（Zero Touch Provisioning，ZTP）技术依然有待完善，因为其中还用到大量遗留组件。我们将在这一系列文章的第 3 篇从较高角度介绍如何让软件或应用程序能够在 IPv6 网络中正常运转。

致谢

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

Zaid Ali、Sriram Akella、Andrey Bibik、Donaldo Carvalho、Brian Davies、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。

作者： Franck Martin ，阅读英文原文： IPv6 Inside LinkedIn Part II

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

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