On 29 Nov. 2016, at 18:44, Roman Mamedov rm@romanrm.net wrote:
On Mon, 28 Nov 2016 10:01:03 +1100 teor teor2345@gmail.com wrote:
(I've rearranged your threads for clarity, please bottom-post in future.)
On Nov 27, 2016 11:59 AM, "root" <tor@afo-tm.org mailto:tor@afo-tm.org> wrote:
It is end 2016 we should change from must have IPv4 to must have IPv6 and can have IPv4.
https://trac.torproject.org/projects/tor/ticket/5788
When the proportion of Tor relays with IPv6 is above 60%, dual stack by default on clients is a feasible option.
When the proportion exceeds 85% (the cube root of 60%), a switch may become plausible.
The proportion of Tor relays with IPv6 is currently at 17% of bandwidth.
Could have been higher, if it weren't so cumbersome to configure.
If you honestly want Tor IPv6 adoption to go up, you should stop treating it as a second-class citizen in Tor, i.e. firstly remove the need to have a static literal IPv6 in the config. Not a single other network daemon requires that. And many home IPv6 allocations are dynamic, so users with those can't feasibly set that up even if they wanted.
What was it, "it's tricky to autodetect which IPv6 to use"? No it's really not. Even starting with a simple "ip route get 2001:db8::", then looking at what "src" you get and if it's a proper global one (in 2000::/3),
It might surprise you, but I agree with most of what you've said so far.
In fact, several developers have spent the last few years laying the groundwork for IPv6 autodetection.
There's already a function in Tor that retrieves a list of local IPv4 and IPv6 addresses: https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1773
It's cross-platform, has a fallback strategy to retrieve the default interface address, and works quite well.
But there's more work to be done:
https://trac.torproject.org/projects/tor/ticket/5940
and try to retrieve something from the Tor project over v6 to confirm that it actually works. Done.
If we're talking clients, that's terribly bad for anonymity, because it would allow the Tor Project to collect the addresses of every IPv6 Tor user.
If we're talking relays, that's terribly bad for reliability, because it would make the Tor Project (website?) a single point of failure.
Here's how we actually do it for IPv4:
Relays retrieve their directory documents over IPv4, and a directory mirror tells them their (apparent, public) IPv4 address in the headers.
Here's why that won't work for IPv6:
There are no IPv6 DirPorts. (That is, you can set one up, but no client or relay will use it, because there is no way for relays to advertise an IPv6 DirPort.)
Here's a solution to that issue:
HTTP headers are also unauthenticated, so we want to switch to using NETINFO cells to discover IPv4 addresses. When we do this, it will work for IPv6 as well as IPv4.
Here's an issue caused by headers being unauthenticated:
https://trac.torproject.org/projects/tor/ticket/16205 https://trac.torproject.org/projects/tor/ticket/17605
Here's a general issue with autodetection:
On 28 Nov. 2016, at 10:01, teor teor2345@gmail.com wrote:
How do we deal with relays which have an IPv6 address that doesn't work?
- Relays should self-test their IPv6 ORPort, but there's a race
condition here:
- if relays only publish their IPv6 ORPort after testing it, they can flip between having and not having an IPv6 address in their descriptor. This is bad for descriptor stability.
https://trac.torproject.org/projects/tor/ticket/13112
We just fixed an issue like this with the IPv4 DirPort reachability test. I'd rather not re-introduce a similar issue for IPv6 ORPort reachability:
https://trac.torproject.org/projects/tor/ticket/18050
- If relays don't self-test their IPv6 ORPort, authorities will exclude
them from the consensus if it turns out to be unreachable. This is a more significant issue if Tor autoconfigures IPv6
It can be hard for a relay to self-test its IPv6 ORPort, because it has to build a path with an IPv6 relay at the next-to-last hop. (When self-testing, the originating relay connects to its own ORPort via a few other relays.)
https://trac.torproject.org/projects/tor/ticket/4565
This is doable, but we'd need to write code to make this happen. And we'd need to test that current tor versions actually use IPv6 when asked, rather than using an existing IPv4 connection to the same relay.
https://trac.torproject.org/projects/tor/ticket/6939
Another issue with autodetection is which address should be chosen if there are multiple valid IP addresses. As far as I know, this is much more common with IPv6 than IPv4. Tor doesn't have code that discovers the IP address of the default route, instead, we use the OS order. (Well, most versions do. There was a bug in some recent versions that reordered addresses from the OS order.)
This seems sufficient, but we still get relay operators who are concerned that tor has chosen the wrong IPv4 address among multiple possible addresses on their machine.
For example: https://trac.torproject.org/projects/tor/ticket/17765 https://trac.torproject.org/projects/tor/ticket/17782 https://trac.torproject.org/projects/tor/ticket/17787
Here are some more open issues and questions:
IPv6-only bridges don't seem to work for clients: https://trac.torproject.org/projects/tor/ticket/4847
How do we properly support tor clients on IPv6? https://trac.torproject.org/projects/tor/ticket/17811
there's no automatic IP version selection ("happy eyeballs") in Tor's dual stack code. And if there were, it could not be turned on by default, because the proportion of relays with IPv6 is too low.
(We would, however, accept a patch that automatically selected IPv4 or IPv6 when specifically configured by the user.)
https://trac.torproject.org/projects/tor/ticket/17217 https://trac.torproject.org/projects/tor/ticket/17835
We'd need some version of this code to actually know whether the local IPv6 address worked. Otherwise, it's probably too risky to use it.
There's also a bug where IPv6-only clients can't use microdescriptors: https://trac.torproject.org/projects/tor/ticket/19608
And various path selection bugs around IPv6: https://trac.torproject.org/projects/tor/ticket/15518 https://trac.torproject.org/projects/tor/ticket/7193 https://trac.torproject.org/projects/tor/ticket/7478 https://trac.torproject.org/projects/tor/ticket/17849
I would love to have the time to write the code for better IPv6 support in tor. I would love to review patches for better IPv6 support in tor.
I'm not opposed to it at all.
I'm just saying that it might be a bit more complicated than you think to get it working well.
T