diff options
Diffstat (limited to 'doc/spec/proposals/117-ipv6-exits.txt')
| -rw-r--r-- | doc/spec/proposals/117-ipv6-exits.txt | 348 |
1 files changed, 184 insertions, 164 deletions
diff --git a/doc/spec/proposals/117-ipv6-exits.txt b/doc/spec/proposals/117-ipv6-exits.txt index 1fefe6e03..47ee2abdd 100644 --- a/doc/spec/proposals/117-ipv6-exits.txt +++ b/doc/spec/proposals/117-ipv6-exits.txt @@ -3,281 +3,301 @@ 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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 + 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. + 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. + 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. + 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. + 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. + 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. + 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: + 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. + 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: + 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: + 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 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. + 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. + 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. + 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. + 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. + 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. + 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. + 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). + 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? + 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? + 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. + 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 + 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. + 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? + 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. + 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. + 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 |