Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-08-14T12:37:01Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33048O1.1 - Propose and implement IPv6 ORPort reachability checks on relays2020-08-14T12:37:01ZGabagaba@torproject.orgO1.1 - Propose and implement IPv6 ORPort reachability checks on relaysSee Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt
The child tickets are in proposal section order, but they will probably be implemented in this order...See Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Pre-Implementation Improvements:
* Require IPv6 tests in Travis CI (O1.3, legacy/trac#33195)
* Test IPv4 Reachability using Chutney (O1.3, legacy/trac#33232)
Implementation:
* Allow Relay IPv6 Extends
* Declare Support for Subprotocol Version "Relay=3"
* Check Relay and Bridge IPv6 ORPort Reachability
Internal Testing:
* Test IPv6 ORPort Reachability using Chutney (O1.3, legacy/trac#33228)
* Test Legacy Relays Accept IPv6 Extends using Chutney (O1.3, legacy/trac#33231)
Public Tor Network Testing:
* Test IPv6 ORPort Reachability on the Tor Network
* Ask Relay Operators to Test IPv6 Reachability
Parent:
* #33045 Increase the number of relays that support IPv6
Children:
* [x] #33285 Make sure relay protocol lists are sorted
* [x] #34445 Split assumereachable into self and authority components
* [x] #34446 TestingTorNetwork should not set AssumeReachable 1
* [ ] #33043 Prop 306: Keep bridge IPv6 behaviour in sync with client behaviour
* [x] #33817 Perform Basic Relay IPv6 Extends
* [x] #33956 Define and use TOR_ADDRPORT_BUF_LEN
* [x] #33220 Prop 311: 3. Allow Relay IPv6 Extends
* [x] #33221 Prop 311: 4. Ensure Relay and Bridge IPv6 ORPorts are Reachable
* [x] #33226 Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"
* [x] #32588 Setting ORPort [ipv6]:auto mistakenly advertises port 94
* [x] chutney#33229 Test IPv6 ORPort Reachability on the Tor Network
* [x] chutney#33230 Ask Relay Operators to Test IPv6 Reachability
* [x] #24403 Propose and implement IPv6 ORPort reachability checks on relays
* [x] #33880 Confusing "Your relay has a very large number of connections to other relays" relay message
* [x] #34137 Make sure inform_testing_reachability() reports the correct ports
* [x] #33633 Move extend and reachability code to the relay module
* [x] #33898 Stop modifying addr on connections, and delete real_addr
* [x] #33899 Allow IPv6 addresses to be canonical
* [x] #33900 Check for invalid zero IPv4 addresses and ports in extend cells
* [x] #33901 Allow IPv6 extend cells
* [x] #33905 Adjust "large number of connections to other relays" warnings
* [x] #33917 Make IF_BUG_ONCE() support ALL_BUGS_ARE_FATAL
* [x] #33919 Write unit tests for channel_matches_target_addr_for_extend()Sponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33049O1.2 - Make relays figure out their own IPv6 address2020-07-24T17:19:17ZGabagaba@torproject.orgO1.2 - Make relays figure out their own IPv6 addressSee Proposal 312: Tor Relay Automatic IPv6 Address Discovery:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt
The child tickets are in proposal section order, but they will probably be implemented i...See Proposal 312: Tor Relay Automatic IPv6 Address Discovery:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Dependencies:
* Propose and implement IPv6 ORPort reachability checks on relays (O1.1, legacy/trac#33048)
Pre-Implementation:
* Test IPv4 Address Detection using Chutney (O1.3, legacy/trac#33250)
* Detailed Address Resolution Logs
Explicit IPv6 Configurations:
* Make the Address torrc Option Support IPv6 Literals
* Use Advertised ORPort IPv4 and IPv6 Addresses in Descriptors
* Use Local Interface IPv6 Address
Directory Authority Security:
* Stop Directory Authorities Resolving *Port Hostnames
* Limit Directory Authority Addresses to Address and ORPort
Remote IPv6 Information:
* Make the Address torrc Option Resolve IPv6 Hostnames
* Use Own Hostname IPv6 Addresses
* Use Directory Header IPv6 Addresses
* Update Directory Spec for IPv6 X-Your-Address-Is
Auto IPv6 ORPort:
* Automatically Enable an IPv6 ORPort
* Add an AddressDisableIPv6 torrc option
* Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure
Internal Testing:
* Test Relay IPv6 Addresses Discovery using Chutney (O1.3, legacy/trac#33251)
Public Tor Network Testing:
* Test Relay IPv6 Addresses Discovery on the Tor Network
* Ask Relay Operators to Test IPv6 Addresses Discovery
Children:
* [x] #33679 Make sure every address function that takes for_listening supports IPv6
* [x] #33073 Write a proposal for Tor Relays to Automatically Find their IPv6 Address
* [x] #5940 Figure out own IPv6 address
* [x] #33091 Remove redundant checks in ip_address_changed()
* [x] #32720 How much bandwidth does a user use to bootstrap and maintain dir info? How has that changed over time?
* [x] #33233 Prop 312: 3.2.1. Make the Address torrc Option Support IPv6 Literals
* [x] #33234 Prop 312: 3.2.1. Make the Address torrc Option Resolve IPv6 Hostnames
* [x] #33235 Prop 312: 3.2.1. Test Address torrc Option Configurations
* [x] #33236 Prop 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors
* [x] #33237 Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames
* [x] #33238 Prop 312: 3.2.3. Use Local Interface IPv6 Address
* [x] #33239 Prop 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPort
* [x] #33240 Prop 312: 3.2.4. Use Own Hostname IPv6 Addresses
* [x] #33241 Prop 312: 3.2.5. Use Directory Header IPv6 Addresses
* [x] #33244 Prop 312: 3.2.5. Use IPv6 Addresses from Directory Servers
* [x] #33245 Prop 312: 3.2.6. Add an AddressDisableIPv6 torrc option
* [x] #33246 Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort
* [x] #33247 Prop 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure
* [x] #33248 Prop 312: 3.5.5. Detailed Address Resolution Logs
* [x] #33252 Prop 312: 5.1. Test Relay IPv6 Addresses Discovery on the Tor Network
* [x] #33253 Prop 312: 5.1. Ask Relay Operators to Test IPv6 Addresses Discovery
* [x] #40022 Prop 312: Relay learn address from NETINFO cell
* [x] #40025 Prop 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptor
* [x] #33768 Make tor_inet_pton() handle bad addresses consistently on Windows
* [x] #33789 Before making changes, move router pick address functions to their own C file Sponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33051O1.4 - Measure the number of Tor relays that support IPv6 reachability checks2020-08-14T12:34:03ZGabagaba@torproject.orgO1.4 - Measure the number of Tor relays that support IPv6 reachability checksSee Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
Tor's IPv6 reachability checks are described in:
Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torpro...See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
Tor's IPv6 reachability checks are described in:
Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Dependencies:
* Prop 311: 5. Declare Support for Subprotocol Version "Relay=3" (O1.1, legacy/trac#33226)
Implementation:
* Write a Script that Counts IPv6 Relays in the Consensus
Metrics Review:
* Check IPv6 Relay Consensus Counts Script
Internal Testing:
* Test IPv6 Relay Consensus Counts using Chutney (O1.3, legacy/trac#33267)
Public Tor Network Testing:
* Test IPv6 Relay Consensus Counts on the Tor Network
Monitoring:
* Monitor IPv6 Relay Counts in the Consensus
Children:
* [x] tor#33262 Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus
* [x] trac#33266 [Prop 313: 7.2. Show IPv6 Relay Counts on Consensus Health ](https://gitlab.torproject.org/tpo/metrics/consensus-health/-/issues/33266)
* [x] tor#33268 Prop 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor Network
* [x] trac#33269 [Prop 313: 8.1. Check IPv6 Relay Consensus Counts Script](https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33269)
* [x] tor#33270 Prop 313: 8.1. Monitor IPv6 Relay Counts in the ConsensusSponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33052O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 ...2020-08-14T12:38:04ZGabagaba@torproject.orgO1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Pre-Implem...See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Pre-Implementation Bugs:
* Fix: Tor relays ignore some local bytes in their statistics
* Diagnose: ConnDirectionStatistics is off by default, but most relays report it
Dependencies:
* (None)
Implementation:
* Collect IPv6 Bandwidth Stats on Relays and Bridges
* Collect IPv6 Connection Stats on Relays
* Update Directory Spec for IPv6 Stats
Internal Testing:
* Test IPv6 Statistics using Chutney (O1.3, legacy/trac#33271)
Public Tor Network Testing:
* Test IPv6 Stats on the Tor Network
Metrics Analysis:
* Analyse and Monitor IPv6 Stats
Children:
* [x] tor#33159 Write a proposal for monitoring IPv6
* [x] tor#33263 Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges
* [x] tor#33264 Prop 313: 5. Collect IPv6 Connection Stats on Relays
* [x] tor#33201 Tor relays ignore some local bytes in their statistics
* [x] tor#33265 Prop 313: 6. Update Directory Spec for IPv6 Stats
* [ ] tor#33617 Add a BandwidthStatistics option and consensus parameter
* [x] tor#33272 Prop 313: 8.2. Test IPv6 Stats on the Tor Network
* [ ] #33273 [Prop 313: 8.2. Analyse and Monitor IPv6 Stats ](https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33273)
* [x] tor#33214 ConnDirectionStatistics is off by default, but most relays report itSponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33234Prop 312: 3.2.1. Make the Address torrc Option Resolve IPv6 Hostnames2020-06-27T13:48:18ZteorProp 312: 3.2.1. Make the Address torrc Option Resolve IPv6 HostnamesThis ticket depends on `Address IPv6` support in legacy/trac#33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
2. Hostnames / DNS names:
*...This ticket depends on `Address IPv6` support in legacy/trac#33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
2. Hostnames / DNS names:
* allow the option to be specified up to two times,
* look up the configured name,
* use the first IPv4 and IPv6 address returned by the resolver, and
Resolving multiple addresses in the same address family is not a
runtime error, but only the first address from each family will be
used.
These lookups should ignore private addresses on public tor networks. If
multiple IPv4 or IPv6 addresses are returned, the first public address from each family should be used.
Tor should warn if a configured Address hostname does not resolve
to any publicly routable IPv4 or IPv6 addresses. (If
tor is configured with a custom set of directory authorities, private
addresses should be allowed, with a notice-level log.)
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 their Address option. They must not attempt to resolve their Address using DNS. It is a config error to provide a hostname as a directory authority's Address.
See proposal 312, section 3.2.1, case 2:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n258Sponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33262Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus2020-07-02T19:46:43ZteorProp 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 legacy/trac#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#n82Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33263Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges2020-07-21T15:33:59ZteorProp 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#n118
Tasks:
* [x] Split bandwidth history into a separate file.
* [x] Get adequate test coverage on bandwidth history code.
* [x] Add a pair of IPv6 bandwidth arrays.
* [x] Make data get inserted into the IPv6 bandwidth arrays as appropriate.
* [x] Include IPv6 bandwidth data in extrainfo descriptors.Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33264Prop 313: 5. Collect IPv6 Connection Stats on Relays2020-07-10T17:14:38ZteorProp 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#n144Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33265Prop 313: 6. Update Directory Spec for IPv6 Stats2020-07-13T19:25:02ZteorProp 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#n168Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33270Prop 313: 8.1. Monitor IPv6 Relay Counts in the Consensus2020-07-30T13:44:24ZteorProp 313: 8.1. Monitor IPv6 Relay Counts in the ConsensusMonitor the output of the script in legacy/trac#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 ...Monitor the output of the script in legacy/trac#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#n337Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33268Prop 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor Network2020-07-02T19:47:19ZteorProp 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor NetworkThis task depends on legacy/trac#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 propo...This task depends on legacy/trac#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#n337Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33272Prop 313: 8.2. Test IPv6 Stats on the Tor Network2020-08-07T13:17:17ZteorProp 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#n355Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33045Sponsor 55 - Increase the number of Tor network relays that support IPv62020-09-10T16:51:17ZGabagaba@torproject.orgSponsor 55 - Increase the number of Tor network relays that support IPv6Project Title: Improving the Tor network’s IPv6 support
Project Period: February 1st, 2020 - August 15th, 2020
The goal of this project is to improve the Tor network’s IPv6 support. Doing so will improve the network’s censorship resist...Project Title: Improving the Tor network’s IPv6 support
Project Period: February 1st, 2020 - August 15th, 2020
The goal of this project is to improve the Tor network’s IPv6 support. Doing so will improve the network’s censorship resistance, its privacy properties, its usefulness for the technical community, its alignment with global migration towards IPv6, with benefits for more than a million Tor users in the RIPE community.
Users in the RIPE region make up more than half of all Tor users--during 2018, more than 51% of Tor’s daily users connected from a RIPE country. Conservatively, that’s more than one million average daily users. During 2018, of the top 10 countries with the largest average daily Tor user bases, seven of those countries are in the RIPE service region. Germany was the largest average daily user group last year—with 17.5% of all Tor users connecting from Germany. United Arab Emirates was third, making up 10.49% of Tor users. Russia was fourth (10.42% of Tor users), France was fifth (4.12% of Tor users), Ukraine was sixth (3.96% of Tor users), the United Kingdom was eighth (2.62% of Tor users), and the Netherlands was ninth, (2.22% of Tor users).
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.
Children:
* [x] #33048 O1.1 - Propose and implement IPv6 ORPort reachability checks on relays
* [x] #33049 O1.2 - Make relays figure out their own IPv6 address
* [x] chutney#33050 O1.3 - Integration test Tor relays over IPv6 using chutney
* [x] #33051 O1.4 - Measure the number of Tor relays that support IPv6 reachability checks
* [x] #33052 O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6
Archive: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor55Sponsor 55: Improving the Tor network’s IPv6 supportGabagaba@torproject.orgGabagaba@torproject.org2020-08-15