On 2023-07-12 16:23, Zack Newman wrote:
> Before I raise a bug report, I wanted to pass it by @misc in case I'm
> confused. It appears there is an issue with link-local addresses at
> least as far as route(8) is concerned. Since May 2, /var/log/messages
> has been getting spammed with the following:
> 
> router$ tail -6 /var/log/messages
> Jul 12 03:02:47 router /bsd: ndp info overwritten for 
> fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0
> Jul 12 03:02:51 router /bsd: ndp info overwritten for 
> fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0
> Jul 12 04:57:30 router /bsd: ndp info overwritten for 
> fe80:4::c6ca:2bff:fe5a:8723 by c4:ca:2b:5a:87:23 on em0
> Jul 12 04:57:34 router /bsd: ndp info overwritten for 
> fe80:4::c6ca:2bff:fe5a:8723 by 00:1c:73:00:00:99 on em0
> Jul 12 06:16:31 router /bsd: ndp info overwritten for 
> fe80:4::c6ca:2bff:fe5a:cf35 by c4:ca:2b:5a:cf:35 on em0
> Jul 12 06:16:35 router /bsd: ndp info overwritten for 
> fe80:4::c6ca:2bff:fe5a:cf35 by 00:1c:73:00:00:99 on em0
> 
> The MAC address 00:1c:73:00:00::99 belongs to the gateway on my ISP's
> side. I have no clue about the other 2 MAC addresses. Anyway, when
> trying to investigate the matter, I found that link-local
> addresses (i.e., fe80::/10) that are not part of fe80::/64, the only
> block that is actually defined to be used per RFC 4291 Section 2.5.6,
> always have the second octet pair as 0:
> 
> router$ route -n get fe80:4::c6ca:2bff:fe5a:cf35%em0 -inet6
>    route to: fe80::c6ca:2bff:fe5a:cf35%em0
> destination: fe80::c6ca:2bff:fe5a:cf35%em0
>        mask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
>   interface: em0
>  if address: fe80::7ec2:55ff:fe62:31fb%em0
>    priority: 3 ()
>       flags: <UP,HOST,DONE,LLINFO,CLONED>
>      use       mtu    expire
>       34         0     85085
> 
> Notice how "route to" does not have the same IP as the IP I passed to
> route(8). Here is another example with a "random" link-local IP:
> 
> router$ route -n get fe80:4:8349:adfe:1ca:2eff:95a:14%em0 -inet6
>    route to: fe80:0:8349:adfe:1ca:2eff:95a:14%em0
> destination: fe80::
>        mask: ffc0::
>     gateway: ::1
>   interface: lo0
>  if address: ::1
>    priority: 8 (static)
>       flags: <UP,GATEWAY,REJECT,DONE,STATIC>
>      use       mtu    expire
>       27     32768         0
> 
> Is there something I am missing, or is this a bug?
> 

I believe you are missing that Link-Local IPv6 addresses aren't
the whole /10, they are only the /64. This is by design, since
quite a few IPv6 functions depend on fe80::/64 being there.

For further reference, see section 2.5.6 of RFC4291, the current
version of the IPv6 Address Architecture.
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.6

Kind Regards,

-- 
Åke Nordin <ake.nordin (at) netia.se>, resident Net/Lunix/telecom geek.
Netia Data AB, Stockholm SWEDEN

Reply via email to