Hi teor,
On 2019-03-05 21:12, teor wrote:
Sure. We usually do torspec changes using GitHub pull requests. Can you open a pull request on https://github.com/torproject/torspec ? Then link to the pull request from #27491 or in an email reply.
The GitHub PR is here: https://github.com/torproject/torspec/pull/61
Just so you know:
Tor Browser is going to test the #27940 version of ClientAutoIPv6ORPort in their alpha series, as a potential fix for IPv6 failures: https://trac.torproject.org/projects/tor/ticket/29641#comment:4
I expect that #27940 will trigger some bugs in the guard code, because all connections for an entire IP version will fail. Then we can teach the guard code to ignore those kinds of failures.
But that will mean that Tor Browser is depending on ClientAutoIPv6ORPort. So we will also need to add a new option to activate the code for this proposal. (Otherwise, we won't know if this proposal is better or worse!)
Makes sense. After all, IPv4/IPv6 selection is complex it something this complicated shouldn't be a "one size fits all".
Here's one way we could do that:
Add a new option ClientAutoIPv6ORPortStrategy, which takes some flags. When no flags are set (the default), we use the original ClientAutoIPv6ORPort. Then we add a flag for this proposal:
- TrackFailures
Then other tickets can use other flags:
- CheckLocalAddresses for #27492 Try IPv4 or IPv6 more often based on public or private IP
addresses
- CheckConsensus for #27647 When randomly choosing IPv4 or IPv6, set IPv6 probability
based on IPv6 weight
What do you think? Would you like to make these changes to this proposal?
These additions sound good.
I have added the "TrackFailures" flag to my GitHub PR and also mentioned other flags will come in the future.
-Neel
===