Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
LOL, fair enough. Feel free to yell at me for this third question and tell me to start a new thread. How do you recommend I should proceed in diagnosing these "ndp info overwritten" messages? It seems bizarre they started out of nowhere. Before May 2, I didn't have any; but since, I get them every 90 minutes or so. There is nothing that stands out in my logs that would suggest it was a software, hardware, or configuration change on my end. I changed hardware in March. I upgraded to OpenBSD 7.3 in late April. The first patch for 7.3 was a day after the first message. I upgraded my BIOS/UEFI in June. I haven't changed my DOCSIS 3.1 modem. There were no reboots around that time. I am still with the same ISP. I found this from @bugs: https://marc.info/?l=openbsd-bugs=165130576328299=2 but I have always had "allow-opts" for both ingress and egress ICMPv6 traffic, so Otto Moerbeek's workaround is not applicable. I tried the opposite (i.e., removing "allow-opts") as a shot in the dark, and it unsurprisingly didn't fix the problem (assuming there is one). I do recall helping the maintainer/creator of my DHCPv6 client, dhcpcd, around that time fix some other bugs; however my logs show that was a few hours after the first "ndp info overwritten" message. Nonetheless, I temporarily replaced the current version of dhcpcd which contains several bug fixes with the older version that is part of the -release packages. Even with that version, I was still getting these messages. Can you provide any guidance?
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
On Wed, Jul 12, 2023 at 10:59:13AM -0600, Zack Newman wrote: > On 7/12/23 10:20, Claudio Jeker wrote: > > 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. > > As predicted, em0 does in fact have index 4. Follow up question. Am I > to interpret this as purely a display problem and not a functional one? Depends. It is mostly a display issue until it isn't. The above is a display issue. > If so, can you explain why when I have the following rule in pf.conf(5): > > block out quick on $wan inet6 to fe80:4::c6ca:2bff:fe5a:8723%em0 > > I am still able to ping6(8) it: > > router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 > PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 > data bytes > 64 bytes from fe80::c6ca:2bff:fe5a:8723%em0: icmp_seq=0 hlim=64 time=7.294 ms > > --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 7.294/7.294/7.294/0.000 ms > > meanwhile if I remove the "4", I am unable to ping6(8) it?: Because the two addresses are not the same (in some cases). Confusing? Yes it is. > router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 > PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 > data bytes > ping6: sendmsg: Permission denied > ping: wrote fe80:4::c6ca:2bff:fe5a:8723%em0 64 chars, ret=-1 > > --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > > I should add that I can replace the second octet pair with any non-zero > value, and I am unable to block it. Asked differently, how would I be > able to block traffic to/from fe80:4::c6ca:2bff:fe5a:8723%em0 while > still allowing traffic to/from fe80::c6ca:2bff:fe5a:8723%em0 where "4" > is interpreted as not the scope_id but in fact part of the address since > seemingly "%em0" is sufficient without scope_id? You can't (they are the same). -- :wq Claudio
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
On 7/12/23 10:20, Claudio Jeker wrote: 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. As predicted, em0 does in fact have index 4. Follow up question. Am I to interpret this as purely a display problem and not a functional one? If so, can you explain why when I have the following rule in pf.conf(5): block out quick on $wan inet6 to fe80:4::c6ca:2bff:fe5a:8723%em0 I am still able to ping6(8) it: router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 data bytes 64 bytes from fe80::c6ca:2bff:fe5a:8723%em0: icmp_seq=0 hlim=64 time=7.294 ms --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 7.294/7.294/7.294/0.000 ms meanwhile if I remove the "4", I am unable to ping6(8) it?: router$ ping6 -c1 fe80:4::c6ca:2bff:fe5a:8723%em0 PING fe80:4::c6ca:2bff:fe5a:8723%em0 (fe80:4::c6ca:2bff:fe5a:8723%em0): 56 data bytes ping6: sendmsg: Permission denied ping: wrote fe80:4::c6ca:2bff:fe5a:8723%em0 64 chars, ret=-1 --- fe80:4::c6ca:2bff:fe5a:8723%em0 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss I should add that I can replace the second octet pair with any non-zero value, and I am unable to block it. Asked differently, how would I be able to block traffic to/from fe80:4::c6ca:2bff:fe5a:8723%em0 while still allowing traffic to/from fe80::c6ca:2bff:fe5a:8723%em0 where "4" is interpreted as not the scope_id but in fact part of the address since seemingly "%em0" is sufficient without scope_id?
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
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: ::::::: > interface: em0 > if address: fe80::7ec2:55ff:fe62:31fb%em0 >priority: 3 () > flags: > use mtuexpire > 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: > use mtuexpire > 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
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
Huh? Please read what I said. I literally mentioned RFC 4291 Section 2.5.6. Additionally, fe80::/10 _is_ defined by RFC 4291 Section 2.4 as "Link-Local unicast" addresses. Section 2.5.6 does not redefine that but instead states that, at least as of now, only fe80::/64 is allowed to be used. The point of defining fe80::/10 as link-local despite only a portion of it being allowed to be used is to prevent other addresses in that block from being used for other purposes. I don't want this to devolve into a game of "Can you guess what RFC 4291 says?" though as I don't actually think it is relevant. route(8) and perhaps other areas of the OS/kernel appear to force the second octet pair to be 0 which may or may not be the cause of my "ndp info overwritten" messages. If you are trying to imply that all fe80::/10 addresses are interpreted as fe80::/64 addresses, then even that does not make sense since you can clearly see that it is only the _second_ octet pair that has 0 while the other octet pairs retain the values that were passed.
Re: IPv6 link-local addresses outside of fe80::/64 are not handled correctly
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: ::::::: > interface: em0 > if address: fe80::7ec2:55ff:fe62:31fb%em0 > priority: 3 () > flags: > 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: > 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 , resident Net/Lunix/telecom geek. Netia Data AB, Stockholm SWEDEN
