Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:50:38Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29801Write a proposal for IPv6 "Happy Eyeballs" on Tor clients2020-06-27T13:50:38ZNeel Chauhanneel@neelc.orgWrite a proposal for IPv6 "Happy Eyeballs" on Tor clientsTeor has asked for updates in https://github.com/torproject/torspec/pull/61, but this PR has already been merged.
I have created a new PR for his suggestions: https://github.com/torproject/torspec/pull/63
I don't believe you can add to...Teor has asked for updates in https://github.com/torproject/torspec/pull/61, but this PR has already been merged.
I have created a new PR for his suggestions: https://github.com/torproject/torspec/pull/63
I don't believe you can add to a merged PR so that's why a new PR exists.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30953ServerTransportListenAddr is ignored when stated second time for the IPv6 add...2020-06-27T13:49:57Zs7rServerTransportListenAddr is ignored when stated second time for the IPv6 addressCurrently is possible to run a dual stacked IPv4 + IPv6 bridge.
`ORPort` can be set 2 times in torrc, once for IPv4 and once for IPv6 - it will open ports on both address families and listen for connections.
However, `ServerTransportLi...Currently is possible to run a dual stacked IPv4 + IPv6 bridge.
`ORPort` can be set 2 times in torrc, once for IPv4 and once for IPv6 - it will open ports on both address families and listen for connections.
However, `ServerTransportListenAddr` will only work for IPv4 and be ignored if set second time in the same torrc for the IPv6 family (no obfs4 port open on the IPv6 address).
Log file does not even mention it, it only confirms the IPv4 one:
[notice] Registered server transport 'obfs4' at '<xxx>:port'Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30954Address torrc option is ignored if set second time for the IPv6 address2020-06-27T13:49:56Zs7rAddress torrc option is ignored if set second time for the IPv6 addressCurrently if we specify `Address` 2 times in the same torrc, once for IPv4 address and once for IPv6 address, it will just ignore the second entry as like it would be for the same IP family:
```
[warn] Option 'Address' used more than on...Currently if we specify `Address` 2 times in the same torrc, once for IPv4 address and once for IPv6 address, it will just ignore the second entry as like it would be for the same IP family:
```
[warn] Option 'Address' used more than once; all but the last value will be ignored.
```
This behavior is perfect for cases where operators specify more addresses from the same family (like IPv4 for example) in the same torrc. I am marking this Low priority because it's here only to remind us about it when IPv6 autodetection will be implemented.
I know currently does not do IPv6 address detection so I am guessing this is why it currently does not care to learn about an IPv6 address from `Address` torrc setting, and only from `ORPort` to build just descriptors and be optimistic about getting the ReachableIPv6 flag, but when this changes it should be possible to specify `Address` 2 times in torrc, once for IPv4 and once for IPv6, the same as for `OutboundBindAddress | OutboundBindAddressOR | OutboundBindAddressExit`.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31039Review proposal 306: IPv6 "Happy Eyeballs" for Tor clients2020-06-27T13:49:51ZteorReview proposal 306: IPv6 "Happy Eyeballs" for Tor clientsHi review assigners,
Please assign a network team member to review proposal 306: IPv6 "Happy Eyeballs" for Tor clients
Here is the pull request:
https://github.com/torproject/torspec/pull/86
Here is the mailing list thread, and my ini...Hi review assigners,
Please assign a network team member to review proposal 306: IPv6 "Happy Eyeballs" for Tor clients
Here is the pull request:
https://github.com/torproject/torspec/pull/86
Here is the mailing list thread, and my initial review:
https://lists.torproject.org/pipermail/tor-dev/2019-June/013907.html
Neel has pushed my suggested changes as fixups.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31088Check IPv4 and IPv6 private addresses in descriptors2020-06-27T13:49:50ZteorCheck IPv4 and IPv6 private addresses in descriptorsTor should check for private relay IPv6 addresses:
When authorities check descriptors:
https://github.com/torproject/tor/blob/e9d99d2e15f09a394ad01189b7965af4888a61a6/src/feature/dirauth/process_descs.c#L429
Note: these changes require...Tor should check for private relay IPv6 addresses:
When authorities check descriptors:
https://github.com/torproject/tor/blob/e9d99d2e15f09a394ad01189b7965af4888a61a6/src/feature/dirauth/process_descs.c#L429
Note: these changes require IPv6 extends from legacy/trac#24403:
When relays extend:
https://github.com/torproject/tor/blob/f7e8b3b68c8e2cecfc7ff4072e9f00d316aaba4f/src/core/or/circuitbuild.c#L1253
And when clients connect:
https://github.com/torproject/tor/blob/f7e8b3b68c8e2cecfc7ff4072e9f00d316aaba4f/src/core/or/circuitbuild.c#L552Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31545CID 1452819: nul-terminated string handling, possibly spurious2020-06-27T13:49:33ZteorCID 1452819: nul-terminated string handling, possibly spuriousBug introduced by legacy/trac#21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
...Bug introduced by legacy/trac#21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
76 if (has_addr) {
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "tor_addr_to_str", which expects a null-terminated string.
77 tor_addr_to_str(cp, addr, TOR_ADDR_BUF_LEN, 1);
78 }
79
80 return buf;
81 }
82
/src/feature/nodelist/describe.c: 70 in format_node_description()
64 cp += 4;
65 }
66 if (addr32h) {
67 struct in_addr in;
68 in.s_addr = htonl(addr32h);
69 tor_inet_ntoa(&in, cp, INET_NTOA_BUF_LEN);
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "strlen", which expects a null-terminated string.
70 cp += strlen(cp);
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
```
I think the best fix for this issue is using strncpy() rather than memcpy().Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32629Re-enable 1 or 2 more macOS jobs in Travis2020-06-27T13:48:44ZteorRe-enable 1 or 2 more macOS jobs in TravisReverts legacy/trac#32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Reverts legacy/trac#32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32707need a mechanism to automatically detect the ipv6 address of the node2020-06-27T13:48:41ZTracneed a mechanism to automatically detect the ipv6 address of the nodebecause for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done ...because for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done for ipv4
**Trac**:
**Username**: babutTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32905Remove the ClientAutoIPv6ORPort option2020-06-27T13:48:31ZNeel Chauhanneel@neelc.orgRemove the ClientAutoIPv6ORPort optionIn legacy/trac#27490, we introduced the option `ClientAutoIPv6ORPort`, which randomly tries IPv4 or IPv6 randomly.
This option is not true Happy Eyeballs and fails very often, usually trying IPv6 on networks which are IPv4-only (legacy/...In legacy/trac#27490, we introduced the option `ClientAutoIPv6ORPort`, which randomly tries IPv4 or IPv6 randomly.
This option is not true Happy Eyeballs and fails very often, usually trying IPv6 on networks which are IPv4-only (legacy/trac#30639).
We should remove this option.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33056Tor relays fail to understand /etc/resolv.conf ipv6 lines with % in them2020-06-27T13:48:26ZRoger DingledineTor relays fail to understand /etc/resolv.conf ipv6 lines with % in themWe had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints...We had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints that % is a standard thing:
* https://bugs.launchpad.net/ubuntu/+source/wide-dhcpv6/+bug/1620221 "The link local name servers should be suffixed with the scope, e.g. "%eth0"."
* https://tools.ietf.org/html/rfc4007#section-11 "to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well."
Tor is unable to handle this % syntax in a resolv.conf line:
```
Jan 25 17:03:00.171 [warn] eventdns: Unable to parse nameserver address fe80::7e2ebdff:fe99:4cb9%enp2s0
```
It's not as bad as it could be, because Tor skips that line and uses whatever other lines there are. But (a) maybe we're not doing as well as we can do, and (b) maybe there are situations where that's the only configured nameserver and everything works on the host except Tor doesn't.
I think technically this might be a libevent bug (aka missing feature), since it's libevent's evdns_base_nameserver_ip_add() which calls evutil_parse_sockaddr_port() which helpfully explains that
```
/* recognized formats are:
* [ipv6]:port
* ipv6
* [ipv6]
* ipv4:port
* ipv4
*/
```
none of which are the % syntax. But I will file it here as a Tor ticket, since it's a Tor bug too, and then we can figure out where best to fix it.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33073Write a proposal for Tor Relays to Automatically Find their IPv6 Address2020-06-27T13:48:25ZteorWrite a proposal for Tor Relays to Automatically Find their IPv6 AddressFor Sponsor 55, I need to write a proposal for IPv6 address detection on relays.For Sponsor 55, I need to write a proposal for IPv6 address detection on relays.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33159Write a proposal for monitoring IPv62020-06-27T13:48:22ZteorWrite a proposal for monitoring IPv6For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (legacy/trac#33051)
* O1.5 - Measure the number of connections, and consumed bandwid...For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (legacy/trac#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6 (legacy/trac#33052)
My current thinking is that:
* tor should log the number and consensus weight of relays that support IPv6 reachability checks, because we will need those numbers during testing
* these numbers are available in the consensus
Here's what the proposal requires:
* calculate relay IPv6 reachability numbers a few times during the project (we may as well use the tor logs)
* collect IPv6 connection and bandwidth statistics on tor relays
* calculate the IPv6 connection and bandwidth amounts a few times during the project
Here are some other useful things we might do:
* split the collected IPv6 statistics by client/relay
* calculate the guard-but-not-exit relays that support IPv6 client connections
* log IPv6 statistics in tor's heartbeat logs (we can't use these logs for our project reports, because they only show the local relay's statistics)
* calculate IPv6 reachability relay count and consensus weight on consensus-health
* add a pseudo-flag for relay IPv6 reachability support in Relay Search
* add metrics graphs that shows our progress on
* IPv6 reachability
* client IPv6 support on relays
* IPv6 connections and bandwidth
We definitely won't have time to do all of these optional things, so we should priorise, once the essential work is done.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33195Require IPv6 tests in Travis CI2020-06-27T13:48:21ZteorRequire IPv6 tests in Travis CIWhile we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas th...While we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas that I can make fast_finish.
I think our Rust build might be a good candidate for fast_finish, we haven't changed that code much in about a year. But I should check with the team before making this change.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33224Prop 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus Parameter2020-06-27T13:48:19ZteorProp 311: 4.3.2. Add AssumeReachableIPv6 Option and Consensus ParameterWe add an AssumeReachableIPv6 torrc option and consensus parameter.
If IPv6 ORPort checks have bugs that impact the health of the network,
they can be disabled by setting AssumeReachableIPv6=1 in the consensus
parameters.
If IPv6 ORPor...We add an AssumeReachableIPv6 torrc option and consensus parameter.
If IPv6 ORPort checks have bugs that impact the health of the network,
they can be disabled by setting AssumeReachableIPv6=1 in the consensus
parameters.
If IPv6 ORPort checks have bugs that impact a particular relay (or bridge),
they can be disabled by setting "AssumeReachableIPv6 1" in the relay's
torrc.
This option disables IPv6 ORPort reachability checks, so relays publish
their descriptors if their IPv4 ORPort reachability checks succeed.
(Unlike AssumeReachable, AssumeReachableIPv6 has no effect on the existing
dirauth IPv6 reachability checks, which connect directly to relay ORPorts.)
The default for the torrc option is "auto", which checks the consensus
parameter. If the consensus parameter is not set, the default is "0".
"AssumeReachable 1" overrides all values of "AssumeReachableIPv6",
disabling both IPv4 and IPv6 ORPort reachability checks. Tor should warn if
AssumeReachable is 1, but AssumeReachableIPv6 is 0. (On directory
authorities, "AssumeReachable 1" also disables dirauth IPv4 and IPv6
reachability checks, which connect directly to relay ORPorts.
AssumeReachableIPv6 does not disable directory authority to relay IPv6
checks.)
See proposal 311, section 4.3.2:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n403Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33226Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"2020-06-27T13:48:19ZteorProp 311: 5. Declare Support for Subprotocol Version "Relay=3"This ticket depends on relay IPv6 extends in legacy/trac#33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this propo...This ticket depends on relay IPv6 extends in legacy/trac#33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See proposal 311, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n601Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33227Prop 311: 5.1. Update Tor Spec Relay Subprotocols2020-06-27T13:48:18ZteorProp 311: 5.1. Update Tor Spec Relay SubprotocolsWe propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually ...We propose the following changes to the [Tor Specification], once this
proposal is implemented.
Adding a new Relay subprotocol version lets testing relays identify other
relays that support IPv6 extends. It also allows us to eventually recommend
or require support for IPv6 extends on all relays.
For the draft text, see proposal 311, section 5.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n608Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33234Prop 312: 3.2.1. Make the Address torrc Option Resolve IPv6 Hostnames2020-06-27T13:48:18ZteorProp 312: 3.2.1. Make the Address torrc Option Resolve IPv6 HostnamesThis ticket depends on `Address IPv6` support in legacy/trac#33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
2. Hostnames / DNS names:
*...This ticket depends on `Address IPv6` support in legacy/trac#33233.
Make relays and bridges use the Address torrc option to find their IPv6 addresses.
This ticket covers the IPv6 hostname / DNS case:
2. Hostnames / DNS names:
* allow the option to be specified up to two times,
* look up the configured name,
* use the first IPv4 and IPv6 address returned by the resolver, and
Resolving multiple addresses in the same address family is not a
runtime error, but only the first address from each family will be
used.
These lookups should ignore private addresses on public tor networks. If
multiple IPv4 or IPv6 addresses are returned, the first public address from each family should be used.
Tor should warn if a configured Address hostname does not resolve
to any publicly routable IPv4 or IPv6 addresses. (If
tor is configured with a custom set of directory authorities, private
addresses should be allowed, with a notice-level log.)
For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory authorities only accept IPv4 or IPv6 address literals in their Address option. They must not attempt to resolve their Address using DNS. It is a config error to provide a hostname as a directory authority's Address.
See proposal 312, section 3.2.1, case 2:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n258Sponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33242Prop 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory Fetches2020-06-27T13:48:17ZteorProp 312: 3.2.5. Make Relays do IPv4 and IPv6 Directory FetchesRelays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients...Relays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients. (So they can't find their IPv6 addresses in this way.)
We propose to use a simple load balancing scheme for IPv4 and IPv6
directory requests:
* choose between IPv4 and IPv6 directory requests at random.
We do not expect this change to have any load-balancing impact on the public
tor network, because the number of relays is much smaller than the number
of clients. However, the 6 directory authorities with IPv6 enabled may see
slightly more directory load, particularly over IPv6.
See proposal 312, section 3.2.5, directory fetch part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n429https://gitlab.torproject.org/tpo/core/tor/-/issues/33243Prop 312: 3.2.5. Handle IPv6 Directory Fetch Failures2020-06-27T13:48:17ZteorProp 312: 3.2.5. Handle IPv6 Directory Fetch FailuresRelays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients...Relays should start fetching directory documents over IPv4 and IPv6, so they can use X-Your-Address-Is HTTP headers to find their IPv6 addresses.
Bridges must only fetch directory documents over IPv4, because they try to imitate clients. (So they can't find their IPv6 addresses in this way.)
To support this change, tor should also change how it handles IPv6
directory failures on relays:
* avoid recording IPv6 directory failures as remote relay failures,
because they may actually be due to a lack of IPv6 connectivity on the
local relay, and
* issue IPv6 directory failure logs at notice level, and rate-limit them
to one per hour.
If a relay is:
* explicitly configured with an IPv6 address, or
* a publicly routable, reachable IPv6 address is discovered in an
earlier step,
tor should start issuing IPv6 directory failure logs at warning level. Tor
may also record these directory failures as remote relay failures. (Rather
than ignoring them, as described in the previous paragraph.)
See proposal 312, section 3.2.5, IPv6 directory failure part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n457https://gitlab.torproject.org/tpo/core/tor/-/issues/33249Prop 312: 4. Update Directory Spec for IPv6 X-Your-Address-Is2020-06-27T13:48:16ZteorProp 312: 4. Update Directory Spec for IPv6 X-Your-Address-IsWe should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we sho...We should explicitly support IPv6 X-Your-Address-Is HTTP headers in the tor directory protocol.
We need to decide whether IPv6 X-Your-Address-Is headers should be formatted enclosed in square brackets. To help with this decision, we should look at what relays currently do (in tor 0.3.5 to 0.4.2, as of January 2020).
See proposal 312, section 4, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1432