[tor-commits] [torspec/master] Prop 312: Remove the DirPort method

teor at torproject.org teor at torproject.org
Wed Feb 5 12:07:24 UTC 2020


commit 0159850437236d0ff8bcd1089ca3aa95e02c07d2
Author: teor <teor at torproject.org>
Date:   Tue Feb 4 12:45:52 2020 +1000

    Prop 312: Remove the DirPort method
    
    It's unlikely to be useful for most configurations.
    
    As suggested by Nick Mathewson.
    
    Part of 33073.
---
 proposals/312-relay-auto-ipv6-addr.txt | 81 ++++++++++++----------------------
 1 file changed, 28 insertions(+), 53 deletions(-)

diff --git a/proposals/312-relay-auto-ipv6-addr.txt b/proposals/312-relay-auto-ipv6-addr.txt
index 752a0be..29a45f6 100644
--- a/proposals/312-relay-auto-ipv6-addr.txt
+++ b/proposals/312-relay-auto-ipv6-addr.txt
@@ -47,7 +47,7 @@ Ticket: #33073
    Relays, bridges, and directory authorities:
      * automatically find their IPv6 address, and
      * for consistency between IPv4 and IPv6 detection:
-       * start using IPv4 ORPort and DirPort for IPv4 address detection, and
+       * start using IPv4 ORPort for IPv4 address detection, and
        * re-order IPv4 address detection methods.
 
    Relays and directory authorities (but not bridges):
@@ -60,7 +60,7 @@ Ticket: #33073
      * clients also check IPv6 addresses when rotating TLS keys for new
        networks.
    In addition to the changes to IPv4 address resolution, most of which won't
-   affect clients. (Because they do not set Address, ORPort, or DirPort.)
+   affect clients. (Because they do not set Address or ORPort.)
 
    Throughout this proposal, "relays" includes directory authorities, except
    where they are specifically excluded. "relays" does not include bridges,
@@ -146,14 +146,20 @@ Ticket: #33073
    IPv6 addresses in this order:
      1. the Address torrc option
      2. the advertised ORPort address
-     3. the advertised DirPort address (IPv4 only; relays, not bridges)
-     4. a local interface address
+     3. a local interface address
         (by making a self-connected socket, if needed)
-     5. the address of the host's own hostname (resolved using DNS, if needed)
-     6. an address reported by a directory server (using X-Your-Address-Is)
+     4. the address of the host's own hostname (resolved using DNS, if needed)
+     5. an address reported by a directory server (using X-Your-Address-Is)
+
+   Each of these address resolution steps is described in more detail, in its
+   own subsection.
 
-   (Each of these address resolution steps is described in more detail, in its
-   own subsection.)
+   We avoid using advertised DirPorts for address resolution, because:
+     * they are not supported on bridges,
+     * they are not supported on IPv6,
+     * they may not be configured on a relay, and
+     * it is unlikely that a relay operator would configure an ORPort without
+       an IPv4 address, but configure a DirPort with an IPv4 address.
 
    While making these changes, we want to preserve tor's existing behaviour:
      * resolve Address using the local resolver, if needed,
@@ -246,37 +252,7 @@ Ticket: #33073
    use NAT to reach the Internet.) If an ORPort address is private, address
    resolution should go to the next step.
 
-3.2.3. Use the Advertised DirPort IPv4 Address
-
-   Next, we propose that relays use the first advertised DirPort IPv4 address,
-   as configured in their torrc.
-
-   The following DirPort configurations can not be used for address
-   resolution, because they are not supported:
-     * bridge DirPorts, and
-     * advertised IPv6 DirPorts.
-
-   The DirPort address may be a hostname. If it is, tor should try to use it to
-   resolve an IPv4 address, and open a DirPort on the first available IPv4
-   address. Tor should only look for IPv6 addresses if the IPv6Only port flag
-   is specified. (Since advertised IPv6 DirPorts are not supported, a
-   working configuration may also require the NoAdvertise flag.)
-
-   Relays currently use the first advertised ORPort IPv6 address as their IPv6
-   address. We propose to use the first advertised IPv4 DirPort address in a
-   similar way, for consistency.
-
-   Therefore, this change may affect existing relay IPv4 addressses. We expect
-   that a very small number of relays may change IPv4 address, from a guessed
-   IPv4 address, to their first advertised IPv4 DirPort address. (But we expect
-   that most relays that change will be using their ORPort address.)
-
-   For the purposes of address resolution, tor should also ignore private
-   configured DirPort addresses on public tor networks. (See the previous
-   section for details.) If a DirPort address is private, address resolution
-   should go to the next step.
-
-3.2.4. Use Local Interface IPv6 Address
+3.2.3. Use Local Interface IPv6 Address
 
    Next, we propose that relays (and bridges) use publicly routable addresses
    from the OS interface addresses or routing table, as their IPv4 and IPv6
