Allow IPv6 Transfers

Summary of Proposal

According to the RIPE Document, “IPv6 Address Allocation and Assignment Policy”, it is not possible to transfer IPv6 address space.

Currently if a company would like to consolidate LIRs, they have to return their IPv6 allocation, as they can’t transfer it. If this IPv6 space is already deployed, this results in renumbering and a delay in IPv6 implementation.

It is unlikely that there will be a very active market in transfers of IPv6 space in the near future, as it is very easy to obtain IPv6 and there is lots of space available via the RIRs. The result would be that the majority of the transfers would be a consolidation of LIRs/companies and not actual transfers outside the company.

An adjustment was made to section 7.1, which describes the current mandatory return of IPv6 PI assignments for LIRs when the original assignment criteria are no longer valid. By using the term “should” according to RFC 2119 this requirement is kept, but it can be ignored for valid reasons such as an upcoming transfer.

The goal of this policy proposal is to allow the transfer of IPv6 allocations and IPv6 PI assignments. This will bring IPv6 space on-par with IPv4 space in terms of the ability to be able to transfer it.

Policy Text

[The following text will update section 7.1 and will create a new section 8.0 in the RIPE Policy Document “IPv6 Address Allocation and Assignment Policy“, if the proposal reaches consensus.]

a. Current policy text

7.1 IPv6 Provider Independent (PI) Assignments for LIRs

LIRs can qualify for an IPv6 PI Assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.

The LIR must return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid.

If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both.

b. New policy text

7.1 IPv6 Provider Independent (PI) Assignments for LIRs

LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.

The LIR should return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid.

If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both.

8.0 Transfer of IPv6 resources

Any holder of IPv6 address space is allowed to transfer complete or partial blocks of IPv6 address space that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry system.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation size at the time of re-allocation.

Provider Independent (PI) address space may only be re-assigned in accordance with the RIPE Document, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The block that is to be re-assigned must not be smaller than the minimum assignment block size at the time of re-assignment.

Transfers must be reflected in the RIPE Database. This transfer may be on either a permanent or non-permanent basis.

The RIPE NCC will record the change of address space after the transfer.

The RIPE NCC will publish a list of all allocations and assignments transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses.

The list will contain information about approved and non-approved transfers.

The following information will be published for approved transfers:

• The name of the transferring party
• The block originally held by the transferring party
• The name(s) of the receiving party or parties
• Each subdivided prefix (each partial block derived from that original block) transferred
• The date each prefix was transferred

Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published:

• The number of requested transfers not approved after the RIPE NCC’s evaluation
• The sum of the number of addresses included in the requested transfers

Neither the blocks nor the organisations involved will be identified in these statistics.

The transferring party always remains responsible for the entire address block it receives from the RIPE NCC until the transfer of address space to another party is completed or the address space is returned. The transferring party must ensure that all policies are applied.

Transferred address blocks are no different from the allocations or assignments made directly by the RIPE NCC and so they must be used by the receiving party according to the policies described in this document.

Rationale

a. Arguments supporting the proposal

• The goal of this policy change is to get IPv6 space on-par with IPv4 space in respect to the ability to transfer it
• Organisations can keep all IPv6 address ranges when consolidating LIRs
• By forcing people to hand their already deployed IPv6 back to the RIPE NCC, it will force companies to either re-do their IPv6 implementation or lie to the RIPE NCC in order to make it look like a merger or acquisition, while it is a consolidation between (sister or related) companies

b. Arguments opposing the proposal

• The policy might open de-aggregation of standard IPv6 blocks like a /29 into multiple /32s

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 as an indication only.

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCCs understanding that this proposal would allow the transfer of IPv6 allocations and IPv6 Provider Independent (PI) assignments (or parts of them) from the rightfully registered resource holder to a new resource holder.

IPv6 allocated space can only be reallocated to an LIR that is also a member of the RIPE NCC and will be subject to current RIPE policies. The block that is to be reallocated must not be smaller than the minimum allocation size at the time of reallocation.

IPv6 PI address space can only be reassigned if both parties fulfil the contractual requirements for independent resources. The receiving party will be subject to current RIPE policies. The block that is to be reassigned must not be smaller than the minimum assignment block size at the time of reassignment.

All IPv6 transfers can be on either a permanent or non-permanent basis.

The RIPE NCC would publish a list of all allocations and PI assignments transferred under the policy. Non-approved transfers would be published only in aggregate statistics.

It is the RIPE NCC’s understanding that transferred address blocks are no different from allocations or assignments made directly by the RIPE NCC, and so must be used by the receiving party according to the RIPE Document, “IPv6 Address Allocation and Assignment Policy”.

B. Impact of Policy on Registry and Addressing System

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

Fragmentation/Aggregation:

This proposed policy would allow larger allocations or assignments to be split until the minimum allocation or assignment size is reached. The RIPE NCC has no historical data to estimate the likely amount of deaggregation.

C. Impact of Policy on RIPE NCC Operations/Services

Registration Services:

There are more than 8,300 IPv6 allocations and 1,900 IPv6 PI assignments eligible for transfer in the RIPE NCC service region. However, as organisations can request IPv6 address space direct from the RIPE NCC, the actual amount of transfer requests is expected to be low.

The RIPE NCC will evaluate the transfer request and will update the RIPE Registry with the new allocation or assignment details if it is approved.

Software Engineering:

Software development will be needed to facilitate the processes of IPv6 allocation and IPv6 PI transfers. Given the information that is currently available, a medium impact is expected, with around three months needed to develop the necessary software tools.

Billing/Finance Department:

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

RIPE Database:

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

D. Legal Impact of Policy

If this proposal is implemented, a number of legal documents will need to be updated, including:

• The procedural document “Transfer of Internet Number Resources and Name Changes”
• The transfer agreement template
• The procedural document “Contractual Relationship Changes Between End Users and Sponsoring LIRs”, where any possible implications will be explained
• Template agreement for assignments between End Users and LIRs

Existing contracts between End Users and sponsoring LIRs state that End Users may not transfer their assignments. However, the contracts also state that the use of resources is subject to RIPE Policies, which may be amended from time to time. Therefore, if this proposal is accepted, it will be possible to transfer PI assignments under existing contracts without any changes being required.

E. 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 IPv6 transfers in internal RIPE NCC systems. New processes and documentation would also need to be created. Experience gained from the existing transfer processes for IPv4 PA and IPv4 PI will be used to optimise the implementation process.