Nick, I don't think the 11 LIRs or 0.3% statistic is a valid indicator; we know there are LIRs (myself included) that have made addressing decisions because they struggled to get larger, or made the decision based on their initial allocation so they didn't have to revisit the network design at a later date. This is a chicken and egg situation, LIRs that don't get a large enough allocation (by default), design their networks to what they have got, not to what they might be able to get in the future.
If a broadband provider were to follow ripe-690's "/48 for everybody" recommendation, that /29 only supports ~524K subscribers without even considering infrastructure. There are definitely more than 11 ISPs in Europe that have more than 524K subs 😊 This is the main reason why broadband subscribers are currently only getting /56-size PDs (or even worse), not the misconception that ISPs want to "upsell" them to a larger prefix. 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. -Rich From: Nick Hilliard <[email protected]> Date: Saturday, 1 November 2025 at 23:41 To: Leo Vegoda <[email protected]> Cc: Angela Dall'Ara <[email protected]>, RIPE Address Policy Working Group <[email protected]> Subject: [EXTERNAL] [address-policy-wg] Re: 2024-02 New Version Policy Proposal (IPv6 Initial Allocations /28 and extension to /28) 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/[email protected]/message/VLOYBQEKQASWVFWKTVTLWNQBWFIGJZNJ/<https://urldefense.com/v3/__https://mailman.ripe.net/archives/list/[email protected]/message/VLOYBQEKQASWVFWKTVTLWNQBWFIGJZNJ/__;!!IlCVUJ0!oHewDutZphGPbP3VF34779FJofmZ2u7gKgkRj8D-mnyGp41Wgq7sUw-lTlVuWsSHLV69bhXdTABdw3rFjP0$> 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 Leo Vegoda wrote on 30/10/2025 10:50: 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]><mailto:[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/<https://urldefense.com/v3/__https://www.ripe.net/community/policies/proposals/2024-02/__;!!IlCVUJ0!oHewDutZphGPbP3VF34779FJofmZ2u7gKgkRj8D-mnyGp41Wgq7sUw-lTlVuWsSHLV69bhXdTABd5LQVPF0$> 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<https://urldefense.com/v3/__https://www.ripe.net/publications/docs/ripe-781__;!!IlCVUJ0!oHewDutZphGPbP3VF34779FJofmZ2u7gKgkRj8D-mnyGp41Wgq7sUw-lTlVuWsSHLV69bhXdTABdTn5rZxU$> We encourage you to review this proposal and send your comments to [email protected]<mailto:[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/<https://urldefense.com/v3/__https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/__;!!IlCVUJ0!oHewDutZphGPbP3VF34779FJofmZ2u7gKgkRj8D-mnyGp41Wgq7sUw-lTlVuWsSHLV69bhXdTABdLjJSRqM$> 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/<https://urldefense.com/v3/__https://www.ripe.net/membership/mail/mailman-3-migration/__;!!IlCVUJ0!oHewDutZphGPbP3VF34779FJofmZ2u7gKgkRj8D-mnyGp41Wgq7sUw-lTlVuWsSHLV69bhXdTABdgMkVGLo$> ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/<https://urldefense.com/v3/__https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/__;!!IlCVUJ0!oHewDutZphGPbP3VF34779FJofmZ2u7gKgkRj8D-mnyGp41Wgq7sUw-lTlVuWsSHLV69bhXdTABdLjJSRqM$> 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/<https://urldefense.com/v3/__https://www.ripe.net/membership/mail/mailman-3-migration/__;!!IlCVUJ0!oHewDutZphGPbP3VF34779FJofmZ2u7gKgkRj8D-mnyGp41Wgq7sUw-lTlVuWsSHLV69bhXdTABdgMkVGLo$> -------------------------------------------------------------------- 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 [email protected]. 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
----- 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/
