The Internet Protocol Journal, Volume 11, No. 4

The End of Eternity

Part One: IPv4 Address Exhaustion and Consequences

by Niall Murphy, Google, and David Wilson, HEAnet

Eternity is a very long time, especially towards the end," said Woody Allen [22, 23], and he was mostly right. The eternity that the 32 bits of IPv4 address space promised is now almost at an end, and we are faced with the task of deciding what to do after the "end of eternity."

The size of the problem of IPv4 exhaustion is, unfortunately, also proportional to its longevity [1, 2, 3]. Although the next-generation (IPng) effort [4] kick-started the development of IPv6 partially in response to concern about the IPv4 consumption rate, the industry as a whole largely ignored the problem after Classless Inter-Domain Routing (CIDR) and the Regional Internet Registries (RIR) system contained the depletion problem to a manageable horizon. More recently, after Geoff Huston's [5] work showing that the expected depletion time was sooner than many organizations had expected, the concern has received considerable attention in address-allocation policy circles.

In this article, we examine IPv4 exhaustion in more detail. We talk about what exactly exhaustion will mean and what we can do about it, and then present a vision for the postexhausted world. Those familiar with our RIPE-55 talk [6] will find much that is familiar, but the arguments have been expanded for a more general audience. The authors, as in that talk, are speaking only for themselves, and not their organizations.

What Does Exhaustion Mean?

Trivially, the point of IPv4 exhaustion is the point at which the guaranteed-free-and-unused pool runs out and the current allocation mechanism comes to an end. Although the depletion of the free pool defines the technical point of exhaustion, it is not the depletion itself that is of primary importance. After all, if it were, we could simply declare a moratorium on allocations with immediate effect, to preserve the resource for some notional future requirements. Rather, it is the effect on the practices and procedures, within the RIRs and within the Local Internet Registries (LIRs), administrative and technical, that will practically define exhaustion. These practices, which have grown to fit around the current behavior of the addressing system, the free pool, and so on, will require urgent reform after exhaustion, as indeed will the RIR system in general.

Currently organizations use and require new addresses for essentially every IP-related additional deployment (for example, adding customers to a publicly numbered DSL service, adding extra Secure Sockets Layer (SSL)-enabled websites to a Web hosting service, and adding extra publicly reachable servers to almost any service).

It has been emphasized that this problem affects only the growth of organizations performing IP deployments [7]. Although it is important to acknowledge the partial correctness of this statement, much about the postexhaustion state could undermine the stability of well-established advertisements and routes unless the transition is well-handled. It seems intuitively correct that those who received allocations before exhaustion will be unaffected by exhaustion turmoil [8], but we regard this premise as optimistic, as you will see later.

Along those lines, one less well-examined consequence of exhaustion is the erosion of the consensus model of Internet governance. There is potential for wide divisions to open up at the local and regional level unless this consensus is carefully conserved. No clear successor to the current model as yet exists; the RIRs appeared to be heading toward a spectrum of positions on, for example, the allocation of the last portions of the IPv4 free pool [9, 10] until quite recently [24].

The erosion of this model of governance as a consequence of exhaustion has been neither widely examined nor expected in the Internet community. Partially, this situation arose because of the useful and well-executed role that the RIRs have historically filled in providing sensible and stable conditions for decision making; some proportion of the membership of the RIRs might well feel that IPv4 exhaustion is a problem like any other, which the RIRs themselves are in the perfect position to resolve. However, although the atmosphere of mutual cooperation fostered by the RIRs has produced many useful service-related outputs (for example, the Test Traffic Measurement service of Réseaux IP Européens [RIPE] [25]), one of the major nonobvious benefits they have brought is to provide a centralized focus for discussion with governments and regulatory agencies. Not only is it more efficient and therefore less time-wasting to centralize through one representative organization, it has also created expectations that similar matters can be dealt with in the same coordinated way—a very valuable expectation, which has helped to increase the credibility of industry self-regulation. This credibility allowed, for example, the Number Resource Organization (NRO) to help forestall a proposal to allocate IPv6 according to geographical boundaries [27, 28].

