Transitional Myths - The Internet Protocol Journal, Volume 14, No.1

Geoff Huston, APNIC

Last October, I attended the Réseaux IP Européens (RIPE) [1] meeting in Rome, and—not unexpectedly for a group that has some interest in IP addresses—the topic of IPv4 address exhaustion, and the related topic of the transition of the network to IPv6, captured a lot of attention throughout the meeting. One session I found particularly interesting was on the transition to IPv6, where people related their experiences and perspectives on the forthcoming transition to IPv6.

I found the session interesting, because it exposed some commonly held beliefs about the transition to IPv6, so I will share them here, and discuss a little about why I find them somewhat fanciful.

Myth 1: "We have many years for this transition."

No, I don’t think we do!

The Internet is currently growing at a rate that consumes some 200 million IPv4 addresses every year, or 5 percent of the entire address IPv4 pool. This growth rate reflects an underlying growth of service deployment by the same order of magnitude of some hundreds of millions of new services activated per year. Throughout a dual-stack transition, all existing services will continue to require IPv4 addresses, and all new services will also require access to IPv4 addresses. The pool of unallocated addresses was exhausted in February 2011, and the Regional Internet Registries (RIRs) [2] will exhaust their local pools commencing early 2011 and through 2012. When those pools exhaust, then all new Internet services will need access to IPv4 addresses as part of the IPv4 part of the dual-stack environment, but at that point there will be no more freely available addresses from the registries. Service providers have some local stocks of IPv4 addresses, but even those stocks will not last for long.

As the network continues to grow, the pressure to find the equivalent of a further 200 million or more IPv4 addresses each year will become acute—and at some point will be unsustainable. Even with the widespread use of Network Address Translators (NATs) [3] and further incentives to recover all unused public address space, the inexorable pressure of growth will cause unsustainable pressures on the supply of addresses.

It is unlikely that we can sustain 10 more years of network growth using dual stack, so transition will need to happen faster than that. How about 5 years? Even then, at the higher level of growth forecasts, we will still need to flush out the equivalent of 1.5 billion IPv4 addresses from the existing user base to sustain a 5-year transition, and this number seems to be a stretch target. A more realistic estimate of transition time, in terms of accessible IPv4 addresses from recovery operations, is in the 3–4 year timeframe, and no longer.

So no, we do not have many years for this transition. If we are careful—and a bit lucky—we will have about 4 years.

Myth 2: "It is just a change of a protocol code. Users will not see any difference in the transition."

If only that were true!

In an open market environment, scarcity is invariably reflected in price. For as long as this transition lasts, this industry is going to have to equip new networks and new services with IPv4 addresses, and the greater the scarcity pressure on IPv4 addresses, the greater the scarcity price of IPv4 addresses. Such a price escalation of an essential good is never a desirable outcome, and although numerous possible measures can be taken to mitigate the problem, to some extent or other, the scarcity pressure and the attendant price escalation suggest a reasonable expectation of some level of price pressure on IPv4 addresses.

In addition, an Internet Service Provider (ISP) may not be able to rely solely on customer-owned and-operated NATs to locally mask out some of the incremental costs of IPv4 address scarcity. It is likely—and increasingly so the longer the transition takes—that the ISP will also have to operate NATs. The attendant capital and operational costs of such additional network functions will ultimately be borne by the service provider’s customer base during the transition.

But it is not just price that is affected by this transition—network performance may also be affected. Today a connection across the Internet is typically made by using the Domain Name System (DNS) to translate a name to an equivalent IP address, and then launching a connection-establishment packet (or the entire query in the case of the User Datagram Protocol [UDP]) to the address in question. But such an operation assumes a uniform single protocol. In a transition world you can no longer simply assume that everything is contactable with a single protocol, and it is necessary to extend the DNS query to two queries, one for IPv4 and one for IPv6. The client then needs to select which protocol to use if the DNS returns addresses in both protocols. Then there is the tricky problem of failover. If the initial packet fails to elicit a response within some parameter of retries and timeouts, then the client will attempt to connect using the other protocol with the same set of retries and timeouts. In a dual-stack transitional world, not only does failure take more time to recognize, but even partial failure may take time.

