Based on feedback about the first version of this policy proposal, most of the restrictions that the original version set out to implement have been removed. 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 space for non-addressing purposes. The updated policy proposal now does the following:
Based on feedback on the second version, some clarifications and corrections were made in the proposed 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” 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:
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.
(…)
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.
(…)
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.
(…)
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:
All allocations made by the RIPE NCC to LIRs based on the IPv4 allocation policy after the 14th of September 2012 will be marked in the RIPE Database as “ALLOCATED FINAL”.
(…)
Any address space that is not covered by other policies or marked to be returned to IANA, will be covered by the rules in section 5.1. This includes address space that is:
(…)
(…)
(…)
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.
(…)
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 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.
This proposal adds some overhead to the management of final /8 allocations, both on the RIPE NCC and the LIR 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.
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.
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”.
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”, 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.
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.
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” 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.
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:
However, in all cases only a small impact is expected. The policy proposal 2015-01, “Alignment of Transfer Requirements for IPv4 Allocations”, 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.
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.
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.