+1, I support this proposal. Wes Pudu, LLC On Thu, Oct 30, 2025, at 10:50, Leo Vegoda wrote:

Dear Working Group,

We have just over a week left of this Discussion Phase. There haven't been any comments on the list so far.

If you support this draft of the proposal, please indicate that with a simple message. It can be a +1 or a 👍.

If you don't support this draft of the proposal, please explain why.

Thanks,

Alex, Franziska, and Leo Your co-chairs

On Thu, 25 Sept 2025 at 14:08, Angela Dall'Ara <adallara@ripe.net> wrote:

...

Dear colleagues,

A new version of RIPE policy proposal 2024-02 "IPv6 Initial Allocations /28 and extension to /28" is now available for discussion.

Following the last round of discussion, this proposal has been updated and it is now at version 4.0. The main difference from version 3.0 is that it allows the extension without additional documentation of a single allocation per LIR instead of per Member.

You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-02/

As per the RIPE Policy Development Process (PDP), the purpose of this six-week Discussion Phase is to discuss the proposal and provide feedback to the proposers.

At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.

The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781

We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 7 November 2025.

Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

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

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

+1, support for this good proposal. Joris -----Oorspronkelijk bericht----- Van: Leo Vegoda <leo@vegoda.org> Verzonden: donderdag 30 oktober 2025 11:51 Aan: Angela Dall'Ara <adallara@ripe.net> CC: RIPE Address Policy Working Group <address-policy-wg@ripe.net> Onderwerp: [address-policy-wg] Re: 2024-02 New Version Policy Proposal (IPv6 Initial Allocations /28 and extension to /28) Dear Working Group, We have just over a week left of this Discussion Phase. There haven't been any comments on the list so far. If you support this draft of the proposal, please indicate that with a simple message. It can be a +1 or a 👍. If you don't support this draft of the proposal, please explain why. Thanks, Alex, Franziska, and Leo Your co-chairs On Thu, 25 Sept 2025 at 14:08, Angela Dall'Ara <adallara@ripe.net> wrote:

Dear colleagues,

A new version of RIPE policy proposal 2024-02 "IPv6 Initial Allocations /28 and extension to /28" is now available for discussion.

Following the last round of discussion, this proposal has been updated and it is now at version 4.0. The main difference from version 3.0 is that it allows the extension without additional documentation of a single allocation per LIR instead of per Member.

You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-02/

As per the RIPE Policy Development Process (PDP), the purpose of this six-week Discussion Phase is to discuss the proposal and provide feedback to the proposers.

At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.

The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781

We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 7 November 2025.

Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

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

----- 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/ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Thank you, Nick, for your very detailed reply. I don't support this proposal either, mainly because I don't see a need for the change from /29 to /28, given the current policy and historical data. Regards, -kai Am 02.11.25 um 00:40 schrieb Nick Hilliard:

I don't support this proposal.

There are a number of things my email to ap-wg on may 13 2025 which remain unaddressed:

...

https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/message/VL...

Specifically, the numbers show that only 0.3% of organisations with ipv6 allocations have an allocation larger than /29. It's reasonable to assume that the majority of organisations who might benefit from having an allocation larger than /29 would be able to request a larger block under the current needs-based allocation policy. I acknowledge that there are some exceptions to this, but the requirements for that set of organisations should be addressed with a different policy which is tailored for their actual requirements rather than the proposed "/28-size-fits-all" policy which might or might not fit their requirements and which isn't aimed at them in the first place.

In fact, the number of organisations who would benefit from this change is not the total number of organisations with > /29 allocation, but the number of organisations who have a /28, which is 11. That is 0.048% of LIRs.

In other words, the current initial allocation policy size appears to be appropriate for slightly more than 99.95% of LIRs. Any policy which deals with 99.95% of organisations is a pretty damned good policy.

In terms of the arguments supporting the proposal, the authors still have not provided any substantial reason for this policy change. The arguments listed are at best marginal and several of them are not arguments at all.

...

It reduces the RIPE NCC’s overhead and some complexity for the LIR’s justification in most regular cases.

