[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