Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis

This policy proposal has been accepted

The new RIPE Document is: ripe-589

2012-10

State:: Accepted

Publication date

17 Dec 2012

Affects

ripe-552

Draft document

IPv6 Address Allocation and Assignment Policy

Authors

Jan Zorz [Go6 Institute]
Mark Townsley [Cisco]
Jordi Palet [Consulintel]

Proposal Version

1.0 - 17 Dec 2012

All Versions

Accepted

14 May 2013

Working Group

Address Policy Working Group

Proposal type

Modify

Policy term

Indefinite

New RIPE Document

ripe-589

Summary of Proposal

Recently, a proposal was accepted that allowed a /32 allocation to be extended to /29 with very little overhead. The initial intent of the proposal, at least from the perspective of its authors, was that this new policy would apply for all /32 allocations.

However, a strict reading of the policy limits extensions to one per LIR, even if that means splitting the extension across multiple past allocations. This creates a variety of complications; for example, an organization with three networks, each with its own /32, would have to extend one /32 to /30 and two /32s to /31. Extending one network from /32 to /29 and leaving the others as they were is not even an option.

With this proposal, we are aim to clarify the recently approved text to ensure that any /32 may be extended to /29, without having to restrict to one extension on a per-LIR-total-summary basis. Detailed arguments are given in the “Arguments supporting the proposal” section.

Policy Text

a. Current policy text

5.7. Existing IPv6 address space holders

LIRs that hold one or more IPv6 allocations are able to request extension of these allocations up to a total of a /29 without providing further documentation.

b. New policy text

5.7. Existing IPv6 address space holders

LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without providing further documentation.

Rationale

a. Arguments supporting the proposal

Extension of initial IPv6 allocation to /29 was accepted for various different reasons, one being that RIPE-NCC had reserved the /29 space for every initial /32 allocation in case the resource holder could expand their allocation in the future if needed. That IPv6 space will probably never be used by anyone else, so the community decided to let the resource holders use that IPv6 space if they want it to.

Intent: It was the intent of the authors of the original proposal that the amended policy be based on each /32 that had been granted in the past within the /29 reserved space, not a total of /29 per LIR, despite the text that was agreed on. This was, frankly, an oversight on our part.

Circumventing the process: If an LIR would expand all /32s before merging multiple LIRs together, the LIR would have multiple /29s. An LIR presumably could separate into multiple LIRs, expand their space, and merge back together.

Additional complexity: limitations, such as that given in the Proposal Summary where an organization with three networks, each with its own /32, could extend one to /29, or one to /30 and two to /31, seem odd and lead to even more variance in the size of prefix allocations.

Finally, many LIRs expressed their support for extending to /29, not just because it had already been reserved in the past, but for ease of address planning and deployment.

b. Arguments opposing the proposal

Currently none.

Impact Analysis

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

The RIPE NCC understands this policy proposal as follows:

Currently, the RIPE NCC can extend existing IPv6 allocations to no more than a /29 in total without additional documentation, per LIR, regardless of the number of allocation the LIR holds.

Under this proposed policy, each IPv6 allocation that an LIR holds can be extended to a /29 without additional documentation.

Apart from allowing LIRs to request an extension to more than one allocation, Registration Services sees no need to change its procedures.