IPv6 Initial Allocations /28
- State:
- Discussion Phase: Awaiting decision from proposer
- Publication date
- Affects
- Draft document
- Draft
- Authors
- Proposal Version
- 1.0 - 14 Oct 2024
- All Versions
-
- State Discription
- Awaiting new version from Proposer
- Working Group
- Address Policy Working Group
- Mailing List
- Address Policy Working Group
- Proposal type
-
- Modify
- Policy term
- Indefinite
Summary of Proposal:
This proposal suggests a revision of the initial IPv6 allocation size to foster IPv6 adoption in the RIPE NCC region. This is by simplifying the way LIRs can obtain IPv6 address space suitable for their networks’ operational requirements.
The proposal originates from the opinions expressed by members of the RIPE community in the Address Policy Working Group during presentations [1], interim sessions [2] and a call with the WG Co-Chairs on this topic.
[1] https://ripe85.ripe.net/wp-content/uploads/presentations/81-IPv6_at_RIPE-85.pdf
[2] https://www.ripe.net/community/wg/active-wg/ap/interim-sessions/interim-session-20-february-2023/
Policy Text:
Current Policy text (ripe-738):
5.1.2. Initial allocation size
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 up to /29 without needing to supply any additional information.
LIRs may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the LIR infrastructure, the hierarchical and geographical structuring of the LIR, the segmentation of infrastructure for security and the planned longevity of the allocation.
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.
The RIPE NCC should allocate the new address space contiguously with the LIRs' existing allocations and avoid allocating non-contiguous space under this policy section.
New Policy text:
5.1.2. Initial allocation size
LIRs that meet the initial allocation criteria are eligible to receive an initial allocation of /32 or /28 without needing to supply any additional information.
LIRs may qualify for an initial allocation greater than /28 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the LIR infrastructure, the hierarchical and geographical structuring of the LIR, the segmentation of infrastructure for security and the planned longevity of the allocation.
5.7. Existing IPv6 address space holders
LIRs that hold one or more IPv6 allocations that were originally issued directly by the RIPE NCC as a single prefix may request an extension of each such allocation up to a /28 without the need for additional documentation.
The RIPE NCC should allocate the new address space contiguously with the LIRs' existing allocations and avoid allocating non-contiguous space under this policy section.
Rationale:
a. Arguments Supporting the Proposal
This proposal supports a regular update of the policy, backed up by IPv6 deployment experience. It reduces the RIPE NCC’s overhead and some complexity for the LIR’s justification in most regular cases. It provides flexibility, allowing LIRs to request, for their initial allocation, a single prefix based on the nibble boundary.
The experience shows that an IPv6 prefix on the nibble boundary greatly simplifies DNS operations. In addition to that, it increases readability of IPv6 addresses, which is always helpful when configuring devices, routes, etc.
Allowing extensions only for allocations originally issued as a single prefix avoids the risk of abuse by infinitely extending chunks resulting from partial IPv6 transfers.
RIPE NCC confirmed that there are 22,682 IPv6 allocations. Sixty-eight of them already have /28 or shorter prefixes (so 22,614 of them are /29-/32). 20,491 of them have bits reserved to allow the extension to /28. So, this proposal would resolve possible extension needs for the majority (91%) of members using the same prefix, just by extending some bits to the left.
All this might result in reducing the IPv6 routing table size.
b. Arguments Opposing the Proposal
None.