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

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