Re: 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, Philip,

On 6/1/21 10:45, Philip Homburg wrote:
[...]
>> While this document does propose a way out (it assumes #3 above, and
>> acts accordingly), I believe the first step is to agree on what "global
>> scope" means and, subsequently, whether ULAs are really "global scope"
>> or not. Since opinions on the topic have vary a lot (as noted above),
>> I've posted this I-D and I'm sending this note for further input from
>> the WG.
> 
> 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.



> Scope has a specific
> meaning for link local. In the past we tried to define local scope similar
> to how link-local scope is defined and it failed.
> 
> 'local' scope is an operational reality. You don't see it at the protocol
> level. So we need to keep it clearly separate from link-local where we do have
> quite a bit of protocol and API specification.

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



[...]
> 
> Of cource with badly chosen ULAs, then chance is higher. But then again, does
> calling ULAs 'local' solve anything?

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.

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.

This in turn probably affects the use such apps make of a list of 
addresses, when more than one is available.



> I don't see an immediate technical problem with ULAs, certainly not one that
> needs to be addressed with a standards track document.
> 
> A practical point that is mentioned in Section 5.1 is what to call ULAs.
> For example, we could call them 'private'. I think there is a need to
> the group of addresses that includes both rfc1918 and ULA. A short
> informational draft that addresses that point could be useful.

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.

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