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