On 3 Oct 2017, at 08:52, Scott Bennett bennett@sdf.org wrote:
teor teor2345@gmail.com wrote:
On 3 Oct 2017, at 03:07, Scott Bennett bennett@sdf.org wrote:
In the meantime, I think it would be great to have IPv6-only relays, to avoid this kind of NAT-related issues.
We'd love to make this happen, but the anonymity implications of mixed IPv4-only and IPv6-only (non-clique) networks need further research. Search the list archives for details.
Couldn't that be taken care of in the tor client code? For example, a client, having chosen a path through which an IPv6-only relay, could extend the path by one hop to tunnel through a node with both types of interface published?
Yes, clients choose paths, and could choose them using these kinds of restrictions. But current tor relay versions won't extend to other relays over IPv6. Because we don't understand the anonymity implications of restricting the next relay in the path based on the previous relay. Which is why we need further research.
Here's a procedure: if the next hop/destination does not use a protocolin common with the client/current hop, a dual-protocoled node must be interposed; else use the originally selected hop/destination directly.
But is this procedure safe? And is it an efficient use of resources to add extra hops? (That is, is there a more efficient 3-hop algorithm that's just as safe?) We need research to answer these questions.
The client-to-first-hop situation is analogous to using a set of entry guards today, so that much should be okay. What do IPv6-only clients currently do?
Choose a relay with an IPv6 ORPort. (Or configure a bridge with an IPv6 ORPort or pluggable transport.)
IPv6-only clients need to be manually configured using "ClientUseIPv4 0", because this feature is still experimental. We think it will be safer when all dual-stack clients use some IPv6 guards.
Allowing IPv6 destinations today limits exit-hop selections to dual-protocol-capable exit nodes
No, IPv4-only exits are still useful and used, because tor clients typically send DNS names to exits. IPv6 DNS records typically have IPv4 as well, so any exit will work. (There's a ticket for better handling of DNS that only resolves to IPv6.)
And in the rare case of address literals, the client can choose a capable exit. (I think there's a ticket for this, too.)
which is like using an "ExitNodesIPv6" (if there were such a thing) line in torrc with a long and growing list of nodes.
There are flags on SOCKSPort for IP versions, including PreferIPv6, which is the default.
How long would that list have to be for the warning on the man page under the ExitNodes statement definition to become unimportant? How many were there when IPv6 destinations were first allowed?
The situation isn't analogous.
For safety, IPv6 exit destinations were turned off by default until we had enough IPv6 exits. Now they are on by default.
But we haven't done the same thing for relays, because we don't know how to design the feature so it's safe.
For interposing dual-protocoled nodes along the way, how many do therehave to be for it to become "not too limiting"?
This is one of the questions we need researchers to answer.
A related question is can a relay with only an IPv4 address published currently set an IPv6 OutboundBindAddress?
Yes. This is useful for IPv6 exits without a fixed IPv6 ORPort address.
That's okay, but what if the node is an entry-and-middle node only?
Relays don't extend to IPv6, so you can set the option, but it won't do anything, because there are no outbound IPv6 connections.
Tim