Summary of Proposal

Based on feedback about on the first version of this policy proposal, I’m removing most of the restrictions that the original version set out to implement have been removed. 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 address 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
• Change the “status” field Changes the “status”field in the RIPE Database to reflect the transferability of an INETNUM

Based on feedback on the second version, some clarifications and corrections were made in the proposed policy text.

Policy Text

[The following text will update sections 5.1, 5.3, 5.5 and 7.0 in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Link: /publications/docs/ripe-649/ ” if the proposal reaches consensus.]

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 Link: /membership/member-support/become-a-member/ " Proced Link: /membership/member-support/become-a-member/ ure for Becoming a Member of the RIPE NCC" Link: /membership/member-support/become-a-member/

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. In case 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 made to fulfill a 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 1,024 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 based on the IPv4 allocation policy after the 14th of after 14 September 2012 will be marked in the RIPE Database as “ALLOCATED FINAL”.

(…)

5.3 Address Recycling

Any address space that is If not covered by other policies or marked to be returned to IANA, 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. This includes address space that is:

• Returned to the RIPE NCC,
• Allocated to the RIPE NCC from the IANA recovered pool as defined in the RIPE Policy “Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA”
• Given to the RIPE NCC by legacy holders

(…)

5.5 Transfers of Allocations

1. 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
System.
2. Address space may only be re-allocated to another resource holder who is a member of an RIR that allows
3. transfersAllocations with the status
transfers.Allocations with a status of "ALLOCATED FINAL" cannot be transferred
4. Point 3 of this article does not apply to any change of holdership of address space as a result of company mergers or acquisitions

(…)

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 not transferable to another LIR.

(…)

Rationale

a. Arguments supporting the proposal

This proposal has the aim sets out to reinforce the intended aim of the currently accepted 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 easy to recognize and unattractive for speculation. It also ensures that any allocations that fall into disuse will eventually be returned to the RIPE NCC for reallocation. It also sets no additional limitations to transfers as a result of M&A activity.

b. Arguments opposing the proposal

This The proposal adds some overhead to the management of final /8 allocations, both on the RIPE NCC and the LIR 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.

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 proposal might have if it is accepted and implemented.

A. RIPE NCC's Understanding of the Proposed Policy

This policy proposal introduces the new status “ALLOCATED FINAL” for IPv4 allocations in the RIPE Database. Despite the title of the proposal making reference to the final /8 (a common term for the IPv4 range 185.0.0.0/8) it is the RIPE NCC’s understanding that this status will be applied to any allocation made from RIPE NCC’s available IPv4 pool after 14 September 2012.

The proposed policy text defines further special transfer conditions for this type of allocation. It also clarifies what IPv4 address space should be added to the RIPE NCC’s IPv4 pool and how the final IPv4 allocation should be used by LIRs. The following sections will analyse these changes in more detail.

Transfer Restrictions for IPv4 Ranges with “ALLOCATED FINAL” 

Allocations with the status “ALLOCATED FINAL” cannot be transferred under the transfer policy to another LIR on either a permanent or temporary basis. This includes transfers between different LIR accounts held by the same organisation. If an LIR no longer needs an allocation with this status, it can return the range to the RIPE NCC. Alternatively, the LIR could consider providing assignments or sub-allocations from this range to other organisations. When an LIR account is closed, allocations with the status “ALLOCATED FINAL” must be returned to the RIPE NCC.

The proposed policy clarifies further that transfers related to changes in the structure of organisations (e.g., mergers, acquisitions) will not be restricted. It is the RIPE NCC’s current procedure that such changes of holdership must be supported by legal documents issued by a national authority proving that a merger or acquisition has taken place according to section 3.1 of the RIPE NCC procedural document “Transfer of Internet Number Resources and Change of a Member’s Official Legal Name Link: /publications/docs/ripe-667/ ”.

From the moment this proposed policy reaches consensus, the RIPE NCC will not longer process new transfer requests for allocations made after the 14 September 2012. Transfers that have already been finalised by the RIPE NCC will not be impacted by this policy change. Any transfer requests submitted before the proposal reaches consensus (and that have complete, valid documentation) will continue to be processed.

It is possible that some LIRs would end up holding multiple ranges with the status “ALLOCATED FINAL” after the policy was implemented. This would be due to transfers that were already completed before the policy came into effect, and also due to mergers and acquisitions.

