Address Exhaustion - The Internet Protocol Journal, Volume 14, No.1

Geoff Huston, APNIC

The level of interest in IPv4 address exhaustion seems to be increasing, so I thought I would share some answers to the most common questions I have been asked on this topic in recent times.

What is the most significant challenge to the Internet today? What a wonderfully open-ended question! There are so many challenges that I could identify: improving the level of security on the network, eradicating spam and viruses, improving capacity of the network infrastructure, improving the efficiency of high-speed data transfer, improving the accuracy of search engines, building more efficient and high-capacity data centers, and reducing the unit cost of Internet services, to name but a few.

If there is a common factor in many of these challenges, it is scaling the network to meet an ever-expanding agenda of more users, more devices, more traffic, more services, and more policies. And with more users and more forms of use come higher levels of diversity of use and greater need to replace implicit mechanisms of trust with explicit forms of trust negotiation and greater levels of demonstrable integrity of operation.

But these topics are all tactical in nature. They reflect the "how" of making the network work tomorrow by studying how to undertake marginal improvements on the network of today. However, it is not clear that the networks not just of tomorrow or next year, but a decade or more hence should reflect the usage patterns and user population of today. Perhaps a more fundamental challenge is to understand what is missing in today's network that we will need in the future.

This discussion leads to a pretty obvious challenge, at least for me. The basic currency of any network is identifiers. Identifiers allow the network to distinguish between clients and ensure that conversations occur between those parties who intended to communicate. In the world of packet-switched networking, such as IP, these endpoint identifiers are synonymous with the concept of an address. What is missing in today's network is an abundant supply of new addresses that will allow the network to scale up in size by a further factor of at least 1 million, and hopefully more than a billion-fold.

In fact, the supply of addresses is not just inadequate for future needs for a decade hence. The stock of addresses is facing imminent depletion, and the question of availability of addresses is best phrased in terms of months rather than years.

Perhaps the term "address" is somewhat of a misnomer in this context, but it may well be too late to change that now. The primary role of an IP address is not to uniquely identify the location of an endpoint of a network in relation to some positional or topographical coordinate set, but to simply uniquely identify an endpoint to distinguish it from all other endpoints. Its location is not an intrinsic property of this so-called address. But common convention is to call these endpoint identifiers "addresses," so I will stick with the same convention here.

So my candidate "most significant challenge for the Internet today" is that we are running out of further supply of IP addresses.

What is an IP address, and why is it so important?

One of the revolutionary changes introduced by the so-called packet-switched network architecture of the Internet—as compared to its telephone predecessor that used circuit switching—was that a massive amount of "intelligence" was ripped out of the network and placed into the devices that connect at the edge.

IP networks are incredibly simple, and at their most basic level they do very little. They are built of routers and interconnecting conduits. The function of a router is quite simple. As a packet arrives at the router from the connected circuitry (or from a wireless interface), it is divided into a common IP header and a payload. The IP header of the packet contains, among other components, two fixed-length fields: the address of the intended destination of the packet, and, like a postal envelope, the address of the packet creator, or the source. The router uses the destination address of the packet to make a routing decision as to how to dispose of the packet. For each incoming packet, the router inspects the destination address in the packet and either passes it to a connected computer if there is an address match or otherwise passes it down the default path to the next router. And that is a working description of the entirety of today's Internet. The important aspect here is that every connected device must have a unique address. As long as this condition is satisfied, everything else can be made to work.

In the current version of the Internet Protocol, an "address" is a 32-bit field, which can encompass some 4.4 billion unique values.

Why are we running out of addresses?

Blame silicon. Over the past 50 years, the silicon chip industry has graduated from the humble transistor of the 1950s to an astonishing industry in its own right, and the key to this silicon industry is volume.

