[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #19468 [Core Tor/Tor]: Revise prop259 to fit the Tor networking API
#19468: Revise prop259 to fit the Tor networking API
-------------------------------------------------+-------------------------
Reporter: asn | Owner: nickm
Type: defect | Status:
Priority: Medium | needs_revision
Component: Core Tor/Tor | Milestone: Tor:
Severity: Normal | 0.2.9.x-final
Keywords: tor-guard, TorCoreTeam201606, | Version:
prop259, TorCoreTeam201607 | Resolution:
Parent ID: #12595 | Actual Points: 5
Reviewer: | Points: 3
| Sponsor:
| SponsorU-must
-------------------------------------------------+-------------------------
Comment (by teor):
Replying to [comment:12 teor]:
> '''IP Version Preferences'''
>
> There's no mention in the proposal of clients which can reach both IPv4
and IPv6 addresses, but prefer IPv6 addresses. We should use
`ClientPreferIPv6ORPort` to tell us whether to prioritise using guards
that support IPv6 over those that do not. [Section:FILTERED] would be a
good place for this. I'd say it like this:
>
> - If ClientPreferIPv6ORPort is 1, and UseBridges is 0, it has an IPv6
ORPort
> (this restriction must be ignored if fewer than
{MEANINGFUL_RESTRICTION_FRAC} of {set:GUARDS} have an IPv6 ORPort),
>
> That way, we make sure every guard is usable. But we also make sure that
Tor still works on IPv4-only networks.
>
> I considered modifying [Section:CONFIRMED] or [Section:PRIMARY] instead,
but it got very complicated, very quickly. But perhaps we should consider
using it as one of the ordering criteria as well, particularly if the
current proportion of IPv6 guards is close to
{MEANINGFUL_RESTRICTION_FRAC}.
Hmm, I'm not sure this will work, particularly for bridge clients, which
only know either an IPv4 or an IPv6 address for their bridge. (Or a
pluggable transport address, some of which are fake - but that is another
matter.)
So we'll need to change the ordering in [Section:CONFIRMED] so either:
* all guards with preferred addresses are higher priority than all guards
without preferred addresses, or
* within any grouping, guards with preferred addresses are higher priority
than guards without preferred addresses. (I think this is the option we
want.)
I think we might also want to make a similar modification to
[Section:PRIMARY].
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19468#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs