#26303 closed defect (duplicate)

IPv6-Flagging of Relay not accurate

Reported by: ruebezahl Owned by: metrics-team
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor:
Severity: Normal Keywords: ipv6, 035-roadmap-proposed
Cc: teor Actual Points:
Parent ID: #24864 Points:
Reviewer: Sponsor:


Our Node (D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA) is reachable via IPv6, but gets flagged with "unreachable IPv6" by the Consensus.

All IPv6-enabled Authorities can be pinged successfully via IPv6 from the Relay, and the advertised Ports are open for connections via IPv6.

Child Tickets

Change History (10)

comment:1 Changed 17 months ago by cypherpunks

Please include timing information. The consensus at what time?
What tool do you use for consensus data lookup? ("Core Tor/DirAuth" might not be the right component for this trac entry)

As per consensus 2018-06-04 09:00 UTC D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA is "ReachableIPv6".

enter your fingerprint at the bottom of this page:

onionoo's opinion:


"relays_published":"2018-06-04 08:00:00",
"bridges_published":"2018-06-04 08:04:10",
Last edited 17 months ago by cypherpunks (previous) (diff)

comment:2 Changed 17 months ago by ruebezahl

The consensus at the time since rebooting the relay yesterday at 2018-06-03 20:34:05 till the creation of this ticket (obviously...) as shown on metrics.

No idea as why it is now correctly flagged. I did not change any configuration nor did I restart / sighup the relay.

Please feel free to correct the trac component.

comment:3 Changed 17 months ago by cypherpunks

Component: Core Tor/DirAuthMetrics
Owner: set to metrics-team
Resolution: worksforme
Status: newclosed

I believe this was just a time of check problem.

Relay Search/onionoo is always a bit behind consensus 2018-06-04 08:00 vs 2018-06-04 09:00

now it is updated and fine:


"relays_published":"2018-06-04 09:00:00",
"bridges_published":"2018-06-04 09:04:10",

please reopen if you are unhappy with this reply.

comment:4 Changed 17 months ago by ruebezahl

Even if relay search/onionoo is behind one hour, this does not explain why it displayed the incorrect flag - or got flagged wrongly - for the remaining 12 hours of relay uptime.

Might be worth investigating, just saying.

comment:5 Changed 17 months ago by cypherpunks

Component: MetricsCore Tor/DirAuth
Resolution: worksforme
Status: closedreopened

Ok, reopened.

Can you describe in detail what you did exactly to help collect relevant information for finding the root-cause?

From previous descriptors on that IP:ORPort (IPv4: we can see that it was probably more than just a reboot?

previous key and platform:
B01B7973207B1FD2F71D51D1B51B89EE77035CF4 Tor on Linux, last seen: 2018-06-01 20:00 first_seen: 2016-04-02 00:00 (Note: this one had no IPv6 ORPort)

current relay:
D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA Tor on SunOS, first seen: 2018-06-02 21:00

Last edited 17 months ago by cypherpunks (previous) (diff)

comment:6 Changed 17 months ago by ruebezahl

Yes, we changed hardware and deployment, which now includes IPv6 connectivity.

D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA is active and online since 2018-06-02 21:00:00, the change can be verified at https://www.ccc.de/en/anonymizer

I checked the flags displayed on metrics regulary since configuring ORPort in torrc. I verified working IPv6 connectivity in- and outgoing at 2018-06-03 20:34:05.

comment:7 Changed 17 months ago by nickm

Cc: teor added
Keywords: ipv6 035-proposed added

comment:8 Changed 17 months ago by teor

Component: Core Tor/DirAuthCore Tor/Tor
Parent ID: #24403
Status: reopenedneeds_information

We don't have enough information to diagnose this issue.
It could be a bug in Core Tor, metrics, or the relay's IPv6 connectivity.

In most cases that we investigate, the problem is on the relay, or the relays network. (It's more likely that one operator has made a mistake, than 6 directory authorities.)
In some cases, Onionoo is outdated.

If it is a bug in Tor, it could be #24864, where some directory authorities take a while to vote on new descriptors. We added #24862 to consensus health to diagnose that issue. So if it happens again, please tell us the descriptor timestamp from consensus health, and the descriptor timestamp from the relay itself:

Ultimately, we will resolve this issue (or make it much easier to diagnose) by making relays check their own IPv6 addresses in #24403.

comment:9 Changed 16 months ago by nickm

Keywords: 035-roadmap-proposed added; 035-proposed removed

comment:10 Changed 15 months ago by teor

Parent ID: #24403#24864
Resolution: duplicate
Status: needs_informationclosed

We think this happened due to the delayed descriptor updates in #24864, or the missing IPv6 reachability checks in #24403.

If it happens again, please open a new ticket with:

Note: See TracTickets for help on using tickets.