Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please implement IPv6 NAT as an available alternative option when using docker with IPv6 enabled #25407

Closed
ghost opened this issue Aug 4, 2016 · 29 comments · Fixed by #41622
Closed
Labels
area/networking kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny status/needs-attention Calls for a collective discussion during a review session

Comments

@ghost
Copy link

ghost commented Aug 4, 2016

Docker's current IPv6 behavior currently still has the following outstanding problems:

  • it lacks -p/--publish and EXPOSE functionality similar to IPv4 (with non-EXPOSE'd ports being hidden, and -p/--publish only using the userland proxy which changes the source IP address to the userland proxy container which makes it near-useless for not all but some protocols because of security reasons - e.g. HTTP can deal with this with proxy headers, but other TCP-based protocols can't). This is a huge pitfall for many users of smaller servers who don't set up manual iptable rules but rely on docker to work as they have grown to expect it out of the box
  • it always requires setting up an entire IPv6 prefix which should always be available in theory, but in certain home networks it requires changing the router configuration to be able to trivially use a larger IPv6 prefix range from a single machine, and multiple lan / wlan interfaces on a laptop can make this task more complicated as well

Due to those and other reasons, it would be very nice if IPv6 NAT was added as han option (not a full replacement for the current IPv6 default behavior) which could be enabled by the user if desired, to perfectly copy the current IPv4 NAT behavior and resolve all of the things listed above and provide an easy to use standard behavior that "just works".

Please note I agree NAT for IPv6 is often a terrible idea in a larger datacenter where you write custom routing and address assignments anyway - which is why NAT should be an option, not a replacement for the current behavior -, but for small servers and laptops where people just want a working default solution, it would be a big improvement.

There is a temporary implementation available from @robbertkl as a privileged container that modifies the iptables rules on the host with automated container discovery using dockergen: https://github.com/robbertkl/docker-ipv6nat . However, it would be neat if this functionality was integrated into docker itself like IPv4 NAT.

(I created this ticket out of a discussion in ticket #13481 where you can read up more details on the previous discussion)

@ghost
Copy link
Author

ghost commented Aug 4, 2016

I tried to collect some outstanding IPv6 issue tickets which I believe would be resolved with the availability of IPv6 NAT:

While those issues would still not necessarily be resolved for anyone not using NAT, this could be clearly documented and then everyone not choosing to use NAT would have clear knowledge that they are expected to do a bit more of effort for custom routing and firewall rules with iptables if they want to choose that approach. (people with non-NAT interests are mostly those running larger datacenters with custom routing setups anyway)

@justincormack
Copy link
Contributor

See also #13481 where this is discussed.

On 4 Aug 2016 3:54 p.m., "Jonas Thiem" notifications@github.com wrote:

I tried to collect some outstanding IPv6 issue tickets which I believe
would be resolved with the availability of IPv6 NAT:

#17666 #17666 (-p/--publish
forwards incorrect ip)

#21951 #21951 (EXPOSE and
publish need to behave similarly with IPv4 and IPv6 [Security design
failure])

While those issues would still not necessarily be resolved for anyone not
using NAT, this could be clearly documented and then everyone not choosing
to use NAT would have clear knowledge that they are expected to do a bit
more of effort for custom routing and firewall rules with iptables if they
want to choose that approach. (people with non-NAT interests are mostly
those running larger datacenters with custom routing setups anyway)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#25407 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcPD0eWdeuAK5VNz4W10-ZwRYdxmloks5qce8mgaJpZM4JcrNW
.

@narqo
Copy link
Contributor

narqo commented Aug 4, 2016

Let me say that the issue is tightly coupled to moby/libnetwork#1183

@thaJeztah thaJeztah added kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny area/networking labels Aug 4, 2016
@ghost
Copy link
Author

ghost commented Nov 7, 2016

Is there any progress on this? It would be nice if this was eventually added. As described above it's not really a revolutionary feature or anything that someone running a big data center setup would need, but it would really go a long way of making docker more easy to setup for beginners and small server owners.

@cpuguy83
Copy link
Member

cpuguy83 commented Nov 7, 2016

ping @docker/core-libnetwork-maintainers

@thaJeztah thaJeztah added the status/needs-attention Calls for a collective discussion during a review session label Dec 13, 2016
@michael-batz
Copy link

Are there any news on that issue? This would be really a nice feature.

@mattlqx
Copy link

mattlqx commented Feb 15, 2017

