Marco Schmidt

Taking a Closer Look at the Last /8

Marco Schmidt
4

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.  

4

You may also like

View more

About the author

Marco Schmidt Based in Amsterdam, Netherlands

Marco Schmidt is the RIPE NCC’s Policy Development Officer. In this role, he supports and drives the RIPE (community) Policy Development Processes (PDP), both externally and internally. He also supports the implementation of accepted policies into RIPE NCC procedures and workflow. Marco initially joined the RIPE NCC as an IP Resource Analyst (IPRA) for the Registration Services department, where he worked for five years. Within that role, he gained valuable experience in evaluating IPv4, IPv6 and Autonomous System Number requests while providing support to the RIPE NCC membership.

Comments 4