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

[Fernando Gont <[e-mail]>]

On 7/1/21 18:51, Ted Lemon wrote:
> On Jan 7, 2021, at 4:35 PM, Fernando Gont <[e-mail] 
> <mailto:[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.

Indeed!



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

Agreed. Or: the address is not globally-unique. So the same address is 
actually valid on all interfaces, most-likely corresponding to different 
nodes .. and thus you need to specify which of all those possible 
instances of address FE80::X you are referring to.




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

As noted to Brian, the case that might need a zone-id is that where you 
have a host with two interfaces, each with one different ULA prefix, and 
you need to send packets to a destination ULA that belongs to a whole 
different prefix than the ones for which you have configured addresses 
for your two interfaces.

Another similar case would be a host with two interfaces, global 
addresses on each, that has to send packets to a ULA prefix.

Relying on your default route might not get your to where you want.

(Not sure if, conceptually speaking, not having an address configured 
for the ULA prefix you're trying to communicate with, means that you're 
not part of the "zone", and hence, that you're on your own)



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

That seems to be a similar case than the one I was noting above. I gues 
it could also be more complicate: even if you had a single interface, 
you might have multiple default routers. So rather than specifying an 
interface, you might actually need to specify "which next hope" to use.

Of course one cannot expect that.


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

#2 would probably make cases that are currently supported, unsupported. 
e.g.: think of a case where your local router advertises a /64 ULA 
prefix on the local link, and you want to send a packet to an address of 
a different subnet of the same Global-ID. -- most likely your router is 
not sending RIOs for the ULA prefix you're employing....




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

Agreed on this one.


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