supervisor
supervisor copied to clipboard
Support basic IPv6
Proposed change
That is still not enough for full ipv6 support as we need the IPv6 plugin for handling the iptables correctly like we have IPv4 support until docker get full support of that and not like now, only partial
Type of change
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] New feature (which adds functionality to the supervisor)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
Additional information
- This PR fixes or closes issue: fixes #
- This PR is related to issue:
- Link to documentation pull request:
- Link to cli pull request:
Checklist
- [ ] The code change is tested and works locally.
- [ ] Local tests pass. Your PR cannot be merged unless tests pass
- [ ] There is no commented out code in this PR.
- [ ] I have followed the development checklist
- [ ] The code has been formatted using Black (
black --fast supervisor tests
) - [ ] Tests have been added to verify that the new code works.
If API endpoints of add-on configuration are added/changed:
- [ ] Documentation added/updated for developers.home-assistant.io
I think we can not just upgrade the existing network. Properly we have to create a function that user can call which disconnect all container and recreate the network. This can be later also used if we allow to change the IP address of internal network
Yeah, I will create the function and create an issue/fix about it and then we can merge it
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.
@pvizeli is there anything I might be able to do in order to help this PR move forward? I have built an addon that would benefit greatly from being able to get a working v6 address :)
@pvizeli is there anything I might be able to do in order to help this PR move forward? I have built an addon that would benefit greatly from being able to get a working v6 address :)
Can you elaborate a bit more on the use case for IPv6 in your add-on? The intention here is to assign an address from the ULA range. Depending on use case this might not be useful.
Can you elaborate a bit more on the use case for IPv6 in your add-on? The intention here is to assign an address from the ULA range. Depending on use case this might not be useful.
Sure thing, my addon is just a simple packaging of the Bind DNS server. A lot of the major DNS registrars/clouds have v6 addresses for their DNS servers and it would be good to be able to reach those as well as the v4 addresses.
FWIW ULA addressing is fine for this sort of thing in Docker because, as with v4, it sets up NAT for outbound connections on v6.
Just a question, could this new feature be able to fix the issues I'm experiencing in my dual-stack network with the Add-ons?
For example, I've not been able to configure access policies on NPM to work properly, since all traffic that is coming from IPv6 will seem to be coming from the bridge (172.30.32.1
).
This has also made me disable fail2ban, since any failed attempts to access Home Assistant or its add-ons from an IPv6 client would ban automatically every IPv6 connection.
I know that I could easily disable dual-stack globally and run IPv4 only, but I'm starting a networks course next month and dual stack looks like it could be a great playground for my experiments (my ISP was kind enough to give me a static public IPv4 and a static /48 prefix for free).