[tor-commits] [torspec/master] Tweak ipv6 roadmap into shape

[Bjoern A. Zeeb]

On 30. Dec 2011, at 12:03 , nickm at torproject.org wrote:

> +0. Overview
> +
> +  IPv6 support is important, but too large to do in a single step.
> +  Therefore, we need a plan for how to build IPv6, starting with high
> +  benefit-per-effort items, and eventually getting full IPv6 support in
> +  Tor's protocols and implementation.
> +
> +  The phases in brief:
> +
> +    1. Remove internal barriers and limitations in Tor's implementation
> +       that would affect IPv6 hosts and multi-stack hosts.
> +

Yeah having the socks side support IPv6 (if not yet) would be awesome as one
could run it on a dual stacked edge host and still use it form no-IPv4 clients.

> +    2. Make client->private bridge connections support IPv6.
> +
> +    3. Make client->public bridge connections support IPv6.
> +
> +    4. Make client->relay connections support IPv6.
> +
> +    5. Support exiting to IPv6 addresses over Tor.
> +
> +    6. Allow relays to connect to one another over IPv6.
> +
> +0.1. Motivation
> +
> +  4 billion addresses wasn't enough.
> +
> +  Also, the IPv6 world is currently not quite so censored as the IPv4
> +  world, so we should take advantage of that.
> +
> +1. The roadmap in detail
> +
> +  We list the steps below in rough implementation order.  There may be
> +  issues with what we can do without hurting anonymity which has to do
> +  with how many relays we have on IPv6.  So maybe it's not wise to derive
> +  the deployment order from the implementation order.  The following tasks
> +  also differ hugely in size.
> +
> +1.1. Phase 1: Infrastructure, part 1
> +
> +  Throughout Tor, there are pieces of code that make certain assumptions
> +  which we will need to change in order to support the features below.
> +
> +  Most of these pieces are already implemented, including:
> +
> +    * We have switched nearly all of our code that assumed an IPv4
> +      address to assume an IPv4 or an IPv6 address.
> +
> +    * We have relaxed the assumption that a Tor relay or bridge may have
> +      one address.
> +
> +1.2. Phase 2: Client->Private Bridge connections
> +
> +  The first piece of IPv6 functionality to deploy is allowing clients
> +  to talk to bridges over IPv6.  (This is simplest because it requires
> +  relatively little design, and has minimal impact on the rest of the
> +  network and codebase.)
> +
> +  The Tor side of this more or less complete. Bridges can advertise
> +  themselves as having IPv4 and IPv6 address, and clients can use a
> +  bridge over IPv6 if configured to know about its IPv6 address.
> +
> +  Design issues to solve:
> +    * If the user configures both the IPv4 and the IPv6 address of a
> +      given bridge, which one does the client use?  (Defaulting to IPv6
> +      if possible seems like a reasonable policy for starters).
> +    * Should we (can we?) detect whether the client is configured to use
> +      its ethernet MAC to build the last part of its address, and
> +      treat it as a privacy issue inasmuch as it allows a bridge to
> +      link connections from a single ethernet device as it moves around
> +      the net?  If possible, we should at least detect this, tell
> +      the user how to work around it, and prefer IPv4 so long as our
> +      IPv6 address identifies our device.

Yeah you should be able to detect this.  You might also want to consider
RFC 4941 priv exts and take them into account.  Also be aware that even
if there is a MAC derived address it might not be used.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.