FreeBSD does not reply to IPv6 Neighbor Solicitations

[John-Mark Gurney]

Lutz Donnerhacke wrote this message on Tue, Jan 05, 2021 at 12:58 +0100:
> > > May you be able to capture the icmp6 traffic of this interface with
> > > respect to ND? I'm really interested in seeing, that the box does
> > > not respond to a given NS query.
> > 
> > Here you are http://admin.sibptus.ru/~vas/nd1.pcapng
> 
> The device, where the capture was taken does not respond tot he NS packet.
> This might be caused by:
>  a) the device has a different configured IP address, than requested
>  b) the network card does not listen to the multicast group, which is
>     used by the request (you see it only due to the promisc mode of the
>     capture). But this is unlikely (due to the promisc mode)
>  c) your system is broken

I have some test scripts where something similar to this happens.

I tcpdump shows the request coming into the FreeBSD box (in this case,
13-current main-c255640-gc38e59ce1b0), addressed to the IPv6 of the
box, and FreeBSD failing to respond w/ an answer for it's own IP...

This is inconsistent and hard to reproduce, but it does happen with
somewhat regularity.

This is from the host w/ ipv6 address fc00:b5d:41c:7e37::c43c:
02:11:53.065550 IP6 :: > ff02::1:ff00:7e37: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::7e37, length 32
02:11:53.069274 IP6 :: > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
02:11:54.639001 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
02:11:55.659956 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
02:11:56.667880 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32

and this is from the host w/ ipv6 address fc00:b5d:41c:7e37::7e37:
02:11:53.065345 IP6 :: > ff02::1:ff00:7e37: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::7e37, length 32
02:11:54.638742 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
02:11:55.658801 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
02:11:56.667187 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32

So, these captures are from the same host, but w/ the two interfaces
in different vnet jails, but wired back to back, so the time stamps
came from same clock, so can give you close to absolute ordering between
the two captures...

This is pretty much, bring up interface, configure a/ ipv6 addresses,
and then ping the address, and fail after a couple tries.

I'm not sure why the 7e37 host didn't receive c43c's hosts broadcast
announcing their address, but other times, it will properly respond,
for example:
05:08:32.158342 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32
05:08:32.158377 IP6 fc00:b5d:41c:7e37::c43c > fc00:b5d:41c:7e37::7e37: ICMP6, neighbor advertisement, tgt is fc00:b5d:41c:7e37::c43c, length 32
05:08:32.215624 IP6 fc00:b5d:41c:7e37::7e37 > fc00:b5d:41c:7e37::c43c: ICMP6, echo request, seq 0, length 16
05:08:32.215646 IP6 fc00:b5d:41c:7e37::c43c > fc00:b5d:41c:7e37::7e37: ICMP6, echo reply, seq 0, length 16

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."