Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33407Make chutney bridge authorities publish bridges in their networkstatus-bridges2020-06-13T15:51:43ZteorMake chutney bridge authorities publish bridges in their networkstatus-bridgesThis issue depends on the tor bridge descriptor upload fix in #33582, or robust reachability self-tests in #33222.
Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to ch...This issue depends on the tor bridge descriptor upload fix in #33582, or robust reachability self-tests in #33222.
Chutney bridge authorities don't have any bridges in their networkstatus-bridges. That's a problem, because we want to check networkstatus-bridges for the reachability checks in #33232.
Once bridges upload their descriptors, we can make chutney check the bridge authority's networkstatus-bridges for bridge nicknames (this ticket).
We can only do the networkstatus-bridges check on tor versions with the #33222 or #33582 fixes. So we'll need to check for:
* the next tor 0.4.4-alpha version, or
* an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33375Stop advertising an IPv6 exit policy when DNS is broken for IPv62020-06-13T15:51:37ZteorStop advertising an IPv6 exit policy when DNS is broken for IPv6When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the desc...When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the descriptor, check `dns_seems_to_be_broken_for_ipv6()` before including an IPv6 exit policy
* reset `dns_seems_to_be_broken_for_ipv6()` periodically, maybe every 1-3 days?Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33333Add a mixed+hs-v23-ipv6 network to chutney2020-06-13T15:51:26ZteorAdd a mixed+hs-v23-ipv6 network to chutneyWe want to test our new IPv6 code in mixed networks, so let's add a `mixed+hs-v23-ipv6` network to chutney.
It should be pretty much a copy-paste from `mixed+hs-v23` and `hs-v23-ipv6-md`.
(There's no need for a non-md variant, all supp...We want to test our new IPv6 code in mixed networks, so let's add a `mixed+hs-v23-ipv6` network to chutney.
It should be pretty much a copy-paste from `mixed+hs-v23` and `hs-v23-ipv6-md`.
(There's no need for a non-md variant, all supported tor versions can use microdescriptors for IPv6 onion services.)
Proposed design:
* 2 dual-stack authorities,
* 2 IPv4-only relays,
* 2 dual-stack relays
* 2 IPv6-only v2 onion services
* 2 IPv6-only v3 onion services
* 2 IPv6-only clients
For each kind of node, one should be a new version, and one should be an old version.
Other networks test IPv4-only authorities and clients, so we don't need them. (But we want to test IPv4 and dual-stack relays in the same network.)Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33334Add a mixed+hs-v23-ipv6 network to tor's test-network2020-06-13T15:51:26ZteorAdd a mixed+hs-v23-ipv6 network to tor's test-networkWe want to add the new mixed+hs-v23-ipv6 chutney network from #33333 to tor's makefile tests:
* test-network-all
* test-network-ipv6
We'll need some minor refactoring, so that we can test for "ipv6" and "mixed", before using this networ...We want to add the new mixed+hs-v23-ipv6 chutney network from #33333 to tor's makefile tests:
* test-network-all
* test-network-ipv6
We'll need some minor refactoring, so that we can test for "ipv6" and "mixed", before using this network.
I think the resulting code will be simpler.
We can pass the following network lists to the test-network-run target:
* unconditional (ipv4 and not mixed)
* ipv6
* mixed
* mixed_ipv6
Then we can:
* test for ipv6 and mixed in separate tests,
* set flags for mixed and ipv6, and
* skip or use the right network lists.Tor: 0.4.4.x-finalteorteorhttps://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/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/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/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/33253Prop 312: 5.1. Ask Relay Operators to Test IPv6 Addresses Discovery2020-06-13T15:51:13ZteorProp 312: 5.1. Ask Relay Operators to Test IPv6 Addresses DiscoverySee #33252 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 312 IPv4 and IPv6 Address Discovery changes.
Once these changes are merged, volunteer relay and bridge ope...See #33252 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 312 IPv4 and IPv6 Address Discovery 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 312, section 5.1, relay operator test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1461https://gitlab.torproject.org/legacy/trac/-/issues/33252Prop 312: 5.1. Test Relay IPv6 Addresses Discovery on the Tor Network2020-06-13T15:51:13ZteorProp 312: 5.1. Test Relay IPv6 Addresses Discovery on the Tor NetworkTest the IPv4 and IPv6 ORPort Address Detection changes in proposal 312, on the public tor network, with a small number of relays and bridges.
Here are some useful features that we can test:
#33246 Prop 312: 3.2.7. Automatically Enable...Test the IPv4 and IPv6 ORPort Address Detection changes in proposal 312, on the public tor network, with a small number of relays and bridges.
Here are some useful features that we can test:
#33246 Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort
#33238 Prop 312: 3.2.3. Use Local Interface IPv6 Address
#33240 Prop 312: 3.2.4. Use Own Hostname IPv6 Addresses
#33247 Prop 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure
See proposal 312, section 5.1, initial public test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1461https://gitlab.torproject.org/legacy/trac/-/issues/33249Prop 312: 4. Update Directory Spec for IPv6 X-Your-Address-Is2020-06-13T15:51:12ZteorProp 312: 4. Update Directory Spec for IPv6 X-Your-Address-IsWe should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we sho...We should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we should look at what relays currently do (in tor 0.3.5 to 0.4.2, as of January 2020).
See proposal 312, section 4, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1432https://gitlab.torproject.org/legacy/trac/-/issues/33248Prop 312: 3.5.5. Detailed Address Resolution Logs2020-06-13T15:51:12ZteorProp 312: 3.5.5. Detailed Address Resolution LogsThis is an optional change, to help diagnose relay address resolution
issues.
Relays (and bridges) should log the address chosen using each address
resolution method, when:
* address resolution succeeds,
* address resolution fails,...This is an optional change, to help diagnose relay address resolution
issues.
Relays (and bridges) should log the address chosen using each address
resolution method, when:
* address resolution succeeds,
* address resolution fails,
* reachability checks fail, or
* publishing the descriptor fails.
These logs should be rate-limited separately for successes and failures.
The logs should tell operators to set the Address torrc option for IPv4 and
IPv6 (if available).
See proposal 312, section 3.5.5:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1083https://gitlab.torproject.org/legacy/trac/-/issues/33247Prop 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure2020-06-13T15:51:11ZteorProp 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability FailureDepends on disabling descriptor publication on reachability
failures in #33223.
Should be done after the first IPv6 address guessing feature: #33238
or #33240.
If both reachability checks succeed, relays should publish their IPv4 and I...Depends on disabling descriptor publication on reachability
failures in #33223.
Should be done after the first IPv6 address guessing feature: #33238
or #33240.
If both reachability checks succeed, relays should publish their IPv4 and IPv6 ORPorts in their descriptor.
If only the IPv4 ORPort check succeeds, and the IPv6 address was guessed
(rather than being explicitly configured), then relays should:
* publish their IPv4 ORPort in their descriptor,
* stop publishing their IPv6 ORPort in their descriptor, and
* log a notice about the failed IPv6 ORPort reachability check.
See proposal 312, section 3.2.7, Guessed IPv6 Reachability Failure part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n567https://gitlab.torproject.org/legacy/trac/-/issues/33246Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort2020-06-13T15:51:10ZteorProp 312: 3.2.7. Automatically Enable an IPv6 ORPortAfter we implement #33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only options
to confi...After we implement #33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only options
to configure different ports for IPv4 and IPv6.
If the ORPort is auto-detected, there will not be any specific bind
address. (And the detected address may actually be on a NAT box, rather
than the local machine.) Therefore, relays should attempt to bind to all
IPv4 and IPv6 addresses (or all interfaces).
Some operating systems expect applications to bind to IPv4 and IPv6
addresses using separate API calls. Others don't support binding only to
IPv4 or IPv6, and will bind to all addresses whenever there is no specified
IP address (in a single API call). Tor should support both styles of
networking API.
In particular, if binding to all IPv6 addresses fails, relays should still
try to discover their public IPv6 address, and check the reachability of
that address. Some OSes may not support the IPV6_V6ONLY flag, but they may
instead bind to all addresses at runtime. (The tor install may also have
compile-time / runtime flag mismatches.)
See proposal 312, section 3.2.7, IPv6 ORPort part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n540
Once this ticket is implemented, we should test the different IPv4/IPv6 configs listed in #33235.https://gitlab.torproject.org/legacy/trac/-/issues/33245Prop 312: 3.2.6. Add an AddressDisableIPv6 torrc option2020-06-13T15:51:10ZteorProp 312: 3.2.6. Add an AddressDisableIPv6 torrc optionShould be done after the first IPv6 address guessing feature: #33238
or #33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6 address
resolution.
...Should be done after the first IPv6 address guessing feature: #33238
or #33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6 address
resolution.
Currently, relays are required to have an IPv4 address. So if the guessed
IPv4 address is unsuitable, operators can set the Address option to a
suitable IPv4 address. But IPv6 addresses are optional, so relay operators
may need to disable IPv6 entirely.
We propose a new torrc-only option, AddressDisableIPv6. This option is set
to 0 by default. If the option is set to 1, tor disables IPv6 address
resolution, IPv6 ORPorts, IPv6 reachability checks, and publishing an IPv6
ORPort in its descriptor.
See proposal 312, section 3.2.6:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n498https://gitlab.torproject.org/legacy/trac/-/issues/33244Prop 312: 3.2.5. Use IPv6 Addresses from Directory Servers2020-06-13T15:51:09ZteorProp 312: 3.2.5. Use IPv6 Addresses from Directory ServersIf relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that relays start fetching dir...If relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that relays start fetching directory documents over IPv4 and IPv6.
We propose that bridges continue to only fetch directory documents over IPv4, because they try to imitate clients. Therefore, they can't use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Tor already ignores private IPv4 addresses in directory headers. We propose
to also ignore private IPv6 addresses in directory headers. If all IPv4 and
IPv6 addresses in directory headers are private, address resolution should
return a temporary error.
Whenever address resolution fails, tor should warn the operator to set the
Address torrc option for IPv4 and IPv6. (If IPv4 is available, and only
IPv6 is missing, the log should be at notice level.) These logs may need to
be rate-limited.
Whenever tor receives a directory header containing a new public IPv4 or
IPv6 address, tor should try to use that address for reachability checks. If the
reachability checks succeed, tor should use that address in its descriptor.
See proposal 312, section 3.2.5, IPv6 address usage part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n457https://gitlab.torproject.org/legacy/trac/-/issues/33243Prop 312: 3.2.5. Handle IPv6 Directory Fetch Failures2020-06-13T15:51:08ZteorProp 312: 3.2.5. Handle IPv6 Directory Fetch FailuresRelays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients...Relays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients. (So they can't find their IPv6 addresses in this way.)
To support this change, tor should also change how it handles IPv6
directory failures on relays:
* avoid recording IPv6 directory failures as remote relay failures,
because they may actually be due to a lack of IPv6 connectivity on the
local relay, and
* issue IPv6 directory failure logs at notice level, and rate-limit them
to one per hour.
If a relay is:
* explicitly configured with an IPv6 address, or
* a publicly routable, reachable IPv6 address is discovered in an
earlier step,
tor should start issuing IPv6 directory failure logs at warning level. Tor
may also record these directory failures as remote relay failures. (Rather
than ignoring them, as described in the previous paragraph.)
See proposal 312, section 3.2.5, IPv6 directory failure part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n457