[tor-bugs] #23819 [Core Tor/Tor]: Support IPv6 link-local interface addresses

Fri Oct 13 18:24:53 UTC 2017

#23819: Support IPv6 link-local interface addresses
-----------------------------+----------------------------------
 Reporter:  Zakhar           |          Owner:  (none)
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor     |        Version:  Tor: unspecified
 Severity:  Normal           |     Resolution:
 Keywords:  ipv6 link-local  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+----------------------------------

Comment (by Zakhar):

 Ok, I have checked that it is unchanged in the last version, and I am
 proposing a "patch" against version 0.2.9.11

 But before that, for the record, I'll detail the "rationale" of this
 '''"enhancement request"'''

 ----
 = Rationale =
 == Use cases and addressing ==
 Tor can be used in different way on the client machine.

 Most commonly, people would use software bundles as "Tor Browser". For
 this kind of use, the Tor daemon needs only listen on the loopback
 interface since we are using it only from a single host.

 Although less common, tor can be configured on a machine so that this
 machine behaves as a router redirecting traffic to tor for other machines
 on the LAN or even for VMs on the router itself.

 For this usage, we need to make the tor daemon listen some ports on the
 relevant local interface of our router.

 When using IPV4, the daemon would typically bind to addresses like
 192.168.0.17 or 172.30.20.10 or the like. Those are "reserved" in the V4
 addressing space and cannot be routed to the Internet.

 When using IPV6, the "best practice" for routing inside a local network is
 to use "link-local" addresses. This is a new concept that comes with IPV6.
 These addresses are local and unique in the scope of a link. What this
 means, is that since we are configuring a router, this router has several
 interface, and you can validly assign the same "link local" address, for
 example ![fe80::1] to all your interfaces in your router. Thus, for
 routing purpose, you must add the interface to the address for
 disambiguation.

 For an easy reading you can look at [https://en.wikipedia.org/wiki/Link-
 local_address Wikipedia Link Local]

 This complete norm: [https://tools.ietf.org/search/rfc4007#section-4
 RFC4007 section 4]

 The RFC clearly says (last sentence first paragraph of section 4)

 '''`The scope of an address is encoded as part of the address`'''

 The tor daemon is also used for tor nodes: entry, relay, exit, etc... I
 won't go into that use case here.

 Now, of course, the tor daemon running on the client/router machine also
 uses other addresses, it is the addresses of the sites you are visiting.
 Those addresses should normally be "on the internet" meaning outside of
 your local machine (unless you are performing tests a locally installed
 tor network which is probably a super rare use case).

 For ipV6 we call that "global" scope. "Global" scope addresses don't need
 the "zone index"... well since there are global as they name says, there
 is no ambiguity. You then transparently use "default zone index"
 (precisely you don't need to specify it as it is explained later in
 RFC4007).

 == Summary of what tor daemon supports ==
 Let's forget the ultra rare case of testing a local tor network with
 relays, entry guards, etc... and focus of what the tor daemon can do on
 your local machine apart from routing packets to the Internet on global
 addresses (which is the main purpose and work well!)

 '''IPV4'''

  * localhost (main usage: Tor Browser)

  * local "reserved" address (LAN router)

  * "global" address (nodes: entry, relay, exit, etc..)

 '''IPV6'''

  * localhost (main usage: Tor Browser)

  * "global" address? (not tested but should work since there are some
 entry/exits having ipV6!)

 So basically, you '''CANNOT''' (in the respect of good practice) build an
 ipv6 "tor router" at the moment.

 This is an acknowledged fact and a limitation.

 Some might argue that it is indeed a "bug" to be not compliant with
 RFC4007, limiting the ipv6 address to 16 bytes and omitting the "zone
 index"... but I'm fine with "acknowledged limitation"!

 == (NOT RECOMMENDED) Workaround ==
 Since ipv6 is much more easy than ipv4, one could also assign a global
 scope address to the interface and work with that.

 But in doing so, you are opening a lot of other issues. First you would
 have to advertise this address as the route for SLAAC configured machines
 on you "tor router" LAN, which is not the default behaviour as you are
 supposed to use link local addresses.

 Link local addresses are best practice, because should you have
 misconfigured some parts of your router, there is always a risk that your
 global addressable ipv6 be leaked. That is your "real" address and in a
 "tor" situation you absolutely do NOT want that!

 You could try with ULA (Unique Local Address) with some more hedaches on
 the softwares to make that unique, but indeed avoid the risk of global
 addresses.

 = Patch =
 So to be helpful (hopefully) I am attaching a patch against 0.2.9.11

 This patch touches only 2 files under src:

  * common/address.c
  * common/address.h

 It is 8 lines of code.

 == Limitations of the patch ==
 It works on a reasonably recent Linux (must have getaddrinfo).
 I have no time nor the resource to test on other O.S.es

 It is not a "correct architecture" correction, I consider it a "temporary
 patch".
 The correct re-architecture would be to use, on each instance where an
 ipv6 address is used, a "full" ipv6 address as specified by RFC4007,
 without omitting the "zone index" (which on Linux is simplified as the
 'scope_id', and that is explained also in the RFC).

 Instead, I added in6_full to the tor_addr_t union, without touching
 in6_addr which would have had a lot of impacts everywhere.

 in6_full is then used only in address.c where we need it, that is after
 getaddrinfo to save the 'scope_id' that is returned, and when we translate
 back a tor_add_t into the structure to open the socket, in order to
 restore the captured 'scope_id' so that the subsequent bind works.

 Last limitation, I have not done extensive tests so far.

 == Applicability to the main branch (0.3.x) ==
 Although the lines have changed, address.c looks the same around where I
 patched. So the patch should be applicable from 0.2.9.11 upwards.

 == AOB ==
 '''@For the TOR team'''... do you need any other input (on your GIT, or
 else) from me to progress this "enhancement"?

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