Re: [EXTERNAL] 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, Bert,

On 6/1/21 02:53, Manfredi (US), Albert E wrote:
> Hi Fernando, let's follow the KISS principle.

KISS *and* real, please ;-)



> -----Original Message----- From: Fernando Gont
> <[e-mail]>
> 
>> RFC4193 does not mandate a specific algorithm, but rather specified
>> the
> requirements for the PRNG (good for the RFC4193 authors!). So, 
> documenting the seed will serve no purpose, because other 
> implementations might use a completely different algorithm for 
> generating the ULA prefix.
> 
> Within an enterprise, the admin has a choice of which PRNG to use,
> and what seed to use. Think in terms of one guy, making that
> decision, and then documenting all the Global ID 40-bit sequences in
> use, in the various nets of the enterprise. The guy with this
> responsibility can certainly decide on which algorithm to use!
> 
> It is easy enough to guarantee uniqueness, in this case.

Please do the math.

Being able to connect a few networks together does not mean the addreses
are unique. You can't normally connect  several 10.0.0.0/8 nets, too.

Global-scope, as per RFC4007 would imply that *the ULA prefixes are
globally unique*. *All, at the same time*.




>> An this one is obviously non-enforceable, for multiple reasons,
> including the fact that RFC4193 doesn't mandate any specific
> algorithm.
> 
> I am the enterprise admin, I'm tasked with administering the ULAs for
> the enterprise, and I enforce the rule. The admin of one enterprise
> network has no say in what other admins, of other enterprise
> networks, want to do. Nor is there any requirement for ULAs of
> different enterprise nets to be mutually unique.

Indeed, "global scope" would imply exactly that. Please check my I-D, 
which quotes the relevant text from RFC4193.



>> I don't think anybody has equated ULAs with link-locals. The
>> argument
> has been, instead, that: scope(link-local) < scope(ULA) < scope(GUA)
> 
> Something like "single administrative domain scope," if that existed,
> makes sense to me. I think the problem is that today, it's either
> link local or global scope?

Exactly!  ULAs are not link-local, but not "global", either. They have a 
scope that lies somewhere in between link-local and global.

In my I-D, I called the ULA scope "local", but I don't mind changing 
that to "single administrative domain scope", "private scope", or 
anything else.

The point is, indeed, that ULAs are currently defined as global. BUt 
they are not -- their scope is certainly smaller than global.




>> In a way, the expectation of ULAs to be global-scope is probably
>> what
> drove the recent discussion on the 6man list about a ULA registry --
> 
> To me, that's a different discussion. That registry idea would
> probably be a necessity, but only for the fc00::/8 ULAs, which are
> for future use. When ULAs are not assigned by an individual admin,
> the problem of uniqueness is different, no? 

Indeed. When they are not centrally assigned, or not assigned by the 
same admin, you cannot expect them to be unique across different 
administrative domains. You can expect the probability of collisions 
*when interconnecting a reduced number of ULA-based networks* to be 
small.  But you can certainly not expect the ULA prefixes to be unique 
at a global scale. when you consider ~1M networks (not a big deal if you 
e.g. expect that each home will generate a ULA prefix) you actually have 
almost certainty that there's a collision.



> To me, that registry
> problem is a non-issue, unless and until we start using the fc00::/8
> addresses. As of now, only fd00::/8 are being discussed.

To me, it's also a non issue. But it looks like the proposal for a 
registry has been motivated by the expectation of ULAs being *globally 
unique* (as opposed to "unlikely to collide if you interconnect a 
handful of ULA-based networks").

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