This report generated at 19-Jun-2013 08:00 UTC.
|IANA Unallocated Address Pool Exhaustion:|
|Projected RIR Address Pool Exhaustion Dates:|
|RIR||Projected Exhaustion Date||Remaining Addresses in RIR Pool (/8s)|
|RIPE NCC:||14-Sep-2012 (actual)||0.8909|
"Exhaustion" is defined here as the time when the pool of available addresses in each RIR reaches the "last /8 threshold" of 16,777,216 addresses.
The IPv4 address space is a 32 bit field. There are 4,294,967,296 unique values, considered in this context as a sequence of 256 "/8s", where each "/8" corresponds to 16,777,216 unique address values.
As noted in RFC 5735 a number of address blocks are 'reserved.' There are a total of the equivalent of 35.078 /8 address blocks that are 'reserved'. (This is composed of 16 /8 blocks reserved for use in multicast scenarios, 16 /8 blocks reserved for some unspecified future use, a /8 (0.0.0.0/8) for local identification, a /8 for loopback (127.0.0.0/8), and a /8 reserved for private use (10.0.0.0/8). Smaller address blocks are also reserved for other special uses.)
The remaining 220.922 /8 address blocks are available for use in the public IPv4 Internet. The current status of the total IPv4 address space is indicated in Figure 1.
This allocated number pool is managed by the Regional Internet Registries, (RIRs) and the breakdown of IANA allocated address blocks to each of the RIRs is shown in Figure 2.
Any individual IPv4 address can be in any one of five states:
The current totals of IP addresses according to this set of states is shown in Figure 3.
This status can be further categorized per RIR, as shown in Figure 4.
Another view of the address state pools is by grouping the address space into a sequence of /8s, and looking at state sub totals within each /8 address block. The following view shows the current status of the IPv4 address space as 256 /8 columns each describing a pool of 16,777,216 addresses.
IPv4 Address are drawn from the Unallocated Address Number Pool, administered by the IANA. These allocations are made to the Regional Internet Registries (RIRs), and the allocation unit is in units of /8s.
This series can be further broken down by RIR.
RIRs perform assignments of address blocks to ISPs and local Internet registries. The cumulative number of assigned addresses over time is shown in Figure 8.
This data can be further categorized by RIR.
Each RIR allocates from its locally administered number pool. When the pool reaches a low threshold size a further address block is allocated by IANA to the RIR. The allocation quantity is based on the allocation activity recorded by the RIR for the 18 months prior to the allocation request, rounded to the next largest /8 address block. The pool size within each RIR over time can be derived from the allocation and assignment series data, producing the following graph. This is indicated in Figure 10.
The more recent data from this series is shown in Figure 10a.
The next data set is total span of address space advertised in the BGP routing table over time. The data has been collected since late 1999. This is shown in Figure 11.
Models for Data Series
The foloowing figure constructs a relatively complete view of the sequences of various address pools over time. Figure 16 shows the total amount of space allocated by the IANA to the RIRs, the total amount of space that has been allocated by the RIRs, the total amount of space advertised in the routing table, the total amount of unadvertised space that has been allocated, and the total amount of address space that is held in the RIR's local allocation pools. This is indicated in Figure 16. The objective here is to generate a predictive model that can be used to extend these series forward in time in order to estimate a point of exhaustion of the unallocated address pool
The more recent section of these series is indicated in Figure 17. The approach used here is to take a recent sequence of data as the baseline for a predictive model.
IANA Data Series
Before looking in detail at the advertised address space, the IANA allocation data and RIR allocation data will be examined, and a relatively straightforward form of data analysis will be performed over the data series.
The IANA allocation data is indicated in Figure 18.
The RIR allocation data is indicated in Figure 19. This data is shown in both its original format, and in a smoothed format, using a sliding window smoothing algorithm, in a double pass of the smoothing algorithm across the data.
BGP Advertised Address Range
The BGP advertised address span data is indicated in Figure 20.
Modelling RIR Allocations
The approach used here to modelling overall address consumption levels is to use the RIR allocation information as the baseline of the address consumption model. This approach treats an address as "consumed" once it has been allocated or assigned by an RIR. The data used to construct the time series of allocations is the allocation "stats file" published on a daily basis by each RIR, placed into a time series, as indicated in Figure 9. The first order differential of the smoothed total allocation rate can be generated, as shown in Figure 27. A least squares linear best fit can be generated for the recent part of this data.
The allocation rates for each RIR are shown in the following figures.
The daily allocation data, and the O(2) polynomial best fit to the data is shown in the following figures.
The data used in this model is based on public data sources, derived from data published by the IANA and the Regional Internet Registries.
The data used in this exercise is a combination of the RIRs' statistics reports and the RIRs' resource databases. There are some inconsistencies in this data, and the analysis here has had to make some assumptions regarding the status of address blocks and the allocation dates. Reports on these inconsistencies can be found at:
21 June 2011
I have revised this model somewhat, in an effort to introduce a measure of uncertainty in the projection of exhaustion for each RIR.
25 November 2010
Like all projections, this "potaroo projection" is simply one possible model of the future, based on certain assumptions about the behaviour of the address allocation system, and based on the data available only from published sources. This latter constraint does impact the ability of the model to map cleanly to the current address allocation framework. Notably, the allocation system uses the concept of "address reservations" in determining whether an RIR has reach a threshold point that makes it eligible to apply to IANA for allocation of further /8 address blocks. As these reservations are not part of an RIR's published data, this adds some element of uncertainty to the predictive model. The prospect of the forthcoming hiatus in the supply of IPv4 addresses also appears to have hastened some network deployment plans on the part of many service providers, and while the RIRs continue to adhere to the policies and practices of allocation of addresses in response to demonstrated need, there is a noted escalation of demand for addresses in recent times that is likely to persist in the coming months.
The November 2010 allocation of a /8 to AFRINIC was not predicted by this model, due to the hidden factor of the reserved blocks in the AFRINIC registry. The continued escalation of demand levels is also adding some pressure to the demand model.
A conservative view of predicted address consumption forecasts APNIC exhausting its available address pool in late 2011 at this point in time. A less conservative model that uses settings that reflect continued escalation of demand through 2011 now forecasts APNIC exhausting its address pools in September 2011. The uncertainty of this September date is +/- 3 months, so that within a 95% confidence level APNIC will exhaust its address pools sometime between June 2011 and December 2011.
6 June 2010
I've made a couple of very slight changes to the RIR operational model to align it to current practices. ARIN appears to to be operating off a low threshold of slightly under 2 /8s in its unallocated pool when if requests IANA for a further 2 /8s, and the RIPE NCC use a low threshold value of slightly greater than 2 /8s in its unallocated pool. This change to the model has had a small impact on the predicted exhaustion dates.
11 May 2009
I've made a couple of changes to the prediction model to align with current RIR practices and my understanding of the manner in which the legacy B and C blocks will be managed by the RIRs.
The RIPE NCC has commenced allocations from 22.214.171.124/8 in February 2009. This is a legacy Class B block that is marked as "various". I've moved this block into the RIPE-managed address pool and used the recent allocations from this block as part of RIPE's total set of allocation in terms of demand modelling RIPE's future needs.
The set of legacy /8s that used to be the old Class B and C space is a set of approximately 50 /8s. A summary of these address blocks can be found here. After making the change for 188/8 there are the equivalent of 7.4731 /8s (or some 125.4 million addresses) unassigned in the remaining "various" legacy /8 address blocks. At the time IANA reaches the last 5 /8s (the "IANA Exhaustion time" as defined by current address allocation policies), these unassigned addresses in the legacy /8s are then distributed evenly to the RIRs. However, as 188/8 was already part of this collection of legacy /8 blocks, the distribution includes a smaller allocation to the RIPE NCC. Using this algorithm, when IANA reaches the last 5 /8s each RIR recceives a further 1.69462 /8s from the "various" pool, except for RIPE, which recieves a further 0.69462 /8s.