Hi Nick,
Thanks for the detailed response — really appreciate your reply.
On the /28 vs /29 point: I recently had to do address planning for an
ISP customer with 256 routing regions, each needing to reserve at least
2048 /48s. If I had received a /28 from the start, it would’ve made
things /a lot/ cleaner — especially in terms of aggregation and
flexibility. I get that not every LIR has this setup, but in cases like
this it quickly becomes a practical problem. (In my case I switched to
/56 per customer to make it fit)
On the second part , applying the policy limitation to the Member rather
than the LIR , do I understand correctly that if we don’t make that
shift from LIR to Member and just focus on the allocation size (assuming
we can agree there’s a good reason), then it will be less of an issue to
you ?
regards,
Rinse
On 13-5-2025 13:32, Nick Hilliard wrote:
Angela Dall'Ara wrote on 13/05/2025 09:38:
The RIPE NCC has prepared an impact analysis on this proposal to
support the community’s discussion.
Angela,
thanks for organising the impact analysis for this policy proposal.
tl;dr: I disagree with each of the two aspects of the proposal, and as
a separate issue, the two should not appear in the same policy
proposal together because they're independent of each other.
Jordi, Rinse,
There are two things in this proposal. On the one hand, it increases
the size of initial allocations from /29 to /28. On the other hand, it
proposes to change the terms of assignment so that the allocation
limit applies to the RIPE NCC member rather than to the LIR, the idea
being that this would help to prevent stop stockpiling of ipv6 address
space.
From a high level point of view, these two things are substantially
different and independent to each other. The first is a technical
solution to a technical problem, i.e. how to deal with organisations
which might need more ipv6 address space, and on the face of it, this
is a relatively straightforward change. The second is a subtle but
fundamental policy shift about how address allocation works. The
details and some of the consequences are outlined in the EB input
section of the Impact Analysis, which categorises the change as both
high-impact and high-risk from both a governance and policy management
point of view.
In terms of the content of the changes:
Increase in Initial Allocation Size
--
There are currently 22731 ipv6 allocations, according to today's
alloclist.txt file, which can be found in in
ftp.ripe.net:/ripe/stats/membership/. Of these, 68 are larger than
/29, and there's only been a single allocation larger than /29 issued
since Jan 1 2020. This suggests that the current initial allocation
size is adequate to deal with most new requests for ipv6 address
space. If you have alternative data which indicates otherwise, then it
would be good to discuss this.
If organisations need more address space on day 1 but don't qualify
for more than /29 (and there are some organisations who genuinely fall
into this category), then the appropriate way to deal with this would
be to change the Initial allocation policy in ripe-738, section 5.1.
It's not viable to justify a policy by stating "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". If
there's a need for established LIRs to increase from /29 to /28, then
you need to provide data to directly justify the change, rather than
just stating that the proposal might resolve someone's possible needs.
The breakdown of allocation sizes from today's alloclist.txt is as
follows:
/19 - 2
/20 - 2
/21 - 4
/22 - 4
/23 - 7
/24 - 7
/25 - 7
/26 - 10
/27 - 14
/28 - 11
/29 - 16406
/30 - 149
/31 - 79
/32 - 6029
It would help clarify future policy proposals / proposal revisions /
APWG presentations if you could highlight the fact that currently less
than 0.3% of current allocations are larger than /29. I.e. that the
proposed change would benefit very few LIRs.
Application of Policy to Member rather than LIR
--
There are already anti-stockpiling processes in place:
https://www.ripe.net/about-us/news/updated-approach-to-ipv6-transfer-requests/
If you want to change the ipv6 allocation policy to apply to
per-member rather than per-LIR, it would be best to handle this in a
separate policy, as the executive board has identified that there are
significant downstream consequences of this part of the proposal. The
new proposal should include the EB analysis of this proposal as the
starting point for the "Arguments Opposing the Proposal" section.
Summary
--
1. the available data doesn't provide justification for the first
change. If there's a problem with the Initial allocation policy or
Subsequent allocations, then these aspects of the policy should be
fixed rather than making a wide-ranging change which affects 100% of
LIRs in order to deal with a problem which impacts significantly less
than 1% of LIRs. In any event, data should be provided which
adequately justifies the proposal.
2. applying allocation policy to members rather than LIRs is more
complex than the proposal anticipated. There is currently very little
discussion in the proposal to justify this change, and there are other
controls in place to deal with the problem that it proposes to fix.
3. at best, it confuses the two changes to include both this and the
change in allocation size in the same proposal: they are very
different changes and act independently to the other.
Nick
-----
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/
