I just read nickm's post on Tor IPv6 migration at https://blog.torproject.org/blog/ipv6-future-i-hear --- What needs to change Tor uses the Internet in many ways. There are three main ways that will need to change for IPv6 support, from most urgent to least urgent.
Tor must allow connections from IPv6-only clients. (Currently, 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.)
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.)
Tor must allow nodes to connect to one another over IPv6. Allowing IPv6-only clients is the most important, since unless we 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. ---
One thought that may or may not be relevant to your sequence of implementation, but that you should be made aware of if you aren't already. (You may well be already be aware of it).
The most important IPv6 compatibility task in Tor is that the Tor servers can accept inbound connections over IPv6. The second most important task is that Tor servers can make outbound IPv6 connections to services on the Internet.
This is, and that may not be intuitive, not isomorphic with Tor clients being able to perform outbound connections to Tor servers over IPv6.
Jane Tor User's laptop does, in all likelihood, not have a globally routable IP address. Instead, Jane's laptop has been assigned an RFC 1918 address by her cable modem or the NAT at the Internet cafe.
It is Jane's cable modem that either does today or very soon will use an IPv6 address to communicate upstream. If the Tor server to which Jane is connecting does not support native IPv6, then Jane's provider will have to force her Tor traffic through a provider-level IPv6-to-IPv4 gateway.
Some days that gateway will work well. Other days that proxy will be overloaded and won't work all that well. Both days, traffic latency will be increased unless the Tor server to which Jane connects accepts inbound IPv6.
This talk by ARIN's CEO John Curran explains the issue beautifully. Watch from the 8 minute mark: http://www.youtube.com/watch?v=S3i4RRubCvI
(When traffic has to be forced through a provider-level gateway out of technical necessity, obvious opportunities for easy filtering arise that I will not explore further in this post).
In summary, outbound IPv6 Tor connections from end-users can wait until after Tor servers accept inbound IPv6 connections (and after exit nodes can make outbound IPv6 connections to other services).
--Lucky
On 2011-May-15 23:53, Lucky Green wrote: [..]
In summary, outbound IPv6 Tor connections from end-users can wait until after Tor servers accept inbound IPv6 connections (and after exit nodes can make outbound IPv6 connections to other services).
Correct, but the bigger issue, which I have mostly tackled is that the current in-git tor is not address family agnostic.
The moment Tor is address family agnostic it can listen on any address type, the next step is to teach the internal protocol, the onion routing portion, to support IPv6 connectivity and a probably more intrusive patch to teach it to support multiple address/port combo's per node.
Most of that "client" code is there already as SOCKS5 fortunately supports IPv6 resolving and that code is implemented already, SOCKS4(a) does not support IPv6 though, possibly if one connects by hostname.
Current IPv6 diff (that does not compile completely yet though):
$ wc tor-ipv6.diff 2968 12526 116496 tor-ipv6.diff
Need some sleep now, and got a concert tomorrow evening (and that thing called work during the day...), but I'll try to finish it off on tuesday evening and then get it here on the list in a chunked way so that the changes can easily be read and then that it gets integrated into the master branch.
Greets, Jeroen
-
Jeroen Massar -
Lucky Green