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

数据中心 IPv6

摘要：

本文将从网络运维的角度介绍为什么领英需要创建同时包含IPv4和IPv6的全球网络，以及领英在自己的数据中心内启用双堆栈环境，并期待着有朝一日能彻底弃用IPv4的过程中所面临的挑战。

正文：

合作者：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