If the IPv6 ORPort can't be reached, will clients/relays fall back to the IPv4 ORPort?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. If a client or relay with IPv6 attempts to connect to a relay's IPv6 ORPort and receives no response, will it fall back to IPv4 or will it consider the relay unreachable? Assume that the directory authorities are able to reach the v6 ORPort. Is the behavior different if there is an explicit error returned, e.g. RST or an ICMPv6 no route to host? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal6ZDgAKCRAw+TRLM+X4 xgM7AP9xJhuSw8vYilYYbtzscuPLZk8BMY58gqPL2gocHYy/9wEAnduiOSjAeG6c 2yzboG7z5+HCV56tjIwXhuUTrprCmAY= =CQEB -----END PGP SIGNATURE-----
Hi forest, Short answer: no, Tor doesn't do Happy Eyeballs for OR connections. Whatever address family gets picked for a connection attempt is what gets tried, and if it fails, that's it for that attempt. Tor won't turn around and retry the same relay over IPv4. A later circuit attempt may try again or choose another path, but that's separate, not a fallback. It's a known gap. There's a proposal for it, Prop 306, "IPv6 Happy Eyeballs" [1], but it was never implemented and is still open. RST vs silence: an RST or usable ICMPv6 error may make the attempt fail faster, while silently dropped traffic has to wait for a timeout. Either way, there is no fallback for that attempt. Worth keeping in mind, the DAs reaching the IPv6 ORPort only proves it's reachable from their networks, not from every client or relay out there. Operationally, if the relay's IPv6 is broken, fix it or stop advertising it. Comment out the explicit IPv6 ORPort line and reload or restart Tor. If IPv6 is still being published, set |AddressDisableIPv6 1|. That saves clients from hitting a dead end for no reason. [1] https://spec.torproject.org/proposals/306-ipv6-happy-eyeballs.html Cheers, rE-Bo0t.bx1 https://relays.brokenbotnet.com On 7/21/26 6:52 AM, forest-relay-contact--- via tor-relays wrote:
Hello.
If a client or relay with IPv6 attempts to connect to a relay's IPv6 ORPort and receives no response, will it fall back to IPv4 or will it consider the relay unreachable? Assume that the directory authorities are able to reach the v6 ORPort.
Is the behavior different if there is an explicit error returned, e.g. RST or an ICMPv6 no route to host?
Regards, forest _______________________________________________ > tor-relays mailing list -- tor-relays@lists.torproject.org > To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. rE-Bo0t.bx1 wrote:
Short answer: no, Tor doesn't do Happy Eyeballs for OR connections. Whatever address family gets picked for a connection attempt is what gets tried, and if it fails, that's it for that attempt. Tor won't turn around and retry the same relay over IPv4. A later circuit attempt may try again or choose another path, but that's separate, not a fallback.
The reason I ask is because I'm considering implications of the toralf tor-ddos script on relays that use IPv6. By its very design, there are a number of hosting providers that will provide, say, a routed /48 for a low cost which could then be used to completely overwhelm the IPv6 anti- DDoS firewall rules (unlike the IPv4 rules where an attacker would need to buy a costly new IPv4 just to get an additional 8 connections). If a hard limit for the number of simultaneous IPv6 connections were set, then that would force the attacker to fall back to IPv4 long before the relay is actually overwhelmed, but that would also prevent anyone else from connecting with IPv6. If connections fell back to IPv4 after failure to connect with IPv6, it could be a solution. It's unfortunate they don't. As it is, it seems like the anti-DDoS script and firewall rules are only effective on dual-stack relays so long as no attacker figures out that there are plenty of routed IPv6 netblocks that they can cheaply use. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal7DNAAKCRAw+TRLM+X4 xiY4AP9ZrbdRHeQC/RVe7XH7B0Q9wAzpUpHmSxC1M0ifWHs6FQEA0urIqk7LHNJ5 hoR3PiMXH0VD3VSR0Dbmp4P9/nln8AE= =QkjG -----END PGP SIGNATURE-----
Hi forest, Yeah, I think your concern is valid. Looking at the current |ipv6-rules.sh|, some known provider ranges are grouped by /64 or /80, while anything outside those ranges is handled as /128. Even with /64 grouping, someone with a routed /48 still has a huge number of prefixes to rotate through. So the current limits can still be worked around by changing prefixes. A global IPv6 cap could help protect the relay, but without fallback it would also block legitimate IPv6 users once the cap is hit. Wider prefix limits or a global emergency cap might help, but both risk blocking innocent users too. This looks like a real IPv6 limitation in the current rules. Cheers, rE-Bo0t.bx1 https://relays.brokenbotnet.com On 7/21/26 9:52 AM, forest-relay-contact--- via tor-relays wrote:
Hello.
rE-Bo0t.bx1 wrote:
Short answer: no, Tor doesn't do Happy Eyeballs for OR connections. Whatever address family gets picked for a connection attempt is what gets tried, and if it fails, that's it for that attempt. Tor won't turn around and retry the same relay over IPv4. A later circuit attempt may try again or choose another path, but that's separate, not a fallback.
The reason I ask is because I'm considering implications of the toralf tor-ddos script on relays that use IPv6. By its very design, there are a number of hosting providers that will provide, say, a routed /48 for a low cost which could then be used to completely overwhelm the IPv6 anti- DDoS firewall rules (unlike the IPv4 rules where an attacker would need to buy a costly new IPv4 just to get an additional 8 connections).
If a hard limit for the number of simultaneous IPv6 connections were set, then that would force the attacker to fall back to IPv4 long before the relay is actually overwhelmed, but that would also prevent anyone else from connecting with IPv6. If connections fell back to IPv4 after failure to connect with IPv6, it could be a solution. It's unfortunate they don't.
As it is, it seems like the anti-DDoS script and firewall rules are only effective on dual-stack relays so long as no attacker figures out that there are plenty of routed IPv6 netblocks that they can cheaply use.
Regards, forest _______________________________________________ > tor-relays mailing list -- tor-relays@lists.torproject.org > To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Am 21.07.26 um 02:52 schrieb forest-relay-contact--- via tor-relays:
The reason I ask is because I'm considering implications of the toralf tor-ddos script on relays that use IPv6. By its very design, there are a number of hosting providers that will provide, say, a routed /48 for a low cost which could then be used to completely overwhelm the IPv6 anti- DDoS firewall rules (unlike the IPv4 rules where an attacker would need to buy a costly new IPv4 just to get an additional 8 connections).
Build an escalation system. E.g. a single IPv6 will be blocked first, if more come from the same /64, the entire /64 is blocked. If more come from the same allocation (either use /48 or even bigger if you can query the BGP data) to block the entire ISP. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
On 21/07/2026 02:52, forest-relay-contact--- via tor-relays wrote:
The reason I ask is because I'm considering implications of the toralf tor-ddos script on relays that use IPv6. By its very design, there are a number of hosting providers that will provide, say, a routed /48 for a low cost which could then be used to completely overwhelm the IPv6 anti- DDoS firewall rules (unlike the IPv4 rules where an attacker would need to buy a costly new IPv4 just to get an additional 8 connections). ?
I updated the comment in [1] [1] https://github.com/toralf/torutils/commit/3505eec5ef0f35b3952a7f994cc25e0f62... -- Toralf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Marco Moock wrote:
Build an escalation system. E.g. a single IPv6 will be blocked first, if more come from the same /64, the entire /64 is blocked. If more come from the same allocation (either use /48 or even bigger if you can query the BGP data) to block the entire ISP.
The problem with that is that someone with an /80 in that /64 could get everyone else on that /64 blocked, which could be used as a way to target specific people by getting them kicked off their guard. For a commercial spam filter, it makes sense to treat every /64 as an individual, but it's quite exploitable. I assume that's why toralf's script will fall back to blocking based on /128 otherwise. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal8UyAAKCRAw+TRLM+X4 xoo8AQC/p10//qpdse1v9tSPckjqyisbnZ47gKKi3v9qrzcT/QEA55Ikn8b9FYtr PNrfcPgJC1sWBmWtzXeXsZYz53wC6AI= =ED+4 -----END PGP SIGNATURE-----
Am 21.07.26 um 08:40 schrieb forest-relay-contact--- via tor-relays:
Hello.
Marco Moock wrote:
Build an escalation system. E.g. a single IPv6 will be blocked first, if more come from the same /64, the entire /64 is blocked. If more come from the same allocation (either use /48 or even bigger if you can query the BGP data) to block the entire ISP.
The problem with that is that someone with an /80 in that /64 could get everyone else on that /64 blocked, which could be used as a way to target specific people by getting them kicked off their guard.
/64 is the smallest allocation for an ethernet link. The only place where multiple subscribers might be in the same /64 is hosting. For every other case, a /64 is assigned to one customer. -- Gruß Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
participants (4)
-
forest-relay-contact＠cryptolab.net -
Marco Moock -
rE-Bo0t.bx1 -
Toralf Förster