Relaxing IPv6 Requirement for Receiving Space from the Final /8

Summary of Proposal

In order to receive an allocation from the final /8, LIRs are currently required to have received an IPv6 allocation. LIRs that have an existing IPv6 PI assignment but no PA allocation do not meet this criterion. In order to qualify, they need to request an IPv6 allocation and subsequently return their existing PI assignment (per ripe-589 section 7.1). LIRs that have already received IPv6 space from a different RIR also do not qualify according to the current text.

This proposal aims to relax this requirement.

The new text proposes that organisations are eligible to receive an allocation from the final /8 if they have an inet6num object registered in the RIPE Database or any of the other RIR databases mirrored by the RIPE NCC.

Policy Text

[The following text will update sections 5.1 in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”, if the proposal reaches consensus.]

a. Current policy text

5.1 Allocations made by the RIPE NCC to LIRs

[...]

Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

b. New policy text

5.1 Allocations made by the RIPE NCC to LIRs

[...]

Allocations will only be made to LIRs if they have already received a valid globally routeable unicast IPv6 address block.

Rationale

a. Arguments supporting the proposal

  • The aim of the original criterion is to facilitate IPv6 deployment. In this respect an LIR that has received an IPv6 allocation from the RIPE NCC should not be treated differently than an LIR that has received an IPv6 allocation or assignment via a different route.
  • The further requirement that a prior IPv6 PI assignment should be returned upon receiving an IPv6 allocation is downright detrimental to IPv6 adoption. In many cases the prior PI assignment will already have authoritative DNS servers registered in numerous TLD registries, which makes renumbering a non-trivial exercise.

b. Arguments opposing the proposal

  • Relaxing the requirements for receiving IPv4 space may lead to a slightly faster run-out rate of IPv4. The authors do not expect this change to have a significant impact, because LIRs are still only entitled to a single /22 from the remaining address pool. The challenge of acquiring an IPv6 allocation from another LIR or the RIPE NCC is equal to the challenge of acquiring other IPv6 address space through the Regional Internet Registry system.


 

Impact Analysis:

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. The RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC's understanding that this proposal will permit a Local Internet Registry (LIR) to receive its /22 IPv4 Allocation from the RIPE NCC when it has received a block of IPv6 Global Unicast Addresses according to valid (regional) policy. This address block must be clearly registered to the RIPE NCC member in the RIPE Database or any RIR database mirrored by the RIPE NCC.

B. Impact of Policy on Registry and Addressing System Address

Internet Number Resource Consumption

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

Fragmentation/Aggregation

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

C. Impact of Policy on RIPE NCC Operations

Services Registration Services

If this proposed policy is accepted, RIPE NCC Registration Services expect no significant change in workload as we expect the majority of the LIRs will continue to request their first IPv6 allocation from the RIPE NCC in order to receive their IPv4 allocation from the last /8.

LIRs that have already received IPv6 address space and do not want to request their IPv6 allocation from the RIPE NCC need to provide the IPv6 range that they are currently using. Registration Services will then verify in the RIR databases if the range is correctly registered to the RIPE NCC member. If this is confirmed, the IPv4 allocation will be provided given that all requirements in section 5.1 are met. Delay and extra workload is only expected if the provided IPv6 range is not clearly registered to the requesting RIPE NCC member.

Billing/Finance Department

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented

RIPE Database

After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

D. Legal Impact of Policy

It is possible that a RIPE NCC member has multiple LIRs. Currently, the RIPE NCC allocates a /22 per LIR. Given that the intention of the proposal is to relax the IPv6 requirements, the RIPE NCC understands that it would be satisfactory for a RIPE NCC member to have received an IPv6 address block for any of its LIRs.

The IPv6 address space must be registered to the legal entity that has signed the RIPE NCC Standard Service Agreement, i.e. the RIPE NCC member. The criteria of this policy would not be met if the IPv6 address block is registered with another organisation that is affiliated with the RIPE NCC member (belonging to the same group of companies or being a subsidiary or holding company etc.).

E. Implementation

The RIPE NCC estimates that if this proposal is accepted the implementation would have a low impact.

Existing processes, supporting software and documentation would need to be updated to verify that the IPv6 requirement is fulfilled for receiving the IPv4 allocation from the RIPE NCC.