Starting at the end: I believe as the bug presently requires each of the host's bridge ports to be ipv6 addressable to enable ipv6 to function in the guest, and most admins won't think to add special entries into their host's nftables.conf to allow for it 'because who knew?' it represents what you might call a 'passive security vulnerability'.
A recent kernel upgrade has broken ipv6/ip6 ndp in a host/kvm setup using a bridge on the host and vlans for some guests. I've tracked the problem to a failure of the mcast code to add entries to the host's mdb table. Manually adding the entries to the mdb on the bridge corrects the problem.
It's very easy to demonstrate the bug in an all ubuntu setup.
1. On an ubuntu host, create two vms, I used libvirt, as set up below.
2. On the host, create a bridge and vlan with two ports, each with the chosen vlan as PVID and egress untagged. Assign those ports one each to the guests as the interface, use e1000. Be sure to NOT autoconfigure the host side of the bridge ports with any ip4 or ip6 address (including fe80::), it's just an avoidable security risk. We don't want to allow the host any sort of ip access / exposure to the vlan. In other words, treat the host's bridge ports as if a 'real off-host switch' without expectation of making each bridge's port being ip6 addressable on the bridge itself. (FWIW: Worth checking if the vlan is left tagged and not pvid, and the vlan is decoded in the guest as a separate interface, does the problem go away? It imposes the burden of vlan management awareness to the guest and so is not acceptable as a solution.)
3. On the host, assign a physical NIC to the bridge and the vlan to the nic. The egress is tagged for the chosen vlan and not PVID. Optionally set up an off-host gateway for the vlan, but it isn't necessary to show the bug.
4. On each guest, manually assign a unique ip4 and ip6 address on the same subnet (you'll see though dhcp4 could work if there was an off-host router providing related services, the bug prevents dhcp6 from working).
5. On one vm, ping the other. Notice ip4 pings work, ip6 pings do not.
6. Manually add the fe02::ffxx:xxxx entries for each vm to the vlan to the host bridge's multicast table. Use 'temp' if you're quick enough, otherwise perm.
7. Notice pings between the guests now work on ip6 and ipv4.
Using tcpdump and watching icmp6 traffic, you'll notice the packets making it across the various bridge ports the moment you manually add the appropriate fe02::ff... multicast address to the mdb table. Beware a false sense of security: Once the ndp completes and the link addresses are in the fdb, it can 'seem like' everything is fine until the fdb times out and the required mdb entry again must be used to allow ndp to refresh the address.
Setting mcast_querier doesn't help. Perhaps previous kernels turned off the multicast snooping by default and just flooded all the bridge ports with all multicast traffic so this bug was avoided.
It's my hunch the reason there hasn't been more complaint about this is it takes an extra step to not autoconfigure the vm ports with fe80:: link local addresses on the host. I believe the existence of the fe80 address on the host ports engages ndp code on the host to load the mdb as if preparing for the host's side of the bridge to participate in ip4 and ip6 higher layer traffic, but that's a 'bad hack that happens to work' -- it shouldn't be a requirement that each host vlan port have an ip6 address, after all it didn't need an IP4 address....
I've attached a linux-bug for you, but it's probably mostly unrelated info.
I believe as the bug presently requires each of the host's bridge ports to be ipv6 addressable to enable ipv6 to function in the guest, and most admins won't think to add special entries into their host's nftables.conf to allow for it 'because who knew?' it represents what you might call a 'passive security vulnerability'.
Temporary workaround:
On the vmhost:
echo 0 > /sys/devices/