Proposal: Put Relay IPv6 Addresses in the microdesc consensus
The relay wedostor is bound to an unreachable IPv6 address. https://atlas.torproject.org/#details/F70B7C5CD72D74C7F9F2DC84FA9D20D51BA13610 (Atlas shows no IPv6 address.)
It advertises the IPv6 address in its descriptor: http://46.28.109.231:9030/tor/server/authority
The full consensus has no IPv6 address: http://collector.torproject.org/recent/relay-descriptors/consensuses/2016-12-07-11-00-00-consensus
But the microdesc does have the IPv6 address: http://46.28.109.231:9030/tor/micro/d/Z7YTOuC8gXcelqDlUhpsvaTPLp04QhyEXvOWo1inWj8
And strangely, no client I have access to seems to download this microdescriptor. Maybe it registers as invalid somehow?
A fix to this will require a new consensus method.
Activity
changed milestone to %Tor: unspecified
Here is the relevant microdesc consensus: https://collector.torproject.org/recent/relay-descriptors/microdescs/consensus-microdesc/2016-12-07-11-00-00-consensus-microdesc
I really do think we should have put the 'a' line in the microdesc consensus instead of the microdescriptor. But it's too late for that now.
A Diversion
My branch bug20916 contains exactly the wrong solution to this problem: I made the microdescriptor change based on the authority's reachability for the IPv6 address.
A Complex Solution
One way to fix this issue is to:
- define a flag UnreachableIPv6,
- have authorities vote for it if AuthDirHasIPv6Connectivity is set and they are sure the relay is unreachable,
- produce a consensus based on the majority view from authorities that know the UnreachableIPv6 flag, and then
- have clients ignore the IPv6 address in the 'a' line if UnreachableIPv6 is present.
There are 3 possible states for authorities with AuthDirHasIPv6Connectivity set:
- reachable: put the IPv6 address in the vote,
- unknown: the authority hasn't been up for enough time to determine reachability: no address, no flag in the vote,
- unreachable: put the UnreachableIPv6 in the vote.
There is 1 possible state for authorities without AuthDirHasIPv6Connectivity set:
- unknown: the authority doesn't have IPv6: no address, no flag.
So the consensus rules become rather complicated. Let's try something simpler.
A Simpler Solution
Another way to fix this issue is to:
- define a flag NoIPv6Consensus,
- have authorities vote for IPv6 addresses as normal,
- have authorities know the NoIPv6Consensus flag when they have been up for long enough to determine IPv6 reachability,
- produce a consensus on NoIPv6Consensus based on a majority IPv6 address votes from authorities that know the NoIPv6Consensus flag, and then
- have clients ignore the IPv6 address in the 'a' line if NoIPv6Consensus is present.
There are 2 possible states for authorities with AuthDirHasIPv6Connectivity set:
- reachable: know the NoIPv6Consensus flag in the vote,
- unreachable: the authority hasn't been up for enough time to determine reachability: don't know the NoIPv6Consensus flag in the vote, and in any case, vote for IPv6 addresses as normal,
There is 1 possible state for authorities without AuthDirHasIPv6Connectivity set:
- unknown: the authority doesn't have IPv6: don't know the NoIPv6Consensus flag in the vote, and don't vote for any IPv6 addresses.
The consensus for IPv6 votes becomes:
- if a majority of authorities that know the NoIPv6Consensus flag agree on the IPv6 address, put the IPv6 address in the full consensus,
- otherwise, put the NoIPv6Consensus flag in all consensus flavours, leave the IPv6 address out of the full consensus, and clients should ignore the IPv6 address in descriptors and microdescriptors.
Replying to teor:
I really do think we should have put the 'a' line in the microdesc consensus instead of the microdescriptor. But it's too late for that now.
This isn't true: we can define a new consensus method that includes 'a' lines in the microdesc consensus. Then, when all clients have updated, we can remove 'a' lines from microdescriptors.
This also makes it easier for IPv6 clients to bootstrap, and makes happy-eyeballs-style IPv6 detection possible.
We'll need a short proposal for this explaining why it will work (and why it gets better once we have consensus diffs).
One decision will be:
- do we move IPv6 addresses from the microdesc to microconsensus in one consensus method?
- (clients will be fine, back to 0.2.8 where we made IPv6 from the consensus work)
- or, do we have one method to add them to the microconsensus, and another to remove them from the microdesc in a later release?
(The staged option seems much more sensible, but maybe we could make them N & N+1 in the same release, in case we need to run with both for a while due to an unexpected bug.)
Some tools and external code might need to adapt. But much external code uses the full consensus anyway.
Trac:
Keywords: N/A deleted, needs-proposal added
Owner: N/A to teor
Status: new to assignedOnce #23975 (moved) and #24573 (moved) close, we are done here. We can close this ticket after marking prop#283 as "Closed". (The spec changes have already been merged as part of #23898 (moved).)
Trac:
Keywords: needs-proposal deleted, prop283 added
Sponsor: N/A to SponsorV-can
Type: defect to taskWe just made our first consensus with consensus method 28 in the test network. The microdesc consensus has IPv6 addresses, the (new) microdescs do not, and everything kept working. So it looks like the new consensus methods are ok.
I still need to revise the last child ticket, and then we can close this ticket.
