Hi, On Tue, Sep 17, 2024 at 01:23:00AM -0700, Leo Vegoda wrote:
We are extending the Discussion Phase for 2024-01 (Revised IPv6 PI Assignment Policy) until 22 November 2024.
So. Apologies for taking until the very last moment to send my full feedback. It *is* a long proposal, and has a long list of changes, some of them look like "intentional" and some of them might or might not be "unintended consequences". Part of the problem is that it mixes intentional changes (Nibbles and Aggregation) with clarification, and at that, adds lots of text which do not serve the clarification purpose. This makes it very hard to come to a clear statement of support or objection (short summary to save you a long read: I do object to the proposal in this form). I do support the goal of clarifying the PI use-cases, and I do support the intended "newly permitted use cases". I am a bit sceptical on the nibbles, and I disagree with the goal of "aggregation in the database" (the DB does not care). This has side effects, which might or might not be intentional - as proposed, it does make IPv6 PI a lot less attractive for coroporate use ("we have these 15 locations all over germany, each using an IPv6 /48 PI, now we open two new locations, ask for 2x extra /48 PI, and have to renumber all the other 15, really?"). So if we want this, it should be very clear that this is a desirable outcome, and should be stated as such in the rationale. I also disagree with the rationale given that "aggregated assignment from the NCC" will do anything useful for *routing table* size - it's PI, after all, and the implied intent of requesting a separate /48 for each location is that "each location is independent", so I do not see why these would then be announced as a, say, /44. So, going through the proposal in detail Section 2.6 My understanding is that this is what will address one of the more immediate problems, namely, clear guidance on what can be done with PI space and not. This takes into account recent developments in IPv6 technology (DHCP PD to devices). I support this. The wording of the new paragraph 3 ((sub-)assignments within the same organization) is what I'd consider "too much text", though - "within your organization" should not need explicit spelling out, as that's always the purpose of assignments "use within the receiving org". Maybe reword to make the intent more clear - e.g. "Providing Internet connectivity to off-site entities using IPv6 PI is strictly disallowed". (If written that way, one could possibly even reduce paragraph 2 + 3 to a single thing "Usage is only permitted within the same end site, but not restricted to equipment owned by the PI holder. Using IPv6 PI for p2p links to other entities is permitted, as long as the purpose is not sole Internet transit using PI space"). Section 2.9 This is, effectively, duplicating the definition of "end site", once for assignments out of PA space, and once for PI space. This is one of the points I am unhappy with. "End site" *should* be a definition that is applicable to both PI and PA assignments - and I agree that it might have different strings attached ("for the purpose of PA assignment, end sites are expected to use transit connectivity and be aggregated (and so on)" - though the aggregation & transit part is not enforced, and sufficient deaggregation garbage in the GRT is proof of that... Maybe we should kick "end site" completely, as it has never been really well defined (we inherited this from IETF, and they have no good definition either). Besides this more generic unhappiness with the proposed new text, there is also inherent inconsistencies - it says "... and has a different routing policy...", while other parts of the proposal aim for aggregation. Now what? ;-) Also, please get rid of "Layer 2". This is too specific, and at the same time, totally unclear - "so if I have a dark fiber, which is Layer 1, this is then not considered a Layer 2 connection"? Or "I buy a routed interconnection service (L3 VPN) to interconnect my sites transparently, this is fine, then"? I can see what this is aiming for ("tightly coupled sites, effectively forming a joint network") - but "a network connection between two End Sites does not make them one..." should do the job. One thing that is new here (and not just clarification) is the requirement that PI receiving end sites must be "in the NCC service region". I just wanted to point this out, which might cause annoyance for entities that have 5 offices in the NCC service region and 1 in the ARIN region - and thus would have to deal with two LIRs now. Is that what we *want*? If yes, it should be clearly stated. Section 5.4 This basically clarifies that these guidelines only apply to IPv6 PA assignments - which is a useful clarification, given that IPv6 PI has its own set of rules (which might be seen as contradictionary). This is a good and useful change :-) Section 7.1 This is lots of text... part of it is clarification of the original intent (new 7.1), part of it is new (7.1.1 "Nibbles", and 7.1.2 "increasing the aggregated PI block" and 7.1.3). In the new 7.1, I'm mostly fine with the new text, though I'd not bother to spend text on "special purpose PI" in *here* - the whole point of "special purpose" is "not the standard thing", so defining rules for those in the relevant documents should be just fine (and less text). On the nibbles in 7.1.1, I do not agree with the argument "for aggregation", neither routing wise nor registry wise. PI, by the very definition of "independent end sites with independent routing policy", is not expected to show up in an aggregated way - so it's not clear what this is trying to achive. Also, as written, this will create pain later to IPv6 PI holders - so, you have a company that has 4 different branches, with different offices and all, and decide to number them with IPv6 PI, a /48 each. Now you sell off one of these branches (because that's what businesses do) - according to the new 7.1.1, they would not be able to take their PI space with them. Is that intended? I won't object to it ("it makes PI less attractive"), but it should state so, very clearly. 7.1.2 has the a similar consequence - if an enterprise has a /44 for 15 "branch sites" today, and wants to open 2 extra locations somewhere, they would qualify for a /40, but if this is not available, all 15 existing sites would have to renumber, which is quite a detriment to "deploy IPv6 in these 2 new locations". Is this intended? 7.1.3 has the same problem. So, I do not care much about nibbles either way (7.1.1) but I do care about incentivizing networks to use IPv6 - and the implied threat here "if you grow in number of locations, there will be a sudden jump cost for your IPv6 deployment" is not a message we should send. Offering "well, the renumbering period can basically be stretched forever if you say 'please' every 12 month" will not cause less work for the NCC either... The argument "PI networks are relatively small, so renumbering is easier" is, uh, not something I'd sign. After all a /48 has 65000 subnets in it... so you can easily number a fairly large campus with *lots* of subnets and an even higher amount of machines with a single IPv6 PI network. So this might be a valid point for an enthusiast deployment ("personal ASN") with a few subnets and a few tens of machines, but the policy needs to work for all kinds of PI holders. What I am missing in the whole 7.1 discussion is how the NCC is expected to evaluate the number of "things" for application of the charging scheme - so is the intent to permit arbitrary numbers of PI assignments (up to a /36 in total = 4096 /48s), counted as "one PI", being charged just once? If yes, this would be something I'd also oppose - the "one fee *per unit* per year" charging was introduced to make PI somewhat less attractive, and incentivize returning of resources no longer needed. Given that each PI prefix in the global table has a cost to everyone, this is a principle we should stick to. (Yes, PA deaggregations exist as well, but this is not a justification for anything). For these reasons, I do not support the proposal "as written" today. I would suggest to split off the "what is allowed and what not" clarification into a smaller proposal, which would solves a clear problem (as Benedikt Neuffer has stated) and is likely to move ahead quicker, and reconsider the goals and consequences of the aggregation approach separately. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279