pre-proposal for IPv6 exit support, questions

[coderman <coderman@xxxxxxxxx>]

i'd like some feedback on possible integration of IPv6 with Tor for
exit and DNS.  all of the following changes need not be implemented
for IPv6 exit to be useful, however, i think most of them will need to
be present for clients to use IPv6 easily.

- transport:
this is perhaps the easiest layer.  the Tor specs already define IPv6
address types and formats which can finally be put to use.  is there a
good reason to keep IPv6 and IPv4 streams in different circuits?

the OR's torrc should contain an explicit OutboundBindAddress with an
IPv6 address to enable IPv6 exit.  if no IPv6 address is bound the OR
should not consider itself IPv6 capable. (otherwise all of the routers
with link local IPv6 will suddenly default to supporting IPv6?)


- exit policy:
existing default exit policy contains *:* and *:$port directives.
this should be expanded to exclude internal/reserved IPv6 address
space as well for IPv6 capable ORs.  [i've included a sample exit
policy at the end of this msg]

should IPv6 capable ORs be required to include at least one IPv6
address or netmask in their exit policy, to signal IPv6 capability?
(likewise, should non-IPv6 capable OR's be forced to exclude any IPv6
addresses)
(for example, accept [2000::]/3:* used to signal IPv6 capability)

should some other method (extended descriptor information?) be used to
identify IPv6 capable OR's?  should public IPv6 connectivity be
verified (similar to OR IP/Port reachability for routers)?


- RESOLVE and RESOLVE_PTR:
DNS for IPv6 sucks [0].  how to limit this suckiness?  some options:

if an OR is IPv6 capable, it must return AAAA and A RR's to every
query.  this (should) keep both IPv4 and IPv6 clients happy, but has
the following drawbacks:
- some AAAA lookups may take forever to timeout, thus delaying the A result.
- some AAAA lookups will fail in a way that may make a resolver
stub/library think a domain does not exit, rather than no IPv6 address
exists for this domain. (require eventdns for IPv6 resolution?)
- AAAA lookups and the IPv6 addresses returned are a waste of
time/bandwidth for IPv4 only clients, and may in fact confuse them.

if a client wishes to use IPv6 exit, somehow signal to the exit that
IPv6 is preferred, and only use the AAAA lookups/responses when the
origin has declared IPv6 interest.  this should apply when doing
RESOLVE or CONNECT to named servers (that is to say, RESOLVE should
return IPv6 addresses, and CONNECT should attempt to connect to IPv6
addresses when a server is referred to by name, like 'www.hexago.com')

other ideas / suggestions?


- misc options:
the RedirectExit option should support IPv6 destinations?

the TransListenAddress should support IPv6 addresses.  this means
using IPV6_ORIGINAL_DST instead of SO_ORIGINAL_DST (and equivalent
flags for other OS'es).

the VirtualAddrNetwork setting will need a private netmask for IPv6
ranges used in MAPADDRESS.  something in link local unicast
(FE80::/10) should work.

should clients have a "PreferIPv6" flag in their configuration to
signal OR exits that DNS and TCP connect should use IPv6 addresses
when possible?


- SOCKS5:
the torrc SOCKSBindAddress should accept an IPv6 address.  if this is
used for SOCKS5, then RESOLVE and CONNECT hostname should all prefer
an IPv6 address when possible.  (again, signal this upstream somehow?
assume that IPv6 capable exits will return IPv6 addresses?)

it would also be nice if somehow IPv4 clients could express an IPv6
preference via SOCKS5.  i'm not sure how this could be done easily
(another config option?).


- control interface:
i don't see a compelling reason to support a control port on IPv6.
as for the control spec, MAPADDRESS [::0]=hostname should work as
indicated in the spec.  the spec lists the address format as just
"::0" while accept / reject declarations need the brackets.  should
this be consistent?

what new control capabilities, if any, should be added?  the only one
that comes to mind is CHECKING_REACHABILITY like commands for IPv6
exit, or DNS lookup with AAAA responses (IPV6DNS_USELESS?, etc)


thanks in advance for any feedback and insight...

best regards,


0. "The IPv6 mess"
  http://cr.yp.to/djbdns/ipv6mess.html

- sample IPv6 default exit policy:
reject 0.0.0.0/8
reject 169.254.0.0/16
reject 127.0.0.0/8
reject 192.168.0.0/16
reject 10.0.0.0/8
reject 172.16.0.0/12
reject [0000::]/8
reject [0100::]/8
reject [0200::]/7
reject [0400::]/6
reject [0800::]/5
reject [1000::]/4
reject [4000::]/3
reject [6000::]/3
reject [8000::]/3
reject [A000::]/3
reject [C000::]/3
reject [E000::]/4
reject [F000::]/5
reject [F800::]/6
reject [FC00::]/7
reject [FE00::]/9
reject [FE80::]/10
reject [FEC0::]/10
reject [FF00::]/8
reject *:25
reject *:119
reject *:135-139
reject *:445
reject *:1214
reject *:4661-4666
reject *:6346-6429
reject *:6699
reject *:6881-6999
# accept [2000::]/3:* is implied
accept *:*