Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:04Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33236Prop 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors2020-06-13T15:51:04ZteorProp 312: 3.2.2. Use Advertised ORPort IPv4 Address in DescriptorsIf the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we ju...If the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we just need to preserve that behaviour.
The ORPort address may be a hostname. If it is, tor should try to use it to
resolve an IPv4 and IPv6 address, and open ORPorts on the first available
IPv4 and IPv6 address. Tor should respect the IPv4Only and IPv6Only port
flags, if specified. (Tor currently resolves IPv4 and IPv6 addresses from
hostnames in ORPort lines.)
Relays (and bridges) currently use the first advertised ORPort IPv6 address
as their IPv6 address. We propose to use the first advertised IPv4 ORPort
address in a similar way, for consistency.
Tor currently uses its listener port list to look up its IPv6 ORPort for
its descriptor. We propose that tor's address discovery uses the listener
port list for both IPv4 and IPv6. (And does not attempt to independently
parse or resolve ORPort configs.)
This design decouples ORPort option parsing, ORPort listener opening, and
address discovery. It also implements a form of caching: IPv4 and IPv6
addresses resolved from hostnames are stored in the listener port list,
then used to open listeners. Therefore, tor should continue to use the same
address, while the listener remains open. (See also sections 3.2.7 and
3.2.8.)
For the purposes of address resolution, tor should ignore private
configured ORPort addresses on public tor networks. (Binding to private
ORPort addresses is supported, even on public tor networks, for relays that use NAT to reach the Internet.)
See proposal 312, section 3.2.2, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n306https://gitlab.torproject.org/legacy/trac/-/issues/33235Prop 312: 3.2.1. Test Address torrc Option Configurations2020-06-13T15:51:03ZteorProp 312: 3.2.1. Test Address torrc Option ConfigurationsThis ticket depends on IPv6 Addresses in #33233, and automatic IPv6 ORPorts in #33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of address literals and hostn...This ticket depends on IPv6 Addresses in #33233, and automatic IPv6 ORPorts in #33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of address literals and hostnames:
Legacy configurations:
A. No configured Address option
B. Address IPv4 literal
C. Address hostname (use IPv4 and IPv6 DNS addresses)
New configurations:
D. Address IPv6 literal
E. Address IPv4 literal / Address IPv6 literal
F. Address hostname / Address hostname (use IPv4 and IPv6 DNS addresses)
G. Address IPv4 literal / Address hostname (only use IPv6 DNS addresses)
H. Address hostname (only use IPv4 DNS addresses) / Address IPv6 literal
If we can't find an IPv4 or IPv6 address using the configured Address options:
* No IPv4: guess IPv4, and its reachability must succeed.
* No IPv6: guess IPv6, publish if reachability succeeds.
Combinations A and B are the most common legacy configurations. We want to support the following outcomes for all legacy configurations:
* automatic upgrades to guessed and reachable IPv6 addresses,
* continuing to operate on IPv4 when the IPv6 address can't be guessed, and
* continuing to operate on IPv4 when the IPv6 address has been guessed, but it is unreachable.
See proposal 312, section 3.2.1, testing notes:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n270https://gitlab.torproject.org/legacy/trac/-/issues/33234Prop 312: 3.2.1. Make the Address torrc Option Resolve IPv6 Hostnames2020-06-13T15:51:02ZteorProp 312: 3.2.1. Make the Address torrc Option Resolve IPv6 HostnamesThis ticket depends on `Address IPv6` support in #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 ...This ticket depends on `Address IPv6` support in #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#n258https://gitlab.torproject.org/legacy/trac/-/issues/33233Prop 312: 3.2.1. Make the Address torrc Option Support IPv6 Literals2020-06-13T15:51:01ZteorProp 312: 3.2.1. Make the Address torrc Option Support IPv6 LiteralsWe can work on this ticket now, but we should do the code movement in
#33789 first.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 literal case:
1. Explicit IP addresse...We can work on this ticket now, but we should do the code movement in
#33789 first.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 literal case:
1. Explicit IP addresses:
* allow the option to be specified up to two times,
* use the IPv4 address for IPv4,
* use the IPv6 address for IPv6.
Configuring two addresses in the same address family is a config error.
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.
It is an error to configure an Address option with a private IPv4 or IPv6
address. (If tor is configured with a custom set of directory authorities, private addresses should be allowed, with a notice-level log.)
See proposal 312, section 3.2.1, case 1:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n252
As soon as we implement this ticket, we should implement #33246 to automatically open an IPv6 ORPort based on the Address config. (Or any discovered addresses.)
Then we should test the different IPv4/IPv6 configs listed in #33235.https://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-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33226Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"2020-07-02T19:46:44ZteorProp 311: 5. Declare Support for Subprotocol Version "Relay=3"This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See p...This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See proposal 311, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n601Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33225Prop 311: 4.4.1. Extend IPv6 From All Supported Second-Last Hops2020-06-13T15:50:59ZteorProp 311: 4.4.1. Extend IPv6 From All Supported Second-Last HopsThis is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing #33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachability checks.)
...This is an optional change.
This change has a zero points estimate, because I think it is the fastest way of implementing #33222. (The alternative design requires creating different circuit types for IPv4 and IPv6 reachability checks.)
4.4.1. Extend IPv6 From All Supported Second-Last Hops
The testing relay (or bridge) puts both IPv4 and IPv6 ORPorts in its final
extend cell, and the receiving ORPort is selected at random by the
extending relay (see sections 3.2.1 and 4.2). Therefore, approximately half
of IPv6 ORPort reachability circuits will actually end up confirming IPv4
ORPort reachability.
We propose this optional change, to improve the rate of IPv6 ORPort
reachability checks:
If the second-last hop of an IPv4 ORPort reachability circuit supports IPv6
extends, testing relays may put the IPv4 and IPv6 ORPorts in the extend
cell for the final extend.
As the number of relays that support IPv6 extends increases, this change
will increase the number of IPv6 reachability confirmations. In the ideal
case, where the entire network supports IPv4 and IPv6 extends, IPv4 and IPv6
ORPort reachability checks would require a similar number of circuits.
See proposal 311, section 4.4.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n439Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33224Prop 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus Parameter2020-06-13T15:53:17ZteorProp 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus ParameterWe add an AssumeReachableIPv6 torrc option and consensus parameter.
If IPv6 ORPort checks have bugs that impact the health of the network,
they can be disabled by setting AssumeReachableIPv6=1 in the consensus
parameters.
If IPv6 ORPor...We add an AssumeReachableIPv6 torrc option and consensus parameter.
If IPv6 ORPort checks have bugs that impact the health of the network,
they can be disabled by setting AssumeReachableIPv6=1 in the consensus
parameters.
If IPv6 ORPort checks have bugs that impact a particular relay (or bridge),
they can be disabled by setting "AssumeReachableIPv6 1" in the relay's
torrc.
This option disables IPv6 ORPort reachability checks, so relays publish
their descriptors if their IPv4 ORPort reachability checks succeed.
(Unlike AssumeReachable, AssumeReachableIPv6 has no effect on the existing
dirauth IPv6 reachability checks, which connect directly to relay ORPorts.)
The default for the torrc option is "auto", which checks the consensus
parameter. If the consensus parameter is not set, the default is "0".
"AssumeReachable 1" overrides all values of "AssumeReachableIPv6",
disabling both IPv4 and IPv6 ORPort reachability checks. Tor should warn if
AssumeReachable is 1, but AssumeReachableIPv6 is 0. (On directory
authorities, "AssumeReachable 1" also disables dirauth IPv4 and IPv6
reachability checks, which connect directly to relay ORPorts.
AssumeReachableIPv6 does not disable directory authority to relay IPv6
checks.)
See proposal 311, section 4.3.2:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n403https://gitlab.torproject.org/legacy/trac/-/issues/33223Prop 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is Unreachable2020-06-13T15:50:57ZteorProp 311: 4.3.1. Don't Publish Descriptor if IPv6 ORPort is UnreachableThis ticket depends on the protocol version ticket #33226.
Since it stops relays publishing their descriptors, it needs to be
tested on the public tor network, see #33229 and #33230.
If IPv6 reachability checks fail, relays (and bridge...This ticket depends on the protocol version ticket #33226.
Since it stops relays publishing their descriptors, it needs to be
tested on the public tor network, see #33229 and #33230.
If IPv6 reachability checks fail, relays (and bridges) should refuse to
publish their descriptors, if:
* enough existing relays support IPv6 extends, and
* the IPv6 address was explicitly configured by the operator
(rather than guessed using [Proposal 312: Relay Auto IPv6 Address]).
Directory authorities may perform reachability checks, and warn if those
checks fail. But they always publish their descriptors.
We set a threshold of consensus relays for reliable IPv6 ORPort checks:
* at least 30 relays, and
* at least 1% of the total consensus weight,
must support IPv6 extends.
We chose these parameters so that the number of relays is triple the
number of directory authorities, and the consensus weight is high enough
to support occasional reachability circuits.
In small networks with:
* less than 2000 relays, or
* a total consensus weight of zero,
the threshold should be the minimum tor network size to test reachability:
* at least 2 relays, excluding this relay.
(Note: we may increase this threshold to 3 or 4 relays if we discover a
higher minimum during testing.)
If the current consensus satisfies this threshold, testing relays (and
bridges, but not directory authorities) that fail IPv6 ORPort reachability
checks should refuse to publish their descriptors.
To ensure an accurate threshold, testing relays should exclude:
* the testing relay itself, and
* relays that they will not use in testing circuits,
from the:
* relay count, and
* the numerator of the threshold percentage.
Typically, relays will be excluded if they are in the testing relay's:
* family,
* IPv4 address /16 network,
* IPv6 address /32 network (a requirement as of Tor 0.4.0.1-alpha),
unless EnforceDistinctSubnets is 0.
As a useful side-effect, these different thresholds for each relay family
will reduce the likelihood of the network flapping around the threshold.
If flapping has an impact on the network health, directory authorities
should set the AssumeIPv6Reachable consensus parameter. (See the next
section.)
See proposal 311, section 4.3.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n351https://gitlab.torproject.org/legacy/trac/-/issues/33222Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests2020-06-13T15:53:19ZteorProp 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests4.2. Checking IPv6 ORPort Reachability
We propose that testing relays (and bridges) select some IPv6 extend-capable
relays for their reachability circuits, and include their own IPv4 and IPv6
ORPorts in the final extend cells on those c...4.2. Checking IPv6 ORPort Reachability
We propose that testing relays (and bridges) select some IPv6 extend-capable
relays for their reachability circuits, and include their own IPv4 and IPv6
ORPorts in the final extend cells on those circuits.
The final extending relay will extend to the testing relay:
* using an existing authenticated connection to the testing relay
(which may be over IPv4 or IPv6), or
* over a new connection via the IPv4 or IPv6 ORPort in the extend cell.
The testing relay will confirm that test circuits can extend to both its
IPv4 and IPv6 ORPorts.
4.2.1. Selecting the Final Extending Relay
IPv6 ORPort reachability checks require an IPv6 extend-capable relay as
the second-last hop of reachability circuits. (The testing relay is the
last hop.)
IPv6-extend capable relays must have:
* Relay subprotocol version 3 (or later), and
* an IPv6 ORPort.
(See section 5.1 for the definition of Relay subprotocol version 3.)
The other relays in the path do not require any particular protocol
versions.
4.2.2. Extending from the Second-Last Hop
IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in
the extend cell for the final extend in reachability circuits.
Supplying both ORPorts makes these extend cells indistinguishable from
future client extend cells.
If reachability succeeds, the testing relay (or bridge) will accept the
final extend on one of its ORPorts, selected at random by the extending
relay (see section 3.2.1).
4.2.3. Separate IPv4 and IPv6 Reachability Flags
Testing relays (and bridges) will record reachability separately for IPv4
and IPv6 ORPorts, based on the ORPort that the test circuit was received on.
Here is a reliable way to do reachability self-tests for each ORPort:
1. Check for create cells on inbound ORPort connections from other relays
Check for a cell on any IPv4 and any IPv6 ORPort. (We can't know which listener(s) correspond to the advertised ORPorts, particularly when using port forwarding.) Make sure the cell was received on an inbound OR connection, that is authenticated to another relay.
2. Check for created cells from testing circuits on outbound OR connections
Check for a returned created cell on our IPv4 and IPv6 self-test circuits. Make sure those circuits were on outbound OR connections.
By combining these tests, we confirm that we can:
* reach our own ORPorts with testing circuits
* send and receive cells via inbound OR connections from other relays to our own ORPorts
* send and receive cells via outbound OR connections to other relays' ORPorts
This isn't a perfect test, there are a few false positives:
* relays with multiple IPv4 or IPv6 ORPorts, where only some ports are reachable:
* (this configuration is uncommon, but multiple ORPorts are supported)
* the final extend cell contains the advertised IPv6 address of the self-testing relay
* if the extending relay already has a connection to an old but working ORPort, it may use that connection instead
* so these tests can pass, even when the advertised ORPort is unreachable
* relays whose keys have been copied from another relay in the consensus, for similar reasons
* this configuration is rare and unsupported
From proposal 311, section 4.2:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n283Tor: 0.4.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33221Prop 311: 4. Ensure Relay and Bridge IPv6 ORPorts are Reachable2020-06-13T15:50:54ZteorProp 311: 4. Ensure Relay and Bridge IPv6 ORPorts are ReachableThis is a parent ticket.
We propose that relays (and bridges) check their own IPv6 ORPort
reachability.
To check IPv6 ORPort reachability, relays (and bridges) extend circuits via
other relays (but not other bridges), and back to their...This is a parent ticket.
We propose that relays (and bridges) check their own IPv6 ORPort
reachability.
To check IPv6 ORPort reachability, relays (and bridges) extend circuits via
other relays (but not other bridges), and back to their own IPv6 ORPort.
If IPv6 reachability checks fail, relays (and bridges) should refuse to
publish their descriptors, if they believe IPv6 reachability checks are
reliable, and their IPv6 address was explicitly configured. (See
[Proposal 312: Relay Auto IPv6 Address] for the ways relays can guess their
IPv6 addresses.)
Directory authorities always publish their descriptors.
From Proposal 311, section 4:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n246teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33220Prop 311: 3. Allow Relay IPv6 Extends2020-06-13T15:50:53ZteorProp 311: 3. Allow Relay IPv6 ExtendsRelays may make a new connection over IPv6 when:
* they have an IPv6 ORPort,
* there is no existing authenticated connection to the requested relay, and
* the extend cell contains an IPv6 ORPort.
If these conditions are satisfied,...Relays may make a new connection over IPv6 when:
* they have an IPv6 ORPort,
* there is no existing authenticated connection to the requested relay, and
* the extend cell contains an IPv6 ORPort.
If these conditions are satisfied, and the extend cell also contains an
IPv4 ORPort, we propose that the relay choose between an IPv4 and an IPv6
connection at random.
If the extend cell does not contain an IPv4 ORPort, we propose that the
relay connects over IPv6. (Relays should support IPv6-only extend cells,
even though they are not used to test relay reachability in this proposal.)
A successful IPv6 connection also requires that:
* the requested relay has an IPv6 ORPort.
But extending relays must not check the consensus for other relays' IPv6
information. Consensuses may be out of date, particularly when relays are
doing reachability checks for new IPv6 ORPorts.
From proposal 311, section 3:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n112teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33195Require IPv6 tests in Travis CI2020-06-13T15:50:47ZteorRequire IPv6 tests in Travis CIWhile we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas th...While we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas that I can make fast_finish.
I think our Rust build might be a good candidate for fast_finish, we haven't changed that code much in about a year. But I should check with the team before making this change.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33159Write a proposal for monitoring IPv62020-06-13T15:50:42ZteorWrite a proposal for monitoring IPv6For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using I...For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6 (#33052)
My current thinking is that:
* tor should log the number and consensus weight of relays that support IPv6 reachability checks, because we will need those numbers during testing
* these numbers are available in the consensus
Here's what the proposal requires:
* calculate relay IPv6 reachability numbers a few times during the project (we may as well use the tor logs)
* collect IPv6 connection and bandwidth statistics on tor relays
* calculate the IPv6 connection and bandwidth amounts a few times during the project
Here are some other useful things we might do:
* split the collected IPv6 statistics by client/relay
* calculate the guard-but-not-exit relays that support IPv6 client connections
* log IPv6 statistics in tor's heartbeat logs (we can't use these logs for our project reports, because they only show the local relay's statistics)
* calculate IPv6 reachability relay count and consensus weight on consensus-health
* add a pseudo-flag for relay IPv6 reachability support in Relay Search
* add metrics graphs that shows our progress on
* IPv6 reachability
* client IPv6 support on relays
* IPv6 connections and bandwidth
We definitely won't have time to do all of these optional things, so we should priorise, once the essential work is done.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33091Remove redundant checks in ip_address_changed()2020-06-13T15:50:29ZteorRemove redundant checks in ip_address_changed()ip_address_changed() does a separate exit policy check, but all relays need to refresh their descriptors when their address changes.ip_address_changed() does a separate exit policy check, but all relays need to refresh their descriptors when their address changes.Tor: 0.4.3.x-finalteorteor