Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:19Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33280Add a "make test-network-ipv6" target, which runs IPv6 chutney networks2020-06-13T15:51:19ZteorAdd a "make test-network-ipv6" target, which runs IPv6 chutney networksPart of #33195.Part of #33195.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33275Tor Manual: Alphabetize Remaining Tor Manual2020-06-13T15:51:18ZTracTor Manual: Alphabetize Remaining Tor ManualAlphabetically sort the options in the following sections:
- DENIAL OF SERVICE MITIGATION OPTIONS
- DIRECTORY AUTHORITY SERVER OPTIONS
- HIDDEN SERVICE OPTIONS
- TESTING NETWORK OPTIONS
**Trac**:
**Username**: swatiAlphabetically sort the options in the following sections:
- DENIAL OF SERVICE MITIGATION OPTIONS
- DIRECTORY AUTHORITY SERVER OPTIONS
- HIDDEN SERVICE OPTIONS
- TESTING NETWORK OPTIONS
**Trac**:
**Username**: swatiTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33272Prop 313: 8.2. Test IPv6 Stats on the Tor Network2020-06-13T15:51:18ZteorProp 313: 8.2. Test IPv6 Stats on the Tor NetworkWe want to test the IPv6 connection and bandwidth statistics on the public network, with a small number of relays and bridges.
See proposal 313, section 8.2, public tor network tests part:
https://gitweb.torproject.org/torspec.git/tree/...We want to test the IPv6 connection and bandwidth statistics on the public network, with a small number of relays and bridges.
See proposal 313, section 8.2, public tor network tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n355Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33271Prop 313: 8.2. Test IPv6 Statistics using Chutney2020-06-13T15:50:22ZteorProp 313: 8.2. Test IPv6 Statistics using ChutneyWe want to test IPv6 connection and consumed bandwidth statistics using
chutney networks. However, chutney runs for a short amount of time, and
creates a limited amount of traffic, so we also need to test these changes
on the public tor ...We want to test IPv6 connection and consumed bandwidth statistics using
chutney networks. However, chutney runs for a short amount of time, and
creates a limited amount of traffic, so we also need to test these changes
on the public tor network.
In particular, we have struggled to test statistics using chutney, because
tor's hard-coded statistics period is 24 hours. (And most chutney networks
run for under 1 minute.)
Maybe we can change the statistics interval to 10-30 seconds, and see if that works?
See proposal 313, section 8.2, chutney tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n355Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33270Prop 313: 8.1. Monitor IPv6 Relay Counts in the Consensus2020-06-13T15:51:17ZteorProp 313: 8.1. Monitor IPv6 Relay Counts in the ConsensusMonitor the output of the script in #33262.
Continue monitoring as more volunteer relay operators deploy the relevant tor versions. (And as the number of IPv6 relays in the consensus increases.)
There isn't actually much to check here....Monitor the output of the script in #33262.
Continue monitoring as more volunteer relay operators deploy the relevant tor versions. (And as the number of IPv6 relays in the consensus increases.)
There isn't actually much to check here. If we do find issues, we should open separate bugs for them.
See proposal 313, section 8.1, ongoing monitoring part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n337Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33268Prop 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor Network2020-06-13T15:51:17ZteorProp 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor NetworkThis task depends on #33262.
Test the IPv6 relay count script in proposal 313, using the public tor network.
There isn't really much to test here. There are only 4 calculations. We've done counts like this before.
See proposal 313, se...This task depends on #33262.
Test the IPv6 relay count script in proposal 313, using the public tor network.
There isn't really much to test here. There are only 4 calculations. We've done counts like this before.
See proposal 313, section 8.1, public tor network tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n337Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33267Prop 313: 8.1. Test IPv6 Relay Consensus Counts using Chutney2020-06-13T15:50:20ZteorProp 313: 8.1. Test IPv6 Relay Consensus Counts using ChutneyTest the IPv6 relay count script in proposal 313, using chutney networks.
Since chutney creates a limited number of relays, we also need to test these changes on consensuses from the public tor network. So we shouldn't spend much time t...Test the IPv6 relay count script in proposal 313, using chutney networks.
Since chutney creates a limited number of relays, we also need to test these changes on consensuses from the public tor network. So we shouldn't spend much time testing the script with chutney.
See proposal 313, section 8.1, chutney tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n337Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33265Prop 313: 6. Update Directory Spec for IPv6 Stats2020-06-13T15:51:16ZteorProp 313: 6. Update Directory Spec for IPv6 StatsWe want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168We want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33264Prop 313: 5. Collect IPv6 Connection Stats on Relays2020-06-13T15:51:15ZteorProp 313: 5. Collect IPv6 Connection Stats on RelaysWe propose that relays (but not bridges) collect IPv6 connection statistics.
Bridges refuse to collect the existing ConnDirectionStatistics, so we do not
believe it is safe to collect the smaller IPv6 totals on bridges.
To minimise dev...We propose that relays (but not bridges) collect IPv6 connection statistics.
Bridges refuse to collect the existing ConnDirectionStatistics, so we do not
believe it is safe to collect the smaller IPv6 totals on bridges.
To minimise development and testing effort, we propose re-using the existing
"bidi" code in rephist.c. (This code may require some refactoring, because
the "bidi" totals are globals, rather than a struct.)
(We might also want to move this code into separate relay-only code and
header files, because it is relay-specific.)
In particular, tor currently counts these connection statistics:
* below threshold,
* mostly read,
* mostly written, and
* both read and written.
We propose adding IPv6 variants of all these statistics. (The IPv4
statistics can be calculated by subtracting the IPv6 statistics from the
existing total connection statistics.)
See proposal 313, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n144Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33263Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges2020-06-13T15:51:15ZteorProp 313: 4. Collect IPv6 Bandwidth Stats on Relays and BridgesWe propose that relays (and bridges) collect IPv6 consumed bandwidth
statistics.
To minimise development and testing effort, we propose re-using the existing
"bw_array" code in rephist.c.
(We might want to move this code into separate ...We propose that relays (and bridges) collect IPv6 consumed bandwidth
statistics.
To minimise development and testing effort, we propose re-using the existing
"bw_array" code in rephist.c.
(We might want to move this code into separate relay-only code and header files, because it is relay-specific.)
In particular, tor currently counts these bandwidth statistics:
* read,
* write,
* dir_read, and
* dir_write.
We propose adding the following bandwidth statistics:
* ipv6_read, and
* ipv6_write.
(The IPv4 statistics can be calculated by subtracting the IPv6 statistics
from the existing total consumed bandwidth statistics.)
We believe that collecting IPv6 consumed bandwidth statistics is about as
safe as the existing IPv4+IPv6 total consumed bandwidth statistics.
See proposal 313, section 4:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n118Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33262Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus2020-07-02T19:47:20ZteorProp 313: 3. Write a Script that Counts IPv6 Relays in the ConsensusWe want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two ...We want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two statistics have no dependencies. The last two statistics depend on the "Relay=3" subprotocol in #33226.
The script should calculate:
* the number of relays, and
* the consensus weight fraction of relays.
In order to provide easy access to these statistics, we propose
that the script should:
* download a consensus (or read an existing consensus), and
* calculate and report these statistics.
We could write this script using Python 3 and Stem:
https://stem.torproject.org
The following consensus weight fractions should divide by the total
consensus weight:
* have an IPv6 ORPort (all relays have an IPv4 ORPort), and
* support IPv6 reachability checks (all relays support IPv4 reachability).
The following consensus weight fractions should divide by the
"usable Guard" consensus weight:
* support IPv6 clients, and
* support IPv6 reachability checks and IPv6 clients.
"Usable Guards" have the Guard flag, but do not have the Exit flag. If the
Guard also has the BadExit flag, the Exit flag should be ignored.
The script should check that Wgd is 0. If it is not, the script
should log a warning about the accuracy of the "Usable Guard" statistics.
See proposal 313, section 3:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n82Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33251Prop 312: 5.1. Test Relay IPv6 Addresses Discovery using Chutney2020-06-13T15:50:19ZteorProp 312: 5.1. Test Relay IPv6 Addresses Discovery using ChutneyTest the IPv6 ORPort Address Detection changes in proposal 312, using chutney networks.
Since chutney runs on private addresses, these tests might be difficult to write, or they might not tell us much about how tor relays behave on the ...Test the IPv6 ORPort Address Detection changes in proposal 312, using chutney networks.
Since chutney runs on private addresses, these tests might be difficult to write, or they might not tell us much about how tor relays behave on the public tor network. So we shouldn't spend much time on them.
See proposal 312, section 5.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1461Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33250Test IPv4 Address Detection using Chutney2020-06-13T15:50:19ZteorTest IPv4 Address Detection using ChutneyBefore we start making changes to tor's IPv6 code in #33049, we need to get IPv4 address detection tests working in chutney.
Since chutney runs on private addresses, these tests might be difficult to write, or they might not tell us muc...Before we start making changes to tor's IPv6 code in #33049, we need to get IPv4 address detection tests working in chutney.
Since chutney runs on private addresses, these tests might be difficult to write, or they might not tell us much about how tor relays behave on the public tor network. So we shouldn't spend much time on them.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33237Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames2020-06-13T15:51:04ZteorProp 312: 3.2.2. Stop Directory Authorities Resolving *Port HostnamesFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort an...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort and DirPort options.
As part of this fix, we may also ban DNS resolution on all configured Ports. (We should try to avoid banning DNS resolution entirely on authorities, because some test networks use Authority/Exits.)
See proposal 312, section 3.2.2, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n340
Directory authorities must not attempt to resolve these
addresses using DNS. It is a config error to provide a hostname as a
directory authority's ORPort or DirPort.
If directory authorities don't have an IPv4 address literal in their
Address or ORPort, they should issue a configuration error, and refuse to
launch. If directory authorities don't have an IPv6 address literal in their
Address or ORPort, they should issue a notice-level log, and fall back to
only using IPv4.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33232Test IPv4 Reachability using Chutney2020-06-13T15:51:43ZteorTest IPv4 Reachability using ChutneyBefore we start making changes to tor's IPv6 code in #33048, we need to get IPv4 reachability tests working in chutney.Before we start making changes to tor's IPv6 code in #33048, we need to get IPv4 reachability tests working in chutney.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33231Prop 311: 6.3. Test Legacy Relays Accept IPv6 Extends using Chutney2020-06-13T15:50:17ZteorProp 311: 6.3. Test Legacy Relays Accept IPv6 Extends using ChutneyThis ticket depends on relay IPv6 extends in #33220. We may also need to disable the "Relay=3" protocol version check.
Test IPv6 extends from newer relays (which implement proposal 311) to older relays (which do not).
Although proposal...This ticket depends on relay IPv6 extends in #33220. We may also need to disable the "Relay=3" protocol version check.
Test IPv6 extends from newer relays (which implement proposal 311) to older relays (which do not).
Although proposal 311 does not create these kinds of circuits, we need to check for bugs and excessive logs in older tor versions.
See proposal 311, section 6.3:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n698Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33230Prop 311: 6.1. Ask Relay Operators to Test IPv6 Reachability2020-06-13T15:50:58ZteorProp 311: 6.1. Ask Relay Operators to Test IPv6 ReachabilitySee #33229 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 311 IPv6 ORPort Reachability and Extends changes.
Once these changes are merged, volunteer relay and bridg...See #33229 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 311 IPv6 ORPort Reachability and Extends changes.
Once these changes are merged, volunteer relay and bridge operators will be able to test them by:
* compiling from source,
* running nightly builds, or
* running alpha releases.
See proposal 311, section 6.1, relay operator test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n671Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33229Prop 311: 6.1. Test IPv6 ORPort Reachability on the Tor Network2020-06-13T15:50:58ZteorProp 311: 6.1. Test IPv6 ORPort Reachability on the Tor NetworkTest the IPv6 ORPort Reachability and Extends changes in proposal 311, on the public tor network, with a small number of relays and bridges.
We can do public tests after each major feature is merged. We can
also wait for multiple featur...Test the IPv6 ORPort Reachability and Extends changes in proposal 311, on the public tor network, with a small number of relays and bridges.
We can do public tests after each major feature is merged. We can
also wait for multiple features to merge, and test them all.
Here are some useful features that we can test:
#33222 / #33226 IPv6 ORPort Reachability Self-Tests / Relay=3 Protocol
#33223 Don't Publish Descriptor if IPv6 ORPort is Unreachable
See proposal 311, section 6.1, initial public test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n671Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33228Prop 311: 6.1. Test IPv6 ORPort Reachability using Chutney2020-06-13T15:50:17ZteorProp 311: 6.1. Test IPv6 ORPort Reachability using ChutneyTest the IPv6 ORPort Reachability and Extends changes in proposal 311, using chutney networks with AssumeReachable disabled.
(Chutney currently enables AssumeReachable by default.)
See proposal 311, section 6.1:
https://gitweb.torproje...Test the IPv6 ORPort Reachability and Extends changes in proposal 311, using chutney networks with AssumeReachable disabled.
(Chutney currently enables AssumeReachable by default.)
See proposal 311, section 6.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n671
Chutney already implements some of these tests, but we still need a fix for a bridge descriptor upload bug, see tor #33582 and chutney #33407.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33227Prop 311: 5.1. Update Tor Spec Relay Subprotocols2020-06-13T15:51:00ZteorProp 311: 5.1. Update Tor Spec Relay SubprotocolsWe propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually ...We propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually recommend
or require support for IPv6 extends on all relays.
For the draft text, see proposal 311, section 5.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n608Tor: 0.4.4.x-finalteorteor