Over the lifetime of all ipv6 allocations issued by the RIPE NCC, this would have benefited only 11 organisations out of the 22,262 organisations who have received ipv6 allocations. I.e. less than a single LIR would benefit from this policy every two years on the basis of the numbers stated. This is not a useful overhead reduction policy for the RIPE NCC, nor is it a useful complexity reduction policy for LIRs because as stated it would only benefit those organisations who would want to apply for a /28 but could only get a /29 under the current policies.

...

It provides flexibility, allowing LIRs to request, for their initial allocation, a single prefix based on the nibble boundary.

It doesn't provide flexibility. The rest of the sentence is not an argument but a statement that a /28 is nibble-aligned.

...

The experience shows that an IPv6 prefix on the nibble boundary greatly simplifies DNS operations. In addition to that, it increases readability of IPv6 addresses, which is always helpful when configuring devices, routes, etc.

It does not "greatly simplify DNS operations". It reduces the number of top-level DNS delegations from 8 zones to 1. This is of very little relevance in the context of modern DNS management or IPAM systems and even if you hand-edit zone files. It's also of almost no relevance to the total overhead of DNS management in an LIR running ipv6.

It does not increase the readability of IPv6 addresses in any meaningful way, and even if it did, this should not be of relevance to assignment policies.

...

Allowing extensions only for allocations originally issued as a single prefix avoids the risk of abuse by infinitely extending chunks resulting from partial IPv6 transfers.

The proposal allows only one extension per LIR without further justification, which limits some of the potential adverse effects of stock-pilers. It also addresses the RIPE NCC Executive Board’s concerns in the previous impact analysis about using “Members” instead of “LIRs”.

These two paragraphs relates to the ancillary safeguard to stop certain types of abuse by stockpilers, but are dependent on the argument that increasing the default allocation size from /29 to /28 is a good idea to start with. I.e. this argument should not be taken into account until the authors have shown that the foundation idea of increasing the default allocation size from /29 to /28 is sound policy.

...

The RIPE NCC confirmed that there are 22,682 IPv6 allocations. 68 of them already have /28 or shorter prefixes (so 22,614 of them are /29 - /32). 20,491 of them have bits reserved to allow the extension to /28. So, 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. All this might result in reducing the IPv6 routing table size. Note that the 91% is calculated including presumable stock-pilers.

This paragraph is not an argument for or against the policy. There is no basis for claiming that the ipv6 routing table size will be reduced, because there is little to no material cost to an organisation to announcing multiple ipv6 prefixes, whereas reducing from two /29s to a single /28 would require renumbering, which has a significant organisational cost and no particular benefit.

In terms of the arguments opposing the proposal:

The authors should state that the proposal would have assisted at least 11 LIRs over the 26 year lifetime of the RIPE NCC's IPv6 allocation, and to provide the percentage to make it clear to people reading the policy that the benefit to most LIRs is nearly nil.

...

By extending the initial allocation size to /28, LIRs gain the ability to split and transfer up to 16 /32 blocks (the current minimum allocation size) to other LIRs.

Counterargument: This practice would be discouraged by the fact that allocations resulting from partial transfers could not be extended anymore.

This counterargument assumes that the arguments to increase the allocation size are justified.

Nick

Hi Rich, Patterson, Richard (Senior IP Architect) wrote on 04/11/2025 20:38:

Nick, I don't think the 11 LIRs or 0.3% statistic is a valid indicator; It's 68 LIRs > /29.  11 refers to those which currently have /28. And I'm sure there are more than 68 networks in the RIPE service region with 500k customers.

Having had to fight tooth and nail with the NCC several times now to get larger IPv6 allocations, I assure you the pain is real; I support a proposal to make it easier to get a larger-than-29 allocation, so indirectly I support this proposal.

I would prefer a proposal to improve policy that streamlines the process and removes the required head-banging-against-brickwall that is currently required to justify a larger allocation, but wording is hard, changing a number from 29 to 28 is (or should be) much easier.

I agree with you that it's too difficult to get larger allocations, but changing the default to /28 is not the solution. All it does is patch a specific case which is not really applicable to most service providers. If there's a problem which causes it to be too difficult to get more than the default size of allocation, then let's fix the problem properly. Nick

Hi, On Tue, Nov 04, 2025 at 10:54:42PM +0000, Patterson, Richard (Senior IP Architect) via address-policy-wg wrote:

I thought the general feeling previously (at and around RIPE 89) was that this approach was an easy quick win and worth doing, as it doesn't preclude any additional proposals to fix the underlying problem(s) properly.

