Opened 3 years ago

Last modified 11 months ago

#17217 new enhancement

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

Reported by: teor Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Major Keywords: ipv6 tor-client robustness censorship-resistance
Cc: adrelanos Actual Points:
Parent ID: #17811 Points: medium
Reviewer: Sponsor:

Description

Tor currently defaults to avoiding IPv6 directories and ORPorts.
When #8374 and #4483 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

Child Tickets

Change History (12)

comment:1 Changed 3 years ago by teor

Keywords: TorCoreTeam201512 added
Severity: Normal

comment:2 Changed 2 years ago by teor

Keywords: ipv6 added
Parent ID: #17811

comment:3 Changed 2 years ago by teor

Keywords: TorCoreTeam201601 added; TorCoreTeam201512 removed
Priority: MediumLow
Severity: NormalMajor

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

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

  • 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 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.)

comment:4 in reply to:  3 Changed 2 years ago by teor

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.

comment:5 Changed 2 years ago by teor

Keywords: TorCoreTeam201601 removed
Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

comment:6 Changed 2 years ago by isabela

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

tickets market to be removed from milestone 029

comment:7 Changed 18 months ago by teor

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

Milestone renamed

comment:8 Changed 17 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:9 Changed 16 months ago by adrelanos

Cc: adrelanos added

comment:10 Changed 12 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:11 Changed 11 months ago by nickm

Keywords: tor-client robustness added

comment:12 Changed 11 months ago by teor

Keywords: censorship-resistance added
Note: See TracTickets for help on using tickets.