[tor-bugs] #17840 [Tor]: Add a minimal implementation of ClientUseIPv4 so IPv6-only clients can bootstrap

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Jan 20 04:32:03 UTC 2016


#17840: Add a minimal implementation of ClientUseIPv4 so IPv6-only clients can
bootstrap
--------------------+------------------------------------
 Reporter:  teor    |          Owner:  teor
     Type:  defect  |         Status:  needs_revision
 Priority:  Medium  |      Milestone:  Tor: 0.2.8.x-final
Component:  Tor     |        Version:
 Severity:  Normal  |     Resolution:
 Keywords:  ipv6    |  Actual Points:
Parent ID:  #17811  |         Points:
  Sponsor:          |
--------------------+------------------------------------

Comment (by teor):

 Replying to [comment:8 nickm]:
 > b6dda7afbd27 Fix *_get_all_orports to use ipv6_orport

 Pushed a fixup.

 >  * Hmm. What if the md has an IPv6 address but the rs doesn't?

 Fixed:
 * add tor_addr_port_is_valid and similar (this also helps with the
 addr/port validity checks in subsequent commits)
 * check that each ri/rs/md is non-NULL and has a a valid address
 * fall back to the next address source if a valid address wasn't found

 >  * Also, even macros should have documentation.

 Fixed.

 >
 > 53b0788505ee Add ClientUseIPv4 and ClientPreferIPv6DirPort torrc options

 Pushed a fixup commit.

 >  * 'node_has_ipv6_addr' has a similar issue to the one from the previous
 patch -- what if the md has no ipv6 address but the rs does?

 Fixed in a similar way to the previous commit
 * Reorder checks to be consistent with other functions (order is
 irrelevant to the result after this fix)

 >  * In the previous patch we looked at ports to see if the address was
 real; here we look at the address (in node_has_ipv6_addr).  Why? If
 there's a good reason let's document it.

 The previous patch now looks at both address and port.
 Modified node_ipv6_or/dir_preferred to check the address and port.
 Modified similar functions to check for valid addresses and ports using
 the new tor_addr_port_is_valid_* functions.

 node_has_ipv6_addr and node_get_prim_addr_ipv4h are not port-specific, so
 they don't know which port to check. Added comments documenting them as
 exceptional cases.

 I also found a formatting inconsistency in node_get_address_string, fixed
 it in a separate commit.

 >  * Removing firewall_is_fascist_or() from choose_good_entry_server()
 makes us iterate over the whole nodelist needlessly sometimes.  Does that
 hurt performance ?

 No, because the next commit removes the iteration which adds unreachable
 nodes to excluded, in favour of checking every node for
 preferred/reachable addresses as it's added to the included list in
 router_choose_random_node.

 Still, it's worth having to use elsewhere, but it is another place where
 we embed the assumption that every non-bridge relay has an IPv4 address.

 I put it back in, modified to work with
 ClientUseIPv4/ClientUseIPv6/UseBridges.
 (This also allows us to do some optimisations to the rest of the
 fascist_firewall_* functions, I'll add that as a final commit.)

 >  *  The stuff in options_validate() to set reachable_knows_ipv6 seems
 pretty horrible.  We should be parsing these to see whether they're ipv6,
 right?  Doing strstr and strcmpstart seems like it's guaranteed to miss
 something.

 Yes, that's ugly. Implemented a simpler check in parse_reachable_addresses
 instead:
 * if ClientUseIPv4 is 1 but fascist firewall blocks all IPv4 addresses, or
 * if ClientUseIPv6 is 1 (or UseBridges is 1) but fascist firewall blocks
 all IPv6 addresses,
 then warn the user they're not getting what they asked for.

 >  * nodelist_prefer_ipv6() seems a little icky; tristates can be
 confusing, especially when the name implies that the function returns a
 boolean.  Maybe rename it to end with "_impl" to make it clear that this
 is an internal-use-only function that the other functions will refer to.

 Done!

 >  * Also, it's against house style to say "refer to bug X" in the Tor
 code.  If it's important enough to refer to in a comment, it's probably
 important enough to explain in the comment.

 Deleted that part of the comment, it's not important.

 >  * Why is nodelist_prefer_* a nodelist function?  It doesn't seem to use
 or manipulate nodes or the nodelist.

 Renamed to fascist_firewall_prefer_* and moved to policies.[ch].
 We can do more renaming when we rename the entire fascist_firewall_*
 function set.

 >  * Can we remove the fascist_firewall_allows_... ri, rs, and md cases in
 favor of fascist_firewall_allows_node ?  Whenever an ri, rs, or md exists,
 a node should exist too.   At the very list, nobody should be using a raw
 md to refer to a node.
 >  * Same as above for choose_address...

 We need fascist_firewall_allows/choose_address_rs because it's used by
 fascist_firewall_allows_dir_server (which passes it
 dir_server_t.fake_status) and
 directory_initiate_command_routerstatus_rend.

 The others can be removed.

 >  * The name fascist_firewall_... is less appropriate than it used to be.
 Let's add a new ticket to rename them though.

 I particularly dislike fascist_firewall_choose_address_impl &
 fascist_firewall_choose_address_base. I'd run out of creativity by that
 point.

 Split off as #18106.

 >
 > 1d81c63c85b4 Choose OR Entry Guards using IPv4/IPv6 preferences
 >   * LGTM
 > 4d453a7a9041 Choose directory servers by IPv4/IPv6 preferences
 >   * I'll return to this after I review all the little ones.
 > dede8d405348 Log when IPv4/IPv6 restrictions or preferences weren't met
 >   * Seems worthwhile.
 > a8a1cb70ce95 fixup! Add ClientUseIPv4 and ClientPreferIPv6DirPort torrc
 options
 >   * LGTM
 > 0204c9dca838 Choose bridge addresses by IPv4/IPv6 preferences
 >   * LGTM
 > fb1cb1bd3046 Make entry_guard_set_status consistent with entry_is_live
 >   * Yup, lgtm.
 > 5ffe801801da Use fascist firewall and ClientUseIPv4 for bridge clients
 >   * I'll return to this too after I've reviewed all the little ones.
 >
 > Looks like I've got a couple more commits to review!

 And I have a few more to fixup!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17840#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list