Details
| Ref. Name: AFPUB-2018-V6-004-DRAFT01 |
Versions: 1.0 Status: Under Discussion |
Author: Jordi Palet Martinez, jordi.palet[at]theipv6company.com The IPv6 Company |
|
Amends: CPM art 6.5 |
||
| Submitted: 28 March 2018 |
Proposal
1.0 Summary of the Problem Being Addressed by this Policy Proposal
The actual policy text was done before the IPv6 deployment was initiated, and now we have the experience of new cases of big IPv6 deployments, even government networks.
It is also necessary to align the text of the subsequent allocations, in order to be coherent and not discriminate LIRs with existing allocations.
Furthermore, 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 actual policy, the ISP will be forced to return the prefix initially they originally received, 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.
2.0 Summary of how this proposal addresses the problem
Making sure that the policy text is aligned with a wider set of possible IPv6 deployment cases and facilitate the justification of the allocation size if a bigger address block (versus the default one) is requested.
Ensuring as well, that the subsequent IPv6 allocation policy is synchronized with the initial allocation one.
This proposal seeks to avoid unnecessary work for both parties: the ISP, who would be forced to renumber, and AFRINIC 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.
3. Proposal
Article 6.5 of the CPM will be modified as follows:
| Current | Proposed |
|
6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must:
|
6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must:
|
|
6.5.1.2 Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. Organizations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure. |
6.5.1.2 Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. Organizations may qualify for an initial allocation larger than /32 by submitting documentation that justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organization's infrastructure In this case, the initial allocation shall be based on the space needed to serve the organization's 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. |
|
[Introduce a new clause 6.5.1.3] |
6.5.1.3. Rectifying the size of initial allocations
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.
|
|
6.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. |
6.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. |
4. Revision History
| Date | Details |
|
28 March 2018 |
Version 1: AFPUB-2018-V6-003-DRAFT01 Initial Draft Posted to rpd. |
5. References
Similar text exists and/or has been proposed in related policy documents at other RIR communities.