@@ -310,7 +286,7 @@ Ticket: #33073
    IPv4 or IPv6 interface addresses are private, address resolution should go
    to the next step.
 
-3.2.5. Use Own Hostname IPv6 Addresses
+3.2.4. Use Own Hostname IPv6 Addresses
 
    Next, we propose that relays (and bridges) get their local hostname, look
    up its addresses, and use them as its IPv4 and IPv6 addresses.
@@ -331,7 +307,7 @@ Ticket: #33073
    each family should be used. If all IPv4 or IPv6 hostname addresses are
    private, address resolution should go to the next step.
 
-3.2.6. Use Directory Header IPv6 Addresses
+3.2.5. Use Directory Header IPv6 Addresses
 
    Finally, we propose that relays get their IPv4 and IPv6 addresses from the
    X-Your-Address-Is HTTP header in tor directory documents. To support this
@@ -392,7 +368,7 @@ Ticket: #33073
    Address resolution should continue the next time tor receives a directory
    header containing a public IPv4 or IPv6 address.
 
-3.2.7. Disabling IPv6 Address Resolution
+3.2.6. Disabling IPv6 Address Resolution
 
    Relays (and bridges) that have a reachable IPv6 address, but that address
    is unsuitable for the relay, need to be able to disable IPv6 address
@@ -418,7 +394,7 @@ 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
+3.2.6.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:
@@ -433,7 +409,7 @@ Ticket: #33073
    Therefore, we avoid this design, becuase it changes the meaning of existing
    flags and options.
 
-3.2.8. Automatically Enabling an IPv6 ORPort
+3.2.7. Automatically Enabling an IPv6 ORPort
 
    We propose that relays (and bridges) that discover their IPv6 address,
    should open an ORPort on that address, and test its reachability (see
@@ -474,8 +450,7 @@ Ticket: #33073
 
    Clients should skip address resolution steps that don't apply to them, such
    as:
-     * the ORPort option,
-     * the DirPort option, and
+     * the ORPort option, and
      * the Address option, if it becomes a relay module option.
 
 3.4. Alternative Address Resolution Designs
@@ -493,7 +468,7 @@ Ticket: #33073
    behaviour. (For example, see [Proposal 306: Client Auto IPv6 Connections].)
 
    When bridges fetch directory documents via IPv6, they will be able to find
-   their IPv6 address using directory headers (see 3.2.6).
+   their IPv6 address using directory headers (see 3.2.5).
 
 3.4.2. Guessing Muliple IPv4 or IPv6 Addresses
 
@@ -521,7 +496,7 @@ Ticket: #33073
    (and bridge) addresses are fixed, or change occasionally. And most relays
    can reliably discover their address using directory headers, if all other
    methods fail. (Bridges won't discover their IPv6 address from directory
-   headers, see section 3.2.6.)
+   headers, see section 3.2.5.)
 
    If complex address resolution is required, it can be configured using a
    dynamic DNS name in the Address torrc option, or via the control port.
@@ -776,7 +751,7 @@ Ticket: #33073
 3.5.7. Use a Local Interface Address on the Default Route
 
    We propose this optional change, to improve the accuracy of local interface
-   IPv4 and IPv6 address detection (see section 3.2.4).
+   IPv4 and IPv6 address detection (see section 3.2.3).
 
    Rewrite the get_interface_address*() functions to choose an interface
    address on the default route, or to sort default route addresses first in
@@ -788,7 +763,7 @@ Ticket: #33073
 
    This change might not be necessary, because the directory header IP address
    method will find the IP address of the default route, in most cases
-   (see section 3.2.6).
+   (see section 3.2.5).
 
 3.5.8. Add IPv6 Support Using gethostbyname2()
 
@@ -796,7 +771,7 @@ Ticket: #33073
    resolution on older OSes. These changes affect:
      * the Address torrc option, when it is a hostname (see section 3.2.1),
        and
-     * automatic hostname resolution (see section 3.2.5).
+     * automatic hostname resolution (see section 3.2.4).
 
    Use gethostbyname2() to add IPv6 support to hostname resolution on older
    OSes, which don't support getaddrinfo().
@@ -911,7 +886,7 @@ Ticket: #33073
    already have the relay's addresses from a previous consensus.)
 
    Automatically enabling an IPv6 ORPort creates a race condition with IPv6
-   extends (see section 3.2.8 of this proposal, and
+   extends (see section 3.2.7 of this proposal, and
    [Proposal 311: Relay IPv6 Reachability]).
 
    This race condition has the most impact when:
@@ -1031,7 +1006,7 @@ Ticket: #33073
 
    [Proposal 306: Client Auto IPv6 Connections] needs to be modified to keep
    bridge IPv6 behaviour in sync with client IPv6 behaviour. (See section
-   3.2.6.)
+   3.2.5.)
 
 References:
 





More information about the tor-commits mailing list