[tor-commits] [torspec/master] Add 283: Move IPv6 ORPorts from microdescriptors to the microdesc consensus
nickm at torproject.org
nickm at torproject.org
Wed Oct 25 16:18:19 UTC 2017
commit 70911f81ea697e22ee1d10e6869349fab555946f
Author: Nick Mathewson <nickm at 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.
More information about the tor-commits
mailing list