IPv4 to IPv6 switch: When protocols collide

Shifting from IPv4 to IPv6 will take years and could be a bumpy ride. But few organisations will find the process as complicated as cloud computing providers, says Lori MacVittie.

Not since the first packets were tossed around the internet has it faced so much potential change, with implications for its health and well-being and, peripherally, cloud computing.

The recent World IPv6 Day gave a host of vendors, providers and interested parties the chance to engage in a full-scale IPv6 interoperability test live on the internet. Yet for many of the participants it wasn't just a test of IPv6 compatibility but an examination of what is considered one of the most promising migration strategies: dual-stack support.

As its name suggests, the dual-stack option involves running IPv4 and IPv6 networking stacks on the same system as a means to communicate with other nodes regardless of which version might be used.

Advantages of the dual-stack option

It's considered the best of the options available — when compared with tunnels and translators — because it's the simplest of the options to implement and provides the widest coverage of endpoint combinations.

It's a 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.

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

Dual stacking meets that need well, because 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.

DNS complexities

Consider the process of simply getting to a website, which is more complex than it sounds. DNS must be queried, packets routed, TCP sessions initiated, data exchanged. And that's only the tip of the iceberg.

Given the reliance business, government and individuals have on the internet, there is no feasible way to accomplish a single, mass migration from IPv4 to IPv6.

Inside the datacentre where that site resides is a multitude of components — hardware and software — that must interact 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? As we shift from one version to the next, we 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 more complicated task than it at first perhaps appears.

Few organisations will find the process of migrating from IPv4 to IPv6 as complicated as cloud-computing providers.

The impact on cloud computing

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 employ 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, but they must migrate their internal systems, frameworks and controls.

For some cloud-computing providers, those supplying software-as-a-service (SaaS) in particular, this requirement is probably not as difficult as it will be for an infrastructure-as-a-service (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 datacentres or vice versa, which may be using different IP versions but rely on IP addresses for security or integration, could be stymied by incompatibilities or incomplete migrations.

Collaboration to avoid wide-scale outages

There are myriad challenges to such a mass migration when so many different variables are involved, so it's 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 have just begun.

As we've never attempted such a large transition before with the internet on its present scale, we must be prepared to cut everyone a bit of slack.

As we've never attempted such a large transition before with the internet on its present scale, we must be prepared to cut everyone a bit of slack. It is no trivial task that the internet as a whole is undertaking. If we understand the complexity of the task before us, we should be able to cope with the inevitable bumps in the road.

Perhaps considering how difficult a task cloud-computing providers — indeed all of us — have ahead, we'll 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.

Lori MacVittie is responsible for application services education and evangelism at application delivery firm F5 Networks. Her role includes producing technical materials and participating in community-based forums and industry standards organisations. MacVittie has extensive programming experience as an application architect, as well as in network and systems development and administration.