Prop 311: 4.2. Implement IPv6 ORPort Reachability Self-Tests

4.2. Checking IPv6 ORPort Reachability

We propose that testing relays (and bridges) select some IPv6 extend-capable relays for their reachability circuits, and include their own IPv4 and IPv6 ORPorts in the final extend cells on those circuits.

The final extending relay will extend to the testing relay:

• using an existing authenticated connection to the testing relay (which may be over IPv4 or IPv6), or
• over a new connection via the IPv4 or IPv6 ORPort in the extend cell.

The testing relay will confirm that test circuits can extend to both its IPv4 and IPv6 ORPorts.

4.2.1. Selecting the Final Extending Relay

IPv6 ORPort reachability checks require an IPv6 extend-capable relay as the second-last hop of reachability circuits. (The testing relay is the last hop.)

IPv6-extend capable relays must have:

• Relay subprotocol version 3 (or later), and
• an IPv6 ORPort. (See section 5.1 for the definition of Relay subprotocol version 3.)

The other relays in the path do not require any particular protocol versions.

4.2.2. Extending from the Second-Last Hop

IPv6 ORPort reachability circuits should put the IPv4 and IPv6 ORPorts in the extend cell for the final extend in reachability circuits.

Supplying both ORPorts makes these extend cells indistinguishable from future client extend cells.

If reachability succeeds, the testing relay (or bridge) will accept the final extend on one of its ORPorts, selected at random by the extending relay (see section 3.2.1).

4.2.3. Separate IPv4 and IPv6 Reachability Flags

Testing relays (and bridges) will record reachability separately for IPv4 and IPv6 ORPorts, based on the ORPort that the test circuit was received on.

Here is a reliable way to do reachability self-tests for each ORPort:

1. Check for create cells on inbound ORPort connections from other relays

Check for a cell on any IPv4 and any IPv6 ORPort. (We can't know which listener(s) correspond to the advertised ORPorts, particularly when using port forwarding.) Make sure the cell was received on an inbound OR connection, that is authenticated to another relay.

2. Check for created cells from testing circuits on outbound OR connections

Check for a returned created cell on our IPv4 and IPv6 self-test circuits. Make sure those circuits were on outbound OR connections.

By combining these tests, we confirm that we can:

• reach our own ORPorts with testing circuits
• send and receive cells via inbound OR connections from other relays to our own ORPorts
• send and receive cells via outbound OR connections to other relays' ORPorts

This isn't a perfect test, there are a few false positives:

• relays with multiple IPv4 or IPv6 ORPorts, where only some ports are reachable:
  • (this configuration is uncommon, but multiple ORPorts are supported)
  • the final extend cell contains the advertised IPv6 address of the self-testing relay
  • if the extending relay already has a connection to an old but working ORPort, it may use that connection instead
  • so these tests can pass, even when the advertised ORPort is unreachable
• relays whose keys have been copied from another relay in the consensus, for similar reasons
  • this configuration is rare and unsupported

From proposal 311, section 4.2: https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n283