Alex Le Heux on IPv6 proposals [alexlh at funk.org: Re: Links about IPv6 in Tor]
nickm at freehaven.net
Thu Jul 24 15:28:46 UTC 2008
Forwarding with permission; these include general comments on Proposal
117 and Proposal 118 issues.
----- Forwarded message from Alex Le Heux <alexlh at funk.org> -----
From: Alex Le Heux <alexlh at funk.org>
To: Nick Mathewson <nickm at freehaven.net>
Subject: Re: Links about IPv6 in Tor
The documents look very good. You seem to have covered most things
A few comments:
1.2 Router IPv6 exit support
There are cleants that have an IPv6 global unicast address, but have
broken IPv6 connectivity. The problem used to be worse in the past,
but once IPv6 deployment gets going, it might get worse for a while.
Wikipedia is testing for just this, their results are here:
This is not something to really worry about, but more something to
keep in mind.
3.3. Support for IPv6 only transparent proxy clients
During the transition phase from IPv4 to IPv6, it seems likely that
there will be wildly varying ways to invent the wheel. Being as
flexible as possible about what configurations will still work upfront
seems like a good idea.
Eventually, clients, nodes and destination servers may have any
combination of v4-only, dual-stack, v6-native-only or any kind of
transition mechanism like 6to4, etc.
I believe Tor makes sure it picks the nodes from different /16s. In
IPv6 you could employ a similar strategy. The fact that IPv6 address
policy is a bit more structured and globally co-ordinated could help:
- Minimum allocation size to ISPs is a /32. The vast majority of the
ISP allocations are /32s.
- End-user assignment sizes are variable, unfortunately, with most
being a /48 although /56s are now appearing as well.
- Direct End-User assignments (Provider Independent, independently
routed blocks) are /48 minimum size. There are some larger
assignments, but most are a /48.
The disadvantage of picking /32 is that all direct end-user
assignments will then be lumped together, while all these assignments
to seperate organistions would come from a handfull of /32s.
The disadvantage of picking /48 is that nearly all "normal" end-users
will be in ISP aggregated space, so you might end up with the entire
path consisting of nodes living in a single ISP.
You could also do something more fine grained, as the blocks that the
RIRs make direct end-user assignments from are well known.
I'll have a look at the other documents as well, if I've got more
comments I'll send them.
On Jul 24, 2008, at 12:01, Nick Mathewson wrote:
>The current version of the proposal for IPv6 exit support in Tor is
>This proposal has some issues related to IPv6 entries:
>To follow along with some of the details here, it may be necessary to
>look at the main specification documents. The most relevent ones are
>the core network protocol specification and the directory
>If you've got any comments on these, the best place to comment would
>be the or-dev mailing list. It's subscriber-only, but it's
>theoretically speaking where technical design discussion is supposed
>to be happening. Also feel free to email the tor-assistants list:
>it's a small list of people who don't mind getting a huge pile of
The Sky is the limit. Let's set it on fire!
----- End forwarded message -----
More information about the tor-dev