I would like to (re)open discussion of IPv6 in containers. In my view, as of now (stable v7.10.2) the problem has at least two sides:
No address. It is not possible to assign one or more IPv6 addresses to a container’s virtual ethernet interface (veth) since /interface/veth explicitly expects only one IPv4. Workarounds:
→ IPv6 SLAAC: add a veth to a bridge, assign an IPv6 address to a bridge with advertise=yes. Pros: easy, persistent. Cons: not suitable for any setup where prefixes longer than /64 are used.
→ Run /sbin/ip -6 addr add [IPV6_ADDRESS] dev eth0 inside a container. Pros: universal. Cons: complex, goes away on reboot.
No gateway. Similarly, it is not possible to assign an IPv6 gateway for a container since /interface/veth explicitly expects IPv4 as a gateway. Workarounds:
→ IPv6 SLAAC: see above, but this is where a problem (probably, a bug) occurs. Normally, a container has to add default route with a gateway set to the IPv6 link-local address of the host’s bridge, but it won’t do that - IPv6 default route is missing in containers. Pros: easy, persistent. Cons: doesn’t work as expected.
→ Run /sbin/ip -6 route add default via [IPV6_GATEWAY] dev eth0 inside a container. Pros: universal. Cons: complex, goes away on reboot.
Other relevant ideas:
→ I understand one may run a custom script to assign IPv6 addresses and gateways to containers on startup but, in my view, it’s an overkill for such a basic functionality.
→ While testing, I was surprised to find that a container can have multiple DNS addresses including IPv6, and they are correctly mirrored to /etc/resolv.conf inside a container. So, there is at least one small step towards a proper dual-stack for containers already made.
→ There is another issue (probably, a bug) with a virtual interface (veth) itself. When you restart a container, its veth and routing table are not reconfigured. In other words, if you run some ip addr add/del or ip route add/del commands inside a container and then reboot this container, it will keep its network configuration. It is an unwanted behaviour, I would say. But if you reboot your host, no changes to your container’s network configuration persist, as expected.
Community, am I the only one suffering from this lack of IPv6 in containers? Or do you know other workarounds that are better in any way? Please share your experience with IPv6 in containers.
MikroTik engineers, I appreciate your hard work and hope this post will help you implement enhancements to the code.
I added IPv6 to my CHR container running a nextdns client. I had to add support for both options 1 and 2 into my docker container (these are using ULA):
Dockerfile
FROM debian:bullseye-slim
RUN apt-get update && apt-get install -y apt-transport-https curl && \
curl -o /usr/share/keyrings/nextdns.gpg https://repo.nextdns.io/nextdns.gpg && \
echo "deb [signed-by=/usr/share/keyrings/nextdns.gpg] https://repo.nextdns.io/deb stable main" | tee /etc/apt/sources.list.d/nextdns.list && \
apt-get update && apt-get install -y nextdns iproute2
EXPOSE 53/tcp 53/udp
CMD /bin/ip -6 addr add ${NEXTDNS_IPV6ADDR} dev eth0; /bin/ip -6 route add default via ${NEXTDNS_IPV6GW} dev eth0 ;/bin/ip -6 addr sh ; /bin/ip -6 route; /usr/bin/nextdns run ${NEXTDNS_ARGUMENTS} -profile ${NEXTDNS_ID}
I add the container with the correct envs. This container will basically have static addresses, so no RA/ND involved.
@biomesh, thanks for sharing your solution. It is universal and works pretty fine. However, it may be a little too complex to recreate and recompile multiple containers, track new versions and support all relevant platforms, at least for me.
Based on your idea I can see another possible workaround for both address and gateway assignment: override an original CMD of your docker container with a custom string:
/container set 0 cmd="sh -c \"ip -6 addr add [IPV6_ADDRESS] dev eth0; ip -6 route add default via [IPV6_GATEWAY] dev eth0; [ORIGINAL_CMD]\""
Pros: universal, persistent. Cons: works well only on the first launch of the container. When a container is restarted, an error occurs (one such line per each ip command): ip: RTNETLINK answers: File exists. This error message confirms what I mentioned in my first post as a veth bug. Nevertheless, the container continues running after such errors.
When you reboot your nextdns client container, do you get similar error messages?
I do get that error message on a container restart but my container works and the address assignment is valid (I added commands in the container CMD to print the ipv6 addresses and routes)
The upcoming changes to ROS mean I can revert my changes to my container soon.
@antonsb, well, you are technically right, it is a container that answers that an address/route is already in place. I mean that no addresses/routes assigned inside a running container should be persistent. Take a bare docker setup: every time you restart a container you will get a basic set of IPs assigned in the config, nothing more, no manual changes are kept. I guess, docker may recreate veth on container restart for this purpose, but I’m not sure about that.
Please, follow the steps below, then restart a container to reproduce error log messages we get.
I get this error “Error: either “local” is duplicate, or “ip” is a garbage.” when CMD is set to ip -6 addr add {myipv6}/64 dev eth0; ip -6 route add default via {ipv6gateay} dev eth0;
