Re: Question about RFC6724

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

On 03-May-22 18:42, Philip Homburg wrote:
>>> In the context of RFC 6724, can you give an example where limiting the
>>> CommonPrefixLen to 64 gives the wrong result?
>>
>> If read that way, it means that all IPv4-mapped addresses match each other
>> at /64. I'm sure that isn't the intention and I very much doubt that any
>> implementation does that. See my reply to Fred Templin.
> 
> If it is obviously wrong, then it should be possible to give an example
> where RFC 6724 gives the wrong results.

Well, if I put this in my hosts file:

10.1.0.10 printer.mynet.example.com
192.168.178.99 printer.mynet.example.com

then getaddrinfo() returns this, on a Windows host whose IPv4
address is 192.168.178.20:

(<AddressFamily.AF_INET: 2>, 0, 0, '', ('10.1.0.10', 0))
(<AddressFamily.AF_INET: 2>, 0, 0, '', ('192.168.178.99', 0))

If I swap the two entries in hosts, I get:

(<AddressFamily.AF_INET: 2>, 0, 0, '', ('192.168.178.99', 0))
(<AddressFamily.AF_INET: 2>, 0, 0, '', ('10.1.0.10', 0))

I regard that as rather broken; it's clearly not a longest match
at /104, which it should be. Maybe it's different on Linux, but
I don't have a Linux box running this morning.

> Any material change in RFC 6724, would basically be us (6man) trying to define
> address selection for IPv4.

Why is that a problem? Obviously, we'd ask intarea for feedback.
  
> There is a reason the common prefix len is now limited to 64. 

RFC 6724 doesn't actually say that; it only gives 64 as an example of
the prefix length in the case of link-local addresses. That's good,
because it makes the text valid for any future change in that area.

> The same
> reasoning applies to IPv4 (i.e., just comparing all address bits is as wrong
> for IPv4 as it is for IPv6).

In my example above, it's apparent that the comparison is not being
done at /104 (/24 in IPv4 terms) although it should be, since my subnet
is 192.168.178.00/24. That is almost certainly because RFC6724 doesn't spell
the IPv4-mapped case out.

Why does it really matter if the comparison is (redundantly) performed
on all 128 bits? fdee:face:fade::a will match fdee:face:fade::b at /127
instead of /64, but no harm is done that I can see. Similarly,
192.168.178.99 and 192.168.178.20 will match at a few bits longer than
/24.

Regards
     Brian