Conversation
|
This would need ipv6 support |
|
Okay - lists like the one from Apple-Privacy-Relay does also contain IPv6 |
If you want to include IPv6 addresses in the same output file as IPv4 addresses, you could use the same convention that Apache HTTPd and other well-known server daemons use, which is to enclose the IPv6 addresses within square brackets, however, I think this would be unnecessary since TCP/UDP port numbers aren't being specified, hence the presence of a colon would be sufficient to detect the address type as IPv6 (do not use a period to detect IPv4 addresses, however, since it's valid for an IPv6 address to include an IPv4 address in the last 32 bits). Here's what two entries could look like (an IPv4 address preceding an IPv6 address): 192.168.55.73/24 It would probably be better to just have separate ipv6.txt files though, since it takes less effort for administrators and users alike to simply concatenate two text files. I believe it's fair to assume that most administrators will prefer separate IPv4 and IPv6 lists (instead of writing a Perl one-liner to separate them) since there are many systems that won't combined lists automatically. We've had dual-stack (IPv4 and IPv6) deployed on our internet serves for more than two decades, and we're finding that nearly all cellular phones these days use IPv6. So, my suspicion is that many VPN providers may already be supporting IPv6 traffic without mapping/converting/gatewaying/proxying to IPv4, at least with cellular phone customers running a VPN app. (Not changing IPv6 to IPv4 makes sense since there are some additional traffic management options available in IPv6 packet headers that are not available in IPv4 packet headers.) |
As a developer I support this. Telling IPv4 and Ipv6 apart is really easy and fast, and it allows us to restrict the haystack and speedup the lookup significantly. |
As the mullvad API also provides IPv6 addresses - we should add them as the information would be wasted otherwise.