r13672@catbus: nickm | 2007-07-10 13:17:08 -0400

 Add IPv6 exit proposal from coderman.


svn:r10783

2 files changed, 343 insertions, 0 deletions

diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt
index 08f33d36f..843f08d0e 100644
--- a/doc/spec/proposals/000-index.txt
+++ b/doc/spec/proposals/000-index.txt
@@ -33,4 +33,7 @@ Proposals by number:
 112  Bring Back Pathlen Coin Weight [OPEN]
 113  Simplifying directory authority administration [OPEN]
 114  Distributed Storage for Tor Hidden Service Descriptors [OPEN]
+115  Two Hop Paths [OPEN]
+116  Two hop paths from entry guards [OPEN]
+117  IPv6 exits [OPEN]
 
diff --git a/doc/spec/proposals/117-ipv6-exits.txt b/doc/spec/proposals/117-ipv6-exits.txt
new file mode 100644
index 000000000..1fefe6e03
--- /dev/null
+++ b/doc/spec/proposals/117-ipv6-exits.txt
@@ -0,0 +1,340 @@
+Proposal : IPv6 exit
+
+Overview
+
+   Extend Tor for TCP exit via IPv6 transport and DNS resolution of IPv6
+   addresses.  This proposal does not imply any IPv6 support for OR traffic,
+   only exit and name resolution.
+
+
+Contents
+
+0. Motivation
+
+   As the IPv4 address space becomes more scarce there is increasing effort to
+   provide Internet services via the IPv6 protocol.  Many hosts are available
+   at IPv6 endpoints which are currently inaccessible for Tor users.
+
+   Extending Tor to support IPv6 exit streams and IPv6 DNS name resolution will
+   allow users of the Tor network to access these hosts.  This capability would
+   be present for those who do not currently have IPv6 access, thus increasing
+   the utility of Tor and furthering adoption of IPv6.
+
+
+1. Design
+
+1.1. General design overview
+
+   There are three main components to this proposal.  The first is a method for
+   routers to advertise their ability to exit IPv6 traffic.  The second is the
+   manner in which routers resolve names to IPv6 addresses.  Last but not least
+   is the method in which clients communicate with Tor to resolve and connect
+   to IPv6 endpoints anonymously.
+
+1.2. Router IPv6 exit support
+
+   In order to specify exit policies and IPv6 capability new directives in the
+   Tor configuration will be needed.  If a router advertises IPv6 exit policies
+   in its descriptor this will signal the ability to provide IPv6 exit.  There
+   are a number of additional default deny rules associated with this new
+   address space which are detailed in the addendum.
+
+   When Tor is started on a host it should check for the presence of a global
+   unicast address, [2000::]/3, and if present include the default IPv6 exit
+   policies and any user specified IPv6 exit policies.
+
+   If a user provides IPv6 exit policies but no global unicast address is
+   available Tor should generate a warning and not publish the IPv6 policy in
+   the router descriptor.
+
+   It should be noted that IPv4 mapped IPv6 addresses are not valid exit
+   destinations.  This mechanism is mainly used to interoperate with both IPv4
+   and IPv6 clients on the same socket.  Any attempts to use an IPv4 mapped
+   IPv6 address, perhaps to circumvent exit policy for IPv4, must be refused.
+
+1.3. DNS name resolution of IPv6 addresses (AAAA records)
+
+   In addition to exit support for IPv6 TCP connections, a method to resolve
+   domain names to their respective IPv6 addresses is also needed.  This is
+   accomplished in the existing DNS system via AAAA records.  Routers will
+   perform both A and AAAA requests when resolving a name so that the client can
+   utilize an IPv6 endpoint when available or preferred.
+
+   To avoid potential problems with caching DNS servers that behave poorly all
+   NXDOMAIN responses to AAAA requests should be ignored if a successful
+   response is received for an A request.  This implies that both AAAA and A
+   requests will always be performed for each name resolution.
+
+   For reverse lookups on IPv6 addresses, like that used for RESOLVE_PTR, Tor
+   will perform the necessary PTR requests via IP6.ARPA.
+
+   All routers which perform DNS resolution on behalf of clients (RELAY_RESOLVE)
+   should perform and respond with both A and AAAA resources.
+
+1.4. Client interaction with IPv6 exit capability
+
+1.4.1. Usability goals
+
+   There are a number of behaviors which Tor can provide when interacting with
+   clients that will improve the usability of IPv6 exit capability.  These
+   behaviors are designed to make it simple for clients to express a preference
+   for IPv6 transport and utilize IPv6 host services.
+
+1.4.2. SOCKSv5 IPv6 client behavior
+
+   The SOCKS version 5 protocol supports IPv6 connections.  When using SOCKSv5
+   with hostnames it is difficult to determine if a client wishes to use an IPv4
+   or IPv6 address to connect to the desired host if it resolves to both address
+   types.
+
+   In order to make this more intuitive the SOCKSv5 protocol can be supported on
+   a local IPv6 endpoint, [::1] port 9050 for example.  When a client requests
+   a connection to the desired host via an IPv6 SOCKS connection Tor will prefer
+   IPv6 addresses when resolving the host name and connecting to the host.
+
+   Likewise, RESOLVE and RESOLVE_PTR requests from an IPv6 SOCKS connection will
+   return IPv6 addresses when available, and fall back to IPv4 addresses if not.
+
+1.4.3. MAPADDRESS behavior
+
+   The MAPADDRESS capability supports clients that may not be able to use the
+   SOCKSv4a or SOCKSv5 hostname support to resolve names via Tor.  This ability
+   should be extended to IPv6 addresses in SOCKSv5 as well.
+
+   When a client requests an address mapping from the wildcard IPv6 address,
+   [::0], the server will respond with a unique local IPv6 address on success.
+   It is important to note that there may be two mappings for the same name
+   if both an IPv4 and IPv6 address are associated with the host.  In this case
+   a CONNECT to a mapped IPv6 address should prefer IPv6 for the connection to
+   the host, if available, while CONNECT to a mapped IPv4 address will prefer
+   IPv4.
+
+   It should be noted that IPv6 does not provide the concept of a host local
+   subnet, like 127.0.0.0/8 in IPv4.  For this reason integration of Tor with
+   IPv6 clients should consider a firewall or filter rule to drop unique
+   local addresses to or from the network when possible.  These packets should
+   not be routed, however, keeping them off the subnet entirely is worthwhile.
+
+1.4.3.1. Generating unique local IPv6 addresses
+
+   The usual manner of generating a unique local IPv6 address is to select a
+   Global ID part randomly, along with a Subnet ID, and sharing this prefix
+   among the communicating parties who each have their own distinct Interface
+   ID.  In this style a given Tor instance might select a random Global and
+   Subnet ID and provide MAPADDRESS assignments with a random Interface ID as
+   needed.  This has the potential to associate unique Global/Subnet identifiers
+   with a given Tor instance and may expose attacks against the anonymity of Tor
+   users.
+
+   Tor avoid this potential problem entirely MAPADDRESS must always generate the
+   Global, Subnet, and Interface IDs randomly for each request.  It is also
+   highly suggested that explicitly specifying an IPv6 source address instead of
+   the wildcard address not be supported to ensure that a good random address is
+   used.
+
+1.4.4. DNSProxy IPv6 client behavior
+
+   A new capability in recent Tor versions is the transparent DNS proxy.  This
+   feature will need to return both A and AAAA resource records when responding
+   to client name resolution requests.
+
+   The transparent DNS proxy should also support reverse lookups for IPv6
+   addresses.  It is suggested that any such requests to the deprecated IP6.INT
+   domain should be translated to IP6.ARPA instead.  This translation is not
+   likely to be used and is of low priority.
+
+   It would be nice to support DNS over IPv6 transport as well, however, this
+   is not likely to be used and is of low priority.
+
+1.4.5. TransPort IPv6 client behavior
+
+   Tor also provides transparent TCP proxy support via the Trans* directives in
+   the configuration.  The TransListenAddress directive should accept an IPv6
+   address in addition to IPv4 so that IPv6 TCP connections can be transparently
+   proxied.
+
+1.5. Additional changes
+
+   The RedirectExit option should be deprecated rather than extending this
+   feature to IPv6.
+
+
+2. Spec changes
+
+2.1. Tor specification
+
+   In '6.2. Opening streams and transferring data' the following should be
+   changed to indicate IPv6 exit capability:
+
+      "No version of Tor currently generates the IPv6 format."
+
+   In '6.4. Remote hostname lookup' the following should be updated to reflect
+   use of ip6.arpa in addition to in-addr.arpa.
+
+      "For a reverse lookup, the OP sends a RELAY_RESOLVE cell containing an
+       in-addr.arpa address."
+
+   In 'A.1. Differences between spec and implementation' the following should
+   be updated to indicate IPv6 exit capability:
+
+      "The current codebase has no IPv6 support at all."
+
+2.2. Directory specification
+
+   In '2.1. Router descriptor format' a new set of directives is needed for
+   IPv6 exit policy.  The existing accept/reject directives should be
+   clarified to indicate IPv4 or wildcard address relevance.  The new IPv6
+   directives will be in the form of:
+
+      "accept6" exitpattern NL
+      "reject6" exitpattern NL
+
+   The section describing accept6/reject6 should explain that the presence
+   of accept6 or reject6 exit policies in a router descriptor signals the
+   ability of that router to exit IPv6 traffic (according to IPv6 exit
+   policies).
+
+   The "[::]/0" notation is used to represent "all IPv6 addresses".  "[::0]/0"
+   may also be used for this representation.
+
+   If a user specifies a 'reject6 [::]/0:*' policy in the Tor configuration this
+   will be interpreted as forcing no IPv6 exit support and no accept6/reject6
+   policies will be included in the published descriptor.  This will prevent
+   IPv6 exit if the router host has a global unicast IPv6 address present.
+
+   It is important to note that a wildcard address in an accept or reject policy
+   applies to both IPv4 and IPv6 addresses.
+
+2.3. Control specification
+
+   In '3.8. MAPADDRESS' the potential to have to addresses for a given name
+   should be explained.  The method for generating unique local addresses
+   for IPv6 mappings needs explanation as described above.
+
+   When IPv6 addresses are used in this document they should include the
+   brackets for consistency.  For example, the null IPv6 address should be
+   written as "[::0]" and not "::0".  The control commands will expect the
+   same syntax as well.
+
+   In '3.9. GETINFO' the "address" command should return both public IPv4 and
+   IPv6 addresses if present.  These addresses should be separated via \r\n.
+
+
+2.4. Tor SOCKS extensions
+
+   In '2. Name lookup' a description of IPv6 address resolution is needed for
+   SOCKSv5 as described above.  IPv6 addresses should be supported in both the
+   RESOLVE and RESOLVE_PTR extensions.
+
+   A new section describing the ability to accept SOCKSv5 clients on a local
+   IPv6 address to indicate a preference for IPv6 transport as described above
+   is also needed.  The behavior of Tor SOCKSv5 proxy with an IPv6 preference
+   should be explained, for example, preferring IPv6 transport to a named host
+   with both IPv4 and IPv6 addresses available (A and AAAA records).
+
+
+3. Questions and concerns
+
+3.1. DNS A6 records
+
+   A6 is explicitly avoided in this document.  There are potential reasons for
+   implementing this, however, the inherent complexity of the protocol and
+   resolvers make this unappealing.  Is there a compelling reason to consider
+   A6 as part of IPv6 exit support?
+
+3.2. IPv4 and IPv6 preference
+
+   The design above tries to infer a preference for IPv4 or IPv6 transport
+   based on client interactions with Tor.  It might be useful to provide
+   more explicit control over this preference.  For example, an IPv4 SOCKSv5
+   client may want to use IPv6 transport to named hosts in CONNECT requests
+   while the current implementation would assume an IPv4 preference.  Should
+   more explicit control be available, through either configuration directives
+   or control commands?
+
+   This can be worked around by resolving names and then CONNECTing to an IPv4
+   or IPv6 address as desired, however, not all client applications may have
+   this option available.
+
+3.3. Support for IPv6 only clients
+
+   It may be useful to support IPv6 only clients using IPv4 mapped IPv6
+   addresses.  This would require transparent DNS proxy using IPv6 
+   transport and the ability to map A record responses into IPv4 mapped
+   IPv6 addresses.  The transparent TCP proxy would thus need to detect these
+   mapped addresses and connect to the desired IPv4 host.
+
+   The relative lack of any IPv6 only hosts or applications makes this a lot of
+   work for very little gain.  Is there a compelling reason to support this
+   capability?
+
+3.4. IPv6 DNS and older Tor routers
+
+   It is expected that many routers will continue to run with older versions of
+   Tor when the IPv6 exit capability is released.  Clients who wish to use IPv6
+   will need to route RELAY_RESOLVE requests to the newer routers which will
+   respond with both A and AAAA resource records when possible.
+
+   One way to do this is to route RELAY_RESOLVE requests to routers with IPv6
+   exit policies published, however, this would not utilize current routers
+   that can resolve IPv6 addresses even if they can't exit such traffic.
+
+
+4. Addendum
+
+4.1. Sample IPv6 default exit policy
+
+   reject 0.0.0.0/8
+   reject 169.254.0.0/16
+   reject 127.0.0.0/8
+   reject 192.168.0.0/16
+   reject 10.0.0.0/8
+   reject 172.16.0.0/12
+   reject6 [0000::]/8
+   reject6 [0100::]/8
+   reject6 [0200::]/7
+   reject6 [0400::]/6
+   reject6 [0800::]/5
+   reject6 [1000::]/4
+   reject6 [4000::]/3
+   reject6 [6000::]/3
+   reject6 [8000::]/3
+   reject6 [A000::]/3
+   reject6 [C000::]/3
+   reject6 [E000::]/4
+   reject6 [F000::]/5
+   reject6 [F800::]/6
+   reject6 [FC00::]/7
+   reject6 [FE00::]/9
+   reject6 [FE80::]/10
+   reject6 [FEC0::]/10
+   reject6 [FF00::]/8
+   reject *:25
+   reject *:119
+   reject *:135-139
+   reject *:445
+   reject *:1214
+   reject *:4661-4666
+   reject *:6346-6429
+   reject *:6699
+   reject *:6881-6999
+   accept *:*
+   # accept6 [2000::]/3:* is implied
+
+4.2. Additional resources
+
+   'DNS Extensions to Support IP Version 6'
+   http://www.ietf.org/rfc/rfc3596.txt
+
+   'DNS Extensions to Support IPv6 Address Aggregation and Renumbering'
+   http://www.ietf.org/rfc/rfc2874.txt
+
+   'SOCKS Protocol Version 5'
+   http://www.ietf.org/rfc/rfc1928.txt
+
+   'Unique Local IPv6 Unicast Addresses'
+   http://www.ietf.org/rfc/rfc4193.txt
+
+   'INTERNET PROTOCOL VERSION 6 ADDRESS SPACE'
+   http://www.iana.org/assignments/ipv6-address-space
+