Increase the number of Tor network relays that support IPv6

By the numbers, about 29% of Tor’s relay bandwidth supports IPv6--but functionally, only 20% of Tor’s available bandwidth supports IPv6. This is because some Guard relays are also Exit relays, and as such, they are only used as Exits by Tor clients. These limitations mean that even if an Exit relay supports IPv6, it doesn’t functionally increase the Tor network’s client to Guard IPv6 bandwidth. 

In order to better support IPv6, we aim to increase the client to Guard relay bandwidth that supports IPv6 to 33%. Reaching this goal (and completing this project) is the first step in a longer-term effort to implement “fast fallback,” which will make sure that Tor clients first try IPv4 and then try IPv6 after a short delay, using whichever option works.

To increase the functional relay bandwidth that supports IPv6, we need to improve the way we handle configuration for dual stack Tor relays (relays that support both IPv4 and IPv6). As it stands, dual stack relays require some manual configuration, which can be a setup barrier for relay operators. Automating relay IPv6 address discovery and reachability checks will help operators to run more dual stack relays more easily and, over time, increase the number of relays that support IPv6.

More information about this project at https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor55

Trac:
Child Ticket(s): #33048 (moved), #33049 (moved), #33050 (moved), #33051 (moved), #33052 (moved)

added component::core tor/tor points::53 priority::medium severity::normal sponsor::55-must status::new type::project labels

Trac:
Sponsor: Sponsor55 to Sponsor55-must

Replying to gaba:

In order to better support IPv6, we aim to increase the client to Guard relay bandwidth that supports IPv6 to 33%.

Great goal! One of the steps that will help the network health team help us get there is if we have a way to visualize progress. Like, a graph on the metrics site, or even a graph off to the side of the metrics site if they are too worried about having to maintain it forever, and maybe it only needs to be updated once a day if that's easier, where anybody can check what number we're at today.

Then it becomes an advocacy thing where we can cheer ourselves on for making progress, and point relay operators to so they can see the impact of their changes.

teor has identified some great technical improvements that will make it easier for relay operators to help out here, and we should definitely do those in order to make this change sustainable. But doing the visualization in parallel, so we can see our progress, would be swell.

Having the automation of a graph over time also lets anybody notice, even after we close this ticket as completed, that the number has mysteriously dropped and needs to be looked into.

Gaba, is this something you can bring to the metrics team? Especially if teor gives them a script that takes in a consensus and outputs a fraction?

By the numbers, about 29% of Tor’s relay bandwidth supports IPv6--but functionally, only 20% of Tor’s available bandwidth supports IPv6.

These numbers seem outdated.

onionoo data from 2020-01-24 23:00 UTC:

What cw fraction / guard/middle/exit probability has an IPv6 ORPort? CW Fraction: 31.83% Guard: 29.06% Middle: 29.79% Exit: 39.24% Relays count: 1210

daily updated onionoo based IPv6 stats: https://nusenu.github.io/OrNetStats/#ipv6-relay-stats

IPv6 related metrics graph: https://metrics.torproject.org/relays-ipv6.html

Replying to arma:

Gaba, is this something you can bring to the metrics team? Especially if teor gives them a script that takes in a consensus and outputs a fraction?

We can talk about it in the meeting next week.

Replying to nusenu:

By the numbers, about 29% of Tor’s relay bandwidth supports IPv6--but functionally, only 20% of Tor’s available bandwidth supports IPv6.

These numbers seem outdated.

onionoo data from 2020-01-24 23:00 UTC:

What cw fraction / guard/middle/exit probability has an IPv6 ORPort? CW Fraction: 31.83% Guard: 29.06% Middle: 29.79% Exit: 39.24% Relays count: 1210

daily updated onionoo based IPv6 stats: https://nusenu.github.io/OrNetStats/#ipv6-relay-stats

IPv6 related metrics graph: https://metrics.torproject.org/relays-ipv6.html

Thanks! Those numbers were from when we wrote the project last year.

Replying to gaba:

Replying to arma:

Gaba, is this something you can bring to the metrics team? Especially if teor gives them a script that takes in a consensus and outputs a fraction?

We can talk about it in the meeting next week.

I've also added these ideas to my IPv6 statistics proposal draft, see #33159 (moved).

I'll put them in the "optional work" section, and we can prioritise after all the essential work is done.

Sponsor 55 is a small grant, so we won't have time to do everything.

Replying to gaba:

Replying to nusenu:

By the numbers, about 29% of Tor’s relay bandwidth supports IPv6--but functionally, only 20% of Tor’s available bandwidth supports IPv6.

These numbers seem outdated.

onionoo data from 2020-01-24 23:00 UTC:

What cw fraction / guard/middle/exit probability has an IPv6 ORPort? CW Fraction: 31.83% Guard: 29.06% Middle: 29.79% Exit: 39.24% Relays count: 1210

daily updated onionoo based IPv6 stats: https://nusenu.github.io/OrNetStats/#ipv6-relay-stats

IPv6 related metrics graph: https://metrics.torproject.org/relays-ipv6.html

Thanks! Those numbers were from when we wrote the project last year.

nusenu, you're also using some different calculations from the grant:

• you're calculating Guard IPv6 consensus weight fraction
• the grant uses Guard-but-not-Exit IPv6 consensus weight fraction

