We’ve updated our IPv4 graph to tell the whole story about our remaining address pool.
In 2012, we started publishing a
weekly chart
that shows how much IPv4 address space we have in our remaining pool. For the most part, these addresses have come from 185.0.0.0/8 – the so-called “last /8” that we received in 2011. It is from this IPv4 pool that LIRs are able to receive a single /22 allocation (1,024 addresses). There is also a small portion of addresses (marked in yellow) that are reserved for temporary assignments and small allocations to IXPs (a /13 and a /16 respectively), along with a /16 set aside for unforeseen circumstances.
Over time, you would expect the graph to tell a clear story about IPv4 depletion, as we have already allocated more than nine million IPv4 addresses since we reached the last /8. And yet, with around a /8 still remaining after more than three years, the IPv4 graph looks remarkably stable – why is that?
Other Sources of Addresses
While we have been making allocations from 185/8, our available address pool has been getting “topped up” from a number of different sources.
In 2014, LACNIC was the first RIR to reach less than a /9 in remaining addresses. This activated a global policy which caused IANA to begin making periodic allocations from its Recovered IPv4 Pool, giving us new addresses every six months.
Because IANA’s pool hasn’t been growing, these allocations are getting smaller in size and we only expect to receive a further 32,000 addresses in the future. So far, we have received the following: a /11, /12, /13, /14 and a /15 (around four million addresses in total).
In addition to the addresses received from IANA, we have been recovering addresses from our own service region and adding them to this pool. Typically these addresses come from LIRs that have closed down, but also noteworthy are de-registered Provider Independent (PI) addresses. A RIPE Policy requires PI holders to have a contractual relationship with a member of the RIPE NCC for their resources. During the implementation of this policy, resources were de-registered if PI holders voluntary returned their addresses, could not be contacted, or did not comply with the policy. It’s important to note that this policy is now implemented and will no longer be a significant source of recovered addresses in the future.
In total, addresses from IANA’s recovered address pool and those recovered from our own service region have added around 8.5 million addresses since September 2012. This has significantly extended the lifespan of our available pool, but these sources are winding down.
Updated IPv4 Graph
The Address Policy Working Group often discusses policies that would affect the lifespan of our remaining IPv4 pool. At RIPE 71, we were asked to give a clearer picture of the status of our pool, so people could see which addresses were from the last /8 and get a sense of the impact that the returned address blocks were having. To do this, we have updated our IPv4 Address Space Chart , which you can see below.
The graph has the following parts:
- In dark green, you can see the status of 185.0.0.0 (the last /8) which is available for allocation.
- In light green, you can see the other available addresses we have in our pool. This category includes addresses received from IANA’s Recovered IPv4 Pool. It also includes previously allocated or assigned address space that was returned by resource holders in our service region (e.g., when an LIR closes down) which is added to the available address pool after a quarantine period.
- In blue, you can see the address space that is currently reserved. Included in this category is a /13 for temporary assignments, a /16 for allocations to IXPs, and a /16 for unforeseen circumstances. This also includes recovered address ranges still in quarantine.
We think the updated IPv4 graph provides a better understanding of the addresses in our remaining pool. It demonstrates more accurately the true rate of address consumption and we hope it will help to inform the RIPE community’s policy discussions in the future.
Comments 4
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Elvis Daniel Velea •
Hi Marco, considering all the noise on the mailing list during the discussion phase of 2015-01, I would have expected to see a slowdown in the number of allocations made from 185/8 starting August 2015. However, the trend seems to be linear. Do you have any ideas why? Thanks, Elvis Velea Chief Executive Officer V4Escrow LLC
Marco Schmidt •
Hello Elvis, Thank you for your question. In July 2015, the proposal 2015-01 introduced a 24-month holding period for allocations made by the RIPE NCC. This prevents people from opening an LIR account solely for the purpose of transferring their /22 allocation and closing the LIR account. Later, in November 2015, the RIPE NCC Executive Board also made a resolution to temporarily restrict the creation of multiple LIR accounts. While these steps have had some effect, you can see that our membership growth has continued to increase over the past few months. https://labs.ripe.net/statistics/number-of-lirs This has countered the effect of the above measures and, as a result, the decrease of 185.0.0.0/8 has remained more or less linear. I hope this clarifies. Regards, Marco Schmidt Policy Development Officer RIPE NCC
Ross Chandler •
Vast improvement on the old graph.
HRH Sven Olaf von CyberBunker •
Exactly what's the problem with putting the E-class space to use (other than some router vendors appearantly having hard-blocked it in their firmware as we could not get it to route over hardware by some manufacturers - but that's just a matter of forcing people to buy better stuff - which happens automatically if it sees wide use ;) 240.0.0.0 - 255.255.254.0 "for future/experimental use"... i'd say it's "the future" now-ish... considering when they came up with that stuff. so just start distributing it. also can't find anything it would collide with as i don't know of any implementation where it's used for internal addresses.