Individual processor chips may take hundreds of millions of dollars to design, but if fabricated in sufficient volume, each processor chip may take as little as a few dollars to manufacture and distribute. The larger the production run of the silicon die, the lower the unit price of the resultant chip. We currently produce a huge volume of computers every year. In 2008 alone around 10 billion computer processors were manufactured. Although most of these microprocessors are simple 8-bit processors that are used to open doors or run elevators, a sizable proportion are used in devices that support communications, whether it is in laptop computers, smartphones, or even more basic communication applications. Typically we do not invent a new communications protocol for each new application. We recycle. And these days if we want a communications protocol for a particular application, it is easiest to simply embed the IP protocol engine onto the chip. The protocol is cheap, well tested, and it works across almost any scale we can imagine from a couple of bits per second to a couple of billion bits per second.

So it is not just the entire human population of the planet who may well have a desire to access the Internet in the future, but equally important is the emerging world of "things" that communicate. Whether it is the latest fashion in mobile phones or more mundane consumer electronics devices such as televisions or games consoles, all these devices want to communicate, and to communicate they need to have a unique identification code to present to the network, or, an "address."

We are presently turning on more than 200 million new Internet services every year, and today we have used up most of the 4.4 billion addresses that are encompassed by the IP protocol.

When will we run out?

As of September 2010, some 151 million addresses were left in the general-use pool of unallocated addresses that are managed by the central pool administration, the Internet Assigned Numbers Authority (IANA). The world's IP address consumption rate peaked earlier this year at a new all-time high of an equivalent rate of 243 million addresses per year.

By early February 2011 IANA handed out its last address blocks to the RIRs.

The five Regional Internet Registries(RIRs) [1] still had pools of addresses available for general use at that time, but from that point, as they further run down their local pools, the IANA is now unable to provide any more addresses to replenish them. The Asia Pacific Regional Registry, APNIC, has been experiencing the highest level of demand in the world, accounting for some two-thirds of all addresses consumed in early 2011. APNIC exhausted its general use IPv4 address pool in April 2011.

Although the current models of address consumption show that the other regions will be able to manage available address pools for a few more months, this prediction does not account for the multi-national nature of many of the largest of the service providers, and at this stage it is not known how much address-consumption pressure will shift outward from APNIC to the other RIRs now that APNIC's available address pool is effectively drained. So it may well be that 2011 will see IPv4 addresses cease to be generally available in many parts of the world, and by early 2012 there will be no further generally available IPv4 addresses in Europe, North America and Asia.

What is the plan?

This news of imminent exhaustion of the supply of addresses is not a surprise. Although the exact date of predicted address exhaustion has varied over time, the prospect of address exhaustion was first raised in technical circles in August 1990, and work has been undertaken since that time to understand what might be possible and how that could be achieved.

The 1990s saw an intense burst of engineering activity that was intended to provide a solution for this forthcoming address problem. The most significant outcome of this effort was the specification of a successor IP protocol to that of IPv4, called IP Version 6 or IPv6.

Why IPv6 and not IPv5?

It would be reasonable to expect the successor protocol of IP Version 4 to be called IP Version 5, but as it turned out Version 5 of the Internet Protocol Family was already taken. In the late 1980s the Internet Protocol itself was the topic of a considerable level of research, as researchers experimented with different forms of network behavior. Version 5 of the Internet Protocol was reserved for use with an experimental IP protocol, the Internet Stream Protocol, Version 2 (ST-II), written up as RFC 1190 in 1990. When it came time to assign a protocol number of the "next generation" of IPv4, the next available version number was 6, hence IPv6.

The outcome of this process was a relatively conservative change to the IP protocol. The major shift was to enlarge the address fields from 32 bits to 128 bits in length. Other changes were made that were thought to be minor improvements at the time, although hindsight has managed to raise some doubts about that!

The design intent of IPv6 is a usable lifetime of more than 50 years, as compared with a "mainstream" deployment lifetime of IPv4 of 15 years, assuming that you are prepared to draw a line at around 1995 and claim that at that time the protocol moved from an interesting academic and research project to a mainstream pillar of the global communications industry.