Since exit bandwidth is scarce in the tor network, tor clients use Guard-Exits as Exits. Therefore, to support IPv6 clients, we need to increase Guard-but-not-Exit IPv6 consensus weight.

Replying to teor:

nusenu, you're also using some different calculations from the grant:

• you're calculating Guard IPv6 consensus weight fraction

I don't know about the grant but I can explain what my value says, it is not what you think it is.

I'm not looking at cw fraction to calculate the "Guard: 29.06%" line above.

I take and sum up onionoo's guard_probability [1] value of relays that have an IPv6 OrPort. The guard_probability of relays having the exit flag is always 0, with one exception: If the relay has the Exit and BadExit flags, in this specific but rare case the exit relay can have a non-zero guard probability.

• the grant uses Guard-but-not-Exit IPv6 consensus weight fraction

If the grant is about supporting Tor clients only (which I hope it is not since I thought client-to-guard supports IPv6 already) than it seems odd to use cw fraction instead of "what fraction of guard capacity is reachable via IPv6?" metrics.

[1] https://metrics.torproject.org/onionoo.html#details_relay_guard_probability

Replying to nusenu:

Replying to teor:

nusenu, you're also using some different calculations from the grant:

• you're calculating Guard IPv6 consensus weight fraction

I don't know about the grant but I can explain what my value says, it is not what you think it is.

I'm not looking at cw fraction to calculate the "Guard: 29.06%" line above.

I take and sum up onionoo's guard_probability [1] value of relays that have an IPv6 OrPort. The guard_probability of relays having the exit flag is always 0, with one exception: If the relay has the Exit and BadExit flags, in this specific but rare case the exit relay can have a non-zero guard probability.

Great, so we're using similar calculations.

• the grant uses Guard-but-not-Exit IPv6 consensus weight fraction

If the grant is about supporting Tor clients only (which I hope it is not since I thought client-to-guard supports IPv6 already) than it seems odd to use cw fraction instead of "what fraction of guard capacity is reachable via IPv6?" metrics.

The grant is about increasing the number of relays on IPv6, so that it's safer for clients to use IPv6: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor55

[1] https://metrics.torproject.org/onionoo.html#details_relay_guard_probability

Replying to arma:

Replying to gaba:

In order to better support IPv6, we aim to increase the client to Guard relay bandwidth that supports IPv6 to 33%.

Great goal! One of the steps that will help the network health team help us get there is if we have a way to visualize progress. Like, a graph on the metrics site, or even a graph off to the side of the metrics site if they are too worried about having to maintain it forever, and maybe it only needs to be updated once a day if that's easier, where anybody can check what number we're at today.

Then it becomes an advocacy thing where we can cheer ourselves on for making progress, and point relay operators to so they can see the impact of their changes.

teor has identified some great technical improvements that will make it easier for relay operators to help out here, and we should definitely do those in order to make this change sustainable. But doing the visualization in parallel, so we can see our progress, would be swell.

Having the automation of a graph over time also lets anybody notice, even after we close this ticket as completed, that the number has mysteriously dropped and needs to be looked into.

Gaba, is this something you can bring to the metrics team? Especially if teor gives them a script that takes in a consensus and outputs a fraction?

Thanks for this feedback, Roger.

I've added metrics graphs, relay search pseudo-flags, and a consensus-health IPv6 section as optional changes in Proposal 313: https://lists.torproject.org/pipermail/tor-dev/2020-February/014158.html

We've spoken with the metrics team, and we're not sure what capacity they have over the next 6 months. Or how much funding will be available in Sponsor 55, after all the required work is done.

So we aren't sure what we will be able to do yet.

(We can also apply for other grants to do this metrics work.)

Replying to teor:

Replying to nusenu:

Replying to teor:

nusenu, you're also using some different calculations from the grant:

• you're calculating Guard IPv6 consensus weight fraction

I don't know about the grant but I can explain what my value says, it is not what you think it is.

I'm not looking at cw fraction to calculate the "Guard: 29.06%" line above.

I take and sum up onionoo's guard_probability [1] value of relays that have an IPv6 OrPort. The guard_probability of relays having the exit flag is always 0, with one exception: If the relay has the Exit and BadExit flags, in this specific but rare case the exit relay can have a non-zero guard probability.

Great, so we're using similar calculations.

• the grant uses Guard-but-not-Exit IPv6 consensus weight fraction

If the grant is about supporting Tor clients only (which I hope it is not since I thought client-to-guard supports IPv6 already) than it seems odd to use cw fraction instead of "what fraction of guard capacity is reachable via IPv6?" metrics.

The grant is about increasing the number of relays on IPv6, so that it's safer for clients to use IPv6: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor55

[1] https://metrics.torproject.org/onionoo.html#details_relay_guard_probability

Thanks for this feedback, I have explicitly described the divisors for each calculation in my draft proposal 313: https://lists.torproject.org/pipermail/tor-dev/2020-February/014158.html

Trac:
Points: N/A to 52

Trac:
Points: 52 to 53

changed time estimate to 424h

mentioned in issue #33052 (moved)

mentioned in issue #33051 (moved)

mentioned in issue #33048 (moved)

mentioned in issue #33049 (moved)