This policy proposal has been accepted
The new RIPE Document is: ripe-589

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

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.

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:

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.

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

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.