<html>Good morning,<br /><br />thanks Max :) and of course Gert for the effort and the excellent presentation; I fully agree with the goals you described.<br /><br />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.<br /><br />To get a better understanding of the impact of the current policy, I've done some analysis on the state of IPv6 PI assignments:<br /><br />Number of IPv6 PI assignments per prefix length:<br />/48: 3381 assignments<br />/47: 40 assignments<br />/46: 15 assignments<br />/45: 7 assignments<br />/44: 2 assignments<br />/42: 1 assignment<br />/40: 1 assignment<br />/32: 3 assignments<br /><br />Number of /48 PI assignements per organisations:<br />1 /48: 2896 organisations<br />2 /48: 123 organisations<br />3 /48: 28 organisations<br />4 /48: 15 organisations<br />5 /48: 5 organisations<br />6 /48: 5 organisations<br />7 /48: 4 organisations<br />12 /48: 1 organisation<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />Best regards<br /><br />Maximilian Emig<br /><br />On Sunday, May 22, 2022 20:59 CEST, Maximilian Wilhelm <max@rfc2324.org> wrote:<br /> <blockquote type="cite" cite="20220522185904.GH1092@principal.rfc2324.org">Anno domini 2022 Gert Doering scripsit:<br /><br />Hey folks,<br /><br />> I announced too many weeks ago that a small group was looking into the<br />> IPv6 policy, as it is today, why it is what it is, and whether the<br />> underlying assumptions that the policy is based on are still valid.<br />[...]<br />> We'll present about this next week, picking some points as starting<br />> points for "shall we do something here? if yes, what? and who?" -<br />> but this is not about *me*, but about the commounity - *you*. Anyone<br />> is free and welcome to start a discussion and work on aspects we brought<br />> up - or on other aspects.<br /><br />Thanks for this and the work you put into it! I also believe some<br />parts of the policies need some review and overhaul, and I think you<br />identified a lot of details to think about. I'll try go provide a<br />brain dump of some topics which resonated with me and which I ran into<br />in the past with one of my different hats.<br /><br />First and foremoest, I agree with the observation that IPv6 PI space<br />is a complicated beast and I still remember my last attempt at making<br />it more usuable so people don't have to lie about there use cases. I<br />fully agree with Jan's statement at the mic that we should look into<br />this again and like Gert's suggestion to just drop the "3rd party<br />clause" of the PI policy. In *this* case the marked might really have<br />solved the issue and I'd be confident the issue of ISPs only giving out<br />one IP per subscriber won't arise as those offers will be laughted at.<br /><br />Another commonly observed obstacle with IPv6 PI has been getting more<br />than one /48, which also has been brought up by Max (not me :)), which<br />I also fully agree with. If a network has a number of sites today and<br />qualifies for n * /48 prefixes and in the foreseeable future might be<br />able to conntect those sites (by means of DF, waves, or whatever), it<br />does make a lot of sense to provide this organization with the<br />aggregate for ceil(n * /48). Even if the sites don't end up being<br />interconnected there's not much difference in prefix size and routing<br />table usage, but less hassle for all parties involved.<br /><br />As a customer I recently ran into the issue that an IP access business<br />connection came with an IPv4 /29 out of the box but no IPv6<br />whatsoever, not even a /64 on-link which would have totally sufficed<br />for the use case. To get a /56 available on that link, it needed to be<br />booked for 30€ MRC on top of the existing monthly fee, which isn't<br />very 2020. Private customers obviously get IPv6 by default as DS-lite<br />is used to serve their IPv4 traffic. Tackling business practices<br />isn't really within our scope, but maybe we can have this in mind when<br />updating BCOP documents, to "motivate" ISPs to diverge from such<br />practices, which certainly do not help furthering IPv6 deployment.<br /><br />Cheers,<br />Max<br />--<br />Friends are relatives you make for yourself.<br /><br />--<br /><br />To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg</blockquote><br /><br /> </html>