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
-----
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/
