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 <[email protected]> > 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/[email protected]/message/QCIQBXYXFPAP7JVZG2ZS7CHHNIIJUWRU/ > > 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 <[email protected]> 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 >>> [email protected] 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. ----- 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/
