| | | HOME | | | RESEARCH | | | DATA | | | TOOLS | | | PUBLICATIONS | | | WORKSHOPS | | | PROJECTS | | | FUNDING | | |
|
IPv4 Consumption Rates
Table of Contents
IntroductionAt 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). MethodologyTo 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. CaveatsAs 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. ResultsThe 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 RatesFigures 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. 
Figure 1. APNIC IPv4 allocated /8s. 
Figure 2. ARIN IPv4 allocated /8s. 
Figure 3. LACNIC IPv4 allocated /8s. 
Figure 4. RIPE IPv4 allocated /8s. 
Figure 5. IPv4 allocated /8s of various organizations who received allocations prior to the existence of the RIRs. 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 combinedTo 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. 
Figure 6. The total allocated /8s by the most specific allocation to RIR end users. 
Figure 7. The total allocated /8s by the first allocation to RIR customers such as ISPs. 
Figure 8. The total allocated /8s as seen in IANA's records. The RIR poolRIR projected allocations
Table 1. Projection of first allocation.
Figures 10.a and 10.b above present actual data up to 2005 and extrapolated data using the equations from Table 1. 
Figure 11.a IANA IPv4 first /8 allocations to RIR customers between 1983-2005 
Figure 11.b IANA IPv4 /8 allocations to RIR specific end users between 1983-2005 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. ConclusionsIf we assume that current consumption rates continue unchanged, a large and entirely unwarranted assumption, and the number of reclaimable addresses stays small, then IANA's IPv4 pool will exhaust in March 2009. Codetarball: code/whois-ipv4-analysis-0.1.tar.gz References
|
||||||||||||||||||||||||||||||||||||||||||||||||
Cooperative Association for Internet Data Analysis (CAIDA)