Change clients to automatically use IPv6 if they can bootstrap over it

Tor currently defaults to avoiding IPv6 directories and ORPorts. When #8374 (moved) and #4483 (moved) are implemented, we should change this default, especially for those clients that can bootstrap successfully over IPv6.

I suggest we add an "auto" option, and make it the default. It would mean that the client uses whichever IP version it bootstrapped over.

ClientUseIPv6 0
ClientPreferIPv6ORPort 0

changed milestone to %Tor: unspecified

added censorship-resistance component::core tor/tor ipv6 milestone::Tor: unspecified parent::17835 points::medium priority::low robustness severity::major status::new tor-client type::enhancement labels

Trac:
Severity: N/A to Normal
Keywords: N/A deleted, TorCoreTeam201512 added

Trac:
Parent: N/A to #17811 (moved)
Keywords: N/A deleted, ipv6 added

See #17835 (moved) for details of how we could automatically determine a preferred IP version.

This ticket could implement a IPv6 autodetection scheme based on #17835 (moved):

• Set ClientUseIPv4 to 1 (for backwards-compatibility) and ClientUseIPv6 to auto by default.
• If the client has any non-localhost, non-link-local IPv6 addresses, act as if ClientUseIPv6 is 1
• Check regularly if the interface addresses have changed. (Relays check every 20 minutes, clients, especially mobile/wireless clients, might want to check more frequently.)

Open Questions:

• Do we want to ignore private IPv6 addresses if the client has a public IPv4 address? (Do people route via private IPv6 addresses to public networks? Do people do IPv6 NAT?)
• If we do, we risk clients which are on strange setups (private IPv6 that works, public IPv4 that doesn't) failing to bootstrap.
• If we don't, we might slow down IPv4 clients with public IPv4 addresses, with private IPv6 addresses that don't go anywhere.
• Is it OK to slow down all (IPv4) clients for the sake of those that can connect only/better via IPv6?
  • Tor Browser already sets ClientUseIPv6 to 1, so the answer is probably "yes".
  • We should be able to tune the (multiple concurrent) connection schedules in #4483 (moved) to help with this, at least during bootstrap.

I'm marking this as low priority, to be resolved in January, because Tor Browser already sets ClientUseIPv6 to 1 by default. One simple resolution to this issue is to follow Tor Browser's lead, and set ClientUseIPv6 to default to 1 in tor.

(If we're going to make IPv6 bootstrap work in 0.2.8, we also need to resolve this issue in the same timeframe.)

Trac:
Severity: Normal to Major
Keywords: TorCoreTeam201512 deleted, TorCoreTeam201601 added
Priority: Medium to Low

Replying to teor:

One simple resolution to this issue is to follow Tor Browser's lead, and set ClientUseIPv6 to default to 1 in tor.

Tor Browser 5.0.4 doesn't have ClientUseIPv6 set.

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final
Keywords: TorCoreTeam201601 deleted, N/A added

tickets market to be removed from milestone 029

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

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Trac:
Cc: N/A to adrelanos
Reviewer: N/A to N/A

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: ipv6 deleted, ipv6 tor-client robustness added

Trac:
Keywords: ipv6 tor-client robustness deleted, ipv6 tor-client robustness censorship-resistance added

Trac:
Cc: adrelanos to adrelanos, neel@neelc.org

Trac:
Owner: N/A to neel
Status: new to assigned

Trac:
Cc: adrelanos, neel@neelc.org to adrelanos, neel@neelc.org, cypherpunks

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

Trac:
Cc: adrelanos, neel@neelc.org, cypherpunks to adrelanos, cypherpunks
Owner: neel to N/A

Trac:
Status: assigned to new