– Lori MacVittie, Senior Technical Marketing Manager at F5 Networks (www.f5.com), says:

Migration is not going to happen overnight and it’s going to require simultaneous support for both IPv4 and IPv6 until both sides of the equation are ready.

Making the switch from IPv4 to IPv6 is not a task anyone with any significant investment in infrastructure wants to undertake. The reliance on IP addresses of infrastructure to control, secure, route, and track everything from simple network housekeeping to complying with complex governmental regulations makes it difficult to simply “flick a switch” and move from the old form of addressing (IPv4) to the new (IPv6). This reliance is spread up and down the network stack, and spans not only infrastructure but the very processes that keep data centers running smoothly. Firewall rules, ACLs, scripts that automate mundane tasks, routing from layer 2 to layer 7, and application architecture are likely to communicate using IPv4 addresses. Clients, too, may not be ready depending on their age and operating system, which makes a simple “cut over” strategy impossible or, at best, fraught with the potential for techncial support and business challenges.

IT’S NOT JUST SIZE THAT MATTERS
The differences between IPv4 and IPv6 in addressing are probably the most visible and oft referenced change, as it is the length of the IPv6 address that dramatically expands the available pool of IP addresses and thus is of the most interest. IPv4 IP addresses are 32-bits long while IPv6 addresses are 128-bits long. But IPv6 addresses can (and do) interoperate with IPv4 addresses, through a variety of methods that allow IPv6 to carry along IPv4 addresses. This is achieved through the use of IPv4 mapped IPV6 addresses and IPv4 compatible IPv6 addresses. This allows IPv4 addresses to be represented in IPv6 addresses.

Traditional IPv4 Address – 192.168.0.1
IPv4 Compatible IPv6 Address – ::192.168.0.1
IPv4 Mapped IPv6 Address – ::ffff:192.168.0.1

But the real disconnect between IPv4 and IPv6 is in the differences in their headers. It is these differences that cause IPv4 and IPv6 to be incompatible. An IPv4 packet header is a fixed length, 40 bytes long. An IPv6 packet header is variable length, and can be up to 60 bytes long. Traditional IP “options” are carried within the IPv4 header, while in IPv6 these options are appended after the header, allowing for more flexibility in extended options over time. These differences are core to the protocol and therefore core to the packet processing engines that drive most routers and switches. Unless network infrastructure is running what is known as a “dual stack”, i.e. two independent networking stacks that allow the processing and subsequent translation of the two protocols, the infrastructure cannot easily handle both IPv4 and IPv6 at the same time.

INVESTMENT and RISK of MIGRATION too HIGH
This makes the task of migrating a massive effort, one that most organizations have continued to put off even though the days of IPv4 address availability are dwindling.

Expert had estimated that public IPv4 addresses will be depleted by the year 2012 which makes it imperative that service providers, hosting companies, and cloud computing providers migrate sooner rather than later or risk being unable to provide services to customers. David Meyer of ZDNet brought this issue to the fore in “IPv4 addresses: Less than 10pc still available” noting that there is little impetus for organizations to make the switch from IPv4 to IPv6 despite continued depletion of IPv4 addresses:

“IPv4 and IPv6 addresses are not compatible. Pawlik [NRO chairma] said it was technically feasible to make the two types of IP address talk to each other, but it would be best for companies and ISPs to switch to IPv6 as soon as possible, to keep networks stable and avoid complexity when IPv4 addresses run out.”

Pawlik also conceded that many businesses are putting off the switch to IPv6 because, even when all public IPv4 addresses have been allocated, they will continue to be able to allocate private IPv4 addresses internally. However, he stressed that anyone running public-facing websites will have to make their sites visible as IPv6 addresses, as their users will be on IPv6 addresses in the future.

The reality is that we’re running out of IPv4 address spaces a lot faster than that. Consider this more recent coverage (Jan 2011) that estimates all available IPv4 address blocks will be officially “gone” in early February 2011:

“It’s likely that this week or next, the central supplier of Internet Protocol version 4 (IPv4) addresses will dole out the last ones at the wholesale level. That will set the clock ticking for the moment in coming months when those addresses will all be snapped by corporate Web sites, Internet service providers, or other eventual owners.”

And that means it’s now a necessity, not a luxury, to rebuild the Net on a more modern foundation called IPv6.

