Opened 4 months ago

Last modified 4 months ago

#33045 new project

Increase the number of Tor network relays that support IPv6

Reported by: gaba Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points: 53
Reviewer: Sponsor: Sponsor55-must

Description

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

Child Tickets

TicketStatusOwnerSummaryComponent
#33048newO1.1 - Propose and implement IPv6 ORPort reachability checks on relaysCore Tor/Tor
#33049newO1.2 - Make relays figure out their own IPv6 addressCore Tor/Tor
#33050newO1.3 - Integration test Tor relays over IPv6 using chutneyCore Tor/Chutney
#33051newO1.4 - Measure the number of Tor relays that support IPv6 reachability checksCore Tor/Tor
#33052newO1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6Core Tor/Tor

Change History (13)

comment:1 Changed 4 months ago by gaba

Sponsor: Sponsor55Sponsor55-must

comment:2 in reply to:  description ; Changed 4 months ago by 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?

comment:3 Changed 4 months ago by 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

Last edited 4 months ago by nusenu (previous) (diff)

comment:4 in reply to:  2 ; Changed 4 months ago by 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.

comment:5 in reply to:  3 ; Changed 4 months ago by 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.

comment:6 in reply to:  4 Changed 4 months ago by teor

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.

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.

comment:7 in reply to:  5 ; Changed 4 months ago by teor

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.

comment:8 in reply to:  7 ; Changed 4 months ago by 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.

  • 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

comment:9 in reply to:  8 ; Changed 4 months ago by 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

comment:10 in reply to:  2 Changed 4 months ago by teor

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

comment:11 in reply to:  9 Changed 4 months ago by teor

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

comment:12 Changed 4 months ago by teor

Points: 52

comment:13 Changed 4 months ago by teor

Points: 5253
Note: See TracTickets for help on using tickets.