Skip to main content
  • Legend
  • Added
  • Deleted

This proposal outlines a framework to migrate previously allocated IPv4 resources from one Local Internet Registry (LIR) to another LIR within the RIPE NCC Service Region.

Summary of Proposal:

This proposal outlines a framework to migrate previously allocated IPv4 resources from one Local Internet Registry (LIR) to another LIR within the RIPE NCC Service Region.

Draft Policy Text

New Text

Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that have been previously allocated to them either by the RIPE NCC or by IANA but which are currently not assigned. Re-allocation may only be to another LIR within the RIPE NCC Service Region. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation.

Enabling Methods for Reallocation of IPv4 Resources Re-allocation is to be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis. The re-allocation will be notified to the RIPE NCC who will record the change of allocation. Re-allocated blocks will be signed to establish current allocation owner.

Rationale:

Arguments Supporting the Proposal

  • Once the IANA resources and subsequently the ability of the RIRs to supply LIRs with fresh IPv4 allocations run out, a new mechanism needs to be in place to cope with that situation. With this new policy, a framework is created to enable usage of usageof the probably significant pool of 'allocated but unused' IPv4 resources. By implementing both a permanent and a non-permanent transfer, most mechanisms that will evolve for moving such space can probably be accommodated.
  • Transferring resources between non-LIRs and between LIRs of different RIRs is outside the scope of this policy. Not implementing this or similar policies will not stop such new mechanisms from evolving.
  • In the 3rd version of the proposal, following the feedback received from the community on the previous versions, an additional criteria is proposed for the receiving LIR so that they will need to demonstrate their need for address space in order to receive a re-allocation. The proposed demonstration of need for a transfer from one LIR to another is to keep it consistent with the criteria to receive further address space from the RIPE NCC directly. As of today’s current policy, this means the receiving LIRs will have to have an eighty percent (80%) usage within all the address space that they already hold before they can receive a re-allocation. If the further allocation criteria changes in the future, same change will apply for transfers.

Arguments Opposing the Proposal

  • None

Additional Information:

Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy may have if the proposal is accepted and implemented.

A. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact on address/Internet resource consumption if this proposal is implemented.

Fragmentation/Aggregation:

When this calculation was made, the RIPE NCC had made approximately 11,100 IPv4 allocations. Today, the minimum allocation size is a /21, and according to the proposal this would be the minimum size possible for a block being transferred. If each of the 11,100 allocations were split into /21s to be transferred, there would eventually be 193,000 allocations (about 17 times more than there currently are). This could have an impact on fragmentation and, therefore, on the routing system, assuming these transferable blocks are announced specifically.

So far, the different blocks that the RIPE NCC had allocated space from had different maximum prefix sizes, depending on the minimum allocation size the policy set at various times. These varying longest prefix sizes per /8 can be seen in the document “Address Space Managed by the RIPE NCC”: http://www.ripe.net/ripe/docs/ripe-415.html. Once this proposal is implemented, the longest prefix size for all blocks will need to be set to one size, a /21, which is the current minimum allocation size that the RIPE policy allows.

B. Impact of Policy on RIPE NCC Operations/Services

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

This policy proposal allows LIRs to move around allocations without prior approval by RIPE NCC. This is a big departure from currently set policy. It also leans heavily on the quality of (execution of) current allocation policy to prevent potential abuse or an increased speed of depletion.