That 50 years of usable life for IPv6 is admittedly very ambitious, because it is intended to encompass a growth of the ubiquity of silicon from the current industry volumes of hundreds of millions of new connected devices every year to a future level of activity that may encompass in the order of hundreds of billions to possibly some trillions of new connected devices every year.

So the technical plan to address the address-exhaustion problem was to perform an upgrade of the Internet and convert the Internet from IP Version 4 to IP Version 6.

Nothing else needs to be changed. This change is not intended to be radical or revolutionary. The change from circuit switching to packet switching was a revolutionary change for both the communications industry itself and for you and me as enthusiastic communicators. The change from IPv4 to IPv6 is intended to be a polar opposite, and at best it is intended to be a transparent and largely invisible transition. E-mail will still be e-mail. The web should still look just as it always did, and anything that works on IPv4 is expected to work on IPv6. IPv6 is not inherently any faster, nor any cheaper, nor is it even all that much better. The major change in IPv6 is that it supports a much larger address field.

How many addresses are in IPv6?

In theory, there are 2 to the power 128 unique addresses in IPv6—a very large number. If each IPv6 address were a single grain of sand, the entire IPv6 address space would construct 300 million planets, each the size of the earth!

But theory and practice align only in theory. In practice the IPv6 address plan creates a usable span of addresses that encompasses between 2 to the power 50 and 2 to the power 60 devices. Although this number is nowhere near 2 to the power 128, it is still a range of numbers that are between 1 million to 1 billion times the size of the IPv4 address space.

How do we transition to IPv6?

Unfortunately IPv6 is not "backward-compatible" with IPv4. Back-ward compatibility would allow for a piecemeal transition, where IPv6 could be regarded as a fully functional substitute for IPv4, so that the existing network base would keep using IPv4 forever, while the most recent devices would use IPv6 and all devices could communicate with each other. The lack of such backward compatibility implies that this communication is simply not possible. IPv4 and IPv6 are distinct and different communications protocols, in the same way that English and, say, German are distinct and different languages.

Attempts have been made to design various forms of automated protocol translator units that can take an incoming IPv4 packet and emit a corresponding IPv6 packet in the same manner as a language interpreter. However, this approach also has some major limitations, so it is usable only in very carefully constrained contexts.

The implication of this lack of backward compatibility and inability to perform automated translation within the network is that if we want to preserve comprehensive any-to-any connectivity during the transition, we have to equip each device that is performing a transition with both protocol stacks, or, in effect, allow the device to become "bilingual," and conduct a conversation in either IPv4 or IPv6, as required. This transition has been termed a dual-stack transition.

When my computer supports IPv6, can I return my IPv4 address?

Each device needs to maintain its capability to converse using IPv4 while there are still other devices out there that remain IPv4-only. So a device that becomes IPv6-capable cannot immediately give up its IPv4 address. It will need to keep this IPv4 capability and operate in dual-stack mode for as long as there are other devices and services out there that are reachable only using IPv4.

The implication of this constraint is that we will need to add dual-stack devices to the Internet and consume both IPv4 and IPv6 addresses during this transition.

So, no, you will need to keep your IPv4 address for as long as there are folk out there with whom you want to communicate who have not also migrated to be a dual-stack IPv4- and IPv6-capable entity

What needs to be done to transition the network to IPv6?

What is encompassed in "transition?" Do all Internet Service Providers (ISPs) have to decide when and how to reprogram their systems and reconfigure their routers, switches, and middleware? Will they need to replace all their customers' modems with ones that support IPv6? What is the agenda?

This level of uncertainty about the transition to IPv6 is evidently widespread in today's Internet. Most of the actors in the Internet are unsure about what needs to be done, from the largest of the service providers down to individual end users. Yes, it appears to be a simple matter of reprogramming devices from being just IPv4-capable to being capable of supporting both IPv4 and IPv6, but it is not quite so simple. Dual-stack operation is not easy, nor will it just happen without any form of applied impetus. Imagine that this transition is from everyone on the planet speaking Latin to each other to everyone speaking Esperanto. If this situation were a simple matter of everyone stopping using one language and being rebooted to use the other language one by one, then imagine the plight of the first people to undertake this transition—from being connected and being able to communicate with everyone else using Latin, these first users would find themselves speaking exclusively Esperanto to…nobody! They would in effect have been disconnected from the network.

