Opened 5 years ago

Last modified 3 months ago

#5940 assigned enhancement

Figure out own IPv6 address

Reported by: ln5 Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, tor-relay, 026-triaged-1, 026-deferrable, lorax, 027-triaged-1-out, tor-03-unspecified-201612
Cc: massar, rl1987@…, sven.herzberg@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


A relay should be able to figure out if the system has got an IPv6
address configured, just like what's done for IPv4.

From #5146:

Should we turn resolve_my_address() into resolve_my_addresses() and
teach it about IPv6? get_interface_address6() used here needs some
work for #4806 too.

A few thoughts:

  • resolve_my_address() looks at options->Address. What should 'Address' mean now that a relay doesn't have one single address any more?
  • get_interface_address() says "This address should only be used in checking whether our address has changed" but is actually used by resolve_my_address() in the case where we fail to resolve our hostname. Does get_interface_address6() need more work or should we just add a comment to where we use it in a non-recommended way?

Child Tickets

Change History (23)

comment:1 Changed 5 years ago by nickm

  • Milestone set to Tor: 0.2.4.x-final

comment:2 Changed 5 years ago by nickm

Since all the *port options allow Address to be overridden, I'm inclined to keep the current meaning of Address. When we resolve it, though, let's remember if it has any INET6 addresses in addition to its INET addresses, and use those as an appropriate fallback when finding our IPv6 address.

I think the right fix for the comment on get_interface_address() is to explain why it can tell you that the address has changed, but it's only a good guess for our current public address (that is, because NAT exists).

comment:3 Changed 4 years ago by nickm

  • Keywords tor-relay added

comment:4 Changed 4 years ago by nickm

  • Component changed from Tor Relay to Tor

comment:5 Changed 4 years ago by nickm

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

comment:6 Changed 3 years ago by nickm

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

comment:7 Changed 3 years ago by andrea

  • Keywords 026-triaged-1 026-deferrable added

comment:8 Changed 2 years ago by nickm

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

comment:9 Changed 2 years ago by teor

  • Keywords lorax added

comment:10 Changed 2 years ago by teor

  • Cc massar added

comment:11 Changed 2 years ago by rl1987

  • Cc rl1987@… added

comment:12 Changed 2 years ago by nickm

  • Status changed from new to assigned

comment:13 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:14 Changed 2 years ago by nickm

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

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:15 Changed 17 months ago by herzi

  • Cc sven.herzberg@… added
  • Severity set to Blocker

comment:16 Changed 17 months ago by herzi

FYI, the severity was displayed as blocker before. I think it was just unset (maybe a problem in the trac setup).

comment:17 Changed 17 months ago by teor

  • Severity changed from Blocker to Normal

comment:18 Changed 17 months ago by teor

As of, we also use get_interface_address6* to discover our IPv4 and IPv6 addresses so we can block them in the exit policy (#17027).

Relays also allow IPv6 ORPorts to be set, and the first IPv6 ORPort is used as the ipv6_addr for the relay.

Perhaps we need an option to tell relays it's ok to autodetect their IPv6 address?
If it's an AUTOBOOL, we could change the default in the consensus from 0 to 1 once enough relays have upgraded, and once we check IPv6 reachability from the relay itself, and the authorities, and maybe the bwauths.

comment:19 Changed 16 months ago by teor

In #17281, I intend to use get_interface_address6* to determine whether the client has any non-local IPv6 address(es). That gets us halfway to fixing this issue.

comment:20 Changed 13 months ago by teor

When tor can figure out its own IPv6 address, a relay configured with ORPort [::]:443 should put the discovered IPv6 address in its descriptor. (See #18387.)

comment:21 Changed 4 months ago by teor

If we turned on IPv6 autodetection by default, operators with broken IPv6 configs might find their relays being excluded from the consensus because they are unreachable on IPv6.

We'd have to teach Tor to test IPv6 reachability, and stop advertising IPv6 if it was unreachable.

But this is counted as an address change by OnionOO, so it has flow-on effects in systems that analyse relay stability.

And there are race conditions involved - this is why we made IPv4 DirPort reachability a requirement in 0.2.8 in #18050.

comment:22 Changed 4 months ago by teor

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

Milestone renamed

comment:23 Changed 3 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.

Note: See TracTickets for help on using tickets.