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/
