Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:02:36Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13043torspec lies about accepting both IPv4 and IPv6 for ORAddress lines2020-06-27T14:02:36ZIsis Lovecrufttorspec lies about accepting both IPv4 and IPv6 for ORAddress lines(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, desp...(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, despite what `dir-spec.txt` says.
The spec [says](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l1166):
```
"a" SP address ":" port NL
[Any number]
The "or-address" element as specified in section 2.1.1.
```
[and](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l587):
```
"or-address" SP ADDRESS ":" PORT NL
[Any number]
ADDRESS = IP6ADDR | IP4ADDR
IPV6ADDR = an ipv6 address, surrounded by square brackets.
IPV4ADDR = an ipv4 address, represented as a dotted quad.
PORT = a number between 1 and 65535 inclusive.
An alternative for the address and ORPort of the "router" line, but with
two added capabilities:
* or-address can be either an IPv4 or IPv6 address
* or-address allows for multiple ORPorts and addresses
A descriptor SHOULD NOT include an or-address line that does nothing but
duplicate the address:port pair from its "router" line.
The ordering of or-address lines and their PORT entries matter because
Tor MAY accept a limited number of addresses or ports. As of Tor 0.2.3.x
only the first address and the first port are used.
```
- In terms of how many `"a"`/`"or-address"` lines there may be, the spec is only correct if you pay _super close attention to the last sentence_ (this is actually the first time I've noticed it :) ).
- In terms of whether IPv4 and/or IPv6 addresses are acceptable, _the spec is currently wrong_, according to the functions `router_rebuild_descriptor()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l1811 [source]] and `router_dump_router_to_string()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l2330 [source]] in `src/or/router.c` in tor's source code.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15235Identify the state of IPv6 support in Tor2020-06-27T14:01:33ZNick MathewsonIdentify the state of IPv6 support in TorWhat works for IPv6 today? What doesn't? What's hard to configure?
* Can clients use ipv6 to connect to Tor?
* Can clients resolve Ipv6 addresses with Tor?
* Does automapping to ipv6 addresses work?
* Can we exit to ipv6?
* Can bridge...What works for IPv6 today? What doesn't? What's hard to configure?
* Can clients use ipv6 to connect to Tor?
* Can clients resolve Ipv6 addresses with Tor?
* Does automapping to ipv6 addresses work?
* Can we exit to ipv6?
* Can bridges be IPv6-only? (no, I don't think so)
* Can relays be IPv6 only? (no)
And many more.
We should ideally not only hand-check tehse issues, but write tests for some of them.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15518Tor considers routers in the same IPv6 /16 to be "in the same subnet"2020-06-27T14:01:27ZIsis LovecruftTor considers routers in the same IPv6 /16 to be "in the same subnet"When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses ...When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses
* that we should treat them as being in the same family */
static INLINE int
addrs_in_same_network_family(const tor_addr_t *a1,
const tor_addr_t *a2)
{
return 0 == tor_addr_compare_masked(a1, a2, 16, CMP_SEMANTIC);
}
```
to determine if an address is in the same family. For an example IPv6 address, `2001:1234::0:1`, its /16 representation is `2001::/16`, meaning that `2001:ffff::` would be in the same family. A `\16` for IPv6 is _huge_, particularly considering that [only one-eighth of all IPv6 space is currently allocated for use on the internet](https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml) (`2000::/3`). For the path selection code, using `/16` essentially means that no two IPv6 routers in the same country (or possibly even continent) will be in the same path, and might possibly provide extremely increased chance of selection to routers in weird/rare IPv6 subnets.
For a related ticket, see legacy/trac#15517 governing how BridgeDB's version of `EnforceDistinctSubnets` will work for IPv6. (In that ticket, I proposed using IPv6 `/32`s, since that is the [minimum ARIN IPv6 subnet allocation for a LIR](https://www.arin.net/resources/request/ipv6_initial_assign.html).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/16069ipv4 + ipv6 exit : v6 policy is displayed twice, v4 isn't displayed2020-06-27T14:01:12Ztoralfipv4 + ipv6 exit : v6 policy is displayed twice, v4 isn't displayedI do have 2 different exit policies for ipv6 (just 6 rules) and ipv4 (reduced exit policy) but the status page shows the ipv6 rule set for ipv4 too :
https://atlas.torproject.org/#details/F1BE15429B3CE696D6807F4D4A58B1BFEC45C822I do have 2 different exit policies for ipv6 (just 6 rules) and ipv4 (reduced exit policy) but the status page shows the ipv6 rule set for ipv4 too :
https://atlas.torproject.org/#details/F1BE15429B3CE696D6807F4D4A58B1BFEC45C822Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17153tor test networks should allow IPv6 private addresses2020-06-27T14:00:34Zteortor test networks should allow IPv6 private addresses`net/nodes/003br/notice.log:Sep 25 09:42:34.000 [warn] Unable to use configured IPv6 address "[::1]" in a descriptor. Skipping it. Try specifying a globally reachable address explicitly.`
I'm sure there's a tor option that allows privat...`net/nodes/003br/notice.log:Sep 25 09:42:34.000 [warn] Unable to use configured IPv6 address "[::1]" in a descriptor. Skipping it. Try specifying a globally reachable address explicitly.`
I'm sure there's a tor option that allows private addresses in descriptors for IPv4. It should do that for IPv6 as well.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17281Make IPv6-only clients work and bootstrap2020-06-27T14:00:26ZNick MathewsonMake IPv6-only clients work and bootstrapWe have a big pile of IPv6 tickets, but none of them actually is for this.
If you start a tor client on an IPv6-only connection, it should bootstrap and connect to the network happily.
Part of this can be solved through the use of fall...We have a big pile of IPv6 tickets, but none of them actually is for this.
If you start a tor client on an IPv6-only connection, it should bootstrap and connect to the network happily.
Part of this can be solved through the use of fallback directories on ipv6, but we need to make sure that the code actually works (legacy/trac#15235)Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17327DirAuthority IPv62020-06-27T14:00:24ZTracDirAuthority IPv6When I try set DirAuthority to IPv6 like that:
```
DirAuthority xxxxx orport=5000 no-v2 v3ident=xxxxxxxxxxxxxxxxxxx [xxx:xxxx:xxxx:xxxx:xxxx:xxxxx:xxxx:xxxx]:7000 fingerxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```
I see error in stdout:
Oct 12 16:...When I try set DirAuthority to IPv6 like that:
```
DirAuthority xxxxx orport=5000 no-v2 v3ident=xxxxxxxxxxxxxxxxxxx [xxx:xxxx:xxxx:xxxx:xxxx:xxxxx:xxxx:xxxx]:7000 fingerxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```
I see error in stdout:
Oct 12 16:04:44.091 [warn] Unrecognized flag
```
Oct 12 16:04:44.091 [warn] Unrecognized flag '[xxx:xxxx:xxxx:xxxx:xxxx:xxxxx:xxxx:xxxx]:7000' on DirAuthority line
Oct 12 16:04:44.091 [warn] Unrecognized flag 'fingerxxxxxxxxxxxxxxxxxxxxxxxxx' on DirAuthority line
```
**Trac**:
**Username**: svirusTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17376Cannot bootstrap over IPv62020-06-27T14:00:23ZTracCannot bootstrap over IPv6Using the current public TorBrowser build, I cannot connect to the Tor network from some machines.
torbrowser error dialog:
```
Tor failed to establish a Tor network connection.
Connecting to a relay directory failed (no route to host...Using the current public TorBrowser build, I cannot connect to the Tor network from some machines.
torbrowser error dialog:
```
Tor failed to establish a Tor network connection.
Connecting to a relay directory failed (no route to host - 199.254.238.52:443).
```
torbrowser log:
```
18/10/2015, 21:46:46.600 [NOTICE] Opening Socks listener on 127.0.0.1:9150
18/10/2015, 21:46:46.600 [NOTICE] Renaming old configuration file to "/Applications/TorBrowser.app/TorBrowser/Data/Tor/torrc.orig.1"
18/10/2015, 21:46:46.600 [NOTICE] Bootstrapped 5%: Connecting to directory server
18/10/2015, 21:46:46.600 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 1; recommendation warn; host 7EA6EAD6FD83083C538F44038BBFA077587DD755 at 194.109.206.212:443)
18/10/2015, 21:50:13.000 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 2; recommendation warn; host 847B1F850344D7876491A54892F904934E4EB85D at 86.59.21.38:443)
18/10/2015, 21:50:13.000 [WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 3; recommendation warn; host F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 at 131.188.40.189:443)
```
Two of the addresses attempted here actually belong to hosts that have IPv6 connectivity: https://gist.github.com/sdstrowes/9e5cf5a3f2fe48ef3979 These hosts have the correct ports open and are listening, but TorBrowser doesn't try to connect. It's not always the case that hosts at this stage have IPv6, but at least some do.
References to 127.0.0.0/8 smells v4-specific, which isn't useful without IPv4 end-to-end. NAT64 won't help in this instance.
**Trac**:
**Username**: sdstroweshttps://gitlab.torproject.org/tpo/core/tor/-/issues/17573Update max_dl_per_request for IPv6 address length2020-06-27T14:00:18ZteorUpdate max_dl_per_request for IPv6 address lengthmax_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets...max_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets.)
While we're doing that, it would be nice to add a comment with the microdescriptor length calculation as well.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17638Make ersatz_socketpair work on IPv6-only systems:2020-06-27T14:00:14ZteorMake ersatz_socketpair work on IPv6-only systems:Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have I...Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have IPv6 localhost (some FreeBSD jails). Instead, they have a non-127/8, non-::1 IP address used as the default:
ersatz_socketpair currently uses INADDR_LOOPBACK. On IPv6, it should use ::1 (or a constant or function returning it). If that fails with E(address not found) (or WSAE(address not found) on Windows), that's actually what we want - we don't want to accidentally expose a socketpair on a routable address.
We should also remove the check in the ersatz_socketpair unit test that bails out on EPROTONOSUPPORT.
Patch on a version before 22dba27d8dd5 (23 Nov 2004) / svn:r2943.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17726IPv6 relay-to-relay communication2020-06-27T14:00:08ZtwimIPv6 relay-to-relay communicationA ticket to track work on enabling IPv6 relay-to-relay communication.
Should also resolve closely related ticket legacy/trac#5788 as consequence.A ticket to track work on enabling IPv6 relay-to-relay communication.
Should also resolve closely related ticket legacy/trac#5788 as consequence.https://gitlab.torproject.org/tpo/core/tor/-/issues/17817Add ipv6 authority and fallback flag to GETINFO config/defaults2020-06-27T14:00:01ZteorAdd ipv6 authority and fallback flag to GETINFO config/defaultslegacy/trac#17327 adds an ipv6=address:orport flag to authorities and fallback directories.
This should be included in GETINFO config/defaults.
Please see legacy/trac#16774 for work on including fallback directories in config/defaults.legacy/trac#17327 adds an ipv6=address:orport flag to authorities and fallback directories.
This should be included in GETINFO config/defaults.
Please see legacy/trac#16774 for work on including fallback directories in config/defaults.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17834Add ClientPreferIPv6DirPort2020-06-27T14:00:00ZteorAdd ClientPreferIPv6DirPortAdd ClientPreferIPv6DirPort to express a preference for IPv6 directory connections over IPv4 directory connections.
Tor already has ClientPreferIPv6ORPort, which expresses a preference for IPv6 OR connections over IPv4 OR connections.
...Add ClientPreferIPv6DirPort to express a preference for IPv6 directory connections over IPv4 directory connections.
Tor already has ClientPreferIPv6ORPort, which expresses a preference for IPv6 OR connections over IPv4 OR connections.
(ClientUseIPv6 allows the use of IPv6 connections, ClientPreferIPv6ORPort/ClientPreferIPv6DirPort are the tie-breakers if IPv4 and IPv6 are both equally likely.)
While we're doing this, let's warn on nonsensical situations like ClientPreferIPv6* 1 ClientUseIPv6 0. (Although ClientPreferIPv6* 0 ClientUseIPv6 1 should be an info or notice, as ClientPreferIPv6* 0 is the default.)Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17849Warn if single-stack IPv4/IPv6 clients have very restricted guard choices2020-06-27T13:59:58ZteorWarn if single-stack IPv4/IPv6 clients have very restricted guard choicesYawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Yawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17854Use ClientIPv4 and ClientIPv6 to select a bridge address2020-06-27T13:59:57ZteorUse ClientIPv4 and ClientIPv6 to select a bridge addressIf a bridge has an IPv4 and an IPv6 address, and a tor client knows both, it should select the address family based on the values of:
* ClientUseIPv4
* ClientUseIPv6
* ClientPreferIPv6ORPort ?
(I don't think ClientPreferIPv6DirPort is r...If a bridge has an IPv4 and an IPv6 address, and a tor client knows both, it should select the address family based on the values of:
* ClientUseIPv4
* ClientUseIPv6
* ClientPreferIPv6ORPort ?
(I don't think ClientPreferIPv6DirPort is relevant here.)
This code works as-is, so I don't see any reason to change it urgently.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17863Fixes to IPv6 address handling2020-06-27T13:59:57ZteorFixes to IPv6 address handlingI've made some fixes to IPv6 address handling:
* make address policy assume_action work for []-quoted IPv6 addresses
* unquoted addresses are ambiguous, because of the port separator ":", and "accept" starting with 4 hex digits
* limit...I've made some fixes to IPv6 address handling:
* make address policy assume_action work for []-quoted IPv6 addresses
* unquoted addresses are ambiguous, because of the port separator ":", and "accept" starting with 4 hex digits
* limit IPv6 mask bits to 128
* warn when comparing against an AF_UNSPEC address in a policy
* no code wants this to happen, and it produces unexpected results
Branch coming soon.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17889Make ClientPreferIPv6ORPort apply to bridge clients2020-06-27T13:59:56ZteorMake ClientPreferIPv6ORPort apply to bridge clientsAfter legacy/trac#17840, clients that don't use bridges will select ORPorts using ClientPreferIPv6ORPort.
We could do this for bridges as well, by modifying the new function fascist_firewall_choose_address_base:
* use ClientPreferIPv6OR...After legacy/trac#17840, clients that don't use bridges will select ORPorts using ClientPreferIPv6ORPort.
We could do this for bridges as well, by modifying the new function fascist_firewall_choose_address_base:
* use ClientPreferIPv6ORPort to choose a preferred address for bridge clients,
* but ignore the "preferred address only setting", so that bridge users always get an address if there is one available.
I don't want to do this as part of legacy/trac#17840, because I'm not sure if it's really necessary - bridges just seem to work ok as-is.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17907Modify clients to consistently send N% of initial consensus requests to the a...2020-06-27T13:59:55ZteorModify clients to consistently send N% of initial consensus requests to the authoritiesWe currently use the directory authority statistics to estimate the number of clients in the Tor network.
But fallback directories will handle initial consensus downloads in future releases.
So, to preserve client statistics, we can mo...We currently use the directory authority statistics to estimate the number of clients in the Tor network.
But fallback directories will handle initial consensus downloads in future releases.
So, to preserve client statistics, we can modify Tor clients to make a certain small percentage (1%?) of initial consensus downloads to the directory authorities. If we scale the authority downloads from each Tor release by this factor, we can estimate the number of clients.
This is particularly important for client IPv6 bootstrap (legacy/trac#17840), as only some authorities and fallbacks have IPv6 (and the proportion of fallbacks is lower than the proportion of authorities).
We could change the meaning of DirAuthorityFallbackRate to "the authorities see this proportion of queries", or implement another option, and document the interaction with DirAuthorityFallbackRate.
(I think the second option is better, but we'd end up essentially obsoleting DirAuthorityFallbackRate.)Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17948HiddenServicePort should connect to localhost by default2020-06-27T13:59:52ZteorHiddenServicePort should connect to localhost by defaultHiddenServicePort currently connects to 127.0.0.1 by default, but this will fail in configs where localhost is somewhere else in 127.0.0.0/8 or is [::1]. (Such as BSD jails.)
Instead, we can:
* resolve "localhost", and check that it's i...HiddenServicePort currently connects to 127.0.0.1 by default, but this will fail in configs where localhost is somewhere else in 127.0.0.0/8 or is [::1]. (Such as BSD jails.)
Instead, we can:
* resolve "localhost", and check that it's in 127.0.0.0/8 or [::1], and use the IPv4 address first for compatibility with existing configurations
* default to 127.0.0.1 if that exists
* default to [::1] if 127.0.0.1 does not exist
This is not a security issue, as it results in a failed hidden service connection on unusual configs. It's a minor usability issue.
(Split from legacy/trac#17901 / legacy/trac#11360.)Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17951Make address family search via UDP socket hack more accurate2020-06-27T13:59:51ZteorMake address family search via UDP socket hack more accurateThe following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it s...The following address family search functions don't always return an IPv6 address:
* get_interface_address6_via_udp_socket_hack takes an address family as its first argument
* when get_interface_address6_list is passed AF_UNSPEC, it should be call get_interface_address6_via_udp_socket_hack with AF_INET, and then AF_INET6, and then both addresses should be returnedTor: 0.2.8.x-finalrl1987rl1987