You're looking at an older version: 1
The current (published) version is 3Based on the ongoing discussions about both the expansion of the final /8 policy as well as some of the obvious loopholes that are now being exploited to get around the policy, I'd like to introduce a policy proposal that does the following:
In short, every LIR is welcome to have one /22. If you end up having more, however you got them, you're supposed to return all but one.
[The following text will update sections 5.1, 5.3, 5.4, 5.5 and 7.0 in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” and section 3.0 in RIPE Policy Document “Policy For Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region”, if the proposal reaches consensus.]
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:
(…)
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.
(…)
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.
(…)
Any resource holder is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System.
Address space may only be re-allocated to another resource holder who is a member of an RIR that allows transfers.
(…)
(…)
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 PI: This address space has been allocated to an LIR or RIR and all assignments made from it are portable. Assignments can be kept as long as the criteria for the original assignment are met. Sub-allocations cannot be made from this type of address space.
(…)
(From RIPE-581, “Policy For Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region”)
The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC.
The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database.
Address space holders may delegate authority to another party.
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:
(…)
If not covered by other policies, any address space that is returned to the RIPE NCC, or allocated to the RIPE NCC from the IANA recovered pool as defined in RIPE policy “Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA” will be covered by the same rules as the address space intended in section 5.1.
(…)
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. Sub-allocations cannot be made from allocations with a status of "ALLOCATED FINAL". The meanings of the various "status:" attribute values are described in Section 7.0.
(…)
Any resource holder is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System.
Address space may only be re-allocated to another resource holder who is a member of an RIR that allows transfers. Allocations with a status of "ALLOCATED FINAL" cannot be transferred.
(…)
(…)
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 PI: This address space has been allocated to an LIR or RIR and all assignments made from it are portable. Assignments can be kept as long as the criteria for the original assignment are met. Sub-allocations cannot be made from this type of address space.
ALLOCATED FINAL: This address space has been allocated to an LIR and no assignments made from it are portable. Assignments cannot be kept when moving to another provider. This allocation is non-transferable and every LIR is only allowed to receive up to a /22 of allocated space of this type.
(…)
(For “Policy For Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region”)
The RIPE NCC provides reverse delegations for IPv4 and IPv6 address space that is registered by the RIPE NCC.
The RIPE NCC also provides systems to control reverse delegation of early registrations that have been transferred to the RIPE Database.
Address space holders may delegate authority to another party.
For "ALLOCATED FINAL" IPv4 address space, authority may not be delegated to another party, and the reverse delegation will be limited to a total of a /22 of IPv4 address space.
This proposal has the aim to reinforce the intended aim of the currently accepted final /8 policy, which is to be able to give new entrants a piece of IPv4 space for as long as possible. It does this by giving these final allocations a special status, marking them as a special case for which regular transfer, merger and acquisition rules do not apply. This makes these allocations unattractive for speculation and makes multiple of these allocations unpractical from an operational perspective. It also ensures that any allocations that fall into disuse will eventually be returned to the RIPE NCC for reallocation. Based on the limitations set out in the policy text, the (implicit) limitations for RPKI and route objects should follow automatically.
This proposal adds significant overhead to the management of final /8 allocations, both on the RIPE NCC and the LIR side, and does not benefit any current LIR. While this proposal should make it a lot more complicated to find creative interpretations of the IPv4 allocation policy, there are no guarantees it covers all potential interpretations.