Indeed, without credible industry self-regulation, it is not at all clear that this community could have grown as fast as it did. Although it seems clear today that the RIRs are the correct place for this kind of activity to go on (witness RIPE's "enhanced cooperation" task force [26]), if they had not been around, government would either have had to deal with an organization with less of a pedigree or one with more inherent bias, or multiple organizations with competing biases, all of which could compel them to distrust the results of their liaisons. Unfortunately, in this respect the RIRs have been a victim of their own success.

Just as the consensus model in domains broke down when top- and second-level domains became monetized, so it is likely that the inherent win or loss for any given holder in any policy changes will undermine attempts to build consensus for address policy in a monetized IPv4 world. Absent this consensus, many of the RIR services that we rely upon will be undermined—not least the veracity of the WHOIS database and subsequent reliability of our routing filters, but also the RIR and Internet Corporation for Assigned Names and Numbers (ICANN) representations toward governments.

What Are the Problems with Exhaustion?

The biggest problem is the simplest one: existing organizations whose business model or operations are solely predicated on an ongoing flow of IPv4 addresses will fail. This premise would seem an extreme, even theoretical, characterization, but the size of this category in the real world is larger than you might think. Numerous organizations are also in trouble, perhaps less predicated upon IPv4 than the others, but that—for example—might have financial or operational difficulty in making the postexhaustion transition happen internally. They would also be placed at risk. Finally, there are those organizations that might rely on others to perform their transition correctly in order for them to continue effective operations: less directly at risk, but still probably affected.

Those who deal with the operation of the Internet on a daily basis are well-aware of the workarounds available that could save organizations from the doomsday scenario. It is unfortunate, then, that many of us have looked to the simplest cases in our immediate experience in order to form our opinions of the scale of the problem. It is indeed true that, in the short term, the client-side problem has largely been solved—provided that your customers or developers never have expectations in line with an end-to-end Internet. (It would seem that address-space pressure is likely to erode whatever end-to-end expectations still remain in today’s Internet.)

However, the server-side problem (for example, SSL Website hosting, IP Security [IPsec] VPN endpoints, ...) remains unsolved. Workarounds exist [11], but whether they will be ready and deployed in time remains an open question. There are, therefore, organizations operating at this moment that depend upon the continued availability of IPv4 addresses. Adequate workarounds have yet to be developed—never mind proven–for these businesses.

The situation becomes more complicated when we consider the candidate solutions. For example, such organizations as described previously cannot solve their problem by deploying IPv6 alone prior to the end of the transition, because they require universal reachability. Without universal reachability, support costs will rise, the quality of the user experience will decrease, and the credibility of Internet governance will be threatened. The only available evidence shows our position on the IPv6 transition curve being at the very beginning [12].

Therefore it is difficult to emphasize this enough—new entrants providing Internet services cannot expect to compete equally with existing operations—because they have a very high barrier to entry formed not by the natural action and development of competitors, but by the resource scarcity of new addresses. Without new addresses, they cannot have an IPv4 Default-Free Zone (DFZ) routing-table entry; without a DFZ entry, they cannot be multihomed; without multihoming, they cannot offer sufficiently redundant Internet service; and without sufficiently redundant Internet service, they cannot meaningfully compete with existing operators.

A variety of poor-quality "fudges" are possible, of course: they could use the address space of their upstream operators (and run the risk of having that address space pulled or charged for), or they could outsource any address-requiring services to another organization (and be unable to control their service quality, as well as dependent upon their continuing operation), or they could host through some kind of public proxy network that redirects to their back-end servers through various hard-coded means (and create a fragile, difficult-to-operate network with higher running costs per unit customer than their competitors).

We will examine the other negative consequences of exhaustion in more detail later in the discussion; meanwhile, let us assume that the scenario described previously is undesirable enough for us to ask whether we can actually do anything to forestall it.

Can We Practically Defer Exhaustion?

What we would ideally like is some policy or algorithm that would give us more time—how much time is open to question—without producing its own set of ill effects. (We can certainly defer exhaustion by ceasing to allocate new IPv4 addresses tomorrow, but that solution is hardly practical.) Unfortunately, this problem is very difficult to resolve. Such direct precedents that appear clearly related to the current situation provide no useful guidance. Many resource-exhaustion problems have been faced before, but ultimately the solutions for those can be categorized into three kinds:

  • Make the resource renewable: In this case, the resource is in danger of running out, but can be replenished by some means. Often this replenishment involves constraining production predicated on the resource to some smaller value, particularly when there is a natural rate of renewal—for example, fishing stocks. In the case of IPv4, it is fundamentally nonrenewable in that the resource is of a finite size. (As we discussed previously, current reclamation efforts [13], although worthy of pursuit as a low-overhead task, cannot be a solution.)
  • Move to another resource: This solution is already under way in the sense that we are engaged in the transition to IPv6. However, adoption of IPv6 will not happen fast enough to prevent the negative consequences of exhaustion.
  • Divide the resource more fairly: This solution is useful primarily in the case where hoarding is taking place, causing resource problems for some significant proportion of a resource-using population. We are dividing the resource fairly as it is, and certainly since the emergence of the RIRs. For reasons discussed later, husbanding the resource more carefully is unlikely to actually be a solution.

We have faced other abstract exhaustion problems before as well: for example, phone-number depletion is somewhat similar to our current problem. However, phone-number depletion admits of a simpler solution—the creation of extra digits in the number space—because of the centralization of network knowledge in a comparatively small number of switches. For the Internet, where every deployed host would have to be informed about changes to the number space, such an approach is not operationally feasible. Furthermore, adding extra digits to the number code is not in fact simple, and telecommunications companies have experienced a wide range of problems with such approach in the past, to say nothing of the loss of revenue and the failure of calls to connect because of customer confusion [14, 15]. We see no historical situation that provides a clear precedent and a clear way forward.

SimLIR

Accordingly, to help answer the question posed in the preceding section, we wrote a tool, SimLIR, to explore exhaustion and post-exhaustion scenarios. Rather than being a tool influenced primarily by computations based on growth curves, a "top-down" approach, it is a modeling tool that examines how changes in behavior affect relative consumption rates. Roughly 6,000 lines of Python, the tool is due to be open-sourced at its Google Code page [16] shortly after this article is available. The tool models the whole Internet Assigned Numbers Authority (IANA)—>RIR—>LIR hierarchy, and currently maps LIRs to countries; it uses the same publicly available data as Geoff's work. We would appeal to the community to help improve the program, because more research is desperately needed in this area.

Running the tool under various scenarios has produced preliminary results indicating that we cannot meaningfully defer exhaustion, given our current growth rates. It can be used to compare the effect of policy adjustments on known historical and simulated behavior. For example, one simple policy adjustment that has been informally suggested is to decrease the initial allocation size for new LIRs. Modeling this allocation with the tool, we halve the size the LIRs receive at the time of initial membership. If we allow this scenario to run to completion, we have seen that it allows us to defer exhaustion by less than a week. Intuitively, we might expect this assumption to be realistic because startup activity, although important, is relatively small in terms of proportion of allocations. New LIRs numbered approximately 500 in 2006 [17], and any scheme that attempted to defer exhaustion based on such a small proportion of overall operations could not practically succeed.

The question then arises whether any other scheme based upon treating some partition of the request-space differently could have a significant positive effect. However, such a scheme necessarily assumes that some set of requests are oversized, and can in fact be shrunk with no ill effects. Even if they are oversized, identifying them without inducing either unworkable bureaucracy or a chilling effect on the operations of the organization would be a significant task, not lightly undertaken. Furthermore, it would be in the self-interest of the current RIR membership not to agree to such a change in policy. With any such scheme, there would be a non-zero chance of their own requests being deemed faulty in some respect, thus leading to significant risk to their own operations. All of this process would of course be happening in the approach to exhaustion, where it would be more critical than ever to receive enough numbering resources! We can assume, therefore, that no such scheme would ever make it past the policy-making apparatus of bottom-up-influenced RIRs. Ironically, the easiest changes to enact are changes governing allocations to startup organizations; the affected organizations are not in the room at the time of policy formation, because they are not members yet. But such changes are highly unlikely to have a positive effect.

Finally, partitioning schemes are similar to other schemes proposed to rework the End Game for IPv4 allocation [18, 19, 20] or retain a certain proportion of the free pool for as-yet-unknown future needs, in that we put RIRs in the awkward situation of having to decide that some requests are more legitimate than others, at a time when these requests are likely to be particularly urgent. RIRs should not be in the business of deciding who gets to have new customers, and partitioning the request space invites the possibility of preferential treatment. We can be sure that any preferential treatment at this crucial time, accidental or otherwise, would attract lawsuits. Judicial involvement in the allocation process close to the time of exhaustion would benefit almost nobody.

It is important to note that these risks are mainly specific to partitioning the request space from the RIR to the LIR; in other words, imposing criteria at the time of request. Partitioning the remaining pool per RIR, that is, imposing criteria at the time of division, such as proposed by the n = 1 policy [24], does not suffer from "favoritism." Indeed, even if there were blatantly iniquitous division at the IANA-to-RIR level, although various checks and balances exist to ensure there is not, it would be unlikely to affect those with resources sufficient to possess an office in the region in question, or to open one up; it is patently clear that the requests will follow where the space is, and it is highly unlikely that any single RIR with a large amount of space left after others have been exhausted would be in any kind of position to pass a discriminatory policy.

We make these points to highlight that any scheme based upon LIR partitioning presents immense difficulties of principle. Even if these difficulties are worked out, they seem unlikely to meaningfully defer exhaustion: the current run rate for IPv4 address space will exhaust the space within a 5-year timeframe anyway, even if all practically possible measures are taken.

The Consequences of Scarcity

Suppose for the moment that at the time of exhaustion, Internet-connected organizations have to fend for themselves, with no particularly well-defined industry strategy in place. We would then expect to see a broad movement within the industry to conserve precious public IPv4 address space. One obvious way for an organization to obtain more usable IPv4 space is to move previously publicly-numbered resources behind Network Address Translation (NAT) gateways. Other, less-legitimate sources of new addresses will probably also be explored, and these actions, combined with the generally uncoordinated changes, may well trigger the following negative consequences:

  • Inability to measure clients, and difficulty of supporting them: As we see more layers of NAT within networks, it becomes gradually more difficult to establish who is actually connecting to you, and what problems they are having. Cookies are a partial solution for only one important protocol. Measurement becoming harder means that support costs will rise.
  • Address-space hijacking: As organizations become more desperate for space, it is entirely feasible that they will begin to cast around for space not explicitly unavailable in order to meet their business needs. How widespread this practice would be remains an open question, but effective barriers to this behavior are not currently available. We would expect a general deterioration in the quality of routing.
  • WHOIS database quality down: Coupled with layers of NAT hiding more and more networks from direct sight, transfers of address space (legitimate or otherwise) will cause the WHOIS database to become gradually less and less accurate, leading to...
  • Distributed denial-of-service (DDoS) tracking trouble: Problems tracking DDoS attacks and abuse origins of all kinds make law enforcement and network operators equally unhappy.
  • Connection quality down: Connection quality, in terms of connections that complete successfully and have tolerable latency, will go down as a function of client growth behind gateways.
  • RIR billing model under pressure: The RIRs will need to find a new way to pay their costs or go out of business—gradually, but inevitably. Of course the RIRs, like every other organization, must serve a need, but they currently provide a large number of ancillary services not directly related to IP allocation, and those services would also be under threat.
  • Consensus undermined: This consequence is possibly the most dangerous of them all. If a chaotic state of affairs is allowed to continue for too long, our very ability to make decisions as a community will be undermined as organizations abandon the RIR model that has failed them. We will have squandered, in a way, the foundation of trust that allows such ethical codes as we have developed in Internet operations to persist. That foundation will not be easily recovered.

(Note that all of these are effects that are likely to emerge to varying degrees with the onset of scarcity, however it takes place; in other words, if the RIRs engage in a program of scarcity management by partitioning requests, it is highly likely that the scenario described previously will happen no matter what is left in the free pool.)

In any large shock such as we describe, there will be operational turmoil. Organizations will attempt to employ the technologies they need to dig themselves out of trouble, or bend the rules to the same end. There will be financial turmoil as the ability of each business to scale in the new regime is tested. Turmoil for existing businesses and new entrants will no doubt attract increased attention from governmental and quasigovernmental agencies of all kinds. Turnover in the routing table will increase as uncoordinated deaggregation of prefixes takes place. Unwelcome as all these consequences are, we will probably be far too preoccupied with our own individual problems to take care of the broader picture.

Postexhaustion Vision

Although we hope it is clear, given the previous discussion—that IPv4 addresses will still be required after exhaustion—our highest aspiration cannot be an Internet confined in perpetuity to IPv4 alone. If we are to continue in a manner resembling our current operations, we require continued address plenty, even by today’s rather restricted standards. The End Game, therefore, is an IPv6 Internet, or at least enough of one to keep off address scarcity for a workable subset of the industry.

So, the problem can then be characterized as the transition toward this state of affairs—the gap between the end of the old allocation model and the emergence of an adequate replacement. Any solution will have to either make the gap shorter, by bringing users to the IPv6 Internet sooner, or make it less painful, by helping IPv4-dependent organizations survive. (Note that a solution that makes the gap less painful may well cause it to lengthen.)

With the problem stated this way, we can evaluate possible solutions in this context. A hurried, stimulated transition of popular services to IPv6 will quite likely shorten the gap, although a mass transition is also likely to be an unstable one and so rather painful.

A voluntary release of unused addresses may help reduce the pain, but is unlikely to service the run rate adequately, given its voluntary nature, and in any event will prolong dependence on IPv4, thus lengthening the gap. Tweaking policies to make remaining IPv4 addresses arbitrarily difficult to get merely introduces the effects of scarcity still sooner, helping neither goal.

That said, our initial examination of the problems of exhaustion indicate that there will be a group of people who will require IPv4 addresses after the exhaustion point, and it is also clear that there are those who have addresses, such as the lucky recipients of class A addresses in the early days, but no particular incentive to give them up. We do not actually want to recycle these prefixes indefinitely, however; that just sustains the current model. Optimally, we should provide whatever opportunity we can to those who require IPv4 addresses, to get them (and us) toward the End Game of an adequate global IPv6 deployment.

We do not require an unlimited IPv4 supply to accomplish this goal. We do, however, require liquidity: the ability to transfer, with incentives to transfer. Although it is very difficult for a centralized system (such as an RIR) to reclaim adequate space, the effort/reward ratio is much more favorable for an individual organization that knows its own network. So we must provide some stimulus for them to increase liquidity, while imposing some realistic restriction on demand. It must of course be scrupulously fair.

Stated in this way, a market-based trading exchange is not just one way of attempting to solve the problem–such an exchange, properly regulated, is arguably the most neutral and fairest way to manage the problem of scarcity.

In the next article we will explore how such a market system should work, discuss what new problems it is likely to create, and consider the potential effect on the routing table.

For Further Reading

[1] ftp://ftp.ietf.org/ietf-online-proceedings/94dec/area.and.wg.reports/ipng/ale/ale-minutes-94dec.txt

[2] http://tools.ietf.org/html/rfc2008

[3] Hain, Tony, "A Pragmatic Report on IPv4 Address Space Consumption," The Internet Protocol Journal, Volume 8, No. 3, September 2005

[4] http://playground.sun.com/ipv6/doc/history.html

[5] http://ipv4.potaroo.net

[6] http://www.ripe.net/ripe/meetings/ripe-55/presentations/murphy-simlir.pdf

[7] http://www.isoc.org/educpillar/resources/ipv6_faq.shtml

[8] http://www.ietf.org/internet-drafts/draft-narten-ipv6-statement-00.txt

[9] http://www.apnic.net/meetings/24/program/sigs/policy/presentations/el-nakhal-prop-051.pdf

[10] http://www.ripe.net/ripe/policies/proposals/2007-06.html

[11] http://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf

[12] For example, http://h.root-servers.org/128.63.2.53_2.html versus http://h.root-servers.org/h2_5.html

[13] http://www.ripe.net/ripe/meetings/ripe-55/presentations/vegoda-reclaiming-our.pdf

[14] A "smooth and convenient" dialing plan for India. http://www.mycoordinates.org/indias-phone-june-06

[15] http://en.wikipedia.org/wiki/UK_telephone_code_misconceptions

[16] http://code.google.com/p/simlir/

[17] http://www.ripe.net/docs/ripe-407.html#membership

[18] http://www.ripe.net/ripe/policies/proposals/2007-03.html

[19] http://www.ripe.net/ripe/policies/proposals/2007-06.html

[20] http://www.ripe.net/ripe/policies/proposals/2007-07.html

[21] http://kuznets.fas.harvard.edu/~aroth/alroth.html

[22] Woody Allen, "Side Effects," 1980.

[23] Woody Allen through (most famously) Stephen Hawking, http://www.cnn.com/2006/WORLD/asiapcf/07/04/talkasia.hawking.script/index.html

[24] http://icann.org/en/announcements/proposal-ipv4-report-29nov07.htm

[25] http://www.ripe.net/ttm/

[26] http://www.ripe.net/ripe/tf/enhanced-cooperation/index.html

[27] http://www.nro.net/documents/nro18.html

[28] http://www.ripe.net/maillists/ncc-archives/im-support/2004/index.html

[29] Huston, G., "The Changing Foundation of the Internet: Confronting IPv4 Address Exhaustion," The Internet Protocol Journal, Volume 11, No. 3, September 2008.

NIALL MURPHY holds a B.Sc. in Computer Science and Mathematics from University College Dublin. While in university, he founded the UCD Internet Society, which provided Internet access to approximately 5,000 students. He went on to work for (and found) various organizations: the .IE domain registry, Club Internet (now Magnet Entertainment), Ireland On-Line, Enigma Consulting, Bitbuzz, and Amazon.com. He is currently in Site Reliability Engineering at Google. He is the coauthor of numerous articles, some RFCs, the O'Reilly book IPv6 Network Administration, and is a published poet and keen amateur landscape photographer. E-mail: niallm@avernus.net

DAVE WILSON holds a B.Sc. in Computer Science from University College Dublin, not coincidentally from around the same time as Niall. He has worked at HEAnet, the Irish National Research & Education Network, for more than 10 years, maintaining an involvement with RIPE and with the pan-European research network Géant. Dave is a member of the ICANN Address Supporting Organization Address Council; he helped to found the Irish IPv6 task force, which has the support of the national government there. E-mail: dave.wilson@heanet.ie