Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#24798 closed enhancement (worksforme)

Enforce ipv4 + ipv6 capable exit

Reported by: Zakhar Owned by:
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version: Tor:
Severity: Normal Keywords: tor-client, ipv6
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


[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 ''; echo; dig A AAAA +short

$ curl ''; echo; dig A AAAA +short

$ curl ''; echo; dig A AAAA +short

$ curl ''; echo; dig A AAAA +short

$ curl ''; echo; dig A AAAA +short

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:


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

We could have:


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!

Child Tickets

Change History (7)

comment:1 Changed 2 years ago by Zakhar


using Tor version (on Ubuntu 16.04.3 x64)

The documentation of the last version of Tor has more configuration items, but couldn't find a description corresponding to that.

comment:2 Changed 2 years ago by teor

Component: - Select a componentCore Tor/Tor
Keywords: tor-client added; exit policy removed
Milestone: Tor: 0.3.3.x-final
Resolution: worksforme
Status: newclosed
Version: Tor:

It's not clear in this ticket what you want to do.
But here is how to use the two IPv6 features that you seem to be looking for.

If you want your client to enter the Tor network over IPv6, use:
ClientPreferIPv6 1
If you want to make IPv6 entries mandatory, use:
ClientUseIPv4 0

If you want your client to exit the Tor network over IPv6, use:
SOCKSPort/TransPort/etc. PORT IPv6Traffic PreferIPv6
If you want to make IPv6 mandatory, use:
SOCKSPort/TransPort/etc. PORT IPv6Traffic PreferIPv6 NoIPv4Traffic

We haven't tested these kinds of configurations, so if you find any bugs, please open a new ticket with the specific bug. Recent Tor versions may have better support for these features: please try 0.3.1 before submitting any bugs.

comment:3 Changed 2 years ago by Zakhar

Thanks for your response, I'll look into that. But from what I can guess that does not completely meet my needs... which I expressed incorrectly.

My configuration already has:
ClientUseIPv6 1

I'll try adding:
but that will probably not do what I have in mind looking at the description in the man.

Reworded Requirements:
The setup is a "Tor router".
This router is supposed to behave as a "transparent router", which means any computer connected to that router thinks it has an "internet connection" whereas instead all traffic goes through Tor.
[ There is a limit to this "transparency": the client has no UDP beside DNS resolved through Tor ]

Since the router is supposed to behave like a "normal router" (think your ISP's router) a client connecting might want to:

  1. browse the internet connecting to a website that only has IPv4 addresses
  2. connect to a home NAS through IPv6... given the ISP didn't give a fixed IPv4 (considering the shortage of that resource).
  3. browse/connect to a server that has both IPv4 and IPv6


  1. for this use case we DO need ipv4 since the web server we want does not have ipv6 (a lot of servers are still not reachable with ipv6)
  2. for this use case we DO need to have ipv6 since the home NAS has only that (the ISP didn't gave a fixed ipV4. Sure there are workaround like DynDNS... but there might be other use cases that we can't workaround)
  3. for this use case we have no requirement on whether the exit node uses ipv4 or ipv6 since the requirement is to connect to the server, not how it is done. I am not sure there is a "standard router rule" here. I know that my ISP (Free / France), which was amongst the pioneers of ivp6 is preferring ipv6 when a site has both, but for my use case having this preference is optional, although I understand PreferIPv6 would do that.

So I will test your recommendations, but seeing the name, I am quite afraid :

... will break use case 1 (connecting to a site that has only ipv4).

With the current existing parameters and your explanation, my impression is that you cannot be sure that an exit node having ipv6 will be selected, unless you forfeit ipv4, which is not what I want!

So maybe a better summary would be:
How to enforce the choice of an exit node have both ipv4 and ipv6?

My initial question was assuming ALL exit nodes have ipv4 (which seemed obvious to me but might in reality not even be the case), so it might be more accurate to rephrase.

Last edited 2 years ago by Zakhar (previous) (diff)

comment:4 Changed 2 years ago by Zakhar

Summary: Enforce ipv6 capable exitEnforce ipv4 + ipv6 capable exit

comment:5 Changed 2 years ago by Zakhar

Indeed, this ticket is not explaining correct.

I am opening a new one, sorry for the disturbance!

comment:6 Changed 2 years ago by teor

Please post the new ticket number in this ticket once you have opened it.

comment:7 Changed 2 years ago by Zakhar

Ticket closed as incorrectly documented.

It is now superseded by: #24833

Focus on DNS: all the rest works like a charm'''

Last edited 2 years ago by Zakhar (previous) (diff)
Note: See TracTickets for help on using tickets.