The hassio bridge network doesn't has the IPv6 network stack enabled.
"Culprit" seems to be the line at hassio/docker/network.py, in particular the parameter enable_ipv6=False in the method _get_network.
Enabling is not as straightforward as puting there True because to set up correctly IPv6 a subnet should be specified. And that subnet is typically provided by the user (if the user is doing globally routable addresses, which is a likely scenario in IPv6 environments).
I haven't come up with a proposal on how to address that. I was open to suggestions (if a PR is feasible and appreciated, I can work on that) or some workaround tips otherwise (if there are any).
Go to the HomeAssistant Config file under component http and add server_host: "::0"
@Fubi95 yeah, I added that to the documentation. Note that the homeassistant container is not part of the hassio bridge, as that container uses host network mode and thus works correctly with IPv6 if the host has IPv6.
However, the problem I found is for the addons, which typically use the hassio bridge which --when created-- has an explicit disable of ipv6.
I have abandoned this route, as it started to seem (at least to me) painful and cumbersome. And Docker itself has no clean semantics and features for IPv6 stack of containers IMHO. So not sure if it is worth having this issue opened, as I don't know if it will benefit anybody in the short term.
@alexbarcelo I would love to expose my hassio on IPv6 but as far as i understand it's not possible now, correct ?
@donnib You can expose hassio to IPv6 because, as I said, that container is not part of the hassio bridge. According to my comment (which I honestly don't remember at all) I updated something in the documentation, probably related to the @Fubi95 comment.
That will expose hassio to IPv6, but will not work for any other container in the hassio environment. That was my use case, and was not supported. ATM I am using vanila dockerized hass, so you should try it yourself /shrug
(see https://www.home-assistant.io/components/http/ > server_host)
@alexbarcelo the doc says explicitly : _"Don鈥檛 use option server_host on a Hass.io installation!"_ so i still don't know how to do this
So... either I did not see it, or it was not there when I was toying around.
If somebody wants to try it, go ahead. I have stopped using Hass.io a while ago so I will keep an eye on the project but I am not doing anything with it at the moment.
I'm open to merging PRs for that but that is no simple task and need a lot of tests and also PRs on another repository to make it working overall instance.
Sorry if it came out as passive aggressive, wasn't my intention, I was in a hurry.
IMHO given my previous experience, Hass.io is phenomenal for easy deployment on typical use cases, specially for non-techie users. Using IPv6 doesn't seem to fit that scenario. IPv6 networks are cumbersome and is very difficult to provide a default behavior one-fits-all that is actually useful. And lots of IoT gadgets are not IPv6 ready, so everything should be dual stack, and to be honest, dual stack feels not so useful right now.
With more perspective (from when I started the issue), I think that it is too soon to give support for IPv6 --I feel it would be a waste of efforts given the current IPv6 ecosystem.
I agree
@pvizeli @alexbarcelo
My use case was to allow Hass.IO to be accessed from the outside world when i have Carrier Grade NAT otherwise that won't be possible. I think this case is still valid for many users that they don't have a public IPv4 address. Maybe this case is simpler than what you are worried about. Please correct.
In Spain, there is no ISP offering IPv6 AFAICT. There are some of them using CGNAT, and in those cases you are basically screwed.
You are right that this specific use case is simpler than the original issue --what I had in mind was something along "support the whole IPv6 hybrid network stack inside the IoT local network". However the scenario you describe was (maybe still is) simply solved by changing the server_host. It beats me why it is discouraged in the documentation, given that it used to work.
@pvizeli do you know why it's not recommended to use server_host ?
IMHO given my previous experience, Hass.io is phenomenal for easy deployment on typical use cases, specially for non-techie users. Using IPv6 doesn't seem to fit that scenario. IPv6 networks are cumbersome and is very difficult to provide a default behavior one-fits-all that is actually useful. And lots of IoT gadgets are not IPv6 ready, so everything should be dual stack, and to be honest, dual stack feels not so useful right now.
With more perspective (from when I started the issue), I think that it is too soon to give support for IPv6 --I feel it would be a waste of efforts given the current IPv6 ecosystem.
It is _too late_ for any platform or product to not be fully embracing IPv6.
IPv6 is no different to IPv4. IPv6 is no more confusing, cumbersome, difficult or any other descriptor that is being thrown around than IPv4 was.
It is becoming common place - especially for major ISP's in the USA.
What is difficult (in my experience) is docker networking and IPv6. But that shouldn't hinder the implementation of IPv6 for Home Assistant/Hass.io.
I Germany many ISPs only offer dslite, where you have a public IPv6 but no IPv4. So if I want to use HA outside my network, I need to use IPv6.
Adding the ::0 value to the server_host does work for me. So why is it not recommend to use it with hassio?
And I agree, that IPv6 is the future and it should be supported as soon as possible (not only Hassio, but all applications in general).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This really should stay open.
IPv6 support is exceptionally important
Most helpful comment
This really should stay open.
IPv6 support is exceptionally important