On 01-Oct-20 03:14, Eric Vyncke (evyncke) wrote: > About ULA, why not simply keeping: > > " ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 > address in the block fc00::/7, defined in [RFC4193]." > > And nothing else of the existing paragraph. IMHO, there is no need to justify > the choice
Logically, I agree. Frankly it's not optimal to hold up this document for a completely external point. V6OPS couldn't ever reach consensus on draft-ietf-v6ops-ula-usage-considerations so I don't think we should try to do the equivalent here in a single paragraph. (If you want the running code argument it's easy: distributed GRASP applications survive unplanned renumbering of the uplink because they prefer ULAs. Case closed.) Brian > > -éric > > -----Original Message----- > From: Anima <anima-boun...@ietf.org> on behalf of Toerless Eckert > <t...@cs.fau.de> > Date: Wednesday, 30 September 2020 at 15:55 > To: Erik Kline <ek.i...@gmail.com> > Cc: "anima-cha...@ietf.org" <anima-cha...@ietf.org>, > "draft-ietf-anima-autonomic-control-pl...@ietf.org" > <draft-ietf-anima-autonomic-control-pl...@ietf.org>, The IESG > <i...@ietf.org>, "anima@ietf.org" <anima@ietf.org>, Sheng Jiang > <jiangsh...@huawei.com> > Subject: Re: [Anima] Erik Kline's Discuss on > draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT) > > Inline > > On Sun, Sep 27, 2020 at 02:52:17PM -0700, Erik Kline wrote: > > Toerless, > > > > Thanks for taking the time to go through all this. Generally LGTM, but > I > > would like to iterate on the ULA text (nothing major). > > > > > > > > [ section 2 ] > > > > > > > > * "It is the approximate IPv6 counterpart of the IPv4 private > address > > > > ([RFC1918])." > > > > > > > > I understand the intent but I don't think this statement is > complete. I > > > > think we shouldn't let this sentence out into the wild as is > since it > > > could > > > > be read without any context nor even any pretense of interest in > > > nuance. > > > > > > > > May I suggest: > > > > > > > > "It is often thought of as the approximate IPv6 counterpart of > the IPv4 > > > > private address space ([RFC1918]), though it is in fact > meaningfully > > > > different in important and subtle ways [and upon which this > document > > > relies]." > > > > > > Thanks for not trying to talk me out of the comparison, which i > > > successfully > > > used to explain ULA to many customers. Your proposal is a bit too > verbose > > > for > > > the terminoloy section, so it's now: > > > > > > It is often thought of as the approximate IPv6 counterpart of the IPv4 > > > private address (<xref target="RFC1918" format="default"/>). There are > > > important differences though that are beneficial for and exploited by > the > > > ACP, such as the ULA Global ID prefix, which are the first 48-bits of > a ULA > > > address. In this document it is abbreviated as "ULA prefix". > > > > > > > It's a statement of fact that this is how people unfamiliar with this > space > > view this space. It's apparently also a statement of fact that people > are > > still actively being told this. ;-) > > > > But I still think it's not quite right. For one, the real counterpart > to > > 1918 in IPv6 is the deprecated site-local prefix. > > > > Also, to say it's "often > > thought of" in an IETF document implies more IETF folks think of this > way, > > when in reality I'm not sure that's the case. > > *cough* *cough* > > |> [ section 2 ] > |> > |> * "It is the approximate IPv6 counterpart of the IPv4 private address > |> ([RFC1918])." > |> ... > |> May I suggest: > |> "It is often thought of as the approximate IPv6 counterpart of the > IPv4 > |> private address space ([RFC1918]), though it is in fact meaningfully > |> different in important and subtle ways ... > > Aka: It is now your text that you would like to see revisited ! > > > If you really want to leave this notion in (removing the sentence > > altogether is good by me), perhaps we can wordsmith it a bit more. If I > > may propose: > > How about: > > ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 > address in the block fc00::/7, defined in [RFC4193]. ULA is the > IPv6 successor of the IPv4 private address space ([RFC1918]). > ULA have important differences over IPv4 private addresses that > are beneficial for and exploited by the ACP, such as the Locally > Assigned Global ID prefix, which are the first 48-bits of a ULA > address [RFC4193 section 3.2.1]. In this document this prefix is > abbreviated as "ULA prefix". > > Successor is hopefully more correct word. Sure, site local prefixes > where a successor too, but i hope i do not have to write > > "ULA is the (only surviving) IPv6 successor..." > > > OLD: > > > > ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 > > address in the block fc00::/7, defined in [RFC4193]. It is often > > thought of as the approximate IPv6 counterpart of the IPv4 private > > address ([RFC1918]). There are important differences though that > > are beneficial for and exploited by the ACP, such as the ULA > > Global ID prefix, which are the first 48-bits of a ULA address. > > In this document it is abbreviated as "ULA prefix". > > > > NEW: > > > > ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 > > address in the block fc00::/7, defined in [RFC4193]. Sometimes > > thought of as the approximate IPv6 counterpart of the IPv4 private > > address ([RFC1918]), there are important differences that are > > beneficial for and exploited by the ACP. In this document, the > > "ULA prefix" refers to Locally Assigned Global ID prefixes, which > > are the first 48-bits of the ULA address [RFC4193 section 3.2.1]. > > Beside the counterpart wordsmithing, > i do not like the removal of pointing out that the ULA prefix is the > new benefit of ULA that we exploit with ACP. That was at the core of the > explanation. > > > (I didn't think it was worth trying to get into the fc00::/8 vs fd00::/8 > > distinction in this glossary text.) > > I agree, but i do not see neither the glossary or the rest of the text > doing that. The spec part just specifies use of fd00:/8 without > discussion and the glossary just uses the ::/7 as thats what rfc4193 say.. > Am i missing something ? > > > > [ section 8.1.3 ] > > > > > > > > * Why is an RIO for ::/0 with a lifetime of 0 required? Doesn't it > > > suffice > > > > it set the default router lifetime to 0? Separately, are all > nodes > > > required > > > > to be Type C? > > > > > > Check the new text, i hope it explains everything. > > > > > > Yes, type A and B do not support per-prefix auto selection of router, > > > The lifetime of 0 is used so only Type C hosts will invalidate the > > > default route for the ACP edge node, but not Type A/B hosts. Maybe > there > > > is another parameter combination that achieves this goal, but this was > > > the easiest for me to assess/describe. > > > > > > > This looks better, thank you. > > > > To be honest, I don't know what the point of Type A/B hosts is anymore > (and > > if it were possible to declare these anima deployments greenfield I > would > > recommend saying the default router lifetime MUST be zero in the RA > header > > to force clients to use a stack that works -- but that's just me). > > I would guess that A and B have been seen in the wild before 4191 was > released and so the RFC was written to be inclusive. No idea. > > I have no idea how prevalent these types are, and the current described > method may be a tiny bit more convoluted but seems to be more compatible. > > Given my deployment experience of enterprises withholding from adopting > new network technology when it wasn't compatible with their oldest > NMS equipment, i am a bit burned in promoting "hard cut" solutions, and > this ben an OPS area draft instead of e.g.: RTG is a good excuse for that > approach ;-)) > > Cheers > Toerless > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
