Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)

[Fernando Gont <[e-mail]>]

Hi, Ted,

On 13/2/21 02:46, Ted Lemon wrote:
> Okay. Consider the clarifications I suggested a while back:

Ok. I will comment on each of them.



> ---
> ULA addresses are, in principle, VALID in any scope.

This begs the question: what's a scope?



> They are not, in principle, UNIQUE to a particular link: it’s entirely 
> possible to have two instances of the same ULA referring to different 
> interfaces connected to different links.

This breaks the definition of scope and global scope from RFC4007.



> In principle, the set of all networks which can route a packet to a 
> particular instance of a ULA /48 MUST be DISJOINT from the set of all 
> networks which can route a packet to some other instance of that ULA /48.

Agreed. But this is at odds with the definition of global scope from 
RFC4007.



> In practice, the randomness of ULAs gives us some reasonable assurance 
> that the principle will hold.

Agreed.



> However, users of ULAs that are routed beyond an individual site had 
> better have some policies and procedures in place to make sure that this 
> is true.
> 
> Internet backbone routers should never accept BGP advertisements for ULA 
> prefixes.

Agreed on both.



> Sites connecting to the Internet should never, by default, route ULAs 
> northbound of their connection to their ISP.

I'd generally agree. But this is somewhat relative and, as Brian noted, 
it boils down to what you define as an administrative domain.

e.g. filtering all ULAs at my CPE router would break part of the 
tracereoute output I normally get, since my ISP employs ULAs in their 
infrastructure.

In any case, even if I wanted to block them, I'd need to treat them 
differently from GUAs.

In cases where you actually DHCPv6-PD ULAs (as I'm told some community 
networks do), it becomes even tricker.

(But yeah, there's probably no debate that, at the very least they 
shouldn't appear in the DMZ. And they also wouldn't survive your ISP if 
you sourced packets from your locally-generated ULAs, since your ISP 
won't have routes for them)

(Probably, all these considerations are exactly the same than for 
RFC1918 space --- which probably tells something).


I guess yet another question would be: If your ISP, for some reason, 
offered you a ULA prefix (along with a GUA prefix), should you also 
propagate it on the LAN-side? (i.e., advertise via SLAAC on the 
LAN-side). I guess you might argue (and I'd agree) that in general, you 
shouldn't. But then again ULAs would be a special case, and trated 
differently from GUAs.



> The last four lines are points of practice, not points of definition of 
> terms.

Agreed.



> But the bottom line is that if the term “global” is confusing as it 
> applies to ULAs, it shouldn’t be that hard to clarify what we mean by 
> global.

This is indeed the point I was trying to make.

I personally think that the definition of "scope" and "global scope" 
from RFC4007 is a good one. And, as per the above, I'm inclined to say 
that the problem is in flagging ULAs as "global scope" (rather than on 
the definition of "global scope" itself).

But, preferences aside, the bottom-line is that as long as it's clear 
what the terminology means, I don't mind a lot what we use.




> Do you think anything I’ve said here is wrong, not in the sense of 
> contradicting RFC 4007, but in the sense that it is incorrect?

The above seems indeed correct.



> I’m not trying to win an argument here—the reason I wrote the above is 
> that I think it’s correct, and I was trying to figure out whether it was 
> in any way consistent with the problem you have.

Indeed, we're on the same page regarding our idea of ULAs -- and 
probably most of us are.

The problems comes from the terminology and definitions that we employ, 
from current RFCs.



> I think Brian has said that the “scoped architecture” is just not how 
> things actually work in real life, with which I agree, so the fact that 
> you can’t explain it to anyone is not a big shock. I think RFC 4007 says 
> some interesting and useful things. It might be worthwhile to write a 
> new document that’s a sort of Talmudic commentary on RFC 4007.

I don't mind that. But that would still leave us with a Proposed 
Standard "IPv6 Scoped Addressing Architecture" (RFC4007) that is at odds 
with other specs (e.g., RFC4291/RFC4193).


> What I do not want to see is some kind of effort to rationalize ULAs 
> into something other than what they are at present, which is quite useful.

I do agree that ULAs are useful, indeed. And the intent is certainly 
*not* to change what ULAs are, but rather to have consistent terminology 
and documents.

Clarifying the terminology would probably also help e.g. direct 
libraries or language macros in how they should consider ULA's attributes.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492