r13674@catbus: nickm | 2007-07-10 13:27:30 -0400

 Re-wrap proposal 117 so it fits in 80 columns.


svn:r10784

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