The Internet Protocol Journal - Volume 10, No. 3

IPv4 Address Consumption

IPv4 Address Space: 2.46 Billion Down, 1.25 Billion to Go
by Iljitsch van Beijnum

In September 2005, The Internet Protocol Journal published an article about the IPv4 address space consumption [1]. At that time, projections done by Geoff Huston and Tony Hain varied widely, because the number of /8 address blocks in use had gone up sharply in early 2005. So what has happened since then, and what can we expect for the not-too-distant future?

Address Assignment and Allocation

The Internet Assigned Numbers Authority (IANA, part of the Internet Corporation for Assigned Names and Numbers [ICANN]) has authority over the IPv4 address space. In the past, IANA gave out address blocks directly to end users, but now IANA distributes address space in the form of /8 blocks, each holding 24 bits worth of address space, or 16,777,216 addresses, to five Regional Internet Registries (RIRs). There are a few exceptions, but AfriNIC [2] gives out address space in Africa; APNIC [3] in the Asia-Pacific region; ARIN [4] in North America; LACNIC [5] in Latin America and the Caribbean; and RIPE NCC [6] in Europe, the former Soviet Union, and the Middle East. These RIRs sometimes assign address space to end users, but mostly allocate it to Internet Service Providers (ISPs), who then assign it to their customers, meaning that there are two pools of available address space: the global pool of /8 blocks that IANA has not delegated to anyone [7], and the address space held by the RIRs that they have not given out yet. The article in the September 2005 issue of The Internet Protocol Journal [1] looked at the depletion of the IANA global pool, whereas this article mostly looks at the amounts of address space given out by the RIRs, providing a more granular view. The RIRs publish daily reports of their address assignments and allocations on their respective FTP servers. According to these reports as downloaded on January 1, 2007, the amounts of address space shown in Table 1 were given out over the past seven years.

Table 1: Address Space Allocated 2000 – 2006 [January 2007 data]

  2000 2001 2002 2003 2004 2005 2006
AfriNIC 0.56 0.39 0.26 0.22 0.51 1.03 2.72
APNIC 20.94 28.83 27.03 33.05 42.89 53.86 51.78
ARIN 30.83 28.55 21.08 22.32 34.26 47.57 38.94
LACNIC 0.88 1.61 0.65 2.62 3.77 10.97 11.50
RIPE NCC 24.79 25.36 19.84 29.61 47.49 62.09 56.53
Total 78.00 84.73 68.87 87.82 128.92 175.52 161.48

However, if we compare these totals to the totals seen on January 1, 2006, we see some differences (Table 2).

Table 2: Address Space Allocated 2000 – 2006 [January 2006 data]

  2000 2001 2002 2003 2004 2005 2006
Total 78.35 88.95 68.93 87.77 128.45 1.03

For the years 2000 to 2002, the number of addresses registered as given out is slightly lower, as seen in the January 1, 2007 data compared to the January 1, 2006 data—a result that is to be expected because address space given out in that year that is no longer used is returned. However, for the later years, and especially for 2005, there is a retroactive increase in the number of addresses given out. The reason: When ARIN suspects an address space user may come back for more space relatively soon, it takes a larger block than requested, and then fulfills the request from part of that block and keeps the rest in reserve. So an organization requesting a /16 may get the first half of a /15. When that organization then requests another /16 one or two years later, ARIN gives the organization the second half of the /15. ARIN subsequently records this as a /15 given out on the date when the original /16 was requested.

For instance, ARIN's January 1, 2006, data shows that a block of 12.6 million addresses was given out within 73.0.0.0/8 block:

arin|US|ipv4|73.0.0.0|12582912|20050419|allocated

In the January 1, 2007 data, this number had changed to 13.6 million addresses:

arin|US|ipv4|73.0.0.0|13631488|20050419|allocated

This change means that simply looking at the registration date does not provide very good information. It also does not account for address space given out in earlier years that is returned. An alternative approach is to count the amount of address space given out based on the RIR records published on a certain date (Table 3).

Table 3: RIR Records for Address Space Allocation

  IANA (/8) RIRs (millions) Total
  Delegated Free Received Delegated Free Free Delta
