INTERNET DRAFT                                              C. Huitema
<draft-ietf-v6ops-unmaneval-00.txt>
<draft-ietf-v6ops-unmaneval-01.txt>                          Microsoft
June 3, 2003
February 4, 2004                                            R. Austein
Expires December 3, 2003 August 4, 2004                            Bourgeois Dilettante
                                                           S. Satapati
                                                   Cisco Systems, Inc.
                                                    Ronald
                                                        R. van der Pol
                                                            NLnet Labs

Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   In a companion paper we defined the "unmanaged networks" scope, networks", which
   typically corresponds correspond to home networks or small office networks, and
   the requirements for IPv6 transition mechanism mechanisms in that
   scope. various scenarios of
   transition to IPv6. We start from this analysis and evaluate here
   the suitability of mechanisms defined in the NGTRANS working group. that have already been specified,
   proposed or deployed.

1	Introduction

   This document analyses the issues involved in the transition from
   IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the
   "unmanaged networks"
   scope, networks", which typically correspond to home networks or
   small office networks, and the requirements for IPv6 transition mechanism in that
   scope. We start from this analysis and evaluate here the suitability
   of
   mechanisms defined in the NGTRANS working group. various scenarios of transition to IPv6.

   The requirements for unmanaged networks are expressed by analyzing
   four classes of application: local, client, peer to peer, and
   servers, and considering four cases of deployment. These are:

Huitema et al.                                               [Page  1]
   A) a gateway which does not provide IPv6 at all;

Huitema et al.                                               [Page  1]
   B) a dual-stack gateway connected to a dual stack dual-stack ISP;
   C) a dual stack dual-stack gateway connected to an IPV4-only IPv4-only ISP; and
   D) a gateway connected to an IPv6-only ISP.

   This document analyses the issues involved in the transition from
   IPv4 to IPv6. One of the most important issues is that of naming and
   addressing.

   During the transition phase from IPv4 to IPv6 there will be IPv4 IPv4-
   only, dual stack dual-stack or IPv6 only IPv6-only nodes. In this document, we make the
   hypothesis that the IPv6 only IPv6-only nodes do not need to communicate with
   IPv4 only
   IPv4-only nodes; devices that want to communicate with both IPv4 and
   IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. i.e., be
   dual stack.
   dual-stack.

   The issues involved are described in the next chapters. sections. This
   analysis outlines two types of requirements: connectivity
   requirements, i.e. i.e., how to ensure that nodes can exchange IP
   packets, and naming requirements, i.e. i.e., how to ensure that nodes can
   resolve each-other's names.

2	Meeting case A The connectivity requirements

   In case A, isolated hosts located behind a NAT need to acquire some
   form of connectivity. In this section, we first evaluate how
   mechanisms already defined or being worked on in the IETF meet this
   requirement. often
   require tunneling solutions. We then consider devote the "remaining holes" and recommend
   specific developments.

2.1 first section of this
   memo to an evaluation of various tunneling solutions.

2	Evaluation of connectivity mechanisms Tunneling Solutions

   In the case A, A and case C scenarios described in [UNMANREQ], the
   unmanaged network cannot obtain IPv6 capable hosts seek service, at least natively,
   from its ISP. In these cases, the IPv6 connectivity in order service will have to
   participate be
   provided through some form of tunnel. There have been multiple
   proposals on different ways to applications in the global tunnel IPv6 Internet. The
   connectivity requirement through an IPv4 service.
   We believe that these proposals can be met in categorized according to two ways: Teredo,
   important properties:

   *	Is the deployment automatic, or UDP
   tunnels. (We will not discuss here does it require explicit
   configuration or service provisioning?

   *	Does the case where there is no NAT;
   this will be considered as proposal allow for the traversal of a subset NAT [NAT-T]?

   These two questions divide the solution space into four broad
   classes. Each of case C.)

2.1.1	TEREDO

   TEREDO these classes has specific advantages and risks,
   which we will now develop.

2.1	Comparing automatic and configured solutions

   It is a mechanism designed to provide IPv6 connectivity to hosts
   behind NATs. Hosts use servers possible to find out broadly classify tunneling solutions as either
   "automatic" or "configured". In an automatic solution, a "mapped" IPv4 address
   and UDP port; they build host or a
   router builds an IPv6 address that includes the or an IPv6 prefix by combining a pre-
   defined prefix with some local attribute, such as local IPv4 address
   [6TO4] or the combination of their preferred server, and their own mapped IPv4 an address and mapped port. A mechanism a port number [Teredo].
   Another typical and very important characteristic of bubbles, relayed by the servers, an automatic
   solution is
   used for establishing contacts between Teredo nodes, they aim to work with a minimal amount of support or
   infrastructure for
   discovering the appropriate Teredo relay serving an IPv6 peer; the
   actual IPv6 packets are carried in UDP packets exchanged directly
   between the nodes, local or exchanged through the relay serving remote ISPs. In a configured
   solution, a host or a router identifies itself to a tunneling
   service to set up a "configured tunnel" with an IPv6
   peer.

2.1.2	Simple UDP tunnel explicitly defined

Huitema et al.                                               [Page  2]
   An alternative to TEREDO is to simply establish a tunnel to a
   "tunnel broker" outside the unmanaged network; in order to traverse
   the NAT, the IPv6 packets would be carried router".

   Configured tunnels have many advantages over UDP. This solution
   was described in a draft that has now expired, automatic tunnels. The
   client is explicitly identified and can obtain a stable IPv6
   address. The service provider is also mentioned
   as a well identified and can be
   held responsible for the quality of the service. It is possible alternative to
   route multicast packets over the bubble mechanism in the TEREDO
   specification.

2.1.3	Comparison of TEREDO and tunnel solution

   The TEREDO and tunnel solutions differ in terms of complexity and
   operation.

   A first difference established tunnel. There is a
   clear address delegation path, which enables easy support for
   reverse DNS lookups.

   Automatic tunnels generally cannot provide the cost same level of operating the server. TEREDO
   service. The IPv6 address is
   designed to minimize only as stable as the cost of operating underlying IPv4
   address, the server, which only
   processes small bubbles and never relays traffic; quality of service depends on the relays operated by third
   parties, there is typically no support for multicast, and there is
   often no easy way to support reverse DNS lookups (although some
   workarounds are probably possible). However, automatic tunnels have
   other hand, advantages. They are obviously easier to configure, since
   there is no need of an explicit relation with a tunnel server will relay all the packets going to service. They
   may also be in some case more efficient, as they allow for "path
   optimization".

