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
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.
Arguments Supporting the Proposal
Arguments Opposing the Proposal
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.