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

[Fernando Gont]

Estimades,

Si alguno se pone a leer RFCs de IPv6, y no entiende una m[beeeeep!], 
tal vez puedan darse una idea de porqué.


-------- Forwarded Message --------
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: 
New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
Date: Wed, 6 Jan 2021 13:36:10 -0300
From: Fernando Gont <fgont at si6networks.com>
To: Philip Homburg <pch-ipv6-ietf-7 at u-1.phicoh.com>, ipv6 at ietf.org
CC: IPv6 Operations <v6ops at ietf.org>

On 6/1/21 13:13, Philip Homburg wrote:
>> 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. 

RFC4007 defines what "scope" and "global scope" are.

RFC4193 defines ULAs to be global scope.

But ULAs (defined in RFC4193 as global scope) contradict the definition 
of global scope from RFC4007.

Hence the connection between the two.




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

At the end of the day, when you do that, the interface is being employed 
as the zone ID.



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

*That is not how they are specified in RFC4193*!



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

It's the definition of ULAs as global scope that is incorrect. NOt the 
other way around.



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

Applications should deal with prefixes. If anything, they should deal 
with address properties.



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

You get operational nightmares when you get multi-scoped addresses and 
you have no clue about the differences and what to do with them.

Crawl Alexa's Top-1M sites, and look at the IPv6 addresses. You find 
anything from loopback, to unspecified address, to link-locals, and ULAs.




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

Huh?

I'm saying:
"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.)"

that is: given a bunch of addresses with different properties, most 
likely applications do need to look at their properties to make 
appropriate use for them.

We're talking about the ULA scope being in contradiction with the 
"global scope definition".




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

Problem #1:
The IETF publishes protocol specifications.
We have two protocol specifications that contradict each other.

Someone that reads both RFC4007 and RFC4193 will have an interesting WTH 
moments. For the rest of the stuff, I said it already. THere's no point 
in re-hashing the same arguments over and over again.



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

---- cut here ----
5.1.  Address Attributes in Programming Languages

    Python's ipaddress library [Python-ipaddr] defines 'IPv6Address'
    objects that have a number of attributes, including:

    o  'True' if the address is allocated for private networks.

    o  'True' if the address is allocated for public networks.

    For ULAs, the is_private attribute is 'True', while the is_global
    attribute is 'False'.  This contradicts the definition of ULAs as
    having "global scope" [RFC4291] [RFC4193], but is in line with the
    specification update performed by this document (see Section 6).
---- cut here ----

This will be faced by every other library or macro in every other language.


---- cut here ----
6.  Specification Updates

    The ultimate goal is to employ coherent terminology and definitions
    throughout the relevant protocol specifications.  Probably the only
    option to achieve this goal is update the definition of ULAs as
    having "local scope", with "local scope" defined as "larger than
    link-local, and smaller than global" (based on ULAs being defined as
    "local addresses").
---- cut here ----

The least we can aim at is consistency among our own specs, right?


... and one should also add to the list "a clarification of the 
expectations regarding ULAs. Because many (including myself in the very 
recent past) had the assumption that ULAs are globally-unique, when they 
are not.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492