Skip to main content

Last /8 Allocation Criteria Revision

This policy proposal has been withdrawn
Publication date
Draft document
Proposal Version
2.0 - 12 Apr 2016
All Versions
02 Jun 2016
Working Group
Address Policy Working Group
Proposal type
  • Modify
Policy term

Summary of proposal:

According to the current IPv4 Address Allocation Policy, since September 2012 each LIR is entitled to receive exactly one /22 – no more, no less. This is the strictest run-out policy among the RIRs and is posing serious competitiveness problems to small players and especially new entrants. Since the last /8 policy has been approved and became effective, the RIPE NCC free pool has been refilled with recovered space distributed by the IANA and with address space returned to RIPE NCC. The extra space, which is somewhere between a /9 and a /10 in size, could be used to give small players a real chance to grow to a comfortable size (a size that may allow them to fulfill their further needs on the transfer market).

Policy text:

a. Current policy text

5.1 Allocations made by the RIPE NCC to LIRs


1. The size of the allocation made will be exactly one /22.
2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
3. The LIR must confirm it will make assignment(s) from the allocation.


b. New policy text

5.1 Allocations made by the RIPE NCC to LIRs


1. The size of the allocation made from 185/8 will be exactly one /22.
2. The LIR must confirm it will make assignment(s) from the allocation.
3. Subsequent allocations of a /22 (or equivalent) can be requested every 18 months from the moment of the last allocation if the following conditions are met:
   3.1. The LIR has not transferred any IPv4 address space to another LIR, a member of another RIR, or an End User.
   3.2. There is enough space in the free pool outside the 185/8 block to perform the allocation.
   3.3. The LIR is holding less than a total count of /20 IPv4 addresses in its registry.
   3.4. The LIR can prove that IPv6 has been deployed. To do so, the LIR must:
   (i) Achieve at least 3 RIPEness stars and
   (ii) Must have IPv6 assignments made within its IPv6 allocation and registered in the RIPE Database.


a. Arguments supporting the proposal

  • The essence of last /8 policy regarding allocations from 185/8 remains unchanged.
  • The RIPE NCC has the strictest policy of allocations from the remaining IPv4 address pool. All other RIRs allow in some way more than a single /22 per member as long as enough address space is available.
  • 36 months after the activation of the last /8 policy, the RIPE NCC still has almost 99% of a /8 remaining, thanks to recovered space from IANA. This extra space is more than the equivalent of a /10, quite close to the equivalent of a /9.
  • While the spirit of the last /8 policy was to save IPv4 space for later entrants, the free pool has been abused in several ways: in the most severe cases to make a quick profit on the transfer market – preventing 185/8 address space from reaching new entrants. Allowing a little more space for growing networks with not enough addresses is a fairer way to distribute space.
  • Members have started to show discontent due to the effects and side-effects of the last /8 policy. This changes are supposed to lower the level of discontent by allowing small players and new entrants to have better chances of survival on the market.
  • Some End User organisations requiring IP blocks sometimes as low as a /26 are being advised to become LIRs in order to get addresses. The result is that these organisations receive a /22, wasting space from 185/8. 

b. Arguments opposing the proposal

  • Further allocations will speed up the depletion of the free pool.
  • If every member holding less than a total of /20 addresses would submit a request for a new /22 allocation every 18 months, the recovered pool could be depleted in 2-3 years from now.
  • Availability of more address space can affect the IPv4 transfer market by reducing demand. There may be an impact on the demand for smaller blocks (/22 to /24), with possible impact on their market price. The impact should be lower to non-existent for bigger blocks.