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, NOC<t...@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
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
