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

On 08-Jan-21 00:41, Philip Homburg wrote:
>>> No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface I
>> Ds
>>> 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?
> 
> It works on Linux and MacOS. On freebsd I get
> '2001:67c:2e8:3::c100:a4%re0: Name does not resolve'
> which suggests that they do an extra check in a library. I didn't check
> if the kernel handles it.

Thanks. It doesn't work on Winsock (Windows 10 version) either. It assigns
interface index 0 to all global addresses (including ULAs) regardless of
which physical interface they are on. There is no interface 0 on Windows;
it amounts to being the "default zone" defined by RFC4007.

There's nothing in RFC4007 suggesting that a non-default zone applies
to global addresses. Rather the opposite:

"And, when supported, the index value zero at each
scope SHOULD be reserved to mean "use the default zone"...
Those default indices can also be used
as the zone qualifier for an address for which the node is attached
to only one zone; e.g., when using global addresses."

So I'd say that Linux and MacOS have got it wrong, and FreeBSD
and Windows are right. Portable code certainly can't assume that
the interface ID can be used for global unicast.

    Brian