RIPE Policy Proposal 2007-08

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.

New Text

[Following text is to appear in the RIPE Policy document, IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region if the proposal reaches consensus. Please review this change that the proposal is bringing within the drafted policy document from the link above in “Draft RIPE Document”]

Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA. Such address space must not contain any block that is assigned to an End User.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC, following the policies set for receiving further allocations within RIPE region (see the Section 5.3 Additional Allocations of this document).

Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.

LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.

The RIPE NCC will record the change of allocation after the transfer. Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC until the transfer of address space to another LIR is completed or the address space is returned. The LIR must ensure that all policies are applied.

Re-allocated blocks will be signed to establish the current allocation owner.

Re-allocated blocks are no different from the allocations made directly by the RIPE NCC and so they must be used by the receiving LIR according to the policies described in this document.

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