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

[Brian E Carpenter <[e-mail]>]

Portmanteau reply to multiple messages:

On 06-Jan-21 20:07, Lorenzo Colitti wrote:
...
> So I guess I'm somewhere between 1) and 3). The specs are consistent but they fail to consider human behaviour, so they don't actually work in practice.

I disagree. They work fine in practice.  The smart meter example is a good one. The ANIMA autonomic control plane is another. My TV has a ULA address. I have no idea whether it's used when I control it from my Android phone, because address selection does its job.

The problem is largely theoretical, and educational for people who train IPv4 users in IPv6 terminology and practices. As Fernando has pointed out, the use of the word "global" is confusing for something that has L for "local" in its name.

On 06-Jan-21 20:30, Christopher Morrow wrote:
...
> option 4, deprecate ULA.
> the best option (tm).

I can't see the least argument for that (no proven damage) and very strong arguments against (running code and operational deployments).

On 07-Jan-21 01:17, Ted Lemon wrote:
...
> GUA: “valid everywhere on the internet scope”
> ULA: “not valid everywhere scope”
> LLA: “valid only on this link scope”

Friendly amendment:

GUA: valid everywhere
ULA: Unique Limited-domain Address
LLA: valid only on this link

("scope" is really a noise word, and "Internet" is too restrictive.)

On 07-Jan-21 02:45, Philip Homburg wrote:
...
> '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.

That's why using "scope" is a noise word. It isn't an abstract property. Try to draw it and you get a mess. This really hasn't changed since https://tools.ietf.org/html/rfc3879. Or see https://www.cs.auckland.ac.nz/~brian/scope6.pdf.

On 07-Jan-21 04:13, Philip Homburg wrote:
...
> Some things don't need fixing even if they are not 100% correct.

+1

On 07-Jan-21 04:29, Richard Patterson wrote:
>>     Applications should not do widely different things if they encouter a ULA.
> 
> But they do.
> Some OSes will see the presence of a ULA address on an interface, and start sending AAAA queries, some will not.
> Some applications will see a ULA destination address and simply ignore it, preferring the IPv4 destination address returned. 
> 
> We need to ask the question why this is happening, and if the answer is "They're doing it wrong", great, let's point them at the existing RFCs and educate them, but if not...... we need to do something, and I think this I-D is a good starting point for WG discussion at least.

FYI, we tried 6 years ago, but draft-ietf-v6ops-ula-usage-recommendations stalled.

On 07-Jan-21 05:13, Philip Homburg wrote:
...
>> 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.

Effectively that's what RFC3879 did. RFC4007 was a bit behind the curve. As far as I know, zone IDs and interface IDs are exactly equivalent (at least in POSIX and WinSock environments). IMHO this is *only* a terminology question.

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

Really? Using the interface ID for non-link-local addresses?

On 07-Jan-21 05:26, Gert Doering wrote:
...
> Why should applications, or anything that is not an admin, care if an
> address is a ULA or a GUA?

It depends on what you mean by "application". I've written code that explicitly prefers a ULA, and I could imagine a security spec saying "prefer ULA". But anyway, it's not really a problem, is it? (It's annoying to me that in Python, a ULA has .is_global == False, but I managed to code round that error.)

On 07-Jan-21 06:06, Ted Lemon wrote:
...
>> or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)…
> 
> This implies concentric circles, which isn’t really valid.

It really, really, really isn't valid. That's where we went wrong in 1995. Once the mid-range scopes start to overlap, the concentric circles model fails completely. That's the main reason we scrapped site-local.

On 07-Jan-21 07:04, Ted Lemon wrote:
...
>> There are potentially many GUA (2000::/3) addresses that could be in DNS,
>> which would not work for some originators due to ACLs, and yet a different
>> entry might work just fine.  Why would ULA be any different?
> 
> The usual case here would be through a VPN; in that case the VPN will specify some set of domains that should be resolved through the VPN’s name servers. You really don’t want the ULA advertised globally.

But neither do you want private-use 2000::/3 addresses advertised globally. I really don't see a difference between RIR-assigned and self-assigned (ULA) prefixes in this respect.

Regards
    Brian