commit f7fb789de4b6198dd7d87aecbd443d0542c08452 Author: teor <teor@torproject.org> Date: Mon Feb 3 21:20:15 2020 +1000 Prop 311: Rewrite and re-order tor-spec changes We want to allow relays to upgrade to trying both addresses in an EXTEND2 cell, without requiring a new protocol version. The spec documents the planned "choose at random" behaviour, but allows relays to try both IPv4 and IPv6 in future. Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 39 ++++++++++++++++++------------- 1 file changed, 23 insertions(+), 16 deletions(-) diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 0adf711..c292c8a 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -603,7 +603,7 @@ Ticket: #24404 We reserve Tor subprotocol "Relay=3" for tor versions where: * relays may perform IPv6 extends, and * bridges might not perform IPv6 extends, - if configured with an IPv6 ORPort, as described in this proposal. + as described in this proposal. 5.1. Tor Specification Changes @@ -630,18 +630,10 @@ Ticket: #24404 Bridges might not extend over IPv6, because they try to imitate client behaviour. - Relays without an IPv6 ORPort, and tor instances running in other - roles, may: - * advertise support for "Relay=3", and - * react to consensuses recommending or requiring support for - "Relay=3". - But their other behaviour is similar to tor versions supporting - "Relay=2". - A successful IPv6 extend requires: - * Relay subprotocol version 3 (or later) and an IPv6 ORPort on the - extending relay, - * an IPv6 ORPort in the EXTEND2 cell, and + * Relay subprotocol version 3 (or later) on the extending relay, + * an IPv6 ORPort on the extending relay, + * an IPv6 ORPort for the accepting relay in the EXTEND2 cell, and * an IPv6 ORPort on the accepting relay. (Because different tor instances can have different views of the network, these checks should be done when the path is selected. @@ -650,12 +642,27 @@ Ticket: #24404 When relays receive an EXTEND2 cell containing both an IPv4 and an IPv6 ORPort, and there is no existing authenticated connection with - the target relay, the extending relay chooses between IPv4 and IPv6 - at random. (TODO: check final behaviour after code is merged.) + the target relay, the extending relay may choose between IPv4 and + IPv6 at random. The extending relay might not try the other address, + if the first connection fails. + (TODO: check final behaviour after code is merged.) + + As is the case with other subprotocol versions, tor advertises, + recommends, or requires support for this protocol version, regardless + of its current configuration. + + In particular: + * relays without an IPv6 ORPort, and + * tor instances that are not relays, + have the following behaviour, regardless of their configuration: + * advertise support for "Relay=3" in their descriptor + (if they are a relay, bridge, or directory authority), and + * react to consensuses recommending or requiring support for + "Relay=3". This subprotocol version is described in proposal 311, and - implemented in Tor 0.4.4.1-alpha. (TODO: check version after code is - merged). + implemented in Tor 0.4.4.1-alpha. + (TODO: check version after code is merged). 6. Test Plan