You are here: Home > Participate > Policy Development > Policy Proposals > IPv4 Waiting List Implementation

Changes to IPv4 Waiting List Implementation

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted

Summary of Proposal:

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. insert: </p>

insert: <p>

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 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. delete: </p> delete: <p> 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. defines a way forward when that happens. insert: </p>

insert: <p>

 

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 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: text ( insert: <a href="../../../../../resolveuid/88d2dc23cd0446c388ff0ffcfbd0869a" data-linktype="internal" data-val="88d2dc23cd0446c388ff0ffcfbd0869a"> ripe-708 insert: </a> ):

delete: <h4> insert: <p>

[...] Keep existing text of 5.1 Allocations made and add: insert: </p>

insert: <p>

All address blocks smaller than a /24 will be held by the RIPE NCC to LIRs delete: </h4> delete: <p> Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC" delete: </p> delete: <p> On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: delete: </p> delete: <ol> delete: <li> The size of the allocation made will be exactly one /22. delete: </li> delete: </ol> delete: <ol start="2"> delete: <li> The sum of all allocations made to a single LIR and are declared unallocatable until the missing fragments are received/recovered by the RIPE NCC after 14 September 2012 is limited to a maximum of 1024 IPv4 addresses (a single NCC. insert: </p>

insert: <p>

Once an equivalent of a /22 or the equivalent thereof). delete: </li> delete: </ol> delete: <ol start="3"> delete: <li> The LIR must confirm it will make assignment(s) from the allocation. delete: </li> delete: </ol> delete: <p> In case an allocation of a single /22 as per clause 1 can no longer be made, allocated, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve first-come-first-served waiting list. At that point in time time, the contents of section 5.1 of this policy document will be automatically replaced with the contents of section 5.1bis and the existing section 5.1bis will be deleted from this policy document. document. 

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

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

  1. All allocation requests are placed on a first-come-first-serve first-come-first-served 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 If this allocation limit has been reached or exceeded exceeded, an LIR can not cannot request any further IPv4 resources an IPv4 allocation under this policy. delete: </li> delete: </ol> delete: <ol start="4"> delete: <li> 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 /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.

 

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 Another possible solution would be to stop allocating IPv4 altogether, but this is likely to be unacceptable for IPv4 allocations. If the current policy remains this waiting list is going to grow indefinitely with most LIRs never getting any IPv4 space [ delete: <a href="https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf" data-linktype="external" data-val="https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf"> 1, slide 14 delete: </a> ]. And if the RIPE NCC given their responsibility as an LIR gets its /22 it will be many years after it has requested it, which will not help new LIRs starting up. RIR for Internet numbering resources.

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 delete: <a href="https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf"> [1, [ insert: <a href="#[1]" data-linktype="anchor" data-val="0"> 1, slide 14] 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 from the RIR for as long as possible.

By extending the availability of IPv4 addresses to newcomers, the RIPE community demonstrates goodwill towards with regards 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. delete: </p> delete: <p> insert: <a id="[1]"> insert: </a> [1]: delete: <a href="https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf"> insert: <a href="https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf" data-linktype="external" data-val="https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf"> https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf

 

a. Arguments Supporting the Proposal

delete: <ul> delete: <li> insert: <p>

A /24 prefix is more than enough as a minimum foothold on the IPv4 Internet for emerging companies almost locked-in into 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. delete: </li> delete: <li> insert: </p>

insert: <p>

Reducing the initial/only allocation from /22 to /24 (only after the runout and during the waiting list phase) will extend the time frame timeframe 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). delete: </li> delete: <li> 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. delete: </li> delete: </ul> insert: </p>

 

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. insert: <br />

    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. insert: <br />
    insert: <br />
  • A /24 allocation size will increase the global routing table's size.
    Mitigation/counter-argument: Any Right now, 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. insert: <br />
    insert: <br />
  • 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 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. While giving newcomers "only a /24" may seem unfair, the alternative is completely running out and giving them nothing at all. having longer waiting periods while on the waiting list. insert: <br />
    insert: <br />
  • 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 in recent years tells us this can be smoothly handled. On the economics side, it From an economic perspective, this will bring more revenue, and it is easy to foresee lower yearly membership fees (or larger yearly rebates). insert: <br />
    insert: <br />
  • 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, to the RIR remain a problematic issue, because holders can make money out of the resources they (think they) don't need, instead of returning it to the pool for free. insert: <br />
    insert: <br />
  • 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 that changing the transfer ban window is not of utmost urgency.

 

