IPv6 exit proposal

[coderman <coderman@xxxxxxxxx>]

apologies for formatting; available at
http://peertech.org/pub/tor-ipv6-exit-proposal.txt if this is
unreadable.

---

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