Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:50:46Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29613Make relays into exits when ExitRelay is auto and IPv6Exit is 12020-06-27T13:50:46ZteorMake relays into exits when ExitRelay is auto and IPv6Exit is 1In legacy/trac#21530, we made relays exit if ExitRelay is auto, and either:
* ReducedExitPolicy is 1, or
* ExitPolicy is set
But a relay operator who sets IPv6Exit to 1 also wants to be an exit.
So we should add `IPv6Exit 1` to the opt...In legacy/trac#21530, we made relays exit if ExitRelay is auto, and either:
* ReducedExitPolicy is 1, or
* ExitPolicy is set
But a relay operator who sets IPv6Exit to 1 also wants to be an exit.
So we should add `IPv6Exit 1` to the options that activate exits when ExitRelay is auto. We should also update the documentation (see legacy/trac#29612).Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/29570Stop relays publishing descriptors containing NoListen IPv6 ORPorts2020-07-29T03:08:55Zs7rStop relays publishing descriptors containing NoListen IPv6 ORPortsFor details:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016988.html
and my reply:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016991.html
This is one rare and strange setup of using IPv6 in a w...For details:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016988.html
and my reply:
https://lists.torproject.org/pipermail/tor-relays/2019-February/016991.html
This is one rare and strange setup of using IPv6 in a way it is not intended, but we should still make sure that:
- if ORPort [IPv6:address::x]:port **NoListen** was set in torrc, and there is no following ORPort [IPv6:address::y]:port **NoAdvertise** or [::]:port **NoAdvertise** (as in use all available IPv6 addresses) is set, warn in the log and **do not build the descriptor using the NoListen address**, since the daemon is not listening on any address from the v6 class.
- check if the logic is applied for IPv4 also, even it's impossible to experience this in IPv4 since UnreachableIPv4 doesn't exist and can't possibly exist.
Otherwise we fill the descriptor with useless data and also have the directory authorities chase green horses.
I think we have this since forever, but not marking this as a backport given the rare cases when it can occur and the state of current IPv6 adoption.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29243Fix minor bugs in the HSv3 unit tests2021-06-23T17:26:03ZteorFix minor bugs in the HSv3 unit testsThe tests:
* copy the first 20 characters of a 40-character hex string to a binary fingerprint
* put IPv6 addresses in a variable called "ipv4"
* do a duplicate tt_int_op() to deliberately fail and print a value, without a comment explai...The tests:
* copy the first 20 characters of a 40-character hex string to a binary fingerprint
* put IPv6 addresses in a variable called "ipv4"
* do a duplicate tt_int_op() to deliberately fail and print a value, without a comment explaining the code
Let's review these changes in legacy/trac#23576.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29237Restore IPv6 intro points in the HS client tests2021-06-23T17:26:03ZteorRestore IPv6 intro points in the HS client testsIn legacy/trac#23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.In legacy/trac#23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29113Add IPv4/IPv6 connections to the heartbeat2020-08-25T12:43:39ZteorAdd IPv4/IPv6 connections to the heartbeatWhen we implement IPv6 extends, we'll need to monitor how many IPv4 and IPv6 connections a relay is making, using every combination of:
* IPv4/IPv6
* initiate/accept
We may also want to add the reason that the connection was initiated:
...When we implement IPv6 extends, we'll need to monitor how many IPv4 and IPv6 connections a relay is making, using every combination of:
* IPv4/IPv6
* initiate/accept
We may also want to add the reason that the connection was initiated:
* IPv4/IPv6
* reachability (origin, authorities only) / client (origin, authorities and relay also act as clients) / extend (relays and authorities only)
It's probably safe to also count all reachability circuits, but it might not be safe to count client circuits on clients, or extend circuits. Let's think about the privacy implications before adding these to the heartbeat.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29015Document tor_ersatz_socketpair() and the functions it calls2021-07-22T16:20:05ZteorDocument tor_ersatz_socketpair() and the functions it callsThe function comments in socketpair.c are missing or incomplete.
Maybe we should add function comments, using the tor_socketpair() comment as a starting point?
https://github.com/torproject/tor/blob/701eaef980de4f7dbb5c31c4fee9b7e1e266...The function comments in socketpair.c are missing or incomplete.
Maybe we should add function comments, using the tor_socketpair() comment as a starting point?
https://github.com/torproject/tor/blob/701eaef980de4f7dbb5c31c4fee9b7e1e266d7a1/src/lib/net/socket.c#L450Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28995Fix the IPv6 case of tor_ersatz_socketpair2020-06-27T13:51:16ZTracFix the IPv6 case of tor_ersatz_socketpairIn `get_local_listener` which is used by `tor_ersatz_socketpair`, `sin6_family` is currently being set to `AF_INET` in the IPv6 case when `AF_INET6` should be used instead.
This code was introduced in commit 9b24609af003cb79091e628c179c...In `get_local_listener` which is used by `tor_ersatz_socketpair`, `sin6_family` is currently being set to `AF_INET` in the IPv6 case when `AF_INET6` should be used instead.
This code was introduced in commit 9b24609af003cb79091e628c179cf617ff41aae7 from this past August, so this is not a brand-new problem.
I tested this on my OpenBSD box by forcing an IPv6 socket to be used for `tor_ersatz_socketpair` and running the test suite. There is a test in the test suite that tests `tor_ersatz_socketpair`: it (of course) fails using the current `AF_INET` code but it passes when using `AF_INET6` instead.
PR to follow to change `AF_INET` to `AF_INET6` in the IPv6 case.
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28919Log IPv4 and IPv6 connections in Tor's heartbeat message2020-06-27T13:51:21ZteorLog IPv4 and IPv6 connections in Tor's heartbeat messageDo we already keep IPv4 and IPv6 statistics?
If we do, then this ticket is easy.
If not, then it's a bit harder, because we'll need to add some code to rephist (or wherever we get the other stats from).Do we already keep IPv4 and IPv6 statistics?
If we do, then this ticket is easy.
If not, then it's a bit harder, because we'll need to add some code to rephist (or wherever we get the other stats from).Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28653Specify IPv4 and IPv6 weight calculations in dir-spec.txt2020-06-27T13:51:31ZteorSpecify IPv4 and IPv6 weight calculations in dir-spec.txtIn legacy/trac#27647, we set the initial IPv6 weight based on the number of entry nodes that support IPv4, IPv6, or both.
We need to specify these calculations.In legacy/trac#27647, we set the initial IPv6 weight based on the number of entry nodes that support IPv4, IPv6, or both.
We need to specify these calculations.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28525Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale...2021-08-23T15:16:06ZNeel Chauhanneel@neelc.orgMake tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 RangesWith the IPv4 depletion, many ISPs, cell carriers and cloud providers are deploying Carrier Grade NAT with the subnet defined in RFC 6598 (100.64.0.0/10). We should make Tor aware of this range as it is internal as well.
I will write a ...With the IPv4 depletion, many ISPs, cell carriers and cloud providers are deploying Carrier Grade NAT with the subnet defined in RFC 6598 (100.64.0.0/10). We should make Tor aware of this range as it is internal as well.
I will write a patch and give a link to a GitHub PR.Tor: 0.2.9.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/28057When randomly choosing IPv4 or IPv6, log better IPv6 preference info2020-06-27T13:51:54ZteorWhen randomly choosing IPv4 or IPv6, log better IPv6 preference infoconnection_connect_log_client_use_ip_version() logs an info-level message when ClientPreferIPv6ORPort isn't satisfied:
https://github.com/torproject/tor/blob/df2b46d18c4a3d6e5eb364f80111ef6c7811383c/src/core/mainloop/connection.c#L2019
...connection_connect_log_client_use_ip_version() logs an info-level message when ClientPreferIPv6ORPort isn't satisfied:
https://github.com/torproject/tor/blob/df2b46d18c4a3d6e5eb364f80111ef6c7811383c/src/core/mainloop/connection.c#L2019
We should update it for ClientAutoIPv6ORPort.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27736Make sure that Tor doesn't build an IPv4 and an IPv6 connection to the same r...2020-08-07T17:16:00ZteorMake sure that Tor doesn't build an IPv4 and an IPv6 connection to the same relayWhen we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code t...When we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code to make sure this check is done on clients and relays. And I need to run the new code to make sure we're not doubling the number of connections that Tor clients make.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27648Stop setting the IPv6 preferred flag on nodes2020-07-28T23:00:38ZteorStop setting the IPv6 preferred flag on nodesInstead:
* for guards, decide on the address to use at random
* for bridges, decide on the address to use at random, but make it more likely that we will use the configured addressInstead:
* for guards, decide on the address to use at random
* for bridges, decide on the address to use at random, but make it more likely that we will use the configured addressTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27647When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weight2020-06-27T13:52:13ZteorWhen randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weightWe can't make 50% of clients use IPv6 until most relays have IPv6. Otherwise, we would overload the IPv6 Guards. Right now, about 25% of Guard consensus weight has IPv6:
https://metrics.torproject.org/advbw-ipv6.html
When we are randoml...We can't make 50% of clients use IPv6 until most relays have IPv6. Otherwise, we would overload the IPv6 Guards. Right now, about 25% of Guard consensus weight has IPv6:
https://metrics.torproject.org/advbw-ipv6.html
When we are randomly choosing IPv4 or IPv6, we need to set the initial IPv6 probability based on the IPv6 Guard consensus weight. (Or the number of IPv6 bridges, if we're using bridges.)
With IPv4-only, IPv6-only, and DualStack Entry nodes, the formulas are:
```
IPv4-capable-weight = IPv4-only + DualStack
IPv6-capable-weight = IPv6-only + DualStack
Total-weight = IPv4-only + IPv6-only + DualStack
IPv4-capable-fraction = IPv4-capable-weight / Total-weight
IPv6-capable-fraction = IPv6-capable-weight / Total-weight
IPv4-probability = IPv4-capable-fraction / (IPv4-capable-fraction + IPv6-capable-fraction)
IPv6-probability = IPv6-capable-fraction / (IPv4-capable-fraction + IPv6-capable-fraction)
```
We should update these probabilities whenever we get a new consensus, new bridge lines, or new bridge descriptors.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27491Prefer IPv4 or IPv6 based on the number of failures2020-06-27T13:52:17ZNeel Chauhanneel@neelc.orgPrefer IPv4 or IPv6 based on the number of failuresSuggested by teor at legacy/trac#17835:
> 3. If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while
> 4. When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much
> 5. When there are ...Suggested by teor at legacy/trac#17835:
> 3. If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while
> 4. When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much
> 5. When there are a lot more IPv6 than IPv4 failures, don't try IPv6 as much
> 6. After a while, forget old failuresTor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27490When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a...2020-06-27T13:52:17ZNeel Chauhanneel@neelc.orgWhen ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at legacy/trac#17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at legacy/trac#17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomTor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27284Check IPv6 exit policies on microdescs2020-06-27T13:52:28ZteorCheck IPv6 exit policies on microdescsIn node_exit_policy_rejects_all(), we check IPv4 and IPv6 policies on ri, but on md we only check IPv4:
```
else if (node->md)
return node->md->exit_policy == NULL ||
short_policy_is_reject_star(node->md->exit_policy);
```
O...In node_exit_policy_rejects_all(), we check IPv4 and IPv6 policies on ri, but on md we only check IPv4:
```
else if (node->md)
return node->md->exit_policy == NULL ||
short_policy_is_reject_star(node->md->exit_policy);
```
One way to fix this issue is to refactor the existing code to check a new policy_is_reject_star, and then populate policy_is_reject_star when the md is parsed. (Like we already do with the ri.)Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27251Add single-onion-v23-ipv6-md to make test-network-all2021-09-30T13:45:56ZteorAdd single-onion-v23-ipv6-md to make test-network-allWhen IPv6 single onion services work, we should add the single-onion-v23-ipv6-md to TEST_CHUTNEY_FLAVORS_IPV6in src/test/include.am.
We can also remove single-onion-ipv6-md, because it's redundant.When IPv6 single onion services work, we should add the single-onion-v23-ipv6-md to TEST_CHUTNEY_FLAVORS_IPV6in src/test/include.am.
We can also remove single-onion-ipv6-md, because it's redundant.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27204add info for IPv6-only hosts to torrc man page2021-07-22T16:20:36Ztraumschuleadd info for IPv6-only hosts to torrc man pageAdd a sentence to the ClientUseIPv6 section of the tor man page:
> For IPv6 only hosts, you need to also set **ClientUseIPv4** to 0 to disable IPv4.Add a sentence to the ClientUseIPv6 section of the tor man page:
> For IPv6 only hosts, you need to also set **ClientUseIPv4** to 0 to disable IPv4.Tor: 0.3.5.x-finaltraumschuletraumschulehttps://gitlab.torproject.org/tpo/core/tor/-/issues/27086Write unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_i...2021-09-30T13:45:56ZteorWrite unit tests for fascist_firewall_choose_address_ls() and hs_get_extend_info_from_lspecs()The branch in legacy/trac#23588 doesn't have unit tests, so we should write some.The branch in legacy/trac#23588 doesn't have unit tests, so we should write some.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org