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
IPv6 iptables config option #41622
IPv6 iptables config option #41622
Conversation
Signed-off-by: Benjamin Böhmke <benjamin@boehmke.net>
@arkodg @thaJeztah PTAL Also I am not sure if there is also changes for the documentation needed. |
I see a |
The swagger part seems to be more for the API of the docker daemon which should not be changed here. The the documentation that maybe have to be updated are this 2 sections in the docker daemon documentation:
If you can give me a hint how this is updated I can also add a change for this. |
ah good point |
ptal @tiborvass @thaJeztah |
@arkodg I directly created a PR for the documentation change -> docker/cli#2846 I hope this is enough (and it was the right position for the change). |
yah that should be good enough imo, thanks for the proactive change |
@arkodg does this feature require additional dependencies to be defined in the packages, or can we assume that if iptables is present, ip6tables is as well? Also; does the |
Thanks for checking! Discussing this in the maintainers meeting, and we're considering to mark the feature as "experimental" for the initial implementation, as it didn't have testing yet, so there could still be issues with it. |
Will it be possible to specify a single IPv6 address for |
Very interesting idea, @ell1e -- are you thinking the containers would just have use link-local IPs instead? (I'm just clarifying the idea, the question itself is likely better for libnetwork maintainers as to whether it's possible |
Yes, in fact I would have assumed that would be naturally the case with |
@ell1e I currently only tested with a single public IPv6 by setting the The only thing is that it is currently required to define a fixed-cidr-v6 otherwise it will not work (because there is no default subnet specified). Edit: This should of course also work with docker networks. |
Ok, so wouldn't it make sense if omitting |
yah in the future we could possibly use a subnet within |
I wonder, maybe it might even be worth having docker print a warning if a non-private v6 subnet is specified in combination with the NAT6....? In case some folks migrate their old config keeping their Edit: please note I don't think it's a good idea to make |
just realized that we have some iptables related integration tests here moby/integration/network/network_test.go Line 96 in 6c0a036
could you maybe add one more (with this dockerd setting enabled) to give the feature more life :) |
Per the comments above, I removed c2b421e072586bfd9be64cf8fa2b17718d9686ed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I think it would be better to by default implicity set Rather, I think it would make more sense to require those to use Otherwise, the options are just going to be an even more wild unusable mess than they already are now IMHO. I mean, sure documentation can help and it's great the feature is now there at all, but I think if you're not optimizing the options for the likely most common use then you're setting yourself up for confused tickets for years (since now is probably the latest moment in time where this can still be changed without messing up everyone's launch options in real deployments later). Edit: different idea which I didn't put at first because it will break more people's pre-existing stuff, but I think this is how it would be in an ideal world: 1. rename But I'm not sure how it would be possible to deprecate the old Edit 2: just to spell out the latest, "ideal world" idea, in full detail, this is how it would work: Experimental features off:
Experimental features on:
|
Let's not over-complicate things if possible. What's the current state of things? As I understand it, those who want to use IPv6 must use both If that's true (and I am by no means an expert), then to use IPv6 without any specified CIDR I would expect To use a specific IPv6 CIDR, use of If someone wants to specify their own IPv6 CIDR and do NAT, then there should be some new way to explicitly turn it on, like It would be okay to specify Summarized, I think this is simplest...
|
I agree there's a ton of room for improvement/adjustment in Docker's IPv6 support (and I want to see it!), but this PR is just adding a flag to enable one bit of optional new behavior that wasn't previously available, so I don't think it makes sense to make any drastic changes in this context (and is why I've added my own "LGTM" to this PR, especially with the new flag under experimental). I think the overall experience improvement discussion should probably move to a separate issue(/PR). |
I like this idea. While I think the options I suggested conceptually make slightly more sense, this one is very practical to add in without breaking old configs while addressing my main concern (which is that @tianon is it common to rename options around again of experimental stuff, though? There might be some merit to get it right the first time, maybe. (I'm not familiar enough with how docker is commonly maintained here.) But I'd be happy to put it into a separate issue, I'm just wondering if that means it won't be addressed for another ten years because then many are already used to the "weird" options. |
There are currently two options to use ipv6:
Based on this it is possible to enable ipv6 only for specific networks without enabling it for the default bridge. The Maybe this can be changed in the future but I have no idea if this is possible at all. In my opinion the |
Interesting, is there a specific reason why it needs to be like that? Ideally I think the most useful way for this new thing to work would be to have one easy option to enable it for everything, exactly like IPv4, including for the default bridge and other places. This would also work nicely with @tomalok 's option suggestion that promotes a single |
Absolutely - the whole point of requiring "experimental" for flags is to let users test them early while they're still completely subject to change (or even removal). |
@ell1e The current IPv6 implementation is build this way, that if you set this option on the daemon only the default network will have IPv6 and the user created ones not (at least if not configured explicit on network creation). In some setups (especially for the first steps with IPv6) it can be a good idea to do not change the default bridge but do first tests with a separate network with IPv6 enabled (this was the way I started with IPv6). Maybe default values the IPv6 cidr would make the situation a bit easier but this is not present so far. |
So are there any objections for merging this as-is? |
lets continue the discussions of default IPv6 flags in a separate PR / issue since reaching a consensus for it here is gating the IPv6 NAT feature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; let's merge this one
Could someone open a ticket to describe and track improvements that we want to make? I'm trying to follow the discussion, but perhaps someone could write up something
@thaJeztah I made a ticket here, I hope that will be suitable: #41754 (if not feel free to close it & replace it with a better one) |
Thanks! |
Hey team, Just wonder when (by date or by release) you plan to make this implementation as non-experimental (remove parameter "experimental")? Thanks a lot. |
For the record, I answered @WallaceSUI question here: #45384. |
Note: This requires pull request #41604 to be merged first(already merged)- What I did
Added an config option to enable the IPv6 iptables rule creation based on moby/libnetwork#2572.
This should close #25407.
fixes #21614
- How I did it
Add a config option
ip6tables
(likeiptables
for IPv4) which can be used to enable the IPv6 iptables rule creation.By default this option is disabled too keep backward compatibility.
- How to verify it
To enable this functionality it is required to enable ipv6, set a fixed cidr and enable the ip6itpables.
This can be done for example via CLI parameters on the daemon:
or by setting the configurations inside the
daemon.json
.Now a container can be started and if a port is published the IPv6 NAT iptables rules are also created.
- Description for the changelog
--ip6tables
enables IPv6 iptables rules (only if experimental)