c. Alignment with other RIRs:

  • AFRINIC insert: <br />
    No waiting list defined by AFRINIC policies yet.
    Within AFRINIC’s Consolidated Policy Manual (version 1.3 - 23 November 2018) AFRINIC has a Soft Landing Policy, changing the minimum initial allocation size from a /22 to a /24 in the final exhaustion phase.
    https://www.afrinic.net/policy/manual#Soft-Landing
  • insert: </ul>
insert: <ul>
  • APNIC
    Will have a waiting list once running out of the primary IPv4 pool (103/8). insert: <br />
    APNIC used to have a waiting list for the IPv4 Recovered pool, which used to serve as a second IPv4 pool to provide additional IPv4 space to existing member. A recent policy change was accepted to abolish this waiting list, to save returned address space for new members only. insert: <br />
    https://www.apnic.net/community/policy/proposals/prop-129 insert: <br />
    insert: <br />
    The APNIC Community is discussing a policy proposal approved a policy change reducing the maximum allocation size of 103/8 IPv4 address pool to a /23. This proposal was published on 18 January 2019.
    https://www.apnic.net/community/policy/proposals/prop-127
  • insert: </ul>
insert: <ul>
  • ARIN
    Within ARIN's Number Resource Policy Manual (version 2017.4 - 8 August 2017) delete: <br /> ARIN has a dedicated IPv4 Provides recovered IPv4 space via a waiting list since IPv4 runout in September 2015. insert: <br />
    https://www.arin.net/resources/guide/ipv4/waiting_list/ insert: <br />
    Currently policy proposals are under discussion to restrict the block to facilitate IPv6 deployment on 4.10. delete: <br /> delete: <a href="https://www.arin.net/policy/nrpm.html#four10"> https://www.arin.net/policy/nrpm.html#four10 size or to abandon the waiting list. The problem statement for both proposals include the observation that the provision of large IPv4 blocks lead to misuse of the waiting list. insert: <br />
    insert: <a href="https://www.arin.net/participate/policy/drafts/2019_2/" data-linktype="external" data-val="https://www.arin.net/participate/policy/drafts/2019_2/"> https://www.arin.net/participate/policy/drafts/2019_2/ insert: </a> insert: <br />
    insert: <a href="https://www.arin.net/participate/policy/drafts/2019_7/" data-linktype="external" data-val="https://www.arin.net/participate/policy/drafts/2019_7/"> https://www.arin.net/participate/policy/drafts/2019_7/
  • insert: </ul>
insert: <ul>

 

insert: <hr />
insert: <h2>

insert: <a id="impact-analysis"> insert: </a> Impact Analysis insert: </h2>

insert: <h3>

A. RIPE NCC's Understanding of the Proposal insert: </h3>

insert: <h5>
Waiting List insert: </h5>
insert: <p>

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. insert: <br />
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. insert: </p>

insert: <h5>
Policy Activation insert: </h5>
insert: <p>

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. insert: </p>

insert: <p>

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). insert: </p>

insert: <p>

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). insert: </p>

insert: <p>

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. insert: </p>

insert: <h5>
Allocation Size and Criteria insert: </h5>
insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: <br />
insert: <br />
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. insert: </p>

insert: <h5>
Prefixes Smaller than /24 insert: </h5>
insert: <p>

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). insert: </p>

insert: <p>

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. insert: <br />
The proposed policy makes it clear that such small ranges will not be allocated. insert: </p>

