mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-13 06:33:44 +01:00
r13674@catbus: nickm | 2007-07-10 13:27:30 -0400
Re-wrap proposal 117 so it fits in 80 columns. svn:r10784
This commit is contained in:
Nick Mathewson
parent
81083cf0ce
commit
4325fc5e83
@ -3,281 +3,301 @@ Proposal : IPv6 exit
|
|||||||
Overview
|
Overview
|
||||||
|
|
||||||
Extend Tor for TCP exit via IPv6 transport and DNS resolution of IPv6
|
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,
|
addresses. This proposal does not imply any IPv6 support for OR
|
||||||
only exit and name resolution.
|
traffic, only exit and name resolution.
|
||||||
|
|
||||||
|
|
||||||
Contents
|
Contents
|
||||||
|
|
||||||
0. Motivation
|
0. Motivation
|
||||||
|
|
||||||
As the IPv4 address space becomes more scarce there is increasing effort to
|
As the IPv4 address space becomes more scarce there is increasing
|
||||||
provide Internet services via the IPv6 protocol. Many hosts are available
|
effort to provide Internet services via the IPv6 protocol. Many
|
||||||
at IPv6 endpoints which are currently inaccessible for Tor users.
|
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
|
Extending Tor to support IPv6 exit streams and IPv6 DNS name
|
||||||
allow users of the Tor network to access these hosts. This capability would
|
resolution will allow users of the Tor network to access these hosts.
|
||||||
be present for those who do not currently have IPv6 access, thus increasing
|
This capability would be present for those who do not currently have
|
||||||
the utility of Tor and furthering adoption of IPv6.
|
IPv6 access, thus increasing the utility of Tor and furthering
|
||||||
|
adoption of IPv6.
|
||||||
|
|
||||||
|
|
||||||
1. Design
|
1. Design
|
||||||
|
|
||||||
1.1. General design overview
|
1.1. General design overview
|
||||||
|
|
||||||
There are three main components to this proposal. The first is a method for
|
There are three main components to this proposal. The first is a
|
||||||
routers to advertise their ability to exit IPv6 traffic. The second is the
|
method for routers to advertise their ability to exit IPv6 traffic.
|
||||||
manner in which routers resolve names to IPv6 addresses. Last but not least
|
The second is the manner in which routers resolve names to IPv6
|
||||||
is the method in which clients communicate with Tor to resolve and connect
|
addresses. Last but not least is the method in which clients
|
||||||
to IPv6 endpoints anonymously.
|
communicate with Tor to resolve and connect to IPv6 endpoints
|
||||||
|
anonymously.
|
||||||
|
|
||||||
1.2. Router IPv6 exit support
|
1.2. Router IPv6 exit support
|
||||||
|
|
||||||
In order to specify exit policies and IPv6 capability new directives in the
|
In order to specify exit policies and IPv6 capability new directives
|
||||||
Tor configuration will be needed. If a router advertises IPv6 exit policies
|
in the Tor configuration will be needed. If a router advertises IPv6
|
||||||
in its descriptor this will signal the ability to provide IPv6 exit. There
|
exit policies in its descriptor this will signal the ability to
|
||||||
are a number of additional default deny rules associated with this new
|
provide IPv6 exit. There are a number of additional default deny
|
||||||
address space which are detailed in the addendum.
|
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
|
When Tor is started on a host it should check for the presence of a
|
||||||
unicast address, [2000::]/3, and if present include the default IPv6 exit
|
global unicast address, [2000::]/3, and if present include the
|
||||||
policies and any user specified IPv6 exit policies.
|
default IPv6 exit policies and any user specified IPv6 exit policies.
|
||||||
|
|
||||||
If a user provides IPv6 exit policies but no global unicast address is
|
If a user provides IPv6 exit policies but no global unicast address
|
||||||
available Tor should generate a warning and not publish the IPv6 policy in
|
is available Tor should generate a warning and not publish the IPv6
|
||||||
the router descriptor.
|
policy in the router descriptor.
|
||||||
|
|
||||||
It should be noted that IPv4 mapped IPv6 addresses are not valid exit
|
It should be noted that IPv4 mapped IPv6 addresses are not valid exit
|
||||||
destinations. This mechanism is mainly used to interoperate with both IPv4
|
destinations. This mechanism is mainly used to interoperate with
|
||||||
and IPv6 clients on the same socket. Any attempts to use an IPv4 mapped
|
both IPv4 and IPv6 clients on the same socket. Any attempts to use
|
||||||
IPv6 address, perhaps to circumvent exit policy for IPv4, must be refused.
|
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)
|
1.3. DNS name resolution of IPv6 addresses (AAAA records)
|
||||||
|
|
||||||
In addition to exit support for IPv6 TCP connections, a method to resolve
|
In addition to exit support for IPv6 TCP connections, a method to
|
||||||
domain names to their respective IPv6 addresses is also needed. This is
|
resolve domain names to their respective IPv6 addresses is also
|
||||||
accomplished in the existing DNS system via AAAA records. Routers will
|
needed. This is accomplished in the existing DNS system via AAAA
|
||||||
perform both A and AAAA requests when resolving a name so that the client can
|
records. Routers will perform both A and AAAA requests when
|
||||||
utilize an IPv6 endpoint when available or preferred.
|
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
|
To avoid potential problems with caching DNS servers that behave
|
||||||
NXDOMAIN responses to AAAA requests should be ignored if a successful
|
poorly all NXDOMAIN responses to AAAA requests should be ignored if a
|
||||||
response is received for an A request. This implies that both AAAA and A
|
successful response is received for an A request. This implies that
|
||||||
requests will always be performed for each name resolution.
|
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
|
For reverse lookups on IPv6 addresses, like that used for
|
||||||
will perform the necessary PTR requests via IP6.ARPA.
|
RESOLVE_PTR, Tor will perform the necessary PTR requests via
|
||||||
|
IP6.ARPA.
|
||||||
|
|
||||||
All routers which perform DNS resolution on behalf of clients (RELAY_RESOLVE)
|
All routers which perform DNS resolution on behalf of clients
|
||||||
should perform and respond with both A and AAAA resources.
|
(RELAY_RESOLVE) should perform and respond with both A and AAAA
|
||||||
|
resources.
|
||||||
|
|
||||||
1.4. Client interaction with IPv6 exit capability
|
1.4. Client interaction with IPv6 exit capability
|
||||||
|
|
||||||
1.4.1. Usability goals
|
1.4.1. Usability goals
|
||||||
|
|
||||||
There are a number of behaviors which Tor can provide when interacting with
|
There are a number of behaviors which Tor can provide when
|
||||||
clients that will improve the usability of IPv6 exit capability. These
|
interacting with clients that will improve the usability of IPv6 exit
|
||||||
behaviors are designed to make it simple for clients to express a preference
|
capability. These behaviors are designed to make it simple for
|
||||||
for IPv6 transport and utilize IPv6 host services.
|
clients to express a preference for IPv6 transport and utilize IPv6
|
||||||
|
host services.
|
||||||
|
|
||||||
1.4.2. SOCKSv5 IPv6 client behavior
|
1.4.2. SOCKSv5 IPv6 client behavior
|
||||||
|
|
||||||
The SOCKS version 5 protocol supports IPv6 connections. When using SOCKSv5
|
The SOCKS version 5 protocol supports IPv6 connections. When using
|
||||||
with hostnames it is difficult to determine if a client wishes to use an IPv4
|
SOCKSv5 with hostnames it is difficult to determine if a client
|
||||||
or IPv6 address to connect to the desired host if it resolves to both address
|
wishes to use an IPv4 or IPv6 address to connect to the desired host
|
||||||
types.
|
if it resolves to both address types.
|
||||||
|
|
||||||
In order to make this more intuitive the SOCKSv5 protocol can be supported on
|
In order to make this more intuitive the SOCKSv5 protocol can be
|
||||||
a local IPv6 endpoint, [::1] port 9050 for example. When a client requests
|
supported on a local IPv6 endpoint, [::1] port 9050 for example.
|
||||||
a connection to the desired host via an IPv6 SOCKS connection Tor will prefer
|
When a client requests a connection to the desired host via an IPv6
|
||||||
IPv6 addresses when resolving the host name and connecting to the host.
|
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
|
Likewise, RESOLVE and RESOLVE_PTR requests from an IPv6 SOCKS
|
||||||
return IPv6 addresses when available, and fall back to IPv4 addresses if not.
|
connection will return IPv6 addresses when available, and fall back
|
||||||
|
to IPv4 addresses if not.
|
||||||
|
|
||||||
1.4.3. MAPADDRESS behavior
|
1.4.3. MAPADDRESS behavior
|
||||||
|
|
||||||
The MAPADDRESS capability supports clients that may not be able to use the
|
The MAPADDRESS capability supports clients that may not be able to
|
||||||
SOCKSv4a or SOCKSv5 hostname support to resolve names via Tor. This ability
|
use the SOCKSv4a or SOCKSv5 hostname support to resolve names via
|
||||||
should be extended to IPv6 addresses in SOCKSv5 as well.
|
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,
|
When a client requests an address mapping from the wildcard IPv6
|
||||||
[::0], the server will respond with a unique local IPv6 address on success.
|
address, [::0], the server will respond with a unique local IPv6
|
||||||
It is important to note that there may be two mappings for the same name
|
address on success. It is important to note that there may be two
|
||||||
if both an IPv4 and IPv6 address are associated with the host. In this case
|
mappings for the same name if both an IPv4 and IPv6 address are
|
||||||
a CONNECT to a mapped IPv6 address should prefer IPv6 for the connection to
|
associated with the host. In this case a CONNECT to a mapped IPv6
|
||||||
the host, if available, while CONNECT to a mapped IPv4 address will prefer
|
address should prefer IPv6 for the connection to the host, if
|
||||||
IPv4.
|
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
|
It should be noted that IPv6 does not provide the concept of a host
|
||||||
subnet, like 127.0.0.0/8 in IPv4. For this reason integration of Tor with
|
local subnet, like 127.0.0.0/8 in IPv4. For this reason integration
|
||||||
IPv6 clients should consider a firewall or filter rule to drop unique
|
of Tor with IPv6 clients should consider a firewall or filter rule to
|
||||||
local addresses to or from the network when possible. These packets should
|
drop unique local addresses to or from the network when possible.
|
||||||
not be routed, however, keeping them off the subnet entirely is worthwhile.
|
These packets should not be routed, however, keeping them off the
|
||||||
|
subnet entirely is worthwhile.
|
||||||
|
|
||||||
1.4.3.1. Generating unique local IPv6 addresses
|
1.4.3.1. Generating unique local IPv6 addresses
|
||||||
|
|
||||||
The usual manner of generating a unique local IPv6 address is to select a
|
The usual manner of generating a unique local IPv6 address is to
|
||||||
Global ID part randomly, along with a Subnet ID, and sharing this prefix
|
select a Global ID part randomly, along with a Subnet ID, and sharing
|
||||||
among the communicating parties who each have their own distinct Interface
|
this prefix among the communicating parties who each have their own
|
||||||
ID. In this style a given Tor instance might select a random Global and
|
distinct Interface ID. In this style a given Tor instance might
|
||||||
Subnet ID and provide MAPADDRESS assignments with a random Interface ID as
|
select a random Global and Subnet ID and provide MAPADDRESS
|
||||||
needed. This has the potential to associate unique Global/Subnet identifiers
|
assignments with a random Interface ID as needed. This has the
|
||||||
with a given Tor instance and may expose attacks against the anonymity of Tor
|
potential to associate unique Global/Subnet identifiers with a given
|
||||||
|
Tor instance and may expose attacks against the anonymity of Tor
|
||||||
users.
|
users.
|
||||||
|
|
||||||
Tor avoid this potential problem entirely MAPADDRESS must always generate the
|
Tor avoid this potential problem entirely MAPADDRESS must always
|
||||||
Global, Subnet, and Interface IDs randomly for each request. It is also
|
generate the Global, Subnet, and Interface IDs randomly for each
|
||||||
highly suggested that explicitly specifying an IPv6 source address instead of
|
request. It is also highly suggested that explicitly specifying an
|
||||||
the wildcard address not be supported to ensure that a good random address is
|
IPv6 source address instead of the wildcard address not be supported
|
||||||
used.
|
to ensure that a good random address is used.
|
||||||
|
|
||||||
1.4.4. DNSProxy IPv6 client behavior
|
1.4.4. DNSProxy IPv6 client behavior
|
||||||
|
|
||||||
A new capability in recent Tor versions is the transparent DNS proxy. This
|
A new capability in recent Tor versions is the transparent DNS proxy.
|
||||||
feature will need to return both A and AAAA resource records when responding
|
This feature will need to return both A and AAAA resource records
|
||||||
to client name resolution requests.
|
when responding to client name resolution requests.
|
||||||
|
|
||||||
The transparent DNS proxy should also support reverse lookups for IPv6
|
The transparent DNS proxy should also support reverse lookups for
|
||||||
addresses. It is suggested that any such requests to the deprecated IP6.INT
|
IPv6 addresses. It is suggested that any such requests to the
|
||||||
domain should be translated to IP6.ARPA instead. This translation is not
|
deprecated IP6.INT domain should be translated to IP6.ARPA instead.
|
||||||
likely to be used and is of low priority.
|
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
|
It would be nice to support DNS over IPv6 transport as well, however,
|
||||||
is not likely to be used and is of low priority.
|
this is not likely to be used and is of low priority.
|
||||||
|
|
||||||
1.4.5. TransPort IPv6 client behavior
|
1.4.5. TransPort IPv6 client behavior
|
||||||
|
|
||||||
Tor also provides transparent TCP proxy support via the Trans* directives in
|
Tor also provides transparent TCP proxy support via the Trans*
|
||||||
the configuration. The TransListenAddress directive should accept an IPv6
|
directives in the configuration. The TransListenAddress directive
|
||||||
address in addition to IPv4 so that IPv6 TCP connections can be transparently
|
should accept an IPv6 address in addition to IPv4 so that IPv6 TCP
|
||||||
proxied.
|
connections can be transparently proxied.
|
||||||
|
|
||||||
1.5. Additional changes
|
1.5. Additional changes
|
||||||
|
|
||||||
The RedirectExit option should be deprecated rather than extending this
|
The RedirectExit option should be deprecated rather than extending
|
||||||
feature to IPv6.
|
this feature to IPv6.
|
||||||
|
|
||||||
|
|
||||||
2. Spec changes
|
2. Spec changes
|
||||||
|
|
||||||
2.1. Tor specification
|
2.1. Tor specification
|
||||||
|
|
||||||
In '6.2. Opening streams and transferring data' the following should be
|
In '6.2. Opening streams and transferring data' the following should
|
||||||
changed to indicate IPv6 exit capability:
|
be changed to indicate IPv6 exit capability:
|
||||||
|
|
||||||
"No version of Tor currently generates the IPv6 format."
|
"No version of Tor currently generates the IPv6 format."
|
||||||
|
|
||||||
In '6.4. Remote hostname lookup' the following should be updated to reflect
|
In '6.4. Remote hostname lookup' the following should be updated to
|
||||||
use of ip6.arpa in addition to in-addr.arpa.
|
reflect use of ip6.arpa in addition to in-addr.arpa.
|
||||||
|
|
||||||
"For a reverse lookup, the OP sends a RELAY_RESOLVE cell containing an
|
"For a reverse lookup, the OP sends a RELAY_RESOLVE cell containing an
|
||||||
in-addr.arpa address."
|
in-addr.arpa address."
|
||||||
|
|
||||||
In 'A.1. Differences between spec and implementation' the following should
|
In 'A.1. Differences between spec and implementation' the following
|
||||||
be updated to indicate IPv6 exit capability:
|
should be updated to indicate IPv6 exit capability:
|
||||||
|
|
||||||
"The current codebase has no IPv6 support at all."
|
"The current codebase has no IPv6 support at all."
|
||||||
|
|
||||||
2.2. Directory specification
|
2.2. Directory specification
|
||||||
|
|
||||||
In '2.1. Router descriptor format' a new set of directives is needed for
|
In '2.1. Router descriptor format' a new set of directives is needed
|
||||||
IPv6 exit policy. The existing accept/reject directives should be
|
for IPv6 exit policy. The existing accept/reject directives should
|
||||||
clarified to indicate IPv4 or wildcard address relevance. The new IPv6
|
be clarified to indicate IPv4 or wildcard address relevance. The new
|
||||||
directives will be in the form of:
|
IPv6 directives will be in the form of:
|
||||||
|
|
||||||
"accept6" exitpattern NL
|
"accept6" exitpattern NL
|
||||||
"reject6" exitpattern NL
|
"reject6" exitpattern NL
|
||||||
|
|
||||||
The section describing accept6/reject6 should explain that the presence
|
The section describing accept6/reject6 should explain that the
|
||||||
of accept6 or reject6 exit policies in a router descriptor signals the
|
presence of accept6 or reject6 exit policies in a router descriptor
|
||||||
ability of that router to exit IPv6 traffic (according to IPv6 exit
|
signals the ability of that router to exit IPv6 traffic (according to
|
||||||
policies).
|
IPv6 exit policies).
|
||||||
|
|
||||||
The "[::]/0" notation is used to represent "all IPv6 addresses". "[::0]/0"
|
The "[::]/0" notation is used to represent "all IPv6 addresses".
|
||||||
may also be used for this representation.
|
"[::0]/0" may also be used for this representation.
|
||||||
|
|
||||||
If a user specifies a 'reject6 [::]/0:*' policy in the Tor configuration this
|
If a user specifies a 'reject6 [::]/0:*' policy in the Tor
|
||||||
will be interpreted as forcing no IPv6 exit support and no accept6/reject6
|
configuration this will be interpreted as forcing no IPv6 exit
|
||||||
policies will be included in the published descriptor. This will prevent
|
support and no accept6/reject6 policies will be included in the
|
||||||
IPv6 exit if the router host has a global unicast IPv6 address present.
|
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
|
It is important to note that a wildcard address in an accept or
|
||||||
applies to both IPv4 and IPv6 addresses.
|
reject policy applies to both IPv4 and IPv6 addresses.
|
||||||
|
|
||||||
2.3. Control specification
|
2.3. Control specification
|
||||||
|
|
||||||
In '3.8. MAPADDRESS' the potential to have to addresses for a given name
|
In '3.8. MAPADDRESS' the potential to have to addresses for a given
|
||||||
should be explained. The method for generating unique local addresses
|
name should be explained. The method for generating unique local
|
||||||
for IPv6 mappings needs explanation as described above.
|
addresses for IPv6 mappings needs explanation as described above.
|
||||||
|
|
||||||
When IPv6 addresses are used in this document they should include the
|
When IPv6 addresses are used in this document they should include the
|
||||||
brackets for consistency. For example, the null IPv6 address should be
|
brackets for consistency. For example, the null IPv6 address should
|
||||||
written as "[::0]" and not "::0". The control commands will expect the
|
be written as "[::0]" and not "::0". The control commands will
|
||||||
same syntax as well.
|
expect the same syntax as well.
|
||||||
|
|
||||||
In '3.9. GETINFO' the "address" command should return both public IPv4 and
|
In '3.9. GETINFO' the "address" command should return both public
|
||||||
IPv6 addresses if present. These addresses should be separated via \r\n.
|
IPv4 and IPv6 addresses if present. These addresses should be
|
||||||
|
separated via \r\n.
|
||||||
|
|
||||||
|
|
||||||
2.4. Tor SOCKS extensions
|
2.4. Tor SOCKS extensions
|
||||||
|
|
||||||
In '2. Name lookup' a description of IPv6 address resolution is needed for
|
In '2. Name lookup' a description of IPv6 address resolution is
|
||||||
SOCKSv5 as described above. IPv6 addresses should be supported in both the
|
needed for SOCKSv5 as described above. IPv6 addresses should be
|
||||||
RESOLVE and RESOLVE_PTR extensions.
|
supported in both the RESOLVE and RESOLVE_PTR extensions.
|
||||||
|
|
||||||
A new section describing the ability to accept SOCKSv5 clients on a local
|
A new section describing the ability to accept SOCKSv5 clients on a
|
||||||
IPv6 address to indicate a preference for IPv6 transport as described above
|
local IPv6 address to indicate a preference for IPv6 transport as
|
||||||
is also needed. The behavior of Tor SOCKSv5 proxy with an IPv6 preference
|
described above is also needed. The behavior of Tor SOCKSv5 proxy
|
||||||
should be explained, for example, preferring IPv6 transport to a named host
|
with an IPv6 preference should be explained, for example, preferring
|
||||||
with both IPv4 and IPv6 addresses available (A and AAAA records).
|
IPv6 transport to a named host with both IPv4 and IPv6 addresses
|
||||||
|
available (A and AAAA records).
|
||||||
|
|
||||||
|
|
||||||
3. Questions and concerns
|
3. Questions and concerns
|
||||||
|
|
||||||
3.1. DNS A6 records
|
3.1. DNS A6 records
|
||||||
|
|
||||||
A6 is explicitly avoided in this document. There are potential reasons for
|
A6 is explicitly avoided in this document. There are potential
|
||||||
implementing this, however, the inherent complexity of the protocol and
|
reasons for implementing this, however, the inherent complexity of
|
||||||
resolvers make this unappealing. Is there a compelling reason to consider
|
the protocol and resolvers make this unappealing. Is there a
|
||||||
A6 as part of IPv6 exit support?
|
compelling reason to consider A6 as part of IPv6 exit support?
|
||||||
|
|
||||||
3.2. IPv4 and IPv6 preference
|
3.2. IPv4 and IPv6 preference
|
||||||
|
|
||||||
The design above tries to infer a preference for IPv4 or IPv6 transport
|
The design above tries to infer a preference for IPv4 or IPv6
|
||||||
based on client interactions with Tor. It might be useful to provide
|
transport based on client interactions with Tor. It might be useful
|
||||||
more explicit control over this preference. For example, an IPv4 SOCKSv5
|
to provide more explicit control over this preference. For example,
|
||||||
client may want to use IPv6 transport to named hosts in CONNECT requests
|
an IPv4 SOCKSv5 client may want to use IPv6 transport to named hosts
|
||||||
while the current implementation would assume an IPv4 preference. Should
|
in CONNECT requests while the current implementation would assume an
|
||||||
more explicit control be available, through either configuration directives
|
IPv4 preference. Should more explicit control be available, through
|
||||||
or control commands?
|
either configuration directives or control commands?
|
||||||
|
|
||||||
This can be worked around by resolving names and then CONNECTing to an IPv4
|
This can be worked around by resolving names and then CONNECTing to
|
||||||
or IPv6 address as desired, however, not all client applications may have
|
an IPv4 or IPv6 address as desired, however, not all client
|
||||||
this option available.
|
applications may have this option available.
|
||||||
|
|
||||||
3.3. Support for IPv6 only clients
|
3.3. Support for IPv6 only clients
|
||||||
|
|
||||||
It may be useful to support IPv6 only clients using IPv4 mapped IPv6
|
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
|
transport and the ability to map A record responses into IPv4 mapped
|
||||||
IPv6 addresses. The transparent TCP proxy would thus need to detect these
|
IPv6 addresses. The transparent TCP proxy would thus need to detect
|
||||||
mapped addresses and connect to the desired IPv4 host.
|
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
|
The relative lack of any IPv6 only hosts or applications makes this a
|
||||||
work for very little gain. Is there a compelling reason to support this
|
lot of work for very little gain. Is there a compelling reason to
|
||||||
capability?
|
support this capability?
|
||||||
|
|
||||||
3.4. IPv6 DNS and older Tor routers
|
3.4. IPv6 DNS and older Tor routers
|
||||||
|
|
||||||
It is expected that many routers will continue to run with older versions of
|
It is expected that many routers will continue to run with older
|
||||||
Tor when the IPv6 exit capability is released. Clients who wish to use IPv6
|
versions of Tor when the IPv6 exit capability is released. Clients
|
||||||
will need to route RELAY_RESOLVE requests to the newer routers which will
|
who wish to use IPv6 will need to route RELAY_RESOLVE requests to the
|
||||||
respond with both A and AAAA resource records when possible.
|
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
|
One way to do this is to route RELAY_RESOLVE requests to routers with
|
||||||
exit policies published, however, this would not utilize current routers
|
IPv6 exit policies published, however, this would not utilize current
|
||||||
that can resolve IPv6 addresses even if they can't exit such traffic.
|
routers that can resolve IPv6 addresses even if they can't exit such
|
||||||
|
traffic.
|
||||||
|
|
||||||
|
|
||||||
4. Addendum
|
4. Addendum
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user