Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#4455 closed defect (implemented)

Add configuration option PreferIPv6?

Reported by: ln5 Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: ipv6 tor-client
Cc: dcf Actual Points:
Parent ID: #4624 Points:
Reviewer: Sponsor:

Description

First take on proposal 186 "multiple OR ports" (#3785) adds a second
IP address to the routerinfo_t struct making it possible for a bridge
to bind to an IPv6 address too. Both addresses are announced in the
descriptor, as per proposal 186.

An OP which finds two IP addresses in a bridge descriptor and has both
of these mentioned in Bridge config lines will have to prefer one over
the other. One way would be to add an option PreferIPv6 0|1 (with a
default of 0). Another way would be to prefer the one mentioned first
in the config file (if the information of the order of config lines
are kept after parsing the config file).

Child Tickets

Change History (14)

comment:1 in reply to:  description ; Changed 8 years ago by arma

Component: - Select a componentTor Client

Replying to ln5:

One way would be to add an option PreferIPv6 0|1 (with a
default of 0). Another way would be to prefer the one mentioned first
in the config file (if the information of the order of config lines
are kept after parsing the config file).

I think from an interface perspective, we're going to go mad if we start trying to teach users that the order of bridges in the torrc file matters. (Remember that most users will be using Vidalia to configure their bridge list, and current Vidalia has no support for reordering bridges.)

So I think a config option is a good plan here. That said, we should think harder about the name.

First, we should try to look into the future and guess what related config options we'll want, and what we might name them. For example, PreferIPv6 doesn't give any indication that we're talking about a client; what will multihomed relays want to say in their torrc if they have an ipv6 address available and want to instruct ambivalent clients to prefer it?

Second, based on the name it sounds like the behavior will be "try all your ipv6 bridges first, and if none of them work fall back to your ipv4 bridges". That's a fine behavior for many users. Will we have users who want "try all your ipv6 bridges, and if none of them work fail"? What lines will we expect those users to set in their torrc, and will they be confused by any of the other names of our new options?

comment:2 in reply to:  1 Changed 8 years ago by ln5

Replying to arma:

First, we should try to look into the future and guess what related config options we'll want, and what we might name them. For example, PreferIPv6 doesn't give any indication that we're talking about a client; what will multihomed relays want to say in their torrc if they have an ipv6 address available and want to instruct ambivalent clients to prefer it?

AFAICT they will not be able to do that. What field in the descriptor should convey that information? Also, is it a sane thing to do? Shouldn't the bridge announce whatever it has and let the client make the choice?

comment:3 in reply to:  1 ; Changed 8 years ago by ln5

Replying to arma:

Second, based on the name it sounds like the behavior will be "try all your ipv6 bridges first, and if none of them work fall back to your ipv4 bridges". That's a fine behavior for many users. Will we have users who want "try all your ipv6 bridges, and if none of them work fail"? What lines will we expect those users to set in their torrc, and will they be confused by any of the other names of our new options?

The name is clearly bad. This was not meant to guide the client to chose one Bridge line over another but rather to chose one of two IP addresses in a descriptor, filtered indeed through "do I have this address in a Bridge line?".

This configuration option would be a last resort for this choice, if all else fail. The only sane influence on this choice beside configuration is a note in the routerinfo_t on whether we've seen the IPv6 address in a connection or not.

The option could be named PreferIPv6AddressOfBridges.

comment:4 in reply to:  3 Changed 8 years ago by ln5

Resolution: wontfix
Status: newclosed

The name is clearly bad. This was not meant to guide the client to chose one Bridge line over another but rather to chose one of two IP addresses in a descriptor, filtered indeed through "do I have this address in a Bridge line?".

Wait. The client should probably just ignore adresses found in a
descriptor that isn't in the configuration. If the user wants to use
only the IPv6 address of a given bridge, she types in the IPv6 address
in the configuration and the IPv4 address in the bridge descriptor
will be ignored. (OK, this is what people like Nick and Roger have
been telling me when I was too occupied with understanding other
things to grasp the meaning of what they said. Sorry.)

This should remove the need for a configuration option indicating
preferences. For clients chosing bridges, that is. Later on, we
might want something like this for clients and routers chosing one of
several addresses in descriptors they got from the consensus.

Let's create another ticket for that when that time comes. Closing
this one.

comment:5 Changed 8 years ago by Sebastian

Resolution: wontfix
Status: closedreopened

We'll want some kind of preference like this for when bridge users learn a descriptor from Tonga and it includes both ipv4 and ipv6 addresses. If the best way to do that is a preferipv6 option or not should be considered once we have that design

comment:6 Changed 8 years ago by nickm

Milestone: Tor: unspecified

Not sure if this is 0.2.3 or not; making it unspecified for

comment:7 Changed 8 years ago by ln5

Parent ID: #4624

comment:8 Changed 7 years ago by ln5

Cc: dcf added

comment:9 Changed 7 years ago by ln5

(Meh, lost all changes in that last update. :-( Trying to recreate.)

The need for config option(s) increase when clients start connecting to public relays (#4564).

We should take into account protection of clients without "privacy
enhancements for SLAAC" enabled (i.e. carrying their MAC address in
their IPv6 address) (#4806).

I see these needs for clients:

  • Prefer IPv6 over IPv4 OR ports (default: 0)

Default 0 saves clients with an IPv6 address but no IPv6
connectivity to the relay from get stuck. (And also saves against a
disaster with a buggy IPv6 implementation.) It also saves clients
from potentially leaking their MAC address.

  • Fall back to another address family for the same relay if the current one fails (default: 0)

Default 0 saves clients from leaking their MAC.

We might want clients running with bridges to default to 1 -- the
user entered an IPv6 address manually after all.

  • Use only IPv6 (default: auto)

'auto' translates to 1 on a system without IPv4 support, otherwise 0.

Or we could have "Clients use IPv4 (default: auto)" and "Clients use
IPv6 (default: auto)".

There might be other needs for relays. They differ enough from client
needs to have their own config options.

comment:10 Changed 7 years ago by ln5

Keywords: ipv6 added

comment:11 Changed 7 years ago by ln5

I propose these for 0.2.4.1.

+**ClientUseIPv6** **0**|**1**::
+    If this option is set to 1, Tor might connect to entry nodes over
+    IPv6. Note that clients configured with an IPv6 address in a
+    **Bridge** option will try connecting over IPv6 if even if
+    **ClientUseIPv6** is set to 0. (Default: 0)
+
+**ClientPreferIPv6ORPort** **0**|**1**::
+    If this option is set to 1, we prefer an OR port with an IPv6
+    address over one with IPv4 if a given entry node has both. Other
+    things may influence the choice. This option breaks a tie to the
+    favor of IPv6. (Default: 0)
+

We might want to make ClentUseIPv6 more strict, i.e. refuse to make
any outgoing connections at all unless it's set. If so, should we make
it default to 'auto' and let that translate to '1' if Tor is running
with at least one IPv6 bridge, else '0'?

comment:12 Changed 7 years ago by ln5

Resolution: implemented
Status: reopenedclosed

Done as part of #5535.

comment:13 Changed 7 years ago by nickm

Keywords: tor-client added

comment:14 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.