Re: [tor-bugs] #5547 [Tor]: Add support for resolving destination names to IPv6 and exiting to IPv6 destinations

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#5547: Add support for resolving destination names to IPv6 and exiting to IPv6
destinations
-------------------------------------------------------+--------------------
 Reporter:  karsten                                    |          Owner:  nickm             
     Type:  project                                    |         Status:  needs_review      
 Priority:  normal                                     |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                                        |        Version:                    
 Keywords:  SponsorF20121101 needs-proposal tor-relay  |         Parent:                    
   Points:                                             |   Actualpoints:                    
-------------------------------------------------------+--------------------

Comment(by nickm):

 Acting on Andrea's reviews:
 > In d39684896e93aefca1d1c738556c2943eae7ed29, it doesn't look like the
 cache actually becomes per-circuit, just that it now passes a circuit
 parameter around. This is intentional to allow for future implementation,
 I presume?

 Yes, that's right.

 > 9a7d1c27432f04bab21b0cbb5ddfc41bc53d8096 looks good and I agree that
 having parsed-cell data structures like this is better than the current
 ad-hocery, but I don't quite see the connection to IPv6. Might have made
 more sense in its own branch. I presume from this that
 tor_addr_port_split() already parses IPv6 addresses?

 The rationale for doing this on this branch was that BEGIN cells needed to
 begin taking a new 'flags' argument, and I wasn't confident in my ability
 to add it correctly without screwing anything up.

 > In 2245ef768094646e22c01caa4420f49fcf6c432e, where does/will the
 TAPMP_EXTENDED_STAR flag come from? It looks like the new flags argument
 to tor_addr_parse_mask_ports() is always being set to 0 so far. Also, I
 think comments should be added to the default config file documenting this
 syntax; it's convenient but strikes me as quite counterintuitive, in that
 my brain wants to read things like '*4' and '*6' as regular expressions.

 I added it to router_parse_addr_policy_item_from_string in 8e33d77e.
 Editing the default config file is something we don't want to do too
 often, since it messes with debian packages, but we should do so when
 we're close to an 0.2.4.x-beta or -rc. I'll add a ticket to that effect.

 It's not too late to come up with a better syntax!  Is there anything you
 like more?

 > I know this is a bit of an abstract concern, since we're unlikely to be
 worried about any protocols other than IPv4 and IPv6 at any point in the
 near future, but it bothers me a bit that we now have two protocols and in
 some places we're dealing with them by ad-hoc code that effectively embeds
 knowledge of what protocols we support in a hardwired way. Things like the
 expansion of AF_UNSPEC into AF_INET and AF_INET6 wildcards in
 policy_expand_unspec() of commit 8e33d77ee1cc73fc5638caff886d16a1a7779646
 feel like they should be more table-driven or something, I guess. Similar
 comments for exit_policy_remove_redundancies() in that commit.

 I don't agree here; if we need to add IPv7 support, we will have plenty of
 warning, and the likelihood of an IPv7 hitting in our lifetime seems a
 little low.  Although from an abstract POV I agree that "there are only 3
 numbers in cs: 0, 1, and infinity", I think that this number is so likely
 to remain 2 that it is going to be safe to keep it.

 >I can think of two other 'easy' cases I didn't see handled (correct me if
 I'm wrong): transparent proxying of IPv6 clients, and hidden service on an
 IPv6 address.
 > Then I can think of one harder one: a multiprotocol network where relays
 are allowed to support only a subset of all protocols means the
 connectivity graph among relays is no longer complete

 I think transparent proxying of IPv6 clients will be trivial to add after
 the nov15 deadline; it isn't much more code.  Hidden service to an IPv6
 address is orthogonal to this, but doable.  A network where some relays
 have no IPv4 address has the problem you mention where the topology of the
 network would change; it's something to contemplate, but also orthogonal
 IMO.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5547#comment:23>
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