Synchronising the Initial and Subsequent IPv6 Allocation Policies

Summary of Proposal:

This policy proposal aims to match the subsequent IPv6 allocation requirements with the initial allocation requirements, which were modified in October 2015 (RIPE-655).

This synchronisation with the initial IPv6 allocation policy is needed because the policy proposal 2015-03 introduced new criteria for evaluation, including hierarchical and geographical structuring, segmentation for security, and planned longevity of the allocation.

However, organisations that have already received an initial allocation and started their deployment are not able to apply for more IPv6 address space using the new criteria. Their only choice is to return their current address space, which forces them to renumber their network. Otherwise they can justify additional addressing space based on the actual utilisation calculated with the HD-ratio, which in turn means they need to be using a large part of the initial allocation, about 30% depending on the size of the allocation. This disadvantages LIRs that have already received an initial IPv6 allocation against newcomers.

This discriminatory situation may contribute to a delay in IPv6 deployment, especially in big organisations.

The current policy text is attached to a standard notion that End Sites should be assigned a /56 IPv6 block each, but in reality, different ISPs and different services within the same ISP may provide different assignment sizes, such as a /48. So, this need must also be considered for subsequent allocations.

In the current policy, requests for subsequent allocations of address space are justified on the basis of forecasts over a strict two year period, without making any reference to other allocation criteria. However, the initial allocation policy text allowed networks to rely on the justification of other needs and not only on the total number of users. So networks are now able to reference the extent of their infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security, and the planned longevity of the allocation. It makes sense to synchronise the subsequent allocation criteria with this as well.

Policy Text:

a. Current Policy text:

5.2. Subsequent allocation

Organisations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [RFC 3194] is used to determine the utilisation thresholds that justify the allocation of additional address as described below.

[...]

5.2.3. Subsequent allocation size

When an organisation has achieved an acceptable utilisation for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.

If an organisation needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.

New Policy text:

5.2. Subsequent allocation

Organisations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.

5.2.1. Subsequent allocation criteria

Subsequent allocation will be provided when an organisation (i.e. ISP/LIR):

1. Satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56. To this end, the HD-Ratio [RFC 3194] is used to determine the utilisation thresholds.
   
   or
   
   
