[tor-commits] [torspec/master] Prop 311: Support seamless upgrades

[teor@xxxxxxxxxxxxxx]

commit 9966ad3f3f82c551ca26b52e4072447b31e5f413
Author: teor <teor@xxxxxxxxxxxxxx>
Date:   Wed Jan 29 13:18:56 2020 +1000

    Prop 311: Support seamless upgrades
    
    We want to support these two cases:
      * upgrade to working IPv6,
      * stay on IPv4-only, if a guessed IPv6 address isn't reachable.
    
    Part of 24404.
---
 proposals/311-relay-ipv6-reachability.txt | 48 ++++++++++++++++++++-----------
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt
index a93f286..ba7a151 100644
--- a/proposals/311-relay-ipv6-reachability.txt
+++ b/proposals/311-relay-ipv6-reachability.txt
@@ -8,9 +8,9 @@ Ticket: #24404
 0. Abstract
 
    We propose that Tor relays (and bridges) should check the reachability of
-   their IPv6 ORPort, before publishing their descriptor. To check IPv6 ORPort
-   reachability, relays and bridges need to be able to extend circuits via
-   other relays, and back to their own IPv6 ORPort.
+   their IPv6 ORPort, before deciding whether to publish their descriptor. To
+   check IPv6 ORPort reachability, relays and bridges need to be able to
+   extend circuits via other relays, and back to their own IPv6 ORPort.
 
 1. Introduction
 
@@ -214,15 +214,19 @@ Ticket: #24404
 
 4. Check Relay and Bridge IPv6 ORPort Reachability
 
-   We propose that relays and bridges check their own IPv6 ORPort reachability.
+   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.
 
-   To check IPv6 ORPort reachability, relays and bridges extend circuits via
-   other relays, 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.)
 
-   IPv6 reachability failures may result in a relay or bridge refusing to
-   publish its descriptor, if enough existing relays support IPv6 extends.
-   (Except for directory authorities: they perform reachability checks, and
-   warn if they fail. But they always publish their descriptors.)
+   Directory authorities always publish their descriptors.
 
 4.1. Current Reachability Implementation
 
@@ -300,20 +304,30 @@ Ticket: #24404
      * relay IPv6 DirPorts.
    Therefore, they are also out of scope for this proposal.
 
-4.3. Refuse to Publish Descriptor if IPv6 ORPort is Unreachable
+4.3. Refusing to Publish Descriptor if IPv6 ORPort is Unreachable
 
    If an IPv6 ORPort reachability check fails, relays (and bridges) should log
    a warning.
 
-   In addition, if IPv6ORPort reachability checks are reliable, based on the
-   number of relays in the network that support IPv6 extends, relays should
-   refuse to publish their descriptor.
+   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 should perform reachability checks, and warn if they
-   fail. But directory authorities should always publish their descriptors.
+   Directory authorities always publish their descriptors.
 
 4.3.1. Refusing to Publish the Descriptor
 
+   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,
@@ -666,7 +680,7 @@ References:
 
 [Proposal 306: Client Auto IPv6 Connections]: One possible design for automatic client IPv4 and IPv6 connections is at https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt (TODO: modify to include bridge changes with client changes)
 
-[Proposal 312: Relay Auto IPv6 Address]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt (TODO)
+[Proposal 312: Relay Auto IPv6 Address]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt
 
 [Proposal 313: Relay IPv6 Statistics]: https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt (TODO)
 



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits