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

[Ted Lemon <[e-mail]>]

On Jan 7, 2021, at 4:35 PM, Fernando Gont <[e-mail]> wrote:
> In order for them to have "global scope", they need to be globally unique. And you note that "they are essentially unique, gven an appropriate scope”.

I think the disconnect here is that RFC 4007’s definition of “global scope” clearly contradicts the sense in which ULAs are “global.” So that’s a real problem.

At the same time, the next question to ask is in what sense “global scope” is actionable. People have been talking about zone identifiers as a way to determine scope, but in practice the way we do this is with routing table entries. The reason you have to specify a zone ID for a link-local address is that the route to the link-local prefix is present on all interfaces, but the address is valid on only one interface.

So you specify that interface with the zone ID. I use the term interface loosely here—in principle you could have two interfaces connected to the same link, and that would notionally mean that they both have the same zone ID, but there’s no safe way to make this determination in practice, so in practice the “zone IDs” will always be different.

The same situation does not apply for ULAs. You can (almost) just use routing table entries to deliver ULAs. I say (almost) because of course if you don’t have an explicit route to the ULA prefix, you can’t send the packet. So there’s a tendency to want to send the packet to the default route, but that doesn’t work if you have two interfaces and two default routers. This is why it’s tempting to then use the “zone ID” to resolve this problem. But that doesn’t work, because the host has no way to know which zone ID to use.

So it’s the network’s responsibility to provide enough information that the ULA can be correctly routed. There are two ways to do this that spring to mind:
1. Make assumptions
2. Only send to a ULA if you have a specific non-global route that points to it.
3. Use provisioning domains (https://tools.ietf.org/html/rfc6418)

Option 2 is probably the safest solution. If the route is present on two interfaces, and you have a collision, and not just two valid ways of reaching the same destination, then you will have a problem. This is why ULAs aren’t as fabulous as we might wish. But in practice, it’s entirely safe to do this.

Option 1 could work pretty well, e.g. on a cell phone. Not so well on a host with two network interfaces. It’s unlikely that a ULA is going to work on the global internet, so you never send it on the cellular interface. Problem solved. This is the sense in which I think it’s tempting to say that the scope of a ULA is not global, because here you can make a purely mechanical decision.

Option 3 would work quite well. Presumably if the name server for a provisioning domain gives you a ULA, then you can use the default router for that provisioning domain to reach that ULA (if it’s not on-link). So here you have effectively an explicit scope, which really doesn’t play well with the meaning of “scope” in RFC 4007.