[tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!

teor teor2345 at gmail.com
Tue Jun 2 15:16:54 UTC 2015


> Date: Fri, 22 May 2015 19:29:43 +0500
> From: Roman Mamedov <rm at romanrm.net>
> 
> On Fri, 22 May 2015 13:31:02 +0000
> Speak Freely <when2plus2is5 at riseup.net> wrote:
> 
> > Uhh, I would like to point out that it would be exceptionally stupid
> > to have Tor autoconfigure IP addresses, regardless of whether it's
> > IPv4 or IPv6.
> 
> On IPv4 it currently does. There is zero rationale as to why IPv6 must be
> different from IPv4 in this aspect.

IP address autodetection is a useful feature for those servers which are dynamically assigned IP addresses. But it's not appropriate in every circumstance, which is why the ORPort and DirPort config options allow an IP address to be specified. It's only in the absence of a configured IP that autodetection is performed.

Here are the enhancement requests in trac that need to be completed for IPv6 address autodetection:

The enhancement request for Tor autodetecting IPv6 addresses is here:
https://trac.torproject.org/projects/tor/ticket/5940

Since Tor normally autodetects its IPv4 address via its first directory request, this requires the directory authorities and/or fallback directories to be on IPv6 answering directory requests:

Directory Authorities on IPv6
https://trac.torproject.org/projects/tor/ticket/6027

Fallback Directories on IPv6
https://trac.torproject.org/projects/tor/ticket/8374
Fallback Directories Initial Release on IPv4/IPv6
https://trac.torproject.org/projects/tor/ticket/15775

Clients/Relays will also need to query directory servers on both IPv4 and IPv6 to autoconfigure both addresses. Currently, directory requests are only made using the default IP protocol, or IPv4 (I'm not sure which).

Once these client and server changes are in place, we then need to test clients to ensure they will bootstrap correctly:
* When clients are on IPv4 only, mixed IPv4/IPv6, and IPv6 only; (3)
Combined with:
* On first run and subsequent runs; (2)
Combined with:
* When the directory authorities are available on IPv4 only, IPv4/IPv6, and IPv6 only;
* When the directory authorities aren't available, and Fallback Directories are available on IPv4 only, IPv4/IPv6, and IPv6 only; (6)
Combined with:
* Using HTTP (DirPort) and Tunneled (ORPort) directory fetches. (2)

          4         4/6       6
a4        Y         Y         f
a4/6      Y         Y         Y
a6        f         Y         Y
f4        Y         Y         N
f4/6      Y         Y         Y
f6        N         Y         Y

Y = Yes, Tor should bootstrap
f = Tor should use other authorities or fallback directories with matching IP version(s)
N = Tor should fail to bootstrap if it doesn't have access to any directories with matching IP version(s), and it doesn't have a recent consensus. Otherwise, it should find a directory with a matching IP version. This may involve a tunneled directory request if DirPorts are not available but ORPorts are, and Tor has enough information to tunnel over an ORPort (this might not apply in the first run case).

That's a lot of different combinations that we need to test and ensure they work as intended. And I am concerned about the complexity of the "N" case.

We'd appreciate any help on these IPv6 enhancements, particularly coding the server-side changes, as it's difficult to code and test the client-side changes without them.

teor

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150603/a6f89272/attachment.sig>


More information about the tor-relays mailing list