An Ending and An Opportunity

A new milestone in the history and evolution of the Internet has passed: On Thursday, February 3, 2011, it was announced that the Internet Assigned Numbers Authority (IANA), steward of the Internet’s reserves of unassigned IP addresses, has distributed the final blocks of IPv4 addresses to the Regional Internet Registries (RIRs). The RIRs, based in North America, Europe, Asia, South America, and Africa, will now allocate them, according to rules developed in each region, to service providers and enterprises worldwide. And then all of the IPv4 addresses will be in use.

What Happened?

In many ways this is a non-event. No network, application, or activity that depends on IPv4 today will stop working due to the events this week. If you aren’t trying to grow your network, directly connected to the global infrastructure, your primary interest in IPv6 is in using it for the simplest, most straightforward interconnection with carriers and content providers in the future. If you do need IPv6 to grow your network, a number of upgrade strategies are available to you. Nothing changes instantly because of this long-predicted turn in the path.

But it is the next step in a vast and inevitable change. Sometime in the not-so-distant future– a few months– the RIRs will no longer have unassigned IPv4 to distribute either. The ability to attach new devices and networks to the Internet will depend on transferring IPv4 addresses from someone else who doesn’t need them, connecting with IPv6, or using some set of “transition” or “co-existence” technologies allowing IPv4 and IPv6 connected devices to talk to each other. All of these approaches can be expected to persist, in all possible combinations, for some time to come; but ultimately, today’s Internet, in which the default underlying protocol is IPv4, will become a network built on IPv6.

What does this mean for the Internet?

In the long term, the deployment of IPv6 promises a vastly larger, richer Internet of more devices and more ways for them to interact. But in the short term, adaptation of the Internet– operating systems, networks, applications– to IPv6 has lagged the depletion of the IPv4 address pool.

So today, there’s a gap to be filled: we’re running out of available IPv4 addresses faster than we’re migrating away from the need for them. Even with the wide deployment of NAT, invented years ago to extend the useful address space beyond what the original specification allowed, there’s only so far we can go in aggregating vast numbers of separate devices behind small numbers of unique IP addresses, and we’re at that limit. Address policy at the RIRs has been getting ever more conservative for a decade, but we’ve gone as far as we can. Even the policy evolution that has allowed the RIRs to permit direct address transfers between members once the unallocated pool has been exhausted– allowing the development of a market in address space– can’t put off the need forever for a larger pool of numbers than IPv4 can provide. There’s simply no other way to connect the users, devices, and services of the future.

The significance of the end of the IPv4 unallocated address pool is this: if you haven’t thought about how you’re going to live, and operate any network you are responsible for, in an IPv6 future, you need to start.

The good news is that the tools are in hand to bridge the gap. Significant work has gone into the invention of “co-existence” technologies to allow systems, networks, and applications not yet ready to use IPv6 to interoperate with those that are. The simplest of these is usually called “dual stack,” in which the same host has both IPv4 and IPv6 addresses; but others have been developed as well, to accommodate both IPv4-only and IPv6-only hosts and networks. These are particularly important now that devices without IPv4 addresses soon may not be able to get them.

Large carriers, content providers, hosting providers, and others for whom access to IP addresses for new devices is mission-critical, have been working towards wide deployment of IPv6 for some time now, and their vendors– including ISC– have been working towards accommodating them. So there is also beginning to be a base of operational experience to draw on, for both the ways in which IPv6 works “just like IPv4” and the ways in which it is different.

What does this mean for ISC and our customers?

First, ISC has been looking towards the migration of the Internet infrastructure to IPv6 for a very long time now. We have contributed significant effort to the standards for accommodating IPv6, and to the policy evolution of the RIRs to promote its use. Our infrastructure software products– principally BIND 9 and DHCP– have been fully compatible with existing IPv6 standards for years. For example, our DHCP package implements the DHCPv6 standard, in both client and server, including IPv6 prefix delegation, which helps support far larger numbers of devices in an IPv6 Internet home or small office than has been the case for IPv4 sites. And our services, including SNS, F-Root, and Hosted@ have been configured for dual-stack operation for years as well. Our DNS root name server was one of the first to have an IPv6 address publicly available and published in the root zone for serving DNS queries over IPv6 transport, and has helped make the business case for IPv6 availability at many of the locations where we operate. And our expanding training offerings now include not only coverage of IPv6 features in our courses on BIND and DHCP, but a new dedicated IPv6 course.

In the last couple of years, we have also worked on standards and implementation for some of the new technologies to support IPv4 and IPv6 interoperation. We have added advanced features for IPv6 and mixed networks to BIND and DHCPv6. We have released AFTR, our package implementing the dual-stack lite protocol to allow IPv4 devices to communicate across an IPv6 carrier network, and we continue to add features as the standard and our customers’ needs evolve; we are currently implementing PCP, or Port Control Protocol, as a further evolution in dual-stack lite. BIND 9.8 will support DNS64, required to enable in turn the NAT64 standard which allows IPv6 devices to communicate with IPv4 servers. ISC DHCP 4.2.1 will be compatible with 6rd, another recently-specified protocol for deploying native IPv6 connectivity to end-users, and there will be more enhancements to IPv6 capabilities in DHCP 4.3, later this year.

Our software, support and consulting engineers are ready to draw upon our experience, and that of the wider community, to help make the future IPv6 Internet a reality for our customers and partners everywhere. We’ll help you figure out what IPv6 means to you, and how to get there with minimal cost and maximum benefit.

Today, though, we stop in amazement to look at what the world has done with the IPv4 protocol that has been the foundation for the Internet. We’re looking forward to seeing what we can make of the IPv6 Internet of the future.