Enable IPv6 support for web UI

[tlstpierre]

Is this a feature relevant to companion itself, and not a module?

• [X] I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the feature

Companion should either by default, or with a simple option, bind listening sockets to IPv6 as well as IPv4. This is easily accomplished by using "::" instead of "0.0.0.0" anywhere a bind IP address is used. Currently companion cannot be accessed over IPv6 even when the host is IPv6 enabled.

Usecases

Because IPv4 is obsolete!

No really, but here's some more concrete use cases:

• Allowing Companion to function on an IPv6 only host (this is actually a thing, and this is how I found this issue).
• Allowing Companion to be directly reachable from remote sites without inbound NAT rules, or on Internet connections that no longer provide public IPv4 addresses. This is the case in many networks in many parts of the world. Even when private IPv4 addresses are configured on the network for device control, the lack of a public IPv4 address prevents remote access. Listening on IPv6 would allow remote access (suitably firewalled) across the Internet.
• Allowing Satellite on an IPv6 only host to access a dual-stack Companion instance. We don't need to turn off IPv4, we just need to allow incoming IPv6 connections.
• IPv6 is the default protocol on many operating systems, so if a hostname is used to connect to the Companion instance on dual-stack host, the connection will fail because the IPv6 address is being used, but Companion is only listening on IPv4.

This is a fairly simple change and would be equivalent to setting --admin-address :: on the CLI at run-time. I have tested this behaviour on Linux and it solved the IPv6 issues and did not negatively affect IPv4 (IPv4 clients were still able to connect).

Branch feature/ipv6 was created to explore this. I may be able to make the changes myself with a little guidance.

[timstpierre-tc]

Thanks for putting this on the list!

Something that this might need also, is a change to the regex patterns that allow IP addresses to be entered in the UI. These should be modified to allow IPv6 notation also, anywhere an IP address is specified.

[Julusian]

Something that this might need also, is a change to the regex patterns that allow IP addresses to be entered in the UI. These should be modified to allow IPv6 notation also, anywhere an IP address is specified.

I would be open to adding a new IPv6 regex, and potentially a combined IPvBoth regex, but I am not sure if the existing one should be changed. Many modules will be assuming that they will get an ipv4 address, and so will error/crash or worse if they are given an invalid address. For example, the generic-tcp-udp module and even the UDPHelper class we provide for modules to use, binds to udp4, on the provided address.

Some more work probably needs to be put into what we can do to encourage modules to support ipv6, which is a similar track to previous discussions about encouraging them to access hostnames as well as ip addresses. I don't remember much progress being made on the hostname track though