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

ipv6 instructions broken #6075

Open
eylvisaker opened this issue Feb 25, 2018 · 16 comments

Comments

@eylvisaker
Copy link

commented Feb 25, 2018

File: config/daemon/ipv6.md, CC @johndmulhausen

If you follow instructions as written, it will prevent the docker daemon from starting. The instructions need to be updated to include the "fixed-cidr-v6" key with a valid ipv6 cidr value.

@justinclift

This comment has been minimized.

Copy link

commented Aug 10, 2018

Having also hit this today, when looking into enabling IPv6 for a swarm setup... it seems the IPv6 instructions used to be more comprehensive, but at some point were reduced to the current non-working single line version.

That single line approach seems like it might work, but only for specialised (non-default) configurations.

Some further info here: moby/moby#29443 (comment)

The IPv6 instructions should probably be made to work "out of the box" for default configurations, or at least be expanded out again to explain how to set up a non-default configuration that does support them.

In the meantime, people should probably use the older docs version that's more comprehensive. 😉

@justinclift

This comment has been minimized.

Copy link

commented Aug 10, 2018

Ugh. docker/compose#4958 ☹️

nolim1t added a commit to lncm/dockerfiles that referenced this issue Sep 16, 2018

@ghost

This comment has been minimized.

Copy link

commented Jan 2, 2019

Closing this ticket due to its age, and the impending refactor. If you think this is in error, feel free to reopen. Thanks!

@ghost ghost closed this Jan 2, 2019

@evaryont

This comment has been minimized.

Copy link

commented Jan 2, 2019

Where can we follow for news about the refactor?

@justinclift

This comment has been minimized.

Copy link

commented Jan 3, 2019

and the impending refactor.

Please don't. Would be better to close it after the refactor is in place and known to work. 😄

If you think this is in error, feel free to reopen.

Doesn't look like I have permission to reopen this, as the button isn't showing up.

@L-Hudson Would you be ok to re-open for us? 😄

@jedahan

This comment has been minimized.

Copy link

commented Feb 23, 2019

Just ran into this issue today when I only want ipv6 link-local addresses.

@hr1232

This comment has been minimized.

Copy link

commented May 24, 2019

As there are several tickets written by people claming that IPv6 is broken, here is the solution how to configure it corretly. Someone should change the documentation accordingly.

Docker IPv6 is working perfectly, it's just the documentation that doesn't tell people what to do in order to set it up correctly.

Docker will not do SLAAC (Stateless Address Autoconfiguration), nor will it use DHCPv6. As it also won't do NATv6 (thank god!), you will have to assign ipv6 prefixes to your networks manually. The default bridge network has to be assigned a network, you can do this by adding the following to daemon.json:

{
"ipv6": true,
"fixed-cidr-v6": "2001:db8::/64",
}

For any other network you might have, you can decide wether or not it will be ipv6 capable. To create an IPv6 capable network, do the following:
docker network create --ipv6 --subnet "2001:db8:1::/64" testnet

Also remember, that this is not NATv6 (thank god!). Therefor you will have to have a route from your router to your docker host!

@justinclift

This comment has been minimized.

Copy link

commented May 25, 2019

@hr1232 That sounds potentially really good. 😄

Which version of Docker have you tried this on, so it's "known good" with?

@hr1232

This comment has been minimized.

Copy link

commented May 25, 2019

I'm on Debian Stretch and use the most current version in the repositories.

# docker version
Client:
 Version:           18.09.5
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        e8ff056dbc
 Built:             Thu Apr 11 04:44:28 2019
 OS/Arch:           linux/amd64
 Experimental:      false
@justinclift

This comment has been minimized.

Copy link

commented May 26, 2019

Thanks @hr1232, that's good info. There's now a reference point for people to work from. 😄

@hr1232

This comment has been minimized.

Copy link

commented May 26, 2019

@justinclift There actually is a reference, but it is wrong. According to the documentation, you only have to add the ipv6 parameter and that is just wrong.

As long as Docker won't do SLAAC, DHCPv6 or NATv6 people need to know that they have to do more than just slapping on a simple parameter. The second parameter fixed-cidr-v6 is mandatory, so is the manual calculation of IPv6 subnets. Sadly that isn't mentioned in the documentation and leads people the the error message Error starting daemon: Error initializing network controller: Error creating default "bridge" network: could not find an available, non-overlapping IPv6 address pool among the defaults to assign to the network

@justinclift

This comment has been minimized.

Copy link

commented May 26, 2019

Yeah, personally speaking I pretty much marked it off as "not fit for purpose" and moved on to other things. 😉

@pandruszkow

This comment has been minimized.

Copy link

commented Jul 12, 2019

Why in the world do we have to specify link-local IPv6 addresses by hand over a year after this issue was opened? What is this, the 1990s?

IMO, if Docker is smart enough to figure out and assign a valid loopback IPv4 address, it's more than capable of doing the same for IPv6 addresses.

@hr1232

This comment has been minimized.

Copy link

commented Jul 12, 2019

@pandruszkow

First of all, the IPv6 addresses you assign are not link local. Docker will do that on its own, so will all containers. You do, however, have to assign a prefix from either the Unique Local Unicast range or the Global Unicast range for every Docker network.

Second of all, Docker does also not assign a lookback IPv4 address. It assigns a private IPv4 subnet and does NAT, except if you assign a routed IPv4 subnet manually.

You do have to do a little bit more with IPv6 because there is no NAT available in IPv6 if it is used correctly. Therefor Docker cannot just assign any Unique Local Unicast address and to NAT. Docker is not able to know which prefix you routed towords the Docker host. Therefor it cannot do that job for you - at least not without SLAAC support. And even if it had SLAAC, you would need a prefix with less then 64 bits in your host network to use SLAAC but most ISPs do only provide a 64 bit prefix to their customers and therefor SLAAC won't work. Providing 64 bit subnets to customers is against RFC (customers should get 48-56 bit subnets), but ISPs are not bound to follow RFCs and most don't.

That said, there is nothing to fix, except the documentation. Of course, Docker could be made SLAAC-capable and thereby easy the configuration in some cases where a large enough IPv6 subnet is available. However, that will do nothing for most users and they will still need to configure manually.

Either way, as you used the terms link local address and loopback address completely wrong, you obviously should read up on both protocols before trolling around and making such nonsensical comments.

@justinclift

This comment has been minimized.

Copy link

commented Jul 12, 2019

You do have to do a little bit more with IPv6 because there is no NAT available in IPv6 if it is used correctly.

A bold statement. 😉

@hr1232

This comment has been minimized.

Copy link

commented Jul 12, 2019

Not a "bold statement" but reality. NAT64 is broken crap and nobody wants to use it because of all the problems NAT is causing in IPv4. If you are talking about the missing SLAAC capability, the answer to why that won't help anybody is also stated above.

Also, the discussion is about the crappy documentation and not about wether or not @justinclift understands that NAT64 is nonsense, invented by people that don't understand IPv6 and try to stay in their broken IPv4 conventions. So stop aguing about things this ticket is not about.
@justinclift Also, please send my a link to where you think that the IPv6 RFC is talking abount a meaningful and correct use of NAT in IPv6 networks. Im waiting for your PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.