
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><div>Hi,</div><div><br></div></div><div dir="ltr">On 2 Aug 2019, at 13:02, NOC <<a href="mailto:tor@afo-tm.org">tor@afo-tm.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>That would imply that guard relays run at 100% capacity which i can't confirm for any of my guards.</span></div></blockquote><div><br></div>I have run guards at 100% before, but it's not ideal.<br><div><br></div><div>Generally, Tor load-balances traffic to make sure that clients get consistently good bandwidth and latency. Adding significant extra load to some relays makes it hard to achieve this goal. In particular, 100% relay usage can significantly increase latency.</div><br><blockquote type="cite"><div dir="ltr"><span>Also seeing decline in usage would maybe give a incentive for some relay operators to configure IPv6 in their torrc,</span></div></blockquote><div><br></div>But IPv4-only relays *will* see a decrease in traffic, and IPv6 relays will see an increase.<br><div><br></div><div>Sending 33% of client traffic to the 20% of guards that have IPv6 will cause an increase in usage for IPv6 relays (and a decrease for IPv4 relays). Even if we check the relay's IPv6 address after its IPv4 address, the traffic is still going to that relay.</div><div><br></div><div>Tor clients on IPv6-only networks will also add extra to IPv6 relays. These clients don't work now, so we don't know how many there are.</div><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">Once we've tested IPv6 in at least one stable release, we will have a better idea of the load balancing impacts of IPv6. And we can think about changing the address order.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Another reason that we want to check IPv4 first is that is preserves tor's current behaviour. Adding</span><span style="background-color: rgba(255, 255, 255, 0);"> an extra attempt at IPv6 once IPv4 has failed, is a smaller change that is unlikely to have any negative impacts.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">(Our last attempt at adding automatic client IPv6 didn't work, and we had to disable it in Tor Browser alpha.)</span></div><br><blockquote type="cite"><div dir="ltr"><span>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.</span><br><span></span><br><span>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</span></div></blockquote><div><br></div><div><blockquote type="cite"><div dir="ltr"><blockquote type="cite"><font color="#000000"><span style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);">We are working on a funding proposal that will increase the number of IPv6 relays by automatically detecting, testing, and using IPv6 addresses.</span></font></blockquote></div></blockquote></div><br><blockquote type="cite"><div dir="ltr"><span> and that a default torrc file loses no word about IPv6.</span><br></div></blockquote><div><br></div><div>You're right, I opened a ticket to add IPv6 ORPorts to the example torrcs:</div><div><a href="https://trac.torproject.org/projects/tor/ticket/31320#ticket">https://trac.torproject.org/projects/tor/ticket/31320</a></div><br><blockquote type="cite"><div dir="ltr"><span>Beside that if i look at <a href="https://metrics.torproject.org/bandwidth-flags.html">https://metrics.torproject.org/bandwidth-flags.html</a> the Tor network could lose their entire IPv4 only guards and still work, but after that guards would indeed run at 100% capacity.</span><br></div></blockquote><div><br></div><div>See my answer above: 100% capacity is not good for the network or clients.</div><div><br></div><div>T</div></body></html>