2.1.1	Path optimization in automatic tunnels

   In automatic tunnels like [Teredo] and from [6to4], the
   Teredo host. This implies a very different amount bulk of traffic.

   To gauge the difference, we consider
   traffic between two nodes using the case of same technology is exchanged on
   a host engaging in
   Voice over IP: it will maintain its address reachable direct path between the endpoints, using the IPv4 services to
   which the endpoints already subscribe. By contrast, the configured
   tunnel servers carry all the time,
   and it will send a large amount of traffic whenever it is engaged in
   a conversation. According to classic figures collected exchanged by AT&T, the
   average duration of a conversation tunnel client.

   Path optimization is around 100 seconds, and not a
   business telephone big issue if the tunnel server is likely close
   to be engaged in a conversation about
   10% of the time, which implies starting a conversation client, on average
   every 1000 seconds. The average load sent by a tunnel the natural path between the client to and its peers.
   However, if the tunnel server is operated by a third party, this
   third party will be 10% of have to bear the average data rate cost of provisioning the client;
   assuming a 16kbps codec and 50 packets per second, bandwidth
   used by the data rate of client. The associated costs can be significant.

   These costs are largely inexistent when the client sums up to about 51 kbps, hence an average load on tunnels are configured
   by the
   tunnel server of 5 kbps. same ISP that provides the IPv4 service. The load sent by ISP can place
   the tunnel client end-points close to the
   tunnel server will be about one exchange of bubble per minute, to
   defend client, i.e., mostly on the address, plus one bubble exchange at
   direct path between the beginning of
   each session with a new peer; adding all headers, client and its peers.

2.1.2	Automatic tunnels and relays

   The economics arguments related to path optimization favor either
   configured tunnels provided by the bubble size is
   about 144 bytes, which results in about 20 bps local ISP or automatic tunneling
   regardless of traffic on the
   server. In short, the amount co-operation of traffic seen by the Teredo server is
   250 times less ISPs. However, automatic solutions
   require that relays be configured throughout the traffic seen by Internet. If a Teredo client.

   The host
   that obtained connectivity through an automatic tunnel approach is more expensive service wants
   to provide, because the tunnel
   server communicate with a "native" host, it will have need to carry use a much larger amount relay
   service, and someone will have to provide and pay for that service.
   We cannot escape economic considerations for the deployment of traffic. these
   relays.

Huitema et al.                                               [Page  3]
   It is
   unclear that a tunnel service can be provided as an almost free
   "supporting infrastructure", except perhaps if desirable to locate these relays close to the service was
   directly provided by "native host".
   During the same ISP that already provides IPv4
   connectivity to transition period, the unmanaged network.

   The two approaches native ISPS have much an interest in common: both need to parameterize a
   client with the name of
   providing a server and with sufficient credentials;
   the encapsulation is similar; both relay service for use the same encapsulation
   mechanism; and both by their native subscribers. Their
   subscribers will use router solicitations to obtain an
   address prefix. The main difference is enjoy better connectivity, i.e., will be happier.
   Providing the handling of bubbles service does not result in
   Teredo, which much extra bandwidth
   requirement: the packets are used to defend exchanged between the address local subscribers
   and to initiate
   sessions with peers. This is obviously more complex than sending the
   packet without any processing, but the complexity is only marginally

Huitema et al.                                               [Page  3]
   higher than the discovery of link layer addresses Internet; they are simply using neighbor
   discovery. In short, Teredo is more complex, but the complexity is a v6-v4 path instead of a
   v6-v6 path. (The native ISP do not overwhelming.

   An advantage have an incentive to provide
   relays for general use; they are expected to restrict access to
   these relays to their customers.)

   We should note however that different automatic tunneling techniques
   have different deployment conditions.

2.1.3	The risk of several parallel IPv6 Internets

   In an early deployment of the tunnel server approach over Teredo is that it
   will work regardless of service by Microsoft, the type and number of NAT between
   relays are provided by the
   client native (or 6to4) hosts themselves. The
   native or 6to4 hosts are de-facto multi-homed to native and the tunnel server. In contrast, Teredo,
   although they never publish a Teredo will not work
   across address in the DNS or
   otherwise. When a "symmetric" NAT, native host communicates with a Teredo host, the
   first packets are exchanged through the native interface and communication may be impossible
   between two relayed
   by the Teredo clients located behind server, while the same NAT.

   Another potential advantage subsequent packets are tunneled
   "end-to-end" over IPv4 and UDP. This enables deployment of Teredo
   without having to field an infrastructure of relays in the tunnel server approach is that it
   could provide clients with stable IPv6 addresses. network.

   This is only a
   potential advantage, since type of solution carries the server may prefer implicit risk of developing two
   parallel IPv6 Internets, one native and one using Teredo: in order
   to delegate
   addresses on communicate with a session per session basis, or may want Teredo-only host, a native IPv6 host has to operate in
   implement a stateless manner.

2.1.4	Recommendation Teredo appears interface. The Teredo implementations try to be
   mitigate this risk by always preferring native paths when available,
   but a good fit for providing IPv6 connectivity to true mitigation requires that native hosts behind NAT, in case A of IPv6 deployment. The service is
   designed for minimizing do not have to
   implement the cost of deploying transition technology. This requires cooperation from
   the server, which
   matches the requirement of minimizing IPv6 ISP, who will have to support the cost of relays. An IPv6 ISP that
   really wants to isolate its customers from the "supporting
   infrastructure" for peer-to-peer applications.

   There are however two situations in which Teredo technology can
   do that by providing native connectivity and a tunnel service makes
   sense: when the cost of bandwidth is Teredo relay. The
   ISP's customers will not a concern, need to implement their own relay.

   Communication between 6to4 networks and when the
   unmanaged network is located behind native networks uses a symmetric NAT. In these
   different structure. There are two
   cases, using a tunnel service is preferred over using Teredo. relays, one for each direction of
   communication. The most reasonable solution would be to develop native host sends its packets through the nearest
   6to4 router, i.e., the closest router advertising the 2002::/16
   prefix through the IPv6 routing tables; the 6to4 network sends its
   packet through a tunnel service
   specification 6to4 relay that is compatible with Teredo, so that a given host
   could be configured to use either Teredo or the tunnel service,
   depending on the server explicitly configured in or
   discovered through the dual stack host.

2.2	Security considerations in case A

   A characteristic of case A 6to4 anycast address 192.88.99.1
   [6To4ANYCAST]. The experience so far is that simple 6to4 routers are
   easy to deploy, but 6to4 relays are scarce. If there are too few
   relays, these relays will create a host located behind a NAT
   acquires global IPv6 connectivity, using either Teredo or bottleneck. The communications
   between 6to4 and native networks will be slower than the direct
   communications between 6to4 hosts. This will create an
   alternative tunneling mechanism. If no precaution is taken, incentive for
   native hosts to somehow "multi-home" to 6to4, de facto creating two
   parallel Internets, 6to4 and native. This risk will only be

Huitema et al.                                               [Page  4]
   mitigated if there is a risk sufficient deployment of exposing to 6to4 relays.

2.1.4	Lifespan of transition technologies

   A related issue is the global Internet some applications and
   services that only expected to serve local hosts, located behind lifespan of the
   NAT. Developers and administrators should make sure transition solutions. Since
   automatic tunneling technologies enable an automatic deployment,
   there is a risk that some hosts never migrate out of the global
   IPv6 connectivity transition.
   The risk is restricted to only those applications that are
   expressly designed arguably less for global Internet connectivity.

3	Meeting case B requirements

   In case B, we assume that explicit tunnels: the gateway and ISPS who provide
   the tunnels have an incentive to replace them with a native solution
   as soon as possible.

   Many implementations of automatic transition technologies
   incorporate an "implicit sunset" mechanism: the ISP are both dual
   stack. The hosts on will not
   configure a transition technology address if they have native
   connectivity; the local network may be IPv4 only, dual stack,
   or IPv6 only. address selection mechanisms will prefer native
   addresses when available. The main requirements are: prefix delegation, and name
   resolution. We also study transition technologies will stop
   being used eventually, when native connectivity has been deployed
   everywhere. However, the potential need "implicit sunset" mechanism does not
   provide any hard guarantee that transition will be complete at a
   certain date.

   Yet, the support of transition technologies has a cost for communication
   between IPv4 and the
   entire network: native IPv6 hosts, ISPS have to support relays in order to
   provide good performance and conclude that a dual stack approach

Huitema et al.                                               [Page  4]
   is preferable.

3.1	Prefix delegation

   The gateway must avoid the "parallel Internet" syndrome.
   These costs may be able to acquire acceptable during an IPv6 prefix, delegated by the
   ISP. initial deployment phase,
   but they can certainly not be supported for an indefinite period.
   The possible "implicit sunset" mechanisms are RA proxy and explicit prefix
   delegation.

3.1.1	RA proxy

   The implicit delegation mechanism assumes that the gateway is
   connected may not be sufficient to the ISP by guarantee
   a point-to-point link. Examples finite lifespan of such
   point to point links are various types the transition.

2.2	Cost and benefits of configured tunnels and
   serial links, for example using PPP. The principle of RA proxy is
   simple: NAT traversal

   During the gateway issues a "router solicitation" message on transition, some hosts will be located behind IPv4 NATs.
   In order to participate in the
   serial link, receives transition, these hosts will have to
   use a "router advertisement", learns tunneling mechanism designed to traverse NAT.

   We may ask whether NAT traversal should be a network
   prefix from the advertisement, generic property of any
   transition technology, or whether it makes sense to develop two
   types of technologies, some "NAT capable" and advertises the same prefix on some not.  An
   important question is also which kinds of NAT boxes one should be
   able to traverse.  One should probably also consider whether it is
   necessary to build an IPv6 specific NAT traversal mechanism, or
   whether it is possible to combine an existing IPv4 NAT traversal
   mechanism with some form of IPv6 in IPv4 tunneling. There are many
   IPv4 NAT traversal mechanisms; thus one may ask whether these need
   re-invention, especially when they are already complex.

   A related question is whether the
   unmanaged network.

   The RA proxy method results NAT traversal technology should
   use automatic tunnels or configured tunnels. We saw in the sharing previous
   section that one can argue both sides of this issue. In fact, there
   are already deployed automatic and configured solutions, so the same prefix over
   several links, a procedure
   reality is that we will probably see both.

Huitema et al.                                               [Page  5]

2.2.1	Cost of NAT traversal

   NAT traversal technologies generally involve encapsulating IPv6
   packets inside a transport protocol that is known as "multi-link subnet".
   This sharing has effects on neighbor discovery protocols, and
   possibly also on other protocols to traverse NAT,
   such as LLMNR that rely on "link
   local multicast". UDP or TCP. These effects need to be carefully studied.

3.1.2	Explicit prefix delegation

   Several networks have already started using an explicit prefix
   delegation mechanism using DHCPv6. In this mechanism, transport technologies require
   significantly more overhead than the gateway
   uses a DHCP request simple tunneling over IPv4 used
   in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on
   UDP require the frequent transmission of "keep alive" packets to obtain an adequate prefix from
   maintain a DHCP server
   managed by "mapping" in the Internet Service Provider. The DHCP request is
   expected to carry proper identification of NAT; solutions based on TCP may not
   require such mechanism, but they incur the gateway, risk of "head of queue
   blocking", which
   enables may translate in poor performances. Given the ISP
   difference in performance, it makes sense to implement prefix delegation policies.

   The basic use consider two types of DHCP is insecure. This may be a problem if
   transition technologies, some capable of traversing NAT and some
   aiming at the link
   between gateway best performance.

2.2.2	Types of NAT

   There are many kinds of NAT on the market. Different models
   implement different strategies for address and ISP port allocations, and
   also different types of timers. It is shared by multiple subscribers. In desirable to find solutions
   that
   case, some security procedure cover "almost all" models of NAT.

   A configured tunnel solution will have to be used, generally make fewer hypotheses on
   the behavior of the NAT than an automatic solution. The configured
   solutions only need to ensure at establish a
   minimum that DHCP requests connection between an internal
   node and replies are properly authenticated.

3.1.3	Recommendation a server; this communication pattern is supported by pretty
   much all NAT configurations. The RA proxy and DHCP methods appear to have different domains variability will come from the type
   of
   application. RA proxy is a simple method transport protocols that corresponds well to
   "informal sharing" the NAT support, especially when the NAT
   also implements "firewall" functions. Some models will allow
   establishment of a link, single "protocol 41" tunnel, while explicit delegation provides
   strong administrative control. Both methods require development:
   specify the interaction with neighbor discovery for RA proxy;
   provide security guidelines for explicit delegation. Proceeding with
   standardization some may
   prevent this type of at least one method, and transmission. Some models will allow UDP
   transmission, while other may only allow TCP, or possibly both, HTTP.

   The automatic solutions have to rely on a "lower common denominator"
   that is quite
   urgent.

3.2	Communication between IPv4-only and IPv6-capable nodes

Huitema et al.                                               [Page  5]
   During the transition phase from IPv4 likely to IPv6 there will be IPv4-
   only, dual stack and IPv6-only nodes. accepted by most models of NAT. In theory, there may be a need practice,
   this common denominator is UDP. UDP based NAT traversal is required
   by many applications, e.g., networked games or voice over IP. The
   experience shows that most recent "home routers" are designed to provide
   support these applications. In some interconnection services so that IPv4-only and IPv6-
   only hosts can communicate. However, as indicated in edge cases, the automatic
   solutions will require explicit configuration of a companion
   document, it port in the home
   router, using the so-called "DMZ" functions.

