Opened 2 years ago

Closed 6 months ago

#20916 closed task (fixed)

Proposal: Put Relay IPv6 Addresses in the microdesc consensus

Reported by: teor Owned by: teor
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: prop283, ipv6, regression, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor: SponsorV-can

Description

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.

Child Tickets

TicketStatusOwnerSummaryComponent
#19990closedteorEntryNodes is incompatible with IPv6-only bootstrapCore Tor/Tor
#23826closedteorAuthorities: Put Relay IPv6 addresses in the microdesc consensusCore Tor/Tor
#23827closedteorClients/Relays: Use IPv6 Addresses from microdesc consensusCore Tor/Tor
#23828closedteorAuthorities: Remove IPv6 addresses from microdescriptorsCore Tor/Tor
#23898closedteortor-spec: move IPv6 addresses from microdescs to microdesc consensusCore Tor/Tor
#24573closedrewrite_node_address_for_bridge() should set IPv6 preferences even if there is no riCore Tor/Tor
#24778closedteorMark prop#283 as AcceptedCore Tor/Tor
#25213closednickm0.3.3.2-alpha - Non-fatal assertion !(node_awaiting_ipv6(get_options(), node)) failed.Core Tor/Tor

Change History (22)

comment:1 Changed 2 years ago by teor

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.

comment:2 Changed 2 years ago by dgoulet

Keywords: triage-out-030-201612 added
Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

Triaged out on December 2016 from 030 to 031.

comment:3 in reply to:  1 Changed 2 years ago by teor

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.

comment:4 Changed 23 months ago by teor

Keywords: needs-proposal added
Owner: set to teor
Status: newassigned

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.

comment:5 Changed 21 months ago by teor

Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

I will not be fixing this in 0.3.1, but I intend to fix it when I have more time.

comment:6 Changed 20 months ago by nickm

Keywords: triage-out-030-201612 removed

comment:7 Changed 17 months ago by teor

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

I'm not going to get time to do these in 0.3.2.
Moving them to 0.3.3.

comment:8 Changed 16 months ago by teor

Summary: Inconsistent IPv6 address between consensus and microdescriptorProposal: Put Relay IPv6 Addresses in the microdesc consensus

comment:9 Changed 15 months ago by teor

Status: assignedneeds_revision

Please see my branch bug20916-v2, which moves the IPv6 address from the microdescriptor to the microdesc consensus.

This needs:

  • a proposal
  • a dir-spec patch
  • a changes file
  • authority changes
  • relay changes

comment:10 in reply to:  9 Changed 15 months ago by teor

This now needs:

  • a proposal
  • a dir-spec patch
  • a changes file

comment:11 Changed 15 months ago by teor

Please see my tor branch bug20916-v3 and my torspec branch bug20916, which now need:

  • a changes file
  • unit tests fixes
  • send the proposal to tor-dev for review

comment:12 Changed 15 months ago by teor

(Also, some related fixes need to be split out into separate tickets)

comment:13 Changed 15 months ago by teor

Status: needs_revisionnew

This is now a parent ticket, we're tracking all the changes in child tickets.

comment:14 Changed 13 months ago by teor

Keywords: prop283 added; needs-proposal removed
Sponsor: SponsorV-can
Type: defecttask

Once #23975 and #24573 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.)

comment:15 Changed 12 months ago by teor

We 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.

comment:16 Changed 12 months ago by nickm

Status: newassigned

comment:17 Changed 12 months ago by teor

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

The 0.3.3 feature freeze deadline has passed. We can do the remaining work in this ticket in 0.3.4. (The old code works, so deferring it is ok.)

comment:18 Changed 11 months ago by teor

Status: assignedneeds_revision

comment:19 Changed 10 months ago by nickm

Keywords: 034-triage-20180328 added

comment:20 Changed 10 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:21 Changed 10 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These needs_revision, tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if somebody does the necessary revision.

comment:22 Changed 6 months ago by teor

Resolution: fixed
Status: needs_revisionclosed

Fixed except for #23975

Note: See TracTickets for help on using tickets.