N.B. This proposal suggests changes to section 5.5, “Transfers of Allocations” in the IPv4 policies. The RIPE community is currently discussing another policy proposal, 2015-04, “RIPE Resource Transfer Polices Link: /community/policies/proposals/2015-04/ ”, that would replace this section with a reference to a new transfer policy document. If 2015-04 reaches consensus first, the suggested changes to section 5.5 in 2016-03 must be reviewed and would likely need to be adjusted. This would result in another Review Phase.

Usage of the Final Allocation

The proposed policy says:
“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.”

The RIPE NCC understands this as a suggestion for using this address block cautiously, in the light of the fact that (especially for new LIRs) this might be their only IPv4 range that allows their IPv6 network to communicate with the IPv4-only networks of other operators.

The use of the term “should” indicates that this is a recommendation and not a mandatory policy requirement. LIRs can use this final allocation according to their own requirements.

Address Space Returned to the RIPE NCC

The proposal states that all IPv4 address space that the RIPE NCC receives will be added to the available pool, unless it is covered by other policies or marked to be returned to IANA. Currently there is no address space that is marked to be returned to IANA.

IXP IPv4 assignments are the only resource type that currently has a special return policy defined. Section 6.1 of “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Link: /publications/docs/ripe-649/ ” states that “IP space returned by IXPs will be added to the reserved pool maintained for IXP use.” Accordingly, any such returned IXP assignments are not added to the RIPE NCC’s general available IPv4 pool.

Returned IPv4 addresses from LIRs and End Users and addresses received from IANA’s recovered pool are currently added to the RIPE NCC’s available IPv4 pool. If this proposal is accepted, legacy resources that have been handed over to the RIPE NCC will also be added to the available pool. Currently, the RIPE NCC holds a total of ten /24 IPv4 legacy resources.

B. Impact of Policy on Registry and Addressing System

If the proposal is accepted, final IPv4 /22 allocations received by LIRs from the RIPE NCC will not be able to be transferred to other LIRs under the RIPE transfer policy. This may impact the consumption rate of IPv4 addresses in RIPE NCC's available pool in two ways:

• Organisations that acquire final /22 allocations for the purpose of transferring them to another legal entity will see this road blocked. The only alternative remaining will be to assign rather than transfer the address space. This might be a less attractive option for both the party that holds the allocation and the party that uses the allocated addresses.
• Organisations that open additional LIR accounts to obtain extra /22 allocations will see the costs of holding on to this address space go up. If these allocations can’t be transferred to the primary account, the additional LIR accounts will have to be kept open, incurring yearly membership fees. This may discourage organisations from using the multiple-LIR route to acquire more IPv4 addresses.

However, in all cases only a small impact is expected. The policy proposal 2015-01, “Alignment of Transfer Requirements for IPv4 Allocations Link: /community/policies/proposals/2015-01/ ”, which was accepted and implemented in July 2015, established a 24-month holding period before a new final /22 allocation can be transferred to another LIR. This has already reduced the rate of /22 transfers. From August 2015 to September 2016, the RIPE NCC recorded 70 transfers from the last /8, down from 342 in the 13 months before. To put these numbers into perspective, the RIPE NCC made 3,500 final /22 allocations in that same time period, from August 2015 to September 2016.

C. Impact of Policy on RIPE NCC Operations/Services

Once this policy change is implemented, the RIPE NCC expects extra efforts will be needed to educate LIRs that they can provide assignments and sub-allocations from their allocations if they no longer need them. This effort will aim to avoid a drop in registration quality as LIRs (particularly new LIRs) might not be aware of this option and instead could provide the address space to other organisations without updating the RIPE Database accordingly.

D. Implementation

With the information currently available, it is expected that implementation of the proposal would have a medium impact in terms of the software development needed to facilitate the policy changes in the RIPE Database and external and internal RIPE NCC systems.

Regarding the suggested changes in the RIPE Database, the RIPE NCC believes it is unlikely that scripts and tools used by network operators will be affected by this change, but cannot exclude this possibility as these tools are not maintained by the RIPE NCC. The RIPE NCC would first deploy this change to the Release Candidate (RC) environment and recommend that all users test that their code can handle the new “ALLOCATED FINAL” status.

Internal and external processes and documentation would also need to be updated.