[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