commit 9966ad3f3f82c551ca26b52e4072447b31e5f413 Author: teor teor@torproject.org 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-eyeb... (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... (TODO) +[Proposal 312: Relay Auto IPv6 Address]: https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6...

[Proposal 313: Relay IPv6 Statistics]: https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stat... (TODO)