1 Filename: 117-ipv6-exits.txt
10 Extend Tor for TCP exit via IPv6 transport and DNS resolution of IPv6
11 addresses. This proposal does not imply any IPv6 support for OR
12 traffic, only exit and name resolution.
19 As the IPv4 address space becomes more scarce there is increasing
20 effort to provide Internet services via the IPv6 protocol. Many
21 hosts are available at IPv6 endpoints which are currently
22 inaccessible for Tor users.
24 Extending Tor to support IPv6 exit streams and IPv6 DNS name
25 resolution will allow users of the Tor network to access these hosts.
26 This capability would be present for those who do not currently have
27 IPv6 access, thus increasing the utility of Tor and furthering
33 1.1. General design overview
35 There are three main components to this proposal. The first is a
36 method for routers to advertise their ability to exit IPv6 traffic.
37 The second is the manner in which routers resolve names to IPv6
38 addresses. Last but not least is the method in which clients
39 communicate with Tor to resolve and connect to IPv6 endpoints
42 1.2. Router IPv6 exit support
44 In order to specify exit policies and IPv6 capability new directives
45 in the Tor configuration will be needed. If a router advertises IPv6
46 exit policies in its descriptor this will signal the ability to
47 provide IPv6 exit. There are a number of additional default deny
48 rules associated with this new address space which are detailed in
51 When Tor is started on a host it should check for the presence of a
52 global unicast IPv6 address and if present include the default IPv6
53 exit policies and any user specified IPv6 exit policies.
55 If a user provides IPv6 exit policies but no global unicast IPv6
56 address is available Tor should generate a warning and not publish the
57 IPv6 policies in the router descriptor.
59 It should be noted that IPv4 mapped IPv6 addresses are not valid exit
60 destinations. This mechanism is mainly used to interoperate with
61 both IPv4 and IPv6 clients on the same socket. Any attempts to use
62 an IPv4 mapped IPv6 address, perhaps to circumvent exit policy for
63 IPv4, must be refused.
65 1.3. DNS name resolution of IPv6 addresses (AAAA records)
67 In addition to exit support for IPv6 TCP connections, a method to
68 resolve domain names to their respective IPv6 addresses is also
69 needed. This is accomplished in the existing DNS system via AAAA
70 records. Routers will perform both A and AAAA requests when
71 resolving a name so that the client can utilize an IPv6 endpoint when
72 available or preferred.
74 To avoid potential problems with caching DNS servers that behave
75 poorly all NXDOMAIN responses to AAAA requests should be ignored if a
76 successful response is received for an A request. This implies that
77 both AAAA and A requests will always be performed for each name
80 For reverse lookups on IPv6 addresses, like that used for
81 RESOLVE_PTR, Tor will perform the necessary PTR requests via
84 All routers which perform DNS resolution on behalf of clients
85 (RELAY_RESOLVE) should perform and respond with both A and AAAA
88 [NOTE: In a future version, when we extend the behavior of RESOLVE to
89 encapsulate more of real DNS, it will make sense to allow more
90 flexibility here. -nickm]
92 1.4. Client interaction with IPv6 exit capability
94 1.4.1. Usability goals
96 There are a number of behaviors which Tor can provide when
97 interacting with clients that will improve the usability of IPv6 exit
98 capability. These behaviors are designed to make it simple for
99 clients to express a preference for IPv6 transport and utilize IPv6
102 1.4.2. SOCKSv5 IPv6 client behavior
104 The SOCKS version 5 protocol supports IPv6 connections. When using
105 SOCKSv5 with hostnames it is difficult to determine if a client
106 wishes to use an IPv4 or IPv6 address to connect to the desired host
107 if it resolves to both address types.
109 In order to make this more intuitive the SOCKSv5 protocol can be
110 supported on a local IPv6 endpoint, [::1] port 9050 for example.
111 When a client requests a connection to the desired host via an IPv6
112 SOCKS connection Tor will prefer IPv6 addresses when resolving the
113 host name and connecting to the host.
115 Likewise, RESOLVE and RESOLVE_PTR requests from an IPv6 SOCKS
116 connection will return IPv6 addresses when available, and fall back
117 to IPv4 addresses if not.
119 [NOTE: This means that SocksListenAddress and DNSListenAddress should
120 support IPv6 addresses. Perhaps there should also be a general option
121 to have listeners that default to 127.0.0.1 and 0.0.0.0 listen
122 additionally or instead on ::1 and :: -nickm]
124 1.4.3. MAPADDRESS behavior
126 The MAPADDRESS capability supports clients that may not be able to
127 use the SOCKSv4a or SOCKSv5 hostname support to resolve names via
128 Tor. This ability should be extended to IPv6 addresses in SOCKSv5 as
131 When a client requests an address mapping from the wildcard IPv6
132 address, [::0], the server will respond with a unique local IPv6
133 address on success. It is important to note that there may be two
134 mappings for the same name if both an IPv4 and IPv6 address are
135 associated with the host. In this case a CONNECT to a mapped IPv6
136 address should prefer IPv6 for the connection to the host, if
137 available, while CONNECT to a mapped IPv4 address will prefer IPv4.
139 It should be noted that IPv6 does not provide the concept of a host
140 local subnet, like 127.0.0.0/8 in IPv4. For this reason integration
141 of Tor with IPv6 clients should consider a firewall or filter rule to
142 drop unique local addresses to or from the network when possible.
143 These packets should not be routed, however, keeping them off the
144 subnet entirely is worthwhile.
146 1.4.3.1. Generating unique local IPv6 addresses
148 The usual manner of generating a unique local IPv6 address is to
149 select a Global ID part randomly, along with a Subnet ID, and sharing
150 this prefix among the communicating parties who each have their own
151 distinct Interface ID. In this style a given Tor instance might
152 select a random Global and Subnet ID and provide MAPADDRESS
153 assignments with a random Interface ID as needed. This has the
154 potential to associate unique Global/Subnet identifiers with a given
155 Tor instance and may expose attacks against the anonymity of Tor
158 To avoid this potential problem entirely MAPADDRESS must always
159 generate the Global, Subnet, and Interface IDs randomly for each
160 request. It is also highly suggested that explicitly specifying an
161 IPv6 source address instead of the wildcard address not be supported
162 to ensure that a good random address is used.
164 1.4.4. DNSProxy IPv6 client behavior
166 A new capability in recent Tor versions is the transparent DNS proxy.
167 This feature will need to return both A and AAAA resource records
168 when responding to client name resolution requests.
170 The transparent DNS proxy should also support reverse lookups for
171 IPv6 addresses. It is suggested that any such requests to the
172 deprecated IP6.INT domain should be translated to IP6.ARPA instead.
173 This translation is not likely to be used and is of low priority.
175 It would be nice to support DNS over IPv6 transport as well, however,
176 this is not likely to be used and is of low priority.
178 1.4.5. TransPort IPv6 client behavior
180 Tor also provides transparent TCP proxy support via the Trans*
181 directives in the configuration. The TransListenAddress directive
182 should accept an IPv6 address in addition to IPv4 so that IPv6 TCP
183 connections can be transparently proxied.
185 1.5. Additional changes
187 The RedirectExit option should be deprecated rather than extending
188 this feature to IPv6.
193 2.1. Tor specification
195 In '6.2. Opening streams and transferring data' the following should
196 be changed to indicate IPv6 exit capability:
198 "No version of Tor currently generates the IPv6 format."
200 In '6.4. Remote hostname lookup' the following should be updated to
201 reflect use of ip6.arpa in addition to in-addr.arpa.
203 "For a reverse lookup, the OP sends a RELAY_RESOLVE cell containing an
204 in-addr.arpa address."
206 In 'A.1. Differences between spec and implementation' the following
207 should be updated to indicate IPv6 exit capability:
209 "The current codebase has no IPv6 support at all."
211 [NOTE: the EXITPOLICY end-cell reason says that it can hold an ipv4 or an
212 ipv6 address, but doesn't say how. We may want a separate EXITPOLICY2
213 type that can hold an ipv6 address, since the way we encode ipv6
214 addresses elsewhere ("0.0.0.0 indicates that the next 16 bytes are ipv6")
215 is a bit dumb. -nickm]
216 [Actually, the length field lets us distinguish EXITPOLICY. -nickm]
218 2.2. Directory specification
220 In '2.1. Router descriptor format' a new set of directives is needed
221 for IPv6 exit policy. The existing accept/reject directives should
222 be clarified to indicate IPv4 or wildcard address relevance. The new
223 IPv6 directives will be in the form of:
225 "accept6" exitpattern NL
226 "reject6" exitpattern NL
228 The section describing accept6/reject6 should explain that the
229 presence of accept6 or reject6 exit policies in a router descriptor
230 signals the ability of that router to exit IPv6 traffic (according to
233 The "[::]/0" notation is used to represent "all IPv6 addresses".
234 "[::0]/0" may also be used for this representation.
236 If a user specifies a 'reject6 [::]/0:*' policy in the Tor
237 configuration this will be interpreted as forcing no IPv6 exit
238 support and no accept6/reject6 policies will be included in the
239 published descriptor. This will prevent IPv6 exit if the router host
240 has a global unicast IPv6 address present.
242 It is important to note that a wildcard address in an accept or
243 reject policy applies to both IPv4 and IPv6 addresses.
245 2.3. Control specification
247 In '3.8. MAPADDRESS' the potential to have to addresses for a given
248 name should be explained. The method for generating unique local
249 addresses for IPv6 mappings needs explanation as described above.
251 When IPv6 addresses are used in this document they should include the
252 brackets for consistency. For example, the null IPv6 address should
253 be written as "[::0]" and not "::0". The control commands will
254 expect the same syntax as well.
256 In '3.9. GETINFO' the "address" command should return both public
257 IPv4 and IPv6 addresses if present. These addresses should be
261 2.4. Tor SOCKS extensions
263 In '2. Name lookup' a description of IPv6 address resolution is
264 needed for SOCKSv5 as described above. IPv6 addresses should be
265 supported in both the RESOLVE and RESOLVE_PTR extensions.
267 A new section describing the ability to accept SOCKSv5 clients on a
268 local IPv6 address to indicate a preference for IPv6 transport as
269 described above is also needed. The behavior of Tor SOCKSv5 proxy
270 with an IPv6 preference should be explained, for example, preferring
271 IPv6 transport to a named host with both IPv4 and IPv6 addresses
272 available (A and AAAA records).
275 3. Questions and concerns
279 A6 is explicitly avoided in this document. There are potential
280 reasons for implementing this, however, the inherent complexity of
281 the protocol and resolvers make this unappealing. Is there a
282 compelling reason to consider A6 as part of IPv6 exit support?
284 [IMO not till anybody needs it. -nickm]
286 3.2. IPv4 and IPv6 preference
288 The design above tries to infer a preference for IPv4 or IPv6
289 transport based on client interactions with Tor. It might be useful
290 to provide more explicit control over this preference. For example,
291 an IPv4 SOCKSv5 client may want to use IPv6 transport to named hosts
292 in CONNECT requests while the current implementation would assume an
293 IPv4 preference. Should more explicit control be available, through
294 either configuration directives or control commands?
296 Many applications support a inet6-only or prefer-family type option
297 that provides the user manual control over address preference. This
298 could be provided as a Tor configuration option.
300 An explicit preference is still possible by resolving names and then
301 CONNECTing to an IPv4 or IPv6 address as desired, however, not all
302 client applications may have this option available.
304 3.3. Support for IPv6 only transparent proxy clients
306 It may be useful to support IPv6 only transparent proxy clients using
307 IPv4 mapped IPv6 like addresses. This would require transparent DNS
308 proxy using IPv6 transport and the ability to map A record responses
309 into IPv4 mapped IPv6 like addresses in the manner described in the
310 "NAT-PT" RFC for a traditional Basic-NAT-PT with DNS-ALG. The
311 transparent TCP proxy would thus need to detect these mapped addresses
312 and connect to the desired IPv4 host.
314 The IPv6 prefix used for this purpose must not be the actual IPv4
315 mapped IPv6 address prefix, though the manner in which IPv4 addresses
316 are embedded in IPv6 addresses would be the same.
318 The lack of any IPv6 only hosts which would use this transparent proxy
319 method makes this a lot of work for very little gain. Is there a
320 compelling reason to support this NAT-PT like capability?
322 3.4. IPv6 DNS and older Tor routers
324 It is expected that many routers will continue to run with older
325 versions of Tor when the IPv6 exit capability is released. Clients
326 who wish to use IPv6 will need to route RELAY_RESOLVE requests to the
327 newer routers which will respond with both A and AAAA resource
328 records when possible.
330 One way to do this is to route RELAY_RESOLVE requests to routers with
331 IPv6 exit policies published, however, this would not utilize current
332 routers that can resolve IPv6 addresses even if they can't exit such
335 There was also concern expressed about the ability of existing clients
336 to cope with new RELAY_RESOLVE responses that contain IPv6 addresses.
337 If this breaks backward compatibility, a new request type may be
338 necessary, like RELAY_RESOLVE6, or some other mechanism of indicating
339 the ability to parse IPv6 responses when making the request.
341 3.5. IPv4 and IPv6 bindings in MAPADDRESS
343 It may be troublesome to try and support two distinct address mappings
344 for the same name in the existing MAPADDRESS implementation. If this
345 cannot be accommodated then the behavior should replace existing
346 mappings with the new address regardless of family. A warning when
347 this occurs would be useful to assist clients who encounter problems
348 when both an IPv4 and IPv6 application are using MAPADDRESS for the
349 same names concurrently, causing lost connections for one of them.
353 4.1. Sample IPv6 default exit policy
356 reject 169.254.0.0/16
358 reject 192.168.0.0/16
390 # accept6 [2000::]/3:* is implied
392 4.2. Additional resources
394 'DNS Extensions to Support IP Version 6'
395 http://www.ietf.org/rfc/rfc3596.txt
397 'DNS Extensions to Support IPv6 Address Aggregation and Renumbering'
398 http://www.ietf.org/rfc/rfc2874.txt
400 'SOCKS Protocol Version 5'
401 http://www.ietf.org/rfc/rfc1928.txt
403 'Unique Local IPv6 Unicast Addresses'
404 http://www.ietf.org/rfc/rfc4193.txt
406 'INTERNET PROTOCOL VERSION 6 ADDRESS SPACE'
407 http://www.iana.org/assignments/ipv6-address-space
409 'Network Address Translation - Protocol Translation (NAT-PT)'
410 http://www.ietf.org/rfc/rfc2766.txt