[tor-bugs] #33236 [Core Tor/Tor]: Prop 312: 3.2.2. Use Advertised ORPort IPv4 Addresses in Descriptors (was: Prop 312: 3.2.2. Use Advertised ORPort IPv4 and IPv6 Addresses in Descriptors)

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Apr 28 11:16:12 UTC 2020


#33236: Prop 312: 3.2.2. Use Advertised ORPort IPv4 Addresses in Descriptors
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  teor
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.4.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  prop312, ipv6, network-team-         |  Actual Points:
  roadmap-2020Q2                                 |
Parent ID:  #33049                               |         Points:  1
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor55-must
-------------------------------------------------+-------------------------

Old description:

> If the Address option is not set for IPv4 or IPv6, relays (and bridges)
> should use the first advertised ORPort IPv4 and IPv6 addresses.
>
> The ORPort address may be a hostname. If it is, tor should try to use it
> to
> resolve an IPv4 and IPv6 address, and open ORPorts on the first available
> IPv4 and IPv6 address. Tor should respect the IPv4Only and IPv6Only port
> flags, if specified. (Tor currently resolves IPv4 and IPv6 addresses from
> hostnames in ORPort lines.)
>
> Relays (and bridges) currently use the first advertised ORPort IPv6
> address
> as their IPv6 address. We propose to use the first advertised IPv4 ORPort
> address in a similar way, for consistency.
>
> Tor currently uses its listener port list to look up its IPv6 ORPort for
> its descriptor. We propose that tor's address discovery uses the
> listener
> port list for both IPv4 and IPv6. (And does not attempt to independently
> parse or resolve ORPort configs.)
>
> This design decouples ORPort option parsing, ORPort listener opening, and
> address discovery. It also implements a form of caching: IPv4 and IPv6
> addresses resolved from hostnames are stored in the listener port list,
> then used to open listeners. Therefore, tor should continue to use the
> same
> address, while the listener remains open. (See also sections 3.2.7 and
> 3.2.8.)
>
> For the purposes of address resolution, tor should ignore private
> configured ORPort addresses on public tor networks. (Binding to private
> ORPort addresses is supported, even on public tor networks, for relays
> that use NAT to reach the Internet.)
>
> See proposal 312, section 3.2.2, general case:
>https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-
> ipv6-addr.txt#n306

New description:

 If the Address option is not set for IPv4 or IPv6, relays (and bridges)
 should use the first advertised ORPort IPv4 and IPv6 addresses.

 Note that relays already use the first advertised IPv6 ORPort address in
 their descriptors. So we just need to preserve that behaviour.

 The ORPort address may be a hostname. If it is, tor should try to use it
 to
 resolve an IPv4 and IPv6 address, and open ORPorts on the first available
 IPv4 and IPv6 address. Tor should respect the IPv4Only and IPv6Only port
 flags, if specified. (Tor currently resolves IPv4 and IPv6 addresses from
 hostnames in ORPort lines.)

 Relays (and bridges) currently use the first advertised ORPort IPv6
 address
 as their IPv6 address. We propose to use the first advertised IPv4 ORPort
 address in a similar way, for consistency.

 Tor currently uses its listener port list to look up its IPv6 ORPort for
 its descriptor. We propose that tor's address discovery uses the  listener
 port list for both IPv4 and IPv6. (And does not attempt to independently
 parse or resolve ORPort configs.)

 This design decouples ORPort option parsing, ORPort listener opening, and
 address discovery. It also implements a form of caching: IPv4 and IPv6
 addresses resolved from hostnames are stored in the listener port list,
 then used to open listeners. Therefore, tor should continue to use the
 same
 address, while the listener remains open. (See also sections 3.2.7 and
 3.2.8.)

 For the purposes of address resolution, tor should ignore private
 configured ORPort addresses on public tor networks. (Binding to private
 ORPort addresses is supported, even on public tor networks, for relays
 that use NAT to reach the Internet.)

 See proposal 312, section 3.2.2, general case:
 ​https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-
 ipv6-addr.txt#n306

--

Comment (by teor):

 Note that relays already use the first advertised IPv6 ORPort address in
 their descriptors. So we just need to preserve that behaviour.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33236#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list