Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt

[Brian E Carpenter <[e-mail]>]

There's now a better version of my diagrams at https://www.cs.auckland.ac.nz/~brian/scope6.pdf

Regards
   Brian

On 25-Dec-20 11:15, Brian E Carpenter wrote:
> Hi Fernando,
> 
> On 24-Dec-20 18:50, Fernando Gont wrote:
>> Hello, Brian,
>>
>> Thanks for your comments! In-line....
>>
>> On 20/12/20 01:44, Brian E Carpenter wrote:
>> [....]
>>>
>>>> 3.1.  Legacy Specifications and Schemes
>>>
>>> I don't think that section is complete without mentioning site-local 
>>> and why it was scrapped (RFC3879).
>>
>> Will do.
>>
>> Comment/question (since I wasn't participating in 6man when RFC3879 was 
>> published, and I've never used site-locals myself):
>>
>>
>> There seem to be two main issues with site-locals:
>>
>> 1) use of the zone index ("%___")
>>
>> 2) "ambiguitiy" of the addresses.
>>
>>
>> Regarding #1:
>> My understanding is that site-locals where expected to be used with a 
>> zone index (as we normally do for e.g. link-locals) in the case the same 
>> prefix is employed on two different networks.
>>
>> Now, my question is: why do this in the first place? What I would expect 
>> is that you simply use the address. Then, if the same node attaches to 
>> two networks that employ the same prefix, that's a configuration 
>> problem. Period. *If* in such scenario, *and for debugging purposes* you 
>> want to be able to specify which interface to use to send packets to a 
>> site-local address (that looks like "on-link" on two different 
>> interfaces), then you use the zone index -- but that's for *debugging* 
>> purposes, since having two subnets employ the same site-local prefix 
>> would be an error.
> 
> If you read RFC4007 you will *not* find that a zone index is formally
> equated to an interface index. The "zone" terminology is confusing since
> it did originally assume a nested scope model, link-local inside site-local
> inside global. By some magic the host was supposed to understand enough
> of the network topology to use a single value "zone index" to capture
> the topology and tell the drivers which interface to use. See diagrams
> at https://sites.google.com/site/bcabrc/miscellany . 
> Slides 3 and 4 show scenarios that simply can't be captured
> by a one-dimensional zone index. In practice, of course, the zone index
> is only meaningful within the host. So the whole concept of a zone
> index for nested scopes was a mistake. With hindsight, we should
> have cleaned that up more definitively in RFC4007.
> 
> (And this problem is still a problem:
> https://bugzilla.mozilla.org/show_bug.cgi?id=700999 was opened
> 9 years ago and still gets traffic despite being formally "closed"
> 5 years ago.)
> 
>> Regarding #2:
>> Modulo the above, for the most part non-global addresses *are* 
>> ambiguous. So this is kind of a feature.
> 
> Yes, but not a *good* feature since it leads to the problems
> in my slides 3 and 4.
>  
>> With the minor consideration in #1, site-locals do not seem to be a lot 
>> different than ULAs. -- Yes, you are supposed to randomize the ULA 
>> prefix ( which I don't when using them in labs, since I don't want 
>> ugly-looking addresses :-) ).. but you might also argue than when using 
>> site-locals you better made sure that you didn't  employ the same 
>> site-local prefix in to interconnected networks, anyway.
> 
> But the design didn't provide for that, whereas the ULA design does
> (and no, using pretty ULA prefixes is not OK).
> 
> RFC3513 was seriously broken, because it suggests using "the same
> subnet IDs for site-local and global prefixes", which doesn't
> make much sense and certainly doesn't provide a high probability
> of uniqueness.
> 
>>
>> Am I missing something?
>>
>>
>>
>>
>>>> 3.2.  Unique Local IPv6 Unicast Addresses (ULAs)
>>> ...
>>>> However, the only reasons for which these addresses are considered 
>>>> to have "global scope" are:
>>>>
>>>> o  given two different networks that employ ULAs, it's unlikely 
>>>> that they will employ the same ULA prefix
>>>
>>> Not at all. The reason they formally have global scope is because 
>>> when site-local was scrapped (as being meaningless and unenforcable, 
>>> see RFC3879), only two scopes were left: link-local and global.
>>> There was no other choice.
>>
>> Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of 
>> "ipv6 is all about the global addresses", mimicking IPv4's private 
>> addresses probably wasn't "sexy", but IMO the concept is useful, and 
>> well understood.
> 
> I think that adds confusion. They are only private because of the
> requirement to block them in border routers; it's not a property
> of the address itself. (Thumbs down to the Python ipaddress module
> by the way, which has invented an "is_private" property and gets
> "is_global" wrong for ULAs.)
> 
>>> What that means is that protocols treat
>>> them *exactly the same* as RIR-assigned prefixes. That applies to
>>> all protocols: ND, RA, DHCPv6, and every routing protocol. They are
>>> only treated differently by policy, such as address selection policy
>>> or boundary router policy. 
>>
>> Wouldn't this also be the case if they were redefined as "IPv6 private 
>> address space"?  i.e., from the point of routing, modulo the link-local 
>> prefixes, you simply have prefixes that you distribute information 
>> about.  i.e. "Private address space" (i.e., non-global) shouldn't be 
>> treated differently by routing protocols.
> 
> It's true, but that's what the "global" property means, and it's different
> from "globally reachable". It's not ideal terminology, of course, since the
> design process had a false start with "site-local".
> 
> Happy holidays!
> 
>      Brian
>>
>>
>>
>>> And, if you like, the pseudo-random
>>> prefix assignment mechanism is also a policy, by making prefix
>>> collision highly unlikely. ULA-C would be a different policy, by
>>> making prefix registration compulsory.
>>
>> Comment/question (rather than "objection"): since the "scope" is
>> essentially defined as the region of the network topology where an
>> address is meaningful, it would seem to me that claiming "ULAs" are
>> global-scope is at odds with the fact that ULAs prefixes are
>> locally-generated.
>>
>> Put another way: when you analyze what "scope" means, ULAs really have 
>> nothing of "global scope". ULAs are not centrally managed, and as such 
>> are ambiguous.
>>
>> (I guess you could argue that ULA-C could be global for some meaning of 
>> the concept. But then I don't see much of a point for such a thing. -- 
>> just use global addresses, and filter where appropriate.)
>>
>>
>>
>>>> o  the ULA address block formally belongs to the Global Unicast 
>>>> Address (GUA) address block
>>> ...
>>>> The ULA address block has been carved out of the GUA address 
>>>> block,
>>>
>>> This statement seems misleading to me. GUA is not actually defined 
>>> very well in RFC4291. True, the table in section 2.4 says "Global 
>>> Unicast (everything else)" and none of the formal updates to RFC4291 
>>> change that.
>>
>> Yes, that was my rationale.
>>
>>
>>
>>> But the choice of fc00::/7 by RFC4193 makes it clear 
>>> that these are not normal GUAs; by definition they are not assigned 
>>> by the RIRs or announced on the public Internet. They are listed in 
>>> the IANA Special-Purpose IP Address registry and discussed
>>> explicitly in RFC8190, so the claim that they are part of the GUA
>>> block seems very dubious.
>>
>> FWIW, I think that RFC4193 should have formally updated RFC4291 (or, 
>> well, since probably they were published together, RFC4291 could have 
>> marked the ULA space in the addressing architecture, and point to 
>> RFC4193 for further details).
>>
>> BTW, there are no macros that would distinguish ULAs them from regular 
>> global addresses: https://tools.ietf.org/html/rfc2553#section-6.7
>>
>>
>>
>>
>>> (I think it's a bug in RFC4193 that it didn't make an update to 
>>> RFC3513, the predecessor of RFC4291, which actually foresaw such a 
>>> case: "Future specifications may redefine one or more sub-ranges of 
>>> the global unicast space for other purposes, but unless and until 
>>> that happens, implementations must treat all addresses that do not 
>>> start with any of the above-listed prefixes as global unicast 
>>> addresses.")
>>
>> Ok, it looks like we are on the same page. :-)
>>
>>
>>
>>
>>>> Therefore, ULAs are not globally meaningful and thus, for most (if
>>>>  not all) practical purposes, ULAs can be considered to have non- 
>>>> global scope.  For this reason, ULAs are treated as non-global 
>>>> scope addresses, even when from a specifications point of view
>>>> they have global scope.
>>>
>>> I don't accept that. I believe we've had that discussion and the 
>>> consensus is in RFC8190 and the IANA registry already.
>>
>> Sorry: what we *meant* here is that, throughout our document, when we 
>> refer to "non-global addresses" we are also thinking about ULAs.
>>
>> (e.g., the "possible isolation provided by the address scope" applies 
>> (to different degrees) to both e.g. link-locals and ULAs...)
>>
>>
>>
>>
>>> Later in the draft you say:
>>>
>>>> In the same light, a ULA prefix generated by a local router will 
>>>> be, by definition, provider independent.  However, a router might 
>>>> also be leased an ULA sub- prefix from its upstream, in which case 
>>>> this prefix would be "provider dependent".
>>>
>>> Exactly. This illustrates that as far as protocols go, ULA prefixes 
>>> behave exactly like RIR-assigned prefixes.
>>
>> Couldn't one also argue that ULAs are, e.g., "IPv6 private address 
>> space" and that, as with the RFC1918 space,  no special provisions are 
>> needed in routing protocols -- other than one filtering prefixes 
>> when/where deemed appropriate?
>>
>>
>>
>>> They are global in 
>>> protocol terms, but not globally routed in operational terms. These 
>>> are orthogonal properties.
>>
>> Sorry for insisting on this one -- I'm bringing up this issues because I 
>> found myself trying to provide an explanation for "global in protocol 
>> terms", without a lot of success. :-)
>>
>> It would seem to me that virtually every use of "global" for ULAs 
>> (modulo ULA-C, I guess) is, conceptually speaking, kind of cumbersome 
>> and incorrect. -- and creates expectations that, at the end of the day, 
>> are probably not going to be fulfilled.
>>
>> Wouldn't the most natural thing be to flag ULAs as "IPv6 Private Address 
>> Space", where e.g. from the point of view of protocols, the same 
>> considerations as for RFC1918 apply (no, I wouldn't *say* this in a 
>> spec), and we simply have the additional feature in the spec that we 
>> recommend how to generate the ULAs prefixes to avoid possible hassles 
>> when merging two different networks?
>>
>> Or, to put in a different way: RFC1918 is private address space, and we 
>> don't need to call it "global" in any way to flag the fact that 
>> addresses from that private address space are not treated in any special 
>> way by e.g. routing protocols     -- for instance, why should they?
>>
>>
>> Thanks!
>>
>> Regards, and Merry Christmas!
>>