So users may see some changes in the Internet. They may be exposed to higher prices that reflect the higher costs of operating the service, and they may see some instances where the network simply starts to appear "sluggish" in response.

Myth 3: "NAT upon NAT upon NAT will work."

Maybe. But maybe not all the time, and maybe not in ways that match what happens today.

The Internet has been operating for more than a decade now with a very prevalent model of a single level of address translation in the path. Application designers now assume its existence, and also make some other rather critical assumptions, notably that the NAT is close to the client in a client-server world, and that there is a single NAT in the path, and that its particular form of address translation behavior can be determined with numerous probe tests. There is even a client-to-NAT protocol to assist certain applications to communicate port-binding preferences to the local NAT. In a multilevel NAT world, such assumptions do not directly translate, but it is not necessarily the case that the application is aware of the added NATs in the end-to-end path.

However, it is not just the added complexity of the multipart NAT that presents challenges to applications. The NAT layering is intended to create an environment where a single IP address is dynamically shared across multiple clients, rather than being assigned to a single client at a time. Applications that use parallelism extensively by undertaking concurrent sessions require access to a large pool of available port addresses. Modern web browsers are a classic example of this form of behavior. The multiple NAT model effectively shares a single address across multiple clients by using the port address, effectively placing the pool of port addresses under contention. The higher the density of port contention, the greater the risk that this multiple layering of NATs will have a visible effect on the operation of the application.

There is also a considerable investment in the area of logging and accountability, where individual users of the network are recorded in the various log functions through their public-side address. Sharing these public addresses across multiple clients at the same time—as is the intended outcome of a multilayer NAT environment—implies that the log function is now forced to record operations at the level of port usage and individual transactions. Not only does this reality have implications in terms of the load and volume of logged information, there is also a tangible increase in the level of potential back tracing of individual users’ online activities if full port usage logging were to be instituted, with the attendant concerns that this back tracing represents an inappropriate balance between accountability and traceability and personal privacy. It is also unclear whether there will be opportunity to have any public debate on such a topic, given that the pressure to deploy multilevel NAT is already visible.

Myth 4: "Changing the Customer Premises Equipment (CPE) is easy."

No, not necessarily.

I think we have all seen many transition plans, including multilevel Version 4 NATs, NATs that perform protocol translation between IPv4 and IPv6, NATs plus tunneling, as in Dual-Stack Lite, the IVI Bi-direction Mapping Gateway, 6to4, 6RD, and Teredo, to call up but a few of the various transitional technologies that have been proposed in recent times. (See the article "Transitioning Protocols" starting on page 22.)

All approaches to dual-stack transition necessarily make changes to some part of the network fabric, whether it is changes to the end systems to include an IPv6 protocol stack in addition to an IPv4 stack, or the addition of more NATs, or gateways into the network infrastructure. Of course, within a particular transitional model there is a selective choice as to what elements of the infrastructure are susceptible to change and what elements are resistant to change. Some models of transition, such as 6RD and Dual-Stack Lite, assume that changing the CPE is easy and straightforward, or at least that such a broad set of upgrades to customer equipment is logistically and economically feasible. 6RD contains an implicit assumption that the network operator has no economic motivation to alter the network elements, and wishes to retain a single protocol infrastructure that uses IPv4.

Where the CPE is owned, operated, and remotely maintained by the service provider, upgrading the image on the CPE might present fewer obstacles than upgrading other elements of the network infrastructure, such as broadband remote-access servers that operate in a single protocol mode, but sweeping generalizations in this industry are unreliable. Service providers tend to operate customized cost models, and appear to be operating with specialized mixes of vendor equipment and operational support systems. For this reason operators tend to have differing perspectives on what component of their network is more malleable, and correspondingly have differing perspectives on which particular transition technology suits their particular environment.

