commit 8e85047b651f6cb3317566b4c0b322cad5ea29e4 Author: teor teor@torproject.org Date: Wed Jan 29 22:43:00 2020 +1000

Prop 311: Improve Subprotocol Version

* don't ban useful behaviours, just mention that they might not happen * don't talk about reachability, other tor instances don't care * specify random choice between IPv4 and IPv6 (and add a TODO)

As suggested by Nick Mathewson.

Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 39 ++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 29c4f1a..4b9889b 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -592,10 +592,10 @@ Ticket: #24404

5. New Relay Subprotocol Version

- We reserve Tor subprotocol "Relay=3" for: - * relays that support for IPv6 extends, and - * relays and bridges that support IPv6 ORPort reachability checks, - as described in this proposal. + We reserve Tor subprotocol "Relay=3" for tor versions where: + * relays may perform IPv6 extends, and + * bridges may not perform IPv6 extends, + if configured with an IPv6 ORPort, as described in this proposal.

5.1. Tor Specification Changes

@@ -604,25 +604,31 @@ Ticket: #24404

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 (and bridges). + or require support for IPv6 extends on all relays.

Append to the Relay version 2 subprotocol specification:

Relay=2 has limited IPv6 support: - * Clients do not include IPv6 ORPorts in EXTEND2 cells. - * Relays do not initiate IPv6 connections in response to - EXTEND2 cells containing IPv6 ORPorts. + * Clients may not include IPv6 ORPorts in EXTEND2 cells. + * Relays (and bridges) may not initiate IPv6 connections in + response to EXTEND2 cells containing IPv6 ORPorts, even if they + are configured with an IPv6 ORPort. However, relays accept inbound connections to their IPv6 ORPorts, and will extend circuits via those connections.

"3" -- relays support extending over IPv6 connections in response to an - EXTEND2 cell containing an IPv6 ORPort. Relays and bridges perform - IPv6 ORPort reachability checks. Client behaviour does not change. + EXTEND2 cell containing an IPv6 ORPort.

- This subprotocol is advertised by all relays and bridges, regardless - of their configured ORPorts. But relays without a configured IPv6 - ORPort may refuse to extend over IPv6. And bridges always refuse to - extend over IPv6, because they try to imitate client behaviour. + Bridges may 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 @@ -634,6 +640,11 @@ Ticket: #24404 Extending relays should only check local IPv6 information, before attempting the extend.)

+ 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.) + This subprotocol version is described in proposal 311, and implemented in Tor 0.4.4.1-alpha. (TODO: check version after code is merged).