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?
