[tor-relays] is it possible to relay using ipv6?

Tue Nov 29 11:29:25 UTC 2016

> On 29 Nov. 2016, at 18:44, Roman Mamedov <rm at romanrm.net> wrote:
> 
> On Mon, 28 Nov 2016 10:01:03 +1100
> teor <teor2345 at gmail.com> wrote:
> 
>> (I've rearranged your threads for clarity, please bottom-post in future.)
>> 
>>>> On Nov 27, 2016 11:59 AM, "root" <tor at afo-tm.org <mailto:tor at 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 at 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

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------