[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-huitema-v6ops-unmaneval) 00 01 02 03 RFC 3904

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


    Evaluation of 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,
   which typically corresponds 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.

1       Introduction

   In a companion paper [UNMANREQ] we defined the "unmanaged networks"
   scope, 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.

   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:

   A) a gateway which does not provide IPv6 at all;

Huitema et al.                                               [Page  1]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   B) a dual-stack gateway connected to a dual stack ISP;
   C) a dual stack gateway connected to an 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
   only, dual stack or IPv6 only nodes. In this document, we make the
   hypothesis that the IPv6 only nodes do not need to communicate with
   IPv4 only nodes; devices that want to communicate with both IPv4 and
   IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. be
   dual stack.

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

2       Meeting case A 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. We then consider the "remaining holes" and recommend
   specific developments.

2.1     Evaluation of connectivity mechanisms

   In case A, IPv6 capable hosts seek IPv6 connectivity in order to
   participate to applications in the global IPv6 Internet. The
   connectivity requirement can be met in two ways: Teredo, or UDP
   tunnels. (We will not discuss here the case where there is no NAT;
   this will be considered as a subset of case C.)

2.1.1   TEREDO

   TEREDO is a mechanism designed to provide IPv6 connectivity to hosts
   behind NATs. Hosts use servers to find out a "mapped" IPv4 address
   and UDP port; they build an IPv6 address that includes the IPv4
   address of their preferred server, and their own mapped IPv4 address
   and mapped port. A mechanism of bubbles, relayed by the servers, is
   used for establishing contacts between Teredo nodes, or for
   discovering the appropriate Teredo relay serving an IPv6 peer; the
   actual IPv6 packets are carried in UDP packets exchanged directly
   between the nodes, or exchanged through the relay serving an IPv6
   peer.

2.1.2   Simple UDP tunnel


Huitema et al.                                               [Page  2]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   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 over UDP. This solution
   was described in a draft that has now expired, and is also mentioned
   as a possible alternative to 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 is the cost of operating the server. TEREDO is
   designed to minimize the cost of operating the server, which only
   processes small bubbles and never relays traffic; on the other hand,
   a tunnel server will relay all the packets going to and from the
   Teredo host. This implies a very different amount of traffic.

   To gauge the difference, we consider the case of a host engaging in
   Voice over IP: it will maintain its address reachable all the time,
   and it will send a large amount of traffic whenever it is engaged in
   a conversation. According to classic figures collected by AT&T, the
   average duration of a conversation is around 100 seconds, and a
   business telephone is likely to be engaged in a conversation about
   10% of the time, which implies starting a conversation on average
   every 1000 seconds. The average load sent by a tunnel client to the
   tunnel server will be 10% of the average data rate of the client;
   assuming a 16kbps codec and 50 packets per second, the data rate of
   the client sums up to about 51 kbps, hence an average load on the
   tunnel server of 5 kbps. The load sent by the tunnel client to the
   tunnel server will be about one exchange of bubble per minute, to
   defend the address, plus one bubble exchange at the beginning of
   each session with a new peer; adding all headers, the bubble size is
   about 144 bytes, which results in about 20 bps of traffic on the
   server. In short, the amount of traffic seen by the Teredo server is
   250 times less that the traffic seen by a Teredo client.

   The tunnel approach is more expensive to provide, because the tunnel
   server will have to carry a much larger amount of traffic. It is
   unclear that a tunnel service can be provided as an almost free
   "supporting infrastructure", except perhaps if the service was
   directly provided by the same ISP that already provides IPv4
   connectivity to the unmanaged network.

   The two approaches have much in common: both need to parameterize a
   client with the name of a server and with sufficient credentials;
   the encapsulation is similar; both use the same encapsulation
   mechanism; and both will use router solicitations to obtain an
   address prefix. The main difference is the handling of bubbles in
   Teredo, which are used to defend the address 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]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   higher than the discovery of link layer addresses using neighbor
   discovery. In short, Teredo is more complex, but the complexity is
   not overwhelming.

   An advantage of the tunnel server approach over Teredo is that it
   will work regardless of the type and number of NAT between the
   client and the tunnel server. In contrast, Teredo will not work
   across a "symmetric" NAT, and communication may be impossible
   between two Teredo clients located behind the same NAT.

   Another potential advantage of the tunnel server approach is that it
   could provide clients with stable IPv6 addresses. This is only a
   potential advantage, since the server may prefer to delegate
   addresses on a session per session basis, or may want to operate in
   a stateless manner.

