Skip to main content

IPv4 Waiting List Implementation

This policy proposal has been accepted and has been implemented

The new RIPE Document is: ripe-725

You're looking at an older version: 1

The current (published) version is 2
2019-02
State:
Accepted
Publication date
Affects
Draft document
Draft
Authors
Proposal Version
2.0 - 17 Apr 2019
All Versions
Accepted
30 Jul 2019
Implemented
19 Sep 2019
Working Group
Address Policy Working Group
Proposal type
  • Modify
Policy term
Permanent
New RIPE Document

Summary of Proposal:

This policy proposal changes the allocation size to a /24, and because the LIRs that have existed since before 14 September 2012 (the day the main RIPE NCC IPv4 pool ran out) have had plenty of time to request their /22, this policy proposal also removes that "special" date from the policy text and treats all IPv4 allocations equally.

As a useful side-effect, the reduced allocation size will also make it financially less attractive to open LIRs for the sole purpose of speculating on the IPv4 address market.

Policy Text:

a. Current Policy text (ripe-708):

5.1 Allocations made by the RIPE NCC to LIRs

Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC"

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

  1. The size of the allocation made will be exactly one /22.
  1. 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).
  1. The LIR must confirm it will make assignment(s) from the allocation.

In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

b. New Policy text:

5.1 Allocations made by the RIPE NCC to LIRs

Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC"

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

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

In case an allocation of a single /22 as per clause 1 can no longer be made, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve waiting list. At that point in time the contents of section 5.1 of this policy document will be automatically replaced with the contents of section 5.1bis and section 5.1bis will be deleted from this policy document.

5.1bis Allocations made by the RIPE NCC to LIRs when using a waiting list

On application for IPv4 resources, LIRs will receive IPv4 addresses according to the following:

  1. All allocation requests are placed on a first-come-first-serve waiting list. No guarantees are given about the waiting time.
  1. The size of the allocation made will be exactly one /24.
  1. The sum of all allocations made to a single LIR by the RIPE NCC is limited to a maximum of 256 IPv4 addresses (a single /24). Once this allocation limit has been reached or exceeded an LIR can not request any further IPv4 resources under this policy.
  1. The LIR must confirm it will make assignment(s) from the allocation.

In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous allocations again.

All address blocks smaller than the allocation size will be held by the RIPE NCC and are declared unallocatable until the missing fragments are received/recovered by the RIPE NCC and they can be allocated as a contiguous allocation as per clause 2.

Rationale:

The current IPv4 allocation policy allows every LIR to request exactly one /22 of IPv4 address space. Based on current trends the IPv4 pool is going to be depleted within one year, at which point there will be a waiting list for IPv4 allocations. If the current policy remains this waiting list is going to grow indefinitely with most LIRs never getting any IPv4 space [1, slide 14]. And if an LIR gets its /22 it will be many years after it has requested it, which will not help new LIRs starting up.

Analysis has shown that changing the allocation size from a /22 to a /24 will prevent (or at least significantly postpone) the waiting list from growing to an unmanageable size [1, slide 14]. This would allow for a fairer distribution of the limited IPv4 resources amongst LIRs and also reduce the waiting time for LIRs so that new LIRs get some useable IPv4 space reasonably soon.

An enterprise, ISP or public/governmental organisation will not be able to run their Internet facing systems without some IPv4 space and some IPv6 space. Pure IPv6 (i.e. IPv6-only) is not going to be tenable for a long while. The goal of this policy proposal is to keep providing newcomers with a minimal amount of IPv4 space for as long as possible.

By extending the availability of IPv4 addresses to newcomers, the RIPE community demonstrates goodwill towards competition laws and regulations. It is recognised that even with the ongoing implementation of IPv6 the global internet is going to need some IPv4 resources for another decade or two.

To prevent allocating the last /22s from multiple smaller fragments, this proposal starts the waiting list scheme as soon as no contiguous /22 can be allocated anymore. This prevents LIRs from receiving fragmented blocks (which they would need to announce separately in the BGP routing table). It also lets the waiting list start off with those fragments in the available pool, thereby providing a smoother transition to the waiting list because the first LIRs to end up on the list can be immediately served from that pool.

[1]: https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf

a. Arguments Supporting the Proposal

  • A /24 prefix is more than enough as a minimum foothold on the IPv4 Internet for emerging companies almost locked-in into an IPv6 world. As long as the prefix is globally routable, the allocation can be fully or partially used for IPv4/IPv6 translation mechanisms.
  • Reducing the initial/only allocation from /22 to /24 will extend the time frame during which new companies can obtain some IPv4 address space in the NCC's service region without the need to trade for address space (at least during their initial setup).
  • Opening multiple LIR accounts will be less attractive if this policy is approved -- because each new LIR would get less IPv4 space for the same amount of money. Thus, decreasing of the free IPv4 available pool is likely to slow down.

b. Arguments Opposing the Proposal

  • Extending the full IPv4 run-out date on the RIPE NCC's service region can be seen as a way to delay IPv6 deployment.
    Mitigation/counter-argument: The aim has not changed since the first iteration of the last /8 policy; networks require a little IPv4 to use IPv6, and the purpose of the policy has always been to provide that space so that IPv6 transition can be facilitated. The proposed amount of IPv4 addresses for allocations will not drive anyone away from IPv6 deployment. Operators/companies can choose to resort to CGNAT-like technologies, which also won't advance IPv6 deployment.
    Having a waiting list in place will also send the signal that IPv4 resources have run out and are no longer directly available when requested.
  • A /24 allocation size will increase the global routing table's size.
    Mitigation/counter-argument: Any /22 owner can effectively today (without this proposal's approval) announce/generate four /24s out of their /22 allocation. The global routing table's growth is something that can't be controlled from the RIPE NCC service region. There are other RIRs which have decided to change allocations to a single /24.
  • LIRs get less addresses in return for their yearly membership fee. It can be argued that the adoption of this policy will create unfairness between newcomers and organisations that became a LIR during the current application of the last /8 policy.
    Mitigation/counter-argument: Older LIRs also received more IPv4 address space from the RIPE/NCC according to existing rules. Enabling more newcomers to receive IPv4 address space seems to clearly supersede in importance any possible sense of unfairness. While giving newcomers "only a /24" may seem unfair, the alternative is completely running out and giving them nothing at all.
  • The number of RIPE NCC members will grow even more.
    Mitigation/counter-argument: While the management of more members can have an impact on RIPE NCC, experience drawn from recent years' membership growth tells us this can be smoothly handled. On the economics side, it will bring more revenue, and it is easy to foresee lower yearly membership fees (or larger yearly rebates).
  • This proposal doesn't focus on recovering address space, either from existing LIRs or Legacy Resource Holders
    Mitigation/counter-argument: Everyone is free to propose such a policy. The current policy proposal is orthogonal to address space returns. At this point in time, address space returns are also an awkward event, because holders can make money out of the resources they (think they) don't need, instead of returning it to the pool for free.
  • This proposal doesn't touch the 24-month transfer ban.
    Mitigation/counter-argument: Everyone is free to propose such a policy. The authors of this policy proposal feel changing the transfer ban window is not of utmost urgency.

c. Alignment with other RIRs: