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

[Fernando Gont <[e-mail]>]

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.


Regarding #2:
Modulo the above, for the most part non-global addresses *are* 
ambiguous. So this is kind of a feature.


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.

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.




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



> 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!
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492