Opened 5 years ago

Last modified 5 weeks ago

#6939 needs_revision defect

Missing IPv6 ORPort reachability check

Reported by: shamrock Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.4.2-alpha
Severity: Normal Keywords: ipv6, tor-relay, ipv6-relay self-test
Cc: Actual Points:
Parent ID: #17811 Points:
Reviewer: Sponsor:

Description

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)"

Child Tickets

Change History (30)

comment:1 Changed 5 years ago by ln5

  • Component changed from - Select a component to Tor Relay
  • Keywords ipv6 added
  • Parent ID set to #5547
  • Priority changed from trivial to normal

comment:2 Changed 5 years ago by ln5

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, setting that as
parent.

comment:3 Changed 5 years ago by nickm

  • Keywords tor-relay added

comment:4 Changed 5 years ago by nickm

  • Component changed from Tor Relay to Tor

comment:5 Changed 5 years ago by nickm

  • Milestone set to Tor: 0.2.4.x-final

comment:6 Changed 5 years ago by nickm

  • Parent ID #5547 deleted
  • Priority changed from normal to major

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

comment:7 Changed 4 years ago by nickm

  • Status changed from new to needs_review
  • Summary changed from Missing log entry for IPv6 ORPort reachability check to Missing IPv6 ORPort reachability check

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?

comment:8 Changed 4 years ago by andrea

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?

comment:9 Changed 4 years ago by nickm

  • Milestone changed from Tor: 0.2.4.x-final to Tor: 0.2.5.x-final
  • Status changed from needs_review to needs_revision

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

comment:10 Changed 3 years ago by nickm

  • Milestone changed from Tor: 0.2.5.x-final to Tor: 0.2.6.x-final

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

comment:11 follow-up: Changed 3 years ago by 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.

comment:12 Changed 3 years ago by nickm

  • Keywords 026-triaged-1 added

comment:13 Changed 3 years ago by nickm

  • Keywords nickm-patch 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.

comment:14 Changed 2 years ago by nickm

  • Milestone changed from Tor: 0.2.6.x-final to Tor: 0.2.7.x-final

comment:15 Changed 2 years ago by nickm

  • Keywords 027-triaged-1-out added

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

comment:16 Changed 2 years ago by nickm

  • Milestone changed from Tor: 0.2.7.x-final to Tor: 0.2.???

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

comment:17 in reply to: ↑ 11 Changed 19 months ago by teor

  • Severity set to Normal

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, that has to come first.)

comment:18 follow-up: Changed 19 months ago by teor

Do we need to check the IPv6 DirPort as well?

comment:19 Changed 19 months ago by teor

  • Parent ID set to #17811

comment:20 Changed 18 months ago by teor

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

comment:21 in reply to: ↑ 18 Changed 9 months ago by teor

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.

comment:22 Changed 9 months ago by teor

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.

comment:23 Changed 8 months ago by teor

  • Milestone changed from Tor: 0.2.??? to Tor: 0.3.???

Milestone renamed

comment:24 Changed 6 months ago by nickm

  • Keywords tor-03-unspecified-201612 added
  • Milestone changed from Tor: 0.3.??? to Tor: unspecified

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

comment:25 Changed 5 weeks ago by nickm

  • Keywords tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:26 Changed 5 weeks ago by nickm

  • Keywords 027-triaged-in added

comment:27 Changed 5 weeks ago by nickm

  • Keywords 027-triaged-in removed

comment:28 Changed 5 weeks ago by nickm

  • Keywords 027-triaged-1-out removed

comment:29 Changed 5 weeks ago by nickm

  • Keywords 026-triaged-1 removed

comment:30 Changed 5 weeks ago by nickm

  • Keywords ipv6-relay self-test added; nickm-patch removed
Note: See TracTickets for help on using tickets.