Missing IPv6 ORPort reachability check

Issue: Tor does not log (or does not perform) a test to determine if an IPv6 ORPort is reachable.

Tor does log a corresponding test for an IPv4 ORPort.

Environment: Debian squeeze amd64, latest patches Tor version 0.2.4.2-alpha (git-0537dc6364594474)

How to reproduce:

• configure Tor with both IPv4 and IPv6 IP addresses and OrPorts.
• start Tor
• the Tor log file will show a test to determine if the IPv4 OrPort is reachable, but not if the IPv6 ORPort is reachable.
• (this particular system was configured as a bridge)

Expected Behavior: The user might expect to see a log entry for IPv6 that corresponds to the following log entry for IPv4:

"Sep 22 11:09:21.000 [notice] Now checking whether ORPort [host's IPv4 address]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)"

changed milestone to %Tor: unspecified

added 034-removed-20180328 034-triage-20180328 component::core tor/tor ipv6 ipv6-relay milestone::Tor: unspecified parent::13112 priority::high self-test severity::normal status::needs-revision tor-relay type::defect version::tor 0.2.4.2-alpha labels

Trac:
Parent: N/A to #5547 (moved)
Component: - Select a component to Tor Relay
Keywords: N/A deleted, ipv6 added
Priority: trivial to normal

Meh, lost the comment in the last change. Something like this:

We need support for exiting to IPv6 addresses in order to do self testing of IPv6 OR ports. This will happen in #5547 (moved), setting that as parent.

Trac:
Keywords: ipv6 deleted, ipv6 tor-relay added

Trac:
Component: Tor Relay to Tor

Trac:
Milestone: N/A to Tor: 0.2.4.x-final

Dropping parent relationship. This is ipv6-related , but not a prereq for making IPv6 exits work.

Trac:
Parent: #5547 (moved) to N/A
Priority: normal to major

I've got an untested implementation for this in branch "bug6939" in my public repo, but I'm inclined to call it a feature and put it in 0.2.5. Thoughts?

Trac:
Status: new to needs_review
Summary: Missing log entry for IPv6 ORPort reachability check to Missing IPv6 ORPort reachability check

I think this is correct, but I also think it's a feature and probably for 0.2.5.

The patch looks okay; just one complaint: the extend_info_from_router() function does a variety of manipulations in the IPv6 case, but just calls router_get_prim_orport() for IPv4. Shouldn't there be a parallel router_get_prim_ipv6_orport() that does that stuff instead?

"prim" is primary; instead it should probably call "get_ipv6_orport()" or whatever it's called.

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final
Status: needs_review to needs_revision

Moving nearly all needs_revision tickets into 0.2.6, as now untimely for 0.2.5.

Trac:
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.6.x-final

This is probably root cause why tor bridgedb do not supports bridges with ipv6 ORPort only. I have bridge configured with:

ORPort [2001:470:....::2]:9090
BridgeRelay 1
AssumeReachable 0

and it never gets published in bridgedb. Changing AssumeReachable to 1, did not make it published.

Trac:
Username: hsn

Trac:
Keywords: ipv6 tor-relay deleted, ipv6 tor-relay 026-triaged-1 added

Add nickm-patch keyword to needs_revision tickets in 0.2.6 where (I think) I wrote the patch, so I know which ones are my responsibility to revise.

Trac:
Keywords: ipv6 tor-relay 026-triaged-1 deleted, 026-triaged-1, tor-relay, ipv6, nickm-patch added

Trac:
Milestone: Tor: 0.2.6.x-final to Tor: 0.2.7.x-final

Marking triaged-out items from first round of 0.2.7 triage.

Trac:
Keywords: N/A deleted, 027-triaged-1-out added

Move most 0.2.7-triaged-1-out needs_revision items into 0.2.???. Keep a few based on my sense of the sensible.

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.???

Replying to hsn:

This is probably root cause why tor bridgedb do not supports bridges with ipv6 ORPort only. I have bridge configured with:

{{{ ORPort [2001:470:....::2]:9090 BridgeRelay 1 AssumeReachable 0 }}}

and it never gets published in bridgedb. Changing AssumeReachable to 1, did not make it published.

IPv6-only relays aren't supported yet, and bridges are relays. (We're working on IPv6 client support in #17840 (moved), that has to come first.)

Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal

Do we need to check the IPv6 DirPort as well?

Trac:
Parent: N/A to #17811 (moved)

See https://trac.torproject.org/projects/tor/ticket/17782#comment:9 for a description of issues involved in reachability self-testing.

Replying to teor:

Do we need to check the IPv6 DirPort as well?

There is now no IPv6 DirPort, it existed for a short while in the 0.2.8 alpha series, and was effectively removed by mandatory client directory fetches over ORPort begindir.

Trac:
Reviewer: N/A to N/A

To implement this ticket, we need Tor to be able to connect to its own IPv6 ORPort, using at least a 3-hop path:

• This relay
• Guard
• Middle that supports IPv6
• IPv6 ORPort on this relay

We can definitely choose a middle node that supports IPv6 (maybe this will need an API change?), but I'm not sure whether we can tell it to extend specifically to an IPv6 address, and how it will react if we do.

Alternately, we could simply test if we can connect, like the IPv4 DirPort, but that is sub-optimal.

In any case, Authorities don't vote on IPv6 addresses unless they can test IPv6 reachability, so at least the authorities are checking IPv6 ORPorts.

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: N/A deleted, 027-triaged-in added

Trac:
Keywords: 027-triaged-in deleted, N/A added

Trac:
Keywords: 027-triaged-1-out deleted, N/A added

Trac:
Keywords: 026-triaged-1 deleted, N/A added

Trac:
Keywords: nickm-patch deleted, ipv6-relay self-test added

Trac:
Parent: #17811 (moved) to #4565 (moved)

Trac:
Parent: #4565 (moved) to #24403 (moved)

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

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

Trac:
Keywords: ipv6-relay self-test deleted, self-test, ipv6-relay, 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 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.

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

This code duplicates code in #13112 (moved), we should take the best combination of both branches.

Trac:
Parent: #24403 (moved) to #13112 (moved)

mentioned in issue #12558 (moved)

mentioned in issue #17066 (moved)

mentioned in issue #17782 (moved)

mentioned in issue #17840 (moved)

mentioned in issue #19919 (moved)

mentioned in issue #22863 (moved)

mentioned in issue #24603 (moved)

mentioned in issue #25182 (moved)

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