2.1.4   Recommendation

   Teredo appears to be a good fit for providing IPv6 connectivity to
   hosts behind NAT, in case A of IPv6 deployment. The service is
   designed for minimizing the cost of deploying the server, which
   matches the requirement of minimizing the cost of the "supporting
   infrastructure" for peer-to-peer applications.

   There are however two situations in which a tunnel service makes
   sense: when the cost of bandwidth is not a concern, and when the
   unmanaged network is located behind a symmetric NAT. In these two
   cases, using a tunnel service is preferred over using Teredo.

   The most reasonable solution would be to develop a tunnel service
   specification 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 configured in the dual stack host.

2.2     Security considerations in case A

   A characteristic of case A is that a host located behind a NAT
   acquires global IPv6 connectivity, using either Teredo or an
   alternative tunneling mechanism. If no precaution is taken, there is
   a risk of exposing to the global Internet some applications and
   services that only expected to serve local hosts, located behind the
   NAT. Developers and administrators should make sure that the global
   IPv6 connectivity is restricted to only those applications that are
   expressly designed for global Internet connectivity.

3       Meeting case B requirements

   In case B, we assume that the gateway and the ISP are both dual
   stack. The hosts on the 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 hosts, and conclude that a dual stack approach

Huitema et al.                                               [Page  4]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   is preferable.

3.1     Prefix delegation

   The gateway must be able to acquire an IPv6 prefix, delegated by the
   ISP. The possible mechanisms are RA proxy and explicit prefix
   delegation.

3.1.1   RA proxy

   The implicit delegation mechanism assumes that the gateway is
   connected to the ISP by a point-to-point link. Examples of such
   point to point links are various types of configured tunnels and
   serial links, for example using PPP. The principle of RA proxy is
   simple: the gateway issues a "router solicitation" message on the
   serial link, receives a "router advertisement", learns a network
   prefix from the advertisement, and advertises the same prefix on the
   unmanaged network.

   The RA proxy method results in the sharing of the same prefix over
   several links, a procedure generally known as "multi-link subnet".
   This sharing has effects on neighbor discovery protocols, and
   possibly also on other protocols such as LLMNR that rely on "link
   local multicast". 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, the gateway
   uses a DHCP request to obtain an adequate prefix from a DHCP server
   managed by the Internet Service Provider. The DHCP request is
   expected to carry proper identification of the gateway, which
   enables the ISP to implement prefix delegation policies.

   The basic use of DHCP is insecure. This may be a problem if the link
   between gateway and ISP is shared by multiple subscribers. In that
   case, some security procedure will have to be used, to ensure at a
   minimum that DHCP requests and replies are properly authenticated.

3.1.3   Recommendation

   The RA proxy and DHCP methods appear to have different domains of
   application. RA proxy is a simple method that corresponds well to
   "informal sharing" of a link, 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 of at least one method, and possibly both, is quite
   urgent.

3.2     Communication between IPv4-only and IPv6-capable nodes


Huitema et al.                                               [Page  5]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   During the transition phase from IPv4 to IPv6 there will be IPv4-
   only, dual stack and IPv6-only nodes. In theory, there may be a need
   to provide some interconnection services so that IPv4-only and IPv6-
   only hosts can communicate. However, as indicated in a companion
   document, it is hard to develop a translation service that does not
   have unwanted side effects on the efficiency or the security of
   communications. As a consequence, the authors recommend that, if a
   device has a requirement to communicate with IPv4 only hosts, this
   device implements an IPv4 stack. The only devices that should only
   have IPv6 connectivity are those that are intended to only
   communicate with IPv6 hosts.

