"Moving" is a bit of a strong word. It would be much more accurate to say "providing alternatives". For example, the "golang" image now has an "alpine" variant for each supported version (https://hub.docker.com/_/golang/), but the default variant is still Debian-based (especially given that switching the base outright would break far too many existing Dockerfiles). Additionally, the documentation calls out that there might be libc compatibility issues in the spirit of trying to ensure our users are properly informed about the potential problems they might run into in their quest for the smallest possible base: https://github.com/docker-library/docs/blob/b7b6b86124682ef1...
I would definitely welcome PRs to make this verbiage more accurate or more informative of pros and cons.
It does have linked local addresses by default. It's the more complicated setup of actually routing IPv6 addresses outside our current host that's not enabled by default.
Basically, we can't use existing router advertisements (as I understand it) because you also have to tell your current IPv6 router that the entire prefix you use for Docker needs to go to this one host as opposed to just the one IPv6 address that host would auto-assign itself via RA.
Since there's manual outside-Docker setup involved, we can't really automate this bit. If there's a nice clean way to do so, we're definitely open to a PR (I'd love to have something simpler myself)! :)
That is not very clear from the docs then which say "By default, the Docker server configures the container network for IPv4 only. You can enable IPv4/IPv6 dualstack support by running the Docker daemon with the --ipv6 flag" - that doesnt sound like link local addresses by default...
Will have to take a look, I guess there are lots of potential setups. If you have a /64 per host it should be ok anyway, if you have a /64 for the network it might not be.
Link local addresses are not meant for application level use in IPv6 so bringing them up would only be confusing.
LL addresses are used for stuff like router advertisement, neighbour discovery (IPv6 equivalent of ARP) etc. You can't use link-local addresses without extra gyrations in socket API (scope id) so they cannot be usefully passed to normal apps.
I am not sure you need to. If each machine has a /64, then each can assign that on the docker0 bridge and run radvd which assigns addresses to the docker containers (from the /64 or eg a /80). I dont see radvd needs changes; you should be able to even run it on its own docker container.
I think the issues are more around the fact you may need to change existing addresses, plus potentially split up the /64 (or whatever) your machine has among docker bridges, plus you need to make sure the /64 is no longer on the external interface.
As one of the maintainers in question, I'd absolutely mirror this whole statement: if any of the image upstreams have an important update available that isn't applied, we're very interested in rectifying that.
This question was asked on https://github.com/docker-library/golang/issues/11#issuecomm... too, but the main reason is that the "debian" base images are tightly controlled and kept really minimal, so it's easy to make the new images as minimal as they can be too. The Ubuntu images are also great, but they include more stuff as part of keeping a consistent experience, so they don't have the same focus on minimalism that the Debian images can.
Note that the image maintainers (starting with tianon above) reserve the right to change the base distro they use for the images. So they can truly use the best tool for the job, now and in the future.
Changing the distro underneath would break all other Dockerfiles that assume they are running on a certain distro. How do we have to deal with cases when the distro is switched from debian to centos for example?.
"Moving" is a bit of a strong word. It would be much more accurate to say "providing alternatives". For example, the "golang" image now has an "alpine" variant for each supported version (https://hub.docker.com/_/golang/), but the default variant is still Debian-based (especially given that switching the base outright would break far too many existing Dockerfiles). Additionally, the documentation calls out that there might be libc compatibility issues in the spirit of trying to ensure our users are properly informed about the potential problems they might run into in their quest for the smallest possible base: https://github.com/docker-library/docs/blob/b7b6b86124682ef1...
I would definitely welcome PRs to make this verbiage more accurate or more informative of pros and cons.