[tor-bugs] #33818 [Core Tor/Tor]: Add options for clients and relays to enable IPv6 extends

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Apr 15 11:49:24 UTC 2020


#33818: Add options for clients and relays to enable IPv6 extends
---------------------------+------------------------------------
 Reporter:  teor           |          Owner:  teor
     Type:  task           |         Status:  assigned
 Priority:  Medium         |      Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  ipv6, prop311  |  Actual Points:
Parent ID:  #33220         |         Points:  1
 Reviewer:                 |        Sponsor:  Sponsor55-must
---------------------------+------------------------------------

Old description:

> 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.
>
> **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

New description:

 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

--

Comment (by teor):

 Be more specific about the refactor.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33818#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list