When protocols collide

Not since the first packets were tossed around the then constrained set of routers that comprised the Internet, has there been this much change potentially impacting the health and well-being of the Internet, and peripherally, cloud computing.

World IPv6 Day, held on 8 June 2011, was the day when a host of vendors, providers and interested parties engaged in a full-scale, live-on-the-Internet-for-one-day-only test of IPv6 interoperability. For many of the participants, however, it wasn't just a test of IPv6 compatibility; it was a test of what is considered one of the most promising migration strategies: dual-stack support.

The process will be slow and eventual, and take years.

Lori MacVittie is technical marketing manager for Application Services at F5 Networks.

The “dual-stack option” is as it sounds: running both IPv4 and IPv6 networking stacks on the same system as a means to communicate with other nodes, regardless of which version might be used. It's considered the best of the options available - when compared to tunnels and translators - because it is the simplest of the options from an implementation standpoint, while providing the widest coverage of endpoint combinations. It's a transitory-focused migration strategy that allows for the reality that it's going to take a long time to migrate the entire world - every single device out there - from what has been the only standard the Internet has really known, to its successor, IPv6.

There is no feasible way, given the reliance that business, government and individuals have on the Internet, to accomplish a single, mass migration from IPv4 to IPv6. The process will be slow and eventual, and take years. In the meantime, the onus is on those with a public-facing presence to somehow support both protocols.

Dual-stacking addresses that need neatly, as most infrastructure is already dual-stacked. But running both stacks is not the same as using it to integrate and interconnect the myriad services - networking and application-oriented - necessary to enable even the simplest of tasks to be completed. Consider the more-complex-than-it-sounds process of simply getting to a Web site; DNS must be queried, packets routed, TCP sessions initiated, data exchanged. And that's only the tip of the iceberg. Inside the data centre at which that site resides is a multitude of components - hardware and software - that must interact in order to answer a query as simple as an ICMP echo request.

Being dual-stacked does not necessarily address the need for services to support IPv6. Imagine an IPv4 endpoint requesting the IP address for a site. DNS must respond, but with what? Obviously an IPv4 address and not an IPv6 address. Consider the reverse, as well. How does DNS know which IP version of the address to respond with? While the world transitions from one version to the next, over time, people will be faced with an environment in which both versions are active, and the infrastructure services responsible for making the 'Internet go round' must be able to support both, a perhaps more complicated task than it appears at first.

Very few organisations will find the process of migrating from IPv4 to IPv6 as complicated a task as cloud computing providers.

Cloud computing providers, like everyone else, rely heavily on IP addresses to integrate and interconnect their vast array of compute, storage and network resources. But they are also responsible for providing public-facing services for their customers, such as DNS.

Internally, they leverage a complex ecosystem of scripts and management frameworks that enable the automation and remote control necessary for “self-service”. So not only does a cloud provider need to ensure its external services are capable of supporting both versions, it must migrate its internal systems, frameworks and controls.

For some cloud computing providers, SaaS in particular, this is likely not as difficult as it will be for an IaaS provider. That's because an IaaS provider must also deal with customers who configure and control their own virtual images, many of which may be reliant on IPv4 instead of IPv6, or vice versa. Applications and other services are often developed using IP addresses as identification of any external or third-party integrated services, and those applications are generally controlled by the customer, not the provider.

But that does not mean SaaS is off the hook. Applications deployed in any cloud computing environment that integrate back into enterprise data centres (or vice versa), which may be using different IP versions but rely on IP addresses for security or integration, may be stymied by incompatibilities or incomplete migrations.

There are myriad challenges to such a mass migration when so many different variables are involved, and thus it is not going to be a simple case of throwing a switch. The collaboration and careful planning that will be required to meet the challenges without causing wide-scale outages has just begun.

As such a large-scale transition has never been attempted before, with a “full” Internet, as it were, organisations must be prepared to cut everyone a bit of slack. This is no trivial task the Internet as a whole is undertaking, and if the complexity of the task is understood before, this can hopefully translate to users having a bit more patience if the inevitable bumps in the road result in a few bruises along the way.

Perhaps considering how difficult a task cloud computing providers - indeed everybody - have ahead, there will be a little less condemning of outages and the like that occur from the collision of IPv4 with IPv6 during the months and years ahead.