This industry is volume-based, where an underlying homogeneity of the deployed technology—and economies of scale and precision of process—are critical components of reliable and cost-efficient rollouts. It is somewhat unexpected to see this transition expose a relative high degree of customization and diversity in network service environments.

Myth 5: "My ISP has enough IPv4 addresses to last for years, so it does not have a problem."

Well, not necessarily.

The assumption behind this statement is that everyone else is also able to persist with IPv4, and everyone you wish to reach, and every service point you wish to access, will maintain some form of connectivity in IPv4 indefinitely.

But this assumption is not necessarily valid. At the point in time when a significant number of clients or services cannot be adequately supported on IPv4, then irrespective of how many IPv4 addresses ISPs have, they will need to provide their clients with IPv6 in order to reach these IPv6-only services On a network, the actions of others directly affect your own local actions. So if you believe that you need do nothing, and you can use an IPv4 service for years into the future, then this position will be inadequate at the point in time when a significant number of others encounter critical levels of scarcity such that they are incapable of sustaining the IPv4 side of a dual-stack deployment, and are forced to deploy an IPv6-only service. The greater the level of address hoarding, the greater the level of pressure to deploy IPv6-only services on the part of those service providers who are badly placed in terms of access to IPv4 addresses.

Myth 6: "We will always have to run IPv4 protocols."

Probably not.

Or at least not in terms and volumes that are significant to the industry over the forthcoming decades. Protocols do die. DECnet and Systems Network Architecture (SNA) no longer exist as widely deployed networking protocols. In particular, networking in the public space is all about any-to-any connectivity, and to support this connectivity we need a common protocol foundation. In terms of the dynamics of transition, this situation is more about tipping points of the mass of the market than it is about sustained coexistence of diverse protocols. When a new technology—or in this case, protocol—achieves a critical level of adoption, the momentum switches from resisting the change to embracing it.

The aftermath of such transitions does not leave a legacy of enduring demand for the superseded technology. As difficult as it is to foresee today, when the industry acknowledges that the new technology achieves this critical mass of adoption, the dynamics of the networking effect propels the industry into a tipping point where the remainder of the transition is likely to be both inevitable and comprehensive. The likely outcome of this situation is that there is no residual significant level of demand for IPv4.

Myth 7: "There is a technology that will translate between IPv4 to IPv6."

Yes, but…

Such a technology effectively maps between IPv4 and IPv6 addresses. One approach, the IVI Bi-direction Mapping Gateway, provides a 1:1 mapping by embedding fields of one address in the other. Another approach, originally termed Network Address Translator – Protocol Translator (NAT-PT), uses a mapping table in a fashion similar to a conventional NAT unit. The common constraint here is that if there are no IPv4 addresses, then such a bidirectional mapping cannot be sustained in each approach. Ultimately, if every packet that traverses the public Internet requires public address values in the source and destination fields, and the ISP must provide a protocol bridge between IPv4 and IPv6, then public IPv4 addresses are required.

But it is not just the requirement for continued access to addresses that is the critical concern here. A reading of RFC 4966 [4], "Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status" should curb any untoward enthusiasm that this approach is capable of sustaining the entire load of this dual-stack transition without any further implications or problems.

Myth 8: "We do not necessarily have to transition to IPv6. There are substitutes."

Nothing is visible from here!

If we want to continue to operate a network at the price, performance, and functional flexibility that is offered by packet-switched networks, then the search for alternatives to IPv6 is necessarily constrained to a set of technologies that offer approaches that are—at a suitably abstract level—isomorphic to IP. But going from abstract observations to a specific protocol design is never a fast or easy process, and the lessons from the genesis of both IPv4 and IPv6 point to a period of many years of design and progressive refinement to develop a viable approach. In our current context any such redesign is not a viable alternative to IPv6, given the timeframe of IPv4 address exhaustion. It is unlikely that such an effort would elicit a substitute to IPv6, and it is more likely that such an effort may lead toward an inevitable successor to IPv6, if we dare to contemplate networking technologies further into the future.

