Unify reachableaddresses and IPv6 settings

changed milestone to %Tor: 0.2.8.x-final

added component::core tor/tor ipv6 milestone::Tor: 0.2.8.x-final owner::teor parent::17840 priority::medium resolution::fixed severity::normal status::closed tor-client type::enhancement labels

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

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

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

Trac:
Owner: N/A to teor
Status: new to accepted

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

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 (moved)
  - 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 ReachableAddresses policies, when ClientUseIPv6 is set to 1, ReachableAddresses will consider all IPv6 addresses reachable by default. End Reachable*Addresses with "reject :" to only allow explicitly specified IPv6 addresses."

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"

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

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?

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 (moved).

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 (moved).

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 (moved) to see if it makes connections on the wrong address family.

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

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.

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

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 (moved) for details.

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

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

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 (moved) for details.

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

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

We resolved this in #17840 (moved) 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 (moved).

Trac:
Status: accepted to closed
Resolution: N/A to fixed