Alex Le Heux on IPv6 proposals [alexlh at funk.org: Re: Links about IPv6 in Tor]

[Nick Mathewson]

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
X-Spam-Level: 

Hi Nick,

The documents look very good. You seem to have covered most things  
very well.

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:

http://ipv6and4.labs.wikimedia.org/

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.


Final remark

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.

Cheers,

Alex

On Jul 24, 2008, at 12:01, Nick Mathewson wrote:

>The current version of the proposal for IPv6 exit support in Tor is  
>here:
>
>  https://www.torproject.org/svn/trunk/doc/spec/proposals/117-ipv6-exits.txt
>
>This proposal has some issues related to IPv6 entries:
>
>  https://www.torproject.org/svn/trunk/doc/spec/proposals/118-multiple-orports.txt
>
>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
>specification.
>
>  https://www.torproject.org/svn/trunk/doc/spec/tor-spec.txt
>  https://www.torproject.org/svn/trunk/doc/spec/dir-spec.txt
>
>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  
>email.
>
>yrs,
>-- 
>Nick

-- 
The Sky is the limit. Let's set it on fire!

----- End forwarded message -----