Tor tries to connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort set

In #29641 (moved) we set ClientAutoIPv6ORPort 1 to help users in IPv6-only networks. However, that leads to bootstrap errors, presumably because Tor is trying to use IPv6 in IPv4-only networks. See e.g.:

https://blog.torproject.org/comment/281976#comment-281976 https://blog.torproject.org/comment/282102#comment-282102

I've seen this myself as well when bootstrapping on a Windows machine at least. Just hitting the "Reconfigure" option and choosing "Connect" again "solved this issue.

changed milestone to %Tor: unspecified

Trac:
Parent Ticket: #32905 (moved)

added 041-deferred-20190719 bootstrap component::core tor/tor milestone::Tor: unspecified parent::32905 priority::medium resolution::fixed severity::normal status::closed tbb-wants type::defect labels

Trac:
Component: - Select a component to Core Tor/Tor

Closed #30640 (moved) as duplicate.

This bug is caused by an interaction between tor and Tor Browser:

1. Tor speculatively tries IPv4 and IPv6
2. Some of those connections fail
3. Tor Browser sets DisableNetwork on any failure

Here are some solutions that probably won't work:

• we could try to auto-detect IPv4 or IPv6 addresses (#27492 (moved)), but that's not reliable, because:
  • local addresses don't guarantee internet connectivity
  • some OSes and security configs don't allow tor to read local network information
• we could downgrade the warning on the Tor side, but that might have unintended consequences for other applications that use tor
  • if fiddling with warning levels is our best option, we could defer the warning for 30? seconds, and cancel the pending warning if another tor connection succeeds

Here's a solution that would work, but we need to schedule it in tor's roadmap:

• we could implement a proper "happy eyeballs" style connection design in tor, where we always choose an IPv4 and IPv6 address for every connection, try both, and use the first one that works

Here's a fix that Tor Browser should implement anyway:

• stop setting DisableNetwork on tor's first connection failure, because tor's next connection attempt might work

Here's a quick fix that restores the previous behaviour (and re-opens #29641 (moved)):

• revert the change that added ClientAutoIPv6ORPort to Tor Browser alpha

Let me know how you'd like to move forward, and what you need the network team to do.

Trac:
Cc: teor to teor, mcs, brade

Trac:
Milestone: N/A to Tor: unspecified

Trac:
Keywords: N/A deleted, network-team-roadmap-maybe added

Trac:
Summary: Tor tries so connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort set to Tor tries to connect over IPv6 in IPv4 networks with ClientAutoIPv6ORPort set

Replying to teor:

... Here's a fix that Tor Browser should implement anyway:

• stop setting DisableNetwork on tor's first connection failure, because tor's next connection attempt might work

This is an interesting ticket.

Tor Launcher does not set DisableNetwork=1 on tor's first connection failure; it is more accurate to say that Tor Launcher displays an error message along with a Reconfigure button after it receives a bootstrap status event that includes RECOMMENDATION=warn, and Tor Launcher also sets DisableNetwork=1 at the same time.

The problem that Kathy and I see with changing Tor Launcher to not set DisableNetwork=1 when a "warn" level bootstrap event occurs is that in many situations that will cause user confusion. In fact, if I remember correctly, Tor Launcher used to behave that way. Our current assumption is that when a "warn" level bootstrap event occurs, the bootstrap process has failed and the user needs to intervene to fix it (e.g., they need to modify their Tor configuration to use a bridge or fix their system clock). In this case, that may not be true.

We count on tor to help us by adhering to this idea from section 4.1.10 of the control spec: Currently Tor uses recommendation=ignore for the first nine bootstrap problem reports for a given phase, and then uses recommendation=warn for subsequent problems at that phase. Hopefully this is a good balance between tolerating occasional errors and reporting serious problems quickly.

But maybe the above does not apply to some types of failures inside tor, e.g., "no route to host?" We need to figure out how to avoid interrupting tor's bootstrap process inside tor and in the Tor Launcher UI; otherwise, Tor Launcher will behave as if a "fatal" error occurred even though one did not.

So long as this is a user-facing issue, it seems like 041-should or -must to me. Putting it there until/unless we fix it, or decide differently.

Trac:
Milestone: Tor: unspecified to Tor: 0.4.1.x-final
Keywords: network-team-roadmap-maybe deleted, network-team-roadmap-maybe 041-should added

Replying to mcs:

Replying to teor:

... Here's a fix that Tor Browser should implement anyway:

• stop setting DisableNetwork on tor's first connection failure, because tor's next connection attempt might work

This is an interesting ticket.

Tor Launcher does not set DisableNetwork=1 on tor's first connection failure; it is more accurate to say that Tor Launcher displays an error message along with a Reconfigure button after it receives a bootstrap status event that includes RECOMMENDATION=warn, and Tor Launcher also sets DisableNetwork=1 at the same time.

The problem that Kathy and I see with changing Tor Launcher to not set DisableNetwork=1 when a "warn" level bootstrap event occurs is that in many situations that will cause user confusion. In fact, if I remember correctly, Tor Launcher used to behave that way. Our current assumption is that when a "warn" level bootstrap event occurs, the bootstrap process has failed and the user needs to intervene to fix it (e.g., they need to modify their Tor configuration to use a bridge or fix their system clock). In this case, that may not be true.

We count on tor to help us by adhering to this idea from section 4.1.10 of the control spec: Currently Tor uses recommendation=ignore for the first nine bootstrap problem reports for a given phase, and then uses recommendation=warn for subsequent problems at that phase. Hopefully this is a good balance between tolerating occasional errors and reporting serious problems quickly.

But maybe the above does not apply to some types of failures inside tor, e.g., "no route to host?" We need to figure out how to avoid interrupting tor's bootstrap process inside tor and in the Tor Launcher UI; otherwise, Tor Launcher will behave as if a "fatal" error occurred even though one did not.

These numbers do not provide "a good balance". Since our fallback and bootstrap changes in Tor 0.2.8, Tor only makes about 7 connections in the first 30 seconds. So a safer balance would be the first 5 or 6 problems in the "connecting" phase. And with bridges, it would be the first (N-1) problems, where N is the number of bridges.

And then there seem to be log messages which don't go through the recommendation filter,

I think Tor needs to be much smarter here, if Tor Browser is relying on this behaviour.

Trac:
Keywords: N/A deleted, bootstrap added
Cc: teor, mcs, brade to teor, mcs, brade, catalyst

See #25713 (moved) for more about how DisableNetwork logs confuse users.

Trac:
Parent: N/A to #29641 (moved)

Add 041-deferred-20190719 tag to 041-should tickets I am deferring today.

Trac:
Keywords: network-team-roadmap-maybe 041-should deleted, network-team-roadmap-maybe, 041-deferred-20190719 added

Trac:
Milestone: Tor: 0.4.1.x-final to Tor: unspecified

I think we are better off removing this option completely. See: #32905 (moved)

Trac:
Keywords: network-team-roadmap-maybe deleted, N/A added