3.3     Resolution of names 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 to obtain
   the IPv6 addresses of correspondent hosts on the Internet; they
   should be able to publish their address if they want to be accessed
   from the Internet; and they should be able to obtain the IPv6
   address of other local IPv6 hosts. These three problems are
   described in the next sections.

3.3.1   Provisioning the address of a DNS resolver

   In an unmanaged environment, IPv4 hosts usually obtain the address
   of the local DNS resolver through DHCPv4; the DHCPv4 service is
   generally provided by the gateway. The gateway will also use DHCPv4
   to obtain the address of a suitable resolver from the local Internet
   service provider.

   The DHCPv4 solution will suffice in practice for the gateway and
   also for the dual stack hosts. There 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 solution for IPv6 only
   local hosts. Three solutions have been envisaged for these hosts:
   either using DHCPv6 to obtain the address of the DNS server; sending
   the DNS requests to a well known IPv6 address; 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 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 a DNS server;
   * Dynamic configuration using the standard dynamic DNS protocol;
   * Dynamic configuration using an ad hoc protocol.

Huitema et al.                                               [Page  6]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   Manual configuration of stable addresses is not satisfactory in an
   unmanaged IPv6 network: the prefix allocated to the gateway may or
   may not be stable, and 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
   the use of standard solutions based on DDNS.

3.3.3   Resolving the IPv6 addresses of local hosts

   There are two possible ways of resolving the IPv6 addresses of local
   hosts: one may either publish the IPv6 addresses in a DNS server for
   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 be located
   anywhere on the Internet. There is however a very strong argument
   for using a local server, which will remain reachable even if the
   network connectivity is down.

   The use of a local server requires that IPv6 capable hosts discover
   this server, as explained in 3.3.1, and then that they use a
   protocol such as DDNS to publish their IPv6 addresses to this
   server. In practice, the DNS address discovered in 3.3.1 will often
   be the address of the gateway itself, and the local server will thus
   be the gateway. Implementing a dynamic DNS server on the gateway may
   be problematic, as many of these gateways are very small devices
   with limited memory and limited processing power.

   An alternative to using a local server is LLMNR, which uses a
   multicast mechanism to resolve DNS requests. LLMNR does not require
   any service from the gateway, and also does not require that hosts
   use DDNS. LLMNR relies on multicast for its operation. There are
   scaling issues with using multicast, as the procedure may become
   very chatty in large networks; but this is not a practical problem
   in most unmanaged networks. A more important problem is that 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; the requirements of ND and LLMNR are similar; if a link
   technology supports use of ND, it will also enable use of LLMNR.

3.3.4   Recommendations for name resolution

   The IETF should quickly provide a recommended procedure for
   provisioning the DNS resolver in IPv6 only hosts, either by
   standardizing the proper DHCPv6 subset, or by recommending an
   alternate convention.

   The most plausible candidate for local name resolution appears to be

Huitema et al.                                               [Page  7]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   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 the limit to connectivity imposed by NAT is both a
   feature and a risk. Implementations should carefully limit global
   IPv6 connectivity to only those applications that are specifically
   designed to operate on the global Internet. Local applications, for
   example, could be restricted to only use link-local addresses, or
   addresses whose most significant bits match the prefix of the local
   subnet.

4       Meeting case C requirements

   Case C is very similar to case B, the difference being that the ISP
   is not dual stack. The gateway must thus use some form of tunneling
   mechanism to obtain IPv6 connectivity, and an address prefix.

   A simplified form of case B occurs is a single host with a global
   IPv4 address, i.e. with a direct connection to the IPv4 Internet.
   This host will be able to use the same tunneling mechanisms as a
   gateway.

4.1     Tunneling mechanisms