Jan. 1, 2004 133 88 1509.95 1245.63 264.32 1740.71  
Jan. 1, 2005 142 79 1660.95 1351.66 309.30 1634.69 106.02
Jan. 1, 2006 155 66 1879.05 1517.74 361.31 1468.61 166.08
Jan. 1, 2007 166 55 2063.60 1685.69 377.90 1300.65 167.96
Jan. 1, 2008 172 49 2181.04 1754.68 426.36 1248.44 52.21

(Note that block 7.0.0.0/8 shows up as unused in the IANA global pool and is counted as available in the table, but this block is in fact used by the U.S. Department of Defense.)

The jump in address consumption between 2004 (106 million) and 2005 (166 million) is even more dramatic in this light, while consumption numbers of 2005 and 2006 (168 million) are now almost identical. The figure for the first four months of 2007 seems rather modest at 52 million addresses, but the reason lies in the fact that Bolt, Beranek and Newman returned 46.0.0.0/8 to IANA in April. So the number of addresses given out from January to April was 69 million, a rate that puts the RIRs on track to give out more than 200 million addresses in 2007.

The size of address blocks given has been increasing steadily. Table 4 shows the number of requests for a certain range of block sizes: equal or higher than the first, lower than the second value (2005 and earlier values from the January 1, 2006 data, 2006 values from the January 1, 2007 data).

Table 4: Number of Requests for Ranges of Block Sizes

  2000 2001 2002 2003 2004 2005 2006
< 1,000 326 474 547 745 1022 1309 1526
1,000 – 8,000 652 1176 897 1009 1516 1891 2338
8,000 – 64k 1440 868 822 1014 1100 1039 1133
65k – 500k 354 262 163 215 404 309 409
500k – 2M 19 39 29 46 61 60 56
> 2M 3 5 5 6 7 18 13

The number of blocks in the two smallest categories has increased rapidly, but not as fast as the number of blocks in the largest category, in relative numbers. However, the increase in large blocks has a very dramatic effect whereas the small blocks are insignificant, when looking at the millions of addresses involved (Table 5).

Table 5: Millions of Addresses Given Out

  2000 2001 2002 2003 2004 2005 2006
< 1,000 0.10 0.16 0.18 0.25 0.35 0.44 0.52
1,000 – 8,000 2.42 4.47 3.23 3.45 4.49 5.07 6.10
8,000 – 64k 18.79 12.81 11.35 14.00 15.99 15.46 17.17
65k – 500k 35.98 32.19 20.28 25.51 42.01 34.23 49.64
500k – 2M 12.68 24.64 21.30 31.98 44.63 41.63 46.64
> 2M 8.39 14.68 12.58 12.58 20.97 68.62 41.42

The increase in the 2M+ blocks was solely responsible for the high number of addresses given out in 2005. In 2006, there was growth in all categories except the 2M+ one (even the 500k – 2M category increased in number of addresses if not in number of blocks). When the 2M+ blocks are taken out of the equation, 2005 had a total of 96.83 million addresses (January 1, 2006) and 2006 had 119.06 million given out, even without fully correcting for the ARIN reporting particularities. Apparently there is still an underlying upward trend.

Figure 1 shows the amounts of address space given out by IANA and by the RIRs every year from 1994 to 2006.

Figure 1: IPv4 Address Space Given Out from 1994 to 2006

Figure 2 shows the amounts of address space marked as "in use" by IANA and by the RIRs. The difference between the two numbers is what the RIRs hold in order to satisfy day-to-day address space requests. This amount is usually two years' worth of address space.

Figure 2: IPv4 Address Space in Use from 1994 to 2006

Depletion

The exact moment when the IPv4 address space will be depleted depends on numerous factors. Since 1997, the three-year period with the largest growth in yearly address use was from 2003 to 2005 relative to the 2002 figure: a factor 2.4, or 34 percent per year. If this growth repeats itself in the next three years, we will be out of IPv4 addresses in the second half of 2010.

Interestingly, the period with the lowest growth also includes the year 2003: from 2001 to 2003 relative to 2000. In 2003, 12 percent more addresses were given out than in 2000, for an average increase in yearly use of 4 percent. If this is the new trend for the coming years, we can expect to run out of IPv4 addresses in mid-2013. There is of course no reason to assume that future IP address use will conform to patterns seen in earlier years, but we really have nothing else to base our projections upon.

