mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13: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
|
||||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user