I wrote two posts on how to get LXD containers to use public/LAN IP addresses.
How to make your LXD containers get IP addresses from your LAN using macvlan
How to make your LXD containers get IP addresses from your LAN using a bridge
Any feedback and corrections are appreciated!
Thanks for the post! Really helpful 
So basically if you don’t need the host to communicate with the containers, macvlan would be the easiest, less invasive to implement, but if host and container need to communicate with each other it doesn’t matter which you choose, since both bridging and macvlan need extra configuration on the host (and with macvlan even an extra config for macvlan.mode in the container/template)?
If someone can enlighten why you would choose one or the other besides these tiny configuration differences?
I am using bridged by the way, but that’s what I was used to 
It is exactly as you summarize.
With macvlan, it is much less intrusive to the general configuration of the host. It does not require any changes to the host’s network configuration.
The changes in LXD are very minimal, and it’s merely the addition of a new profile.
Then, when you launch a new container, you can pick and choose whether it should have private networking or to work on the macvlan.
With a bridge, you need to make changes to the host’s networking. Without NetworkManager, these changes can be error-prone. If you are OK to make the networking changes on the host, and also require host<->containers communication, then it has to be a bridge.
In both cases, if a user in the container runs sudo tcpdump, they only get their own network packages, and any broadcast packets. It is possible to arpspoof in order for a bridged container to MitM the traffic of another bridged container and then this mitigated with iptables rules (bridge-iptables-mitm). I do now know how possible arpspoof would be with macvlan and google did not enlighten. In both cases, it would be interesting to see these in practice.
Neither (bridge, macvlan) work on WiFi networks, especially when WEP/WPA/WPA2 are used. It has to do with the WiFi router that expects a single MAC address to come from an established secure WiFi connection.
Apart from macvlan, there is also ipvlan. @stgraber had a look at ipvlan and saw that it is not workable in LXD.
To have a bridge on a WiFi network with LXD, it might be possible with ebtables as discussed at https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC
Yes I think it’s worth to revive this topic because it contains an assertion that was quite true at the time but is no longer accurate:
This is really cool.
The PR is currently marked as DRAFT (per Github features). It will take a bit before it gets accepted so that a daily snap (snap channel edge) is made available for easy testing.
However, it’s possible to compile LXD with this PR from this repository, https://github.com/tomponline/lxd/tree/tp-ipvlan according to instructions such as these ones, https://blog.simos.info/how-to-develop-the-lxd-hypervisor-part-2-using-multipass-kvm-vm/
ipvlan support is now available in LXD 3.13, currently only from the edge channel.
The reason being that it requires extra features in liblxc, and only the edge channel at the moment has a recent enough liblxc version.
See the announcement and the further discussion in the comments at LXD 3.13 has been released
Note that the edge channel is the channel that gets updated everyday, so if you switch to that, you are living on the bleeding edge (or, you have bug reporting privileges 
).