That would imply that guard relays run at 100% capacity which i can't confirm for any of my guards. Also seeing decline in usage would maybe give a incentive for some relay operators to configure IPv6 in their torrc, because there are thousands of relays which do have IPv6 connectivity, but the operator simply didn't configure it because it is not as easy as putting "ORPort 9001" in your torrc and it listens on IPv4 and IPv6.
Sadly ORPort 9001 gives you a working relay which listens only on IPv4, so i would say the lack of IPv6 enabled relays is a problem which is created by how the config works and that a default torrc file loses no word about IPv6.
Beside that if i look at https://metrics.torproject.org/bandwidth-flags.html the Tor network could lose their entire IPv4 only guards and still work, but after that guards would indeed run at 100% capacity.
On 02.08.2019 02:05, teor wrote:
Hi,
On 2 Aug 2019, at 09:20, NOCtor@afo-tm.org wrote:
I see this staying longer with IPv4 longer than we should also problematic, we are at the point that there are providers out there who do have more clients than IPv4 space which results in having them making carrier grade NAT. Some of them have the problem that their NAT gear gets maxed out at peak hours which results in heavy packet loss and very slow speeds, while their IPv6 connection is perfectly fine. That will not get better, i guess it will get worse in the future. So i would also prefer to use IPv6 if it works better.
Currently, Tor clients don't use IPv6 unless they are specifically configured to use it. Some apps (OnionBrowser) use the OS network APIs to automatically configure Tor, but most don't.
This proposal makes sure that Tor clients try IPv4, then try IPv6 after a short delay. If either works, the client will connect to the Tor network.
At this stage, only 20% of guards support IPv6. But we are going to make sure at least one of the three client primary guards has IPv6. Ensuring at least one IPv6 client guard will increase traffic to IPv6 guards by up to 1.7x, which could cause load balancing issues.
So we need to counter this load imbalance by trying IPv6 after IPv4.
Once 33% of non-exit guards support IPv6, we can reduce the delay, or try IPv6 first at random. Once 67% of non-exit guards support IPv6, we can try IPv6 first.
We are working on a funding proposal that will increase the number of IPv6 relays by automatically detecting, testing, and using IPv6 addresses.
T _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev