diff options
author | Nick Mathewson <nickm@torproject.org> | 2007-07-10 17:17:14 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2007-07-10 17:17:14 +0000 |
commit | 2721a2187afb23bd44bf0f048f535d7ac77d5999 (patch) | |
tree | 8526ff85d2e71da25acbef0a713635faa9dfbf35 /proposals/117-ipv6-exits.txt | |
parent | 72cc853b9e5f8dd85b54d51080a95b38d96d2ebf (diff) | |
download | torspec-2721a2187afb23bd44bf0f048f535d7ac77d5999.tar.gz torspec-2721a2187afb23bd44bf0f048f535d7ac77d5999.zip |
r13672@catbus: nickm | 2007-07-10 13:17:08 -0400
Add IPv6 exit proposal from coderman.
svn:r10783
Diffstat (limited to 'proposals/117-ipv6-exits.txt')
-rw-r--r-- | proposals/117-ipv6-exits.txt | 340 |
1 files changed, 340 insertions, 0 deletions
diff --git a/proposals/117-ipv6-exits.txt b/proposals/117-ipv6-exits.txt new file mode 100644 index 0000000..1fefe6e --- /dev/null +++ b/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 + |