insert: <p>

  insert: </p>

insert: <h3>

B. Impact of Policy on Registry and Addressing System insert: </h3>

insert: <h4>

B.1 IPv4 Addresses insert: </h4>

insert: <p>

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. insert: <br />
insert: <br />
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. insert: </p>

insert: <p>

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. insert: <br />
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. insert: </p>

insert: <h4>

B.2  IPv6 Uptake insert: </h4>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <h4>

B.3 Routing insert: </h4>

insert: <p>

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. insert: </p>

insert: <p>

  insert: </p>

insert: <h3>

C. Impact of Policy on RIPE NCC Operations/Services insert: </h3>

insert: <p>

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. insert: </p>

insert: <p>

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). insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

If LIRs have received an IPv4 allocation from the RIPE NCC before, they will not be able to submit an allocation request. insert: <br />
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. insert: <br />
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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

  insert: </p>

insert: <h3>

D. Implementation insert: </h3>

insert: <p>

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. insert: <br />
Internal and external processes and documentation would also need to be updated. insert: </p>

How to read this draft document:

This document relates to the policy proposal 2019-02, “ Reducing IPv4 Allocations to a /24 Waiting List Implementation ”. If approved, it will modify ripe-708, “ IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region ”.

To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.

We indicate changes to existing text in the document like this:

ORIGINAL TEXT NEW TEXT

The text from the current policy document that will be replaced is displayed here.

The proposed text change will be displayed here.  

 

Abstract

This document describes the RIPE community's current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.

Information on the Address Policy WG is available at:

http://www.ripe.net/ripe/groups/wg/ap

Contents

1.0  Introduction

1.1  Scope

2.0  IPv4 Address Space

3.0  Goals of the Internet Registry System

3.1  Confidentiality

3.2  Language

4.0  Registration Requirements

5.0  Policies and Guidelines for Allocations

5.1  Allocations made by the RIPE NCC to LIRs

5.2  Unforeseen circumstances

5.3  Address Recycling

5.4  Sub-allocations

5.5  Transfers of Allocations

6.0  Policies and Guidelines for Assignments

6.1  Assignments to Internet Exchange Points

6.2  Network Infrastructure and End User Networks

6.3  Validity of an Assignment

6.4  Transfers of PI space

7.0  Types of Address Space

8.0  LIR Audit

9.0  Closing an LIR by the RIPE NCC

1.0 Introduction

The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document " Internet Registry System ".

1.1 Scope

This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs.

This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community's policies for ASN assignment and IPv6 are published in the RIPE Document Store at: 
http://www.ripe.net/ripe/docs/policy

2.0 IPv4 Address Space

For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses:

  1. Public IP addresses are distributed to be globally unique according to the goals described in Section 3 of this document. The two types of IPv4 address described in this documents are Provider Aggregatable (PA) and Provider Independent (PI).

  2. Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used. 
    For a detailed description of “Address Allocation for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at:  ftp://ftp.ripe.net/rfc/rfc1918.txt
    For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at:  ftp://ftp.ripe.net/rfc/rfc2993.txt

  3. Some address ranges are reserved for special use purposes. These are described in the  IANA IPv4 Special-Purpose Address Registry  and are beyond the scope of this document. 

3.0 Goals of the Internet Registry System

Public IPv4 address assignments should be made with the following goals in mind:

  1. Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.

  2. Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.

  3. Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.

  4. Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.

3.1 Confidentiality

Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.

3.2 Language

Please note that all communication with the RIPE NCC must be in English.

4.0 Registration Requirements

All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. 

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).

5.0 Policies and Guidelines for Allocations

An allocation is a block of IPv4 addresses from which assignments are taken.

All LIRs receiving address space from the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document.

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.

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 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 insert: <span class="newdifftext"> All address blocks smaller than a /24 will be held by the RIPE NCC and are declared unallocatable until the missing fragments are received/recovered by the RIPE NCC. insert: </span> insert: </p>