I also thought that increasing the default from 29 to 28 was fairly non-contentious because it is already sparsely allocated as a 28, so it's effectively no-impact to consumption anyway. Perhaps a naive view of things on my part.

All the allocations made when the default size was /35 or /32 came from a reserved /29. So not everything can grow to a /28 "just so". On the proposal itself, I could care less, tbh. The argument "because DNS" is about as weak as it was in version 1 (aka "if you know your tools, it does not make a difference, and if not, it will not help"). OTOH the extra waste induced by making things larger every few years is also tolerable in the grand scheme of things. So I'm just "don't care" on this. 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 Mick, Just a clarification. The change doesn’t change the “default”. It change from /29 to /28 the prefix that you can request without additional justification, but you still can request a /32, /31, /30 or /29. What I always do and recommend to customers is 1st do a good addressing plan, be conservative, not wasteful (even if it is not a problem in IPv6), not too strict. Then you request the right prefix size, not in the other way around. In fact, even if it is much more work, my addressing plans starting point is demography. You can calculate actual number of customers (if you have already an IPv4 network) and expected maximum grow, in each “PoP”, and based on that you can do a better design (not a wasteful one) of your needed prefix. Regards, Jordi @jordipalet

El 5 nov 2025, a las 13:20, Mick O'Donovan via address-policy-wg <address-policy-wg@ripe.net> escribió:

Having read Nick's detailed response on why he doesn't approve of this policy amendment I tend to agree with him and therefore confirm that *I don't approve of this amendment*

Making the sweeping change of default allocations from /29 to /28 seems like the incorrect approach imo to fixing an issue for a clear and very obvious small minority. On that basis, it very much seems like the current policy as written is appropriate and there should be a approach taken to instead look to address the difficulties faced in getting larger blocks for those that need it!

My two cents anyway!

- Mick

-- Mick O’Donovan Senior Network Engineer

HEAnet CLG Ireland's National Education and Research Network

3rd Floor, North Dock 2 | 93/94 North Wall Quay | Dublin D01 V8Y6 | Ireland +353 1 6609040 | mick.odonovan@heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

On 04/11/2025 22:34, Nick Hilliard wrote:

...

CAUTION[External]: This email originated from outside of the organisation. Do not click on links or open the attachments unless you recognise the sender and know the content is safe. Hi Rich, Patterson, Richard (Senior IP Architect) wrote on 04/11/2025 20:38:

...

Nick, I don't think the 11 LIRs or 0.3% statistic is a valid indicator; It's 68 LIRs > /29. 11 refers to those which currently have /28. And I'm sure there are more than 68 networks in the RIPE service region with > 500k customers. Having had to fight tooth and nail with the NCC several times now to get larger IPv6 allocations, I assure you the pain is real; I support a proposal to make it easier to get a larger-than-29 allocation, so indirectly I support this proposal.

I would prefer a proposal to improve policy that streamlines the process and removes the required head-banging-against-brickwall that is currently required to justify a larger allocation, but wording is hard, changing a number from 29 to 28 is (or should be) much easier. I agree with you that it's too difficult to get larger allocations, but changing the default to /28 is not the solution. All it does is patch a specific case which is not really applicable to most service providers. If there's a problem which causes it to be too difficult to get more than the default size of allocation, then let's fix the problem properly. 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/

<OpenPGP_0x5200DFEAD07FBDF5.asc>----- 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.

Dear AP-WG, I'm personally against moving forward with this proposal. The reason is that I haven't seen any real data, as mentioned in the last paragraph of my previous message on this topic [1]. Having such data would allow us to assess the real need for this proposed policy change. [1] https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/message/QC... Best, Piotr On Thu, Oct 30, 2025 at 10:50:35AM +0000, Leo Vegoda wrote:

Dear Working Group,

We have just over a week left of this Discussion Phase. There haven't been any comments on the list so far.

If you support this draft of the proposal, please indicate that with a simple message. It can be a +1 or a ????.

If you don't support this draft of the proposal, please explain why.

Thanks,

Alex, Franziska, and Leo Your co-chairs

On Thu, 25 Sept 2025 at 14:08, Angela Dall'Ara <adallara@ripe.net> wrote:

...

Dear colleagues,

