commit dbc1039e3e19b577548f9fadf205ebd0d5d71f52 Author: Nick Mathewson <nickm@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. +