ipv6 instructions broken #6075
Comments
|
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. 😉 |
|
Ugh. docker/compose#4958 |
|
Closing this ticket due to its age, and the impending refactor. If you think this is in error, feel free to reopen. Thanks! |
ghost
closed this as 
|
Where can we follow for news about the refactor? |
Please don't. Would be better to close it after the refactor is in place and known to work. 😄
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? 😄 |
|
Just ran into this issue today when I only want ipv6 link-local addresses. |
bermudezmt
added
the
area/compose
|
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: 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: Also remember, that this is not NATv6 (thank god!). Therefor you will have to have a route from your router to your docker host! |
|
@hr1232 That sounds potentially really good. 😄 Which version of Docker have you tried this on, so it's "known good" with? |
|
I'm on Debian Stretch and use the most current version in the repositories. |
|
Thanks @hr1232, that's good info. There's now a reference point for people to work from. 😄 |
|
@justinclift There actually is a reference, but it is wrong. According to the documentation, you only have to add the 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 |
|
Yeah, personally speaking I pretty much marked it off as "not fit for purpose" and moved on to other things. 😉 |
|
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. |
|
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. |
A bold statement. 😉 |
|
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. |
|
@hr1232 I agree the documentation is highly confusing. I have been unable to get traffic to egress from a user created bridge. I am sure it is my new-ness to linux and docker routing that is the issue but after 10 hours on this i am kind of read up and researched out. For example the comments in this thread appear to suggest that the following only applies to the default bridge and not user created bridges? { (note by default my docker platform doesn't have this enabled, but i have played with having it on and off) If that is so then then doc needs to clearly state it as i enabled this and was messing around for hours on user created bridge. On my user created ipv6 bridge, the container gets an IP at the beginning of the range and can ping the gateway defined inside the container. Heck i even get full ipv6 name resolution for external IPv6 addresses and full ICC IPv6 name resolution AND traffic flowing between multiple containers on the same bridge. On the default bridge i enabled the ipv6 section in dockerd.json and got stuck in exactly the same place. What i don't have is any form of routing out or back into the container. Or what i am supposed to do about it!? It isn't clear to me which commands are executed on the host and which in the container. It is also possible i messed up on IPv6 itself, my PD issued subnet is: My subnet i am using the containers is 2601:xxxx:xxxx:7c80::500/120 I assume this is ok as there is nothing to say don't do this... i tried and failed to figure out what the IPv6 equivalent is of 192.168.x.x. is... and what the notation would be.. aka fd00, fc00 - maybe an example showing how to use these AND get routing but given there is no ipv6 NAT i assume these are useless for egress to internet? While i don't expect steps to tell me how to do it on my router - i do expect the basic sketch of the procedure.. For example i would expect see a default ipv6 route in the containers routing table but i don't... and it won't let me add one, or rather if it can i can't figure out the exact command. My point being the documentation is incomplete in that it should either say ipv6 is only for internal traffic on a user created bridge OR 'here is the outline on how to get it; routing. root@debian-ipv6:/# ip route root@debian-ipv6:/# ip addr I think i will be using macvlan for now as that allows a single container to talk full ipv6 with ease! |
You have to assign a gateway and subnet to you docker network manually. You have to make sure, the subnet ist routed from your router to the docker host. You have to create the route manually on your router because Docker will not use SLAAC!
ipv6: true; applies to all bridges.
In that case you will never be able to get packets out because without ipv6: true; there will be no ipv6 routing available.
Correct
If you don't have ipv6: true; set, this ist exactly what you will see. Without IPv6 routing activated you will not have IPv6 routing. Of course containers on your virtual switch will still be able to communicate amongst each other because switches don't care about layer 3 protocols.Name resolution is done through IPv4 (from the docker host towords the Internet). Note that you don't need an IPv6 capable nameserver to query AAAA records.
See above. You have to activate IPv6 routing (ipv6: true;) to have IPv6 routing.
Your router will have to know where to send answering packets. This ist neither NAT, nor dynamic routing.
See above in my earlier comment. You should know how to subnet your home network without creating conflicts within your home network. You than have to route the subnet you created towards your docker host. Then you have to do further subnetting to get one subnet for every docker network, including the default bridge, and assign them manually. Default bridge MUST have a subnet assigned, all other networks are optional. Also, you have to activate IPv6 on your manual networks during creation (--ipv6). This ist all very basic network knowlegde. It is not the job of docker docs to tell you that. It is the job of Wikipedia. Docker docs just need to tell you that Docker won't so SLAAC.
Again, if you don't activate IPv6 routing, you won't have IPv6 routing. As soon as you activate it, your containers will be taken care of by DHCPv6.
If you follow the instructions you will have egress capabilities. You did not activate IPv6 routing, so what do you expect? Take an old IPv4-only router and connect your PC. Will you then have IPv6 in you PC? I think Not. Will you be able to communicate via IPv6 with another PC through the router's internal Switch? Of course! Will your stoneage-router give your PC an egress route or will it Just magically appear in your PC's routing table? Probably not, but don't give up hope....
Result as expected. Please consult either man ip or man route.
Also as expected.
Completely non-sensical, but OK. Dont't learn, just use deprecated hacks and wonder why they stop working at some point in the near future. |
|
@hr1232 > Completely non-sensicle but OK. Dont't learn, just use deprecated hacks and wonder why they stop working at some point in the near future. No thats pragmatically using something that works for what i wanted to do (ipv4 and ipv6 enabled pihole with non port conflicts on host) - it worked quickly and easily. Moreover i am trying to learn so thank you for your patience - what may seem obvious to you isn't obvious to others - esp with vast amounts of conflcting information on the webs. For example in your docs is the first time i have manged to get the IPv6 routes displayed with ip -6 route show - other posts i followed were BS. I am currently in a state where, as i said, i do have the following section enabled: { I am fairly comfortable with IPv4 subnetting and i think i have done the IPv6 correctly,. I think i may be in the NDP scenario (as will almost all folks) as we will always be subnettings the scheme provided to us by an ISP - most of us don't have the luxry of the ISP giving us multiple independent /64 like you show in all the diagrams. If my scenario is indeed the NDP Proxying may i suggest you change the title of that section to indicate the outcome (Subnetting you ISP provide subnet) as it wasn't obvious to me until the 15th reading it might be my scenario - not because i am stupid, but because there is a vast amount of highly complex information to parse. though i am not sure i need to do the NDP as my host route table looks like this `alexb@SYN02:/var/packages/Docker/etc$ ip -6 route show
When i look at your 'routed network' example I note they have example route add comands tagged clearly against where to run them - doing the same in the NDP diagram might help - i don't expect you to tell me how to run mine or what IPs to use., i think i can figure that out (maybe not). I just need to a)identify which scenario documented i should be following and b)if i have all tne right commands. BTW i tried the NDP commands you have documented and it didn't fix a thing for me. You beat me for not trying to learn, well i am here to learn, please help and give some pointers. PS for example: |
|
I have tried running this on the hosts to no avail: sudo sysctl net.ipv6.conf.ovs_eth0.accept_ra=2 sudo sysctl net.ipv6.conf.ovs_eth0.proxy_ndp=1 sudo ip -6 neigh add proxy 2601:600:8880:7c80::502 dev ovs_eth0 |
Why would you do something like that? Please don't confuse the terms proxy and router. |
|
Thanks for replying Which of the commands should i have not run? Did my running them harm anything. After all i did documented in my previous post i have the router pinging the 502 machine (on the default bridge) and vice versa but not the 602 machine on the custom bridge. I ran the two extra commands above, no change. Also the doc implies they are not needed if one has modified the dockerd.json? |
|
ok i see why the 602 failed, i am a dumbass it should have been. sudo ip -6 neigh add proxy 2601:600:8880:7c80::502 dev ovs_eth0 serves me right for copying and pasting. Ok now i ahve this I can write it all up for all those synology folks wondering why IPV6 doesn't work when it has UI items - bloody synology never finished supporting the scenario. I will call it good, thanks for your help figuring out, hopefully the guide i will write will help mean less folks end up here. Any chance the NDPPD you mentioned would be standard part of docker (if it makes it simpler?) |
|
Hmm this is exactly the article I needed about 10 hours ago. Seems about right level... but seriously this is perfect. I never found it because a google would never turn a German doc up.... This is way better the formal docs. Still not sure why only the NDP method worked for me - maybe because I didn’t create a route on my router? I think the docs could be improved by starting with ‘if you are in this scenario do X. For most people getting started the instruction below will be the default.... |
|
Forget everything you EVER heard about NDP. NDP is a very foolish way of pressing IPv6 into the broken, outdated NAT-concepts of IPv4. Please remove every NDP-thing you did from your Docker host. It is not possible to use routing and proxying simultaniously. Also remember to activate IPv6 routing in the host via the 2 commands stated above. Lastly, call your ISP and demand to be given a prefix of 48-52 bits of length as is the RFC-default for end users. If they ignore you, try tunnelbroker.net, they will give you a 48 Bit Network for free. Alternatively, you can also add 32 to every bitmask in my examples but remember that this will rob your containers of the ability to use SLAAC internally because it will leave you with a 96 bit subnet in your docker networks. PS: you don't need the sysctl accept_ra command, either. This ist für SLAAC, but Docker uses DHCPv6 by Default. If you manipulate accept_ra that will only give you trouble with tbe Hosts external connection. |
That method has been marked deprecated for years. Therefore your Docker may stop working after any apt upgrade without any prior notice.
Always a good idea to consult man ip instead of Google. Only ask Google for specific questions, not for man pages.
If you anable routing AND NDP that won't work for you. With routing you give Docker a subnet for every docker network. With NDP you assign ip addresses from your external network and do something very dirty and awful - some mixture between NAT and Proxy.
Should Work but won't as long as you try to route and proxy an ip address at the same time. Hang on to my examples commands, just replace the prefix and the bitmask. Don't try to subnet within address blocks. If your ISP gives you /64 prifix, use the entire fifth Block (bits 65-80) for subnetting so you will end up with /80 subnets. Use a Block representing locally administered Mac addresses for routing to your Docker Host so you won't run into conflicts with your other devices doing SLAAC....
A) The only valid scenario is routing. There ist no NAT in IPv6 so trying to use it is nonsense.
In neither
Proxied IP-addresses (pseudo-Nat) is not routing. |
|
Thanks for all your pointers, and if that german articles was yours, thanks for that too! Oddly i have done both the NDP commands and routing commands (minus setting up a route on the router back to each bridges subnet as i stopped before doing that) it is all working. My next task is tear it all down and try just the routing and eliminate the NDP. My confusion was that because my ISP is Comcast (a US home cabled tv company) demanding anything from them will be next to impossible. It only leaves me the option of further dividing their provided /64 and the NDP is the only picture that matched my scenario. Yes i know proxied IP addresses are not routing,. To your point if it is the only valid scenario - that is exactly the issue with the document - it throws all scenarios at one including ones you have stated should not be used. I don't know why you have said i shouldn't try subntetting the ISP given /64 block? And yeah i get the issue with using deprecated mechanisms. (though as a point of order, the doc pages give no indication of this https://docs.docker.com/network/macvlan/ and the original github just says it was moved upstream to experimental and provides only a dead link https://github.com/gopher-net/macvlan-docker-plugin) And thanks for the tip on RA 2 - i didn't commit those syctls to file so a reboot will get me back to default :-) that may explain why the docker host interfaces suddenly became really slow at acquiring their IPv6 SLACC. Does beg question is there any plans to implement SLACC for docker? - i can go look in the issues list and see what the state of that conversation is like. Again thanks for your patience, i can tell this is frustrating for you, my only parting comments is don't assume folks are complaining about the docs to personally slight or attack you. Folks are finding the doc confusing from the angle of 'what should I do' and 'how does this relate to 'my' real world' AND yes one can argue the doc, like a man page shouldn't do that but hey that's us dumb masses for you. Thanks! |
That is, because your entire /64 subnet is in the same broadcast domain ("on the same wire") as your Docker host. If you do NDP Proxy/NAT your host accepts packets for these ip addresses and the kernel's internal routing does the rest to shove them into Docker. This only works with a /64 prefix, though. If your ISP was aware of RFCs they gave you something between /52 and /48, your home network would only have a /64 subnet and you would be in charge of routing the rest (or parts of the rest) towards your Docker host via a static route.
Even if you only have 64 bits, the correct way is to route a smaller subnet towards your Docker Host. Don't do NDP, just create a static route on your router.
When subnetting a 64 bit network you have to be aware of the inner workings of DHCPv6 and SLAAC. As you probably don't have static ipv6 addresses in your home network, you mustn't use any address space that may be used by your other clients in SLAAC. You also have to stay clear of any addresses your router may give to clients via DHCPv6 (that usually happens if a device doesn't support SLAAC or has been configured not to use it). DHCPv6 usually uses ::nnnn which you routed towards Docker. Don't use that. With SLAAC enabled, subnetting is a little more complex, as the last 64 bits consist of 12 bits for the mac vendor id, 16 static bits and 12 bits for the mac device id. With privacy extensions enabled, those 64 bits become almost completely random (appart from a few exceptions). Your best bet is to use a subnet that would normally be reserved for any Locally Administered MAC Address (LAA) as this area will never be used by SLAAC (with or without privacy extensions), nor by DHCPv6. For a given subnet 2001:db8:1:1::/64 an example subnet that is safe to use would be 2001:db8:1:1:600::/80. Just route that towards your Docker host and slice it into tiny subnets for each of your docker networks. Just be arware, that your containers will not be able to use SLAAC anymore because the subnets are to small (SLAAC needs 64 bits). You should be safe because Docker hands out addresses via DHCPv6, but you have to make sure that all of your containers support that, because DHCPv6 is not the default. Not every container's kernel supports it and those that do, may have it deactivated.
I thought we had established that the docs are incorrect and/or outdated. Also, NDP is not really a Docker thing, but a Linux kernel thing.
Internally, Docker sends out RAs towards the containers but they can only be used if the subnets in your docker nets are at least /64. Requesting entire subnets from your router and assigning them automatically to your Docker nets is quite complex. Also, most home routers don't support that, and most hosting companies have it disabled. So even if Docker could request subnets, chances are quite high that your router wouldn't be able to answer those requests. Also, RFCs forbid to create subnets smaller than /64 (because SLAAC won't work there), so even if your home router did support prefix delegation and Docker did support prefix requests, you would still have to get a bigger prefix from your ISP. The only home router I know of that really supports prefix delegation, is a high priced premium product, called Fritz!Box. Aside from the fact that your ISP probably won't spend 300$ on your router, that box is only sold in German speaking countries. |
|
Thanks. Again thanks for your help got it all working this morning with just routed on a clean synology system. My /120 subnetting works ok for routed (i tested this morning) i don't mind it doesn't use SLACC as the /80 wont use SLACC either. I guess i am lucky, my ubiquit router (not a home router that i have had for 3+ years) and the Asus home router before that have always worked perfectly with comcast IPv6 and their PD64 - not sure if this means SLACC worked or not. But again not relevant given the subnets won't have SLACC. Understand your point about if SLACC did propogate out of some future docker version i would need a higher range from comcast. As an aside part of the issue i had was i had not recognized that the Synology IPv6 implementation is very very flaky and often doesn't setup the right default routes on the host. I logged a support call on that this morning too - FYI for anyone else who gets here by googling. |
Your /120 subnet is still in conflict with the default DHCPv6 range of your home router. Use the /80 range proposed earlier to avoid ip address conflicts between your Docker networks and your home network. Ubiquity might make prefix delegations available if Docker ever supports prefix requests. AFAIK those functions are not planned for Docker, though. |
|
I had to think about that for a while and look at my IP addresses to understan. For example if I use I see that my router issues a machine an address like this: IPv6 Address. . . . . . . . . . . : 2601:600:8880:7c80::15f Why does it issue both? OK I will change to /80 as i now see issue - got it. Thanks. |
|
Yup already moved to /80. Also what RFC forbids anything smaller than 64? I tried to find and came up blank. I would like to read it so i learn more. The /80 doesn't really seem to be for this scenario (at least i have yet to find the explicit RFC) but rather it was a solution for IPv4 encapsulation - but i see why it works and why it avoids the conflicts you mention https://trac.tools.ietf.org/html/rfc7600 and why we can use it here - wow the RFCS for IPv6 have changed a lot since i read them last in 1997! It took me writing out the bit mask to understand why i was being stupid and of course i guess we should document here that one shouldn't use the 2601:0600:8880:7c80:0000:0000:0000:0000/80 as that also conflicts with the 2601:0600:8880:7c80:0000:0000:0000:0000/64 space! |
Don't use any /80 subnet, that's just as bad as using /120. You have to use a vendor id that represents a locally administered MAC range, e.g 2601:600:8880:7c80:600::/80
Because you configured your device that way. Not a problem of your router, but a problem of your device. You should configure your devices to use either DHCPv6 OR SLAAC. Default is to use DHCPv6 and fall back in SLAAC If No DHCPOFFER comes in. |
The old 2460 and the current 8200 both tell you how the lower 64 bits are used to create your host id based on the mac. Therefor you don't have those bits for your routing issues. They also tell you that end users should be provided with 48-52 bit networks so they can actually do subnetting. That's the closest RFC's come to forbidding things. Because they are not laws, you have to decide yourself If you want to follow them or not. |
|
ok, nice conversation, but it's 2020 and i still landed here because of the outdated documentation. can someone please take a look at it? thanks...! |
Thanks for this. It's the most concise explanation of what's going on that I've managed to find in a couple of weeks of googling in my free time. A few points I'd like to respectfully bring up, as someone who just installed docker for the first time a couple of weeks ago and only want it to run pihole--for which I need to handle v6 DNS requests.
My entire network uses dual stack v4 + v6 networking, with the v6 provided from my ISP via prefix designation. Everything is automatic and works perfectly, and any deficiencies are purely the fault of my router's software being old enough to make a few things tedious on initial setup. But it all works automatically once it's set up, and I don't have to worry about it. Again, with deepest respect to the people who work so hard to maintain this software, I don't really understand why the Docker daemon can't just be configured to run something like prefix designation for all running containers that request ipv6 support. I would hope a solution can be found to make v6 containerized networking just as transparent and easy to use for the end user as v4 networking. I know there must be a way. End users only care whether it works or not. Underlying technical implementation and philosophy doesn't matter to them. And right now, out of the box, with the current documentation, ipv6 networking is effectively broken for the end users. Users who are sophisticated enough to know they need ipv6 networking in docker shouldn't have to try to make it work with incomplete official instructions and the variability of host hardware/software in play. |
|
@johntdavis84 nice post, never realized it was that big an issue, had ipv6 working on my Synology outdated docker for nearly a year with macvlan and pihole containers. As you state the key is to statically subnet you ipv6 range appropriately and adding right next hop router to your router to point to host (anyone with a Synology I have a complete how to doc, pm me if u want) To add to your post I never got it working on default bridge only user created ones (btw folks NEVER use the default bridge for anything, that’s why y’all have crappy name resolution issues between containers, only ever use a bridge you create). |
|
Linux myhost 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux My Docker is behind a load balancer and a firewall (another host). I solved my problem thanks to the following link You can pick any IPv6, for the subnet calculation, I have used this site : You just need to concat: |
|
I think so.
Do the instructions at https://docs.docker.com/config/daemon/ipv6/ <https://docs.docker.com/config/daemon/ipv6/> actually enable a container to get and use an IPv6 address?
My understanding is that either (1) manual alterations of the host’s routing table, or (2) enabling docker’s ip6tables functionality are still required. That’s not presently reflected in the documentation.
I would think using the ip6tables method is the preferred way to go for most users, and to my knowledge this is still an experimental feature. I would suggest keeping this issue open until the ip6tables functionality is no longer experimental and the documentation has been updated to indicate how to use it.
… On May 5, 2021, at 7:43 PM, Piotr Andruszkow ***@***.***> wrote:
Is this still an open issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#6075 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGI5CYUIYDCOSZQGO7IEXW3TMHQZXANCNFSM4ESJW4MQ>.
|
|
I'd like to be able to spin up a Docker container with the following attributes:
Is this possible in 2022? I understand that SLAAC hasn't worked in previous versions of the Docker engine. However, if the Shouldn't FYI I'm using an Ubiquiti EdgeRouter X behind SpaceX Starlink satellite internet. IPv6 works great, but not (yet) in Docker containers. |
This was done in #11148. |
|
Closing the original issue as fixed. Feel free to continue the conversation in the comments. |
|
Closed issues are locked after 30 days of inactivity. If you have found a problem that seems similar to this, please open a new issue. /lifecycle locked |
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.
The text was updated successfully, but these errors were encountered: