Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:02:57Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12163Tor 0.2.4.22 doesn't bind to low IPv6 ports2020-06-27T14:02:57ZTracTor 0.2.4.22 doesn't bind to low IPv6 portsIPv4 works fine with a low port number (445 in my case), but IPv6 doesn't.
Config:
ORPort 445
ORPort [2001:db8:a:b::c]:445
[warn] Could not bind to 2001:db8:a:b::c:445:
| > | Permission denied
Now when I change the IPv6 port to a hi...IPv4 works fine with a low port number (445 in my case), but IPv6 doesn't.
Config:
ORPort 445
ORPort [2001:db8:a:b::c]:445
[warn] Could not bind to 2001:db8:a:b::c:445:
| > | Permission denied
Now when I change the IPv6 port to a higher number everything works fine:
ORPort [2001:db8:a:b::c]:4445
OS is Ubuntu; Linux version 3.13.0-24-generic (buildd@batsu) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) legacy/trac#47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
**Trac**:
**Username**: rommelbakTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12138No IPv6 support when suggesting a bindaddr to a PT2022-02-28T19:40:20ZGeorge KadianakisNo IPv6 support when suggesting a bindaddr to a PTThis recent post in tor-talk:
http://www.marshut.com/iwuqqh/setting-up-an-ipv6-%20supporting-obfs3-bridge.html
revealed that Tor does not support IPv6 when supporting a bind address to a pluggable transport. It seems that we missed that ...This recent post in tor-talk:
http://www.marshut.com/iwuqqh/setting-up-an-ipv6-%20supporting-obfs3-bridge.html
revealed that Tor does not support IPv6 when supporting a bind address to a pluggable transport. It seems that we missed that during legacy/trac#7011.
The problem is that the first time someone fires up a `ServerTransportPlugin`, Tor will suggest to it to bind in `0.0.0.0:0`. This can be seen in `get_stored_bindaddr_for_server_transport`:
https://gitweb.torproject.org/tor.git/blob/2ee56e4c2c841a45418cfb826e1ce6689278382d:/src/or/statefile.c#l517
```
no_bindaddr_found:
/** If we didn't find references for this pluggable transport in the
state file, we should instruct the pluggable transport proxy to
listen on INADDR_ANY on a random ephemeral port. */
tor_asprintf(&default_addrport, "%s:%s", fmt_addr32(INADDR_ANY), "0");
return default_addrport;
```
Instead of using `fmt_addr32(INADDR_ANY)`, we should use `fmt_addrport` and suggest `[::]` if we need to use IPv6. We should probably suggest an IPv6 address, if our ORPort is IPv6 (what if we have both kinds of ORPorts?).
Implementation of this should not be hard. I can do it one of these days.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/11625Tor DNSPORT returns NXDOMAIN for AAAA records?2022-06-17T16:14:40ZNick MathewsonTor DNSPORT returns NXDOMAIN for AAAA records?On legacy/trac#11603, mickeyc reports:
```
Behaviour has changed with 0.2.5.4, but it is still broken. Now I'm getting an NXDOMAIN
instead whenever I do any AAAA lookups. A record lookups are still fine:
mike@glue:~$ dig aaaa gmail.com...On legacy/trac#11603, mickeyc reports:
```
Behaviour has changed with 0.2.5.4, but it is still broken. Now I'm getting an NXDOMAIN
instead whenever I do any AAAA lookups. A record lookups are still fine:
mike@glue:~$ dig aaaa gmail.com @localhost -p 5304
; <<>> DiG 9.9.5-3-Debian <<>> aaaa gmail.com @localhost -p 5304
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19056
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN AAAA
;; Query time: 249 msec
;; SERVER: ::1#5304(::1)
;; WHEN: Sun Apr 27 11:37:35 BST 2014
;; MSG SIZE rcvd: 27
mike@glue:~$ dig +short a gmail.com @localhost -p 5304
173.194.70.18
mike@glue:~$
```https://gitlab.torproject.org/tpo/core/tor/-/issues/11360Listen on IPv6 by default for SocksPort *:Port2021-06-18T18:20:31ZDavid Gouletdgoulet@torproject.orgListen on IPv6 by default for SocksPort *:PortThat would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon....That would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon.
One way to fix that would be to change the function parse_port_config() in _src/or/config.c_ to allow multiple default values adding v6 defaults (which would benefit other ports as well).
Else, having a check somewhere that adds other defaults for specific ports but not sure that it's a good idea nor makes sense in the long run in terms of maintainability.
I thought also about bringing back legacy/trac#4760 by default and setting the ipv6 only option only and only if the user has defined an option in the torrc explicitly. For instance, this in the torrc would ONLY allow v6 (remove dual stack).
```
SocksPort [::1]:9050
```
Thoughts?https://gitlab.torproject.org/tpo/core/tor/-/issues/11211Multiple ServerTransportListenAddr entries should be allowed per transport.2023-11-16T20:18:11ZYawning AngelMultiple ServerTransportListenAddr entries should be allowed per transport.Looking through or/config.c, it is apparent that the ServerTransportListenAddr line only allows one address/port to be specified per transport. This is problematic because there are cases where it is beneficial/required to list more tha...Looking through or/config.c, it is apparent that the ServerTransportListenAddr line only allows one address/port to be specified per transport. This is problematic because there are cases where it is beneficial/required to list more than one.
A simple example of where this would be useful is:
```
ServerTransportListenAddr obfs3 0.0.0.0:443
ServerTransportListenAddr obfs3 [::]:443
```
The Pluggable Transport spec doesn't explicitly disallow having multiple bind addresses for TOR_PT_SERVER_BIND_ADDR, but I'm not sure what would happen if more than one is passed with each of the pt config protocol libraries in use.
The keys holding transport names must appear on the same order
as they appear on TOR_PT_SERVER_TRANSPORTS.
Currently the particular example I used is probably a moot point because of #7961, but in general I don't see a good reason why each transport should be limited to one bind address.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/10987IPv6 is not working when using SocksPort2020-06-27T14:03:25ZDavid Gouletdgoulet@torproject.orgIPv6 is not working when using SocksPortTor daemon replies to a SOCKS5 connect command with an IPv4 payload when using IPv6 thus making the client trying to receive too much bytes and failing to use IPv6 with a SOCKS5 connection.
I'll be submitting a patch for this soon. Jus...Tor daemon replies to a SOCKS5 connect command with an IPv4 payload when using IPv6 thus making the client trying to receive too much bytes and failing to use IPv6 with a SOCKS5 connection.
I'll be submitting a patch for this soon. Just need to get this bug number and make the changes file.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10468Make DnsPort, IPv6, and AutomapHostsOnResolve work together2020-06-27T14:03:34ZNick MathewsonMake DnsPort, IPv6, and AutomapHostsOnResolve work togetherFrom legacy/trac#10465: I started Tor with "./src/or/tor -dnsport '9999 preferipv6automap' -automaphostsonresolve 1 -automaphostssuffix . "
Then I did:
```
[619]$ dig @localhost -p 9999 aaaa www.torproject.org
; <<>> DiG 9.8.3-P1 <<>> ...From legacy/trac#10465: I started Tor with "./src/or/tor -dnsport '9999 preferipv6automap' -automaphostsonresolve 1 -automaphostssuffix . "
Then I did:
```
[619]$ dig @localhost -p 9999 aaaa www.torproject.org
; <<>> DiG 9.8.3-P1 <<>> @localhost -p 9999 aaaa www.torproject.org
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45384
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.torproject.org. IN AAAA
;; ANSWER SECTION:
www.torproject.org. 60 IN A 127.237.144.204
;; Query time: 0 msec
;; SERVER: 127.0.0.1#9999(127.0.0.1)
;; WHEN: Sun Dec 22 09:19:54 2013
;; MSG SIZE rcvd: 52
```
and
```
[621]$ dig @localhost -p 9999 example.com
; <<>> DiG 9.8.3-P1 <<>> @localhost -p 9999 example.com
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18398
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 60 IN A 127.201.101.133
;; Query time: 0 msec
;; SERVER: 127.0.0.1#9999(127.0.0.1)
;; WHEN: Sun Dec 22 09:20:31 2013
;; MSG SIZE rcvd: 45
```
It seems to be sending A even if it was asked for an AAAA.
(There are deeper DNSPort+IPv6 issues going on, of course, but this part is probably easier, and it's an independently useful bit of functionality.)
See legacy/trac#10465 notes for moreTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9068Unify reachableaddresses and IPv6 settings2020-06-27T14:04:17ZNick MathewsonUnify reachableaddresses and IPv6 settingsThere's really no difference between "I can't reach IPv6" and "ClientUseIPv6 0". Let's make them redundant. Let's also add an "I can't reach IPv4" option.
See legacy/trac#6027 and legacy/trac#9067There's really no difference between "I can't reach IPv6" and "ClientUseIPv6 0". Let's make them redundant. Let's also add an "I can't reach IPv4" option.
See legacy/trac#6027 and legacy/trac#9067Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9067Choice of address and match of fascist_firewall_allows_address* need to consi...2020-08-11T12:13:35ZNick MathewsonChoice of address and match of fascist_firewall_allows_address* need to consider ipv6Right now, when we decide "can we reach node X", we only pass the node's primary address to fasist_firewall_allows_*.
Also, when we decide whether to use an primary or secondary address, we don't look at fascist_firewall_* as far as I k...Right now, when we decide "can we reach node X", we only pass the node's primary address to fasist_firewall_allows_*.
Also, when we decide whether to use an primary or secondary address, we don't look at fascist_firewall_* as far as I know.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8846Useless log message when using IPv6 address on SocksPort without IPv62020-06-27T14:04:25ZTracUseless log message when using IPv6 address on SocksPort without IPv6I'm using TBB but with custom built tor executable, actually from git.tpo/debian/tor.git, and the log shows the following errors upon trying to visit an IPv6 address in TBB.
May 08 19:28:06.684 [Notice] Tor v0.2.4.11-alpha (git-f4f37a8f...I'm using TBB but with custom built tor executable, actually from git.tpo/debian/tor.git, and the log shows the following errors upon trying to visit an IPv6 address in TBB.
May 08 19:28:06.684 [Notice] Tor v0.2.4.11-alpha (git-f4f37a8fed617ffd) running on Linux with Libevent 2.0.21-stable and OpenSSL 1.0.1e.
May 08 19:28:06.684 [Notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 08 19:28:06.684 [Notice] This version is not a stable Tor release. Expect more bugs than usual.
May 08 19:28:06.686 [Notice] Read configuration file "XXXXXX/tor-browser_en-US/App/../Data/Tor/torrc".
May 08 19:28:06.692 [Notice] We were compiled with headers from version 2.0.19-stable of Libevent, but we're using a Libevent library that says it's version 2.0.21-stable.
May 08 19:28:06.692 [Notice] Opening Socks listener on 127.0.0.1:9150
May 08 19:28:06.692 [Notice] Opening Socks listener on 127.0.0.1:9050
May 08 19:28:06.692 [Notice] Opening Control listener on 127.0.0.1:9151
May 08 19:28:06.709 [Notice] Parsing GEOIP IPv4 file ./Data/Tor/geoip.
May 08 19:28:08.199 [Notice] Bootstrapped 5%: Connecting to directory server.
May 08 19:28:08.199 [Warning] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 1; recommendation warn)
May 08 19:28:08.270 [Notice] Bootstrapped 10%: Finishing handshake with directory server.
May 08 19:28:08.534 [Notice] Bootstrapped 15%: Establishing an encrypted directory connection.
May 08 19:28:08.932 [Notice] New control connection opened.
May 08 19:28:08.932 [Notice] Bootstrapped 20%: Asking for networkstatus consensus.
May 08 19:28:08.932 [Notice] Bootstrapped 25%: Loading networkstatus consensus.
May 08 19:28:10.586 [Notice] Bootstrapped 45%: Asking for relay descriptors.
May 08 19:28:10.586 [Notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 2187/3501, and can only build 27% of likely paths. (We have 65% of guards bw, 64% of midpoint bw, and 66% of exit bw.)
May 08 19:28:14.205 [Notice] We now have enough directory information to build circuits.
May 08 19:28:14.205 [Notice] Bootstrapped 80%: Connecting to the Tor network.
May 08 19:28:14.205 [Notice] Bootstrapped 90%: Establishing a Tor circuit.
May 08 19:28:14.683 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 08 19:28:14.684 [Notice] Bootstrapped 100%: Done.
May 08 19:33:48.508 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:48.792 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:50.516 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:50.517 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:51.515 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:51.516 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:52.313 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:33:52.363 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:54.314 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:57.545 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:34:00.998 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:34:01.535 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:36:28.511 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:36:50.612 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:08.202 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $A59E1E7C7EAEE083D756EE1FF6EC31CA3D8651D7~chaoscomputerclub19 at 31.172.30.2. Retrying on a new circuit.
May 08 19:37:09.088 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:34.885 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:48.819 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:57.915 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:38:35.203 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $43691853EA556C21A77E006886A5DC579855F527~sofia at 109.163.233.202. Retrying on a new circuit.
May 08 19:38:50.204 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $4F8D80A0F768A2A29856A8F26B05D35DEAA39850~wannabe at 96.47.226.19. Retrying on a new circuit.
May 08 19:39:36.202 [Notice] Tor has not observed any network activity for the past 69 seconds. Disabling circuit build timeout recording.
My torrc:
# If non-zero, try to write to disk less frequently than we would otherwise.
AvoidDiskWrites 1
# Store working data, state, keys, and caches here.
DataDirectory ./Data/Tor
GeoIPFile ./Data/Tor/geoip
# Where to send logging messages. Format is minSeverity[-maxSeverity]
# (stderr|stdout|syslog|file FILENAME).
Log notice stdout
# Bind to this address to listen to connections from SOCKS-speaking
# applications.
SocksPort 9150
ControlPort 9151
ClientPreferIPv6ORPort 1
ClientUseIPv6 1
SocksPort 127.0.0.1:9050 IPv6Traffic
I used to be able to visit IPv6 addresses from TBB up until 0.2.4.10 (if I remember correctly) using the same method (custom built tor executable).
If I start a TBB session and I don't visit any IPv6 addresses then I got no problems and no 'connection_ap_get_begincell_flags(): Bug:' messages appear in the logfile.
**Trac**:
**Username**: kargigTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8475internal-address check in handling RESOLVED cells doesn't cover IPv62020-06-27T14:04:36ZNick Mathewsoninternal-address check in handling RESOLVED cells doesn't cover IPv6Our check for internal addresses in connection_ap_process_not_open() doesn't look at IPv6 addresses. Better fix that. This is less horrible than it could be now that we don't cache answers, but somebody else might be caching Tor's repl...Our check for internal addresses in connection_ap_process_not_open() doesn't look at IPv6 addresses. Better fix that. This is less horrible than it could be now that we don't cache answers, but somebody else might be caching Tor's replies or something.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8380DNS A records returned when asking for AAAA2020-06-27T14:04:40ZTracDNS A records returned when asking for AAAAI have Tor v0.2.5.0-alpha-dev running with DNSPort 53
Tor incorrectly returns an A record when asking for an AAAA
```
$ host -t aaaa google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
google.com h...I have Tor v0.2.5.0-alpha-dev running with DNSPort 53
Tor incorrectly returns an A record when asking for an AAAA
```
$ host -t aaaa google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
google.com has address 74.125.132.138
```
Additionally, if there is no AAAA record, it still returns an A
Using Google's public DNS:
```
$ host -t aaaa chase.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
chase.com has no AAAA record
```
Using Tor's DNSPort
```
$ host -t aaaa chase.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
chase.com has address 159.53.84.126
```
**Trac**:
**Username**: dhillTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8377Tor claims that [::1]:9050 is non-loopback.2020-06-27T14:04:40ZNick MathewsonTor claims that [::1]:9050 is non-loopback.I just started Tor as "tor -socksport '[::1]:9050'". It said:
```
Mar 01 12:12:34.606 [notice] You configured a non-loopback address '[::1]:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy...I just started Tor as "tor -socksport '[::1]:9050'". It said:
```
Mar 01 12:12:34.606 [notice] You configured a non-loopback address '[::1]:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
```
This occurs in 0.2.3 and later.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8374Ship list of fallback directory mirrors on long-term fixed IPv6 addresses2020-06-27T14:04:40ZKarsten LoesingShip list of fallback directory mirrors on long-term fixed IPv6 addresseslegacy/trac#6027 enables clients which cannot talk to IPv4 relays to use fallback directory mirrors with IPv6 addresses and ORPorts. It's going to get merged into 0.2.5.x.
Assuming this code is in tor, how would we ship an up-to-date l...legacy/trac#6027 enables clients which cannot talk to IPv4 relays to use fallback directory mirrors with IPv6 addresses and ORPorts. It's going to get merged into 0.2.5.x.
Assuming this code is in tor, how would we ship an up-to-date list of long-term fixed directory mirror IPv6 addresses with bundles? I think I can provide a simple script or set up a service generating this list. But what's the easiest way to include the step "Grab new IPv6 addresses file and put it into all bundles" in the process of making bundles? There's no code written yet, so please say what's most convenient for bundle makers.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7961Publish transports that bind on IPv6 addresses2021-11-19T21:12:13ZGeorge KadianakisPublish transports that bind on IPv6 addressesCurrently, `pt_get_extra_info_descriptor_string()` uses `router_pick_published_address()` to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.
Th...Currently, `pt_get_extra_info_descriptor_string()` uses `router_pick_published_address()` to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.
The bad news are that `router_pick_published_address()` only returns IPv4 addresses, and we will probably have to refactor it, or do something like this:
~~ https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775 ~~
(wrong commit reference)
for IPv6 addresses.
Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we implement it, and how complex the changes are going to be.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7489Allow hidden services on IPv6 addresses2020-06-27T14:05:13ZNick MathewsonAllow hidden services on IPv6 addressesWith everything else we're doing for IPv6, we should allow HS operators to run a hidden service on a local IPv6 address. I believe Andrea was interested in this one.With everything else we're doing for IPv6, we should allow HS operators to run a hidden service on a local IPv6 address. I believe Andrea was interested in this one.Tor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7488Make sure transparent proxies work with IPv62020-06-27T14:05:13ZNick MathewsonMake sure transparent proxies work with IPv6I haven't yet had a chance to make sure that TransPort and NatdPort work with IPv6. We need to test that before 0.2.4.x releases. Looking at the code, I don't see anything that would stop them, but without testing, best to assume the wo...I haven't yet had a chance to make sure that TransPort and NatdPort work with IPv6. We need to test that before 0.2.4.x releases. Looking at the code, I don't see anything that would stop them, but without testing, best to assume the worst.https://gitlab.torproject.org/tpo/core/tor/-/issues/7482Discard nonsense in address.c about v4-mapped addresses2021-09-16T14:36:00ZNick MathewsonDiscard nonsense in address.c about v4-mapped addressesRight now, some but not all places in address.c do strange contortions to treat ::ffff:1.2.3.4 as equivalent to 1.2.3.4. Instead, we should be rejecting these addresses as private, rather than trying to pretend that we support them.Right now, some but not all places in address.c do strange contortions to treat ::ffff:1.2.3.4 as equivalent to 1.2.3.4. Instead, we should be rejecting these addresses as private, rather than trying to pretend that we support them.https://gitlab.torproject.org/tpo/core/tor/-/issues/7481There should be some way to indicate [2001:...].foo.exit2020-06-27T14:05:14ZNick MathewsonThere should be some way to indicate [2001:...].foo.exitRight now, there isn't a workable syntax for describing "IPv6 address X, as connected to through the exit foo." This could be important for doing the kind of tricks people like with MapAddress and its friends.Right now, there isn't a workable syntax for describing "IPv6 address X, as connected to through the exit foo." This could be important for doing the kind of tricks people like with MapAddress and its friends.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7478Allow routersets to include/exclude nodes by IPv6 address2022-05-02T20:28:11ZNick MathewsonAllow routersets to include/exclude nodes by IPv6 addressRight now, routerset_contains_*() and friends only looks at a single tor_addr_t. But nodes now can have more than one address.
The simple rule here would be to have a node considered to be a member of a routerset if *any* of its addres...Right now, routerset_contains_*() and friends only looks at a single tor_addr_t. But nodes now can have more than one address.
The simple rule here would be to have a node considered to be a member of a routerset if *any* of its addresses is contained in the routerset. That would make ExcludeNodes work right, but could get surprising behavior with ExitNodes and the like.
A less simple rule would be to have slightly different semantics for 'include' and 'exclude' routersets, but I don't much like that option: it also seems likely to surprise.
The least simple option would be to treat a node as partially in a set if one of its addresses is included and another isn't. That's a worst-case option IMO: it's likely to be complex and error-prone.