Other approaches exist, based on application-level gateways and similar forms of mapping of services from one network domain. We have been there before in the chaotic jumble of networks and services that defined much of the 1980s, and it is a past that I for one find easier to forget! Such an outcome is of considerably higher complexity, considerably less secure, harder to use, more expensive to operate, and more resistant to scaling.

Like it or not, the pragmatic observation of today's situation is that we do not have a viable choice here. No viable substitutes exist.

Myth 9: "We know what is happening."

I am not sure that is universally true! The comments I have heard about the current situation lead me to the observation that there are many different perspectives on the situation. Individuals perceive the transition in terms that relate to their own circumstances and their own limitations, and a more encompassing perspective of the entire Internet and this transition is harder to assemble. So, from the perspective of the Internet as a whole, no, we are not really aware of what is happening.

Myth 10: "We know what we are doing."

Individually this statement is, hopefully, true. But at the level of the entirety of the Internet, no, we do not really have a clear perspective of this transition.

Myth 11: "We have a plan!"

See the comment for myth 10.

Myth 12: "The Internet will be fine!"

I am unsure about this one.

The worrying observation is that the Internet has so far thrived on diversity and competition. We have seen constant innovation and evolution on the Internet, and the entrance of new services and new service providers.

But if we rely solely on IPv4 for the future Internet, then this level of competition and diversity will be extremely challenging to sustain. If we lose that impetus of competitive pressure from innovation and creativity, then the Internet will likely stagnate under the oppression of brutal volume economics. The risks of monopoly formation under such conditions are relatively high.

I hope one observation I heard at the RIPE session will be a myth as this transition gets underway:

The incumbents will have all the IPv4 space. Thanks for playing!"

If that is not a myth, then we are going to be in serious trouble!


The views expressed in this article do not necessarily represent the views or positions of the Asia Pacific Network Information Centre (APNIC).



[2] Daniel Karrenberg, Gerard Ross, Paul Wilson, and Leslie Nobile, "Development of the Regional Internet Registry System," The Internet Protocol Journal, Volume 4, No. 4, December 2001.

[3] Geoff Huston, "Anatomy: A Look inside Network Address Translators," The Internet Protocol Journal, Volume 7, No. 3, September 2004.

[4] Cedric Aoun and Elwyn Davies, "Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status," RFC 4966, July 2007.

Pool of Unallocated IPv4 Addresses Now Completely Emptied

On February 3, 2011 a critical point in the history of the Internet was reached with the allocation of the last remaining IPv4 Internet addresses from a central pool. It means the future expansion of the Internet is now dependant on the successful global deployment of the next generation of Internet protocol, called IPv6.

The announcement was made by four international non-profit groups, which work collaboratively to coordinate the world's Internet addressing system and its technical standards. At a news conference in Miami, Florida, the Internet Corporation for Assigned Names and Numbers (ICANN) joined the Resources Organization (NRO), the Internet Architecture Board (IAB) and the Internet Society (ISOC) in announcing that the pool of first generation Internet addresses has now been completely emptied. The final allocation of Internet addresses was administered by the Internet Assigned Numbers Authority (IANA), which is a function of ICANN.

"This is a major turning point in the on-going development of the Internet," said Rod Beckstrom, ICANN's President and Chief Executive Officer. "No one was caught off guard by this. The Internet technical community has been planning for IPv4 depletion for some time. But it means the adoption of IPv6 is now of paramount importance, since it will allow the Internet to continue its amazing growth and foster the global innovation we've all come to expect."

Two "blocks" of the dwindling number of IPv4 addresses—about 33 million of them—were allocated in late January to APNIC, the Regional Internet Registry (RIR) for the Asia Pacific region. When that happened, it meant the pool of IPv4 addresses had been depleted to a point where a global policy was triggered to immediately allocate the remaining small pool of addresses equally among the five global RIRs.

"It's only a matter of time before the RIRs and Internet Service Providers (ISPs) must start denying requests for IPv4 address space," said Raúl Echeberría, Chairman of the NRO, the umbrella organization of the five RIRs. "Deploying IPv6 is now a requirement, not an option."