<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 24, 2017 at 11:35 PM, teor <span dir="ltr"><<a href="mailto:teor2345@gmail.com" target="_blank">teor2345@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
We would like to move IPv6 ORPorts from microdescriptors to the<br>
microdesc consensus. This makes it easier for IPv6 clients to bootstrap<br>
and choose reachable guards.<br>
<br>
The proposal is inlined below, it is also available with the corresponding<br>
dir-spec updates in my torspec branch bug23826-23828 on GitHub:<br>
<br>
<a href="https://github.com/teor2345/torspec.git" rel="noreferrer" target="_blank">https://github.com/teor2345/<wbr>torspec.git</a><br>
<br>
The tor code that implements these new consensus methods is in my tor<br>
branch on bug23826-23828 on GitHub:<br>
<br>
<a href="https://github.com/teor2345/tor.git" rel="noreferrer" target="_blank">https://github.com/teor2345/<wbr>tor.git</a><br>
<br>
The parent ticket for these related changes is #20916. The code changes are<br>
being tracked in #23826 and #23828, and the spec changes and proposal in<br>
#23898:<br>
<br>
<a href="https://trac.torproject.org/projects/tor/ticket/20916" rel="noreferrer" target="_blank">https://trac.torproject.org/<wbr>projects/tor/ticket/20916</a><br>
<br>
If we've spoken about this, and I've left you out as an author, please let<br>
me know!<br></blockquote><div><br></div><div><br></div><div>Hi, Tim! I promised you a quick review here, so here goes. I have some questions, but nothing looks like a showstopper here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is the proposal text:<br>
<br>
Filename: xxx-ipv6-in-micro-consensus.<wbr>txt<br>
Title: Move IPv6 ORPorts from microdescriptors to the microdesc consensus<br>
Author: Tim Wilson-Brown (teor)<br>
Created: 18-Oct-2017<br>
Status: Open<br>
Target: 0.3.3.x<br>
<br>
1. Summary<br>
<br>
Moving IPv6 ORPorts from microdescs to the microdesc consensus will make<br>
it easier for IPv6 clients to bootstrap and select reachable guards.<br>
<br>
Since consensus method 14, authorities have voted for IPv6 address/port<br>
pairs (ORPorts) in "a" lines. Unreachable IPv6 ORPorts are dropped from the<br>
full consensus. But for clients that use microdescriptors (the default),<br>
IPv6 ORPorts are placed in microdescriptors. So these clients can only tell<br>
if an IPv6 ORPort is unreachable when a majority of voting authorities<br>
mark the relay as not Running.<br>
<br>
This proposal puts reachable relay IPv6 ORPorts in an "a" line in the<br>
microdesc consensus. This allows clients to discover unreachable IPv6<br>
ORPorts, even if a minority of voting authorities set<br>
AuthDirHasIPv6Connectivity 1.<br></blockquote><div><br></div><div>To me, this motivation makes a little less sense than the bootstrapping improvements in 4.3 do. Don't get me wrong: it's cool that we can get IPv6 online-ness detection "for free" on existing clients... but there are other ways we could IPv6 online-status advertising too (like a status flag, or conditionally omitting "a" lines from microdescriptors, or something else).</div><div><br></div><div>But the bootstrapping considerations discussed in 4.3 below are something we really _can't_ do without moving the "a" lines into the consensus. So to my mind, that's the major reason we should do this.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Proposal<br>
<br>
We add two new consensus methods, here represented as M and N (M < N), to<br>
be allocated when this proposal's implementation is merged. These consensus<br>
methods move IPv6 ORPorts from microdescs to the microdesc consensus.<br>
<br>
We use two different methods because this allows us to modify client code<br>
based on each method. Also, if a bug is discovered in one of the methods,<br>
authorities can be patched to stop voting for it, and then we can implement<br>
a fix in a later method.<br>
<br>
2.1. Add Reachable IPv6 ORPorts to the Microdesc Consensus<br>
<br>
We specify that microdescriptor consensuses created with methods M or later<br>
contain reachable IPv6 ORPorts.<br>
<br>
2.2. Remove IPv6 ORPorts from Microdescriptors<br>
<br>
We specify that microdescriptors created with methods N or later do not<br>
contain any IPv6 ORPorts.<br></blockquote><div><br></div><div>Let's say that with method N, we start omitting them. Let's not say that we commit to omitting them forever. Perhaps we will someday have a reason to put more "a" lines in microdescriptors again.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Retaining Existing Behaviour<br>
<br>
The following existing behaviour will be retained:<br>
<br>
3.1. Authority IPv6 Reachability<br>
<br>
Only authorities configured with AuthDirHasIPv6Connectivity 1 will test<br>
IPv6 ORPort reachability, and vote for IPv6 ORPorts.<br>
<br>
This means that:<br>
* if no voting authorities set AuthDirHasIPv6Connectivity 1, there will be<br>
no IPv6 ORPorts in the consensus,<br>
* if a minority of voting authorities set AuthDirHasIPv6Connectivity 1,<br>
unreachable IPv6 ORPort lines will be dropped from the consensus, but the<br>
relay will still be listed as Running,<br>
* if a majority of voting authorities set AuthDirHasIPv6Connectivity 1,<br>
relays with unreachable IPv6 ORPorts will be dropped from the consensus.<br>
<br>
We will document this behaviour in the tor manual page, see #23870.</blockquote><div><br></div><div>So, there's an alternative here: we could let the HasIPV6 authorities vote on a flag to indicate "reachable/unreachable with IPv6," and let all the authorities vote on the "a" lines. Then, in the consensus, we could omit the "a" lines unless the router has the reachable-with-ipv6 flag; and include them otherwise.</div><div><br></div><div>This way, we wouldn't need to have a majority of IPv6 authorities in order to have meaningful "a" lines that tell you whether the router is reachable. (But of course, the more we had, the more reliable the information would be.)</div><div><br></div><div>This change could be done as part of consensus method M, I think. Do you think it's worthwhile?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.2. Full Consensus IPv6 ORPorts<br>
<br>
The full consensus will continue to contain reachable IPv6 ORPorts.<br></blockquote><div><br></div><div>By "full" consensus, do you mean "NS" consensus? I don't think we use "full" elsewhere.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3.3. Clients that use Full Descriptors<br>
<br>
Tor clients that use full descriptors already ignore unreachable IPv6<br>
ORPorts, and have done so since at least 0.2.8.x.<br></blockquote><div><br></div><div>Wow. I'd forgotten this. How does this work?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Impact and Related Changes<br>
<br>
4.1. Directory Authority Configuration<br>
<br>
We will work to get a super-majority (75%) of authorities checking relay<br>
IPv6 reachability, to avoid Running-flag flapping. To do this, authorities<br>
need to get IPv6 connectivity, and set AuthDirHasIPv6Connectivity 1.<br></blockquote><div><br></div><div>How far away are we from this today? How long do the authority operators think it would take?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4.2. Relays and Bridges<br>
<br>
Tor relays and bridges do not currently use IPv6 ORPorts from the<br>
consensus.<br>
<br>
We expect that 2/3 of authorities will be voting for consensus method N<br>
before future Tor relay or bridge versions use IPv6 ORPorts from the<br>
consensus.<br>
<br>
4.3. Clients<br>
<br>
4.3.1. Legacy Clients<br>
<br>
4.3.1.1. IPv6 ORPort Circuits<br>
<br>
Tor clients on versions 0.2.8.x to 0.3.2.x check directory documents for<br>
ORPorts in the following order:<br>
* descriptors (routerinfo, available if using bridges or full descriptors)<br>
* consensus (routerstatus)<br>
* microdescriptors (IPv6 ORPorts only)<br>
<br>
Their behaviour will be identical to the current behaviour for consensus<br>
methods M and earlier. When consensus method N is used, they will ignore<br>
unreachable IPv6 ORPorts without any code changes.<br>
<br>
4.3.1.2. IPv6 ORPort Bootstrap<br>
<br>
Tor clients on versions 0.2.8.x and 0.2.9.x are currently unable to<br>
bootstrap over IPv6 only connections when using microdescriptors. This<br>
happens because the microdesc consensus does not contain IPv6 ORPorts.<br>
<br>
When consensus method M is used, they will be able to bootstrap over IPv6<br>
only connections using microdescriptors, without any code changes.<br></blockquote><div><br></div><div>(How does the behavior of 0.3.0.x and onward differ here?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4.3.2. Future Clients<br>
<br>
4.3.2.1. Ignoring IPv6 ORPorts in Microdescs<br>
<br>
Tor clients on versions 0.3.3.x and later will ignore unreachable IPv6<br>
ORPorts once consensus method M or later is in use. (See #23827.)<br>
<br>
4.3.2.2. IPv6 ORPort Bootstrap<br>
<br>
If a bootstrapping IPv6-only client has a consensus made with method M or<br>
later, it should download microdescriptors from one of the IPv6 ORPorts in<br>
that consensus. Previously, IPv6-only clients would use fallback directory<br>
mirrors to download microdescs, because there were no IPv6 ORPorts in the<br>
microdesc consensus. (See #23827.)<br>
<br>
4.3.2.3. Ignoring Addresses in Unused Directory Documents<br>
<br>
If a client doesn't use a particular directory document type for a node,<br>
it should ignore any addresses in that document type. (See #23975.)<br>
<br>
5. Data Size<br>
<br>
This change removes 2-50 bytes from the microdescriptors of relays that<br>
have an IPv6 ORPort, and adds them to reachable IPv6 relays' microdesc<br>
consensus entries.<br>
<br>
As of October 2017, 600 relays (9%) have IPv6 ORPorts in the full<br>
consensus. Their "a" lines take up 19 KB, or 33 bytes each on average.<br>
The microdesc consensus is 1981 KB, so this represents about 1% of its<br>
uncompressed size.<br>
<br>
Most tor clients are already running 0.3.1.7, which implements consensus<br>
diffs. We expect that most directory mirrors will also implement consensus<br>
diffs by the time 2/3 of authorities are voting for consensus method M.<br>
<br>
So we expect that this change will have a minimal impact, which is made<br>
even smaller by compression and consensus diffs.<br></blockquote><div><br></div><div>Let's look at a worst-case analysis, though. How would the impact be if 100% of the relays had IPv6 ORPorts? I'm not very interested in the uncompressed size; it's the gzip-compressed size that determines the worst-case impact.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
6. External Impacts<br>
<br>
We don't expect this change to impact Onionoo and similar projects, because<br>
they typically use the full consensus.<br>
<br>
Metrics doesn't currently graph IPv6 usage in Tor, but would like to in<br>
future.<br>
<br>
<br>
--<br>
Tim / teor<br>
<br>
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B<br>
ricochet:ekmygaiu4rzgsk6n<br>
------------------------------<wbr>------------------------------<wbr>------------<br>
<br>
<br>______________________________<wbr>_________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/<wbr>cgi-bin/mailman/listinfo/tor-<wbr>dev</a><br>
<br></blockquote></div><br></div></div>