Hi Rinse, Rinse Kloek wrote on 20/05/2025 20:02:
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 ?
The two proposed changes are largely unrelated to each other. There might be good reasons for generally changing from LIR to member-based allocations, but it's hard to tell because this isn't the focus of the policy, even though - from the point of view of the EB - it's a fairly major policy change in itself. My take would be that if you want to propose this as a policy change, it would be better to do it in a separate policy proposal. In terms of the /28 vs /29 part of the proposal, it looks to me like the problem you're trying to solve is that some organisations need or could justifiably use a /28, but find it difficult or impossible to justify it under current allocation policies. I've talked to people from larger organisations who have described a need for > /29, but who haven't been able to justify it under the current HD: their concerns are real. In terms of numbers, there's an allocation cliff between /29 and /28:
/27 - 14 /28 - 11 /29 - 16406 /30 - 149 /31 - 79
I didn't mention it in my previous email, but taken as its own data point, it suggests two things: 1. /29 is probably too large as a default allocation size because so few organisations have allocations larger than this, and 2. the difference between /29 and /28 is different enough that it suggests that either a) /29 is wildly too large as a default allocation size, or b) that justifying larger allocations is much too hard under current policies. Which gets back to the point I was making in my previous email: if there's a problem with allocation policy, then the allocation policy should be examined and fixed, rather than changing the default allocation size. Changing the default allocation size might work in a "there, I fixed it!" sense, but I would argue that if we are going to look at the RIPE allocation policy, we should make more effort to understand the underlying strategy and the associated problems with the current allocation policies rather than implementing a quick-fix approach. A better structural fix could involve rewriting ipv6 allocation strategy, or it could be as straightforward changing the HD ratio from 0.94 to something else. Incidentally (and this is not directed at you or Jordi), it's worth reading or re-reading RFC3194. We may have unintentionally shown that HD=94% justifies a new "Excessively Painful" tag in real life. Nick