A new version of RIPE policy proposal 2024-02 "IPv6 Initial Allocations /28 and extension to /28" is now available for discussion.

Following the last round of discussion, this proposal has been updated and it is now at version 4.0. The main difference from version 3.0 is that it allows the extension without additional documentation of a single allocation per LIR instead of per Member.

You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-02/

As per the RIPE Policy Development Process (PDP), the purpose of this six-week Discussion Phase is to discuss the proposal and provide feedback to the proposers.

At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.

The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781

We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 7 November 2025.

Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

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

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

Hi Piotr, all, (and responding to several others as the points are basically the same) If I recall correctly the data of rejected requests was provided a year ago by the NCC and was in our slides for the first version of the proposal. However, I don’t think this should be taken as the “only real data” (and consequently % calculated by Nick are not good - we will not have good data unless every member comes and say if they will have wanted a shorter prefix). Let me explain. In my experience, not just in RIPE, but also in other regions, when an ISP has difficulties to obtain the prefix size they believe they need for their network, considering actual number of users and planned network design for a few additional years, they don’t bother to keep trying to fight with the RIR, they pass "the ball" to the customers: So instead of providing them what they initially though is the right prefix size, for example /48, they will reduce it to a /56 or even worst /60. So in most of the cases, the RIR is not even getting the requests, because they know it will not work or they don’t bother to waste time in a long justification discussion. In fact I’ve seen many times, that many LIRs, having “IPv4 mind-set”, they just go for the minimum allocation /32, because they believe they will allocate a single /128 or /64 for customers. Of course, a different problem, but it shows that people tend to go for the easy and if they avoid documentation to justify anything, it is easier. This has been said already several times by other folks in this thread and in previous similar ones. It will be nice if other members like Rinse and Richard did, publicly say "yes, we have been in the same situation and we reduced the prefix to customers because even if the justification was good enough, RIPE NCC could accept it and we give up”. But I don’t think it will happen. Even it will be curious to know the % of members that are in this mailing list … not to say how many actually participate. In the corridors, during meetings across the years, I got from many members that same comments that we got publicly from Richard and Rinse. And even more, the first time Richard told me about that, I told him “I’m sure we don’t need to change the policy, you just need to do a better job in the justification” … and here I'm, eating my own words. Thousand excuses Richard, of course you was absolutely right! We tried to fix the policy a few times to make easy the justification, and didn’t worked. I will be happy if we can find a magic wording for that, but across many years was not fixable. Our initial proposal presented to the chairs had a different plan and included a more complete review of the IPv6 policy, including all this and the PI parts. The idea was to size the allocations based on network size in terms of number of users (something like if you have “n” end-sites you will get up to /28, for “2xn” you will get /24, etc. - note not real numbers just to provide an idea). However the chairs asked as to break up the policy in different smaller parts. This looks a good idea, but I always said is not. You need to see a complete view of the situation and change many pieces of the text. A progressive approach doesn’t seem to work as expected. Now, looking into the policy proposal that we have in the table: 1) We know that allowing a /28 without justification is not a big issue neither for RIPE NCC neither for the global Internet. Even if we provide several /48’s per each human (not just per-end site), we will have IPv6 for about 500 years, in the worst case. 2) Allowing /28 doesn’t mean that everyone will take it, or everyone will request to upgrade to it, so this reinforces 1 above. 3) Allowing /28 will allow more LIRs to provide /48 to end-sites instead of longer prefixes which is really bad. Will avoid future renumbering and we know that’s not easy. Remember that we have more and more ways (RFC9663 and RFC8273) to provide to hosts not just a /128 but prefixes, so containers, VMs, etc., in all kind of devices can have real IPv6 addresses and we avoid repeating mistakes like NAT. 4) Allowing /28 will solve the problem for a few or many, I really don’t think “to how many" is the key. Let me explain this last point. If we pretend to be a community, as we have heard across the years a few colleagues that have problems justifying a real need, and we know that accepting this change solves the problem for a few of them, not creating any real problem for the rest of the community, then we, as a community must do it. Otherwise, may be we should not call ourselves a community in the sense that looks for the good of all (at least this is my view of what is a community in our environment). I will understand that we reject something that creates many problems for the global community, but this is not the case. Regards, Jordi @jordipalet

