过去几年，Facebook一直在推动其数据中心基础设施从IPv4向IPv6的过渡。起初，Facebook主要采用双栈技术，将IPv6协议添加到全部的IPv4基础设施上，对内部网络进行改造升级。Facebook已决定针对所有新的联网数据中心群集，全部实现IPv6-only部署。为此，Facebook致力于将其运行的所有应用程序和服务，全部迁移到数据中心使用和支持IPv6的设备上。

       目前，Facebook公司99%的内部数据传输已经完成IPv6网络改造，50%的设备集群支持IPv6-only。Facebook预计，未来几年内，将实现全部基础设施升级到IPv6，剩余的IPv4群集“退役”。

       然而目前，在全球范围内，只有15%的用户使用IPv6访问Facebook。因此，Facebook必须找到一种方法，在其所有数据中心基础设备全部运行IPv6-only架构后，继续为另外那85%只能访问IPv4互联网的用户提供服务。

       所有访问Facebook的请求，通常在登录到服务器之前，需要先通过一系列负载均衡设备。这些负载均衡设备在一定程度上充当了代理服务器，因此，Facebook可以通过这部分设备保持对IPv4的支持。这使其能够在保持数据中心所有内容支持IPv6-only后，仍然可以提供IPv4的流量服务。

       在Facebook网络中，有两个基于软件的负载均衡系统同时运行：一个是运行在TCP/IP协议第4层负载均衡（L4LB/shiv），另一个是运行在HTTP/HTTPS上的7层，既应用层负载均衡系统（L7LB/proxygen）。我们采用了支持IPv6-only的数据中心集群，同时对软件负载均衡进行了一系列更改，以增加对IPv4外部请求的支持（所有内部请求都只支持IPv6）。

       所有访问Facebook的请求，通过一系列网络设备进入Facebook网络体系后，首先由路由传输到使用BGP技术的L4LB服务器。L4LB通过ExaBGP发布其可公开路由的虚拟IP地址（VIP）。在双栈集群中，这个可路由的主机IPv4地址被用作BGP的下一跃点地址，标识IP包所经过的下一个路由器。而IPv6-only的服务器不需要这个地址。实际上，IPv6-only服务器使用一个IPv4的链路本地地址代替了BGP的下一个地址。这个链路本地地址允许L4LB服务器和路由器之间进行通信，但无需为服务器分配可路由的IP地址。

       随后，L4LB服务器通过IP隧道将请求转发给L7LB。在双栈集群中，所有IPv4通信都封装在IPv4隧道中，所有IPv6通信都封装在IPv6隧道中。然而，如果由于L4LB和L7LB没有可路由的IPv4地址，IPv4隧道将不再可用。相反，我们增加了对L4LB的支持，使其可以将IPv4流量在IPv6内进行隧道传输。我们的L4LB使用IPVS将流量转发到L7LB，但用来设置IPVS的工具不支持混合IP版本的隧道。因此，Facebook创建了开源的gnlpy，它是一个通用的netlink Python库，允许L4LB直接使用netlink设置IPVS转发。

       L7LB服务器接收封装在IPv6隧道中的IPv4客户端请求。要处理该请求，L7LB服务器需要先解除隧道的封装。我们以前使用默认的Linux隧道模块，但是这些模块只支持对相同版本的IP隧道进行解封。为此我们创建了另一个定制的内核模块，可以对相同版本或混合版本的隧道进行解封。在解除封装后，该模块将原始客户端的请求推送到服务器的环回接口上之后，L7LB就能够像往常一样接收请求并响应。L7LBs可使用DSR（直接服务器返回）的设计，将响应直接发送到客户端，而无需通过L4LB。即使服务器没有可路由的IPv4地址，我们也可以通过设置IPv4默认网关和链接本地地址将其配置为发送IPv4响应。

       数据包传输的过程如下所示：

       首先，IPv4的访问请求进入Facebook网络并被路由到L4LB。其次，L4LB将数据包封装在IPv6隧道中，并将其发送到所选的L7LB。L4和L7 LBs不在同一机架中，这就是为什么隧道不能使用IPv4本地链路而需要IPv6的原因。最后，L7LB接收请求，解除封装，并将响应直接发送回客户端。

       虽然，IPv4数据中心集群要被完全淘汰还需要若干年的时间，但Facebook现在的处境是，他们只能将基础设施的一部分转移到IPv6，因为他们必须继续支持那些尚不支持IPv6的用户，而不能切断他们的互联网服务。未来，当Facebook不再必需提供这部分功能时，他们可以很轻松地关闭它。

       (本文来源：Facebook Engineering,作者：Glenn Rivkees，翻译：张彤）