Hi,
On 2 Aug 2019, at 09:20, NOC<tor@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev