IPv6 publish forwards incorrect ip

IPv6 publish forwards incorrect ip. It's just the IPv4 of the host, not the IPv6 of the client which it should be.

Sorry for yet another rant, but will you ever start taking IPv6 seriously? I feel like half of my tickets are IPv6, because each day I'm discovering how more atrocious docker's current support is.

People have to use publish because of your other glorious decision, public but random IPv6 address assignments. (who ever thought that was a good idea?) And due to your additional insightful decision to not easily allow optionally specifying a fixed IP, that is not a possible workaround for that either. And now publish is also just a half-baked horrible rushed implementation when using it for IPv6.

Really?

I'll just leave this here because people seem to be forgetting:

• http://arstechnica.com/business/2015/09/north-america-is-out-of-ipv4-addresses-for-really-real-this-time/
• http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/
• http://arstechnica.co.uk/business/2015/07/bt-begins-trial-of-ipv6-as-ipv4-address-exhaustion-looms/

[thaJeztah]

I realize this won't solve your problems directly, but proper IPv6 support is one of the goals for the next (1.10) release. The foundations for better support are added in the 1.9 release with a massive rewrite of the networking model in lib network (additional improvements coming in 1.10 as well).

Just to explain it's on the radar, but one step at a time. You can check progress (or help with development) in the LibNetwork repository https://github.com/docker/libnetwork, or discuss issues in the #docker-network IRC channel.

/cc @mavenugo @mrjana

[timcoote]

fwiw. Despite the apparent design goal of stable IPv6 addresses, it looks like ISPs are intent on breaking the assumption that they will be stable. This will create issues as it means that all programs will need to add another layer to get the name binding right. So unpredictable IP addresses will need to be coped with in the general case. I'd guess that this means either using some local discovery mechanism (Zookeeper? etcd?) or something more global (dns? doa?)

Also, it should be noted that IP addresses (v4 and v6) are not properties of hosts. They are properties of interfaces. Identifying hosts by IP address is difficult, except for special cases.

Facebook has found that it is getting benefit from starting with IPv6 versions of its code (the FB AS's are nearly 100% ipv6, and they've measured 30% better performance for users connected by IPv6 compared to IPv4).

Well but none of that is an excuse to replace the IP entirely with a v4 variant of the forwarding host. IPv6 addresses aren't reliable? Oh great, then let's break them even more!

[timcoote]

indeed. I'll try to read the notes that theJeztah has pointed at.

Just a small poke since 1.9 is out and I suppose work on 1.10 has started - it would be really really good if this could be finally addressed. (as written above, it would be instrumental in making the random public IPs problem much less of an issue if this worked properly, and it would make the behavior much more parallel to IPv4/what people are used to)

[schwebke]

are there any news regarding IPv6 support for exposed ports? My dockerized webserver with exposed port 80 sees the correct IPv4 client address, but in case of a client connecting over IPv6 just the IPv4 ip of the host (docker version 1.10.3).

@thaJeztah any news available on this?

[thaJeztah]

@Jonast Docker 1.10 allows you to specify an IP-address for a container (using the --ip and --ip6 options on docker run and docker network connect - also see https://docs.docker.com/engine/userguide/networking/work-with-networks/, would that solve your case?

No. For two reasons:

1. I have many services that need to be reachable under the same host (the microservices movement means splitting up even stuff traditionally operating under one host into many containers). This can't be easily set up without port publishing working. DNS for a single host can't magically point to multiple IPs.
2. EXPOSE making ports reachable from the internet with IPv6 is a serious flaw and a really dangerous default choice which has the following likely outcome that is unacceptable: it makes it much harder to make supposedly "hidden" internal backends only reachable through a proxy for security reasons which works trivially with IPv4 docker, and it will bite a lot of people who are used to their IPv4 setups and aren't aware in this radical change in behavior who will inavertedly expose sensitive backends to the internet. Therefore I'm both advocating a change of that not happening per default, and I'll use iptables to make other containers except my main gateway unreachable apart from minor exceptions - which means I need to rely on properly working port publishing to work.

So yes, please fix this. Even with --ip and directly reachable EXPOSEd ports (which again as above is a huge problem of its own and IMHO a big mistake to have it work that way per default) it has its uses and you lose a lot of flexibility without it.

Also let me note I think NAT Is a bad idea too. But IPv6 containers could still have sensible iptable defaults to not put them right into the internet without explicit user request, by e.g. simply blocking all TCP/IP connections not initiated by the container, and adding some new option that allows them to be reachable from the internet if desired. And unless you fix port publishing, this can't be addressed easily, since it is often required in a setup where containers aren't all directly reachable from the internet...

[robbertkl]

It's not just EXPOSEd ports that are publicly accessible. The container gets a publicly routable IPv6 address, meaning anything that binds to this address (or binds to everything, [::]) will be available to the world, unless additional firewall/filters are in place. Even ports that aren't EXPOSEd.

To me, the issue of publicly accessible IPv6 containers is a different (although related) issue to the current issue: published ports not working / not working correctly, which is now being continued at moby/libnetwork#1099.

It's not just EXPOSEd ports that are publicly accessible. The container gets a publicly routable IPv6 address, meaning anything that binds to this address (or binds to everything, [::]) will be available to the world, unless additional firewall/filters are in place. Even ports that aren't EXPOSEd.

Ok, I made a ticket for that here: #21951

[robbertkl]

I've created docker-ipv6nat to address both the issue of publicly accessible container ports, and the incorrectly forwarded IP. I know NAT for IPv6 is not "the way to go", but this does fix published ports and other issues with IPv6, compared to IPv4. Until Docker has good, practical alternatives to NAT (which I welcome!), you could give this a try.