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/

Hi, On Wed, May 21, 2025 at 11:02:42AM +0100, Nick Hilliard wrote:

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,

Just for the record - this is, and always was, the goal of the IPv6 allocation policy -> give out chunks that are insanely big and most of the receivers will be happy forever with the address space they get, without having to waste human lifetime on argueing or coming back. "Insanely big", of course, needs to be balanced against "number of eligible receivers" and "overall address space size" - and doing that, a /29 is still somewhat conservative (as in "if we spend all of FP001 on /29s, we end up with 67 million /29s, which cannot be handled by BGP in the foreseeable future", so 'run out of space' is not the first problem we're going to hit here). Of course this puts people that really would prefer a "1 bit bigger" allocation in an uncomfortable spot. But this can not be avoided, because there's always some entities that *think* they need bigger, and others that actually *do*. Looking at your numbers again, it seems our current allocation policy does a nice job, making 99+% of the receiving members happy while not taxing the total address space available very much - and the remaining <1% could get more, when spending the effort. That said, maybe we need to work on the criteria, if legitimate use cases find it hard to argue for a /28 or /27. (*That* said, I'm not sure I find "256 routing nodes with 2048 prefixes each" a very realistic mapping of an ISP's network...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Wed, May 21, 2025 at 12:20:44PM +0100, Nick Hilliard wrote:

Gert Doering wrote on 21/05/2025 11:44:

...

That said, maybe we need to work on the criteria, if legitimate use cases find it hard to argue for a /28 or /27.

this is the core problem. As it stands, the proposal deals with the /29 -> /28 case, but doesn't deal with /28 -> /27, or /27 -> /26, and so on. I.e. shifting the bit by one position papers over potential problems with the current allocation policies rather than solving any of them.

Yes. This was more spoken on the general nature of "we have a huge one-size-fits-nearly-all, and need some good criteria for the rest". I wouldn't mind /28 (because math says we can afford it, and to spite ARIN), but I'm not advocating it. The nibble argument is a very weak one, though. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

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