Skip to content

Enable IPv6 client by default

Currently, the Tor Browser bundle does not enable IPv6 for connections to entry or guard nodes. This causes the tor browser to get stuck in the "Establishing a Connection" screen while claiming that internet connectivity is properly available within the settings page in IPv6-only networks with DNS64 and NAT64.

image image

Log:

2023-04-23 11:57:14.691 [NOTICE] New control connection opened from 127.0.0.1.
2023-04-23 11:57:14.691 [NOTICE] New control connection opened from 127.0.0.1.
2023-04-23 11:57:14.706 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
2023-04-23 11:57:18.065 [NOTICE] Opening Socks listener on 127.0.0.1:9150
2023-04-23 11:57:18.065 [NOTICE] Opened Socks listener connection (ready) on 127.0.0.1:9150
2023-04-23 11:57:18.072 [NOTICE] Renaming old configuration file to "D:\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.1"
2023-04-23 11:57:47.906 [NOTICE] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.
2023-04-23 11:58:21.158 [NOTICE] New control connection opened from 127.0.0.1.

Possible solutions:

  1. Add ClientUseIPv6 1 and ClientPreferIPv6ORPort 1 to the torrc-defaults. As this only influences us using IPv6 for the connection to the entry node, and we're expecting to be on a monitored network already. It doesn't change anything. As establishing a connection with our IPv6 address is the same as someone logging all NAT44 transitions (or not having any NAT, as in, e.g., university networks) is the same threat vector. So changing this default is probably the best and easiest solution. (Also, as a side effect, it improves the performance of the tor client in CG-NAT scenarios)
  2. Do #1, but not "just" within the Tor Browser (bundle) but within the tor client itself.
  3. Do #1 but only as a fallback when IPv4 fails after user confirmation. I don't see why that would be preferred, but it would also improve the current situation where the tor client gets stuck without any message, and users don't know what to do. Or them assuming Tor is blocked on the network and (try to) requesting bridges where it is neither necessarily helpful nor necessary.
  4. Another flavor of #3, add a distinct warning/error message when no IPv4 connectivity is possible and also add a configuration option within Tor Browser to enable IPv6 connectivity. I again don't see why this would be preferred over enabling the client to use IPv6, but ymmv.
  5. Detect the presence of NAT64 using a DNS lookup of ipv4only.arpa and even if clientUseIPv6 is disabled use IPv6 but only to communicate with IPv4 endpoints. I consider this the worst solution, but I want to mention it, as it is still better than the status quo.

My preferred solutions are #1 and #2, as it is the simplest one to implement.