Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-07-13T19:25:02Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33265Prop 313: 6. Update Directory Spec for IPv6 Stats2020-07-13T19:25:02ZteorProp 313: 6. Update Directory Spec for IPv6 StatsWe want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168We want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33264Prop 313: 5. Collect IPv6 Connection Stats on Relays2020-07-10T17:14:38ZteorProp 313: 5. Collect IPv6 Connection Stats on RelaysWe propose that relays (but not bridges) collect IPv6 connection statistics.
Bridges refuse to collect the existing ConnDirectionStatistics, so we do not
believe it is safe to collect the smaller IPv6 totals on bridges.
To minimise dev...We propose that relays (but not bridges) collect IPv6 connection statistics.
Bridges refuse to collect the existing ConnDirectionStatistics, so we do not
believe it is safe to collect the smaller IPv6 totals on bridges.
To minimise development and testing effort, we propose re-using the existing
"bidi" code in rephist.c. (This code may require some refactoring, because
the "bidi" totals are globals, rather than a struct.)
(We might also want to move this code into separate relay-only code and
header files, because it is relay-specific.)
In particular, tor currently counts these connection statistics:
* below threshold,
* mostly read,
* mostly written, and
* both read and written.
We propose adding IPv6 variants of all these statistics. (The IPv4
statistics can be calculated by subtracting the IPv6 statistics from the
existing total connection statistics.)
See proposal 313, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n144Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33263Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges2020-07-21T15:33:59ZteorProp 313: 4. Collect IPv6 Bandwidth Stats on Relays and BridgesWe propose that relays (and bridges) collect IPv6 consumed bandwidth
statistics.
To minimise development and testing effort, we propose re-using the existing
"bw_array" code in rephist.c.
(We might want to move this code into separate ...We propose that relays (and bridges) collect IPv6 consumed bandwidth
statistics.
To minimise development and testing effort, we propose re-using the existing
"bw_array" code in rephist.c.
(We might want to move this code into separate relay-only code and header files, because it is relay-specific.)
In particular, tor currently counts these bandwidth statistics:
* read,
* write,
* dir_read, and
* dir_write.
We propose adding the following bandwidth statistics:
* ipv6_read, and
* ipv6_write.
(The IPv4 statistics can be calculated by subtracting the IPv6 statistics
from the existing total consumed bandwidth statistics.)
We believe that collecting IPv6 consumed bandwidth statistics is about as
safe as the existing IPv4+IPv6 total consumed bandwidth statistics.
See proposal 313, section 4:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n118
Tasks:
* [x] Split bandwidth history into a separate file.
* [x] Get adequate test coverage on bandwidth history code.
* [x] Add a pair of IPv6 bandwidth arrays.
* [x] Make data get inserted into the IPv6 bandwidth arrays as appropriate.
* [x] Include IPv6 bandwidth data in extrainfo descriptors.Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33262Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus2020-07-02T19:46:43ZteorProp 313: 3. Write a Script that Counts IPv6 Relays in the ConsensusWe want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two ...We want to write a script that generates statistics for relays that:
1. have an IPv6 ORPort,
2. support IPv6 clients,
3. support IPv6 reachability checks, and
4. support IPv6 reachability checks, and IPv6 clients.
The first two statistics have no dependencies. The last two statistics depend on the "Relay=3" subprotocol in legacy/trac#33226.
The script should calculate:
* the number of relays, and
* the consensus weight fraction of relays.
In order to provide easy access to these statistics, we propose
that the script should:
* download a consensus (or read an existing consensus), and
* calculate and report these statistics.
We could write this script using Python 3 and Stem:
https://stem.torproject.org
The following consensus weight fractions should divide by the total
consensus weight:
* have an IPv6 ORPort (all relays have an IPv4 ORPort), and
* support IPv6 reachability checks (all relays support IPv4 reachability).
The following consensus weight fractions should divide by the
"usable Guard" consensus weight:
* support IPv6 clients, and
* support IPv6 reachability checks and IPv6 clients.
"Usable Guards" have the Guard flag, but do not have the Exit flag. If the
Guard also has the BadExit flag, the Exit flag should be ignored.
The script should check that Wgd is 0. If it is not, the script
should log a warning about the accuracy of the "Usable Guard" statistics.
See proposal 313, section 3:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n82Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33253Prop 312: 5.1. Ask Relay Operators to Test IPv6 Addresses Discovery2020-07-22T19:55:48ZteorProp 312: 5.1. Ask Relay Operators to Test IPv6 Addresses DiscoverySee legacy/trac#33252 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 312 IPv4 and IPv6 Address Discovery changes.
Once these changes are merged, volunteer relay and...See legacy/trac#33252 for advice on testing stages.
Write an email to the tor-relays list, asking relay operators to help test the proposal 312 IPv4 and IPv6 Address Discovery changes.
Once these changes are merged, volunteer relay and bridge operators will be able to test them by:
* compiling from source,
* running nightly builds, or
* running alpha releases.
See proposal 312, section 5.1, relay operator test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1461Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33252Prop 312: 5.1. Test Relay IPv6 Addresses Discovery on the Tor Network2020-07-22T17:29:08ZteorProp 312: 5.1. Test Relay IPv6 Addresses Discovery on the Tor NetworkTest the IPv4 and IPv6 ORPort Address Detection changes in proposal 312, on the public tor network, with a small number of relays and bridges.
Here are some useful features that we can test:
legacy/trac#33246 Prop 312: 3.2.7. Automatic...Test the IPv4 and IPv6 ORPort Address Detection changes in proposal 312, on the public tor network, with a small number of relays and bridges.
Here are some useful features that we can test:
legacy/trac#33246 Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort
legacy/trac#33238 Prop 312: 3.2.3. Use Local Interface IPv6 Address
legacy/trac#33240 Prop 312: 3.2.4. Use Own Hostname IPv6 Addresses
legacy/trac#33247 Prop 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure
See proposal 312, section 5.1, initial public test part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1461Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33249Prop 312: 4. Update Directory Spec for IPv6 X-Your-Address-Is2020-06-27T13:48:16ZteorProp 312: 4. Update Directory Spec for IPv6 X-Your-Address-IsWe should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we sho...We should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we should look at what relays currently do (in tor 0.3.5 to 0.4.2, as of January 2020).
See proposal 312, section 4, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1432https://gitlab.torproject.org/tpo/core/tor/-/issues/33248Prop 312: 3.5.5. Detailed Address Resolution Logs2020-07-22T17:33:47ZteorProp 312: 3.5.5. Detailed Address Resolution LogsThis is an optional change, to help diagnose relay address resolution
issues.
Relays (and bridges) should log the address chosen using each address
resolution method, when:
* address resolution succeeds,
* address resolution fails,...This is an optional change, to help diagnose relay address resolution
issues.
Relays (and bridges) should log the address chosen using each address
resolution method, when:
* address resolution succeeds,
* address resolution fails,
* reachability checks fail, or
* publishing the descriptor fails.
These logs should be rate-limited separately for successes and failures.
The logs should tell operators to set the Address torrc option for IPv4 and
IPv6 (if available).
See proposal 312, section 3.5.5:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1083Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33247Prop 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure2020-07-24T17:04:58ZteorProp 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability FailureDepends on disabling descriptor publication on reachability
failures in legacy/trac#33223.
Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
If both reachability checks succeed, relay...Depends on disabling descriptor publication on reachability
failures in legacy/trac#33223.
Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
If both reachability checks succeed, relays should publish their IPv4 and IPv6 ORPorts in their descriptor.
If only the IPv4 ORPort check succeeds, and the IPv6 address was guessed
(rather than being explicitly configured), then relays should:
* publish their IPv4 ORPort in their descriptor,
* stop publishing their IPv6 ORPort in their descriptor, and
* log a notice about the failed IPv6 ORPort reachability check.
See proposal 312, section 3.2.7, Guessed IPv6 Reachability Failure part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n567Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33246Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort2020-07-22T13:56:19ZteorProp 312: 3.2.7. Automatically Enable an IPv6 ORPortAfter we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only optio...After we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only options
to configure different ports for IPv4 and IPv6.
If the ORPort is auto-detected, there will not be any specific bind
address. (And the detected address may actually be on a NAT box, rather
than the local machine.) Therefore, relays should attempt to bind to all
IPv4 and IPv6 addresses (or all interfaces).
Some operating systems expect applications to bind to IPv4 and IPv6
addresses using separate API calls. Others don't support binding only to
IPv4 or IPv6, and will bind to all addresses whenever there is no specified
IP address (in a single API call). Tor should support both styles of
networking API.
In particular, if binding to all IPv6 addresses fails, relays should still
try to discover their public IPv6 address, and check the reachability of
that address. Some OSes may not support the IPV6_V6ONLY flag, but they may
instead bind to all addresses at runtime. (The tor install may also have
compile-time / runtime flag mismatches.)
See proposal 312, section 3.2.7, IPv6 ORPort part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n540
Once this ticket is implemented, we should test the different IPv4/IPv6 configs listed in legacy/trac#33235.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33245Prop 312: 3.2.6. Add an AddressDisableIPv6 torrc option2020-07-21T13:02:03ZteorProp 312: 3.2.6. Add an AddressDisableIPv6 torrc optionShould be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6...Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
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
resolution.
Currently, relays are required to have an IPv4 address. So if the guessed
IPv4 address is unsuitable, operators can set the Address option to a
suitable IPv4 address. But IPv6 addresses are optional, so relay operators
may need to disable IPv6 entirely.
We propose a new torrc-only option, AddressDisableIPv6. This option is set
to 0 by default. If the option is set to 1, tor disables IPv6 address
resolution, IPv6 ORPorts, IPv6 reachability checks, and publishing an IPv6
ORPort in its descriptor.
See proposal 312, section 3.2.6:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n498Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33244Prop 312: 3.2.5. Use IPv6 Addresses from Directory Servers2020-07-02T15:53:45ZteorProp 312: 3.2.5. Use IPv6 Addresses from Directory ServersIf relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that relays start fetching dir...If relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that relays start fetching directory documents over IPv4 and IPv6.
We propose that bridges continue to only fetch directory documents over IPv4, because they try to imitate clients. Therefore, they can't use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Tor already ignores private IPv4 addresses in directory headers. We propose
to also ignore private IPv6 addresses in directory headers. If all IPv4 and
IPv6 addresses in directory headers are private, address resolution should
return a temporary error.
Whenever address resolution fails, tor should warn the operator to set the
Address torrc option for IPv4 and IPv6. (If IPv4 is available, and only
IPv6 is missing, the log should be at notice level.) These logs may need to
be rate-limited.
Whenever tor receives a directory header containing a new public IPv4 or
IPv6 address, tor should try to use that address for reachability checks. If the
reachability checks succeed, tor should use that address in its descriptor.
See proposal 312, section 3.2.5, IPv6 address usage part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n457Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33243Prop 312: 3.2.5. Handle IPv6 Directory Fetch Failures2020-06-27T13:48:17ZteorProp 312: 3.2.5. Handle IPv6 Directory Fetch FailuresRelays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients...Relays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients. (So they can't find their IPv6 addresses in this way.)
To support this change, tor should also change how it handles IPv6
directory failures on relays:
* avoid recording IPv6 directory failures as remote relay failures,
because they may actually be due to a lack of IPv6 connectivity on the
local relay, and
* issue IPv6 directory failure logs at notice level, and rate-limit them
to one per hour.
If a relay is:
* explicitly configured with an IPv6 address, or
* a publicly routable, reachable IPv6 address is discovered in an
earlier step,
tor should start issuing IPv6 directory failure logs at warning level. Tor
may also record these directory failures as remote relay failures. (Rather
than ignoring them, as described in the previous paragraph.)
See proposal 312, section 3.2.5, IPv6 directory failure part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n457https://gitlab.torproject.org/tpo/core/tor/-/issues/33242Prop 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory Fetches2020-06-27T13:48:17ZteorProp 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory FetchesRelays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients...Relays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients. (So they can't find their IPv6 addresses in this way.)
We propose to use a simple load balancing scheme for IPv4 and IPv6
directory requests:
* choose between IPv4 and IPv6 directory requests at random.
We do not expect this change to have any load-balancing impact on the public
tor network, because the number of relays is much smaller than the number
of clients. However, the 6 directory authorities with IPv6 enabled may see
slightly more directory load, particularly over IPv6.
See proposal 312, section 3.2.5, directory fetch part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n429https://gitlab.torproject.org/tpo/core/tor/-/issues/33241Prop 312: 3.2.5. Use Directory Header IPv6 Addresses2020-07-02T15:53:44ZteorProp 312: 3.2.5. Use Directory Header IPv6 AddressesThis is a parent ticket.
If relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that...This is a parent ticket.
If relays are unable to discover their IPv6 address in any other way, they should get their IPv6 address from the X-Your-Address-Is HTTP header in tor directory documents. To support this change, we propose that relays start fetching directory documents over IPv4 and IPv6.
We propose that bridges continue to only fetch directory documents over IPv4, because they try to imitate clients. Therefore, they can't use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
See proposal 312, section 3.2.5:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n429https://gitlab.torproject.org/tpo/core/tor/-/issues/33240Prop 312: 3.2.4. Use Own Hostname IPv6 Addresses2020-06-29T11:09:37ZteorProp 312: 3.2.4. Use Own Hostname IPv6 AddressesThis ticket depends on `Address IPv6` support in legacy/trac#33233 and IPv6 resolution support in legacy/trac#33234.
If they don't have usable Address, ORPort, or interface addresses, relays (and bridges) should get their local hostname...This ticket depends on `Address IPv6` support in legacy/trac#33233 and IPv6 resolution support in legacy/trac#33234.
If they don't have usable Address, ORPort, or interface addresses, relays (and bridges) should get their local hostname, look
up its addresses, and use them as its IPv4 and IPv6 addresses.
We propose to use the same underlying lookup functions to look up the IPv4
and IPv6 addresses for:
* the Address torrc option (see section 3.2.1), and
* the local hostname.
However, OS APIs typically only return a single hostname. (Rather than a
separate hostname for IPv4 and IPv6.)
The hostname lookup should ignore private addresses on public relays. If
multiple IPv4 or IPv6 addresses are returned, the first public address from
each family should be used.
See proposal 312, section 3.2.4:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n408David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33238Prop 312: 3.2.3. Use Local Interface IPv6 Address2020-07-03T13:21:32ZteorProp 312: 3.2.3. Use Local Interface IPv6 AddressThis ticket depends on `Address IPv6` support in legacy/trac#33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as ...This ticket depends on `Address IPv6` support in legacy/trac#33233.
If they don't have usable Address or ORPort addresses, relays (and bridges) should use publicly routable addresses
from the OS interface addresses or routing table, as their IPv4 and IPv6
addresses.
Tor has local interface address resolution functions, which support most
major OSes. Tor uses these functions to guess its IPv4 address. We propose
using them to also guess tor's IPv6 address.
We also propose modifying the address resolution order, so interface
addresses are used before the local hostname. This decision is based
on our principles: interface addresses are local, trusted, and reliable;
hostname lookups may be remote, untrusted, and unreliable.
If the local interface addresses are unavailable, tor opens a UDP socket to
a publicly routable address, but doesn't actually send any packets.
Instead, it uses the socket APIs to discover the interface address for the
socket. (UDP is used because it is stateless, so the OS will not send any
packets to open a connection.)
Tor already ignores private IPv4 interface addresses on public relays. We
propose to also ignore private IPv6 interface addresses.
See proposal 312, section 3.2.1, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n359Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33236Prop 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors2020-07-07T15:02:30ZteorProp 312: 3.2.2. Use Advertised ORPort IPv4 Address in DescriptorsIf 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 ju...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#n306Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33235Prop 312: 3.2.1. Test Address torrc Option Configurations2020-07-01T20:27:30ZteorProp 312: 3.2.1. Test Address torrc Option ConfigurationsThis ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of addr...This ticket depends on IPv6 Addresses in legacy/trac#33233, and automatic IPv6 ORPorts in legacy/trac#33246. These tests should be in CI, or they should be repeated after each change.
We should support the following combinations of address literals and hostnames:
Legacy configurations:
1. (A) No configured Address option
2. (B) Address IPv4 literal
3. (C) Address hostname (use IPv4 and IPv6 DNS addresses)
New configurations:
1. (D) Address IPv6 literal
2. (E) Address IPv4 literal / Address IPv6 literal
3. (F) Address hostname / Address hostname (use IPv4 and IPv6 DNS addresses)
4. (G) Address IPv4 literal / Address hostname (only use IPv6 DNS addresses)
5. (H) Address hostname (only use IPv4 DNS addresses) / Address IPv6 literal
If we can't find an IPv4 or IPv6 address using the configured Address options:
* No IPv4: guess IPv4, and its reachability must succeed.
* No IPv6: guess IPv6, publish if reachability succeeds.
Combinations A and B are the most common legacy configurations. We want to support the following outcomes for all legacy configurations:
* automatic upgrades to guessed and reachable IPv6 addresses,
* continuing to operate on IPv4 when the IPv6 address can't be guessed, and
* continuing to operate on IPv4 when the IPv6 address has been guessed, but it is unreachable.
See proposal 312, section 3.2.1, testing notes:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n270Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33234Prop 312: 3.2.1. Make the Address torrc Option Resolve IPv6 Hostnames2020-06-27T13:48:18ZteorProp 312: 3.2.1. Make the Address torrc Option Resolve IPv6 HostnamesThis ticket depends on `Address IPv6` support in legacy/trac#33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
2. Hostnames / DNS names:
*...This ticket depends on `Address IPv6` support in legacy/trac#33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
2. Hostnames / DNS names:
* allow the option to be specified up to two times,
* look up the configured name,
* use the first IPv4 and IPv6 address returned by the resolver, and
Resolving multiple addresses in the same address family is not a
runtime error, but only the first address from each family will be
used.
These lookups should ignore private addresses on public tor networks. If
multiple IPv4 or IPv6 addresses are returned, the first public address from each family should be used.
Tor should warn if a configured Address hostname does not resolve
to any publicly routable IPv4 or IPv6 addresses. (If
tor is configured with a custom set of directory authorities, private
addresses should be allowed, with a notice-level log.)
For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory authorities only accept IPv4 or IPv6 address literals in their Address option. They must not attempt to resolve their Address using DNS. It is a config error to provide a hostname as a directory authority's Address.
See proposal 312, section 3.2.1, case 2:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n258Sponsor 55: Improving the Tor network’s IPv6 support