commit 70911f81ea697e22ee1d10e6869349fab555946f Author: Nick Mathewson nickm@torproject.org Date: Wed Oct 25 12:18:14 2017 -0400
Add 283: Move IPv6 ORPorts from microdescriptors to the microdesc consensus --- proposals/000-index.txt | 2 + proposals/283-ipv6-in-micro-consensus.txt | 161 ++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 8a8d22e..ded6f78 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -203,6 +203,7 @@ Proposals by number: 280 Privacy-Preserving Statistics with Privcount in Tor [DRAFT] 281 Downloading microdescriptors in bulk [DRAFT] 282 Remove "Named" and "Unnamed" handling from consensus voting [OPEN] +283 Move IPv6 ORPorts from microdescriptors to the microdesc consensus [OPEN]
Proposals by status: @@ -259,6 +260,7 @@ Proposals by status: 276 Report bandwidth with lower granularity in consensus documents [for 0.3.1.x-alpha] 277 Detect multiple relay instances running with same ID [for 0.3.??] 282 Remove "Named" and "Unnamed" handling from consensus voting [for 0.3.3.x] + 283 Move IPv6 ORPorts from microdescriptors to the microdesc consensus [for 0.3.3.x] ACCEPTED: 172 GETINFO controller option for circuit information 173 GETINFO Option Expansion diff --git a/proposals/283-ipv6-in-micro-consensus.txt b/proposals/283-ipv6-in-micro-consensus.txt new file mode 100644 index 0000000..1334844 --- /dev/null +++ b/proposals/283-ipv6-in-micro-consensus.txt @@ -0,0 +1,161 @@ +Filename: 283-ipv6-in-micro-consensus.txt +Title: Move IPv6 ORPorts from microdescriptors to the microdesc consensus +Author: Tim Wilson-Brown (teor) +Created: 18-Oct-2017 +Status: Open +Target: 0.3.3.x + +1. Summary + + Moving IPv6 ORPorts from microdescs to the microdesc consensus will make + it easier for IPv6 clients to bootstrap and select reachable guards. + + Since consensus method 14, authorities have voted for IPv6 address/port + pairs (ORPorts) in "a" lines. Unreachable IPv6 ORPorts are dropped from the + full consensus. But for clients that use microdescriptors (the default), + IPv6 ORPorts are placed in microdescriptors. So these clients can only tell + if an IPv6 ORPort is unreachable when a majority of voting authorities + mark the relay as not Running. + + This proposal puts reachable relay IPv6 ORPorts in an "a" line in the + microdesc consensus. This allows clients to discover unreachable IPv6 + ORPorts, even if a minority of voting authorities set + AuthDirHasIPv6Connectivity 1. + +2. Proposal + + We add two new consensus methods, here represented as M and N (M < N), to + be allocated when this proposal's implementation is merged. These consensus + methods move IPv6 ORPorts from microdescs to the microdesc consensus. + + We use two different methods because this allows us to modify client code + based on each method. Also, if a bug is discovered in one of the methods, + authorities can be patched to stop voting for it, and then we can implement + a fix in a later method. + +2.1. Add Reachable IPv6 ORPorts to the Microdesc Consensus + + We specify that microdescriptor consensuses created with methods M or later + contain reachable IPv6 ORPorts. + +2.2. Remove IPv6 ORPorts from Microdescriptors + + We specify that microdescriptors created with methods N or later do not + contain any IPv6 ORPorts. + +3. Retaining Existing Behaviour + + The following existing behaviour will be retained: + +3.1. Authority IPv6 Reachability + + Only authorities configured with AuthDirHasIPv6Connectivity 1 will test + IPv6 ORPort reachability, and vote for IPv6 ORPorts. + + This means that: + * if no voting authorities set AuthDirHasIPv6Connectivity 1, there will be + no IPv6 ORPorts in the consensus, + * if a minority of voting authorities set AuthDirHasIPv6Connectivity 1, + unreachable IPv6 ORPort lines will be dropped from the consensus, but the + relay will still be listed as Running, + * if a majority of voting authorities set AuthDirHasIPv6Connectivity 1, + relays with unreachable IPv6 ORPorts will be dropped from the consensus. + + We will document this behaviour in the tor manual page, see #23870. + +3.2. Full Consensus IPv6 ORPorts + + The full consensus will continue to contain reachable IPv6 ORPorts. + +3.3. Clients that use Full Descriptors + + Tor clients that use full descriptors already ignore unreachable IPv6 + ORPorts, and have done so since at least 0.2.8.x. + +4. Impact and Related Changes + +4.1. Directory Authority Configuration + + We will work to get a super-majority (75%) of authorities checking relay + IPv6 reachability, to avoid Running-flag flapping. To do this, authorities + need to get IPv6 connectivity, and set AuthDirHasIPv6Connectivity 1. + +4.2. Relays and Bridges + + Tor relays and bridges do not currently use IPv6 ORPorts from the + consensus. + + We expect that 2/3 of authorities will be voting for consensus method N + before future Tor relay or bridge versions use IPv6 ORPorts from the + consensus. + +4.3. Clients + +4.3.1. Legacy Clients + +4.3.1.1. IPv6 ORPort Circuits + + Tor clients on versions 0.2.8.x to 0.3.2.x check directory documents for + ORPorts in the following order: + * descriptors (routerinfo, available if using bridges or full descriptors) + * consensus (routerstatus) + * microdescriptors (IPv6 ORPorts only) + + Their behaviour will be identical to the current behaviour for consensus + methods M and earlier. When consensus method N is used, they will ignore + unreachable IPv6 ORPorts without any code changes. + +4.3.1.2. IPv6 ORPort Bootstrap + + Tor clients on versions 0.2.8.x and 0.2.9.x are currently unable to + bootstrap over IPv6 only connections when using microdescriptors. This + happens because the microdesc consensus does not contain IPv6 ORPorts. + + When consensus method M is used, they will be able to bootstrap over IPv6 + only connections using microdescriptors, without any code changes. + +4.3.2. Future Clients + +4.3.2.1. Ignoring IPv6 ORPorts in Microdescs + + Tor clients on versions 0.3.3.x and later will ignore unreachable IPv6 + ORPorts once consensus method M or later is in use. (See #23827.) + +4.3.2.2. IPv6 ORPort Bootstrap + + If a bootstrapping IPv6-only client has a consensus made with method M or + later, it should download microdescriptors from one of the IPv6 ORPorts in + that consensus. Previously, IPv6-only clients would use fallback directory + mirrors to download microdescs, because there were no IPv6 ORPorts in the + microdesc consensus. (See #23827.) + +4.3.2.3. Ignoring Addresses in Unused Directory Documents + + If a client doesn't use a particular directory document type for a node, + it should ignore any addresses in that document type. (See #23975.) + +5. Data Size + + This change removes 2-50 bytes from the microdescriptors of relays that + have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc + consensus entries. + + As of October 2017, 600 relays (9%) have IPv6 ORPorts in the full + consensus. Their "a" lines take up 19 KB, or 33 bytes each on average. + The microdesc consensus is 1981 KB, so this represents about 1% of its + uncompressed size. + + Most tor clients are already running 0.3.1.7, which implements consensus + diffs. We expect that most directory mirrors will also implement consensus + diffs by the time 2/3 of authorities are voting for consensus method M. + + So we expect that this change will have a minimal impact, which is made + even smaller by compression and consensus diffs. + +6. External Impacts + + We don't expect this change to impact Onionoo and similar projects, because + they typically use the full consensus. + + Metrics doesn't currently graph IPv6 usage in Tor, but would like to in + future.