Rectifying the size of initial allocations

Original Language Español Date Published 02/02/2017 Last Modified 26/01/2017
Last Call for Comments Period 23/05/2017 - 07/07/2017 Date Ratified Does not apply Implementation Date 16/08/2017
Status Implemented Download TXT PDF XML DOCX
See other versions 1.0 2.0 (compare)

Authors

Name: Jordi Palet Martinez
Email: jordi.palet@consulintel.es
Organization: Consulintel

General opinion

Proposal Data

Policy Type: LACNIC
Id: LAC-2017-1
Last version: 2
Presented at: LACNIC 27 Presentations:

Summary

Historically, the process for requesting the default initial IPv6 assignment (/32 block) was very easy and, because many people were used thinking "the IPv4 way," they believed this would be large enough for their networks.

For this reason, many ISPs don't prepare a proper addressing plan before requesting the proper prefix for the long-term deployment of their IPv6 network.

As a result, there are many cases —and quite possibly the number of such cases will increase in the coming months— where, as a result of the policy currently in force, the ISP will be forced to return the prefix initially they originally received to LACNIC, submit a new initial request, and renumber their existing deployment.

This is typically the case in the early stages of IPv6 deployment, when a serious, long-term addressing plan is prepared, even though there might have been an initial deployment of IPv6 in part of the network, such as the core, pilot projects, initial testing, etc. However, this situation can also present itself in more advanced stages of deployment, where obviously the idea is to complete the deployment without restrictions, renumbering, or serious changes to the addressing plan.

This could also be the case where the initial allocation occurred many years ago, at the time when it was free and easy to simply "request" an IPv6 prefix, without any study of the deployment and addressing plan. Several years may have gone by and the size of the network may have changed substantially, technical knowledge on how to use IPv6 has evolved, there are new technologies based on IPv6 (IoT, Smart Cities, ...), etc.

Rationale

This proposal seeks to avoid unnecessary work for both parties: the ISP, who would be forced to renumber, and LACNIC staff, who in any case would have to evaluate the new request and also provide a new prefix.

This is leading to a situation where, instead of preparing a proper numbering plan, an ISP may wish to avoid it by adjusting the size of the prefix it provides to its customers, which undoubtedly affects the proper deployment of IPv6 in the medium to long term.

The current procedure is based on section 4.5.2.4 of the Policy Manual.

This proposal therefore seeks to eliminate section 4.5.2.4, and, instead, simplify the process, eliminating the need for renumbering, except in those (probably infrequent) cases where inter-assignment space does not allow assigning the new requested size with the same prefix.

Text

Eliminate Section 4.5.2.4.

New text:

4.5.1.4. Rectifying the size of initial allocations
During IPv6 deployment, if an organization finds that the size of the initial allocation it requested no longer satisfies its needs, the organization may submit a new addressing plan to LACNIC, without having to wait until it can fulfill the requirements for a subsequent allocation, and therefore the organization will not have to prove utilization thresholds, but, instead the desire to apply a different addressing plan that is better suited to the reality of the deployment.

The new size will be adjusted according to the new addressing plan as specified in section 4.5.1.3., and will thus qualify for extending the current prefix the necessary number of bits.

If it were not possible to provide this prefix length because the adjacent space is already being used by another organization, or if making the allocation would not leave sufficient space for subsequent allocations, LACNIC shall inform the applicant, who may choose to:
a) receive a new prefix with the new requested size and renumber their network and return "original" initial allocation to LACNIC within 6 months, or
b) receive a complementary prefix to complete their addressing plan, and announce both the "original" initial prefix and the new prefix resulting from the new allocation. For all effects and purposes, in the case of subsequent allocations, both allocations shall be considered as if they were a single allocation.

Each organization may only use this procedure once, so for this "second opportunity" they should carefully study the final medium and long term network addressing plan.

Additional Information

-

Timetable

Immediate implementation

References

-

Public Comments by LACNIC Staff

LACNIC STAFF´S IMPACT ANALYSIS - Proposal LAC-2017-1 - version 2

LACNIC Staff's Interpretation of the Proposal
---------------------------------------------
Applying Section 4.5.2.4.
-------------------------
This section will apply when an organization has received an initial IPv6 allocation and then, once it starts to use these addresses and prepares its addressing plan, they realize they need a larger block than the one they were initially assigned. In this case they request a larger block from LACNIC.

Modification to the current text and staff comments
--------------------------------------------------
According to the changes in proposal 2017-1, the following changes would be introduced to the Policy Manual:

• Section “4.5.2.4. Returning the First Allocation for the Second Allocation” would be eliminated.
• Section: “4.5.2.4. LIR-to-ISP Allocation” would be renumbered.
• Section “4.5.1.4: Rectifying the size of initial allocations” would be added under Section "4.5.1. Initial Allocation."

Staff comments: In order to manage resources in an orderly manner, LACNIC already applies the process described in this proposal. This process is not documented in the Policy Manual, so documenting it would be advisable.

Implementation of the Proposal
-------------------------------
The proposal can be implemented immediately.

Impact of the policy on the registry system and address pool
-------------------------------------------------------------
This proposal does not involve any modifications to the registry system.