AW: FreeBSD does not reply to IPv6 Neighbor Solicitations

[Lutz Donnerhacke]

Victor Sudakov wrote:
> Paul Mather wrote:
> > >>>> Why could it be that a FreeBSD 12.2 host does not reply to ICMPv6
> > >>>> Neighbor Solicitations from the router?
> 
> Well, Neighbor Solicitations (ICMPv6 type 135) and Neighbor
> Advertisements (ICMPv6 type 136) are not exactly routing messages, they
> are the equivalent of the ARP protocol in IPv6, and AFAIK should work
> between any two IPv6 nodes to map L3 addresses to L2 addresses, even if
> there are no routers on the segment. Correct me if I'm wrong.

Correct.

> You may be right but then it is certainly a bug. Unfortunately I cannot
> reproduce the problem with any reliability, this thing works more often
> than not.

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.

There are various reasons, why this may happen, i.e. sender IP in the NS is
out of prefix of the target IP. This may happen, if multiple prefixes are
added to the interface. Some devices (like Cisco ASA) are very picky on
matching source/target IPs. So it might be possible, that the problem is not
the the FreeBSD box, but the querying device (Mircotik?)

> > My interface ifconfig shows "nd6
> > options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>"
[...]
> > [*] As well as a static IPv6 address I also enable SLAAC to get
> > autoconfigured and privacy addresses on the interface.
> 
> I see your point, this makes sense, but I would like to try and isolate
> the problem.

There is no problem with neighbour discovery without the ACCEPT_RTADV
option. It simply works.
# uname -a
FreeBSD ... 12.2-STABLE FreeBSD 12.2-STABLE r368820 ENCOLINE-NAT  amd64

# ifconfig vlan1111
vlan1111: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
       options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
       ether 48:df:37:3c:d3:50
       inet6 fe80::4adf:37ff:fe3c:d350%vlan1111 prefixlen 64 scopeid 0x1e
       inet6 2a01:75c0:1000:1111:5:102:160:146 prefixlen 64
       inet 5.102.160.146 netmask 0xfffffff0 broadcast 5.102.160.159
       groups: vlan
       vlan: 1111 vlanpcp: 0 parent interface: ixl0
       media: Ethernet autoselect (10Gbase-SR <full-duplex,rxpause,txpause>)
       status: active
       nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

# tcpdump -ni vlan1111 icmp6 | fgrep neighbor
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1111, link-type EN10MB (Ethernet), capture size 262144
bytes
09:06:17.823698 IP6 fe80::50:1111 > 2a01:75c0:1000:1111:5:102:160:146:
ICMP6, neighbor solicitation, who has 2a01:75c0:1000:1111:5:102:160:146,
length 32
09:06:17.823708 IP6 fe80::4adf:37ff:fe3c:d350 > fe80::50:1111: ICMP6,
neighbor advertisement, tgt is 2a01:75c0:1000:1111:5:102:160:146, length 24
09:06:22.782809 IP6 fe80::4adf:37ff:fe3c:d350 > fe80::50:1111: ICMP6,
neighbor solicitation, who has fe80::50:1111, length 32
09:06:22.787620 IP6 fe80::50:1111 > fe80::4adf:37ff:fe3c:d350: ICMP6,
neighbor advertisement, tgt is fe80::50:1111, length 24
^C271 packets captured
5149447 packets received by filter
0 packets dropped by kernel

So it works in both directions.
Please note, that the first NS query is coming from a link-local address and
requesting a global IP. This will not always be answered by any device out
there (especially if the roles are reversed)