insert: <p>

insert: <span class="newdifftext"> Once an allocation of a single equivalent of a /22 as per clause 1 can no longer be made, delete: <span class="newdifftext"> allocated, 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.

delete: <h4> insert: <h5>
5.1bis Allocations made by the RIPE NCC to LIRs when using a waiting list delete: </h4> insert: </h5>

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

  1. All allocation requests are placed on a first-come-first-serve first-come-first-served 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 If this allocation limit has been reached or exceeded exceeded, an LIR can not cannot request any further an IPv4 resources allocation under this policy. delete: </span> delete: </li> delete: </ol> delete: <ol start="4"> delete: <li> delete: <span class="newdifftext"> 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 /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.

5.2 Unforeseen circumstances

A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen. Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it.

In the event that this /16 remains unused at the time the remaining addresses covered by this policy have been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document.

5.3 Address Recycling

Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1.

This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.

5.4 Sub-allocations

Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0.

LIRs wishing to convert their allocations to PA status must contact the RIPE NCC by email at  [email protected] .

LIRs may make sub-allocations to multiple downstream network operators.

The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations.

Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator.

5.5 Transfers of Allocations

The transfer of Internet number resources is governed by the RIPE Document, " RIPE Resource Transfer Policies ".

 

6.0 Policies and Guidelines for Assignments

6.1. Assignments to Internet Exchange Points

A /16 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive one number resource (/24 to /22) according to the following:

  • This space will be used to run an IXP peering LAN; other uses are forbidden.

  • Organisations receiving space under this policy must be IXPs and must meet the definition as described in section two of the RIPE document " IPv6 Address Space for Internet Exchange Points ".

  • IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment.

  • New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined.

  • IP space returned by IXPs will be added to the reserved pool maintained for IXP use.

  • Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN.

6.2 Network Infrastructure and End User Networks

IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.

An explanation of how to register objects in the database can be found in the "RIPE Database User Manual: Getting Started" found at:

http://www.ripe.net/data-tools/support/documentation/getting-started

6.3 Validity of an Assignment

An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database. Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid. An assignment that was based on information that turns out to be incorrect is no longer valid.

6.4 Transfers of PI space

The transfer of Internet number resources is governed by the RIPE Document, " RIPE Resource Transfer Policies ".

 

7.0 Types of Address Space

LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered.

Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning:

Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.

LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are:

  • ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider.

  • ALLOCATED UNSPECIFIED: This address space has been allocated to the RIPE NCC or other RIRs for further distribution. If the address space is administered by the RIPE NCC, more specific objects with other values may exist.

  • SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider.

  • LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific  inetnum  must be registered.

  • LEGACY: This indicates the Internet number resource was obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries.

  • ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.

  • ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties.

  • ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services.

The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status.

Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate.

In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.

The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.

8.0 LIR Audit

The RIPE community asked the RIPE NCC to audit LIR operations and ensure consistent and fair implementation of the community's policies. Details of this activity are described in the RIPE Document "RIPE NCC Audit Activity" found at:  http://www.ripe.net/ripe/docs/audit

9.0 Closing an LIR by the RIPE NCC

The RIPE NCC may close an LIR for any of the following reasons:

  • the LIR does not pay money owed to the RIPE NCC

  • the LIR cannot be contacted by the RIPE NCC for a significant period of time

  • the LIR consistently violates the RIPE community's policies

The RIPE NCC takes on responsibility for address space held by closing LIRs.

2019-02: Reducing IPv4 Allocations to a /24 Waiting List Implementation
Reducing IPv4 Allocations to a /24 Waiting List Implementation
Get Involved

The Address Policy Working Group develops policies relating to the allocation and registration of Internet number resources (IPv4 and IPv6 addresses and ASNs) by the RIPE NCC and its members. Anyone with an interest in Internet numbering issues is welcome to observe, participate and contribute to the WG. To post a message to the list, send an email to [email protected] Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.