Re: Question about RFC6724

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

Hi Jinmei-san,

On 03-May-22 11:42, JINMEI Tatuya / 神明達哉 wrote:
> On Sun, May 1, 2022 at 9:33 PM Brian E Carpenter
> <[e-mail]> wrote:
> 
>>> 2.2.  Common Prefix Length
>>>
>>>     We define the common prefix length CommonPrefixLen(S, D) of a source
>>>     address S and a destination address D as the length of the longest
>>>     prefix (looking at the most significant, or leftmost, bits) that the
>>>     two addresses have in common, up to the length of S's prefix (i.e.,
>>>     the portion of the address not including the interface ID).  For
>>>     example, CommonPrefixLen(fe80::1, fe80::2) is 64.
>>
>> The "interface ID" is simply a non-concept for IPv4-mapped IPv6 addresses. So what do implementations do?
> 
> I've just checked an implementation I'm relatively familiar with, and
> found that it seems to completely ignore the "up to the length of S's
> prefix" part:
> https://github.com/freebsd/freebsd-src/blob/271f6d52a606e86c11b366082f11fe69350f24da/lib/libc/net/getaddrinfo.c#L924
> that is, it compares the entire 128-bit IPv6 addresses and 32-bit IPv4
> addresses.

I think that makes a lot of sense. There's no real advantage in stopping
the match at /64, and it's only by going beyond /96 that it can be
useful for IPv4-mapped, if a host happens to have more than one IPv4
address.
  
> But I don't think the specification simply "doesn't work for
> ::ffff:0:0/96" (or IPv4 addresses).
> Since 'S' is a local address, the implementation should also be able
> to get the corresponding netmask
> (which should be contiguous in practice, and can be converted to a
> "prefix length").

Right, but the text is written as if every address is a GUA (or ULA)
in a /64 subnet. It looks as if implementers have simply ignored
the statement about the prefix.

> An implementation could apply that prefix and compare the
> corresponding IPv4 addresses
> up to that length of bits.
> Extending it to the form of IPv4-mapped IPv6 addresses would be straightforward,
> although the RFC text could have been clearer for that case.

Exactly, and I think that should be logged in the errata for future
reference. (Also, architecturally, we don't want the /64 burnt into
code, for reasons discussed often on this list.)

Thanks,
    Brian