Opened 5 years ago

Closed 2 years ago

#9068 closed enhancement (fixed)

Unify reachableaddresses and IPv6 settings

Reported by: nickm Owned by: teor
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client ipv6
Cc: Actual Points:
Parent ID: #17840 Points:
Reviewer: Sponsor:

Description

There's really no difference between "I can't reach IPv6" and "ClientUseIPv6 0". Let's make them redundant. Let's also add an "I can't reach IPv4" option.

See #6027 and #9067

Child Tickets

Change History (15)

comment:1 Changed 4 years ago by nickm

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

comment:2 Changed 3 years ago by teor

Parent ID: #17811
Severity: Normal

comment:3 Changed 3 years ago by teor

Owner: set to teor
Status: newaccepted

My design for this task is as follows:

  • Add ClientUseIPv4 set to 1 by default
  • When checking options, fail (REJECT) if ClientUseIPv4 is 0 and ClientUseIPv6 is 0
  • Make ClientUseIPv4 0 prepend "reject 0.0.0.0/0" to reachable addresses
  • Make ClientUseIPv6 0 prepend "reject [::]/0" to reachable addresses

comment:4 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.2.8.x-final

comment:5 Changed 3 years ago by teor

Also:

  • Prepend ReachableORAddresses and ReachableDirAddresses as well
  • Replace all instances of ClientUseIPv6 with the appropriate tests on ReachableAddresses.
    • Preserve the existing behaviour of ClientUseIPv6:
      • "Note that clients configured with an IPv6 address in a Bridge line will try connecting over IPv6 even if ClientUseIPv6 is set to 0."
    • This probably means implementing #9067
      • Which might be difficult to do without breaking existing configs, but I think we can fix that by:
        • Make ClientUseIPv6 1 append "accept [::]/0" to Reachable*Addresses
          • "For backwards-compatibility with IPv4-only Reachable*Addresses policies, when ClientUseIPv6 is set to 1, Reachable*Addresses will consider all IPv6 addresses reachable by default. End Reachable*Addresses with "reject *:*" to only allow explicitly specified IPv6 addresses."

comment:6 Changed 3 years ago by teor

  • When checking options, fail (REJECT) if ClientUseIPv4 is 0 and ClientUseIPv6 is 0
    • Also fail if no addresses are reachable, that is, the user has configured the equivalent of: "Reachable*Addresses reject 0.0.0.0/0, reject [::]/0"

comment:7 Changed 3 years ago by teor

Web browsers and operating systems have to deal with dual-stack hosts.
Here is how some of them do it:

Google Chrome
Start IPv6 connection, then 300ms later, start IPv4 connection.
https://codereview.chromium.org/7029049

Safari / OS X
Starts both at the same time, and races them (Happy Eyeballs)
http://lists.apple.com/archives/Ipv6-dev/2011/Jul/msg00009.html

Windows does something complex
http://blogs.msdn.com/b/b8/archive/2012/06/05/connecting-with-ipv6-in-windows-8.aspx

And the correct way of doing it is:
RFC 3484 - address sorting
https://www.ietf.org/rfc/rfc3484.txt
TL;DR: Prefer IPv6 if it actually works

comment:8 Changed 3 years ago by yawning

Is it worth (for the time being) issuing a warning if the client only supports IPv6?
How much of the current guard pool only supports either protocol version?

comment:9 in reply to:  8 Changed 3 years ago by teor

Replying to yawning:

Is it worth (for the time being) issuing a warning if the client only supports IPv6?
How much of the current guard pool only supports either protocol version?

Split off as #17849.

comment:10 Changed 3 years ago by teor

It turns out that the majority of this ticket can be implemented by checking ClientUseIPv4 and ClientUseIPv6 when checking the fascist firewall settings for OR and Dir connections. This is implemented in #17840.

We don't even need to switch between IPv4 and IPv6 on dual-stack hosts. The random node selection already does that for us - in proportion to the IPv4/IPv6 consensus weight ratio.
(Which is a desirable property.)

This ticket might be able to be closed after testing #17840 to see if it makes connections on the wrong address family.

comment:11 Changed 3 years ago by teor

Parent ID: #17811#17840

comment:12 in reply to:  5 ; Changed 3 years ago by teor

Parent ID: #17840#17811

Replying to teor:

  • Make ClientUseIPv6 1 append "accept [::]/0" to Reachable*Addresses
    • "For backwards-compatibility with IPv4-only Reachable*Addresses policies, when ClientUseIPv6 is set to 1, Reachable*Addresses will consider all IPv6 addresses reachable by default. End Reachable*Addresses with "reject *:*" to only allow explicitly specified IPv6 addresses."

Oops, this still needs to be done.

comment:13 in reply to:  12 ; Changed 3 years ago by teor

Parent ID: #17811#17840

Replying to teor:

Replying to teor:

  • Make ClientUseIPv6 1 append "accept [::]/0" to Reachable*Addresses
    • "For backwards-compatibility with IPv4-only Reachable*Addresses policies, when ClientUseIPv6 is set to 1, Reachable*Addresses will consider all IPv6 addresses reachable by default. End Reachable*Addresses with "reject *:*" to only allow explicitly specified IPv6 addresses."

Oops, this still needs to be done.

It turns out my current code is sufficient, as the default fascist firewall policy action is ADDR_POLICY_ACCEPTED. See #9067 for details.

This ticket can close when #17840 has been thoroughly tested to see if it uses the wrong address family.

comment:14 in reply to:  13 Changed 3 years ago by teor

Replying to teor:

Replying to teor:

Replying to teor:

  • Make ClientUseIPv6 1 append "accept [::]/0" to Reachable*Addresses
    • "For backwards-compatibility with IPv4-only Reachable*Addresses policies, when ClientUseIPv6 is set to 1, Reachable*Addresses will consider all IPv6 addresses reachable by default. End Reachable*Addresses with "reject *:*" to only allow explicitly specified IPv6 addresses."

It turns out my current code is sufficient, as the default fascist firewall policy action is ADDR_POLICY_ACCEPTED. See #9067 for details.

Ugh, options_validate() appends reject *:*. If ClientIPv6 is set and Reachable*Addresses looks IPv4-only, I'll warn the user. (See #9067.)

This ticket can close when #17840 has been thoroughly tested to see if it ever uses IPv4/6 when ClientUseIPv4/6 0 is set.

comment:15 Changed 2 years ago by teor

Resolution: fixed
Status: acceptedclosed

We resolved this in #17840 by redesigning the fascist_firewall API to check and choose addresses, taking ClientUseIPv[46] into account.

We also log an info if Tor ever makes a connection that violates IP family preferences, and log a warning and stack trace if tor ever uses a disabled IP family. See connection_connect_log_client_use_ip_version().

See my branch feature17840-v11-squashed in #17840.

Note: See TracTickets for help on using tickets.