Possible deprecation of docker-ipv6nat #65
Comments
|
@robbertkl I think we should keep it up until built-in IPv6 NAT is rolled out for most distributions. |
|
Exactly, agree 100%! I wanted to use this issue to share findings on behavior of built-in IPv6 NAT. After confirming this tool is no longer needed, I wanted to deprecate it with a README message, but still keep it available until the built-in IPv6 NAT is widespread. |
|
We should also track moby/moby#41622 because this is the requirement to enable the IPv6 NAT in the docker daemon. Many thanks also for the great work on this project, it has made my work with IPv6 and docker much easier. |
|
Docker 20.10 with IPv6 NAT is out but it has some serious issues: moby/moby#41774 |
|
I was actually coming here to open a ticket about this very thing. :) The latest stable update on Manjaro included Docker 20.10, and I saw the new ipv6nat functionality--and read the long thread of people trying to figure out exactly how it should work, here: moby/moby#41622 It sounds like it's very much still experimental? I'm not sure how to check whether a feature is considered experimental or not? In the meantime, if we've been using (It's also amazing to me--in a good way--that the official Docker release is implementing IPv6 NAT after months/years of philosophical pushback about that NAT'ing IPv6 being Wrong®. Maybe it is in most contexts, but it's clearly the best way to go in Docker, given how seamless v4 NAT'ing is with containers. Thanks for all your work on this. I could never have used IPv6 before this point on docker without your work. :) |
|
I have no intentions of pulling the plug until we can all agree Docker offers the same functionality (and stability). Of course, I'll be hesitant to add new features to docker-ipv6nat when it might be deprecated "soonish". We're keeping an eye on the development within Docker, and currently have no reason to think it will break docker-ipv6nat if you keep it disabled. Thanks for the support @johntdavis84 ! |
|
Finally with release 20.10.2 the upstream IPv6 NAT seems to work now. If you want to give it a try simply add the following lines to the {
"experimental": true,
"ip6tables": true
}and configure the IPv6 the same way as for this container (see https://github.com/robbertkl/docker-ipv6nat#docker-ipv6-configuration)
|
|
There's a regression in 20.10.2: |
|
I’m very pleased to see how aggressively this is being developed/bugs are being squished. If this is going to be part of docker’s core functionality, it needs to be rock solid.
It’s especially nice to see given the previous resistance from some of the docker community to incorporating NAT-based IPv6.
Robbert, are they collaborating with you at all or drawing from your codebase, or did they roll this from scratch?
- JTD.
… On Jan 6, 2021, at 11:07 AM, J0WI ***@***.***> wrote:
There's a regression in 20.10.2:
moby/moby#41858 <moby/moby#41858>
moby/libnetwork#2607 <moby/libnetwork#2607>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI5CYVQ3WI35USCHL5PQJTSYSKFTANCNFSM4UHVYYOQ>.
|
|
No collaborating, I think they rolled it from scratch. That makes most sense, as they can mirror the internal workings of the IPv4 NAT. Docker-ipv6nat is set up as an external listener, so doesn't make much sense to draw from this codebase. I agree that it seems they're very much on top of things. Since the decision was made to make it part of Docker, they're taking it seriously. |
|
That makes sense. Thanks for taking the time to explain how these things work. I’m a relative Linux/networking newbie, and I feel like I’m starting to get a handle on the basics, but the intricacies of IPv6 especially, and how it is implemented across various systems, remains impenetrable deep magic.
I understand why IPv6 is so important, but I am deeply concerned that it’s so difficult to use compared to IPv4. That’s fine for commercial/professional deployments, but the current tools available do not seem anywhere near as accessible to home networking prosumers as the IPv4 tool stack is.
Docker-ipv6nat is one of the few “let’s make this easier” v6 tools I’ve found.
- JTD.
… On Jan 6, 2021, at 12:41 PM, Robbert Klarenbeek ***@***.***> wrote:
No collaborating, I think they rolled it from scratch. That makes most sense, as they can mirror the internal workings of the IPv4 NAT. Docker-ipv6nat is set up as an external listener, so doesn't make much sense to draw from this codebase.
I agree that it seems they're very much on top of things. Since the decision was made to make it part of Docker, they're taking it seriously.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI5CYVGKJEVDMVKH33SDHDSYSVHBANCNFSM4UHVYYOQ>.
|
|
Has anyone tried enabling IPv6 NAT for the default bridge network? In my case dockerd tries to execute a wrong command and crashes. Reported it here: moby/moby#41861 |
|
Hi all, With Docker 20.10.6 the ipv6nat function is fully intergrated (experimental). |
Thanks for the update. How does this compare to the earlier updates that enabled/tweaked IPv6 NAT? Is it considered feature complete now/lacking known bugs? I found this in the release notes:
|
|
The docker versions between 20.10.2 and 20.10.6 had some regressions with the user land proxy. Until now there are no know bugs for the IPv6 handling anymore. (At least non that I am aware of). I already used version 20.10.2 in a semi productive setup without any issues (with disabled user land proxy). |
|
Thanks for the info.
I have a VM running Manjaro I can test this in once it’s available there...
… On Apr 13, 2021, at 12:30 PM, Benjamin Böhmke ***@***.***> wrote:
The docker versions between 20.10.2 and 20.10.6 had some regressions with the user land proxy.
This issues are now solved and the daemon should work exactly as before with disabled ip6tables.
Until now there are no know bugs for the IPv6 handling anymore. (At least non that I am aware of).
I already used version 20.10.2 in a semi productive setup without any issues (with disabled user land proxy).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI5CYWQQWIVFIGWK7C4CTDTIR5TNANCNFSM4UHVYYOQ>.
|
|
I can confirm that Docker 20.10.6's ipv6nat implementation works, and it seems to work exactly like how this container was doing it. The only difference I have seen is that the |
|
Let's keep this issue open until NAT for IPv6 is available in upstream docker without experimental mode. 👍 |
|
now (20.10.7), I am using this experimental feature with docker-compose and it work perfectly! |
|
@chesskuo How do I make this work with docker-compose stacks (which use custom bridge networks)? My containers only get IPv4 addresses unless I use the default bridge network. |
You need to define an IPv6 subnet for the network: networks:
network:
driver: bridge
enable_ipv6: true
ipam:
config:
- subnet: fd00:abcd:ef12:1::/64
- subnet: 10.1.0.0/16 |
|
If you want to make the network persistent, so that it exists all the time (even when the container is not running), you can use the docker network create command to do the same thing.
This is useful if you have a number of containers that need to use the same network (e.g., if you’re running NGINX Reverse Proxy Manager in Container A and need to run a reverse proxy’d service in container B).*
*This might not be The One True Way® to do this, but it works.
…-- -- --
John T Davis
On Jul 20, 2021, at 8:40 AM, Mark Vander Stel ***@***.***> wrote:
How do I make this work with docker-compose stacks (which use custom bridge networks)? My containers only get IPv4 addresses unless I use the default bridge network.
You need to define an IPv6 subnet for the network:
networks:
network:
driver: bridge
enable_ipv6: true
ipam:
config:
- subnet: fd00🔡ef12:1::/64
- subnet: 10.1.0.0/16
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI5CYU2SAXDMK32NAKJYI3TYV4EFANCNFSM4UHVYYOQ>.
|
|
this is my network part of networks:
traefik:
name: traefik
attachable: true
enable_ipv6: true
ipam:
config:
- subnet: 172.100.0.0/24
gateway: 172.100.0.254
- subnet: fd00:dead:beef::/112
gateway: fd00:dead:beef::254 |
|
Thanks. Unfortunately this means we'll have to deal with IP addresses in For now, we only need IPv6 in CI (for outbound connections to IPv6-only servers), so we'll just connect all containers to the default bridge network to make it work: for container in $(docker ps -q -f "label=com.docker.compose.project.working_dir=${PWD}"); do docker network connect bridge "$container"; done |
|
I found out that
It seems that theres some difference in how the 2 implementations manipulate iptables, and yours seem to integrate better with wireguard. |
|
Just as a follow-up to my comment above, I found the problem to be the default policy set on the
Interestingly, the default FORWARD policy for IPv4 is set to ACCEPT also by docker (contrary to whats stated in this doc: https://docs.docker.com/network/iptables/#docker-on-a-router). TLDR: If your Docker host is also doing routing, jumping from As a fix I run this script when my network becomes active, but you may as well simply change the default FORWARD policy to accept. EDIT: Here the very succinct list of differences, since this post became rather long and the ticket is mainly about tracking differences:
|
|
Does this feature work with Docker Desktop v20.10.14 for Mac? I'm unable to connect to ipv6 hosts or ping it from the inside of the container, even if I put to the config |
I don't think it will. Docker for Mac runs in a virtual machine (xhyve), not directly in macOS. |
|
Something I noticed: If you use a ULA prefix for I guess the OS is smart and knows that a ULA address isn't supposed to be able to talk to a global address and therefore doesn't even try to in the first place. So then I tried it with the designated documentation prefix |
|
FYI I explained why it prefers ipv4 here: #78 (comment). It's basically glibc ignoring the standard to support a particular configuration (site local ipv6 that uses public ipv4 for internet access). This unfortunately breaks ipv6 NAT by default. |
|
Just a question, is this container still required for Docker IPv6 NAT or is it enough now to enable a ULA via the daemon.json as defined in the Docker Docs and the containes will have internal IPv6 addresses ? |
The upstream implementation in |
Actually, you shouldn't use Global Unicast Addresses under NAT66. It's against RFC4193. Something similar as manipulating gai.conf could be better. |
When is that an actual deal breaker though? That would only be happening on the docker host or from containers, not remote clients connecting.
Yes, for the default bridge at least you can apply the ]config shown earlier](#65 (comment)). You can set You may not need to assign IPv6 addresses to containers though (at least for ULA), as IPv4 for the containers network should work fine if your host has a single IPv6 address that you want to publish ports to like you would with IPv4, this will work properly (preserve the remote client IP) if you enable If you were to actually need publicly routable IPv6 addresses to each container, that can be done. Port publishing if used with IPv4 will still publish to host interfaces by default including the assigned IPv6 address to the docker host. While regardless of published ports IPv6 GUA addresses would be reachable unless you have a firewall active and specifically allow traffic through for those (port publishing bypasses firewalls though, so that may not be the case 😅 ) IPv6 GUA is also a bit more complicated if you've got a
At least with v23 of Docker the findings reported earlier seem incorrect. The This can happen because Docker enables If UFW is active, that also modifies some default polices like setting It's possible that while the commenter was experimenting between the two, these conditional behaviours applied causing the mismatch depending on how they approached the comparison. Or it's possible there was a difference with Likewise the
This can be done, you need to edit Personally until there is an official default pool, it's probably more portable to provide an IPv6 subnet explicitly than require someone to modify the default pools, as you need to declare the IPv4 ones too. There's also presently a bug with excessive memory usage if your IPv6 subnets in a pool would be many (eg: millions / billions) vs the 31 you get for IPv4 by default. That'll be resolved once they support initializing pools lazily on-demand. |
With the merge of moby/libnetwork#2572 we're finally 1 step closer to having IPv6 NAT built into Docker!
I'm creating this issue to track the release of this feature, and to figure out if there are any remaining use cases for this tool. If not, we can deprecate this tool in favor of the built-in functionality.
The text was updated successfully, but these errors were encountered: