[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: IPv6 exit proposal
i've attached a patch for some clarifications to the proposal. i've
also answered some questions inline below...
On 7/10/07, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
...
Alternatively, we could just apply IPv4 exit policies to IPv4-mapped
IPv6 addresses. Would that be cleaner?
all of the IPv4 mapped IPv6 should occur at the client side, not exit,
so this shouldn't be necessary.
also, this would only be needed for the transparent proxy of IPv6 only
clients, as the usual IPv4 mapped IPv6 applies to listening sockets,
making it internal to Tor itself, and not exposed to either clients or
exits.
> All routers which perform DNS resolution on behalf of clients
> (RELAY_RESOLVE) should perform and respond with both A and AAAA
> resources.
Hm. We need some way to do this inside the current relay_resolve
format without confusing existing clients.
i added a paragraph to "3.4. IPv6 DNS and older Tor routers" with this
concern. hopefully this can be done without confusing existing
clients, perhaps by always returning the IPv4 address(es) first,
followed by IPv6 in the response.
i'd like to avoid a RELAY_RESOLVE6 kind of hack like that used for
exit policies.
best regards,
--- 117-ipv6-exits.txt 2007-07-11 19:57:46.814722640 -0700
+++ mod-117-ipv6-exits.txt 2007-07-18 15:12:35.836881296 -0700
@@ -44,12 +44,12 @@ Contents
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.
+ global unicast IPv6 address 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 IPv6
+ address is available Tor should generate a warning and not publish the
+ IPv6 policies 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
@@ -159,7 +159,7 @@ Contents
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.
+ this is not likely to be used and is of low priority. Refer to
1.4.5. TransPort IPv6 client behavior
@@ -270,21 +270,29 @@ Contents
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?
+ Many applications support a inet6-only or prefer-family type option
+ that provides the user manual control over address preference. This
+ could be provided as a Tor configuration option.
+
+ An explicit preference is still possible 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 transparent proxy clients
+
+ It may be useful to support IPv6 only transparent proxy clients using
+ IPv4 mapped IPv6 like addresses. This would require transparent DNS
+ proxy using IPv6 transport and the ability to map A record responses
+ into IPv4 mapped IPv6 like addresses in the manner described in the
+ "NAT-PT" RFC. The transparent TCP proxy would thus need to detect
+ these mapped addresses and connect to the desired IPv4 host. The IPv6
+ prefix used for this purpose must not be the actual IPv4 mapped IPv6
+ address prefix, though the manner in which IPv4 addresses are embedded
+ in IPv6 would be the same.
+
+ The lack of any IPv6 only hosts which would use this transparent proxy
+ method makes this a lot of work for very little gain. Is there a
+ compelling reason to support this NAT-PT like capability?
3.4. IPv6 DNS and older Tor routers
@@ -299,6 +307,20 @@ Contents
routers that can resolve IPv6 addresses even if they can't exit such
traffic.
+ There was also concern expressed about the ability of existing clients
+ to cope with new RELAY_RESOLVE responses that contain IPv6 addresses.
+ If this breaks backward compatibility, a new request type will be
+ necessary, like RELAY_RESOLVE6.
+
+3.5. IPv4 and IPv6 bindings in MAPADDRESS
+
+ It may be troublesome to try and support two distinct address mappings
+ for the same name in the existing MAPADDRESS implementation. If this
+ cannot be accommodated than the behavior should replace existing
+ mappings with the new address regardless of family. A warning when
+ this occurs would be useful to assist clients who encounter problems
+ when both an IPv4 and IPv6 application are using MAPADDRESS for the
+ same names concurrently, causing lost connections for one of them.
4. Addendum
@@ -358,3 +380,5 @@ Contents
'INTERNET PROTOCOL VERSION 6 ADDRESS SPACE'
http://www.iana.org/assignments/ipv6-address-space
+ 'Network Address Translation - Protocol Translation (NAT-PT)'
+ http://www.ietf.org/rfc/rfc2766.txt