From 0e20e5a06736a36599e2c1a2e2efd1f055ee18bb Mon Sep 17 00:00:00 2001 From: teor Date: Mon, 3 Feb 2020 19:00:12 +1000 Subject: Prop 312: Add an alternative IPv6 disable design And explain why we didn't use the existing ORPort IPv4Only flag to disable IPv6 address resolution. Part of 33073. --- proposals/312-relay-auto-ipv6-addr.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'proposals/312-relay-auto-ipv6-addr.txt') diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt index ec1d52d..3f3b587 100644 --- a/proposals/312-relay-auto-ipv6-addr.txt +++ b/proposals/312-relay-auto-ipv6-addr.txt @@ -387,6 +387,21 @@ Ticket: #33073 resolution, IPv6 ORPorts, IPv6 reachability checks, and publishing an IPv6 ORPort in its descriptor. +3.2.7.1. Disabling IPv6 Address Resolution: Alternative Design + + As an alternative design, tor could change its interpretation of the + IPv4Only flag, so that the following configuration lines disable IPv6: + (In the absence of any non-IPv4Only ORPort lines.) + * ORPort 9999 IPv4Only + * ORPort 1.1.1.1:9999 IPv4Only + + However, we believe that this is a confusing design, because we want to + enable IPv6 address resolution on this similar, very common configuration: + * ORPort 1.1.1.1:9999 + + Therefore, we avoid this design, becuase it changes the meaning of existing + flags and options. + 3.2.8. Automatically Enabling an IPv6 ORPort We propose that relays (and bridges) that discover their IPv6 address, -- cgit v1.2.3-54-g00ecf