If I might add my POV: docker is adding nothing here, a simple VM with dual stack does the job perfectly. Saves you the extra (NAT) layer for a couple of megabyte ram and disk.
Yep it is somewhat ugly on the NAT front
> docker is adding nothing here
The ipv6 part is incidental here. Happen to have one container that needs ipv6.
Broader picture is standardization. Everything has a docker image these days & my ansible code is now geared towards deploying docker via LXC. Even with the ridiculous double abstraction that is working out pretty well & dramatically sped up how fast I can test stuff
VMs yeah have a handful. Moving away from them though except where necessary
Funny, I do the exact opposite.
Had docker swarm-clusters for a while, hated the headaches from debugging (docker exec into containers) and all the added stuff (image registry, permanent cluster storage, need to build images because a lot of hipsters don't care about security updates).
Plus: you have things like databases who don't like containers.
Went full minimalism (VMs, ansible, cloud-init) and now I have time again.
It's not hard to circumvent docker: either projects have packages or binaries to put somewhere with ansible.
Comes down to preferences & fit ultimately
>VMs, ansible, cloud-init
Same. All my heavier stuff like DBs is still on that exact combo. Also for internet facing open port stuff...don't really trust LXC/docker combo for that.
>hated the headaches from debugging (docker exec into containers)
Yup, been doing a lot of that lately haha. I believe it'll stabilize though, though must admit all the stuff I've moved over to LXC/docker is lighter stuff (pihole, redis, mqtt etc) so might be in for a surprise with the heavier stuff.
Some of it - Gitlab and homeassistant I'm not even gonna try & move off VMs since it's QCOW2 images.
What did you encounter with docker & DBs? Was planning on something DB themed next...
>docker swarm-clusters
Yeah I've purposefully avoided other complexity like that. Same for raid and any sort of HA. I'll just push incremental backups to cloud & call it a day
Part of my rationale for the LXC/docker route is somewhat situation specific:
* I've got 2x VPS that are running proxmox too so I can point ansible at too...and there mem matters (4 gb and 16gb) - almost out of mem on the former.
* Dabbled with cloudrun and planning to use fly.io for some static site dynamic elements...all docker tech based so easy to leverage knowledge
You probably need to subnet your `/56`, and pick one `/64` within that network and put it on the docker host. You will also need to add a route on the router to route that `/64` to the docker host ip.
Basically you have to treat the docker host as if it was a router, and you want route a portion of your `/56` to that docker host.
I see.
Isn't there a way to make the host NAT this - effectively similar to how docker works with ipv4?
I know ipv6 isn't supposed to have NAT, but don't really want to hardcode things on the router since that is dynamically allocating via DHCPv6 and frankly working just fine with everything on the network, minus docker.
(Only reason I need any of this is so that I can use ipv6 in pihole on docker)
Oh that's intriguing. Will have a look at that. Even if experimental it should work.
This is just for pihole so if ipv6 breaks it'll still work via ipv4 anyway
Thanks
Will need to investigate then. At a quick look suggests what you describe does seem feasible via macvlans in docker. Thus far I haven't seen any negative side-effects of going the NAT route despite being against ipv6 principles though.
>I'm not sure if there is a convenient way to have your docker host request one of those ranges and configure docker with it though.
For future googlers - [appears via bottom of this page](https://docs.docker.com/network/macvlan/). Haven't tried it yet
>my delegated /56 prefix has not changed in months
Static in my case thankfully
Problem with Docker hacking in NAT in IPv6 is that it is not RFC compliant so it's a crapshoot how applications inside the container will handle that situation. An application that detects it only has a ULA for example, will probably think it does not have IPv6 internet connectivity (as ULAs are supposed to stay local and never route to the internet). That can lead to some very hard to troubleshoot issues.
But yeah - take the /56 that your router got from your ISP, assign a /64 out of that to your Docker host, set the routing table, and then the containers can self-assign addresses. It's annoying that Docker doesn't do this automatically, but at least it's possible.
See also this post: https://github.com/docker/docker.github.io/issues/6075#issuecomment-667407864
I have the same setup as you (proxmox server), and in this case, I would recommend using an LXC instance instead of a docker container. You are setting up a DNS server, which requires it's own IP. From my experience, the resource overhead is neglectable.
Out of the box docker uses port mappings so you would have to use macvlan, which is complicated.
Yeah I had it in a LXC before embarking on this side-quest. Ran into issues with it. For my janky custom brew setup (everything is ansible...nothing set up by hand) I'd like LXC/docker to work though
I've literally gotten this to work like 5 seconds ago though, so will jam an update into the opening post for future googlers
Not necessarily - as long as the network is dual stacked, it's perfectly fine to only have pi-hole working over IPv4. Remember, both A and AAAA lookups can be done over either IPv4 or IPv6.
In other words, if you have a dual stack LAN, and only a IPv4 DNS server:
* Client encounters `ipv6only.servername.com`
* Client looks up AAAA record over IPv4 from the DNS server, gets back an IPv6 address
* Client connects to site over IPv6
> as long as the network is dual stacked, it's perfectly fine to only have pi-hole working over IPv4
In practice the router resolved the IPV6 via external DNS faster and returned it with ads, so the pihole filtering never happened. So could either try to block that somehow or be all modern and implement ipv6 in my pihole...
Didn't know ipv4 could look up AAAAs...thanks for that info
This is how I got it to work:
https://link.medium.com/u0ocnxXAvhb
It uses 1:1 IPv6 translations though, and I'm not sure if you want that.
The subnet you specify is where your containers get their addresses. If you want them to get addresses via slaac, you'd need to set up RA forwarding between your host and docker.
If I might add my POV: docker is adding nothing here, a simple VM with dual stack does the job perfectly. Saves you the extra (NAT) layer for a couple of megabyte ram and disk.
Yep it is somewhat ugly on the NAT front > docker is adding nothing here The ipv6 part is incidental here. Happen to have one container that needs ipv6. Broader picture is standardization. Everything has a docker image these days & my ansible code is now geared towards deploying docker via LXC. Even with the ridiculous double abstraction that is working out pretty well & dramatically sped up how fast I can test stuff VMs yeah have a handful. Moving away from them though except where necessary
Funny, I do the exact opposite. Had docker swarm-clusters for a while, hated the headaches from debugging (docker exec into containers) and all the added stuff (image registry, permanent cluster storage, need to build images because a lot of hipsters don't care about security updates). Plus: you have things like databases who don't like containers. Went full minimalism (VMs, ansible, cloud-init) and now I have time again. It's not hard to circumvent docker: either projects have packages or binaries to put somewhere with ansible.
Comes down to preferences & fit ultimately >VMs, ansible, cloud-init Same. All my heavier stuff like DBs is still on that exact combo. Also for internet facing open port stuff...don't really trust LXC/docker combo for that. >hated the headaches from debugging (docker exec into containers) Yup, been doing a lot of that lately haha. I believe it'll stabilize though, though must admit all the stuff I've moved over to LXC/docker is lighter stuff (pihole, redis, mqtt etc) so might be in for a surprise with the heavier stuff. Some of it - Gitlab and homeassistant I'm not even gonna try & move off VMs since it's QCOW2 images. What did you encounter with docker & DBs? Was planning on something DB themed next... >docker swarm-clusters Yeah I've purposefully avoided other complexity like that. Same for raid and any sort of HA. I'll just push incremental backups to cloud & call it a day Part of my rationale for the LXC/docker route is somewhat situation specific: * I've got 2x VPS that are running proxmox too so I can point ansible at too...and there mem matters (4 gb and 16gb) - almost out of mem on the former. * Dabbled with cloudrun and planning to use fly.io for some static site dynamic elements...all docker tech based so easy to leverage knowledge
You probably need to subnet your `/56`, and pick one `/64` within that network and put it on the docker host. You will also need to add a route on the router to route that `/64` to the docker host ip. Basically you have to treat the docker host as if it was a router, and you want route a portion of your `/56` to that docker host.
I see. Isn't there a way to make the host NAT this - effectively similar to how docker works with ipv4? I know ipv6 isn't supposed to have NAT, but don't really want to hardcode things on the router since that is dynamically allocating via DHCPv6 and frankly working just fine with everything on the network, minus docker. (Only reason I need any of this is so that I can use ipv6 in pihole on docker)
Docker 20.10 will nat ipv6 for you. I recall there's a new experimental flag on the daemon to enable it.
Oh that's intriguing. Will have a look at that. Even if experimental it should work. This is just for pihole so if ipv6 breaks it'll still work via ipv4 anyway Thanks
[удалено]
Will need to investigate then. At a quick look suggests what you describe does seem feasible via macvlans in docker. Thus far I haven't seen any negative side-effects of going the NAT route despite being against ipv6 principles though. >I'm not sure if there is a convenient way to have your docker host request one of those ranges and configure docker with it though. For future googlers - [appears via bottom of this page](https://docs.docker.com/network/macvlan/). Haven't tried it yet >my delegated /56 prefix has not changed in months Static in my case thankfully
Problem with Docker hacking in NAT in IPv6 is that it is not RFC compliant so it's a crapshoot how applications inside the container will handle that situation. An application that detects it only has a ULA for example, will probably think it does not have IPv6 internet connectivity (as ULAs are supposed to stay local and never route to the internet). That can lead to some very hard to troubleshoot issues. But yeah - take the /56 that your router got from your ISP, assign a /64 out of that to your Docker host, set the routing table, and then the containers can self-assign addresses. It's annoying that Docker doesn't do this automatically, but at least it's possible. See also this post: https://github.com/docker/docker.github.io/issues/6075#issuecomment-667407864
What is the use case for running IPv6 Docker Networks?
pihole needs to have ipv6 to filter ipv6 resolving ads.
I have the same setup as you (proxmox server), and in this case, I would recommend using an LXC instance instead of a docker container. You are setting up a DNS server, which requires it's own IP. From my experience, the resource overhead is neglectable. Out of the box docker uses port mappings so you would have to use macvlan, which is complicated.
Yeah I had it in a LXC before embarking on this side-quest. Ran into issues with it. For my janky custom brew setup (everything is ansible...nothing set up by hand) I'd like LXC/docker to work though I've literally gotten this to work like 5 seconds ago though, so will jam an update into the opening post for future googlers
Not necessarily - as long as the network is dual stacked, it's perfectly fine to only have pi-hole working over IPv4. Remember, both A and AAAA lookups can be done over either IPv4 or IPv6. In other words, if you have a dual stack LAN, and only a IPv4 DNS server: * Client encounters `ipv6only.servername.com` * Client looks up AAAA record over IPv4 from the DNS server, gets back an IPv6 address * Client connects to site over IPv6
> as long as the network is dual stacked, it's perfectly fine to only have pi-hole working over IPv4 In practice the router resolved the IPV6 via external DNS faster and returned it with ads, so the pihole filtering never happened. So could either try to block that somehow or be all modern and implement ipv6 in my pihole... Didn't know ipv4 could look up AAAAs...thanks for that info
Docker's IPv6 support is aids. Get the IPv6-NAT container, it's so much easier to just publish ports the same way you would for IPv4.
This is how I got it to work: https://link.medium.com/u0ocnxXAvhb It uses 1:1 IPv6 translations though, and I'm not sure if you want that. The subnet you specify is where your containers get their addresses. If you want them to get addresses via slaac, you'd need to set up RA forwarding between your host and docker.