Version 2 changes the focus of the proposal, looking only at creating a waiting list based on an allocation size of /24 after the current policy no longer works. All other changes have been removed from this proposal and the proposal name has been changed accordingly.
It is expected that later this year (2019) or earlier next year (2020) the RIPE NCC will not be able to continue to allocate /22s to LIRs anymore because the IPv4 pool will have run dry. At that point there is no clear policy in effect. This policy proposal defines a way forward when that happens.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.
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, 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.
text (ripe-708 Link: /publications/docs/ripe-708/ ):
[...] Keep existing text of 5.1 and add:
All address blocks smaller than a /24 will be heldDetails 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:
NCC.Once an equivalent of a /22
On application for IPv4 resources 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 until the RIPE NCC recovers enough address space to allocate contiguous /24 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.
Another possible solution would be to stop allocating IPv4 altogether, but this is likely to be unacceptable for the RIPE NCC given their responsibility as an RIR for Internet numbering resources.
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 Link: https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf ]. 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 Link: #[1] ]. [1, slide 14] Link: https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf . 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 from the RIR for as long as possible.
By extending the availability of IPv4 addresses to newcomers, the RIPE community demonstrates goodwill with regards towards competition laws and regulations. It is recognised that even with the ongoing implementation of IPv6, 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 /24 prefix is more than enough as a minimum foothold on the IPv4 Internet for emerging companies almost locked in to 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 (only after the runout and during the waiting list phase) will extend the timeframe 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).
It is the RIPE NCC's understanding that this proposed policy will change the IPv4 allocation practice from the moment of the exhaustion of RIPE NCCs IPv4 (available) address pool. The proposal will introduce a first-come-first-serve waiting list for IPv4 allocation requests.
If this policy change is accepted, the time at which the IPv4 allocation request is received by the RIPE NCC will determine its position on the waiting list.
The proposed policy will become active at the moment that the RIPE NCC can no longer allocate a /22 IPv4 allocation from the RIPE NCC’s free IPv4 pool. It is the RIPE NCC’s understanding that this applies to a single /22 range or an equivalent of a /22.
It is also the RIPE NCC’s understanding that the /16 held in reserve for unforeseen circumstances as per current policy section 5.2. will be added to the free IPv4 pool before this policy is activated (provided that the reserved /16 is not designated for other use by another policy before that time).
Address space in the reserved IPv4 pool will not be taken into consideration when this policy will be activated (for example recently returned address space still under quarantine).
Once the policy has become active, the RIPE policy “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” will also be updated. As described in the proposed policy, the contents of section 5.1 of the policy document will be automatically replaced with the contents of section 5.1bis and section 5.1bis will be deleted. A new version of the RIPE Document will be published reflecting this change.
The proposed policy also defines that, from the moment it comes into effect, the size of allocation received by LIRs will be reduced to a /24 (currently /22). The proposed policy removes the requirement that the LIR must confirm that it will make assignment(s) from this allocation.
Only LIRs that have not yet received an IPv4 allocation directly from the RIPE NCC will qualify for an IPv4 allocation under this policy. An LIR still qualifies for a /24 IPv4 allocation if all previous IPv4 allocations were received from other LIRs - for example via policy transfer or merger - or were converted by the LIR from PI or Legacy space.
Currently around 700 LIR accounts older than six months would match this allocation criteria and would still qualify for a /24 allocation under the proposed policy.
At the time this analysis was carried out, there were about 2,800 LIR accounts that had received IPv4 allocations from the RIPE NCC but had not yet requested a /22 allocation under the current policy. These LIRs will no longer be able to request an IPv4 allocation from the RIPE NCC once this policy is activated.
Once an LIR has received its /24 IPv4 allocation, it will not be able to request another IPv4 allocation from the RIPE NCC. In accordance with the relevant policies, all LIRs will still be able to request other IPv4 resources, such as temporary assignments or IXP assignments.
The proposed policy stipulates that prefixes smaller than a /24 will not be allocated. If the recovery of missing fragments leads to the creation of a contiguous /24 range, then that prefix will be provided to the next entitled LIR on the waiting list (after a potential quarantine time).
At the time of writing this analysis, the RIPE NCC holds a total of around 6000 IPs in blocks of /29 - /25. Under a strict interpretation of the current policy these blocks of address space will be handed out to LIRs even if they are widely considered as unusable, as they fall below the minimal routable prefix size.
The proposed policy makes it clear that such small ranges will not be allocated.
Under the current policy, based on a linear extrapolation of trends observed over the last 6 months, we expect the IPv4 pool to become empty in the first half of 2020. This is only a rough estimate as the weekly allocation rate fluctuates significantly.
With respect to the waiting list, it is difficult to impossible to make any projections. The RIPE NCC does not know in advance how much IPv4 space will be recovered via de-registrations. However, it is clear that if the allocation size were a /24 instead of a /22, more LIRs would receive addresses from whatever is returned. In the past three years, the RIPE NCC recovered an average of around 80K IPv4 addresses annually. In terms of the current allocation size, this would accommodate around 80 requests per year, while with the proposed allocation size, the number would quadruple to around 320.
Clearly, the time spent on a waiting list will depend heavily on how long the waiting list will grow. In 2018, the RIPE NCC saw approximately 4,200 new LIR accounts being established. It is expected that there will be a significant decrease once organisations can no longer be certain at which point they will receive a (small) IPv4 allocation. In comparison to the current policy, waiting times will be reduced given that four times the number of allocations can be provided. On the other hand, each LIR will receive less address space.
The reduced waiting time might be an incentive for those organisations who require only a small IPv4 block for their network or for IPv6-to-IPv4 translations. Organisations that are in need of larger IPv4 blocks might choose the transfer market over the waiting list.
Whilst it appears from research data that the limited availability of IPv4 addresses has only little impact on the adoption rate of IPv6, it is expected that the depletion of the remaining IPv4 pool held by RIPE NCC will spur some heightened interest in IPv6. A similar surge in requests for IPv6 addresses and information about IPv6 deployment was observed upon the depletion of the IANA free pool in 2011 and the activation of the final /8 policy by the RIPE NCC in 2012, although the latter was likely related to a policy at the time requiring IPv6 addresses as a precondition to receiving the /22 final allocation.
For providers deploying an IPv6-only scenario, the /24 IPv4 allocation could serve to enable connections to IPv4-only services by means of IPv6-to-IPv4 translation. In particular, as the allocation size is equal to what is to be considered the minimal routable prefix size in the global routing table, further de-aggregation of the prefix becomes impracticable. This might result in operational challenges in the implementation of site redundancy or load balancing scenarios that rely on such de-aggregation.
To date, network owners have often resorted to the IPv4 address market to compensate for the fixed and limited IPv4 allocation size available from the RIPE NCC. This will likely continue, but as demand for what is already a scarce resource continues to grow, it is expected that market prices will increase further. In theory, this would reduce the (perceived) gap between the cost of IPv4 and the cost of deploying IPv6, but the immediate impact on IPv6 deployment is estimated to be small.
In conclusion, the effects of depletion of the RIPE NCC IPv4 address pool, along with the introduction of a waiting list and/or reduction in the size of IPv4 allocations, will likely only have a limited effect on the level and speed of IPv6 deployment in the RIPE service region.
The impact of the policy proposal on the routing tables is expected to be insignificant. If the allocation size is not reduced following exhaustion of the pool and activation of a waiting list, up to one hundred /22 allocations could be made annually, some of them likely consisting of non-contiguous prefixes. Under the proposed policy, the RIPE NCC will allocate a few hundred /24 IPv4 prefixes per year. On a total default-free routing table size of around 730,000 IPv4 prefixes that is negligible.
The RIPE NCC has already started preparations for the upcoming exhaustion of the free IPv4 address pool based on the current policy, including a waiting list system. Many of these preparations can continue if this policy change is accepted.
When approaching the moment of policy activation, the RIPE NCC will draw on experience gained during the process of reaching the final /8 in autumn 2012 to ensure a transparent and fair process. LIRs that will have sent their request just before the policy activation, but which couldn’t receive an /22 allocation, will be placed on the waiting list if they fulfil the adjusted allocation criteria (in particular that they have not received an IPv4 allocation from the RIPE NCC before).
Waiting list management will be automated as much as possible. The submission of the IPv4 allocation request will determine the position on the waiting lists. Non-formal requests added in another communication with the RIPE NCC (for example during LIR application or different resource requests) will not be considered.
If LIRs have received an IPv4 allocation from the RIPE NCC before, they will not be able to submit an allocation request.
The RIPE NCC has identified a number of LIRs that only received IPv4 allocations in the early years of the RIPE NCC. As it is not entirely possible to automatically identify how these allocations have been received, these LIRs will still be able to submit the request. The RIPE NCC will then manually review how these IPv4 allocations have been received and if the LIR qualifies for an allocation under the proposed policy. It is difficult to estimate the actual workload, as it is unclear how many of these LIRs will decide to request an /24 allocation.
Before an IPv4 allocation is provided, the RIPE NCC will perform a check to ensure that the LIR on top of the waiting list still fulfils all membership and policy obligations.
As all returned space will be put in quarantine before re-issuing, the RIPE NCC will be able to estimate when IPv4 allocation will become available and perform all relevant checks before this moment.
Despite these additional steps, the RIPE NCC does not expect an overall increase of workload if this policy gets accepted as it is expected that the total amount of resource requests will likely go down once LIRs cannot be certain when they will receive an IPv4 allocation from the waiting list.
The RIPE NCC also expects interest in IPv6 and concerns regarding IPv4 scarcity from policy makers, press and RIPE NCC membership to surge in the wake of the announced changes. The RIPE NCC will take extra communication, outreach and training activities to satisfy this increased interest.
With the information currently available, it is expected that implementation of the proposal would take around one to two months in terms of the software development to facilitate the policy changes in internal RIPE NCC systems. It should be noted that this estimation only includes the implementation of the actual specifications defined by this policy change. Preparations for the upcoming exhaustion that are independent of this policy change are not included.
Internal and external processes and documentation would also need to be updated.