El 5 nov 2025, a las 18:20, Piotr Strzyzewski <piotr@internetsailor.net> escribió:

Dear AP-WG,

I'm personally against moving forward with this proposal. The reason is that I haven't seen any real data, as mentioned in the last paragraph of my previous message on this topic [1]. Having such data would allow us to assess the real need for this proposed policy change.

[1] https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/message/QC...

Best, Piotr

On Thu, Oct 30, 2025 at 10:50:35AM +0000, Leo Vegoda wrote:

...

Dear Working Group,

We have just over a week left of this Discussion Phase. There haven't been any comments on the list so far.

If you support this draft of the proposal, please indicate that with a simple message. It can be a +1 or a ????.

If you don't support this draft of the proposal, please explain why.

Thanks,

Alex, Franziska, and Leo Your co-chairs

On Thu, 25 Sept 2025 at 14:08, Angela Dall'Ara <adallara@ripe.net> wrote:

...

Dear colleagues,

A new version of RIPE policy proposal 2024-02 "IPv6 Initial Allocations /28 and extension to /28" is now available for discussion.

Following the last round of discussion, this proposal has been updated and it is now at version 4.0. The main difference from version 3.0 is that it allows the extension without additional documentation of a single allocation per LIR instead of per Member.

You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-02/

As per the RIPE Policy Development Process (PDP), the purpose of this six-week Discussion Phase is to discuss the proposal and provide feedback to the proposers.

At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal.

The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781

We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 7 November 2025.

Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

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

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

---

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.

Hi Nick, When designing a medium to large ISP network, it’s common to split it into multiple routing areas, each with its own subnet(s) for proper aggregation. In my case, as a medium-sized ISP, I wanted to create an address plan that can scale to around 1 million end-users. A /28 would have made this possible. We started small, but want room to grow — redesigning the addressing plan later would be much more complex. Since there is plenty of address space available (RIPE already reserves a /26), why not allow an ISP to start with an allocation that matches its realistic growth target? As Jordi also says, If you don't need that from the start, you are free to go with the smaller /32 (or /31 or /30...) Here’s the concrete plan: 256 routing areas → needs 8 bits Up to 4,000 /48s per area → round to 4,096 = 2¹² → needs 12 bits Total bits from allocation to /48 = 8 + 12 = 20 bits => /48 − 20 = /28 This checks out: 256 × 4,000 = 1,024,000 /48s ≈ 2²⁰ /28 provides 2^(48−28) = 2²⁰ = 1,048,576 /48s A /28 fits this plan with a small safety margin (~24k /48s). A /29 (2¹⁹ = 524,288 /48s) would not be sufficient in this case. Regards, Rinse On 11/6/2025 7:06 PM, Nick Hilliard wrote:

jordi.palet--- via address-policy-wg wrote on 06/11/2025 14:42:

...

However, I don’t think this should be taken as the “only real data” (and consequently % calculated by Nick are not good - we will not have good data unless every member comes and say if they will have wanted a shorter prefix). Jordi,

Just to clarify the figures I quoted: a /29 will provide 2^(48-29) = 2^19 /48s.

In other words, /29 is roughly a reasonable general magnitude for an organisation with a requirement of up to around 500,000 /48s.

The questions we need to ask are:

1. roughly how many organisations are there in the RIPE NCC service region that need > 500,000 /48s. I.e. what's the size of the problem we're trying to solve here?

2. how can we fix the ipv6 allocation policy to help these organisations get the address space that they need?

If we tweak the netmask one bit to the left, from /29 to /28, then all that will happen is that we'll be talking about 1m customers instead of 1/2m, but the underlying problem will still be there, and unsolved.

That is why we need to discuss and try to fix the underlying problem.

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/

