LACNIC Staff's Interpretation of the Proposal
---------------------------------------------
Applicability of Section 4.5.2.3:
--------------------------------
Section 4.5.2.3 would apply when an organization requests the allocation of an additional IPv6 block from LACNIC.
Modifications to the current text and comments by LACNIC staff:
----------------------------------------------------------------
According to policy proposal 2017-9, the Policy Manual would undergo changes in the sections listed below.
• Modification of section 4.5.2.3 “Modifying the size of a subsequent allocation”
When an organization has achieved an acceptable utilization of its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space it was previously allocated. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation will be extended one bit to the left.
If an organization requires more address space, the organization shall provide documentation justifying the space it needs to serve its clients, number of users, extent of its infrastructure, hierarchical and/or geographic structure, infrastructure segmentation for security or other reasons, and the longevity anticipated for the subsequent allocation.
LACNIC Staff Comments:
-------------------------
By modifying the current text, LACNIC understands that it would no longer be a requirement that the addressing plan for subsequent IPv6 allocations to an ISP must not exceed two years.
LACNIC understands that the allocation would be based on the new text:
“(...) the space it needs to serve its clients, number of users, extent of its infrastructure, hierarchical and/or geographic structure, infrastructure segmentation for security or other reasons, and the longevity anticipated for the subsequent allocation.”
Thus, LACNIC interprets that the applicant would be able to receive an additional IPv6 block with no limitation in terms of size or period of time. However, LACNIC also understands that the request would have to be justified by the addressing plan.
Implementation of the Proposal
-------------------------------
The proposal can be implemented immediately.
Impact of the policy on the registry system and the addressing pool
--------------------------------------------------------------------
This proposal does not require any modification to the registry system.
Policy proposal LAC-2016-7, which reached consensus and is pending ratification by the Board, modifies the justification requirements for LIRs/ISPs requesting an initial allocation larger than the default size (/32).
However, the current text for subsequent allocations is based on the text of the previous policy. This proposal allows “synchronizing” both parts of the policy.
Rationale (Describe the problem you intend to solve)By default, a subsequent allocation extends the existing allocation one bit, i.e., it doubles the already allocated address space.
The current policy also considers the possibility of justifying the need for a larger amount of address space, limiting this to a two-year period. This text, however, was modified by proposal LAC-2016-7.
Current textCurrent text:
4.5.2.3. Subsequent Allocation Size
When an organization has achieved an acceptable utilization for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.
If an organization needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.
Proposed text:
4.5.2.3. Subsequent Allocation Size
When an organization has achieved an acceptable utilization of its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space it was previously allocated. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation will be extended one bit to the left.
If an organization requires more address space, the organization shall provide documentation justifying the space it needs to serve its clients, number of users, extent of its infrastructure, hierarchical and/or geographic structure, infrastructure segmentation for security or other reasons, and the longevity anticipated for the initial allocation.
Current text:
4.5.2.3. Subsequent Allocation Size
When an organization has achieved an acceptable utilization for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.
If an organization needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement.
Proposed text:
4.5.2.3. Subsequent Allocation Size
When an organization has achieved an acceptable utilization of its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space it was previously allocated. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation will be extended one bit to the left.
If an organization requires more address space, the organization shall provide documentation justifying the space it needs to serve its clients, number of users, extent of its infrastructure, hierarchical and/or geographic structure, infrastructure segmentation for security or other reasons, and the longevity anticipated for the initial allocation.
This modification is fully equivalent to the one implemented by RIPE NCC.
TimetableImmediate implementation
Referenceshttps://www.ripe.net/participate/policies/proposals/2016-05
https://www.apnic.net/community/policy/proposals/prop-122/
LACNIC 28 (18/09/2017)