Re: [tor-relays] Emerald Onion's new relays

Hi,

On 14 Aug 2019, at 03:42, NOC <tor@xxxxxxxxxx> wrote:

On 12.08.2019 23:39, teor wrote:

On 13 Aug 2019, at 05:08, Roman Mamedov <rm@xxxxxxxxxxx> wrote:

On Mon, 12 Aug 2019 00:46:50 +0000
Christopher Sheats <yawnbox@xxxxxxxxxxxxxxxx> wrote:

Tor Project, please increase your #IPv6 awareness/outreach similar to how

ARIN and the other RIRs try very hard to do.

Before outreach Tor would need some actual IPv6 support, as in using it for
the actual traffic of relay-to-relay communication. I tried running a few
relays with very fast IPv6 and slow IPv4 (due to a common NAT frontend which
was the bottleneck), but it was a complete nonstarter.

Tor relays currently don't connect over IPv6. When 10% of the network

supported IPv6, there wasn't much point, because putting a very small

number of paths over IPv6 has privacy risks. So we focused on client, guard,

and exit IPv6 support.

But currently, about 30% of the consensus weight supports IPv6. So we

are working on a grant for IPv6 support (see below).

We won't be able to prefer IPv6 until 50-67% of relays support IPv6, for

load-balancing and privacy reasons. But we plan on using the

"Happy Eyeballs" (RFC 8305) algorithm on dual-stack relays. So

sufficiently slow IPv4 will cause relays to connect over IPv6. (And we can

tune the load-balancing using the IPv4 to IPv6 delay.)

I still would say that these stats are deeply flawed. Looking at the Autonomous Systems where the relays are located from the top100, 99 of them do support IPv6 (85,7625& consensus weight), the only one which doesn't support is AS4224 but since they manage their AS themselves they would only need to ask their LIR and would get IPv6.

The top 100 relays are only 13-18% of the total advertised bandwidth:

https://metrics.torproject.org/advbwdist-relay.html?start=2019-05-16&end=2019-08-14&n=1&n=100

https://metrics.torproject.org/bandwidth.html

So my conclusion is not that there is any need to wait for adaption, only for software support.

It's hard to draw accurate conclusions from less than 20% of the network.

What about the other 80% of the network?

Release one stable from which point you need IPv6 and the operator will see that there is something to be done. You won't affect older versions since they still can speak with you but you won't get in the consensus from that point because you don't fulfill all requirements for it.

I don't think kicking relay operators off the network when they upgrade to a new version is helpful. We *want* people to upgrade.

Also, abruptly reducing the capacity of the network is a bad experience for Tor users. They will have slow traffic or connection failures.

We call these kinds of abrupt changes "flag days", and we try hard to avoid them.

Here's a plan that will take longer, but help more relay operators get on IPv6:

Automatically detect and use IPv6 on relays:

1. Release a tor version that automatically detects IPv6 on relays, and uses it if it works. But turn it off by default, and have an option and a consensus parameter to turn it on.

2. Ask relay operators to test the new feature in the alphas and release candidates.

3. Once the feature has had enough testing, turn it on for all relays using the consensus parameter.

4. Encourage relay operators to configure IPv6 on their relay's network stack and upstream connection

Reduce the consensus weight for IPv4-only relays:

1. Wait until we have enough dual-stack relays, that we can afford to send them more traffic. (We need metrics for IPv6 traffic, which we don't have right now.)

2. Add a consensus parameter and consensus method that reduces the consensus weight for IPv4-only relays by a percentage.

3. Gradually reduce the weight of IPv4 relays.

4. Encourage relay operators to configure IPv6 on their relay's network stack and upstream connection

Wait until we have seen some good research on non-clique anonymity networks, or remove IPv4 and allow IPv6 at the same time.

Allow IPv6-only guards:

1. Add automatic IPv6 support to clients, so clients use IPv4 and IPv6 when available

2. Optional: add automatic IPv6 support to bridges, so bridges use IPv4 and IPv6 when available

3. Wait until we have enough dual-stack middle relays, and dual-stack or IPv6 clients and bridges

4. Allow IPv6-only guards

5. Optional: allow IPv6-only bridges

Allow IPv6-only exits:

1. Improve Tor client and Tor exit support for IPv6 exit connections, allowing clients to discover and remember whether a site is IPv4-only, dual-stack, or IPv6-only

2. Wait until we have enough dual-stack middle relays, and enough internet sites that support IPv6

3. Allow IPv6-only exits

Allow IPv6-only middles:

1. Wait until we have enough dual-stack guards and exits

2. Allow IPv6-only middles

Remove IPv4-only relays:

1. Wait until the proportion of IPv4-only guards, middles, or exits is small enough

2. Remove IPv4-only relays from that role (we can turn guards and exits into middles)

I've added this draft plan to the IPv6 roadmap page:

https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#DraftLong-TermTransitionPlan