So the transition is a little trickier than just turning a big switch from IPv4 to IPv6. Because this transition is a piecemeal and fragmentary one, each device, each router, each firewall, each load server, and all those other components of the network service platform need to be programmed with an additional protocol, and become, in effect, bilingual. And in this case there are no magic interpreters that can "translate" between IPv4 and IPv6. So it is only when the entire network is bilingual in a dual-stack mode that we can turn off IPv4 and consider the transition to be complete.

For an extended period of time the Internet is going to have to operate as two Internets. We have never tried that type of operation before, at least not on a grand scale as this one; in fact, it has often been likened to replacing the jet engines of an airplane while the plane is in flight. Somehow we now have to not only sustain a growth rate of at least some 250 million new connections per year, but at the same time retrofit IPv6 to the existing installed base while continuing to support IPv4. The complexity of this operation is significant, and there is considerable confusion about what to do, when to do it, how much it will all cost, and who will pay. So yes, we are all unsure about what needs to be done.

How long do we expect this dual-stack transition to take?

If only we knew! The Internet today encompasses some 1.7 billion users, and hundreds of millions of devices out there are configured to "talk" only IPv4. Some of these devices will surely die in the coming years, and others may be upgraded or reprogrammed, but others will persist in operation for many years to come while continuing to speak only IPv4. Even looking at what is being sold today, although many general-purpose computers (or at least their operating systems) are now configured to operate in dual-stack mode, when you look at embedded devices such as Digital Subscriber Line (DSL) or cable modems, or firewalls, or a myriad of other devices that are integral to the operation of today's Internet, many of these devices are still configured in firmware to operate exclusively using IPv4.

Some modeling of the transition process has projected an 80-year transition process. That projection is heading into the realms of the absurd, given that our expectations for the operational lifespan of IPv6 have a lower bound of just 50 years or so. However, given the sheer scope of the conversion task and the current level of penetration of IPv6 to levels of between 2 and 5 percent of today's Internet, and given that a deadline of 2 years from now implies a conversion rate of in excess of 1 million devices every day in that 2-year span. It seems that an expectation that this transition could be substantially completed in as little as 2 years also strikes an unrealistic note.

So a more realistic assumption is that we will probably take around 5 years to complete this transition, and we will need to operate the Internet in dual-stack mode with both IPv4 and IPv6 across this entire period.

But at the current level of Internet growth, the IPv4 address pool cannot sustain a further 5 years of growth—at least not with the current amount of unallocated addresses remaining in the allocation pools. The current address-consumption rate is some 250 million addresses per year. The depleted IPv4 address pool simply cannot withstand the pressures of a 5-year transition without a radical change to the model of the IPv4 network. And if we need to rework the model of the IPv4 network simply to sustain a transition to IPv6, then can't we simply get going with IPv6 a little more quickly instead?

However, "fully depleted" or even "run out" is perhaps not the most appropriate way to describe what will happen to IPv4 addresses in the coming months. It is probably more accurate to say "unobtainable at the current prices." When the current orderly process of allocation of IPv4 addresses comes to an end, that does not mean that IPv4 addresses will be completely unobtainable. In this world many things that are scarce are still obtainable—for a price. It is quite reasonable to anticipate that for as long as there is still a demand for IPv4 addresses there will be some form of "aftermarket" where addresses are traded for money. However, as with many markets, what is not possible to predict is the price for addresses that will be established by such a market-based address-trading regime.

What about "address sharing" in IPv4?
Why do we need IPv6, given that we could simply share addresses in IPv4?

Yes, of course address sharing [2] is an option, and we have been doing it for many years already in IPv4. But is it a viable substitute for IPv6?

