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

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