On Wed, Jul 12, 2023 at 08:23:36AM -0600, 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?
You are missing something. It is called the KAME hack or embedded scope. The KAME IPv6 implementation hijacks the 2nd 16bit addr part to store the scope_id. In some cases this embedded scope escapes in the addrs printed. Especially the "ndp info overwritten for" is leaking the scope_id (4) which is probably the interface index of your em0 interface. Welcome to IPv6, the world would be better without all the garbage. -- :wq Claudio
