IPv6 Adoption in the Data Center
Owen DeLong is an IPv6 Evangelist and Director of Professional Services at Hurricane Electric, a large provider of IPv6-native Internet backbone and colocation services.OWEN DELONG
Most data center operators know that a failure to transition to IPv6 will eventually restrict access to connected resources and degrade communications efficiency. But one lesson of World IPv6 Day (held June 8, 2011) is that IPv6 adoption can bring immediate benefits in the form of improved network topologies and security today.
In determining when to transition to IPv6, the most common concern is the dwindling availability of IPv4 addresses to support additional devices. This limited thinking is a pity, as IPv4 suffers from a host of limitations beyond its address capacity, including inefficient routing and packet processing, indirect data flows, overly complex network configuration, and feeble security. Yes, IPv6’s nearly infinite supply of addresses (340 undecillion) could accommodate an intergalactic deployment of connected devices, but of equal importance is IPv6’s ability to improve routing efficiency, reduce router processing, enable true peer-to-peer connectivity, and eliminate complex layers of indirection like NAT.
IPv6 Transition Strategy: Dual Stack
Despite the clear benefits of IPv6, telecom companies, service providers and enterprises with large data centers struggle to determine the least disruptive IPv6 transition strategy. The key element of maintaining backward compatibility with IPv4 systems during the transition is to encourage a “dual-stack” mentality. All devices along the communication path, including endpoint devices, data-center routers and switches, ISPs, and backbone providers must simultaneously support IPv4 and IPv6.
Although the dual-stack model may appear to add complexity, it has the benefit of ensuring that no matter which protocol an endpoint application wishes to use, there will be support for it in the underlying network substrate. Nearly all modern operating systems support both IPv4 and IPv6, so in many cases, enabling IPv6 is simply a matter of turning it on (or, even better, just making sure that no-one has turned it off). Indeed, the majority of infrastructure behind the global Internet is now dual-stacked. Root name servers (fundamental to how we convert names like he.net into address numbers) have been IPv6-enabled for years, and Top Level Domains (TLDs) like .com, .net and .gov are serviced by domain name servers that are dual-stacked. Presently at least 256 of the 306 TLDs are enabled for IPv6.
Once dual-stack operating systems are deployed and enabled throughout an enterprise, there are a few technologies (6in4, 6to4 and Teredo) that ensure that IPv6 traffic can traverse pathways where only IPv4 is supported. Tunnelbrokers, which leverage the 6in4 protocol, allow IPv6 traffic to be tunneled inside IPv4 packets. The 6to4 protocol provides IPv6 connectivity over an IPv4 network by mapping IPv4 addresses into IPv6 addresses using the special 2002::/16 prefix. A 6to4 relay router at the network edge is required to encapsulate and decapsulate IPv6 traffic sent to and from site nodes. Another means to connectivity, Teredo, encapsulates IPv6 packets within IPv4 UDP packets that can be routed through NAT devices. Close consideration and understanding of these temporary measures is critical to filling the gaps in IPv6 connectivity.
The transition to IPv6 takes time and effort, and a carefully managed transition is better than one done in a panic. An organization’s network is a strategic asset that should not be neglected. Like roses and children, networks reflect their care.
Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.
Ulric ErikssonPosted September 23rd, 2011
At the turn of the century, many organizations were transitioning from IPX to IPv4 and there was a lot of dual-stacking going on, not to mention gizmos to access the Internet from IPX-only networks. Once the necessary technology was there, the dual-stacking and gizmos went away. Since the technology is already there this time, there is even less reason to dual-stack, except for the ISP:s dragging their feet.
Would that that were the case, Ulric. In reality, there is much foot-dragging, but, it is mostly NOT ISPs. Most of the foot dragging these days is a combination of enterprises, equipment vendors, consumer electronics makers, and others. Residential CPE technology is still very limited. In terms of consumer electronics, it’s very hard to find devices (A/V receivers, televisions, blu-ray players, media centers, game consoles) that actually have IPv6 support. Even the ubiquitous Linux-based DVR (yes, TiVO, I’m picking on you here) fails to support IPv6.
The ISPs that might appear to be dragging their feet at this point (primarily the residential eye-ball ISPs) still face daunting challenges in hardware and software availability for provisioning systems, CPE, and other network resources that are needed for them to make an effective deployment.
Things are moving forward and the pace is accelerating, but, there is still a pretty strong need for dual stack for a few years yet. The IPX->NetBIOS->IP transition did not happen overnight and there are still a few networks out there running IPX. IPv4->IPv6 will, likewise still take some time.
My home ISP has finally stopped saying “we’re fine, we’ve hoarded enough IPv4 address space to keep going” to “we’re working on a plan for IPv6 but don’t yet know what that plan is”. Meanwhile, my tunnel through Hurricane Electric does the job.
Right now, though, I have native IPv6 on one of my colocated servers, 6to4 to another, and no IPv6 connectivity at all to the third (Amazon EC2). Having added AAAA records in DNS, I discovered connecting was much slower from work … on every single request, that Windows 7 machine would try in vain to use IPv6 before falling back to IPv4. I managed to disable IPv6 on that particular machine with a registry hack, rather than deleting my AAAA records again, but it’s depressing when trying to keep up to date backfires and yields no apparent benefit!
Maybe a bigger version of IPv6 day, where the big content providers/hosts like Google and Akamai publish AAAA records to everyone *and keep them there* would be enough to push people into at least fixing broken IPv6 non-deployments. Right now, I don’t think there’s a smooth enough transition path between the two: too many cases where beginning a migration causes big problems.