pre-proposal for IPv6 exit support, questions

[Nick Mathewson]

On Wed, Jun 06, 2007 at 11:18:57PM -0700, coderman wrote:
> 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.

Cool; I would like to get this feature into the 0.2.0.x series.

(Independently, I'm also interested in support for IPv6-only
_clients_, but that seems orthogonal.)

> - 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?

No.  (I hope we don't do that now, do we?)

> 
> 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?)

Hmmm.  I understand the point of this, but I don't think
OutboundBindAddress is the way to go.  OutboundBindAddress is used
right now to say "Make sure that all outgoing connections use this
address."  I don't want to add an extra meaning.

If I understand correctly, link-local and site-local IPv6 addresses
are easy to detect.  Couldn't Tor do this automatically, as it detects
RFC 1918 addresses now?

> - 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?

There are two issues here.  If we're we talking about "Does the
administrator need to set an IPv6 address in the exit policy in torrc
to say 'Hey, I do ipv6'," I'm not sure.  That would be quite unlike
the current IPv4 behavior, where there's a default exit policy unless
you change it.  But maybe it's okay for now.

But if we're talking about "Does the *node* need to _list_ an ipv6
address in the exit policy in its router to be considered
ipv6-capable", that's more reasonable.  I like that idea, in fact.

> (likewise, should non-IPv6 capable OR's be forced to exclude any IPv6
> addresses)

No; these ORs already exist, running older versions of Tor.  If not
mentioning IPv6 meant that you supported it, then all 0.1.1.x and
0.1.2.x routers would seem to support IPv6.

> (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?

I like the idea of "If you list yourself as able to connect to ipv6
addresses in your exit policy, you are ipv6 capable".

>  should public IPv6 connectivity be
> verified (similar to OR IP/Port reachability for routers)?

Verifying the ability to _exit_ is outside of what Tor authorities do
now; this sounds like a fine job for Mike Perry's "Snakes on a Tor"
program.

> 
> - 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.

Ugh.

> - 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?)

Eventdns is already required in Tor 0.2.0.x-alpha; we don't do
dnsworkers any more.  (They sucked, and platform resolver libraries
sucked worse.)

> - AAAA lookups and the IPv6 addresses returned are a waste of
> time/bandwidth for IPv4 only clients, and may in fact confuse them.

Well, a RESOLVED cell is the same size no matter what's in it...

> 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')

Hmmm.  I'm okay saying "If there is an ipv4 address, I will connect to
the ipv4 address.  I'll only connect to the ipv6 address if I find
that there's no ipv4 address and there's only an ipv6 address, or if
you request the ipv6 address explicitly."

I think there's room for a flag in BEGIN and RESOLVE cells, though we
might need to make sure we only set the flag for newer Tors that
accept flags there. 

> other ideas / suggestions?
> 
> 
> - misc options:
> the RedirectExit option should support IPv6 destinations?

Yes; or we should rip it out.  (Does anybody actually use it?)

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

Right, but this is an implementation issue.

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

Right.  I would prefer if there were a range of _host-local_ addresses
(like 127/8 in IPv4), though.

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

Hmm. I'm not sure.  I'd go with "Not unless somebody turns out to need
it." for now.

> - 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?)

Hmmm.  Neat idea.

> 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?

It should be consistent; let's do the brackets.

> 
> 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:

Hm.  At the descriptor level, we can't do it like this.  Existing Tors
can't parse IPv6 addresses in exit policies, and so won't accept any
descriptor that has them.

I think we need to create new "accept6" and "reject6" items for
descriptors, and intermix them with existing accept and reject items.

> 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 *:*

Other semantic stuff you haven't specified:

  * it looks like you're assuming that "*" means "All IPv4 and all
    IPv6" addresses.  That's cool.  We can have "0.0.0.0/0" as our
    notation for "all IPv4 addresses" and "[::]/0" as our notation for
    "all IPv6 addresses".

  * Are we assuming that ::ffff:1.2.3.4 and 1.2.3.4 and the obsolete
    ::0:1.2.3.4 are all the same address for the purpose of exit
    policy?  I think we have IPv4 policies also apply to IPv4-mapped
    IPv6 addresses, so that "reject 10.0.0.0" also means "reject
    ::ffff:10.0.0.0".  Otherwise, everybody's exit policy will need to
    get twice as big.

peace,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070607/5c98ee77/attachment.pgp>