Solved interface cannot receive IPv6 packets

[PMc]

There seems to be a major difference between IPv4 and v6: with IPv4 an interface does receive packets with a destination of it's own configured IP address. With IPv6 it does not:

# ifconfig tap0 inet6
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::2%tap0 prefixlen 64 scopeid 0x9
        inet6 2003:e7:17ff:4a2f::10 prefixlen 124
        Opened by PID 2776

# ping6 -c 1 google.com
PING6(56=40+8+8 bytes) 2003:e7:17ff:4a2f::10 --> 2a00:1450:4001:801::200e

--- google.com ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

/var/log/security
kernel: ipfw: 1 Accept ICMPv6:128.0 [2003:e7:17ff:4a2f::10] [2a00:1450:4001:801::200e] out via tap0

tcpdump -nitap0
19:01:55.943404 IP6 2003:e7:17ff:4a2f::10 > 2a00:1450:4001:801::200e: ICMP6, echo request, seq 0, length 16
19:01:55.964742 IP6 2a00:1450:4001:801::200e > 2003:e7:17ff:4a2f::10: ICMP6, echo reply, seq 0, length 16

As one can see, the echo-request is accepted by the firewall, and goes out to the correct interface. Then an echo-reply is seen by the interface, but the interface prefers not to receive it: the firewall does neither Accept nor Deny.

It cannot be a routing issue because the reply is obtained and is already here.

And ping6 works with the link-local addresses, so it cannot be a general IPv6 issue either.
Trying to do a link-local ping via the global unicast address does not work, because the interface also prefers to not receive the neighbor advertisment for these addresses.

 

[PMc]

My mistake, I got hosed between tun and tap interfaces.

While a tun interface uses the local address as the next hop gateway for routing, a tap interface uses the remote address. If the local address gets configured, the packets will be sent (and the other side can see them in promiscuous mode), but they have the local end as their linklayer destination.

Also, there is no arp, but icmp6 depends on linklevel address resolution which is done with icmp6 - and there are some strange effects with that construct. Specifically, I ran into this problem, which seems to be just the same with FreeBSD.

 

[PMc]

Also, there is no arp, but icmp6 depends on linklevel address resolution which is done with icmp6 - and there are some strange effects with that construct. Specifically, I ran into this problem, which seems to be just the same with FreeBSD.

But here it is solveable! sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861
(This is a security issue, and a problem only when the subnetting structure is different between link-local and global addresses, so the system cannot figure out which are honest neighbours. Alternatively the mac addresses could be loaded manually with ndp -s)