commit 2cb38a6ef43fd3b5de7508622a815d8810275e0b Author: Nick Mathewson nickm@torproject.org Date: Wed Mar 2 11:29:41 2011 -0500
ipv6-plan patch from ioerror --- proposals/ideas/xxx-ipv6-plan.txt | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/proposals/ideas/xxx-ipv6-plan.txt b/proposals/ideas/xxx-ipv6-plan.txt index e9ffb10..12bd4d4 100644 --- a/proposals/ideas/xxx-ipv6-plan.txt +++ b/proposals/ideas/xxx-ipv6-plan.txt @@ -18,13 +18,16 @@ Motivation:
What needs to change:
- Tor uses the Internet in many ways. There four main ways that + Tor uses the Internet in many ways. There are four main ways that will need to change for IPv6 support, from most urgent to least urgent.
+ 0. An unknown laundry list of issues that will supersede all other + listed issues in this list. + 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 + 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. @@ -35,8 +38,11 @@ What needs to change: 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 + 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.
Designs that we will need to do:
@@ -51,13 +57,16 @@ Designs that we will need to do: 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 + 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 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