commit 27936d046eb6678c0661b5657d83a6082d66033c Author: teor teor@torproject.org Date: Wed Jan 29 22:39:46 2020 +1000

Prop 311: Allow Extends to Prefer IPv4 or IPv6

Add an alternate design, suggested by Nick Mathewson.

Part of 24404. --- proposals/311-relay-ipv6-reachability.txt | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/proposals/311-relay-ipv6-reachability.txt b/proposals/311-relay-ipv6-reachability.txt index 8bb71f4..f34d379 100644 --- a/proposals/311-relay-ipv6-reachability.txt +++ b/proposals/311-relay-ipv6-reachability.txt @@ -191,7 +191,29 @@ Ticket: #24404 default, bridges should also adopt this behaviour. (For example, see [Proposal 306: Client Auto IPv6 Connections].)

-3.3.3. Rejected Extend Designs +3.3.3. Allowing Extends to Prefer IPv4 or IPv6 + + Here is an alternate design, which allows extending clients (or relays doing + reachability tests) to prefer either IPv4 or IPv6: + + Suppose that a relay's extend cell contains the IPv4 address and the + IPv6 address in their _preferred order_. So if the party generating + the extend cell would prefer an IPv4 connection, it puts the IPv4 + addess first; if it would prefer an IPv6 connection, it puts the IPv6 + address first. + + The relay that receives the extend cell could respond in several ways: + * One possibility (similar to section 3.2.1) is to choose at random, + with a higher probability given to the first option. + * One possibility (similar to section 3.3.1) is to try the first, and + then try the second if the first one fails. + + This scheme has some advantage, in that it lets the self-testing relay say + "please try IPv6 if you can" or "please try IPv4 if you can" in a reliable + way, and lets us migrate from the current behavior to the 3.3.1 behavior + down the road. + +3.4. Rejected Extend Designs

Some designs may never be suitable for the Tor network.