Filename: xxx-ipv6-plan.txt
Title: How to implement IPv6 in Tor
Author: Nick Mathewson
Created: 1 March 2011
Status: Draft

Overview:

   This document outlines what we'll have to do to make Tor fully
   support IPv6.  It refers to other proposals, current and as-yet
   unwritten.  It suggests a few incremental steps, each of which on
   its own should make Tor more useful in the brave new IPv6 future of
   tomorrow.

Motivation:

   Turns out, 4 billion addresses wasn't enough.

What needs to change:

   Tor uses the Internet in many ways.  There are three main ways that
   will need to change for IPv6 support, from most urgent to least
   urgent.

     1. Tor must allow connections from IPv6-only clients. (Currently,
        routers and bridges do not listen on IPv6 addresses, and can't
        advertise that they support IPv6 addresses, so clients can't
        learn that they do.)

     2. Tor must transport IPv6 traffic and IPv6-related DNS traffic.
        (Currently, Tor only allows BEGIN cells to ask for connections
        to IPv4 targets or to hostnames, and only allows RESOLVE cells
        to request A and PTR records.)

     3. Tor must allow nodes to connect to one another over IPv6.

   Allowing IPv6-only clients is the most important, since unless we
   do, these clients will be unable to connect to Tor at all.  Next
   most important is to support IPv6 DNS related dependencies and
   exiting to IPv6 services. Finally, allowing Tor nodes to support a
   dual stack of both IPv4 and IPv6 for interconnection seems like a
   reasonable step towards a fully hybrid v4/v6 Tor network.

   One implementation hurdle that will need to get resolved alongside
   these changes is to convert uint32_t to tor_addr_t in many more places
   in the Tor code, so we can handle addresses being either IPv4 or IPv6.
   There are a few cases, e.g. the local router list, where we'll want
   to think harder about the resource requirements of keeping tens of
   thousands of larger addresses in memory.

   More issues may of course also be discovered as we develop solutions
   for these issues, some of which may need to take priority.

Designs that we will need to do:

   For IPv6-only clients, we'll need to specify that routers can have
   multiple addresses and ORPorts.

   There is an old proposal (118) to try to allow multiple
   ORPorts per router.  It's been accepted; it needs to be checked for
   correctness, updated to track other changes in more recent Tor
   versions, and updated to work with the new microdescriptor designs.

   Additionally, we'll need to audit the designs for all our codebase
   for places that might assume that IPs are a scarce resource.  For
   example, clients assume that any two routers occupying an IPv4 /16
   network are "too close" topologically to be used in the same
   circuit, and the bridgedb HTTPS distributor assumes that hopping
   from one /24 to another takes a little effort for most clients.
   The directory authorities assume that blacklisting an IP is an okay
   response to a bad router at that address.  These and other places
   will instead need more appropriate notions of "closeness" and
   "similarity".

   We'll want to consider geographic and political boundaries rather than
   purely mathematical notions such as the size of network blocks.

   We'll need a way to advertise IPv6 bridges, and to use them.

   For transporting IPv6-only traffic, we have another accepted design
   proposal (117).  It has some open questions concerning proper
   behavior with respect to DNS lookups, and also needs to be checked
   and updated to track current Tor designs.

   We do not have a current accepted design proposal for allowing
   nodes to connect to each other via IPv6.  Allowing opportunistic
   IPv6 traffic between nodes that can communicate with both IPv4 and
   IPv6 will be relatively simple, as will be bridges that have only
   an IPv6 address: both of these fall out relatively simply from
   designing a process for advertising and connecting to IPv6
   addresses.  The harder problem is in supporting IPv6-only
   Tor routers.  For these, we'll need to consider network topology
   issues: having nodes that can't connect to all the other nodes
   will weaken one of our basic assumptions for path generation, so
   we'll need to make sure to do the analysis enough to tell whether this
   is safe.

Ready, fire, aim: An alternative methodology

   At least one volunteer is currently working on IPv6 issues in Tor.
   If his efforts go well, it might be that our first design drafts
   for some of these open topics arrive concurrently with (or even in
   the form of!) alpha code to implement them.  If so, we need to
   follow a variant of the design process, extracting design from code
   to evaluate it (rather than designing then coding).  Probably,
   based on design review, some changes to code would be necessary.

