[or-cvs] r10783: Add IPv6 exit proposal from coderman. (in tor/trunk: . doc/spec/proposals)
nickm at seul.org
nickm at seul.org
Tue Jul 10 17:17:14 UTC 2007
Author: nickm
Date: 2007-07-10 13:17:14 -0400 (Tue, 10 Jul 2007)
New Revision: 10783
Added:
tor/trunk/doc/spec/proposals/117-ipv6-exits.txt
Modified:
tor/trunk/
tor/trunk/doc/spec/proposals/000-index.txt
Log:
r13672 at catbus: nickm | 2007-07-10 13:17:08 -0400
Add IPv6 exit proposal from coderman.
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r13672] on 8246c3cf-6607-4228-993b-4d95d33730f1
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2007-07-10 17:14:55 UTC (rev 10782)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2007-07-10 17:17:14 UTC (rev 10783)
@@ -33,4 +33,7 @@
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]
Added: tor/trunk/doc/spec/proposals/117-ipv6-exits.txt
===================================================================
--- tor/trunk/doc/spec/proposals/117-ipv6-exits.txt (rev 0)
+++ tor/trunk/doc/spec/proposals/117-ipv6-exits.txt 2007-07-10 17:17:14 UTC (rev 10783)
@@ -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
+
Property changes on: tor/trunk/doc/spec/proposals/117-ipv6-exits.txt
___________________________________________________________________
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
More information about the tor-commits
mailing list