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
signature.asc
Description: PGP signature
----- 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/
