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

On 6/1/21 12:13, Philip Homburg wrote:
>>> In my opinion we should leave scope the way it is.
>>
>> The current definition of global scope as per RFC4007 doesn't match the
>> definition of ULAs as being global scope. Both of them can't be right.
> 
> Some things don't need fixing even if they are not 100% correct.

There's an architecture document, and a spec that doesn't follow it.

That's a bug. I don't know if that means 45% correct or 95.4% correct. 
But it does mean that we have defined terms, and that we don't use them 
in a consistent manner.

If we expect people to read our specs, and make sense out of them, we 
have fix them if we find issues.

And, as noted, there are concrete implications:
RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and 
a Python library says ULAs are non-global. I don't think we want that.



>> "scope" and "zone" are part of the architecture. So we have a IPv6
>> Scoped Addressing Architecture, and then a definition ULAs that doesn't
>> really comply with that definition.
> 
> Effectively we have only two scopes: link-local and 'other'. What we need to
> do is simply things, not create a bigger mess.
> 
> We don't need zone IDs that try to identify the scope of a ULA. All of this
> was part of attempts to define local addresses. It didn't work.
> 
> We need to redefine zone IDs as interface IDs and clean up a lot of that
> stuff.

You mean use interface IDs as zone IDs?



>> Changing the formal scope of ULAs does change the expectation when it
>> comes to their usage: i.e., ULAs are not expected to be globally unique.
>> They are just expected to have small chances of collision if you
>> connected a limited number of ULA-based networks.
> 
> Networks don't just connect by themselves. Networks admins who connect two
> networks are not going the read RFC 4007 and conclude from the definition of
> scope that is safe to connect the networks.

It must be clear what ULAs are, and what they are not. Part of that is 
acknowledging that their scope is not global.



[...]
>> Besides, this does have an impact on current libraries (such as Python's
>> ipaddress) and other libraries or macros that may have been defined for
>> other languages, or that may be defined in the future.
> 
> The IETF does not define APIs for Python libraries, so I don't see why we would
> need to change the scope of ULA to accomodate them.

You seem to be missing my original point:
The definition of ULAs as "global scope" contradicts the definition of 
"global scope" from RFC4007.

We don't need to change the scope of ULAs to accommodate them. We need 
to change the scope of ULAs such that we don't have specs that 
contradict with each other (consistency). Most likely, when we have 
that, we'll end up accommodating the Python library as a side effect.
They got it right, and we didn't.



> We could call ULA 'private' if that would help python devs. But they can just
> well call ULA 'private' without involving the IETF.

So.. from the pov of RFC4007 ULAs are non-global.
 From the pov of RFC4193 ULAs are global.

... and you don't mean to fix that, but still expect devolopers from 
multiple languages to get that right, and programmers to make sense out 
of the outcome?



>> This in turn probably affects the use such apps make of a list of
>> addresses, when more than one is available.
> 
> Applications should not do widely different things if they encouter a ULA.
> 
> We have policy tables for source and destination address selection. Those
> should be used to decide what to do.

That's a "one size fits all". There are valid reasons for which you 
mihgt *not* want to do that, (including using ULAs for services that are 
expected to be local-only, not binding temporary addresses to listening 
sockets, etc., etc., etc.)



>> The problem is that for ULAs to be marked as "non-global" (whatever we
>> call that), RFC4291 needs to be updated. Also, at least a part of
>> RFC4193 needs to be updated.
> 
> They don't need to be marked 'non-global'. Changing the scope of ULA serves
> no purpose.

So what we do here is specifying protocols, and you argue that fixing 
inconsistencies when specs have conflicting definitions and usages serve 
no purpose?

Me, that's the least I'd expect from us....


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