DirAuths that have IPv6 addresses don't include them in their vote on themself

changed milestone to %Tor: 0.4.1.x-final

added 034-removed-20180328 034-triage-20180328 asn-merge component::core tor/tor easy intro milestone::Tor: 0.4.1.x-final owner::neel parent::24403 points::1 priority::medium resolution::fixed reviewer::nickm severity::normal sponsor::V-can status::closed tor-dirauth type::defect version::tor 0.2.4.1-alpha labels

Authorities should assume their configured IPv6 address is reachable, just like they do for IPv4.

Also strange: dannenberg votes on ReachableIPv6 but is not itself granted ReachableIPv6

That's not surprising: voting on ReachableIPv6 requires outbound IPv6 connectivity (like IPv6Exit). But receiving ReachableIPv6 requires inbound connectivity to an IPv6 ORPort. Does it declare one in its descriptor?

If it does, I'll email the dirauth list to let them know there's a misconfiguration, because it could end up with dannenberg not being marked Running,

Trac:
Points: N/A to 1
Sponsor: N/A to SponsorV-can
Keywords: N/A deleted, IPv6, tor-dirauth added
Parent: N/A to #20916 (moved)
Milestone: N/A to Tor: 0.3.3.x-final

dannenberg does not have an IPv6 ORPort in its descriptor, so this is the expected behaviour:

http://193.23.244.244/tor/server/authority

But we still need to fix the underlying bug:

if an authority has AuthDirHasIPv6Connectivity set, and
it has an IPv6 ORPort,
it should assume it's own IPv6 ORPort is reachable and vote for it

This is what all authorities do with their own Running flag (which represents IPv4 and IPv6 ORPort reachability).

Trac:
Keywords: N/A deleted, intro, easy added

I think this is a feature, not a bug.

If an authority votes for its own IPv6 address, and it's the only one to do this, then its IPv6 address will always be in the consensus, even if it's actually unreachable. (A single IPv6-voting authority can determine an IPv6 address by voting for it.)

When we make IPv6 mandatory on authorities, and change the consensus method so IPv6 votes are a simple majority, then we can fix this issue.

Trac:
Sponsor: SponsorV-can to N/A
Milestone: Tor: 0.3.3.x-final to Tor: very long term
Keywords: IPv6 deleted, needs-mandatory-IPv6 added

Hang on, we will need authorities to unconditionally advertise their own IPv6 address.

When we implement relay IPv6 reachability checks, relays in a new network will need IPv6 addresses to bootstrap off.

If an authority votes for its own IPv6 address, and it's the only one to do this, then its IPv6 address will always be in the consensus, even if it's actually unreachable. (A single IPv6-voting authority can determine an IPv6 address by voting for it.)

This is ok, because if we have a majority of authorities on IPv6 (that doesn't include that authority), that authority won't be marked Running, and its operator will notice.

Also, we should do reachability checks on authority IPv6 addresses, but just warn if they fail. This is what we do for authority IPv4 addresses.

Trac:
Milestone: Tor: very long term to Tor: 0.3.3.x-final
Parent: #20916 (moved) to N/A

Trac:
Parent: N/A to #24403 (moved)
Keywords: needs-mandatory-IPv6 deleted, N/A added

Here's what we need to do to fix this bug:

If an authority has an IPv6 ORPort, it should assume its own IPv6 ORPort is reachable, and vote for it. This is what authorities do for their own Reachable flag, so we should be able to use the same code for this fix.

Trac:
Sponsor: N/A to SponsorV-can

The 0.3.3 freeze deadline has passed, all these children of #24403 (moved) belong in 0.3.4

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

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

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

Trac:
Status: new to assigned
Cc: teor to teor, neel
Owner: N/A to neel

Is the function dirserv_set_router_is_running() the function where a dirauth would set itself as running (e.g. the "Reachable" flag)?

I have a PR here: https://github.com/torproject/tor/pull/698

I am not sure whether or not it is correct, but here it is.

Trac:
Milestone: Tor: unspecified to Tor: 0.4.1.x-final
Status: assigned to needs_review

Trac:
Reviewer: N/A to nickm

Hi! I'd suggest that instead of overriding the last_reachable6 flag in node, we should override the place where we assign the ipv6_addr in the routerstatus:

  if (options->AuthDirHasIPv6Connectivity == 1 &&
      !tor_addr_is_null(&ri->ipv6_addr) &&
      node->last_reachable6 >= now - REACHABLE_TIMEOUT) {
    /* We're configured as having IPv6 connectivity. There's an IPv6
       OR port and it's reachable so copy it to the routerstatus.  */
    tor_addr_copy(&rs->ipv6_addr, &ri->ipv6_addr);
    rs->ipv6_orport = ri->ipv6_orport;

(in set_routerstatus_from_routerinfo())

Instead of checking whether last_reachable6 is recent, we could check whether it is recent OR the router is ourself.

Note that I think this change will make the test expression above way too complicated, and we should extract it into its own function, maybe called something like should_publish_node_ipv6().

Trac:
Status: needs_review to needs_revision

I made the changes and pushed them.

Trac:
Status: needs_revision to needs_review

Yes; this looks great. Thanks!

Trac:
Status: needs_review to merge_ready

Trac:
Keywords: N/A deleted, asn-merge added

Merged to master!

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

The changes file for this release said "bugfix on 0.4.0.1-alpha". I fixed it in the ChangeLog and ReleaseNotes in #31461 (moved).

Trac:
Version: N/A to Tor: 0.2.4.1-alpha

closed

changed time estimate to 8h

moved to tpo/core/tor#24338 (closed)

DirAuths that have IPv6 addresses don't include them in their vote on themself

Child items ...

Activity