Skip to main content

Reducing Initial IPv4 Allocation, Aiming to Preserve a Minimum of IPv4 Space for Newcomers

This policy proposal has been withdrawn
2017-03
State:
Withdrawn
Publication date
Affects
Draft document
Draft
Authors
Proposal Version
1.0 - 16 Sep 2017
All Versions
Withdrawn
23 Oct 2017
Working Group
Address Policy Working Group
Proposal type
  • Modify
Policy term
Permanent

Summary of Proposal

Adoption of IPv6 has been slower than desired; therefore, IPv6/IPv4 interoperation will be with us for a long time. This policy proposal aims to extend the RIPE NCC's ability to provide a minimum of IPv4 space to newcomers (hopefully for another decade, at least) to allow the use of transition mechanisms. The current consumption rate can be slowed by changing the initial IPv4 allocation size from a /22 to a /24 (or even further), and not allowing a subsequent IPv4 allocation. If the minimum globally-routable prefix changes from a /24 to a smaller prefix, the initial IPv4 allocation should also change to match. Historically, the minimum allocation size (and hence the minimum routable block) was a /19 [see RFC2050], and this has evolved to the current size of 256 addresses (/24). While changing the initial and only IPv4 allocation in the RIPE NCC service region to a /24 should be the primary goal, the authors anticipate it will be possible to agree on an even smaller initial size, if global agreement on routing prefixes longer than a /24 is achieved. In this regard, some research should be performed to test global reachability for prefixes longer than a /24.

Policy Text

a. Current Policy text

[The following text will update section 5.1 in the RIPE Policy Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” if the proposal reaches consensus.]

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.

  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.

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 /24.

  2. 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).

  3. 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. If the minimum allocation size can't be changed into a smaller size by a future policy proposal, full IPv4 run-out in the service region will be declared by the RIPE NCC.

Rationale

Allowing or encouraging intentional run-out of IPv4 addresses is an abrogation of the RIPE community's responsibility. Any measures that can be taken to postpone this point in time should be seen as critical. By extending the availability of IPv4 addresses to newcomers, the community shows goodwill towards competition laws and regulations. The global Internet is going to be dual-stack for another decade or two.

An enterprise, ISP or public/governmental organisation will not be able to run without some IPv4 space and some IPv6 space. Pure IPv6 (i.e. IPv6-only) is not going to be tenable for a long while. Our goal is to keep providing newcomers with as little IPv4 space as possible and as much use of IPv6 space as possible.

The rationale here is that an organisation can operate with a minimal set of IPv4 out front and NAT64 or other transition technology so they can use IPv6 internally. If they can't get that bit of IPv4, they simply can't run on the actual Internet of the next decade or two.

There have been experiments on using routing prefixes longer than a /24. In the future, large ISPs/Carriers could agree to route prefixes longer than a /24 if they are inside well-defined ranges that are easily identifiable and integrated into ACL automation.

a. Arguments Supporting the Proposal

  • A /24 prefix is more than enough as a minimum foothold on the IPv4 Internet for emerging companies that are almost locked-in to 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 a /22 to a /24 will extend the time frame during which new companies can obtain some IPv4 address space in the RIPE NCC 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.

  • According to the RIPE NCC's statistics, there are already over 60 assignments between a /25 and a /29 in size; artifacts of history.  But a look at https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics grepping for "/24" shows that transfers of /24s are common.

b. Arguments Opposing the Proposal

  • Extending the full IPv4 run-out date in the RIPE NCC 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 the IPv6 transition can be facilitated. All that has changed since that consensus is that we now have more data on the rate of consumption.

  • For each /22 (currently allocated), only one prefix will only be added to the global routing system.

    Mitigation/counter-argument: This is mostly inaccurate, as any /22 holder can effectively announce/generate four /24s and many do Fragmentation is ultimately limited not by the size of an RIR allocation, but by global agreement on routable prefixes.

  • 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 an 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.

  • The number of RIPE NCC members will grow even larger.

    Mitigation/counter-argument: While the management of more members can have an impact on the RIPE NCC, experience drawn from recent years' membership growth tells us this can be handled smoothly. On the economics side, it will bring more revenue, and it is easy to foresee lower yearly membership fees (or larger yearly rebates).

  • How would folk announce longer prefixes for DDoS protection?

    Mitigation/counter-argument: As operators accept /24s today, when the allocation size is a /22, it might be wise to accept prefixes longer than a /24 when the allocation size is /24. Of course, this would be in the well-documented address range(s) where /24s are allocated.

c. Alignment with other RIRs