[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: pre-proposal for IPv6 exit support, questions
On 6/7/07, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
...
> 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?
that's a better idea. my only concern was routers with a public IPv4,
a site local IPv6 that provides route to 2000::/3. this is probably
an obscure edge case not worth worrying about. (even 6to4 tunneled
endpoints get a 2002::/16)
> - exit policy: ...
> should IPv6 capable ORs be required to include at least one IPv6
> address or netmask in their exit policy, to signal IPv6 capability?
...
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.
yes, this was the intent. it should work automagically if a (!local)
IPv6 address is detected, and then the IPv6 relevant parts enabled in
the exit policy. this would then be used to identify IPv6 capable
exits.
> 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.
agreed. that makes sense.
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.)
...
> 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...
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.
another possibility is providing a RESOLVE6 that only deals with AAAA
resource records. if the client prefers IPv6, it can request RESOLVE6
lookups, and then always provide CONNECT with an IPv6 address,
removing ambiguity.
likewise, in the IPv6 SOCKS5 example below, an IPv6 client using the
Tor SOCKS proxy will default to using RESOLVE6 for names in SOCKS
requests, and IPv6 CONNECTs.
hacking RESOLVE / RESOLVE6 this way doesn't seem too elegant. it
would avoid long timeouts for AAAA lookups when only IPv4 addresses
are desired; i don't know how common this is, but it has caused
problems in the past.
> the RedirectExit option should support IPv6 destinations?
Yes; or we should rip it out. (Does anybody actually use it?)
ripping it out seems like a good idea.
> 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.
the FC00::/7 unique local prefix seems well suited for this then.
the Global ID is randomly populated and the Subnet ID can be set to an
arbitrary value. MAPADDRESS then selects Interface ID's as needed.
[0]
> 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.
this would be another benefit of RESOLVE6 and explicit CONNECT (or
MAPADDRESS) with IPv6 addresses.
> - 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.
ok.
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".
yes, this should be made explicitly clear in a proposal. :)
* 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.
the IPv4 mapped IPv6 addresses are usually encountered if a listening
socket is bound to both IPv4 and IPv6 addresses on a given port (or
similar situations).
if the SOCKS5 interface, for example, got a request for an IPv4 mapped
IPv6 address, i think it should CONNECT that request directly via
IPv4. the application using SOCKS would still see an IPv4 mapped IPv6
address, as desired, but the transport would function more in line
with the way hosts handle these addresses now.
it would seem easier (in terms of code and design) to eliminate IPv4
mapped IPv6 destinations in an exit policy. this should be explicitly
stated in a proposal too.
thanks for the comments. i've got enough detail to get a draft
proposal implemented. (i think :)
best regards,
0. RFC 4193 Unique Local IPv6 Unicast Addresses
http://www.faqs.org/rfcs/rfc4193.html