Where to Start Deploying IPv6 in the Enterprise
by Scott Hogg, on Oct 11, 2017 4:27:45 PM
One of the common questions that often gets asked shortly after some introductory IPv6 training is “Where do I start deploying IPv6?” In the early years of IPv6’s adoption there were debates about how IPv6 should be deployed in enterprise networks. Should organizations start to deploy IPv6 at the core and then work their way out to access networks or should they start at the edge and move toward the core? In those early days for IPv6, both of these methods considered using IPv6-in-IPv4 tunnels as a method to fill in the gaps where there was IPv4-only connectivity. As time went on, the dual-protocol approach became the recommended transition strategy and tunneling fell out of favor. Now that IPv6 is more ubiquitous on the Internet, with virtually all end-user mobile device operating systems support dual-stack, and since more popular content is available over IPv6, the recommendation for deploying IPv6 in internal enterprise networks is changing.
IPv6 Starts at the Internet Perimeter
For at least the past decade, the prevailing recommendation for enterprises is to start to deploy IPv6 at the Internet perimeter. The common wisdom to start your IPv6 deployment at your Internet edge makes total sense because that is the point in your network topology where upstream Internet connectivity exists. Therefore, it is a given that you must enable the Internet perimeter first and then proceed toward the core network of the enterprise.
Before you can bring IPv6 in to your organization you first must establish upstream Internet connectivity. This involves contacting your upstream ISP and asking for them to enable IPv6 on your connection. The ISP will allocate some of their IPv6 address space for the link between you and them (probably a single /64) and then configure either static or dynamic routing (probably BGP). Once you have IPv6 configured on your router and are advertising your assigned IPv6 prefix (probably assigned to you by your Regional Internet Registry (RIR)), you can then test your IPv6 Internet connectivity. This approach is recommended by Cisco and Shannon McFarland, Distinguished Consulting Engineer at Cisco, has been extolling this method for many years. This has also been the mandated strategy for U.S. Federal Government entities to have IPv6-enabled the Internet edge. Many federal organizations have IPv6 at their Internet edge and on their web site, but they have yet to fully deploy an IPv6-enabled core network.
Once you have achieved this IPv6 internet edge configuration, the next step would be to enable IPv6 on your perimeter firewalls and security systems. After that, the next step is to deploy IPv6 into the core backbone.
IPv6 Across the Core
During this phase of your IPv6 deployment you will need to deploy IPv6 across your core network. IPv6 must be enabled one layer-3 hop at a time as you bring it inward to your organization’s core network. As this simple video illustrates, IPv6 moves across the backbone network without leaving any gaps in connectivity. The blue lines represent links that have IPv4 enabled on them. The red lines represent IPv6 enabled links that are configured in sequence one at a time. The IPv6 migration progresses one router and link at a time in a cohesive manner until it has been enabled across the entire core network.
This process of adding IPv6 to the core network should be fairly easy because you are simply overlaying a new protocol on top of existing links and interfaces. The IPv6 addressing is straightforward and you will use a /64 for each of these links from your overall IPv6 address block. The IPv4 routing protocols you are intimately familiar with already support IPv6 and you can leverage your knowledge of these protocols to simply add IPv6 as a new address family.
Once you are at this point you have a choice of what to do next: Should you configure IPv6 in the data center or on access networks first?
Motivation for IPv6-Enabling Users
At this point, if your plan was to start by enabling IPv6 on the IPv4 systems in the data center, then those servers and services would only have dual-protocol Internet connectivity. Since the end-user networks would be IPv4-only at that point, then the end-users would continue to use IPv4 to connect to internal and external applications. Many of the applications and services in the private on premises enterprise data center are not reachable directly from the Internet. IPv6-enabling the data center networks at this point does not provide significant benefit compared to the work involved.
Many end-users have IPv6 on their mobile devices and in their homes or when they are working from a remote location. As a result of this growth in IPv6 adoption, IPv6 adoption is accelerating while IPv4 is nearing its peak. LinkedIn has observed that more than 50% of their traffic is using IPv6. Also, in some cases, IPv6 can even perform better than IPv4 and Facebook prefers IPv6 for user connections.
These end-users are often using IPv6 and they don’t even realize it, nor do we want them to be cognizant of which IP version they are using. We want to shield end-users from any knowledge of IPv4 or IPv6 addresses but we do want to provide them the best end-user experience when connecting to the Internet and to their applications. End-users may be using IPv6 when they are on their wireless mobile devices or when they are at their homes or connected to a public wireless network. However, they lack IPv6 Internet connectivity when they are at work. Therefore, we want to give end-users the option to use the best performing transport protocol resulting in the optimal end-user experience when they are in the office as well as at home.
An enterprise will gain more benefits from providing dual-protocol connectivity to their end-users than configuring dual-protocols in the data center. The priority for enterprises should be to IPv6-enable end-user access networks.
IPv6 Access Enablement Preparation
When you get to the point of IPv6-enabling the access network you need to be prepared. Before you enable IPv6 on the edge, you must validate that you have solid contiguous IPv6 connectivity across the core network. You must also verify that your users will be able to have their IPv6 connections traverse the security perimeter and the other security measures such as intrusion prevention and content filtering, which will need to be IPv6-enabled.
As soon as you assign an IPv6 address to the first-hop router for the access network, it will immediately send out ICMPv6 Router Advertisement (RA) messages indicating to the end-nodes that IPv6 is available. In a data center environment you may prefer to disable ICMPV6 RAs and use static IPv6 addressing for the hosts and turn up IPv6 deliberately on one server at a time. However, in an access network, you will send out an RA and the IPv6-enabled user devices will immediately obtain a global IPv6 unicast address and start to originate IPv6 traffic. The end-user devices will receive the RA and use the A, L, M, and O bits in the RA message to determine the method their OS will use (i.e., SLAAC or DHCPv6) to configure their Interface Identifier (the last 64-bits of their IPv6 address).
You must also plan if you are going to use DHCPv6 or if you must keep SLAAC and use RDNSS (RFC 8106) to support your Android devices. For most enterprises, the preference will be to use DHCPv6 in the same way they use DHCP for IPv4 today; i.e., to lease IPv6 addresses to end-nodes. These DHCPv6 or RDNSS services will need to be configured and tested prior to sending that first ICMPv6 RA message from the first-hop router for the access network.
Wireless Access Networks
As organizations have upgraded their wireless infrastructure to support IEEE 802.11ac, the hardware and software have been upgraded and now IPv6 features are assured. For your wireless access networks, you will need to plan how to configure your wireless LAN controllers for IPv6. Cisco has some good documents to help you configure IPv6 correctly on their Wireless LAN Controllers (WLCs) running version 8.0 or newer. Aruba Mobility Controllers have supported IPv6 since ArubaOS 6.0 and there are documents to assist you with IPv6 configuration of these devices as well.
If you are using autonomous WAPs that are individually configured, they are likely able to support simple bridging of the IPv6 packets from the RF interface to the wired interface. If you are using a cloud-based controller system, like Cisco Meraki, then you will want to confirm IPv6 support and device compatibility. Other wireless systems from Ruckus and Aerohive also have some IPv6 capabilities as well.
Regardless of the wireless infrastructure you are using, enabling IPv6 on both the wired and wireless access networks will mean that end-users will enjoy dual-protocol Internet connectivity using either medium.
As you start to bring IPv6 from the Internet perimeter inward to your enterprise networks, you will need to IPv6-enable the core, one layer-3 hop at a time. As your IPv6 deployment proceeds across the core network you will soon reach the access networks. You may want to enable IPv6 for the end-user access networks before you try to tackle enabling IPv6 for the systems in the data center. The preference in this case would be unlocking the improved end-user-experience benefits as soon as possible for your employees.
This post originally appeared on Infoblox Community at https://community.infoblox.com/t5/IPv6-CoE-Blog/IPv6-Enabled-Access-Networks-Are-Priority-for-Enterprises/ba-p/11456
Scott Hogg is the Chief Technology Officer (CTO) for GTRI.