Hola, Sounds to me that 91% of the prefixes could previously not justify that they needed more space. Checking a nice tool like https://bgp.tools to see how many hosts are actually active give a good indicator per prefix how that is the case. The LIR vs Member part also makes this a lot more work for the NCC. On top of that though there seem to be many LIRs setup for 'companies', that then after the time has passed are merged with other similar ones. One can already see many ASNs with multiple (in some cases 20+!) /32s from a single ASN and often a related (eg upstream or side-ASN under that same upstream) with the same name/description of the /32 or bigger (depending on when they registered). As such, of those 91% that could 'grow' to a /28, how many will suddenly take more space and upgrade it. RIPE NCC cannot say which companies are the same 'member', thus all would be valid. As the text says itself: "Note that the 91% is calculated including presumable stock-pilers." (no idea why people are trying to stock pile IPv6 prefixes.... there is soooo much of it...) Please let people justify their needs, even if lightly. Being able to show that you have more than 2^(48-29) customers, or even close to that and that your currently used address space is 'well used' should not be tricky, it means that you will have a LOT of customer Atlas probes in your network ;) Yes, there is "enough", and yes, if we cock up this first 2000::/3 we can do that problem another 5 times. But when that was worded, some 20+ years ago, the initial allocations were /32, not /29 let alone /28. And indeed, most of those /32s can be upgraded in the same slot to a /26. Any LIR that needs 'more space' can grow that upto the /26 by filing the paper work, in the same routing slot. Many will chose (as can be checked in current routing tables) to separately announce a /29 as multiple /32s though, thus a /28 will take 16 slots. Thus if routing slots is the concern, then one should justify the need for that space. Considering that only a few have done so, either says nobody really needs it; or that the process is to tricky (if the latter, which the NCC can say if that is the case of how many attempts have failed and thus a ratio of rejected/allowed) then that needs to be adjusted. And checking the 'very large ASNs' they already get big and often multiple allocations from multiple RIRs and... they can justify it easily (they also have the #hosts or customers to do so). Thus for which people is this policy change meant: - it does not seem to help workload in NCC: 15k+ could then 'freely' request upgrade without justification or actual need. - it does not help the few that can actually justify it: they already did Thus, why bother going with this change? I think it would be better for the NCC to spend time on validating that the "company" behind an LIR is a real entity, and not just another incarnation of another company. The routing tables tell us quite adifferent story where address space is "used" and how it is used... Regards, Jeroen
On 13 May 2025, at 10:38, Angela Dall'Ara <adallara@ripe.net> wrote:
Dear colleagues,
Policy proposal 2024-02, "IPv6 Initial Allocations /28 ", is now in the Review Phase.
This proposal aims to change the initial IPv6 allocation size from /29 to /28 and allow one IPv6 allocation extension per member to /28 without justification.
This proposal has been updated and it is now at version 3.0. The main difference from version 2.0 is that one IPv6 allocation extension up to /28 without justification is allowed per member instead of per LIR.
The RIPE NCC has prepared an impact analysis on this proposal to support the community’s discussion.
You can find the proposal and impact analysis at: https://www.ripe.net/community/policies/proposals/2024-02/ https://www.ripe.net/participate/policies/proposals/2024-02#impact-analysis And the draft document at: https://www.ripe.net/participate/policies/proposals/2023-04/draft
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg@ripe.net before 11 June 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/