[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