Opened 7 months ago

Last modified 4 months ago

#33818 assigned task

Add options for clients and relays to enable IPv6 extends

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, prop311, 044-deferred
Cc: Actual Points:
Parent ID: #33819 Points: 1
Reviewer: Sponsor: Sponsor55-can

Description (last modified by teor)

To help with testing and future network upgrades, we want to add options that:

  • make clients and relays send IPv6 addresses in extend cells, and
  • make relays perform extends over IPv6.

We also want to refactor the changes from #33817, so that we perform all the IPv6 mode checks in the same place. We want to modify tor's behaviour based on:

  • tor's configuration
    • including consensus parameters
  • the reachability of a relay's own IPv6 ORPort, and
  • any other relevant factors.

The functions that need to be refactored should all be in circuitbuild_relay.c.

We don't need to refactor or add IPv6 mode checks to the changes in #33899 or #33901. That includes these functions:

  • connection_or_check_canonicity()
  • channel_tls_process_netinfo_cell()
  • channel_get_for_extend()
  • check_extend_cell()
  • extend_cell_from_extend2_cell_body()

But we might want to change how we *call* these functions from other code.

General Options

ExtendByIPv6ORPort (like ExtendByEd25519ID):

If this option is set to 1, Tor tries to include a relay’s IPv6 ORPort when telling the preceding relay in a circuit to extend to it. When IPv6 extends are enabled, relays and bridges use them to perform IPv6 reachability self-tests. Once these tests succeed, they publish their descriptors. (See AssumeReachable for more details.)

If this option is set to 0, Tor never includes an IPv6 ORPort when extending circuits. Tor relays and bridges are unable to perform IPv6 reachability self-tests.

If the option is set to "auto", Tor obeys a parameter in the consensus document. If the consensus parameter is not set:

  • relays include IPv6 ORPorts in extend cells,
  • bridges only include IPv6 ORPorts in the final extend in reachability self-test circuits,
  • clients do not include IPv6 ORPorts in extend cells.

(Default: auto)

Note: there's a design tradeoff here:

  • Gradual IPv6 upgrade:
    • we can have 3 different behaviours:
      • relay always sends IPv6
      • bridge sends IPv6 on reachability
      • client never sends IPv6
    • and do a gradual IPv6 upgrade:
      • stage 1: relay all, bridge reachability
      • stage 2: relay, bridge, client all; or
  • Big Bang IPv6 upgrade:
    • we can have 2 different behaviours:
      • relay, bridge sends IPv6 on reachability
      • client never sends IPv6
    • and do a big bang IPv6 upgrade:
      • stage 1: relay and bridge reachability,
      • stage 2: relay, bridge, client all

I think the gradual upgrade is less risky for the network, and the complexity of the extra code, behaviour, and testing is manageable.

Relay and Bridge Options

ExtendAllowIPv6Addresses (like ExtendAllowPrivateAddresses):

Relays and bridges only.

When this option is set to 1, Tor relays and bridges allow EXTEND requests to IPv6 addresses. When IPv6 extends are enabled in their own configurations, relays and bridges assume that other relays in the network will also allow IPv6 extends. So they perform IPv6 reachability self-tests, before publishing their descriptors. (See AssumeReachable for more details.)

This option does not apply to clients, or direct OR connections initiated by relays or bridges. Use ClientUseIPv6 and ClientPreferIPv6ORPort to enable direct IPv6 OR connections.

If this option is set to 0, Tor relays and bridges do not connect to IPv6 ORPorts when extending circuits. When IPv6 extends are disabled, relays and bridges assume that other relays in the network may also refuse IPv6 extends. So they continue to perform IPv6 reachability self-tests, but consider them unreliable. They publish their descriptors, regardless of the outcome of the tests.

If the option is set to "auto", Tor obeys a parameter in the consensus document. If the consensus parameter is not set:

  • relays allow IPv6 extends,
  • bridges do not allow IPv6 extends, and
  • relays and bridges perform IPv6 reachability self-tests, before publishing their descriptors.

(Default: auto)

Proposal Notes

The design and option names are changed from section 4.4.4 of proposal 311, for the following reasons:

  • consistent, safer design for ExtendByIPv6ORPort:
    • relay reachability and other cells can't be distinguished
    • relays include IPv6 first, because they don't require anonymity
    • clients wait for deployment, before including IPv6 on a flag day
    • bridges match clients
  • ExtendAllowIPv6Addresses can wait for clients to learn IPv6
  • consistency with existing options
  • AssumeIPv6Reachable is no longer required, it is obsoleted by:
    • AssumeReachable 1 (skip IPv4 and IPv6 reachability)
    • ExtendByIPv6ORPort 0 (skip IPv6 reachability)
    • ExtendAllowIPv6Addresses 0 (only log IPv6 reachability)

See:
https://github.com/torproject/torspec/blob/master/proposals/311-relay-ipv6-reachability.txt#L535

Child Tickets

Change History (7)

comment:1 Changed 7 months ago by teor

Description: modified (diff)

Describe options and reachability behaviour.

comment:2 Changed 7 months ago by teor

Description: modified (diff)

More design notes

comment:3 Changed 6 months ago by teor

Description: modified (diff)

Move refactor from #33817 to this ticket.

comment:4 Changed 6 months ago by teor

Description: modified (diff)

Be more specific about the refactor.

comment:5 Changed 6 months ago by teor

Owner: teor deleted
Sponsor: Sponsor55-mustSponsor55-can

I don't think these options are an essential part of Sponsor 55.

We can test the extend code using the reachability self-test code.

comment:6 Changed 6 months ago by teor

Parent ID: #33220#33819

comment:7 Changed 4 months 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.

Note: See TracTickets for help on using tickets.