2.2.3	Reuse of existing mechanisms

   NAT traversal is hard to develop a translation service that does not a problem for IPv6 alone. Many IPv4
   applications have unwanted side effects on the efficiency developed solutions, or the security of
   communications. As kludges, to enable
   communication across a consequence, NAT.

   Virtual Private Networks are established by installing tunnels
   between VPN clients and VPN servers. These tunnels are designed
   today to carry IPv4, but in many cases could easily carry IPv6. For
   example, the authors recommend that, if a
   device has IETF standard, L2TP, includes a requirement to communicate with IPv4 only hosts, this
   device implements an IPv4 stack. The only devices PPP layer that should only
   have can

Huitema et al.                                               [Page  6]
   encapsulate IPv6 connectivity are those that as well as IPv4. Several NAT models are intended to only
   communicate with IPv6 hosts.

3.3	Resolution of names explicitly
   designed to IPv6 addresses

   There are three types of name resolution services that should be
   provided in case B: local IPv6 capable hosts must be able pass VPN traffic, and several VPN solutions have special
   provisions to obtain traverse NAT. When we study the IPv6 addresses establishment of correspondent hosts on the Internet; they
   should be able
   configured tunnels through NAT, it makes a lot of sense to publish their address if they want consider
   existing VPN solutions.

   [STUN] is a protocol designed to be accessed
   from facilitate the Internet; establishment of UDP
   associations through NAT, by letting nodes behind NAT discover their
   "external" address. The same function is required for automatic
   tunneling through NAT, and they should be able to obtain one could consider reusing the IPv6
   address STUN
   specification as part of other local IPv6 hosts. These three problems are
   described in an automatic tunneling solution. However,
   the next sections.

3.3.1	Provisioning automatic solutions also require a mechanism of bubbles to
   establish the address initial path through a NAT. This mechanism is not
   present in STUN. It is not clear that a combination of STUN and a DNS resolver

   In an unmanaged environment, IPv4 hosts usually obtain the address
   bubble mechanism would have a technical advantage over a solution
   specifically designed for automatic tunneling through NAT.

2.3	Development of transition mechanisms

   The previous sections make the local DNS resolver through DHCPv4; case for the DHCPv4 service is
   generally provided by development of four
   transition mechanism, covering the gateway. The gateway will also use DHCPv4
   to obtain following 4 configuration:

   -	Configured tunnel over IPv4 in the absence of NAT;
   -	Automatic tunnel over IPv4 in the address absence of NAT;
   -	Configured tunnel across a suitable resolver from the local Internet
   service provider.

   The DHCPv4 NAT;
   -	Automatic tunnel across a NAT.

   Teredo is an example of already designed solution will suffice in practice for the gateway and
   also for the dual stack hosts. There automatic
   tunnel across a NAT; 6to4 is evidence that even the
   simple DNS resolvers present in small gateways can relay arbitrary
   DNS request and serve arbitrary DNS records, including AAAA records.

   Just using DHCPv4 will not be an adequate example of solution for IPv6 only
   local hosts. Three solutions have been envisaged for these hosts:
   either using DHCPv6 to obtain automatic
   tunnel over IPv4 in the address absence of the DNS server; sending
   the DNS requests NAT.

   All solutions should be designed to a well known IPv6 address; meet generic requirements such
   as security, scalability, support for reverse name lookup, or sending the DNS
   requests to the IPv6 address of the gateway itself.

3.3.2	Publishing IPv6 addresses to the Internet

   IPv6 capable hosts simple
   management. In particular, automatic tunneling solutions may be willing to provide services accessible
   from the global Internet. They will thus need to document their
   address in a server that is publicly available. IPv4 hosts in
   unmanaged networks have a similar problem today, which they solve
   using one of three possible solutions:

   * Manual configuration of a stable address in
   be augmented with a special purpose reverse DNS server;
   * Dynamic configuration using the standard dynamic DNS protocol;
   * Dynamic configuration using lookup mechanism,
   while configured tunnel solutions would benefit from an ad hoc protocol.

Huitema et al.                                               [Page  6]
   Manual automatic
   service configuration of stable addresses is not satisfactory in an
   unmanaged IPv6 network: the prefix allocated mechanism.

3	Meeting case A requirements

   In case A, isolated hosts need to the gateway may acquire some form of connectivity.
   In this section, we first evaluate how mechanisms already defined or
   may not be stable, and
   being worked on in any case copying long binary addresses
   through a manual procedure is error prone.

   Dynamic configuration using the same type of ad hoc protocols that
   are common today is indeed possible, but the IETF should encourage meet this requirement. We then consider
   the use "remaining holes" and recommend specific developments.

3.1	Evaluation of standard solutions based on DDNS.

3.3.3	Resolving the connectivity mechanisms

   In case A, IPv6 addresses of local capable hosts

   There are two possible ways of resolving seek IPv6 connectivity in order to
   communicate with applications in the global IPv6 addresses of local
   hosts: one may Internet. The
   connectivity requirement can be met using either publish configured tunnels
   or automatic tunnels.

Huitema et al.                                               [Page  7]
   If the IPv6 addresses in host is located behind a DNS server for NAT, the local domain, or one may use a peer-to-peer address resolution
   protocol such as LLMNR.

   When a DNS server is used, this server could in theory tunneling technology should
   be located
   anywhere on designed to traverse NAT; tunneling technologies that do not
   support NAT traversal can obviously be used if the Internet. There host is however a very strong argument
   for using not
   located behind a local server, which will remain reachable even if NAT.

   When the
   network connectivity local ISP is down.

   The use of willing to provide a local server requires that IPv6 capable hosts discover
   this server, as explained configured tunnel
   solution, we should make it easy for the host in 3.3.1, and then that they case A to use a
   protocol such as DDNS it.

   An automatic solution like Teredo appears to publish their be a good fit for
   providing IPv6 addresses connectivity to this
   server. In practice, the DNS address discovered hosts behind NAT, in 3.3.1 will often
   be case A of IPv6
   deployment. The service is designed for minimizing the address cost of
   deploying the gateway itself, and server, which matches the local server will thus
   be requirement of minimizing
   the gateway. Implementing a dynamic DNS server on cost of the gateway may
   be problematic, as many "supporting infrastructure".

