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

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

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!
>