Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:00:00Zhttps://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/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/17811Tor Clients on IPv62020-07-27T18:24:13ZteorTor Clients on IPv6This is a top-level task that tracks the progress of IPv6 tor client support.This is a top-level task that tracks the progress of IPv6 tor client support.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17787Improve address detection on multihomed relays2020-07-27T18:20:28ZteorImprove address detection on multihomed relaysIf tor finds multiple publicly routable interface addresses, it will choose the first one returned by the syscall.
Do we know if the syscall always returns addresses in the same order?
If not, we should sort them, or perhaps include bo...If tor finds multiple publicly routable interface addresses, it will choose the first one returned by the syscall.
Do we know if the syscall always returns addresses in the same order?
If not, we should sort them, or perhaps include both addresses in the descriptor?
This issue can be mitigated by the operator explicitly choosing an address using the Address torrc option.
Only an operator knows the preferred address on a multihomed relay, or if they want to use both.
Therefore, I'm marking this low priority.Tor: unspecifiedhttps://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/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/17636Can a single IPv6 bridge failure stop Tor connecting?2020-07-27T18:18:15ZteorCan a single IPv6 bridge failure stop Tor connecting?ln5's IPv6-only Linux system had 3 bridges, but 2 failed.
Then the tor instance stopped connecting, even though it still had one good bridge.
Does this happen on IPv4?
(Can we reproduce it on IPv6?)
How can we make this more robust?ln5's IPv6-only Linux system had 3 bridges, but 2 failed.
Then the tor instance stopped connecting, even though it still had one good bridge.
Does this happen on IPv4?
(Can we reproduce it on IPv6?)
How can we make this more robust?Tor: unspecifiedhttps://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/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/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/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/17230Local DNS resolver will not resolve AAAA records with fc00::/8 prefixes.2022-06-17T18:57:41ZTracLocal DNS resolver will not resolve AAAA records with fc00::/8 prefixes.When using the DNS resolver configured using the DNSPort directive, AAAA records using fc00::/8 prefixes are not returned. This interferes with the proper resolution of hosts using [cjdns](https://github.com/cjdelisle/cjdns) addresses, w...When using the DNS resolver configured using the DNSPort directive, AAAA records using fc00::/8 prefixes are not returned. This interferes with the proper resolution of hosts using [cjdns](https://github.com/cjdelisle/cjdns) addresses, which are typically specified using h.domain.tld addresses.
[Example](http://pastie.org/private/3ote0ky6lfzmkp4tcnwfbg)
**Trac**:
**Username**: JacobHennerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17217Change clients to automatically use IPv6 if they can bootstrap over it2020-07-24T18:25:24ZteorChange clients to automatically use IPv6 if they can bootstrap over itTor currently defaults to avoiding IPv6 directories and ORPorts.
When legacy/trac#8374 and legacy/trac#4483 are implemented, we should change this default, especially for those clients that can bootstrap successfully over IPv6.
I sugges...Tor currently defaults to avoiding IPv6 directories and ORPorts.
When legacy/trac#8374 and legacy/trac#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
```Tor: unspecifiedhttps://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/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/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/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/13112Some things are probably broken when we advertise multiple ORPorts and only s...2020-07-24T15:56:37ZAndrea ShepardSome things are probably broken when we advertise multiple ORPorts and only some are reachableObservations on reachability testing made while fixing legacy/trac#12160:
- We only have a 1-bit notion of reachability; if we get an incoming non-local connection, we assume reachability in onionskin_answer() and call router_orport_fo...Observations on reachability testing made while fixing legacy/trac#12160:
- We only have a 1-bit notion of reachability; if we get an incoming non-local connection, we assume reachability in onionskin_answer() and call router_orport_found_reachable() to publish a descriptor.
- We should have a reachability bit per *advertised* ORPort to determine its inclusion in the published descriptor, and publish if and only if we have one or more reachable ORPorts.
- To implement this, we need a way to link incoming testing circuits to a particular advertised ORPort; we don't know this from the port the underlying channel was listening on because reverse proxies might make this not one-to-one in general.
- Arma suggests in IRC that netinfo cells know the IP the connection was attempted on and if they were extended with a port number they might provide a sufficient mechanism.Tor: unspecifiedhttps://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/12558Tor doesn't show warning for non-reachable IPv6 OR port2020-06-27T14:02:49ZTracTor doesn't show warning for non-reachable IPv6 OR portI recently upgraded my routers firmware. After that, I restarted Tor as usual. After one day, I noticed that atlas is showing my relay as offline since restart.
After more than hour of investigating, I found out that my router gave my R...I recently upgraded my routers firmware. After that, I restarted Tor as usual. After one day, I noticed that atlas is showing my relay as offline since restart.
After more than hour of investigating, I found out that my router gave my Raspberry Pi a new IPv6 interface ID. Due to this, my port forwarding didn't work anymore.
The strange thing is: In my tor logs, I saw this:
"Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor."
Looks like Tor was just referring to my IPv4 OR Port, which was still reachable, and didn't notice my non-reachable IPv6 OR Port. This issue should be fixed.
**Trac**:
**Username**: anong