3.2	Security considerations in case A

   A characteristic of these gateways are very small devices
   with limited memory and limited processing power.

   An alternative to case A is that an isolated host acquires global
   IPv6 connectivity, using a local server either Teredo or an alternative tunneling
   mechanism. If no precaution is taken, there is LLMNR, which uses a
   multicast mechanism risk of exposing to resolve DNS requests. LLMNR does not require
   any service from
   the gateway, global Internet some applications and also does not require services that hosts
   use DDNS. LLMNR relies on multicast for its operation. There are
   scaling issues with using multicast, as only
   expected to serve local hosts, e.g., those located behind the procedure may become
   very chatty in large networks; but this is not NAT
   when a practical problem
   in most unmanaged networks. A more important problem NAT is present. Developers and administrators should make
   sure that some
   networks only have limited support for multicast transmission: for
   example, multicast transmission on 802.11 network the global IPv6 connectivity is error prone.
   However, unmanaged networks also use multicast restricted to only those
   applications that are expressly designed for neighbor
   discovery; global Internet
   connectivity. The users should be able to configure which
   applications can get IPv6 connectivity to the Internet and which
   should not.

4	Meeting case B requirements of ND

   In case B, we assume that the gateway and LLMNR the ISP are similar; if a link
   technology supports use of ND, it will also enable use of LLMNR.

3.3.4	Recommendations for name resolution both dual-
   stack. The IETF should quickly provide a recommended procedure for
   provisioning hosts on the DNS resolver in local network may be IPv4-only, dual-stack,
   or IPv6-only. The main requirements are: prefix delegation, and name
   resolution. We also study the potential need for communication
   between IPv4 and IPv6 only hosts, either and conclude that a dual-stack approach
   is preferable.

4.1	Connectivity

   The gateway must be able to acquire an IPv6 prefix, delegated by
   standardizing the proper DHCPv6 subset,
   ISP. This can be done through explicit prefix delegation (e.g.,
   DHCPv6), or if the ISP is advertising a /64 prefix on the link, such
   a link can be extended by recommending the use of ND proxy or a bridge.

   An ND proxy can also be used to extend a /64 prefix to multiple
   physical links of different properties (e.g, an
   alternate convention.

   The most plausible candidate for local name resolution appears Ethernet and a PPP
   link).

4.1.1	Extending a Subnet to Span Multiple Links

   A /64 subnet can be extended to span multiple physical links using a
   bridge or ND proxy.  Bridges can be used when bridging multiple

Huitema et al.                                               [Page  7]
   LLMNR; the IETF should quickly proceed to the standardization fo
   that protocol.

3.4	Security considerations in case B

   The case B solutions provide global IPv6 connectivity to the local
   hosts. Removing  8]
   similar media (mainly, Ethernet segments).  On the limit to connectivity imposed by NAT is both other hand, ND
   proxy must be used if a
   feature /64 prefix has to be shared across media
   (e.g., an upstream PPP link and a risk. Implementations should carefully limit global
   IPv6 connectivity to only those applications that are specifically
   designed downstream Ethernet), or if an
   interface cannot be put into promiscuous mode (e.g., an upstream
   wireless link).

   Extending a single subnet to operate on span from the global Internet. Local applications, for
   example, could be restricted ISP to only use link-local addresses, or
   addresses whose most significant bits match the prefix all of the local
   subnet.

4	Meeting case C requirements

   Case C
   unmanaged network is very similar not recommended, and prefix delegation should
   be used when available.  However, sometimes it is unavoidable.  In
   addition, sometimes it's necessary to case B, extend a subnet in the difference being that
   unmanaged network, at the ISP
   is not dual stack. The gateway must thus use some form "customer-side" of tunneling
   mechanism to obtain IPv6 connectivity, the gateway, and an address prefix.

   A simplified form
   changing the topology using routing might require too much
   expertise.

   The ND proxy method results in the sharing of case B occurs is a single host with a global
   IPv4 address, i.e. with a direct connection to the IPv4 Internet. same prefix over
   several links, a procedure generally known as "multi-link subnet".
   This host will be able sharing has effects on neighbor discovery protocols, and
   possibly also on other protocols such as LLMNR [LLMNR] that rely on
   "link local multicast". These effects need to use be carefully studied.

4.1.2	Explicit prefix delegation

   Several networks have already started using an explicit prefix
   delegation mechanism using DHCPv6. In this mechanism, the same tunneling mechanisms as gateway
   uses a
   gateway.

4.1	Tunneling mechanisms

4.1.1	6to4

   The [6TO4] technology allows routers DHCP request to derive a global scope IPv6 obtain an adequate prefix from a global IPv4 address. This technology is a very good
   fit for DHCP server
   managed by the second phase Internet Service Provider. The DHCP request is
   expected to carry proper identification of the transition, as it can be programmed
   in gateway, which
   enables the "upgraded gateway", and can provide value ISP to implement prefix delegation policies. It is
   expected that the gateway
   users without requiring explicit support from ISP assigns a /48 to the ISP. customer. The gateway
   should automatically assign /64s out of this /48 to its internal
   links.

   The basic use of DHCP is insecure. This
   technology has however may be a clear limitation: it requires that problem if the link
   between gateway obtains at least one global IPv4 address from and ISP is shared by multiple subscribers. DHCP
   specification includes authentication options, but does not describe
   the local ISP.

   Another potential limitation task of managing the technology is the reliance on
   publicly accessible "6to4 relay routers" that accept packets from
   6to4 routers keys, and relay them to how the "regular" IPv6 Internet. These
   relays all listen to information would be
   shared between the same IPv4 anycast address [6TO4ANYCAST],
   which enables gateways to start operating as 6to4 routers without
   requiring any explicit configuration. As customer and the deployment of IPv6
   progresses, a growing fraction ISP.  To be useful in such
   environment in practice, the practical details of managing the traffic originating from 6to4
   routers will have DHCP
   authentication need to be carried through these relays, potentially
   leading analyzed.

4.1.3	Recommendation

   The ND proxy and DHCP methods appear to severe congestion have different domains of the relays.

   There are three possible ways to alleviate this congestion. First,
   one can hope
   application. ND proxy is a simple method that many actors will deploy 6to4 relay routers, in
   order corresponds well to facilitate the deployment
   "informal sharing" of IPv6; congestion would be
   alleviated by a link, while explicit delegation provides
   strong administrative control. Both methods require development:
   specify the provision of interaction with neighbor discovery for ND proxy;
   provide security guidelines for explicit delegation.

4.2	Communication between IPv4-only and IPv6-capable nodes

   During the transition phase from IPv4 to IPv6 there will be IPv4-

Huitema et al.                                               [Page  9]
   only, dual-stack and IPv6-only nodes. In theory, there may be a large number of gateways. Second,
   one could develop need
   to provide some "route optimization" process, interconnection services so that the

