Locking Down the Final /8 Policy

Summary of Proposal

Based 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:

• Explicitly state that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA
• Limit the number of  “final /22s” to one per LIR, regardless of how they were received
• Ban transfers of final /22 allocations
• Change the ‘status’ field in the RIPE Database to reflect the transferability of an INETNUM
• Limit reverse delegation of final /22s to a maximum of one /22 of address space per LIR
• Limit the number of final /22 INETNUM objects that can get RPKI validation to one per LIR
• Limit the number of ROUTE objects of final /22s to a maximum of one /22 of address space per LIR

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.

Policy Text

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

a. Current policy text

5.1 Allocations made by the RIPE NCC to LIRs

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:

1. The size of the allocation made will be exactly one /22.
2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
3. The LIR must confirm it will make assignment(s) from the allocation. 

(…)

5.3 Address Recycling

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.

(…)

5.4 Sub-allocations

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.

(…)

5.5 Transfers of Allocations

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.

(…)

7.0 Types of Address Space

(…)

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”)

3.0 Reverse Delegation 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.

b. New policy text

5.1 Allocations made by the RIPE NCC to LIRs

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:

1. The size of the allocation made will be exactly one /22.
2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
3. The LIR must confirm it will make assignment(s) from the allocation.
4. All allocations will be marked in the RIPE database as ‘ALLOCATED FINAL’
5. An allocation marked "ALLOCATED FINAL" is valid as long as it remains with the LIR it was allocated to. If an LIR, due to mergers, acquisitions or other means gains additional allocations marked "ALLOCATED FINAL", all but the equivalent of a single /22 will be de-registered by the RIPE NCC within 180 days.

(…)

5.3 Address Recycling

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.

(…)

5.4 Sub-allocations

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.

(…)

5.5 Transfers of Allocations

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.

(…)

7.0 Types of Address Space

(…)

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”)

3.0 Reverse Delegation 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.

Rationale

a. Arguments supporting the proposal

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.

b. Arguments opposing the proposal

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.