It seems that MLD snooping on Linux bridges has broken various parts of IPv6 connectivity over the past 10 years or so.
- Initial reports of bugs were from 2013, when having MLD snooping enabled on the bridge broke neighbour discovery (breaking IPv6 connectivity altogether), corosync multicast (including non-IPv6 multicast), and other guest-to-host multicast traffic: https://bugzilla.redhat.com/show_bug.cgi?id=902922
- This commit in the 3.x kernel series was supposed to fix it: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg946154.html, and apparently did in that case, but
- It was still causing problems in 2016 on the 4.x series, and with no apparent resolution (xkcd 979, anyone?): https://bugzilla.kernel.org/show_bug.cgi?id=99081
I started setting up my first IPv6-only VM host in April 2020 and I encountered a similar bug wherein initial OSPFv3 neighbour relationships were established with other hosts on my backbone VLAN over the main Ethernet bridge, but eventually the MLD entry timed out and the neighbour relationship disappeared, taking the associated IPv6 routes with it and thus breaking connectivity from non-local networks.
From my dpkg and etckeeper logs it seems I was running linux-image-5.4.0-21-generic on the newly-released Ubuntu 20.04 (focal fossa). At the time I just added the recommended snippet to my /etc/network/interfaces entry and moved on with life:
post-up echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping
I recently switched from ifupdown to netplan and revamped the bridge configuration on this host. The host is now running kernel linux-image-5.15.0-56-generic. As I was converting the ifupdown configuration to netplan, I kept the above post-up script as a comment in case I needed it again. So far, it has not shown any signs of needing the above workaround, so here's hoping it's fixed for good.