Huitema et al.                                               [Page  8]
   traffic would flow through IPv4-only and IPv6-
   only hosts can communicate. However, it is hard to develop a "shortcut path" rather than through
   translation service that does not have unwanted side effects on the
   6to4 relays;
   efficiency or the relays would then avoid congestion by carrying only
   a small fraction security of communications. As a consequence, the traffic. Third,
   authors recommend that, if neither the first nor the
   second solution materializes, some gateways may enter into
   contractual agreements with relay service providers; in this case,
   the 6to4 technology would become merely a variant of the configured
   tunnel technologies.

4.1.2	Tunnel broker

   Configured tunnels require device has a contractual agreement requirement to communicate
   with IPv4-only hosts, this device implements an IPv4 stack. The only
   devices that should only have IPv6
   provider, which comes in addition connectivity are those that are
   intended to the existing agreement only communicate with the
   IPv4 provider; different technologies have different domains IPv6 hosts.

4.3	Resolution of
   application.

   Many tunnel technologies use a global IPv4 address names to identify the
   "client end" IPv6 addresses

   There are three types of name resolution services that should be
   provided in case B: local IPv6 capable hosts must be able to obtain
   the tunnel, thus inheriting the same "global IPv4
   address" requirement as 6TO4. A variant IPv6 addresses of correspondent hosts on the [TEREDO] technology
   could Internet; they
   should be used able to establish tunnels over UDP when publish their address if they want to be accessed
   from the client is
   behind a NAT; this variant is however not standardized.

   Practical deployment Internet; and they should be able to obtain the IPv6
   address of tunnel technologies requires other local IPv6 hosts. These three problems are
   described in the next sections. Operational considerations and
   issues with IPv6 DNS are analyzed in [DNSOPV6].

4.3.1	Provisioning the address of a DNS resolver

   In an unmanaged environment, IPv4 hosts usually obtain the
   introduction address
   of accounting/billing functions; the existing tunnel
   broker specification, [TUNNELS], does not describe how these
   functions should be implemented. (However, local DNS resolver through DHCPv4; the DHCPv4 service is
   generally provided by the gateway. The gateway will also use of public relays
   in DHCPv4
   to obtain the 6to4 technology may raise address of a similar issue.)

   Configured tunnels are suitable resolver from the local Internet
   service provider.

   The DHCPv4 solution will suffice in practice an intermediate solution between for the "automatic configuration" provided by 6to4, gateway and
   also for the "ISP
   support" dual-stack hosts. There is evidence that characterizes case B.