The last 5 blocks of addresses “each with 16.8 million addresses”, were distributed to the regional registries earlier this week. It is expected such allotments will be depleted in six to nine months.” (Internet Runs out of addresses as devices grow – Boston.com). It is the organizational reliance on IP addresses in the network and application infrastructure and how thoroughly permeated throughout configurations and even application logic IP addresses are that make Pawlik’s statement quite true. Because organizations can continue to leverage IPv4 internally – and thus make no changes to its internal architecture, infrastructure, and applications – it is unlikely they will feel pressure to migrate. The effort associated with the changes required to migrate along with the possible requirement to invest in solutions that support IPv6 make it financially difficult for many organizations to justify, especially given that they can technically continue to utilize IPv4 internally with very few ramifications.
But as Pawlik also points out, externally it is important to make that migration as more and more users are migrated off of IPv4 and onto IPv6 by service providers. The ramifications of not migrating public facing services to IPv6 is that eventually those services will be unreachable and unusable by customers, partners, and users who have made the move to IPv6.

HOW to EAT YOUR CAKE and HAVE it TOO

There are a variety of ways in which both IPv4 and IPv6 can be made “compatible” from a data center networking point of view.

Tunneling IPv6 via IPv4 to allow individual hosts on an IPv4 network to reach the IPv6 network is one way, but requires that routers are able to be configured to support such encapsulation. Hybrid networking stacks on hosts makes the utilization of IPv6 or IPv4 much simpler, but does not necessarily help routing IPv6 through an IPv4 network. Most methods effectively force configuration and potentially architectural changes to support a dual IP version environment, which for many organizations is exactly what they were trying to avoid in the first place: disruptive, expensive changes in the infrastructure.

There is a way to support IPv6 externally while making relatively no changes to the organizational network architecture. An IPv6 gateway can provide the translation necessary to seamlessly support both IPv6 and IPv4. Employing an IPv6 gateway insulates organizations from making changes to internal networks and applications while supporting IPv6 clients and infrastructure externally.

The right IPv6-enabled solution can also help with migration internally. For example, an enabled application delivery controller can act as an IPv4 to IPv6 gateway, and vice-versa, by configuring a virtual server using one IP address version and pool members using the other version. This allows organizations to mix and match IP versions within their application infrastructure as they migrate on their own schedule toward a completely IPv6 network architecture, internally and externally.

For more complete data center enablement, deploying a gateway can provide the translation necessary to enable the entire organization to communicate with IPv6 regardless of IP version utilized internally. A gateway translates between IP versions rather than leveraging tunneling or other techniques that can cause confusion to IP-version specific infrastructure and applications. Thus if an IPv6 client communicates with the gateway and the internal network is still completely IPv4, the gateway performs a full translation of the requests bi-directionally to ensure seamless interoperation. This allows organizations to continue utilizing their existing investments – including network management software and packaged applications that may be under the control of a third party and are not IPv6 aware yet – but publicly move to supporting IPv6.

THERE’S NO REASON LEFT NOT to SUPPORT IPv6
Literally, this is true because IPv4 addresses are nearly gone by the time you’ve read this post.

The urgency with which NRO chariman Pawlik speaks on the subject of IPv6 is real. There is an increasing number of users accessing the Web via mobile devices, and it is in the telco and service provider markets that we see the most momentum toward mass adoption of IPv6.
IDC also reported in its new Marketplace Model and Forecast report that more than a quarter of the world’s population, or 1.6 billion people, used the Internet in 2009 on a PC, mobile phone, video-game console, or other device. By 2013, that number is expected to rise to 2.2 billion.
— InformationWeek, “1 Billion Mobile Internet Devices Seen By 2013”

The rapid increase in mobile devices is also driving providers to adopt IPv6 as they build out their next generation networks to support a massive subscriber base. Unless organizations adopt a strategy that includes supporting IPv6 at least externally, it is likely that they will begin to experience fewer and fewer visitors and customers as more people worldwide adopt, albeit unknowingly, IPv6.

Supporting IPv6 can be a fairly simple exercise that incurs very little costs when compared to a complete architectural overhaul of the data center. There’s just no good reason to ignore the growing need, and about 2.2 billion good reasons to do something about it sooner rather than later.

**F5 is a regular contributor on Data Center Post