Support IPv6 > add trustGuestRxFilters='yes' to the mapvtap interface

[HLFH]

Hi,

We need to add to the mapvtap interface:

<interface type='direct' trustGuestRxFilters='yes'>

For a website / web app within the VM to be reachable over public IPv6 and for IPv6 to fully work.

Can you add this as the default or at least as a GUI macvtap configuration option?

Related to: virt-manager/virt-manager#676

[garrett]

I did a search and saw that there seems to be "security implications" to setting this flag:

https://bugzilla.redhat.com/show_bug.cgi?id=1035253#c21

To enable multicasting, you need set the interface trustGuestRxFilters attribute to yes. This has security implications, because it allows the virtual server to change its MAC address and thus to receive all frames delivered to this address.

While I really don't think having an option to "unbreak" something that should work by default (IPv6) is a good idea... I also don't think it's acceptable to have something with hidden security implications.

According to https://libvirt.org/formatdomain.html#network-interfaces, trustGuestRxFilters='yes' only applies to macvtap and virtio network devices, nothing else.

Since 1.2.10 ), the interface element property trustGuestRxFilters provides the capability for the host to detect and trust reports from the guest regarding changes to the interface mac address and receive filters by setting the attribute to yes. The default setting for the attribute is no for security reasons and support depends on the guest network device model as well as the type of connection on the host - currently it is only supported for the virtio device model and for macvtap connections on the host.

Does the libvirt team treat this as a workaround and suggest using bridged instead (which I can confirm works with IPv6 here locally)? It feels like that, but I don't know their intent. We need this clarified. The fact that they have it off by default and say (admittedly hand-wavy) "security" issues with it set to yes means that there really must be some reasons why it shouldn't be on by default. I wish they'd clearly state what those are. (Are the reasons more than putting another machine on the network directly? Probably. It might be that the VM can intercept traffic delivered to the host? 🤷 That's certainly one interpretation of the quote from Bugzilla.)

Hypothetically, from a design viewpoint, if we were to have an option like this in the UI, it should be off by default (which is what libvirt does) due to "security" reasons, and it should plainly state that it's intended for multicast and IPv6, and should only show up when it's relevant (when both macvtap and virtio are active). And it should have the security reasons listed (perhaps with details in a disclosure, like a popover), with some kind of clear warning indicator.

As this is security-related, for this to proceed, we need someone who knows the implementation better. (I am not that person. I'm just reading what the Internet and libvirt docs say and drawing some conclusions from that, from a design perspective. 😉)