Tor currently requires a public IPv4 address for all relays. The Tor relay requirements state that “There should be no problem at all with this requirement (all commercially available servers come with at least one IPv4 address)”. Actually, there are issues with that requirement as of July 2023.
Firstly, not all commercially available servers come with at least one IPv4 address. Right now, there are multiple VPS providers that are IPv6-only on cheaper servers and require paying extra for IPv4.
People also run relays on residential internet connections, where having a public IPv4 address is starting to get uncommon. For instance, I was forced to shut down my Tor relay because my new ISP does not offer public IPv4 at all for residential customers and the IPv4 is behind a CGNAT. I have a /56 IPv6 prefix, so I can self-host stuff just fine on IPv6-only, but Tor requires a public IPv4 anyway. It’s a bit of a waste that I’m not allowed to run a Tor relay through my new connection, as it’s a symmetrical fiber connection with pretty high bandwidth. I can contribute using Snowflake, but that doesn’t use nearly as much bandwidth as a relay.
To mitigate this issue Tor could:
-
Allow full IPv6-only relays while allowing IPv4-only relays
Tor would have to deal with the fact that there are now both IPv4-only and IPv6-only relays.
An IPv4-only relay and an IPv6-only relay would not be able to communicate directly. -
Allow IPv4 outbound-only addresses
In this case, a relay could have a full IPv6 address for incoming and outgoing connections.
The shared IPv4 address would be “outbound-only” and it could only be used for outgoing connections to other relays.
IPv4-only relays would not be able to reach IPv6 + IPv4 outgoing-only relays. -
Use shared IPv4 addresses for incoming connections through NAT hole punching
I believe this is not viable for Tor because NAT hole punching would compromise user anonymity and make it easy to track Tor connections. Tor also uses TCP, not UDP. -
Require IPv6 addresses and make IPv4 optional
This is also not viable for Tor because most relays are still IPv4-only.
Option 1 could be a solution. However, current Tor clients assume that all relays are reachable from all other relays. Maybe new Tor versions could by default only serve directory information for IPv4-only and dual stack relays to older versions - relays with a “IPv6 Only” flag would not be included by default. New Tor versions could request that those relays be included and handle them appropriately depending on IPv6 connectivity status.
Option 2 could also be a solution that would minimize the fragmentation of the Tor network.
There’s a question if relays without IPv4 incoming capability should be middle relay only or also allowed as guards. Relays and Tor clients run the same Tor software, so at first glance it’s fine to allow them as guards. However, what if Tor is started on an IPv6 compatible network, but moves to an IPv4-only network? Tor would have to pick a new guard, which isn’t too good for anonymity. So these relays would probably have to be middle relay only for now.
Another thing that Tor could improve with IPv6 support would be allowing IPv6-only exit policies. This is probably much easier than IPv6-only relays or bridges. As an example, an exit that’s reachable through both IPv4 and IPv6 could only allow IPv6 exit connections. IPv6 address space is much easier to obtain compared to IPv4 address space and having your own address space is always a good idea when running an exit relay. I’ve noticed that if an IPv6-only website is requested through Tor Browser, it loads just fine - it appears that Tor finds an IPv6 exit node and loads the website. It seems that it would not be that difficult to switch to an IPv4 exit node if an IPv4-only website is requested.