[tor-commits] [torspec/master] Prop 311: Improve Subprotocol Version

[teor at torproject.org]

commit 8e85047b651f6cb3317566b4c0b322cad5ea29e4
Author: teor <teor at 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).