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

[Philip Homburg <[e-mail]>]

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

RFC 4007 does not mention ULA. I don't see why python libraries are
relevant for what we do.

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

No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface IDs
to select the interface of an outgoing packet, whether link-local or global.

It doesn't change anything in practice, because that is what existing code
does.

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

ULAs are not link-local addressses. That's the only thing we need to know.

Yes, we could update the definition of global scope in RFC 4007 such that
ULAs are included, but it strikes me as a waste of time. Unless, we are doing
a bis document.

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

Like I said, the definition of global scope in RFC 4007 can be fixed if we
would care enough. 

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

Developers should not use scope to mean anything. Maybe some applications
need to do something special when they encouter certain addresses. In that
case they can directly list the prefixes that need special treatment.

There is no need to come up with convoluted library schemes that try to
classify addresses. That only causes operational nightmares.

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

Do you propose to introduce new scopes for temporary addresses?

The I-D we are discussion doesn't describe these issues in the problem
statement.

Maybe you want to go back to the problem statement and describe what you
really want to solve.