The challenge with having a step by step tutorial is that there are many different ways to configure it, and many different types of ISP networks, so its not a case of one-size fits all.
This is why LXD comes out of the box with a private bridge, so that it doesn’t have to take into account the external connectivity much (apart from NAT).
For example, if you did not need automatic IP assignment via SLAAC, I would have suggested you just use LXD’s built in
routed NIC type, that uses Linux’s built in proxy NDP functionality without the need for using a LXD bridge or the NDP proxy daemon at all. This would be the simplest option IMHO, as it also avoids the need to rely on your ISPs routing advertisement daemon (if they have one), and avoids any MAC filtering on the ISP network side. However it requires static IP assignment.
Another option would be to use the
macvlan NIC type, which, again, would allow you to avoid using the lxdbr0 and NDP proxy daemon, and instead directly connect your container to the host’s network (which, if the ISP provides a routing advertisement daemon, and there’s no indication from their tutorial that they do), then SLAAC would work directly with external addresses. This may cause issues if the ISP has MAC filtering in place. It also doesn’t allow your containers to talk to your host (which some people need).
Next there is
ipvlan which is like a cross between
macvlan, in that it requires static assignment, and shares the host’s MAC address, but doesn’t allow containers to talk to the host.
There’s also the option of creating a new unmanaged bridge, say br0, and then linking both your host’s eth0 interface and your container’s eth0 to it, effectively joining your containers to the external network of your host. This has most of the same properties (pros and cons) as
macvlan above, but does allow your containers to talk to your host. However it is the most tricky to setup, as you have to remove the IP from your host’s eth0 and move it to the unmanaged bridge interface.