IPv6 strangeness

awebster

@cmpsalvestrini You need to be specifically looking for ICMP6 neighbor solicitation messages, simply trying to capture while filtering for the host won't show anything because it hasn't been found yet (ie: it doesn't exist), consequently the capture will show nothing.
You are basically looking for the IPv6 equivalent of an ARP WHO-HAS message.
Here is an example of what that actually looks like IRL, but let me set the stage...

Host xxxx:yyyy:zzzz:e001::4:9, MAC address: 00:0c:29:cb:fd:01
Host xxxx:yyyy:zzzz:e001::4:61, MAC address: 00:0c:29:d7:c8:44
::4:9 has not talked to ::4:61 recently, so needs to figure out how to do that.
All Ethernet communication is ultimately Layer 2 based, Layer 3 stuff comes after the hosts have figured out how to reach each other.

08:38:22.234952 00:0c:29:cb:fd:01 > 33:33:ff:04:00:61, ethertype IPv6 (0x86dd), length 86: xxxx:yyyy:zzzz:e001::4:9 > ff02::1:ff04:61: ICMP6, neighbor solicitation, who has xxxx:yyyy:zzzz:e001::4:61, length 32

08:38:22.234973 00:0c:29:d7:c8:44 > 00:0c:29:cb:fd:01, ethertype IPv6 (0x86dd), length 86: xxxx:yyyy:zzzz:e001::4:61 > xxxx:yyyy:zzzz:e001::4:9: ICMP6, neighbor advertisement, tgt is xxxx:yyyy:zzzz:e001::4:61, length 32

In the above capture, you can see host xxxx:yyyy:zzzz:e001::4:9 wanting to communicate with xxxx:yyyy:zzzz:e001::4:61, but it doesn't yet know where to send the packets, so it asks...
Since ..::4:9 doesn't know the Layer 2 MAC address to which to send the packets to, it starts off with a multicast packet to a special IPv6 multicast address composed of the last 24 bits of the IPv6 address (ff02::1:ff00/104 which maps to a Layer 2 multicast address 33:33:ff:xx:xx:xx) - see RFC4291. All devices on the same broadcast domain will hear this message, but presumably there are very few that will actually act on it, and only one will match exactly and trigger a response.
The response packet is an ICMP6 neighbor advertisement back to the sender, thus the sender learns the MAC address to which to direct further traffic.

If there is no response to an ICMP6 neighbor solicitation message, traffic shall not pass!

Edit - What the ND Proxy will do in cases where the desired destination is not on the same subnet is respond to that ICMP6 neighbor solicitation message on behalf of devices on the other side of the router, so that the traffic is actually delivered.

Derelict

@awebster You need to be specifically looking for ICMP6 neighbor solicitation messages

Ah I didn't test it. I know you will capture ARP if you filter on a host address. Guess I have never looked for ND the same way.

awebster

@Derelict You had me second guessing myself...
I had always used the icmp6 filter on tcpdump, but then I tried out what you had suggested, and it did appear to work when specifying host... but that was on a Linux host.
On pfSense, tcpdump does not show anything when specifying host for a non-existent host, only icmp6 shows the ND Solicit messages.
Clearly, the tcpdump parsers are different!

pfSense 2.4.4-p3
tcpdump version 4.9.2
libpcap version 1.8.1

Linux CentOS 6.10:
tcpdump version 4.1-PRE-CVS_2017_03_21
libpcap version 1.4.0

cmpsalvestrini

Dear all,

Thank you. I will keep plugging at this; will keep posted as need arises.

Cheers!