4.1.3	ISATAP even the
   simple DNS resolvers present in small gateways can relay arbitrary
   DNS requests and serve arbitrary DNS records, including AAAA
   records.

   Just using DHCPv4 will not be an adequate solution for IPv6-only
   local hosts. The ISATAP protocol [ISATAP] enables DHCP working group has defined how to use
   (stateless) DHCPv6 to obtain the construction address of the DNS server
   [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked
   at in the DNSOP Working Group.

4.3.2	Publishing IPv6 addresses by combining a subnet prefix with an identifier derived to the Internet

   IPv6 capable hosts may be willing to provide services accessible
   from an the global Internet. They will thus need to document their
   address in a server that is publicly available. IPv4 address. Hosts hosts in
   unmanaged networks have a similar problem today, which they solve
   using one of three possible solutions:

   * Manual configuration of a stable address in a DNS server;
   * Dynamic configuration using the standard dynamic DNS protocol;
   * Dynamic configuration using an ISATAP subnet exchange IPv6
   packets by ad hoc protocol.

   Manual configuration of stable addresses is not satisfactory in an automatic tunneling mechanism: the
   unmanaged IPv6 packets are
   tunneled over IPv4 towards network: the IPv4 address specified prefix allocated to the gateway may or
   may not be stable, and in any case copying long hexadecimal strings
   through a manual procedure is error prone.

   Dynamic configuration using the
   identifier part same type of ad hoc protocols that
   are common today is indeed possible, but the address. Hosts in IETF should encourage
   the ISATAP tunnel
   communicate with use of standard solutions based on Dynamic DNS (DDNS).

4.3.3	Resolving the IPv6 Internet by sending packets to the ISATAP
   subnet routers. In practical deployments, ISATAP addresses of local hosts

   There are
   configured with the IPv4 address or two possible ways of resolving the DNS name IPv6 addresses of an ISATAP
   router.

   In theory, ISATAP could be used to provide hosts in an unmanaged
   network with local
   hosts: one may either publish the IPv6 connectivity; addresses in a DNS server for
   the gateway might function local domain, or one may use a peer-to-peer address resolution
   protocol such as an
   ISATAP router. However, in LLMNR.

   When a single subnet deployment, this solution DNS server is markedly inferior to native IPv6: it incurs more overhead, and used, this server could in theory be located
   anywhere on the Internet. There is
   not easier to deploy.

   One may also consider however a very strong argument
   for using a local server, which will remain reachable even if the ISATAP technology
   network connectivity is down.

   The use of a local server requires that IPv6 capable hosts discover
   this server, as explained in 4.3.1, and then that they use a
   protocol such as DDNS to provide publish their IPv6
   connectivity addresses to this
   server. In practice, the gateway itself. However, ISATAP only derives a

Huitema et al.                                               [Page  9]
   single IPv6 DNS address from an IPv4 address. ISATAP can discovered in 4.3.1 will often
   be the address of the gateway itself, and the local server will thus only
   be
   used in the degenerate case when the unmanaged network consists of gateway.

   An alternative to using a
   single host. This will only be interesting if this single host local server is LLMNR, which uses a
   multicast mechanism to resolve DNS requests. LLMNR does not obtain a global IPv4 address require
   any service from the ISP; if it did, it could
   use 6TO4, which is easier to configure. An ISP gateway, and also does not require that provides hosts
   with non-global IPv4 address could set up an ISATAP router, so
   use DDNS. An important problem is that
   each some networks only have
   limited support for multicast transmission: for example, multicast
   transmission on 802.11 network is error prone. However, unmanaged
   networks also use multicast for neighbor discovery [NEIGHBOR]; the
   requirements of these hosts could obtain an IPv6 address.

4.1.4 ND and LLMNR are similar; if a link technology
   supports use of ND, it can also enable use of LLMNR.

4.3.4	Recommendations for name resolution

   The practical conclusion of IETF should quickly provide a recommended procedure for
   provisioning the previous analysis is that "upgraded
   gateways" will probably support DNS resolver in IPv6-only hosts, either by
   standardizing the 6TO4 technology, and will have proper DHCPv6 subset, or by recommending an optional configuration option for "configured tunnels".
   alternate convention.

   The
   ISATAP technology most plausible candidate for local name resolution appears to have very limited applicability be
   LLMNR; the IETF should quickly proceed to the standardization of
   that protocol.

4.4	Security considerations in this
   scenario. case B
   The tunnel broker technology case B solutions provide global IPv6 connectivity to the local
   hosts. Removing the limit to connectivity imposed by NAT is both a
   feature and a risk. Implementations should be augmented, carefully limit global
   IPv6 connectivity to only those applications that are specifically
   designed to include support operate on the global Internet. Local applications, for accounting and billing functions.

   Due
   example, could be restricted to concerns with potential overload only use link-local addresses, or
   addresses whose most significant bits match the prefix of public 6to4 relays, the
   6to4 implementations local
   subnet, e.g., a prefix advertised as "on link" in a local router
   advertisement. There is a debate as to whether such restrictions
   should include be "per-site" or "per-link", but this is not a configuration option that let
   user take advantage serious issue
   when an unmanaged network is composed of specific relays.

4.2	Naming requirements in a single link.

5	Meeting case C

   Naming requirements are

   Case C is very similar to case B.

4.3	Security considerations in case C

   The security issues in case C combines the issues already mentioned
   in case B, plus the specific issues related to difference being that the ISP
   is not dual-stack. The gateway must thus use some form of tunneling
   technologies. The main concern with tunneling technologies is the
   possibility for attackers
   mechanism to spoof the source obtain IPv6 connectivity, and an address prefix.

   A simplified form of IPv6
   packets sent inside case B occurs is a tunnel, and single host with a global
   IPv4 address, i.e., with a direct connection to the IPv4 Internet.
   This host will be able to use this spoofing as the basis for same tunneling mechanisms as a
   gateway.

5.1	Connectivity

   Connectivity in case C requires some form of tunneling of IPv6 over
   IPv4. The various attacks. Attacks on 6TO4 tunnels tunneling solutions are documented discussed in
   [6TO4SECU]. Configured section 2.
   The requirements of case C can be solved by an automatic tunneling
   mechanism such as 6to4 [6TO4]. An alternative may be the use of a
   configured tunnels that do mechanism [TUNNELS], but as the local ISP does is
   not use per packet
   authentication can also IPv6-enabled this may not be feasible. The practical conclusion
   of our analysis is that "upgraded gateways" will probably support
   the 6to4 technology, and will have an optional configuration option
   for "configured tunnels".

   The tunnel broker technology should be subject augmented, to spoofing attacks, if the
   attacker is able include support
   for some form of automatic configuration.

   Due to spoof the source IPv4 address concerns with potential overload of either a tunnel
   server or public 6to4 relays, the
   6to4 implementations should include a tunnel client.

5 configuration option that let
   user take advantage of specific relays.

6	Meeting the case D requirements

   In case D, the ISP only provides IPv6 services.

5.1.1

6.1	IPv6 addressing requirements

   We expect IPv6 addressing in case D to proceed similarly to case B,
   i.e.
   i.e., use either RA ND proxy or explicit configuration prefix delegation through
   DHCPv6 to provision an IPv6 prefix on the gateway.

5.1.2

6.2	IPv4  connectivity requirements

   Local IPv4 capable hosts may want to still access IPv4 only IPv4-only
   services. The proper way to do this for dual stack dual-stack nodes in the
   unmanaged network is to develop a form of "IPv4 over IPv6"
   tunneling. This tunneling protocol need to be standardized. Part of
   the standardization will have to cover configuration issues, i.e. i.e.,
   how to provision the IPv4 capable hosts with the address of the
   local IPv4 tunnel servers.

5.2

6.3	Naming requirements

   Naming requirements are similar to case B, with one difference: the
   gateway cannot expect to use DHCPv4 to obtain the address of the
   DNS resolver recommended by the ISP. This problem is similar to the
   provision of DNS parameters to an IPv6 only host in case B, and the
   same mechanisms can be used.

5.3	Security requirements

   Security requirements in case D are analogous to those of case B.
   The use of a tunneling mechanism to provide IPv4 connectivity may
   introduce its own security issues, but the analysis of these issues
   can only be performed after this tunneling mechanism is fully
   designed.

6

7	Provisional recommendations

   This draft is still

   After a draft, but careful analysis of the possible solutions, we can already list a
   set of recommendations for the V6OPS working group:

   1- To meet case A and case C requirements, we need to develop and standardize
   the Teredo develop, or similar technology.
   continue to develop, four types of tunneling technologies: automatic
   tunnels without NAT traversal such as [6TO4], automatic tunnels with
   NAT traversal such as [TEREDO], configured tunnels without NAT
   traversal such as [TUNNELS] and configured tunnels with NAT
   traversal.

   2- To meet case B prefix delegation requirements, we need a
   standardized IPv6 prefix delegation mechanism

   3- To meet case B "informal prefix sharing" requirements, we would
   need a standardized way to perform "RA "ND proxy", possibly as part of a
   "multi-link subnet" specification

   4- specification. (The explicit prefix delegation
   can be accomplished through [PREFIXDHCPV6].)

   3- To meet case B naming requirements, we need to standardize a way
   to provision a DNS resolver address in IPv6 only hosts, and we need
   to proceed with the standardization of LLMNR.

   5- To meet case C connectivity requirement, requirements we need to continue proceed with the
   standardization of the 6to4 mechanism.

   6- LLMNR. (The provisioning of DNS parameters can be
   accomplished through [DNSDHCPV6].)

   4- To meet case D IPv4 connectivity requirement, we need to
   standardize an IPv4 over IPv6 tunneling mechanism, as well as the
   associated configuration services.

7

8	Security consideration
   The present document does not define any specific technology, and
   thus is not believed to introduce any new security issue. The considerations

   This memo describes the general requirements for transition
   mechanisms. Specific security requirement issues should be studied and addressed
   during the development of each the specific transition case mechanisms.

   When hosts which have been behind a NAT are described
   as part of exposed to IPv6, the analysis of
   security assumptions may change radically.  This is mentioned in
   sections 3.2 and 4.4.  One way to cope with that case.

8 is to have a
   default firewall with NAT-like access configuration; one might also
   restrict applications which can benefit from global IPv6
   connectivity on the nodes.

9	IANA Considerations

   This memo does not include any request to IANA.

9

10	Copyright

   The following copyright notice is copied from RFC 2026 [Bradner,
   1996], Section 10.4, and describes the applicable copyright for this
   document.

   Copyright (C) The Internet Society July 12, 2001. June 3, 2003. All Rights
   Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

10

11	Intellectual Property

   The following notice is copied from RFC 2026 [Bradner, 1996],
   Section 10.4, and describes the position of the IETF concerning
   intellectual property claims made against this document.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

11

12	Acknowledgements

   This fractional and preliminary memo has benefited from comments of Margaret Wasserman Wasserman, Pekka
   Savola, Chirayu Patel and Tony Hain.

12 Tim Chown provided a lot of the
   analysis for the tunneling requirements work.

13	References

   Normative references

   [UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der
   Pol. "Unmanaged Networks IPv6 Transition Scenarios", Work in
   progress.

   [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 2460, December 1998.

   [NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [STATELESS] Narten, T., and S. Thomson, "IPv6 Stateless Address
   Autoconfiguration", RFC 2462, December 1998.

   [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via
   IPv4 Clouds", RFC 3056, February 2001.

   [6TO4ANYCAST] C. Huitema, Huitema. "An Anycast Prefix for 6to4 Relay
   Routers", RFC 3068, June 2001.

   [TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs."
   Work in progress.

   [TUNNELS] Durand, A., Fasano, P., and I. Guardini. IPv6 Tunnel
   Broker. RFC 3053, January 2001

   [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
   "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in
   progress.

   [PREFIXDHCPV6] Troan, O., and R. Droms. "IPv6 Prefix Options for
   DHCPv6." Work in progress.

   [SIIT] E. Nordmark, Stateless IP/ICMP Translation Algorithm (SIIT).
   RFC 2765, February 2000.

   [NAT-PT] Tsirtsis, G., and P. Srisuresh,  Network Address
   Translation - Protocol Translation (NAT-PT). RFC 2766, February
   2000.

   [DNS-ALG-ISSUES] Issues with NAT-PT DNS ALG in RFC2766. Work in
   progress.

   [HALLIN-DNS-ALG] NAT-PT DNS ALG solutions. Work in progress.

   [TRT] Hagino, J., and K. Yamamoto. An IPv6-to-IPv4 Transport Relay
   Translator, RFC 3142, June 2001.

   [DSTM] Dual Stack Transition Mechanism (DSTM). Work in progress.

   [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
   M. Carney. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)."
   Work in progress.
   (DHCPv6)."RFC 3315, July 2003.

   [DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." Work
   in progress.

   [DNSANYCAST] Durand, A., Hagino, J., and  D. Thaler. "Well known
   site local unicast addresses to communicate with recursive DNS
   servers." Work in progress.

   [LLMNR] Esibov, L., Aboba, B., RFC
   3646, December 2003.

   [PREFIXDHCPV6] Troan, O. and D. Thaler. "Linklocal Multicast
   Name Resolution (LLMNR)Multicast DNS." Work in progress.

   [NODEINFO] M. Crawford. R. Droms. "IPv6 Node Information Queries." Work in
   progress.

   [6TO4SECU]  Savola, P., "Security Considerations Prefix Options for 6to4", Work in
   progress.
   DHCPv6." RFC 3633, December 2003.

   Informative references

   [NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address
   Translation - Protocol Translation (NAT-PT)." RFC 2766, February
   2000.

   [DNS-ALG-ISSUES] A. Durand. "Issues

   [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy. "STUN
   - Simple Traversal of User Datagram Protocol (UDP) Through Network
   Address Translators (NATs)", RFC 3489, March 2003.

   [DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational
   Considerations and Issues with NAT-PT DNS ALG IPv6 DNS." Work in RFC2766." progress.

   [LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast
   Name Resolution (LLMNR)." Work in progress.

13

14	Authors' Addresses

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   Email: huitema@microsoft.com

   Rob Austein
   Email: sra@hactrn.net

   Suresh Satapati
   Cisco Systems, Inc.
   San Jose, CA 95134
   USA
   EMail: satapati@cisco.com

   Ronald van der Pol
   NLnet Labs
   Kruislaan 419
   1098 VA Amsterdam
   NL
   Email: Ronald.vanderPol@nlnetlabs.nl

Table of Contents:

1 Introduction ....................................................   1
2 Evaluation of Tunneling Solutions ...............................   2
2.1 Comparing automatic and configured solutions ..................   2
2.1.1 Path optimization in automatic tunnels ......................   3
2.1.2 Automatic tunnels and relays ................................   3
2.1.3 The risk of several parallel IPv6 Internets .................   4
2.1.4 Lifespan of transition technologies .........................   5
2.2 Cost and benefits of NAT traversal ............................   5
2.2.1 Cost of NAT traversal .......................................   6
2.2.2 Types of NAT ................................................   6
2.2.3 Reuse of existing mechanisms ................................   6
2.3 Development of transition mechanisms ..........................   7
3 Meeting case A requirements .....................................   2
2.1   7
3.1 Evaluation of connectivity mechanisms .........................   2
2.1.1 TEREDO ......................................................   2
2.1.2 Simple UDP tunnel ...........................................   2
2.1.3 Comparison of TEREDO and tunnel solution ....................   3
2.1.4 Recommendation ..............................................   4
2.2   7
3.2 Security considerations in case A .............................   8
4
3 Meeting case B requirements .....................................   4
3.1 Prefix delegation .............................................   5
3.1.1 RA proxy ....................................................   5
3.1.2   8
4.1 Connectivity ..................................................   8
4.1.1 Extending a Subnet to Span Multiple Links ...................   8
4.1.2 Explicit prefix delegation ..................................   5
3.1.3   9
4.1.3 Recommendation ..............................................   5
3.2   9
4.2 Communication between IPv4-only and IPv6-capable nodes ........   5
3.3   9
4.3 Resolution of names to IPv6 addresses .........................   6
3.3.1  10
4.3.1 Provisioning the address of a DNS resolver ..................   6
3.3.2  10
4.3.2 Publishing IPv6 addresses to the Internet ...................   6
3.3.3  10
4.3.3 Resolving the IPv6 addresses of local hosts .................   7
3.3.4  11
4.3.4 Recommendations for name resolution .........................   7
3.4  11
4.4 Security considerations in case B .............................   8
4  11
5 Meeting case C requirements .....................................   8
4.1 Tunneling mechanisms ..........................................   8
4.1.1 6to4 ........................................................   8
4.1.2 Tunnel broker ...............................................   9
4.1.3 ISATAP ......................................................   9
4.1.4 Recommendations .............................................  10
4.2 Naming requirements in case C .................................  10
4.3 Security considerations in case C .............................  10
5  12
5.1 Connectivity ..................................................  12
6 Meeting the case D requirements .................................  10
5.1.1  12
6.1 IPv6 addressing requirements ................................  10
5.1.2 ..................................  12
6.2 IPv4  connectivity requirements .............................  10
5.2 ...............................  13
6.3 Naming requirements ...........................................  11
5.3 Security requirements .........................................  11
6  13
7 Provisional recommendations .....................................  11
7 Security consideration ..........................................  11  13
8 Security considerations .........................................  13
9 IANA Considerations .............................................  12
9 Copyright .......................................................  12  14
10 Copyright ......................................................  14
11 Intellectual Property ..........................................  14
12
11 Acknowledgements ...............................................  15
13
12 References .....................................................  13
13  15
14 Authors' Addresses .............................................  15  16