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