Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:12Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33249Prop 312: 4. Update Directory Spec for IPv6 X-Your-Address-Is2020-06-13T15:51:12ZteorProp 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/legacy/trac/-/issues/33244Prop 312: 3.2.5. Use IPv6 Addresses from Directory Servers2020-06-13T15:51:09ZteorProp 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#n457https://gitlab.torproject.org/legacy/trac/-/issues/33243Prop 312: 3.2.5. Handle IPv6 Directory Fetch Failures2020-06-13T15:51:08ZteorProp 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/legacy/trac/-/issues/33242Prop 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory Fetches2020-06-13T15:51:08ZteorProp 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#n429