I have a passthru MACVLAN enslaved to a bridge. The MACVLAN and and its underlying link do NOT have IPv6LL (or any) address configured (while the bridge does). I expect all IPv6 (or even all Ethernet) multicast to "walk across" the MACVLAN. Yet in reality only some of the traffics do that. What "walk across": ping ff02::1%bridge and Neighbor Solicitation from this host (tcpdump multicast on a LAN host can see them) ping ff02::1%some_dev from a LAN host (tcpdump multicast on this host or a bridge tap host can see them) What do not "walk across": Neighbor Solicitation from a LAN host (both tcpdump multicast on this host and on a bridge tap host cannot see them) ping ff02::1%some_dev and Neighbor Solicitation from a bridge tap host (tcpdump multicast on this host can see them, but that on a LAN host cannot)
Btw there is no problem with ARP (or IPv4 multicast, apparently)
Actually: > ping ff02::1%some_dev and Neighbor Solicitation from a bridge tap host "walks across" the MACVLAN as well (I forgot to change the ether saddr for them: the underlying link is a wireless NIC) So it seems that only: > Neighbor Solicitation from a LAN host does not "walk across". Btw Neighbor Advertisement from a LAN host "walks across" the MACVLAN as well. I can see it on this host.
To be more precise, when the passthru MACVLAN is not bridged, I can see: # tcpdump -eni any icmp6 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 15:30:50.865328 wlan0 M ifindex 5 LAN_HOST_MAC ethertype IPv6 (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor solicitation, who has THIS_HOST_LL, length 32 15:30:50.865547 macvl0 M ifindex 6 LAN_HOST_MAC ethertype IPv6 (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor solicitation, who has THIS_HOSTLL, length 32 followed by unicast neighbor advertisement "OUTs" from this host to the LAN host. But when the MACVLAN is bridged, I cannot see similar capture at all (i.e. it doesn't just "stopped" before "walking across" the MACVLAN, rather they appears to be like blocked at "the outside" or so.)
Hmm, interestingly, the problem occurs only when I am using the permanent MAC address of the wireless NIC. If I change/randomize the address (and of course, make the bridge use the result as its own address as well), Neighbor Solicitations can come in without needing the NIC and the MACVLAN to have IPv6LL.