So anyone expecting to obtain new IPv4 address space more than three years from now is taking a big risk. With the IPv4 reserves visibly diminishing each year, the question is: What can we, as a community, do to make the IPv4 address depletion as painless as possible? IPv4 addresses are useful only if the people who need them can obtain them, meaning that using up addresses unnecessarily fast or locking up the still-available reserves are both suboptimal solutions. It has been suggested that turning IPv4 address space into a tradable commodity would allow a free market to form, aiding the efficient distribution of address space from those who have it to those who need it.

This scenario has several problems. First, when supply is limited and demand is high, prices rise and hoarding becomes lucrative. So the effect of making address space tradable could be a reduction of available address space rather than an increase. And certainly, as trading IPv4 space becomes more likely, holders of large address blocks will be less inclined to return them. Finally, more than half of the IPv4 address space in use is held by organizations in the United States, whereas the developing world has comparatively little address space. The prospect of having to buy address space from American companies that got the space for free is not likely to be popular in the rest of the world.

Address Reclamation a Solution?

There are two large classes of potentially reclaimable address space: the class E reserved space (240.0.0.0255.255.255.255) and the class A blocks given out directly to end users by IANA. The class E space has 268 million addresses and would give us in the order of 18 months worth of IPv4 address use. However, many TCP/IP stacks, such as the one in Windows, do not accept addresses from class E space and will not even communicate with correspondents holding those addresses. It is probably too late now to change this behavior on the installed base before the address space would be needed. There are currently 42 class A blocks and another two /8s from class C space listed as given out to end users—738 million addresses. The U.S. government uses about 10 of those blocks; 21 of them are not present in the Border Gateway Protocol (BGP) routing table.

Although harsh judgments about the need for so much address space are easily made from the outside without having all the pertinent information, it seems reasonable to try to reclaim some of this space. I would consider getting back half of this space a big success, but that would give us only 2 years worth of additional address space. There are also 645 million addresses of older class B assignments, but reclaiming those will be extremely difficult because nearly 8,000 individual assignments are involved. Reclaiming a class B block is probably not much easier than reclaiming a class A block, but the amount of address space returned is less than half a percent.

Planning for the End Game

So what should we do? In my opinion: promote predictability. The situation where we run out of IPv4 address space much faster than expected would be very harmful as organizations struggle to adjust to the new circumstances. On the other hand, if the IPv4 space unexpectedly lasts longer, people may be disinclined to believe space is really running out and then would be unprepared when it does. Artificially delaying running out of IPv4 address space also prolongs the situation in which it is difficult to get IPv4 space, but not enough people feel the pain to initiate IPv6 deployment. One solution worthy of consideration would be to impose a worldwide moratorium on the change of IPv4 address allocation and assignment policies after a certain date to aid this predictability. If some kind of encouraged or forced reclamation of older class A blocks is desired, this process should be instigated sooner rather than later, both for the sake of predictability and because it gives the address holders involved time to reorganize their networks. Another small but useful step would be to limit the size of address blocks given out. This scenario would be like the agreement between the RIRs and IANA that the RIRs will receive two /8s at a time in the future. The situation where a single /9 or /8 allocation constitutes 5 or even 10 percent of the address space given out in that year makes adequate predictions extremely difficult, and also runs the risk that a good part of the address block in question will never be used as circumstances change. Limiting individual allocations to a /11 or /12 would be better, even if it requires the requesting organization to come back for more address space several times per year.

Finally, it seems prudent for all organizations using public IPv4 address space to start planning for the moment that they themselves, or third parties that they communicate with over the public Internet, can no longer obtain additional IPv4 address space.

References

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

[2] AfriNIC, http://www.afrinic.net

[3] APNIC, http://www.apnic.net

[4] ARIN, http://www.arin.net

[5] RIPE NCC, http://ripe.net

[6] IANA Internet Protocol v4 Address Space http://www.iana.org/assignments/ipv4-address-space

ILJITSCH VAN BEIJNUM holds a Bachelor of Information and Communication Technology degree from the Haagse Hogeschool in The Hague, Netherlands. In 1995, he found himself in the emerging Internet Service Provider business. There he learned about system administration, IP networking, and especially routing. After first starting a small ISP with four others and working as a senior network engineer for UUNET Netherlands, he became a freelance consultant in 2000. Not long after that, he started contributing to the IETF Multihoming in IPv6 working group. He wrote the book BGP: Building Reliable Networks with the Border Gateway Protocol, ISBN 0-596-00254-8, published by O'Reilly in 2002, and Running IPv6, ISBN 1590595270, published by Apress in 2005. E-mail: iljitsch@muada.com