I agree this proposal just kicks the can down the road and I would like to see the underlying issues fixed. I think we're all in agreement on that. For the list record, I'll briefly summarise my personal experience over the last few years of requesting more/larger IPv6 allocations: 1. New LIR with a greenfield network build. Zero customers, but the business plan/forecast would have us exceeding the initial allocation very quickly if we followed RIPE-690 and used /48-sized prefix delegation. * NCC's expectation was that we design the network knowing that we would run out, and then come back when we could prove it. * Not ideal from my perspective, and we had many back-n-forth discussions trying to justify the request before we almost gave up and used /56. Thankfully in the end (many months) we got a larger allocation. 2. Two LIRs both owned by the same legal entity. LIR1 had exhausted its initial /29 allocation, and requested expansion or another allocation, the NCC said "Why aren't you using the /29 in LIR2?" and told us to transfer the unused /29 from LIR2 to LIR1. * We only lightly pushed back on this, I wish we had pushed back more, but IMO the NCC should not have even looked at a different LIR/membership when evaluating this request. 3. LIR2 now wants to start deploying IPv6 so requests a new initial allocation because it no longer has one. The NCC says "You've already had your initial allocation, you can't have anymore". * This required months of back-n-forths, still didn't get anywhere, and eventually required escalation to get resolved. Issue 1, is a bit of a chicken and egg deal, and policy could probably be updated to improve this specific situation, if the community thinks it should. (But I concede this is a unique case) Issues 2 and 3 are more misunderstandings or perhaps misinterpretations. I don't think policy changes are required to change the fundamentals, but perhaps the wording of the policy could be updated to avoid the misinterpretations. e.g., defining "Member" == "LIR", not "Account Holder", and clarifying or renaming "Initial Allocation". From: Tore Anderson <tore@fud.no> Date: Friday, 7 November 2025 at 09:46 To: Nick Hilliard <nick@foobar.org>, jordi.palet@consulintel.es <jordi.palet@consulintel.es> Cc: RIPE Address Policy Working Group <address-policy-wg@ripe.net> Subject: [EXTERNAL] [address-policy-wg] Re: 2024-02 New Version Policy Proposal (IPv6 Initial Allocations /28 and extension to /28) Den 06.11.2025 19:06, skreiv Nick Hilliard:

If we tweak the netmask one bit to the left, from /29 to /28, then all that will happen is that we'll be talking about 1m customers instead of 1/2m, but the underlying problem will still be there, and unsolved.

That is why we need to discuss and try to fix the underlying problem.

The above succinctly summarises my thoughts about this policy proposal. It seems to just kick the can down the road. Is it truly the case the an LIRs with >500k active subscribers all ready to be assigned /48s will *not* receive an initial allocation of a /28, if they request one? I see this argument is being made, but I have a hard time believing it, if I am being honest. I do not understand how the NCC could possibly refuse such a request based on section 5.1.2 in the policy. Tore ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://urldefense.com/v3/__https://mailman.ripe.net/mailman3/lists/address-... 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://urldefense.com/v3/__https://www.ripe.net/membership/mail/mailman-3-m... -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

On Thu, Nov 06, 2025 at 09:42:04AM -0500, jordi.palet--- via address-policy-wg wrote: Hi Jordi,

Hi Piotr, all, (and responding to several others as the points are basically the same)

If I recall correctly the data of rejected requests was provided a year ago by the NCC and was in our slides for the first version of the proposal.

Thank you for this reminder. I assume you are referring to this presentation [1]. Unfortunately, I was unable to find any email containing this data. Based on this, I found that from January 2023 to October 2024 (my understanding of the sentence), NCC "closed 331 IPv6 additional allocation tickets and extended 129 IPv6 allocations." That means 202 tickets were closed without such extension. Later on the same slide, there is information that "Some people request an additional allocation, we tell them more about how they can use their existing one, and they never reply. _This happens often._". I assume [2] that "often" means 50% of the time. That lowers the number to 101 tickets closed without extension in the 22-month period, which means around 55 per year. An important note is that other major reasons for closing the tickets without such an extension were not mentioned in the presentation. I leave the interpretation of this data to anyone interested.

However, I don???t think this should be taken as the ???only real data??? (and consequently % calculated by Nick are not good - we will not have good data unless every member comes and say if they will have wanted a shorter prefix).

I beg to differ. First of all, we have some real data that allows us to make estimates. Secondly, probing the entire population is not the only way to obtain "good data" for some definition of good. [1] https://ripe89.ripe.net/wp-content/uploads/presentations/80-2024-02-RIPE-89-... [2] As a non-native speaker who doesn't want to be biased, I asked AI to rank commonly used frequency adverbs/phrases in British English, along with approximate probabilities indicating how often the events occur. "Often" was assigned 50%-70%. I decided to use 50%. With 70%, the numbers are 60 and 33, respectively. Best, Piotr -- Piotr Strzyżewski