Detect and warn about common IPv6 misconfigurations

I’ll also post this on the GitLab issue tracker once I get approved there.

Right now, around 50% of all Tor relays are reachable over IPv6. That number could certainly be higher if IPv6 on many Tor relays weren’t misconfigured. Many relay operators are not aware of IPv6 and don’t configure it properly.

I believe Tor should detect common issues, for instance:

  • IPv6 disabled on OS level, in kernel, on interface
  • IPv6 incoming connections blocked by firewall (outgoing connections work, incoming connections don’t)
    and display appropriate warnings. Tor could even add a relay flag (for example “IPv6Misconfigured”) to warn the relay operator more efficiently. If the “misconfiguration” was intentional, there should be a config option (for example “RemoveIPv6MisconfiguredFlag 1”), disabled by default, to remove the flag even if a “misconfiguration” is detected.

I’m almost certain this would increase the amount of relays that have working IPv6. As I understand, Tor doesn’t want to allow IPv6-only relays as long as IPv4-only relays are a thing due to network fragmentation. This could accelerate the transition from “IPv4 required, IPv6 optional” to “IPv6 required, IPv4 optional” and eventually allow Tor to avoid the IPv4 exhaustion issue.

My computer have at least 4 IPv6 addresses available:
address #1 (static) is for local network - I don’t want Tor to use it.
address #2 (static) is for overlay network - I want Tor to use it, but without advertising (NoAdvertise flag).
addresses #3 and #4 are for global network, they are public, but potentially dynamic.

Do anyone knows if it is possible to make such torrc file, which will satisfy requirements?
Another question: documentation states that “… static IP addresses are preferred.”
Do it make sense to use potentially non-preferred option even if someone would help me to make correct torrc for my configuration?

IPv6 incoming connections blocked by firewall (outgoing connections work, incoming connections don’t)
and display appropriate warnings. Tor could even add a relay flag (for example “IPv6Misconfigured”)

Tor does add a flag for IPv6 misconfigured relays (although only visible as additional flag on metrics), which states that the relay announces IPv6 but authorities cannot reach the relay. There’s no point in misconfiguring a relay intentionally, hence no need for a “RemoveIPv6MisconfiguredFlag 1” option.

This could accelerate the transition from “IPv4 required, IPv6 optional” to “IPv6 required, IPv4 optional”

Not really, Tor isn’t responsible for accelerating the transition. If you put IPv6 as a requirement, the network will lose a big chunk of relays that either don’t support IPv6 (as ISP/Cloud providers can’t freely offer it yet) or operators aren’t just interested (only them know why).

You’re looking at the “Bridges by IP version” graph, not the “Relays by IP version” graph…

On the “Relays by IP version” graph: ~3500 / ~7500 = ~47%.

Tor does add a flag for IPv6 misconfigured relays (although only visible as additional flag on metrics ), which states that the relay announces IPv6 but authorities cannot reach the relay. There’s no point in misconfiguring a relay intentionally, hence no need for a “RemoveIPv6MisconfiguredFlag 1” option.

I wasn’t aware there’s such a flag. I unfortunately can’t setup a relay with intentionally broken IPv6 right now to test it (my IPv4 is CGNATed).

Not really, Tor isn’t responsible for accelerating the transition. If you put IPv6 as a requirement, the network will lose a big chunk of relays that either don’t support IPv6 (as ISP/Cloud providers can’t freely offer it yet) or operators aren’t just interested (only them know why).

Obviously not right now, when 50% of relays are IPv4-only. But Tor should allow IPv6-only relays as soon as possible and making IPv6 required and the primary protocol would be one of the ways Tor could do that.

On the other hand, there are providers that offer cheaper IPv6-only servers, or providers that charge for expensive IPv4 addresses (sometimes more than a cheap VPS!). As more providers run out of IPv4, even more of them will charge for IPv4 addresses.

You’re looking at the “Bridges by IP version” graph, not the “Relays by IP version” graph…

On the “Relays by IP version” graph: ~3500 / ~7500 = ~47%.

You are absolutely right, I’m sorry. I edited my message at the same moment you just answered.

I wasn’t aware there’s such a flag. I unfortunately can’t setup a relay with intentionally broken IPv6 right now to test it (my IPv4 is CGNATed).

They aren’t the most common flags, ngl. But if you spend some time looking through the list you’ll eventually find them. Have you got in touch with your ISP? Many offer to opt out of CG-NAT, some free and others for a really cheap plan, like 1€ or so.

On the other hand, there are providers that offer cheaper IPv6-only servers, or providers that charge for expensive IPv4 addresses (sometimes more than a cheap VPS!). As more providers run out of IPv4, even more of them will charge for IPv4 addresses.

While this is true, it is better to offer IPv6Only as an option and not as a requirement, as you said in the beginning. That way if you don’t own an IPv6 address the network won’t be affected as you wouldn’t be excluding those with just IPv4.

They aren’t the most common flags, ngl. But if you spend some time looking through the list you’ll eventually find them. Have you got in touch with your ISP? Many offer to opt out of CG-NAT, some free and others for a really cheap plan, like 1€ or so.

I’m sorry, apparently I’ve somehow missed that flag (“UnreachableIPv6”). Here’s an example relay with broken IPv6 for others reading: Relay Search.

My ISP unfortunately doesn’t offer non-CGNATed IPv4 anymore on their newer plans - I had to shut down my relay for this reason - regrettably, as on this newer plan I could dedicate 300Mb/s of download and upload bandwidth to a Tor relay and not really notice it, even on a speed test.

I actually self-host a lot of stuff, but I usually make it IPv6-only and then either use Cloudflare (for HTTPS) or ZeroTier (for other protocols) as IPv4>IPv6 proxies for access from IPv4-only networks. Sadly, none of these work for Tor and it would be bad to use a centralised proxy for Tor anyway.

While this is true, it is better to offer IPv6Only as an option and not as a requirement, as you said in the beginning. That way if you don’t own an IPv6 address the network won’t be affected as you wouldn’t be excluding those with just IPv4.

The issue is that Tor currently assumes that all relays are fully reachable from other relays. Allowing IPv4-only relays and IPv6-only relays is obviously the best solution and I wish Tor would implement it (then I could actually run a relay on my home connection) rather than making either IPv4 or IPv6 required, but it obviously makes some relays not directly reachable from others and I’ve heard that it requires some major changes in the Tor protocol.

I’ll try one thing with IPv4, however: I could WireGuard tunnel to a location with public IPv4 but lower bandwidth and then forward a port to the Tor relay. However, I don’t know if it work well if a relay had like 10Mb/s of IPv4 bandwidth, but 300Mb/s of IPv6 bandwidth.