The IT department of Futurewei Technologies, which may be considered the U.S. research and development (R&D) arm of Huawei Technologies, is a good example of a midsize enterprise committed to adopting IPv6 and learning from the transition process. Futurewei is located in Santa Clara, California, U.S.A., and occupies several office buildings with several hundred engineers and staff members. Futurewei manages and operates its own campus networks for daily business needs, and, as a registered U.S. company, operates relatively independently of its parent company, which is headquartered in China.
As part of an ambitious IPv6-enabled next generation campus infrastructure project, the IPv6 transition process began by acquiring dual-stack Internet access and services from Comcast. The IPv6 infrastructure is an overlay logically separated from the existing IPv4 network and is targeted to enable IPv6 transport and services and to effectively explore new concepts in deploying IPv6 in an enterprise environment.
Over the past two years, industry perception about the best practice for IPv6 deployment in the enterprise environment has changed significantly. The core-to-edge approach is viewed as very practical. Tunnelling has fallen out of grace with many IPv6 practitioners, who believe the operational headache is not worth the level of access tunnels provide. More recently, those who have already deployed IPv6 have begun to explore ways to eliminate IPv4 from their environments as soon as possible in order to avoid the costs of simultaneously managing two stacks. In this context, the team at Futurewei is focussed on leveraging recent IETF work to explore deployment options that would improve some of the current best practices.
The environment architecture reflects the goals and design guidelines of the initiative:
1) enable all employees to have IPv6 access to Futurewei and Huawei Intranet- and Internet-based services;
2) explore practical IPv6 deployment and transition options for medium-sized enterprises;
3) enable employees to innovate and collaborate with external partners;
4) and, enable Huawei product teams to test the implementation of their IPv6 innovations and standards.
The first steps were to acquire IPv6 address space and to enable IPv6 Internet access. The R&D center decided to use provider-assigned address space for this medium-sized organization, as it provides an incentive to explore multi-homing constraints and implications. A native IPv6 link was acquired from Comcast Business Services along with a /48 globally routable IPv6 allocation. The address space was distributed along topological and functional boundaries covering several participating teams and test environments (see figure 1).
Figure 1: Futurewei IPv6 Environment Layout
The campus routing topology is organized as core-to-edge (hub-and-spoke), with emphasis on maintaining an IPv6-only stack for as much of the infrastructure as possible. Such an approach reduces operational costs more than a pervasive dual-stack infrastructure and accelerates the transition to the targeted IPv6-only architecture.
All elements supporting end-to-end services were updated to support IPv6. IPv6 has been enabled on all networking infrastructure elements (switches, routers, wifi gateways, service platforms, such as firewalls, and Integrative Directory Services, or IDS), data center resources (compute, storage, load-balancers), and infrastructure services (Dynamic Host Configuration Protocol—or DHCP—and DNS). Key business and productivity applications have also been IPv6-enabled, and employees are provided incentives to use them over IPv6: email, eSpace, file transfer, messenger, VoIP, and voice conferencing, to name a few. Employees are also provided with native IPv6 Internet access.
The project team is helping employees enable their devices—from laptops to iPads—to use the IPv6 infrastructure. The team conducts regular seminars to provide users with the awareness and knowledge necessary to conduct business in an IPv6 environment, and to stimulate and enable innovation.
The environment is instrumented to monitor utilization of the IPv6 infrastructure and services, and to evaluate user experience. Testing new deployment solutions for IPv6 goes beyond functionality; it collects statistics that enable quantitative evaluations. A virtual team consisting of corporate IT staff and IPv6 project resources operate the environment.
Exploring Carrier-Grade Network Address Translators (CGNAT) as an IPv6 Transition Mechanism in Enterprise Environments
In addition to dual-stack, there are other IPv6 transition mechanisms and technologies that have been or are currently being developed within the IETF, which may be required for business in the near future. With that in mind, the IT engineers developed a practical plan to test running code implemented in compliance with relevant RFCs and IETF drafts, including NAT44, NAT64/DNS64, PCP, DS-Lite, 6rd, multicast transition, extensions to DHCP/DHCPv6, and RADIUS, among others. These tests have contributed to progress within the IETF. In fact, a significant amount of work on and preparation for the Port Control Protocol (PCP) demo at IETF 81 and the IP multicast transition demo at IETF 82 were accomplished by Futurewei IT engineers. In addition, the IT department plans to extend and apply these new technologies to the business. For example, the IPv4-based customer data centre used by the marketing department today will be accessible by IPv6 customers around the world via NAT64/DNS64 installed on the site. Video applications and eSpace will be supported by two or more IP multicast transition technologies to accommodate external IP access from customers, business partners, and Huawei offices in China, as well as other parts of the world.
The CGN plus PCP solution first demonstrated at IETF 81 was tested more extensively in our IPv6 lab environment (see figure 2).
Figure 2: CGN Plus PCP Test Layout
In this transition scenario the core of the network is IPv6 only, enabling native forwarding for IPv6 end-to-end. At the same time, IPv4 access is provided over tunnels. The solution can be considered the opposite of 6PE, in which instead of a Multiprotocol Label Switching (MPLS) core with an IPv4 control plane where IPv6 traffic is tunnelled via MPLS, we have an IPv6 core where IPv4 is tunneled via DS-Lite. This solution can be very appealing to large enterprises having to mitigate a shortage of IPv4 (RFC 1918) addresses. At the same time it reduces the footprint of the infrastructure, no longer having to support two IP stacks per node with the inherent additional operational costs.
This solution was used to demonstrate ubiquitous accessibility of resources, such as FTP services, behind provider translating devices. Vodafone partnered with the Futurewei engineering team to run tests over the infrastructure services that could be enabled by its customers or by client applications that need to receive gratuitous flows.
Use Case: Content distribution over an IPv6-only core.
To support a useful IT environment on an IPv6-only core, the Futurewei IT engineers had to devise a solution for distributing content over multicast. In partnership with the Huawei product teams and associated universities, a translation solution for both control and forwarding planes has been developed and tested in the Futurewei IT environment (see figure 3).
Figure 3: Multicast Test Infrastructure
This solution is related to an emerging body of work on multicast transition in the IETF to which Huawei has given strong support. After two years of development, the general problem statement for this work was recently accepted as a formal mboned working group (WG) draft. The primary focus of this problem statement, and the detailed work programme it lays out, is the distribution of broadcast content by service providers (such as Internet Protocol television, or IPTV), but the results will be equally applicable to the distribution of such content in enterprise networks. The basic issue is that content sources and/or receivers may still support only IPv4. Running the core in dual-stack mode and carrying the content in both IP versions is wasteful of bandwidth. The work in hand will specify the mechanisms required to support IPv6-only multicast distribution in the core network interfacing with IPv4 source networks and/or IPv4 networks or subnetworks at the receiving end.
The work programme needed to meet the objectives is laid out in the mboned document and consists of several parts, as described here.*
- A discussion in the mboned WG about how receivers can acquire the multicast group addresses (and unicast source addresses, in the case of Specific-Source Multicast, or SSM) of the channels in which they are interested in the IP version they can use. This problem is much simpler if the receivers are dual-stack.
- A specification of an IPv6 multicast address format that embeds IPv4 multicast addresses, allowing stateless translation between IPv4 and IPv6 addresses. This eliminates the need to provide coordinated translation tables at multiple nodes if the control or data plane crosses multiple IP version transition points. This is already a chartered mboned work item, but the details are still under discussion.
- A related draft on DHCP provisioning of the IPv6 multicast prefixes used in the stateless translation mechanism. This is a work item in the Softwires WG, supporting operation of multicast consistent with the DS-Lite transition mechanism (RFC 6333) that is being done in that WG.
- A draft on translation between the Internet Group Management Protocol (IGMP) and Multilistener Discovery (MLD), needed in Customer Edge equipment (the “B4”) in DS-Lite environments. This has been submitted to the Protocol Independent Multicast (PIM) WG.
- A draft on operation of PIM routers in dual-stack environments, also submitted to PIM.
*References for drafts related to this work follow this article. They still have the status of individual drafts at the time of writing.
The results of the tests referred to at the beginning of this section were demonstrated at IETF 82.
To ensure that as many services as possible are accessed over IPv6, multicast content is delivered to end users (i.e., multicast listeners) over IPv6. The traffic is transported over the IPv6 infrastructure while translation is used at the data centre edge to enable access to IPv4-only content sources. On the control-plane, listeners use MLDv2, PIM for IPv6 is used for routing over the infrastructure, and PIM for IPv4 is used towards the IPv4-only content sources.
The multicast solution described in combination with the CGN-based IPv6 integration option provides an innovative new approach to IPv6 transition that takes into account recent operational experience (in particular, the idea of operating as much of the infrastructure as possible in IPv6-only mode), as well as standardization developments.
IPv6 Exploration Continues: Future work at Futurewei
The IT department at the Futurewei R&D centre plans to expand upon the solutions evaluated thus far and apply them to larger scale deployments. For example, a project is ongoing to enable IPv6-only hosts to access the IPv4-only data center supporting corporate marketing applications. This solution will test NAT64/DNS64 technologies. Another Futurewei project will enable IPv6 operation for eSpace, Futurewei’s unified collaboration platform that facilitates off-campus, off-corporate network collaboration (see figure 4).
Figure 4: eSpace Unified Communication Target Architecture
The Futurewei team is sharing its lessons learned with the community at large to help both technologists and customers with their IPv6 transition planning. Many of the tests performed continue to support the work done in the IETF by applying new ideas in a real environment.
We thank the following people for their comments and support.
Comcast: Jason Livingood, Kent Porter, David Chai, Frank Rudnick, Yiu Lee, Tim Ruelas
Nephos6: Mo Khalid
Viagenie: Marc Blanchet
Vodafone: Loris Cardullo
SI6Networks: Fernando Gont
Huawei: Frank Zhong, James Huang, Yunshan Zhu, Frankie Zhang, Steve Anderson, Wendell Rios, Kenneth Durazzo, Susan Hares, Daniel Lo
draft-ietf-mboned-v4v6-mcast-ps, IPv4-IPv6 Multicast: Problem Statement and Use Cases.
draft-tsou-pcp-natcoord, Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation.
draft-ietf-softwire-multicast-prefix-option, DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes.
draft-tsou-mboned-multrans-addr-acquisition, Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions.
draft-perreault-mboned-igmp-mld-translation, Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation (“IGMP/MLD Translation”).
draft-taylor-pim-v4v6-translation, A Translator For Protocol Independent Multicast (PIM) Interworking Between IPv4 and IPv6.
draft-lopez-v6ops-dc-ipv6-01, DC Migration to IPv6.
Deploy360: Helping You Deploy New Technologies Quickly and Efficiently
The IETF creates protocols based on open standards, but some are not widely known or deployed as quickly as we would like. To help bridge this gap between completed standards and real-world deployment, the Internet Society launched its Deploy360 Programme in January 2012.
Deploy360 collects and creates technical resources from industry experts and makes them available in a free and open environment so other organizations can deploy technologies like IPv6 and Domain Name System Security Extensions (DNSSEC) quickly and efficiently. Deploy360 provides case studies, videos, technical documents, tutorials, and more, and continuously spreads this information through social media, speaking engagements, and ION Conferences.
Have you already deployed IPv6 or DNSSEC?
We can work with you on a case study, tutorial, white-paper, or other resource to help spread your knowledge to those following your lead with their own deployments.
Are you looking to deploy IPv6 or DNSSEC but you’re not sure where to start?
Visit and explore http://www.internetsociety.org/deploy360 to see what we already have. If you are looking for something specific and it’s not there, let us know by emailing us at email@example.com.
The IETF community works hard to finalize standards to help the Internet run better. Now help the Internet Society Deploy360 Programme get real-world deployment information into the hands of the professionals who need to deploy those standards.
To get more involved, email us at firstname.lastname@example.org or visit us at http://www.internetsociety.org/deploy360.