Hi Nick, Thanks for the detailed response — really appreciate your reply. On the /28 vs /29 point: I recently had to do address planning for an ISP customer with 256 routing regions, each needing to reserve at least 2048 /48s. If I had received a /28 from the start, it would’ve made things /a lot/ cleaner — especially in terms of aggregation and flexibility. I get that not every LIR has this setup, but in cases like this it quickly becomes a practical problem. (In my case I switched to /56 per customer to make it fit) On the second part , applying the policy limitation to the Member rather than the LIR , do I understand correctly that if we don’t make that shift from LIR to Member and just focus on the allocation size (assuming we can agree there’s a good reason), then it will be less of an issue to you ? regards, Rinse On 13-5-2025 13:32, Nick Hilliard wrote:
Angela Dall'Ara wrote on 13/05/2025 09:38:
The RIPE NCC has prepared an impact analysis on this proposal to support the community’s discussion.
Angela,
thanks for organising the impact analysis for this policy proposal.
tl;dr: I disagree with each of the two aspects of the proposal, and as a separate issue, the two should not appear in the same policy proposal together because they're independent of each other.
Jordi, Rinse,
There are two things in this proposal. On the one hand, it increases the size of initial allocations from /29 to /28. On the other hand, it proposes to change the terms of assignment so that the allocation limit applies to the RIPE NCC member rather than to the LIR, the idea being that this would help to prevent stop stockpiling of ipv6 address space.
From a high level point of view, these two things are substantially different and independent to each other. The first is a technical solution to a technical problem, i.e. how to deal with organisations which might need more ipv6 address space, and on the face of it, this is a relatively straightforward change. The second is a subtle but fundamental policy shift about how address allocation works. The details and some of the consequences are outlined in the EB input section of the Impact Analysis, which categorises the change as both high-impact and high-risk from both a governance and policy management point of view.
In terms of the content of the changes:
Increase in Initial Allocation Size --
There are currently 22731 ipv6 allocations, according to today's alloclist.txt file, which can be found in in ftp.ripe.net:/ripe/stats/membership/. Of these, 68 are larger than /29, and there's only been a single allocation larger than /29 issued since Jan 1 2020. This suggests that the current initial allocation size is adequate to deal with most new requests for ipv6 address space. If you have alternative data which indicates otherwise, then it would be good to discuss this.
If organisations need more address space on day 1 but don't qualify for more than /29 (and there are some organisations who genuinely fall into this category), then the appropriate way to deal with this would be to change the Initial allocation policy in ripe-738, section 5.1.
It's not viable to justify a policy by stating "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". If there's a need for established LIRs to increase from /29 to /28, then you need to provide data to directly justify the change, rather than just stating that the proposal might resolve someone's possible needs.
The breakdown of allocation sizes from today's alloclist.txt is as follows:
/19 - 2 /20 - 2 /21 - 4 /22 - 4 /23 - 7 /24 - 7 /25 - 7 /26 - 10 /27 - 14 /28 - 11 /29 - 16406 /30 - 149 /31 - 79 /32 - 6029
It would help clarify future policy proposals / proposal revisions / APWG presentations if you could highlight the fact that currently less than 0.3% of current allocations are larger than /29. I.e. that the proposed change would benefit very few LIRs.
Application of Policy to Member rather than LIR --
There are already anti-stockpiling processes in place:
https://www.ripe.net/about-us/news/updated-approach-to-ipv6-transfer-request...
If you want to change the ipv6 allocation policy to apply to per-member rather than per-LIR, it would be best to handle this in a separate policy, as the executive board has identified that there are significant downstream consequences of this part of the proposal. The new proposal should include the EB analysis of this proposal as the starting point for the "Arguments Opposing the Proposal" section.
Summary --
1. the available data doesn't provide justification for the first change. If there's a problem with the Initial allocation policy or Subsequent allocations, then these aspects of the policy should be fixed rather than making a wide-ranging change which affects 100% of LIRs in order to deal with a problem which impacts significantly less than 1% of LIRs. In any event, data should be provided which adequately justifies the proposal.
2. applying allocation policy to members rather than LIRs is more complex than the proposal anticipated. There is currently very little discussion in the proposal to justify this change, and there are other controls in place to deal with the problem that it proposes to fix.
3. at best, it confuses the two changes to include both this and the change in allocation size in the same proposal: they are very different changes and act independently to the other.
Nick ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/