Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I will start thinking about supporting IPv6 when Docker supports it out of the box.

Hopefully, then I can test an individual application by running it in a container with "docker run -p [::1]:80:80 ...".

I don't want to go down the rabbit hole of fiddling with the docker demon and setting up a custom network.



I host Internet facing docker containers that support IPv6 with '--net=host'. For those who don't know, this allows to run a container with exactly the same characteristics as a normal process network wise.


Yes, that works.

I am not comfortable giving a container full control over the host network though. I have not looked into the security implications of it but I would expect it is dangerous for the host.


It's not even complicated at this point, just delegate an prefix in daemon.json and it'll all work automatically, even better if you use compose.


The problem with Docker is that assumptions of NAT and proxies are built-in quite deeply into the v4 networking functionality and defaults. With v4 it just exposes NATed rfc1918 space subnets to containers with a hardcoded prefix that's by default the same for all Docker installations in the world.

The sensible way to use it in the ipv6 world would be to give Docker its own globally routable prefix(es) acquired via eg dhcpv6 prefix delegation. The current manual prefix configuration is not how things should work in v6.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: