add IPv6 support

Patrick · May 28, 2024, 6:52pm

Now that the port to nftables has been completed, it’s time to add IPv6 support.

Suggestions which internal IPv6 addresses we should use for,

A) Whonix-Gateway internal network interface?
B) Whonix-Gateway external network interface?
C) Whonix-Workstation internal network interface?

I plan to keep using static IP configuration without introducing the complexities of DHCP.

related source code files:

related, on why we use 10.152.152.10 for IPv6:

This is for Non-Qubes-Whonix only. For Qubes-Whonix, there is a separate ticket: add IPv6 support to Qubes-Whonix · Issue #9267 · QubesOS/qubes-issues · GitHub

Patrick · June 6, 2024, 11:33am

Should consider using unique local address (ULA).

Patrick · June 6, 2024, 1:12pm

github.com/QubesOS/qubes-issues

IPV6: Use GUA (Global Unicast Addresses) or reserved addresses instead of ULA (Unique Local Unicast Addresses) within Qubes

opened 09:17PM - 01 Oct 22 UTC

brejdol

T: enhancement P: default C: networking

The current IPv6 setup within Qubes use Unique Local Unicast Addresses (ULA) (f…c::/7) + NAT66 today. The original intention with ULA was to have a private address space in IPv6, and to use NAT66 if internet access is needed, just as RFC1918 addresses work in IPv4. For Qubes, this makes perfect sense since it solves all portability issues - The network within Qubes doesn't change even if you move from one network to another, and the environment within is oblivious to the uplink. The problem is that ULA addresses in 2022 doesn't work as originally did, and this is unfortunately not common knowledge outside the networking community. The working order of ULA addresses was changed a few years back. Now, IPv4 addresses are ALWAYS preferred over ULA addresses, wich makes ULA addresses pretty much useless in a dual stack environment - They will never be used by the operating system for anything. You can force ping and traceroute to use IPv6, but not much else. Even if you change the priority for ULA in /etc/gai.conf, you will still not be able to reliably get IPv6 ULA and AAAA DNS records to always be preferred (probably due to some hard-coding somewhere). The solution is to stop using ULA addresses internally, and to use Global Unicast Adresses (GUA) instead. This however means you need to get ahold of a prefix to use for this. Another option is to use addresses from the reserved address space, like the documentation prefix 2001:db8::/32, or the unused and reserved 0200::/8 space. The latter one is proposed to be the new "lab" prefix (not ratified yet) in order to solve this exact issue with ULA addresses not being preferred by the operating system. Both these reserved prefixes are considered bogon networks on the internet, and they will be dropped at the first hop (just like RFC1918 addresses in IPv4). They can't be routed on the internet, so they can't ever be destination networks. This means they are both perfectly suited to be used within Qubes for the internal addressing instead of the dreaded ULA. IPv6 deployments for home users is now starting to pick up the pace. This change would make the Qubes environment more seamlessly blend in, and would make it work exactly the same as the rest of your equipment in your IPv6 enabled network. As it is now, Qubes doesn't really use IPv6.

Patrick · June 6, 2024, 1:58pm

Patrick · June 15, 2024, 1:48pm

Patrick · June 16, 2024, 2:34pm