IPv4 Consumption Rates
At least as far back as the early 1990's the IETF network community began discussing how to deal with the eventual exhaustion of IPv4 network numbers. The community designed a stopgap solution, specifically more flexible allocation methodologies that allowed a finer granularity in allocation size. This modification in addressing policy bought some time in the mid 1990's for the engineering community to work on a longer-term solution, eventually (perhaps temporarily) referred to as IPv6. Today, IPv6 has failed to reach substantial global penetration, and yet the exhaustion of IPv4 address space continues at a growing pace. This analysis attempts to extrapolate, from the best data available, when IANA will allocate all available IPv4 address space to the Regional Internet Registries (RIR).
To capture the rate at which blocks are assigned to the RIRs, we collected IANA's ipv4-address-space file on 14 Sept 2005. To calculate the rate at which the individual RIRs use their assigned space, we took a snapshot of their whois databases on 31 Aug 2005 for APNIC, ARIN, LACNIC, and RIPE. We were unable to get a snapshot from Afrinic in time for this study.
Although the whois datasets come in similar formats, we remove the few differences in order to convert the data to a single shared format. During this process we reduce the assignments for a given RIR to those inside of the address space assigned to them by IANA's ipv4-address-space file. This avoids duplicates created by cross referencing and migration of allocations across RIRs over time. There is also a large block of addresses originally assigned before the creation of the RIRs. These legacy blocks are primarily concentrated in ARIN, but some of them have since migrated to other RIRs. For these, we merge the data from all the RIR databases into a single set we call various.
As mentioned above, we were unable to get a snapshot from Afrinic in time for this analysis, but at the time the AfrinNIC allocation only contained a single /8, out of a total of 256 available /8s, out of 150 allocated to the RIRs. The inclusion of the AfriNIC data would only push the exhaustion point closer to the present. Additionally, we do not have detailed information regarding APNIC's allocations to Local Internet Registries (LIR).
Although we do include data from LACNIC, it is a relatively new RIR and so it has a short period of time over which to model its assignment rates. We also find it likely that this initial rapid increase in LACNIC allocations might represent pent up demand and do not necessarily reflect assignment rates going forward.
When we graph the allocations data for a given registry, we only include address space assigned to the particular registry from IANA's global allocation file. Each registry actually contains some information about allocations that have since migrated to another registry. We ignore this data and only account for assignments in address blocks belonging to the registry according to IANA's assignment file.
As mentioned above, this analysis assumes that allocation policies remain unchanged. Yet as we approach full depletion of IPv4 space from IANA, we expect new policies to emerge to further postpone complete exhaustion of the address space. Furthermore, a growing understanding of the possible exhaustion of the address space, or even the coming policy changes to prevent it, will likely have a dramatic effect on end user behavior.
The figures and tables below provide analysis of individual RIR IPv4 consumption rates, combined RIR IPv4 consumption rates, the rates at which the RIRs assign addresses from the working pool of addresses they have already received from IANA, and finally projections of rates of future allocations from IANA to the RIRs and from the RIRs to LIRs and ISPs.
RIR consumption Rates
Figures 1 through 5 below show IANA allocations to RIRs including APNIC, ARIN, LACNIC, RIPE and address blocks assigned to "various" organizations prior to the existence of the RIRs. These graphs include the IANA /8 allocations to each RIR as well as the RIR allocations to users, ISPs, large companies, and their customers. The graphs only show allocations, not announcements or reachability.
The black line in each graph describes the rate at which IANA allocated IPv4 address blocks to each RIR. The red and green lines depict the rate at which the RIRs assign blocks (sub-blocks of the original IANA /8 allocations) to downstream ISPs and end users. The red line represents the first occurrence of an assignment when an RIR allocates an IPv4 address block to an ISP. The green line represents the last, most specific assignment found in the data.
These graphs reflect the process of larger organizations breaking up their original assignments and allocating them to their customers. The gap between the red line and the green line shows the time it takes between the allocation from the registry to an organization (provider) and then the sub-allocations from that provider to its customers. Since the green line depicts a number of small assignments, it is both smoother and a more accurate reflection of the underlying structure. Since more specific assignments from providers to customers drive the green line, this line will gradually approach the red line. In fact the green line converges to the red line as the time between the allocation and the suballocations exceed the time between the allocation and the present.
In 1993, IANA sought to bring the IANA address assignment file up to date. During this process many historical 'legacy' allocations were simply assigned the date of August 1993, the first date precise records began. When ARIN was created, it inherited the original unaltered database containing information on legacy prefixes. Over time, RIRs other than ARIN have maintained legacy blocks that are owned by companies within their regions, although the majority of legacy prefixes remain with ARIN.
RIR consumption combined
To examine the size of the total allocations across the RIRs and legacy blocks, we took each of the individual graphs and stacked them. The top of the stacked graphs represents the total allocated space at any given point in time.
The RIR poolAt any point in time, each RIR holds a number of addresses allocated to it by IANA that have not yet been assigned or allocated to one of the RIR's customers. This set of unassigned IPv4 addresses is called the RIR's pool. The size of the pool, based on the number of addresses, represents each RIR's ability to satisfy IPv4 address requests. Figure 9 shows the relative sizes of the different RIR's pools between 1998 and 2005. IANA allocation policy states that an RIR should be assigned an allocation equal to its previous 18 months of allocations with a maximum allocation of 3 /8s. RIRs appear to make this request when their pool size is around 2 /8s. We use this policy in the model presented below.
RIR projected allocations
We used the parameters in table 1 to curve fit the slopes of the lines in figures 1 through 5, according to the equation in the first row of the table.
Figures 10.a and 10.b above present actual data up to 2005 and extrapolated data using the equations from Table 1.
Figures 11.a and 11.b start with the allocation size graphs from figure 10, add the RIR pool sizes, and stack the results to show the current number of allocations by IANA. The allocations to individual RIRs are divided into two areas. The checkered area represents the number of addresses allocated from IANA to the RIR but not yet assigned to customers. The solid area represents the number of addresses assigned from the RIR to specific end users. We recognize the theoretical availability of several reserve blocks, e.g., special use blocks such as 1918 addresses [ RFC 1700, RFC 1797, RFC 1918, RFC 2544, RFC 3068 ], reserved for multicast [ RFC 3171 ], and unspecified future use [ RFC 1700]. The black line divides actual data, to the left, from projected data, to the right.
Figures 12.a and 12.b zoom in to the period 2003-2010. The new dashed black vertical lines on the right side of the graph represent the different dates at which IANA would be projected to exhaust its space. The ordering of the IETF reserved blocks reflects the likely order in which they would be reclaimed by IANA for reuse as standard address space.
The first dashed line, around June 2008, reflects the projected exhaustion date should nothing change: no run on the bank; no change in assignment policy; and no reclamation of reserved space. The second dashed line, around October 2008, shows how much time, again assuming no change on the part of consumers or policy, reclamation of the "future use" address block would give us. The third line, around March 2009, shows the point in time at which we would need to start reclaiming "special use" address space. We emphasize that while reclamation of all such addresses seems unlikely, the least likely to be reclaimed is this final component, which includes loopback and private addresses used ubiquitously throughout the Internet.
The light blue represents LACNIC, a fairly new RIR that does not yet have a large quantity of data to analyze. LACNIC appears to have had a large number of allocations in its first year, which we believe derives from pent up demand, not necessarily an an accurate reflection of long term demand. That said, even if we remove LACNIC, the exponential nature of the underlying functions results in postponing the exhaustion date by less than a year.
In October 2005, CAIDA's analysis of IPv4 consumption rates (sponsored by ARIN and presented at the October 2005 ARIN meeting) used an exponential model that predicted that, at 2005 IPv4 address allocation rates, IANA would allocate all unused IPv4 space by 2008, with exhaustion of the additional multicast and special-use space following in late 2008 and early 2009.
- Internet Society: Jon Postel http://www.isoc.org/postel/
- RFC 1700 http://www.faqs.org/rfcs/rfc1700.html
- RFC 1797 http://www.faqs.org/rfcs/rfc1797.html
- RFC 1918 http://www.faqs.org/rfcs/rfc1918.html
- RFC 2544 http://www.faqs.org/rfcs/rfc2544.html
- RFC 3068 http://www.faqs.org/rfcs/rfc3068.html
- RFC 3171 http://www.faqs.org/rfcs/rfc3171.html