4.1.1   6to4

   The [6TO4] technology allows routers to derive a global scope IPv6
   prefix from a global IPv4 address. This technology is a very good
   fit for the second phase of the transition, as it can be programmed
   in the "upgraded gateway", and can provide value to the gateway
   users without requiring explicit support from the ISP. This
   technology has however a clear limitation: it requires that the
   gateway obtains at least one global IPv4 address from the local ISP.

   Another potential limitation of the technology is the reliance on
   publicly accessible "6to4 relay routers" that accept packets from
   6to4 routers and relay them to the "regular" IPv6 Internet. These
   relays all listen to the same IPv4 anycast address [6TO4ANYCAST],
   which enables gateways to start operating as 6to4 routers without
   requiring any explicit configuration. As the deployment of IPv6
   progresses, a growing fraction of the traffic originating from 6to4
   routers will have to be carried through these relays, potentially
   leading to severe congestion of the relays.

   There are three possible ways to alleviate this congestion. First,
   one can hope that many actors will deploy 6to4 relay routers, in
   order to facilitate the deployment of IPv6; congestion would be
   alleviated by the provision of a large number of gateways. Second,
   one could develop some "route optimization" process, so that the

Huitema et al.                                               [Page  8]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   traffic would flow through a "shortcut path" rather than through the
   6to4 relays; the relays would then avoid congestion by carrying only
   a small fraction of the traffic. Third, 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 a contractual agreement with an IPv6
   provider, which comes in addition to the existing agreement with the
   IPv4 provider; different technologies have different domains of
   application.

   Many tunnel technologies use a global IPv4 address to identify the
   "client end" of the tunnel, thus inheriting the same "global IPv4
   address" requirement as 6TO4. A variant of the [TEREDO] technology
   could be used to establish tunnels over UDP when the client is
   behind a NAT; this variant is however not standardized.

   Practical deployment of tunnel technologies requires the
   introduction of accounting/billing functions; the existing tunnel
   broker specification, [TUNNELS], does not describe how these
   functions should be implemented. (However, the use of public relays
   in the 6to4 technology may raise a similar issue.)

   Configured tunnels are in practice an intermediate solution between
   the "automatic configuration" provided by 6to4, and the "ISP
   support" that characterizes case B.

4.1.3   ISATAP

   The ISATAP protocol [ISATAP] enables the construction of IPv6
   addresses by combining a subnet prefix with an identifier derived
   from an IPv4 address. Hosts in an ISATAP subnet exchange IPv6
   packets by an automatic tunneling mechanism: the IPv6 packets are
   tunneled over IPv4 towards the IPv4 address specified in the
   identifier part of the address. Hosts in the ISATAP tunnel
   communicate with the IPv6 Internet by sending packets to the ISATAP
   subnet routers. In practical deployments, ISATAP hosts are
   configured with the IPv4 address or the DNS name of an ISATAP
   router.

   In theory, ISATAP could be used to provide hosts in an unmanaged
   network with IPv6 connectivity; the gateway might function as an
   ISATAP router. However, in a single subnet deployment, this solution
   is markedly inferior to native IPv6: it incurs more overhead, and is
   not easier to deploy.

   One may also consider using the ISATAP technology to provide IPv6
   connectivity to the gateway itself. However, ISATAP only derives a

Huitema et al.                                               [Page  9]


INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   single IPv6 address from an IPv4 address. ISATAP can thus only be
   used in the degenerate case when the unmanaged network consists of a
   single host. This will only be interesting if this single host does
   not obtain a global IPv4 address from the ISP; if it did, it could
   use 6TO4, which is easier to configure. An ISP that provides hosts
   with non-global IPv4 address could set up an ISATAP router, so that
   each of these hosts could obtain an IPv6 address.

4.1.4   Recommendations

   The practical conclusion of the previous analysis is that "upgraded
   gateways" will probably support the 6TO4 technology, and will have
   an optional configuration option for "configured tunnels". The
   ISATAP technology appears to have very limited applicability in this
   scenario.

   The tunnel broker technology should be augmented, to include support
   for accounting and billing functions.

   Due to concerns with potential overload of public 6to4 relays, the
   6to4 implementations should include a configuration option that let
   user take advantage of specific relays.