A use-case for this feature would be for in Amazon EC2 since they have recently widely released IPv6 addressing. Unfortunately, they only allow you to assign individual IPv6 addresses (/128) to EC2 instances. You also cannot add routes for IPv6 subnets (for instance a /80 of the VPC's /56) to EC2 instances within the VPC's routing tables. These two limitations make IPv6 NAT the easiest solution for container connectivity on an EC2 instance.

@mostolog
Copy link

mostolog commented Mar 8, 2017

Hi

Trying to deploy docker with IPv6, but have found a few issues.

IIUC, and according to https://docs.docker.com/engine/userguide/networking/default_network/ipv6/ setting --ipv6 on docker daemon would enable IPv6 for docker.
As we haven't DHCP (for ipv6: SLAAC?), daemon fails to start, so --fixed-cidr-v6 must be provided.

/etc/systemd/system/docker.service.d/ipv6.conf

...
ExecStart=
ExecStart=/usr/bin/dockerd --ipv6 --fixed-cidr-v6 2001:db8::/64
...

At this point, docker is able to start and containers will get valid IPv6 addresses but containers aren't able to ping outside world/beyond docker host.

It seems that as IPv6 doesn't have NAT, outgoing requests would be using internal docker IP/network, but target doesn't know where that network is located, so it cant "return".

So, to being able to go beyond host, ndp_proxy can be enabled

sysctl net.ipv6.conf.eth0.proxy_ndp=1

and a neighbour proxy must be declared for each specific IP

ip -6 neigh add proxy 2001:db8::c009 dev eth0

So now, we are able to ping6 www.google.com within container.

Adding each container IP manually as a neighbour - IMHO - its painful, horrible and kills a few cats each time is done. To avoid that ndppd is suggested.

Wouldn't it make sense docker adding and removing those neighbours automatically?
Have anyone considered working on moby/libnetwork#1159 / moby/libnetwork#1316 ?

Wouldn't IPv6 NAT solve this issue also?

Moreover, swarm mode provides HA for docker services. ie: any docker host can answer to a request, no matter if container is running on another hosts.
On the other hand, seems docker still needs a HAProxy to HA docker hosts.

Is there any issue open to provide HA for docker hosts? Maybe a daemon configuration for IPVS could be a good alternative to fix this. Is anyone working on this?

Anyway, setting IPv6 networks on daemon requires setting different networks on each host, and requires adding ip routes to being able to use IPv6 between docker on different containers.

May this comment be a request to improve docker IPv6 and swarm mode stack, I'll happily help testing anything you may need.
Regards

@aboch
Copy link
Contributor

aboch commented Mar 8, 2017

@mostolog

FYI, @CtrlZvi has an open PR for automating the ndp_proxy programming: moby/libnetwork#1316

EDIT: Oh, I just realized you were already pointing this PR out
Please feel free to take over the change, submitter has not gotten back for a while now.

@ghost
Copy link
Author

ghost commented Mar 9, 2017

Since it has been almost a year, is anyone looking into this? It would be really neat to have, given IPv6 has now some actual real world usage...

And as far as I am aware, without this there is still no neat way to easily run a docker dev environment with full IPv6 connectivity without lots of pain. You either have to manually add routing of some sort, or accept that EXPOSE doesn't work, publish doesn't work, running multiple microservices in separate containers on the same ip doesn't work... none of which is a problem in a production environment with a custom routing setup and proxies etc that make all of those things work again in various other ways, but definitely a big problem on a dev machine where you just randomly throw up services to test and work on them.

@mostolog
Copy link

mostolog commented Mar 10, 2017

Regarding swarm IPv6 connectivity, as described in https://docs.docker.com/engine/userguide/networking/default_network/ipv6/#docker-ipv6-cluster, some routes must be managed externally to docker.

As a temporary workaround to improve swarm and IPv6, and making it possible docker to create host's routes automatically, couldn't it use IPv4 connectivity to retrieve host IPv6 and docker networks IPv6's and send them to the manager?

  • (nodeA) docker swarm init
  • (nodeB) docker swarm join
  • (A) get host IPv6 address and docker interfaces IPv6
  • (A) as IPv4 connectivity is working, send that information to manager
  • (B) send IPv6 information to manager
  • (A and B) create routes to docker IPv6 networks using host IPv6 networks automatically in the way a user manually would do: ip route IPv6-docker-network via IPv6-docker-host

@BenediktS
Copy link

+1 for the request

1und1 servers only get one ipv6 address. I want all my dockers to use ipv6, but i don't want to start all ip6tables rules by hand (I think a "-p 443:443" at startup should do the trick).

And even if i get more then one IPv6 address, i couldn't say "DNS your AAAA record is one of many xx:xx:xx/64 addresses. But i don't know which one."
And i can't use "--net=host", because some other things won't work with "--net=host" (ie: rsyslog)

I consider docker ipv6 as broken, until this "feature" is implemented.

@jojoob
Copy link

jojoob commented Apr 12, 2017

I also run into problems caused by the lack of the IPv6 NAT feature.

I have a postfix container running on a host. IPv6 is enabled and the SMTP port is exposed via -p 25:25. I expected that exposing ports with IPv6 will work like with IPv4. But a test via telnet -6 localhost 25 on the host machine showed that docker act as a proxy to route the connection via the IPv4 bridge (postfix log shows a connection attempt from the IPv4 docker container gateway address instead of the IPv6 address of the docker host).
https://github.com/robbertkl/docker-ipv6nat solved the problem for me.

@chrisnew
Copy link

@jojoob great finding! I just tried it out and it works like a charm.

@wrridgwa
Copy link
Contributor

I agree with @BenediktS. Without NAT/Masquerade/port forwarding available for IPv6, Docker doesn't support IPv6.

@wrridgwa
Copy link
Contributor

I am working on a patch for this. What kind of testing occurs to get through the Docker open source process?

@chrisnew
Copy link

@wrridgwa you can propose your patch by opening a pull request where it should pass all tests. Also you should have a good test coverage as well as some documentation. Thanks for your commitment!

@wrridgwa
Copy link
Contributor

Here is a pull request with the fix: moby/libnetwork#1992

@ghost
Copy link
Author

ghost commented Oct 20, 2017

Oh that's so neat!! Any chance this could get merged? ❤️

@pznamensky
Copy link

Are there any news?

wrridgwa added a commit to wrridgwa/libnetwork that referenced this issue Nov 28, 2017
Signed-off-by: Billy Ridgway <wrridgwa@us.ibm.com>
@wrridgwa
Copy link
Contributor

wrridgwa commented Jan 8, 2018

@pznamensky Still waiting for Docker people to move the pull request along.

@ghost
Copy link
Author

ghost commented Feb 19, 2018

It's a shame it's just sitting here, more or less finished. I have been waiting for this feature for years 😢

@amjd
Copy link

amjd commented Mar 7, 2018

This is a really important feature for Docker and it's a shame it's not supported yet. Could the maintainers please take this on priority? A lot of people are blocked from using Docker with IPv6 in production because short of having a subnet on the host machine, all other ways seem to be temporary workarounds.

@PacAnimal
Copy link

Bumping this, as it's a very important feature. The world is moving to IPv6, and docker containers should be able to easily access IPv6 servers without fiddling about with manual IP assignments. I know IPv6 NAT is a problematic proposal in many ways, but for rapid prototyping and ease of use it should definitely be available, while not recommended for production use.

@ghost
Copy link
Author

ghost commented Jun 19, 2018

@b01t it's already implemented, but the docker people just don't merge it, which is disappointing. (sorry if I sound a little frustrated...)

@chris42
Copy link

chris42 commented Sep 16, 2018

+1 Can only add to that.
Just setting up docker with ipv6 within Amazon VPCs.
Right now their incoming routing is wired to the assigned IPs of the instance. Hence a prefix delegation to docker is not possible and incoming traffic is lost.
Only option to make it work, is NAT on the instance you run docker. Creating the rules manual is possible, however annoying. A switch feature within docker would be appreciated.

@amjd
Copy link

amjd commented Nov 10, 2018

Hi, is there any plan to implement this? It's already been 2+ years since this issue was raised and a lot of users have requested this. I understand the project maintainers have their own priority, but could we get a comment on whether this is planned and if it is, when it's targeted?

@ghost
Copy link
Author

ghost commented Nov 10, 2018

@fcrisciani may I ping you on this? you indicated this would be considered for future plans, but that was many months ago (Edit: the pull request here moby/libnetwork#2023 to be specific)

@KyronNextLevel
Copy link

Hi. I have struggled for some weeks to understand why I couldn't ping the outside world with an ipv6 container. I had the exactly same issues as @mostolog 's ones. As an internship student, discovering docker by doing some tests in ipv6 containers is really painful... It feels like we can make this works only with error prone hacks at the moment... I have read some similar issues and I don't understand why two years after, this issue is still relevant and referenced. As @Jonast said, ipv6 support should be a priority and you have several companies wasting a lot of time to make it work.

@ghost ghost mentioned this issue Apr 14, 2020
9 tasks
bboehmke pushed a commit to bboehmke/libnetwork that referenced this issue Jul 18, 2020
Signed-off-by: Billy Ridgway <wrridgwa@us.ibm.com>
bboehmke pushed a commit to bboehmke/libnetwork that referenced this issue Jul 19, 2020
Signed-off-by: Billy Ridgway <wrridgwa@us.ibm.com>
Signed-off-by: Benjamin Böhmke <benjamin@boehmke.net>
cpuguy83 pushed a commit to cpuguy83/docker that referenced this issue May 25, 2021
Signed-off-by: Billy Ridgway <wrridgwa@us.ibm.com>
Signed-off-by: Benjamin Böhmke <benjamin@boehmke.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/networking kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny status/needs-attention Calls for a collective discussion during a review session
Projects
maintainers-session
  
Awaiting triage
Development

Successfully merging a pull request may close this issue.