My ISP has just implemented IPv6 and at the same time is starting to roll out CGNAT.
What do I need to do/change to use IPv6 for Hass.io?
I’m currently running the generix linux installation on Debian. I also use the Caddy reverse proxy addon and have port 80 and a high xxxxx port forwarded in my router. I use duckdns (which supports IPv6 and is updating my IPv6 address already) as well as Google Assistant.
I can opt out of CGNAT for free for now but it’s only a matter of time…
Any advice?
I can’t seem to find any resources regarding the use of IPv6 with Hass.io, but you might be able to use a tool like 6tunnel to access your install remotely. I have a similar problem with my ISP, but since they don’t support IPv6 (yet), I’m stuck with tools like Chisel, FRP, or SSH reverse tunnels to a VPS. You could try them out as well, but YMMV.
EDIT: Apparently IPv6 on hass.io would require the use of IPv6 docker networks, which means the entire Docker installation, with the addons, would have to be reconfigured.
EDIT 2: It’s possible to enable IPv6 for HomeAssistant (but only home assistant) by setting it to listen on ::0 in the server_host option.
Since you are already using a reverse proxy there is nothing to do to access hass.io’s web interface from IPv6 connections. Do not use the server_host option when using hass.io since this is not recommend (throws a warning in your log).
Make sure your DuckDNS add-on does not set the IPv4 address when using CGNAT since this IPv4 address likely won’t resolve to your endpoint. Which DuckDNS add-on are you using? As far as I remember the original one does not support IPv6.
I had trouble to set up the Google Assistant component for users with CGNAT. I’m under the impression the initial handshake requires IPv4 connectivity, but that limitation may no longer be there. Once set up Google Assistant works perfectly with IPv6 only connections.
My router automatically does duckdns for both IPv4 and IPv6 so no addon. So I thought IPv6 was preferred in most browsers these days? I seem to be using IPv6 anyway for sites that support it. I probably can stop duckdns using IPv4 but not sure why I would have to if I was on CGNAT?
I can see that it would be impossible to make GA work on CGNAT
So currently I can access my HA via:
https://domain.duckdns.org:xxxxx
Or
http://local-IPv4-address:8123
Or
http://debian:8123
What would I put in the address bar to access via IPv6?
Thanks for your response… it’s almost impossible finding any information about this still…
I just tried:
https://[2403:5800:etc]
421 Site [2403:5800:etc] is not served on this interface
Also got a chrome error… of course I don’t have a certificate for that IP address.
http gives me a 404 error - site not served on this interface
As long as you are trying to access hass.io from within your own network it is completely unimportant if your ISP uses CGNAT or not. Your local IPv4 won’t stop working even with CGNAT.
CGNAT only influences your connection, when you try to connect from the outside of your home and the connection you are using does not support IPv6. In this case it queries DuckDNS for your IP, gets the “shared” IPv4 one (if you push that to your domain) and tries to connect there for the given port. Since this IP address is shared between multiple customers your ISP can’t forward this address to your router.
Are you a windows user?
Please try to ping your DuckDNS domain with either -6 or -4 to check if they work as expected.
E.g. ping -6 david.duckdns.org and ping -4 david.duckdns.org
The -6 variant should point to your device that runs hass.io. The -4 should return an error (Ping request could not find host…) when already behind CGNAT to avoid the problem stated in my last post.
Understood. I was trying within my own network. I can’t connect using the V6 IP address but can using the IPv4 one.
right. totally understand. I think our mobile networks here all support IPv6.
Yes Windows 10.
Pinging my duckdns domain without either -4 or -6 automatically prefers IPv6 and it shows mt IPv6 address and a ping time of <1ms
Actually, the device is my router, not my NUC running hass.io
I can ping the ip address but get the above error with https and if I try http://v6ip:8123 ger similar error.
This is all on my local network
ip a on the debian box gives the ipv6 address and my router also shows the ipv6 address.
going to http://testmyipv6.com/ shows my server prefers ipv6 (but of course that’s win10 PC, not nuc) The NUC is only running stretch lite - no desktop.
The duckdns points to the router and then port forwards to 8123 via caddy for hass.io
I would have expected to be able to connect on ipv6 address in browser though - I can’t even make that work and not sure why or what I need to change. If I can make that work then I can just get another duckdns address or manually edit the duckdns config so it points at my nuc.
I think that may be a problem. The (global) IPv6 address of the host where caddy is running is relevant. If it’s not the same machine as your router, then the duckdns has to point IPv6 at that host, not at the router (because technically the router isn’t listening on 8123). In the routers firewall you would need to allow traffic to that host then.
Thanks Daniel… yeah I know that is a problem but I can’t even connect if I use the IP address in a browser. I can connect using the V4 IP address but not the v6 one.
you are using the port caddy forwards to hass.io and not directly hass.io right?
hass.io itself will not respond on IPv6 connections
My Router forwards port xxxxx to 443 Caddy then will use localhost:8123 etc
Maybe it’s localhost in the caddyfile?
But I would have thought (probably wrongly) that it wouldn’t even be using caddy at all locally as I can access:
So I was trying
Which won’t connect
Home Assistant is not dual stack. It’s either IPv4 or IPv6. I assume caddy may be able to answer on both IPv4 and IPv6. So you have to access the machine running caddy (via it’s IPv6 address), and make sure that caddy forwards those requests to Home Assistant.
EDIT:
Apparently caddy does not support dual stack. Or at least it just recently gaineid support for that: https://github.com/mholt/caddy/pull/2128
I’m not sure how I would do that…
Here’s a workaround. But it’s really just that. So at least from my point of view you’re out of luck if you stick to caddy.
And have a look at my edit from my post above in case you haven’t seen it yet.
i’ll doubt you are using the bind option daniel is referring to so you might still be in luck and everything is fine since the default for caddy is to bind to the wildcard host 
you could post your redacted caddy file if you want to. based on the information you’ve posted i’d assume it looks similar to this one (the tls line might differ if you let caddy generate your certs):
https://xxx.duckdns.org:443 {
header / {
Strict-Transport-Security "max-age=31536000; includeSubdomains"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "same-origin"
}
tls /ssl/fullchain.pem /ssl/privkey.pem
proxy / localhost:8123 {
# websocket =
header_upstream Connection {>Connection}
header_upstream Upgrade {>Upgrade}
# transparent =
header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Proto {scheme}
}
}
if your file looks like that one hass.io is only available using your duckdns domain. that means you can neither access hassio with ipv6:8123 (since hass.io does not listen on ipv6 with your current configuration) nor with ipv6:443 (since this is not a rule in your file).
you can circumvent caddy in your local network as long as you use the ipv4 address of your nuc.
you can use caddy in your local network as long as you point your duckdns domain to the ipv6 address of the nuc and not your router.
in my opinion there is no reason to avoid caddy in your local net since it comes with proper encryption, a nice url and it keeps working even if you use your devices outside of your own network (e.g. your smartphone).
Thanks for that…
Here is my redacyed caddyfile:
my-domain.duckdns.org {
header / {
Strict-Transport-Security "max-age=31536000; includeSubdomains"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "same-origin"
-Server
}
proxy / localhost:8123 {
websocket
transparent
}
}
term.my-domain.duckdns.org {
proxy / localhost:7681 {
websocket
transparent
}
}
conf.my-domain.duckdns.org {
proxy / localhost:3218 {
websocket
transparent
}
}
tasmo.my-domain.duckdns.org {
proxy / localhost:9541 {
websocket
transparent
}
}
log.my-domain.duckdns.org {
proxy / localhost:4277 {
websocket
transparent
}
}
cloud9.my-domain.duckdns.org {
proxy / localhost:8321 {
websocket
transparent
}
}
port.my-domain.duckdns.org {
proxy / localhost:9000 {
websocket
transparent
header_downstream -X-Frame-Options
}
}
webterm.my-domain.duckdns.org {
proxy / localhost:5713 {
websocket
transparent
}
}
Yes I let Caddy generate ssl certificates and have sub domains for stuff on other ports so I only have 2 ports exposed - port 80 for the LetsEncrypt and port xxxxx.
My Router forwards port 80-80 and xxxxx-443. The router also generates the duckdns updates but I can just create another domain and I can statically address that on duckdns as it it’s a static IPv4 and IPv6 anyway so the address doesn’t need any updating if that makes sense. If you say this will work then I can just update the duckdns address and remove the router doing it and see if it works.
Also seems you have different options under the proxy… should I have those options in mine and in every subdomain?
With IPv6 there is usually no forwarding. You just have to configure the routers firewall to not block the ports you need for the device behind the ipv6 address. That may of may not be the same thing in your router’s interface but better take a look if this is the case.
You don’t need to add my variant below the proxy config since this is essentially the same. You can either write websocket or the two lines if used. That makes no difference since websocket and transparent are just shortcuts for what i wrote 
That would be the easiest solution. But when you still have your own IPv4 (and that one is also a static address) why bother with all the IPv6 “problems” we were talking about in this topic?
The IPv4 address isn’t ‘static’ just very sticky… it has not changed and I get the same one whenever I connect. The ISP is rolling out CGNAT at the moment so this situation will change.
I assume… that I would need to check the ‘Open firewall for delegated IPv6 prefixes of this device’?
Also to be clear, would I use https://domain.duckdns.org:xxxxx still to connect? Or would I leave the port off the end?
One other thing… If I make another duckdns domain, can I just add that to the caddy file… basically duplicate the section for my duckdns domain that is there already?
