On 05/02/2026 19.39, Marco Moock via tor-relays wrote:
There are some other parts that could be done:
ClientPreferIPv6ORPort 1 could be enabled by default, maybe together with a fallback to IPv4 if the connection is not possible. That would massively increase IPv6 traffic.
Guards (only Guard position) reachable by IPv6 only should be possible. Certain home user plans don't include a public routable IPv4 address, but IPv6. IPv4-only middle relays can be reached by CGNAT by those machines. That would enable many users to run such relays that currently cannot.
Exits with an IPv6 only exit policy are currently not possible. Is there a special reason for that? The client already need to check the policies of the exit relays to determine if the exit is suitable for the connection.
Are those things part of the plan?
I think they are in the potential solution space, yeah. At the recent Tor Community Gathering, I did a small project with scanning the network for latency differences between IPv4 and IPv6 to figure out how something like Happy Families would look in a Tor context. Browsers went with a slight delay for IPv4 when trying to "upgrade" to v6 (which has no delay). We may want to use that too, but in practice, we may as well just try to connect on both IPv4 and IPv6 at the same time and use the one that establishes a connection first. This goes for both client -> guard connections, but also for relay to relay connections. I will need a bit more time to look at the data, so realistically, this will be after the next Tor Community Gathering, which takes place at the beginning of March. I suspect the initial output will be a Torspec proposal, and then some experimentation in Arti and/or C Tor. Cheers, Alex -- Alexander Hansen Færøy