[address-policy-wg] IPv6 Policy Musings...

Good morning,

thanks Max :) and of course Gert for the effort and the excellent presentation; I fully agree with the goals you described.

To reiterate, end users can request an assignment of one separate /48 PI allocation per site with little justification. The implementation of the current policy permanently inhibits aggregation; receiving the same number of bits as an aggregate assignment instead of multiple /48 PI in practice requires a much more convoluted justification of additional routing requirements.

To get a better understanding of the impact of the current policy, I've done some analysis on the state of IPv6 PI assignments:

Number of IPv6 PI assignments per prefix length:
/48: 3381 assignments
/47: 40 assignments
/46: 15 assignments
/45: 7 assignments
/44: 2 assignments
/42: 1 assignment
/40: 1 assignment
/32: 3 assignments

Number of /48 PI assignements per organisations:
1 /48: 2896 organisations
2 /48: 123 organisations
3 /48: 28 organisations
4 /48: 15 organisations
5 /48: 5 organisations
6 /48: 5 organisations
7 /48: 4 organisations
12 /48: 1 organisation

This can't account for the number of end users who didn't choose to go with one /48 IPv6 PI per site, i.e. by leasing IPv6 (disaggregating PA space) instead or were deterred from IPv6 deployment at all. Enterprises, which stand to benefit from a policy change, are still lagging the furthest behind with IPv6 deployment, according to Paolo Volpato's presentation in the IPv6 WG.

As Gert described, renumbering is hard. I believe we shouldn't needlessly prevent any aggregation from occurring in the future, i.e. when an end-user with multiple sites adds transport links between their sites or other future changes of plans, they should be able to aggregate.

I support the proposal to promote aggregation as a BCOP. Please keep in mind that a single disaggregated /29 PA from any LIR could octuple the size of the global routing table; we shouldn't judge end-users abilities to keep the size of the global routing down any worse than those of LIR, which could cause significantly more harm.

>From a conservation perspective, rounding up the additional bits to the next aggregate block is hardly relevant, especially compared to the generous IPv6 PA allocations to LIR. Currently, each standard /48 PI assignment has a reserved size of /46 in the pool; allowing for non-bureaucratic extensions instead of additional /48 PI assignments for additional sites is therefore more conservative than the status quo in the current model. The fact that the already reserved /46 can satisfy the needs of over 90% of the end-users with more than one /48 PI assignment per organisation, as per my analysis, fits in nicely with this proposal.

Neither I nor any entity I am currently representing is interested in obtaining larger IPv6 PI assignments at the moment. Thus, I believe I am in no conflict of interest.

Best regards

Maximilian Emig

On Sunday, May 22, 2022 20:59 CEST, Maximilian Wilhelm <max at rfc2324.org> wrote:
 Anno domini 2022 Gert Doering scripsit:

Hey folks,

> I announced too many weeks ago that a small group was looking into the
> IPv6 policy, as it is today, why it is what it is, and whether the
> underlying assumptions that the policy is based on are still valid.
[...]
> We'll present about this next week, picking some points as starting
> points for "shall we do something here? if yes, what? and who?" -
> but this is not about *me*, but about the commounity - *you*. Anyone
> is free and welcome to start a discussion and work on aspects we brought
> up - or on other aspects.

Thanks for this and the work you put into it! I also believe some
parts of the policies need some review and overhaul, and I think you
identified a lot of details to think about. I'll try go provide a
brain dump of some topics which resonated with me and which I ran into
in the past with one of my different hats.

First and foremoest, I agree with the observation that IPv6 PI space
is a complicated beast and I still remember my last attempt at making
it more usuable so people don't have to lie about there use cases. I
fully agree with Jan's statement at the mic that we should look into
this again and like Gert's suggestion to just drop the "3rd party
clause" of the PI policy. In *this* case the marked might really have
solved the issue and I'd be confident the issue of ISPs only giving out
one IP per subscriber won't arise as those offers will be laughted at.

Another commonly observed obstacle with IPv6 PI has been getting more
than one /48, which also has been brought up by Max (not me :)), which
I also fully agree with. If a network has a number of sites today and
qualifies for n * /48 prefixes and in the foreseeable future might be
able to conntect those sites (by means of DF, waves, or whatever), it
does make a lot of sense to provide this organization with the
aggregate for ceil(n * /48). Even if the sites don't end up being
interconnected there's not much difference in prefix size and routing
table usage, but less hassle for all parties involved.

As a customer I recently ran into the issue that an IP access business
connection came with an IPv4 /29 out of the box but no IPv6
whatsoever, not even a /64 on-link which would have totally sufficed
for the use case. To get a /56 available on that link, it needed to be
booked for 30€ MRC on top of the existing monthly fee, which isn't
very 2020. Private customers obviously get IPv6 by default as DS-lite
is used to serve their IPv4 traffic. Tackling business practices
isn't really within our scope, but maybe we can have this in mind when
updating BCOP documents, to "motivate" ISPs to diverge from such
practices, which certainly do not help furthering IPv6 deployment.

Cheers,
Max
--
Friends are relatives you make for yourself.

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20220606/a3d50118/attachment.html>