As part of the engineering effort to develop a successor protocol to IPv4 in the mid 1990s, the IETF published a novel approach of address sharing, which we call today Network Address Translation, or NAT. [3 These days almost every DSL modem, and other forms of customer connection equipment, comes equipped with NAT functions. Today most Internet Service Providers give their subscribers a single IPv4 address. At home I have a single IPv4 address, and you probably do too. But in my home I have about 20 connected devices of various sorts (I am counting TiVo units, game consoles, televisions, printers, and such, because they are all in essence Internet-connected devices, and I believe that my situation is not unusual). All these devices "share" the single external IP connection, so all of them "share" this single IPv4 address.

But address sharing has its limitations. When a single household shares a single address, nothing unusual happens. But If I were to try to do the same address-sharing trick of using a single IP address to share across, say 2,000 customers, I would cross over into a world of pain. Many applications today gain speed through parallelism, and they support parallelism through consuming port addresses.

Each IP address can support the parallel operation of 65,535 sessions, using a 16-bit port identifier as the distinguishing identifier. But when address sharing is used, these ports are shared across the number of devices that are all sharing this common address. When 2,000 customers are sharing a single address and each customer has some 20 or so devices, then the average number of port addresses per device is 1.5. Common applications that exploit parallel operation include such favorites as Gmail, Google Maps, and iTunes. With a sufficiently constrained number of available ports to use, these applications would cease to work. Indeed, many network applications would fail, and at a level of a single address shared across 2,000 households, I would guess that up to half of these 2,000 customers would not have a working Internet at any single point in time.

Our experience suggests that address sharing works only up to a point, and then it breaks everything badly. We are already address sharing at the level of sharing a single address per household, and households are these days buying more connected devices of various sorts, not fewer. So attempting to share that single address across more than one household is at best a temporary solution, and is not a sustainable option that is an alternative to IPv6.

So we need to transition to IPv6, and we need to do so within an impossibly short time.

This discussion all sounds like a terrible problem.
Was this global “experiment” with the Internet all one big mistake?
Should we have looked elsewhere for a networking technology back in the 1990s?

The IP address problem is—for me at any rate—a fascinating one. At the time when researchers were working on the specifications for the Internet Protocol in the 1970s, they decided to use fixed-length 32-bit fields of the interface identifier addresses in the protocol. This decision was a radical one at the time. Contemporary network protocols, such as DECnet Phase III, used 16-bit address lengths, and 8-bit addresses were also very common at the time. After all, computers were so big and expensive, who could possibly afford more than 256 unique devices in a single network? Eight bits for addresses was surely enough! Using 32 bits in the address field was not an easy decision to make, because there was constant pressure to reduce the packet headers in order to leave more room for the data payload, so to reserve such a massive amount of space in the address fields of the protocol header to allow two 32-bit address fields was a very bold decision.

However, it was a decision that has proved to be very robust. TCP/IP has sustained the Internet from a mere handful of warehouse-sized computers running at mere kilobits per second to today, where probably more than 3 billion devices connect to the Internet in one way or another, at speeds that range from a few hundred bits per second to a massive 100 Gbps—all talking one single protocol that was invented more than 30 years ago.

IP has demonstrated a scale factor 1 billion! In my mind that achievement demonstrates a level of engineering foresight that is truly phenomenal. So in some sense the underlying observation here is not that IPv4 is running out of addresses today, but that it has been able to get to today at all!

that IPv4 has been able to scale by a factor of 1 billion, then if we can make IPv6 scale by a further factor of 1 billion from today we will have done well.


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


[1] 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.

[2] Geoff Huston, "NAT++: Address Sharing in IPv4," Internet Protocol Journal, Volume 13, No. 2, June 2010.

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

GEOFF HUSTON, B.Sc., M.Sc., is the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. He has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. He is author of numerous Internet-related books, and was a member of the Internet Architecture Board from 1999 until 2005; he served on the Board of Trustees of the Internet Society from 1992 until 2001. E-mail: