Enforce ipv4 + ipv6 capable exit

[Enhancement Request]

(unless I missed something in the configurations and options!)

While trying to add ipv6 capability to my Tor router, I noticed a limitation.

There does not seem to be a parameter in the configuration to ensure that the selected exit node is ipv6 capable... which could be unfortunate if the client really needs ipv6!

Did I miss such a parameter in the configuration?

So here is some test output. This is done from a machine connected to my "Tor router" which is transparently (for the client) routing all TCP traffic to Tor, routing DNS through Tor, and discards the rest.

$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short 185.107.81.234 216.58.198.206 2a00:1450:4007:809::200e

$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short 216.218.222.14 172.217.15.110

$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short 185.220.101.13 172.217.19.206 2a00:1450:400e:805::200e

$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short 142.44.156.128 216.58.212.206

$ curl 'http://ipv4.whatismyip.akamai.com'; echo; dig google.com A google.com AAAA +short 77.247.181.162 172.217.17.142 2a00:1450:400e:807::200e

Between each command, I send a NEWNYM through the command port (on the router) to get a new identity. The curl gives the ipv4 address of the exit node. DIG tries to get both ipv4 and ipv6 addresses of a site we konw has both (google here).

As we can see, depending on our exit node we get or we don't get AAAA adresses.

(DNS is done with ipv4)

When we don't get AAAA resolution, as expected, we don't either have ipv6 connectivity.

Although this is undocumented, an educated guess is that an ipv4-only exit would never send back AAAA responses to DNS requests since it can't handle an incoming request to connect to an ipv6 host. Correct me if I'm wrong on that, as I didn't check in the code... just guessing!

This makes perfect sense and is coherent with what we can observe.

But then, from the client point of view, having** ipv6 connectivity is unreliable**.

From trying to understand the "path-spec", I can imagine that if the client provides an ipv6 address instead a host name when the circuit is established, it could do the trick (not tested it!). But that would not be practical at all for end-users (already with ipv4 it's bad, but ipv6 is hell!)

At worst it can trigger errors: since a client might cache DNS responses, when you have an ipv6 capable exit node, then a AAAA response and use ipv6, and you happen to hit MaxCircuitDirtiness and change exit, you could be sending ipv6 requests to an exit that can't handle that, resulting in hard to diagnose errors.

Hence this ticket: it would be nice to be able to have a flag (or any reliable method) allowing to select only ipv6 capable exits.

For example, we already have:

ClientUseIPv6

(I assume that one of the result of that is to triggers AAAA responses to DNS)

We could have:

ClientNeedIPv6

Or same as you can select exits by country, being able to select exits with ipv6

ExitNodes ipv6

(This is not as good because it becomes confusing when you add countries, since the implied operator when you supply a list of nodes is OR, and we obvisouly want AND for ipv6)

This should obviously be used with caution, and only when you really need it since it might harm anonymity by reducing the number of possible exits (same as selecting a country does!).

Should you thinks there is not yet enough ipv6 capable exits, this enhancement could be put in the roadmap at a later date.

From my tests short tests randomly changing exits, I got between around half of capable ipv6 exits... you might have a more reliable stat to decide I guess!

Trac:
Username: Zakhar