4.2     Naming requirements in case C

   Naming requirements are 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 the use of tunneling
   technologies. The main concern with tunneling technologies is the
   possibility for attackers to spoof the source address of IPv6
   packets sent inside a tunnel, and use this spoofing as the basis for
   various attacks. Attacks on 6TO4 tunnels are documented in
   [6TO4SECU]. Configured tunnels that do not use per packet
   authentication can also be subject to spoofing attacks, if the
   attacker is able to spoof the source IPv4 address of either a tunnel
   server or a tunnel client.

5       Meeting the case D requirements

   In case D, the ISP only provides IPv6 services.

5.1.1   IPv6 addressing requirements

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

5.1.2   IPv4  connectivity requirements

Huitema et al.                                               [Page 10]

INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   Local IPv4 capable hosts may want to still access IPv4 only
   services. The proper way to do this for 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.
   how to provision the IPv4 capable hosts with the address of the
   local IPv4 tunnel servers.

5.2     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       Provisional recommendations

   This draft is still a draft, but we can already list a set of
   recommendations for the V6OPS working group:

   1- To meet case A requirements, we need to develop and standardize
   the Teredo or similar technology.

   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 proxy", possibly as part of a
   "multi-link subnet" specification

   4- 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, we need to continue
   standardization of the 6to4 mechanism.

   6- 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       Security consideration

Huitema et al.                                               [Page 11]

INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   The present document does not define any specific technology, and
   thus is not believed to introduce any new security issue. The
   security requirement of each specific transition case are described
   as part of the analysis of that case.

8       IANA Considerations

   This memo does not include any request to IANA.

9       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. 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      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

Huitema et al.                                               [Page 12]

INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   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      Acknowledgements

   This fractional and preliminary memo has benefited from comments of
   Margaret Wasserman and Tony Hain.

12      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, "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,

Huitema et al.                                               [Page 13]

INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

   "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.

   [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., and D. Thaler. "Linklocal Multicast
   Name Resolution (LLMNR)Multicast DNS." Work in progress.

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

   [6TO4SECU]  Savola, P., "Security Considerations for 6to4", Work in
   progress.

   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 with NAT-PT DNS ALG in RFC2766."
   Work in progress.


Huitema et al.                                               [Page 14]

INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

13      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





























Huitema et al.                                               [Page 15]

INTERNET DRAFT    Unmanaged Networks Transition Tools    June 3, 2003

Table of Contents:

1 Introduction ....................................................   1
2 Meeting case A requirements .....................................   2
2.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 Security considerations in case A .............................   4
3 Meeting case B requirements .....................................   4
3.1 Prefix delegation .............................................   5
3.1.1 RA proxy ....................................................   5
3.1.2 Explicit prefix delegation ..................................   5
3.1.3 Recommendation ..............................................   5
3.2 Communication between IPv4-only and IPv6-capable nodes ........   5
3.3 Resolution of names to IPv6 addresses .........................   6
3.3.1 Provisioning the address of a DNS resolver ..................   6
3.3.2 Publishing IPv6 addresses to the Internet ...................   6
3.3.3 Resolving the IPv6 addresses of local hosts .................   7
3.3.4 Recommendations for name resolution .........................   7
3.4 Security considerations in case B .............................   8
4 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 Meeting the case D requirements .................................  10
5.1.1 IPv6 addressing requirements ................................  10
5.1.2 IPv4  connectivity requirements .............................  10
5.2 Naming requirements ...........................................  11
5.3 Security requirements .........................................  11
6 Provisional recommendations .....................................  11
7 Security consideration ..........................................  11
8 IANA Considerations .............................................  12
9 Copyright .......................................................  12
10 Intellectual Property ..........................................  12
11 Acknowledgements ...............................................  13
12 References .....................................................  13
13 Authors' Addresses .............................................  15









Huitema et al.                                               [Page 16]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/