Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-11-16T14:20:15Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40885dual stack bridges only publish an IPv4 bridge line2023-11-16T14:20:15Zdzwdzdual stack bridges only publish an IPv4 bridge lineBridges currently only publish one bridge line per transport, and, if they have both an IPv4 and v6 address available, they always prefer IPv4, leaving the IPv6 address unused.
https://gitlab.torproject.org/tpo/core/tor/-/blob/cec6f9919...Bridges currently only publish one bridge line per transport, and, if they have both an IPv4 and v6 address available, they always prefer IPv4, leaving the IPv6 address unused.
https://gitlab.torproject.org/tpo/core/tor/-/blob/cec6f9919d3128646d85c75d08338bea4b31bffa/src/feature/client/transports.c#L1724-1732
@arma checked the extra-info descriptor of one of my (dual stack) bridges and confirmed it only used its IPv4 address in the transport line. I don't see any IPv6 users either, but that's just anecdotal evidence. I think this has the potential to add a lot of new bridge address to the pool, which would be pretty neat from an anti-censorship perspective.
Right now I'll try to patch a bridge of mine to publish two transport lines in extra-info, one per IP version, and see if that breaks anything. If it doesn't, I can submit a MR after !782 gets merged (it affects the same area of the code).https://gitlab.torproject.org/tpo/core/tor/-/issues/40857refused due to NAT64 exit policy failed2023-11-16T18:47:05ZpseudonymisaTorrefused due to NAT64 exit policy failedIf tor client send a NAT64 `64:ff9b::/96` address stream to exist, the connection_ap_process_end_not_open() refused due to 'exit policy failed'.
Consider to apply RFC6146 to exitpolicy proccessing?
valid on Tor 0.4.8.1-alpha-devIf tor client send a NAT64 `64:ff9b::/96` address stream to exist, the connection_ap_process_end_not_open() refused due to 'exit policy failed'.
Consider to apply RFC6146 to exitpolicy proccessing?
valid on Tor 0.4.8.1-alpha-devhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40711Tor with new ipv6 only works after a restart2022-12-16T18:26:07ZGusTor with new ipv6 only works after a restartA relay operator reported that every day their relay changes the IPv4 and IPv6 addresses. But while Tor with IPv4 works automatically, for IPv6 connection, they need to restart the service.
```
Auto-discovered IPv6 address [1111:::ffff]...A relay operator reported that every day their relay changes the IPv4 and IPv6 addresses. But while Tor with IPv4 works automatically, for IPv6 connection, they need to restart the service.
```
Auto-discovered IPv6 address [1111:::ffff]:9001 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds])
```
#### Tor version
0.4.7.10.
#### torrc
```
SocksPort 0
Log notice file /var/log/tor/notices.log
DataDirectory /var/lib/tor
ControlPort xxxxx
HashedControlPassword xxxxx
ORPort 9001
Nickname justme
RelayBandwidthRate 250 KB # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 750 KB # But allow bursts up to 200KB/s (1600Kbps)
ContactInfo me@there.net
DirPort 9005
ExitRelay 0
ExitPolicy reject *:* # no exits allowed
```
#### Forum link
https://forum.torproject.net/t/ipv6-with-dynamic-prefix-behind-nat/5296https://gitlab.torproject.org/tpo/core/tor/-/issues/40583Default SocksPort should bind to localhost IPv6 also2022-04-07T04:54:36Zs7rDefault SocksPort should bind to localhost IPv6 alsoCurrently a default `SocksPort 9050` will only bind to 127.0.0.1:9050.
While this is of course sufficient for most of cases, we might also want to bind by default to [::1]:9050 as well, along with 127.0.0.1. At some point maybe TBB will ...Currently a default `SocksPort 9050` will only bind to 127.0.0.1:9050.
While this is of course sufficient for most of cases, we might also want to bind by default to [::1]:9050 as well, along with 127.0.0.1. At some point maybe TBB will configure Firefox to use ::1 instead of 127.0.0.1. I don't think any decent OS does not have localhost IPv6 support in 2022.
Are there any reasons we might not want to do this?
Also, in an (I think outdated) manual version from 2019.www.tpo I can find this SocksPort flag with this description:
PreferIPv6
Tells exits that, if a host has both an IPv4 and an IPv6 address, we would prefer to connect to it via IPv6. (IPv4 is the default.)
I don't know if IPv4 is the default, because in the latest Tor when my clearnet destination has both IPv4 and IPv6 and the Exit node in my circuit has IPv6 exiting, it will connect (as it should) via IPv6. So we should change this to "IPv6 is the default" - as per RFC's recommendations.https://gitlab.torproject.org/tpo/core/tor/-/issues/33375Stop advertising an IPv6 exit policy when DNS is broken for IPv62022-02-28T19:41:05ZteorStop advertising an IPv6 exit policy when DNS is broken for IPv6When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the desc...When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the descriptor, check `dns_seems_to_be_broken_for_ipv6()` before including an IPv6 exit policy
* reset `dns_seems_to_be_broken_for_ipv6()` periodically, maybe every 1-3 days?https://gitlab.torproject.org/tpo/core/tor/-/issues/26646add support for multiple OutboundBindAddressExit IP(ranges)2023-04-03T16:39:16Znusenuadd support for multiple OutboundBindAddressExit IP(ranges)tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and ...tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and IPv6
ranges/prefixes.
The idea is to assign an IP address to each tor circuit. The exit IP
address must never change during the lifetime of the circuit.
Exit IP addresses would be randomly assigned to circuits. Once
the exit runs out of IPs it cycles through his pool of IPs again.
With IPv6 address space availability this can take a long time
with IPv4 it will be limited.
This aims to reduce the negative impact of few "bad" users on many "good"
users since they will not share the same IP address on the exit.
This might also have some negative? side effect since
it demultiplexes tor clients to multiple source IPs on the exit
and an external observer (not running the exit itself)
can tell clients apart by looking at source IPs.
Instead of doing it on the circuit level you could do it
based on time. Change the exit IP every 5 minutes (but
do _not_ change the exit IPs for _existing_ circuits even if they
live longer than 5 minutes).
https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.htmlTor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24731Stop checking routerinfos for addresses when we use microdescs for circuits2022-09-01T21:31:34ZteorStop checking routerinfos for addresses when we use microdescs for circuitsDirectory mirrors and clients that FetchUselessDescriptors check for IPv4 and IPv6 addresses in the following order:
* routerinfos (descriptors)
* routerstatus (consensus)
* microdescriptors
But they should check using the following ord...Directory mirrors and clients that FetchUselessDescriptors check for IPv4 and IPv6 addresses in the following order:
* routerinfos (descriptors)
* routerstatus (consensus)
* microdescriptors
But they should check using the following order:
* bridge routerinfos (descriptors)
* routerstatus (consensus)
If using microdescriptors for circuits:
* microdescriptors
Otherwise:
* routerinfos (descriptors)
There is code that implements this algorithm in commits decb0636e2, 1d1c927b9a, and 4979ec3c17 of my bug23975_tree branch.
But this adds overhead to every address lookup when building circuits.
Maybe we can make it faster by:
* not parsing routerinfos or microdescs if we aren't using them for circuits, or
* putting a canonical address in node_t, updating it whenever ri, rs, or md change, and always using ithttps://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/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.org