Locking Down the Final /8 Policy

Summary of Proposal

Based on feedback on the first version of this policy proposal, I’m removing most of the restrictions that the original version set out to implement. The obvious loopholes that are now being exploited to get around the policy should still be reduced as this proposal makes it unattractive to collect final /8 space for non-addressing purposes. The updated policy proposal now does the following:

• Explicitly states 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
• Adds a consideration to the IPv4 allocation policy that the LIR should conserve whole or part of their final /22 allocation for interoperability purposes
• Bans transfers of final /22 allocations
• Changes the “status”field in the RIPE Database to reflect the transferability of an INETNUM

Policy Text

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.

In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

(…)

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

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. If an allocation of a single /22 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be used to fulfil the request.
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. The LIR must be aware that this is the last IPv4 allocation it will receive from the RIPE NCC, and should reserve at least part of this allocation for interoperability with networks that are only reachable using IPv4.

All allocations made by the RIPE NCC to LIRs after 14 September 2012 will be marked in the RIPE Database as “ALLOCATED FINAL”.

(…)

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 rules in section 5.1.

(…)

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 or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider. This allocation is non-transferable.

Rationale

a. Arguments supporting the proposal

This proposal sets out to reinforce the intended aim of the current 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 rules do not apply. This makes these allocations unattractive for speculation. It also ensures that any allocations that fall into disuse will eventually be returned to the RIPE NCC for reallocation.

b. Arguments opposing the proposal

The proposal adds some overhead to the management of final /8 allocations, both on the RIPE NCC’s and the LIR’s side, and does not benefit any current LIR. This amended proposal should still make it more complicated to find creative interpretations of the IPv4 allocation policy, but will not cover all potential interpretations or address all current loopholes.