Greetings, we're having at least two different weird ndp/icmp6 related behaviours we would like to share
The setup is quite simple, we're trying to ping6 from one OpenBSD 6.8 to another, sometimes, without any clear reason, the host sending the request will start to use its link-local address in the icmp neighbor solicitation See below a NOK scenario with the solicitation dropped by the requested system The OK scenario may come back after a while, where the unicast address is again in use in the the neighbor solicitation source address and is properly answered A simple way we found to reproduce this on demand is to run a ndp delete and then ping in a loop $ while (:); do ndp -d 2a02:6f00:c0:30::10; ping6 -c2 2a02:6f00:c0:30::10; done Usually after 5 to 10 attempts the issue shows up NOK pcap on requested host (trafic goes through but ignored by target/requested host) # 16:50:06.340898 00:15:17:dd:60:fa 33:33:ff:00:00:10 86dd 86: fe80::215:17ff:fedd:60fa > ff02::1:ff00:10: icmp6: neighbor sol: who has 2a02:6f00:c0:30::10 # 16:50:07.356429 00:15:17:dd:60:fa 33:33:ff:00:00:10 86dd 86: fe80::215:17ff:fedd:60fa > ff02::1:ff00:10: icmp6: neighbor sol: who has 2a02:6f00:c0:30::10 OK same pcap with unicast address of source instead of link local, properly answered # 16:57:10.308265 00:15:17:dd:60:fa 33:33:ff:00:00:10 86dd 86: 2a02:6f00:c0:30::3 > ff02::1:ff00:10: icmp6: neighbor sol: who has 2a02:6f00:c0:30::10 # 16:57:10.308512 00:1e:67:15:18:ba 00:15:17:dd:60:fa 86dd 86: 2a02:6f00:c0:30::11 > 2a02:6f00:c0:30::3: icmp6: neighbor adv: tgt is 2a02:6f00:c0:30::10 We then enabled nd6_debug with sysctl net.inet6.icmp6.nd6_debug=1, ran the test again and below are the pcap and dmesg output Notice how the src and dst address in nd6_ns_input are altered We started to wonder what is at fault, the 'NS packet from non-neighbor' check or the ipv6 fields being altered higher up in the chain On the live system - OpenBSD 6.8 (yes, we plan to update) # pcap - correct source link-local address # 13:42:54.252709 00:15:17:dd:60:fa 33:33:ff:00:00:10 86dd 86: fe80::215:17ff:fedd:60fa > ff02::1:ff00:10: icmp6: neighbor sol: who has 2a02:6f00:c0:30::10 # dmesg with altered src and dst addresses (extra 9 on bits 16-31) # May 16 13:42:54 vpn1 /bsd: nd6_ns_input: NS packet from non-neighbor # May 16 13:42:54 vpn1 /bsd: nd6_ns_input: src=fe80:9::215:17ff:fedd:60fa # May 16 13:42:54 vpn1 /bsd: nd6_ns_input: dst=ff02:9::1:ff00:10 # May 16 13:42:54 vpn1 /bsd: nd6_ns_input: tgt=2a02:6f00:c0:30::10 The same attempt on a 7.3 system in a "lab" are working correctly: 1. With a "default" configuration, the src address in the neighbor solicitation is the unicast address and not the link local address, 'NS packet from non-neighbor' is not triggered and ndp works correctly, icmp6 request/reply then goes through without issues 2. When explicitly crafting a packet with the link local address as source, the remote system properly reply to neighbor solicitation and icmp req/rep goes as well too which would indicate that 'NS packet from non-neighbor' allows link local address as source 3. The interesting part is when we explicitly craft a neighbor solicitation packet with a "invalid" source link local address, the 'NS packet from non-neighbor' triggers and shows up in dmesg, but again, with an altered bit - "lab" testing - 7.3 # pcap - crafted incorrect source link-local address # 13:58:42.675849 c8:8a:9a:a3:ea:26 33:33:ff:00:00:01 86dd 86: fe80::9:5054:ff:fe28:e372 > ff02::1:ff00:1: icmp6: neighbor sol: who has 2a02:6f00:8888::1 # dmesg with altered src and dst address (extra 1 on bits 16-31 on top of crafted 9) # May 16 13:58:42 obsd68 /bsd: nd6_ns_input: NS packet from non-neighbor # May 16 13:58:42 obsd68 /bsd: nd6_ns_input: src=fe80:1:0:9:5054:ff:fe28:e372 # May 16 13:58:42 obsd68 /bsd: nd6_ns_input: dst=ff02:1::1:ff00:1 # May 16 13:58:42 obsd68 /bsd: nd6_ns_input: tgt=2a02:6f00:8888::1 Questions are then: - why would a system change between link-local and unicast address in the source address of neighbor solicitations it sends (although I'm painfully aware 6.8 is quite old) - is the nd6_ns_input logging having issue with display of dst/src addresses ? - and/or the 'NS packet from non-neighbor' mechanism known to sometime discard perfectly valid neighbor solicitation with link-local address as source ? Thank you, and let me know if you would need more details on this
