Opened 6 months ago

Last modified 8 weeks ago

#33236 assigned enhancement

Prop 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors

Reported by: teor Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop312, ipv6, network-team-roadmap-2020Q2, 044-deferred
Cc: Actual Points:
Parent ID: #33049 Points: 1
Reviewer: Sponsor: Sponsor55-must

Description (last modified by teor)

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

Child Tickets

TicketTypeStatusOwnerSummary
#33681taskassignedRefactor using_default_dir_authorities() local address checks

Change History (6)

comment:1 Changed 4 months ago by gaba

Keywords: network-team-roadmap-2020Q2 added

Add more s55 tickets to 2020 Q2 roadmap for the network team.

comment:2 Changed 3 months ago by teor

Description: modified (diff)
Summary: Prop 312: 3.2.2. Use Advertised ORPort IPv4 and IPv6 Addresses in DescriptorsProp 312: 3.2.2. Use Advertised ORPort IPv4 Addresses in Descriptors

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

comment:3 Changed 3 months ago by teor

Summary: Prop 312: 3.2.2. Use Advertised ORPort IPv4 Addresses in DescriptorsProp 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors

comment:4 Changed 3 months ago by teor

Owner: teor deleted

Un-assign myself from future Sponsor 55 tasks.

comment:5 Changed 8 weeks ago by nickm

Keywords: 044-deferred added
Milestone: Tor: 0.4.4.x-finalTor: unspecified

Bulk-remove tickets from 0.4.4. Add the 044-deferred label to them.

comment:6 Changed 8 weeks ago by nickm

Milestone: Tor: unspecified

Bulk-move prop311 and prop312 to 0.4.5

Note: See TracTickets for help on using tickets.