2. Can justify new needs (which can't be satisfied within the previous allocation), according to the initial allocation size criteria as described in section 5.1.2.

[...]

5.2.3. Subsequent allocation size

When an organisation meets the subsequent allocation criteria, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.

If an organisation needs more address space, it must provide documentation justifying its requirements for the planned longevity of the allocation. The allocation will be based on this relevant documentation.

Rationale:

The same considerations that were discussed when the initial IPv6 allocation policy was proposed (2015-03) and successfully amended can be considered here. For further details, please refer to https://www.ripe.net/participate/policies/proposals/2015-03.

a. Arguments Supporting the Proposal

The text on ripe-655 (5.1.2) implies that it will be easier for a new LIR to justify an allocation larger than a /29 compared to an LIR that has already received a first IPv6 allocation.

This proposal will benefit LIRs with particular dynamics in terms of grouping both their user base and infrastructure. Having more bits to keep for future changes to their IPv6 addressing plan should be a clear benefit.

IPv6 address conservation should not be an issue. If abuse occurs, the policy can be further amended by a new policy proposal that will probably also include amendments to the initial allocation criteria.

Furthermore, a few years ago Tony Hain did some calculations around the expected lifetime of IPv6. Even if we allocate a /48 for every possible human on planet Earth, this is close to 480 years. This means that we don’t have a risk of exhaustion as with IPv4. The authors believe that the next big Internet problem will not be associated with the lack of addresses, but instead will be related to other technological challenges.

In terms of management, having all the infrastructure under the same addressing hierarchy on the same IPv6 prefix will facilitate building «allow filters».

Regarding the global routing table, having a bigger prefix should avoid using more routing slots. However, this ultimately depends on how the prefix is used by each organisation.

With this policy proposal, the authors also wish to avoid cases where /58s, /60s or smaller IPv6 address blocks are distributed to lower hierarchical organisations (within extensive vertical organisations) due to the constraints that a /29 could represent. The authors believe that End Sites must be able to subnet, even residential ones, which implies a /48 prefix assignment.

b. Arguments Opposing the Proposal

It can be argued that an alternative to the HD-ratio (hierarchy requirements, etc…) could consume the RIPE NCC’s IPv6 pool faster.
Mitigation/counter-argument: If this becomes an issue, the first allocation policy will be falling into the same issue and so far the RIPE NCC has not identified this as a risk after the last policy change.

RIPE NCC IP Resource Analysts will need to spend additional effort to understand requests and the details supplied.
Mitigation/counter-argument: This will not be any different to the current process with initial allocations.

Some security related concerns may arise, especially if large infrastructures stay exclusively under a single prefix (easily filtered out from third party networks, i.e. «deny filters»).
Mitigation/counter-argument: On the other hand, more aggregation can also favour the build-up of «allow filters».

The current different rules regarding a first allocation and a subsequent allocation can be circumvented by either creating a new LIR, or returning an initial allocation made under the old criteria to the RIPE NCC (which could imply a costly renumbering process).
Mitigation/counter-argument: The path described above will be time consuming – synchronising the criteria is much simpler.

There could be global IPv6 routing table concerns if bigger prefixes are split into smaller ones.
Mitigation/counter-argument: This could also happen with initial IPv6 allocations. In the end it depends on the policy of the organisation using the prefix. There is also no guarantee that this won’t happen if the prefix is smaller – smaller prefixes may be split into even smaller blocks, which may be worse. The minimum acceptable routing advertisement size is not touched in any way by this policy proposal.

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

A. RIPE NCC's Understanding of the Proposed Policy

If this proposal is accepted, it is the RIPE NCC’s understanding that the current criteria to qualify for a subsequent IPv6 allocation (past address utilisation) will be extended to include the same criteria that apply to initial IPv6 allocation requests. These new criteria are:

• Number of users
• Extent of the organisation's infrastructure
• Hierarchical and geographical structuring of the organisation
• Segmentation of infrastructure for security
• Planned longevity of the allocation

It is the RIPE NCCs understanding that where IPv6 has been already assigned or sub-allocated in the existing allocation, it must always be documented in the RIPE Database before a subsequent allocation can be requested. This is important to ensure the goal of registration. If this documented utilisation threshold is not sufficient to qualify for a subsequent allocation, the LIR can present new needs to the RIPE NCC in accordance with the new criteria introduced by this policy proposal.

If an LIR is requesting a subsequent IPv6 allocation based on these criteria, it must provide sufficient documentation to justify the new need for additional address space. This new need can be an addition to the original addressing plan or a completely new service or network.

Along with documentation for the new need, the LIR will also be required to provide details about the latest deployment status in their initial IPv6 allocation and potential changes to the original addressing plan on which the initial allocation was based. This is necessary to establish that the new need cannot be satisfied with the existing IPv6 allocation.

When evaluating the new need, the RIPE NCC will apply the same standards as for initial IPv6 allocation requests, especially in regards to the understanding of "reasonable" for the different criteria. The details of this evaluation are outlined on our website.

When the RIPE NCC concludes that the new need cannot be satisfied with the existing allocation, the LIR will immediately qualify for a doubling of the address space allocated to it. If the LIR requires more address space, the provided documentation must contain reasonable justification that allows the RIPE NCC to calculate the correct allocation size.

Where possible, the RIPE NCC will provide a subsequent allocation from the adjacent address block to the initial allocation. This is mandated by policy to ensure the goal of aggregation.

If the justified subsequent allocation size exceeds the size of the adjacent block, the RIPE NCC will first allocate the available adjacent address space and provide a separate address range for the remaining part of the justified size.

B. Impact of Policy on Registry and Addressing System

Under the current policy, no LIR has qualified yet for a subsequent IPv6 allocation bigger than /29 based on past utilisation. If this proposal is accepted, LIRs will have new options to qualify for a subsequent allocation. It is likely that this will increase the amount of successful requests.

While it is difficult to make a precise projection, based on present usage patterns, the RIPE NCC does not foresee any serious impact on IPv6 consumption as the amount of subsequent allocation requests is expected to be low.

C. Impact of Policy on RIPE NCC Operations/Services

The evaluation of subsequent IPv6 allocation requests under the new criteria will require considerably more work than an evaluation of the past utilisation.
Still, the overall change in the workload will be minor, as the RIPE NCC’s Registration Services Department has gained valuable experiences during the evaluation of initial IPv6 allocation requests under the same criteria. Also, the overall amount of such requests is estimated to be low, as requests from LIRs will mainly be from those that have received their initial allocation before the implementation of 2015-03 or discovered new needs after receiving their initial IPv6 allocation.

As for large initial IPv6 requests, Registration Services has a team of experienced IP Resource Analysts (IPRAs) who evaluate such requests together. This ensures that requests are evaluated consistently and to a high quality.

D. Implementation

With the information currently available, it is expected that implementation of the proposal would have a low impact in terms of the software development needed to facilitate the policy changes in internal RIPE NCC systems. Internal and external processes and documentation would need to be updated.