Hello,
I want to change the default internal IPv6-prefix from ULA to a “real” GUA-addresses (I have a real allocation that I can grab a slice out of). The reason is that ULA-addresses doesn’t not really work in a dual stack environment, they are never used due to lower prio in the OS. I have native IPv6 at home, and would like to have a setup where my qubes work as my other local machines.
I haven’t really found where the IP-pools are to be found, so thankful for a hint.
Regards,
/Richie
Hi Richie!
I’m not a Qubes developer so I can’t give an authoritative answer to your question but I’m very interested in ipv6 and your question inspired me to look into it.
One thing I like to do whenever I have a question about a open-source tool is to look at relevant issues to see if other people have asked about it before. Applying that strategy I found this comment from the lead Qubes developer marmarek about ipv6 support:
But you can’t disable NAT. This is rather unavoidable(*) with tree-like
structure of network connections between VMs (sys-net → sys-firewall →
AppVMs, possibly sys-whonix in between).
Check out the linked issue for more context but his reasoning makes sense to me. The network architecture of Qubes seems to make NAT66, as gross as it may be, necessary.
Hello!
Just to clarify - This is has nothing to do with NAT66 - The setup with qubes pretty much demand that solution, and it’s really the best way to handle the networking, within a laptop for example. Otherwise you would have to change your routing/addressing all the time. I have no issues with the current setup with NAT66. The issue I have is that the setup uses ULA-addresses (fc00::/7), since they have been prioritized lower then IPv4 in all OS (yes, it is true), following the evolvement of the RFC, creating an odd situation where ULA-addresses makes no sense in using for most internal networks. An ULA-address will never be used if IPv4 is present on the host/vm. Simple as that. So, ULA now only makes sense in an internal native IPv6-only environment where this doesn’t matter at all (think IoT-devices, kubernetes cluster etc). I can manually force ping/traceroute to use IPv6 in the current setup, but nothing else will use IPv6, ever. I would suggest to change the address allocation to instead use a prefix out of the documentation prefix 2001:db8::/32 instead, since these actually have the same priority within the operating system as “real” GUA (Global unicast addresses).
I should also add that I’m new to Qubes, soon two weeks in. I think this project is beyond awesome! I used a linux host + vmware workstation earlier, and that was clunky, and not that secure (everything that was supposed to be work related ended up being mixed up with private stuff). I switched over on my work laptop, and haven’t looked back!
1 Like
ULA can be prioritized over IPv4 by modifying the /etc/gai.conf as follows:
label ::1/128 0
label ::/0 1
label fc00::/7 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label fec0::/10 5
label 2001:0::/32 7
precedence ::1/128 50
precedence fc00::/7 45
precedence ::/0 40
precedence 2002::/16 30
precedence ::/96 20
precedence ::ffff:0:0/96 10
1 Like
Heh, I forgot about that. Yes, that might be the best solution for now. Thank you!
Ongoing, it might be one thing to consider changing globally in Cubes, since the ULA-addresses simply don’t work properly for this sort of setup. The documentation prefix will work better.