Hi @Nick_Knutov IPVLAN is unfortunately designed that way in the kernel (not an LXD decision).
In principle it could be worked around by attaching another interface to the host that is part of the IPVLAN, although that is not ideal due to routing issues, as you’d end up with duplicate routes to the same subnet.
venet from OpenVZ made the host act like a router, where packets coming from the container used the host’s routing table to pick the next interface to send packets to, and it had the ability to communicate with the host. This also allowed the host to use iptables to filter packets between containers and the host.
We have had some discussions around potentially adding a “routed” mode that would behave similarly, but using veth pairs rather than an in-kernel venet implementation.
This would also use the same ARP and NDP proxying that IPVLAN uses so that containers could appear to be on an external network.
This would make it easy to add a container with a public IP address on a VPS or physical server that has multiple IPs routed to it.