[tor-commits] [torspec/master] Add the start of an "ipv6 issues" document to proposals/ideas

[nickm at torproject.org]

commit dbc1039e3e19b577548f9fadf205ebd0d5d71f52
Author: Nick Mathewson <nickm at torproject.org>
Date:   Wed Mar 2 01:51:49 2011 -0500

    Add the start of an "ipv6 issues" document to proposals/ideas
    
    One of the sponsors wanted this for March, I believe.
---
 proposals/ideas/xxx-ipv6-plan.txt |   90 +++++++++++++++++++++++++++++++++++++
 1 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/proposals/ideas/xxx-ipv6-plan.txt b/proposals/ideas/xxx-ipv6-plan.txt
new file mode 100644
index 0000000..e9ffb10
--- /dev/null
+++ b/proposals/ideas/xxx-ipv6-plan.txt
@@ -0,0 +1,90 @@
+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-yes
+   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 four 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 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 unable to connect to Tor at all.  Next most
+   important is to allow IPv6 XXXX
+
+Designs that we will need to do:
+
+   For IPv6-only clients, we'll need to specify that routers can have
+   multiple addresses and ORPorts, and allow secondary addresses/ports
+   that.  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 needed instead more appropriate notions of "closeness" and
+   "similarity".
+
+   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 that 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 (or even in the
+   form of!) with 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.
+