Opened 5 years ago

Last modified 5 months ago

#5940 new 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, lorax
Cc: massar, rl1987@…, sven.herzberg@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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 (30)

comment:1 Changed 5 years ago by nickm

Milestone: 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 5 years ago by nickm

Keywords: tor-relay added

comment:4 Changed 5 years ago by nickm

Component: Tor RelayTor

comment:5 Changed 5 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:6 Changed 4 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:7 Changed 3 years ago by andrea

Keywords: 026-triaged-1 026-deferrable added

comment:8 Changed 3 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:9 Changed 3 years ago by teor

Keywords: lorax added

comment:10 Changed 3 years ago by teor

Cc: massar added

comment:11 Changed 3 years ago by rl1987

Cc: rl1987@… added

comment:12 Changed 3 years ago by nickm

Status: newassigned

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

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

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

comment:15 Changed 2 years ago by herzi

Cc: sven.herzberg@… added
Severity: Blocker

comment:16 Changed 2 years 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 2 years ago by teor

Severity: BlockerNormal

comment:18 Changed 2 years ago by teor

As of 0.2.7.3-rc, 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?
IPv6Relay?
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 23 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 20 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 12 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 11 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:23 Changed 10 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:24 Changed 5 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:25 Changed 5 months ago by nickm

Keywords: 027-triaged-in added

comment:26 Changed 5 months ago by nickm

Keywords: 027-triaged-in removed

comment:27 Changed 5 months ago by nickm

Keywords: 027-triaged-1-out removed

comment:28 Changed 5 months ago by nickm

Keywords: 026-triaged-1 removed

comment:29 Changed 5 months ago by nickm

Keywords: 026-deferrable removed

comment:30 Changed 5 months ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

Note: See TracTickets for help on using tickets.