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.
[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.]
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:
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.
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:
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.
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.
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.
Within ARIN's number resource policy manual (version 2017.4 - 8 August 2017) ARIN has a dedicated IPv4 block to facilitate IPv6 deployment on 4.10.
(ref: https://www.arin.net/policy/nrpm.html#four10)
2017-4 proposal (Modify the minimum size of initial allocations to ISPs) was ratified on 16 August, changing the initial allocation size from a /22 to a /24.
(ref: https://politicas.lacnic.net/politicas/detail/id/LAC-2017-4?language=en)