- Legend
- Added
- Deleted
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 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
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 up to /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
A Member, that holds Organizations, not LIRs, that hold one or more IPv6 allocations that were originally issued directly to them by the RIPE NCC as a single prefix, mayrequest prefix may request once an extension of one of these allocations suchallocation up to a /28 without the need for additional documentation. Only one such extension may be granted per Member, regardless of the number of LIR accounts they hold.
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.
The proposal allows only one extension per Member, organization, which limits some of the potential adverse effects of stockpiling.
The 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. Note that the 91% is calculated including presumable stock-pilers.
b. Arguments Opposing the Proposal
This policy proposal is perceived as counterproductive to conservation efforts. Under the proposal, LIRs can initially receive up to twice the amount of IPv6 space compared to the current system.
- Counterarguments: For each new /29 allocation, the RIPE NCC already reserves a /26 block. This means that the proposed change will not significantly increase the depletion rate of the RIPE NCC address pool. Additionally, LIRs retain the option to request an allocation smaller than a /28, with a minimum of /32 if they do not require larger address spaces.
By extending the initial allocation size to /28, LIRs gain the ability to split and transfer up to 16 /32 blocks (the current minimum allocation size) to other LIRs.
- Counterargument: This practice would be discouraged by the fact that allocations resulting from partial transfers could not be extended anymore.
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
It is the RIPE NCC’s understanding that this proposal, if accepted, will change the current practice for issuing IPv6 initial allocations and for extending existing IPv6 allocations without a justification requirement.
Specifically, from the moment this proposal would come into effect,
- The maximum size that can be requested as initial IPv6 allocation, confirming only the plan to make assignments within two years, will be /28 instead of /29.
- Each LIR account, including multiple accounts held by the same member, can receive an initial IPv6 allocation up to a /28.
- RIPE NCC members holding multiple IPv6 allocations in one or more LIR accounts will be able to extend up to /28, without justification, one of the allocations they received directly from the RIPE NCC, provided none of its parts have been transferred away. A documented justification will be required to extend any other allocation.
- While new members can open multiple LIR accounts and receive a prefix from /32 to /28 in each account, they will be allowed to extend without justification only one of such prefixes to /28 if they initially requested a smaller size.
- All requests to extend allocations received via a transfer will require justification.
The following will not change
- Requesting an initial allocation with the minimum size /32 or the intermediate sizes /31, /30 and /29 will still be possible.
- Whenever the available contiguous address space is insufficient to satisfy an approved extension, a new allocation will be issued, and renumbering and return of the allocation for which the extension was requested will be required.
- Subsequent allocations will still be issued by doubling the size of existing ones (i.e., one bit at a time), leading to blocks not aligned on nibble boundaries.
If the proposal is accepted, a new policy document, “IPv6 Address Allocation and Assignment Policy”, will obsolete the current one (ripe-738).
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 anticipates a
higher amount of distributed IPv6 addresses due to the larger size of new initial allocations and the requested extensions to /28 of eligible existing allocations. This is considering that the majority of LIRs will request the maximum allocation size allowed by the policy.
Fragmentation/Aggregation:
The RIPE NCC expects the global routing table to grow if this proposal is accepted, provided that LIRs will have more IPv6 address space to manage and that separate routing of more specific prefixes from the allocations remains an option. It is possible that organisations will be less motivated to optimise the usage of their allocated space in terms of aggregation, preferring de-aggregation due to traffic engineering.
C1. Impact of Policy on RIPE NCC Operations/Services
Software Engineering:
Software development work will be needed to update our systems to apply the new size range to initial allocation requests. Limiting extensions (without justification) to one per member rather than one per LIR will require significant and extensive work to implement new functionalities that allow us to:
- Identify allocations that may be extended according to the policy
- Track across all LIRs held by the same member that such an extension has already been granted
Registration Services:
RIPE NCC Registration Services anticipates the following impact if this proposal is implemented:
- An increased workload can be expected, at least temporarily:
- A significant number of requests to extend IPv6 allocations to /28 is expected to be submitted. Around 15,000 members hold IPv6 allocations that are eligible for extension. However, the actual number of requests will likely be lower as not all will apply.
- A specific procedure must be followed to receive the confirmation that all LIRs of the same member are aware that a request for an extension has been submitted.
- Some members, unaware of the details of the policy change, may expect all their allocations to be extendable without justification and could challenge the RIPE NCC’s evaluation.
- This proposal will also reduce workload, though to a lesser extent:
- Most new members will start with a /28 allocation, which should provide more than sufficient address space, further decreasing the already low number of subsequent allocation requests.
- With the doubling of the standard IPv6 allocation size, fewer initial requests for larger allocations are expected, subsequently reducing the need for extensive evaluation of such requests.
C2. RIPE NCC Executive Board’s input
Changing the policy wording from LIR to Member will have a very high impact on our registry systems and registry administration execution, and could set a precedent for future policies that shift the technical implementation focus from LIR to Member. Therefore, we strongly recommend a careful evaluation of whether this shift is truly necessary for this policy. As an alternative, we suggest maintaining the current technical and administrative terminology (i.e., using LIR rather than Member) to preserve the clear distinction between the two concepts and to stay true to the original rationale behind their separation.
Member vs LIR: Origins and Rationale
The current policy framework at the RIPE NCC deliberately maintains a clear distinction between the administrative concept of “Member” and the technical role of “Local Internet Registry” (LIR). This separation, introduced over a decade ago, was designed to clarify and streamline the processes: the Member governs the contractual and administrative relationship with the RIPE NCC, whereas the LIR focuses on the technical management and distribution of IP resources. Introducing an administrative term (Member) into a context traditionally reserved for a technical role (LIR) blurs the boundary between policy governance and technical resource management. The proposal to replace “LIR” with “Member” marks a significant departure from this established framework and raises several challenges:
- Precedent for Future Policy:
Merging these concepts may set a precedent that undermines the clarity and effectiveness of future policy development. The separation was specifically intended to avoid such overlaps, ensuring that administrative and technical processes could evolve independently to meet their respective needs. - Increased Technical Complexity:
RIPE NCC’s internal systems, databases, and operational workflows are designed around the LIR as the primary technical entity for resource allocation. Modifying this system to accommodate Member-level references would require a substantial system redesign and could introduce ambiguity or errors in resource tracking and compliance. - Impact on Community Governance and Policy Enforcement:
The current model allows for nuanced policy controls, such as limiting the creation of multiple LIR accounts by a single member to prevent resource hoarding or policy circumvention. Abandoning this distinction could weaken these controls and complicate both policy enforcement and community oversight.
Summary
In summary, while the intention behind the policy proposal may be to simplify or modernise IPv6 allocation processes, removing the LIR-to-Member reference is likely to lead to technical and governance complications and is therefore considered to be a high-impact, high-risk change that will have a significant impact on the systems and processes that we use to implement the RIPE community’s policies.
D. Legal Impact of Policy
None
E. Implementation
With the information currently available, it is expected that implementation of the proposal will have a high impact on RIPE NCC’s internal systems’ software development. Internal and external processes and documentation, including material for training and exams, will also need to be updated and approved internally before publication.