Hi Jordi, First of all, let me repeat what I said during the AP-WG session - let's not repeat the mistakes of the past. Now, let me also support this with some references. My understanding is that you claim that "because the organization term is not defined, [it] is by default taken as 'member'". Nevertheless, when one checks RIPE-552, which implements Policy Proposal 2011-04 ("This proposal modifies the eligibility for an organisation to receive an initial IPv6 allocation up to a /29."), it becomes clear that the NCC's understanding was different. The policy text states: "Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary", whereas RIPE NCC's Understanding of the Proposed Policy says: "This proposal defines the size of the initial IPv6 allocation LIRs can receive. If this proposal will be implemented, LIRs currently eligible for a /32 will be eligible for up to a /29". This means that, back then, the NCC understood the term "organisation" as "LIR", not as "member". In my view, this interpretation feels more natural when one follows the text (still present in RIPE-699) in sections 2.5, then 2.4, and finally 2.1. I hope this clarifies the matter. As for the "there are many others" cases - have you checked with the NCC for aggregated data on the number of requests for allocations larger than /29 over the years, with particular emphasis on rejected requests? That could provide some valuable context and real data for this proposal. Best, Piotr On Wed, May 21, 2025 at 01:08:51PM +0200, jordi.palet--- via address-policy-wg wrote:
Hi Nick,
As we mention in the mic last week, previously the policy didn???t worked based on LIRs, but organizations:
https://www.ripe.net/publications/docs/ripe-699/diff/ripe-738/??? IPv6 Address Allocation and Assignment Policy ripe.net
My understanding is that because the organization term is not defined, is by default taken as ???member???, as it can be a real incorporated organization (juridical person), but asl members can be physical persons (with or without economical activity).
So while I understand your concern and the EB points, I think this is not a real problem. I only can agree that this makes a bit more complete de implementation of the proposal in terms of software development, but we are just somehow ???going back??? to our origins in terms of limiting the number of allocations that can be assigned per ???organization??? (read member).
Anyway, I think is possible to amend the proposal to use again LIR and ignore the stock-piling problem here, because is being operationally solved by the NCC, at least partially, as Marco presented in the meeting.
Now, regarding the other point, we tried very hard already several times, to have a different criteria to be able to get everyone happy with the initial allocation, and clearly is not working. That why we believe (not just the co-authors but according to previous rounds of discussions in the WG, interim meetings, etc.) that a /28 will work much better for all. This doesn???t means that everyone get a /28 by default.
It is really bad that cases like the one Rinse mention (and there are many others), decide to assign /56, /60, etc., instead of /48, even if they are convinced that the right thing to do is /48, just because the justification or criteria, doesn???t work well.
Now, on the HD-Ratio, and the criteria, our goal is to change both of them, as explained in our last slide.
Our *initial* proposal sent to the chairs had all the changes in one shot. In my personal opinion this is much better because then you have an *overall* view of what we are trying to do and the discussion is more complete. However, the chairs suggested that we should split the proposal in 2-3 parts. Probably a mistake as authors to accept that ???enforced recommendation???.
I personally think we should really go back to the original idea of having the proposal with all the changes.
Then we can have a table instead of the HD-Ratio for number of subscribers for a /32, /28, /24, or even steps in the middle if the community believes that nibble boundary is not the best.
Regards, Jordi
@jordipalet
El 21 may 2025, a las 12:02, Nick Hilliard <nick@foobar.org> escribió:
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/
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
----- 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/
-- Piotr Strzyżewski