GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc3904

Network Working Group C. Huitema Request for Comments: 3904 Microsoft Category: Informational R. Austein

                                                                   ISC
                                                           S. Satapati
                                                   Cisco Systems, Inc.
                                                        R. van der Pol
                                                            NLnet Labs
                                                        September 2004
  Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This document analyzes issues involved in the transition of
 "unmanaged networks" from IPv4 to IPv6.  Unmanaged networks typically
 correspond to home networks or small office networks.  A companion
 paper analyzes out the requirements for mechanisms needed in various
 transition scenarios of these networks to IPv6.  Starting from this
 analysis, we evaluate the suitability of mechanisms that have already
 been specified, proposed, or deployed.

Table of Contents:

 1.  Introduction .................................................  2
 2.  Evaluation of Tunneling Solutions ............................  3
     2.1.  Comparing Automatic and Configured Solutions ...........  3
           2.1.1.  Path Optimization in Automatic Tunnels .........  4
           2.1.2.  Automatic Tunnels and Relays ...................  4
           2.1.3.  The Risk of Several Parallel IPv6 Internets ....  5
           2.1.4.  Lifespan of Transition Technologies ............  6
     2.2.  Cost and Benefits of NAT Traversal .....................  6
           2.2.1.  Cost of NAT Traversal ..........................  7
           2.2.2.  Types of NAT ...................................  7
           2.2.3.  Reuse of Existing Mechanisms ...................  8
     2.3.  Development of Transition Mechanisms ...................  8

Huitema, et al. Informational [Page 1] RFC 3904 Unmanaged Networks Transition Tools September 2004

 3.  Meeting Case A Requirements ..................................  9
     3.1.  Evaluation of Connectivity Mechanisms ..................  9
     3.2.  Security Considerations in Case A ......................  9
 4.  Meeting case B Requirements .................................. 10
     4.1.  Connectivity ........................................... 10
           4.1.1.  Extending a Subnet to Span Multiple Links ...... 10
           4.1.2.  Explicit Prefix Delegation ..................... 11
           4.1.3.  Recommendation ................................. 11
     4.2.  Communication Between IPv4-only and IPv6-Capable Nodes . 11
     4.3.  Resolution of Names to IPv6 Addresses .................. 12
           4.3.1.  Provisioning the Address of a DNS Resolver ..... 12
           4.3.2.  Publishing IPv6 Addresses to the Internet ...... 12
           4.3.3.  Resolving the IPv6 Addresses of Local Hosts .... 13
           4.3.4.  Recommendations for Name Resolution ............ 13
     4.4.  Security Considerations in Case B ...................... 14
 5.  Meeting Case C Requirements .................................. 14
     5.1.  Connectivity ........................................... 14
 6.  Meeting the Case D Requirements .............................. 14
     6.1.  IPv6 Addressing Requirements ........................... 15
     6.2.  IPv4  Connectivity Requirements ........................ 15
     6.3.  Naming Requirements .................................... 15
 7.  Recommendations .............................................. 15
 8.  Security Considerations ...................................... 16
 9.  Acknowledgements ............................................. 16
 10. References ................................................... 16
 11. Authors' Addresses ........................................... 18
 12. Full Copyright Statement ..................................... 19

1. Introduction

 This document analyzes the issues involved in the transition from
 IPv4 to IPv6 [IPV6].  In a companion paper [UNMANREQ] we defined the
 "unmanaged networks", which typically correspond to home networks or
 small office networks, and the requirements for transition mechanisms
 in various scenarios of transition to IPv6.
 The requirements for unmanaged networks are expressed by analyzing
 four classes of applications: local, client, peer to peer, and
 servers, and are considering four cases of deployment.  These are:
    A) a gateway which does not provide IPv6 at all;
    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.
 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

Huitema, et al. Informational [Page 2] RFC 3904 Unmanaged Networks Transition Tools September 2004

 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 sections.  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.  The connectivity requirements often require
 tunneling solutions.  We devote the first section of this memo to an
 evaluation of various tunneling solutions.

2. Evaluation of Tunneling Solutions

 In the case A and case C scenarios described in [UNMANREQ], the
 unmanaged network cannot obtain IPv6 service, at least natively, from
 its ISP.  In these cases, the IPv6 service will have to be provided
 through some form of tunnel.  There have been multiple proposals on
 different ways to tunnel IPv6 through an IPv4 service.  We believe
 that these proposals can be categorized according to two important
 properties:
  • Is the deployment automatic, or does it require explicit

configuration or service provisioning?

  • Does the proposal allow for the traversal of a NAT?
 These two questions divide the solution space into four broad
 classes.  Each of these classes has specific advantages and risks,
 which we will now develop.

2.1. Comparing Automatic and Configured Solutions

 It is possible to broadly classify tunneling solutions as either
 "automatic" or "configured".  In an automatic solution, a host or a
 router builds an IPv6 address or an IPv6 prefix by combining a pre-
 defined prefix with some local attribute, such as a local IPv4
 address [6TO4] or the combination of an address and a port number
 [TEREDO].  Another typical and very important characteristic of an
 automatic solution is they aim to work with a minimal amount of
 support or infrastructure for IPv6 in the local or 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 explicitly
 defined "tunnel router".  The amount of actual configuration may vary
 from manually configured static tunnels to dynamic tunnel services
 requiring only the configuration of a "tunnel broker", or even a
 completely automatic discovery of the tunnel router.

Huitema, et al. Informational [Page 3] RFC 3904 Unmanaged Networks Transition Tools September 2004

 Configured tunnels have many advantages over automatic tunnels.  The
 client is explicitly identified and can obtain a stable IPv6 address.
 The service provider is also well identified and can be held
 responsible for the quality of the service.  It is possible to route
 multicast packets over the established tunnel.  There is a clear
 address delegation path, which enables easy support for reverse DNS
 lookups.
 Automatic tunnels generally cannot provide the same level of service.
 The IPv6 address is only as stable as the underlying IPv4 address,
 the quality of service depends on 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
 advantages.  They are obviously easier to configure, since there is
 no need for an explicit relation with a tunnel service.  They may
 also be more efficient in some cases, as they allow for "path
 optimization".

2.1.1. Path Optimization in Automatic Tunnels

 In automatic tunnels like [TEREDO] and [6TO4], the bulk of the
 traffic between two nodes using the same technology is exchanged on a
 direct path between the endpoints, using the IPv4 services to which
 the endpoints already subscribe.  By contrast, the configured tunnel
 servers carry all the traffic exchanged by the tunnel client.
 Path optimization is not a big issue if the tunnel server is close to
 the client on the natural path between the client and its peers.
 However, if the tunnel server is operated by a third party, this
 third party will have to bear the cost of provisioning the bandwidth
 used by the client.  The associated costs can be significant.
 These costs are largely absent when the tunnels are configured by the
 same ISP that provides the IPv4 service.  The ISP can place the
 tunnel end-points close to the client, i.e., mostly on the direct
 path between the 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 local ISP or automatic tunneling
 regardless of the co-operation of ISPs.  However, automatic solutions
 require that relays be configured throughout the Internet.  If a host
 that obtained connectivity through an automatic tunnel service wants
 to communicate with a "native" host or with a host using a configured

Huitema, et al. Informational [Page 4] RFC 3904 Unmanaged Networks Transition Tools September 2004

 tunnel, it will need to use a relay service, and someone will have to
 provide and pay for that service.  We cannot escape economic
 considerations for the deployment of these relays.
 It is desirable to locate these relays close to the "native host".
 During the transition period, the native ISPs have an interest in
 providing a relay service for use by their native subscribers.  Their
 subscribers will enjoy better connectivity, and will therefore be
 happier.  Providing the service does not result in much extra
 bandwidth requirement: the packets are exchanged between the local
 subscribers and the Internet; they are simply using a v6-v4 path
 instead of a v6-v6 path.  (The native ISPs do not 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 Teredo service by Microsoft, the relays
 are provided by the native (or 6to4) hosts themselves.  The native or
 6to4 hosts are de-facto "multi-homed" to native and Teredo hosts,
 although they never publish a Teredo address in the DNS or otherwise.
 When a native host communicates with a Teredo host, the first packets
 are exchanged through the native interface and relayed by the Teredo
 server, while the 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 network.
 This type of solution carries the implicit risk of developing two
 parallel IPv6 Internets, one native and one using Teredo: in order to
 communicate with a Teredo-only host, a native IPv6 host has to
 implement a Teredo interface.  The Teredo implementations try to
 mitigate this risk by always preferring native paths when available,
 but a true mitigation requires that native hosts do not have to
 implement the transition technology.  This requires cooperation from
 the IPv6 ISP, who will have to support the relays.  An IPv6 ISP that
 really wants to isolate its customers from the Teredo technology can
 do that by providing native connectivity and a Teredo relay.  The
 ISP's customers will not need to implement their own relay.
 Communication between 6to4 networks and native networks uses a
 different structure.  There are two relays, one for each direction of
 communication.  The 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 6to4 relay that is either explicitly configured or

Huitema, et al. Informational [Page 5] RFC 3904 Unmanaged Networks Transition Tools September 2004

 discovered through the 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 bottleneck.  The communications
 between 6to4 and native networks will be slower than the direct
 communications between 6to4 hosts.  This will create an incentive for
 native hosts to somehow "multi-home" to 6to4, de facto creating two
 parallel Internets, 6to4 and native.  This risk will only be
 mitigated if there is a sufficient deployment of 6to4 relays.
 The configured tunnel solutions do not carry this type of risk.

2.1.4. Lifespan of Transition Technologies

 A related issue is the lifespan of the transition solutions.  Since
 automatic tunneling technologies enable an automatic deployment,
 there is a risk that some hosts never migrate out of the transition.
 The risk is arguably less for explicit tunnels: the 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 hosts will not configure a
 transition technology address if they have native connectivity; the
 address selection mechanisms will prefer native addresses when
 available.  The transition technologies will stop being used
 eventually, when native connectivity has been deployed everywhere.
 However, the "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 the entire
 network: native IPv6 ISPS have to support relays in order to provide
 good performance and avoid the "parallel Internet" syndrome.  These
 costs may be acceptable during an initial deployment phase, but they
 can certainly not be supported for an indefinite period.  The
 "implicit sunset" mechanisms may not be sufficient to guarantee a
 finite lifespan of the transition.

2.2. Cost and Benefits of NAT Traversal

 During the transition, some hosts will be located behind IPv4 NATs.
 In order to participate in the transition, these hosts will have to
 use a tunneling mechanism designed to traverse NAT.
 We may ask whether NAT traversal should be a generic property of any
 transition technology, or whether it makes sense to develop two types
 of technologies, some "NAT capable" and some not.  An important
 question is also which kinds of NAT boxes one should be able to

Huitema, et al. Informational [Page 6] RFC 3904 Unmanaged Networks Transition Tools September 2004

 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 NAT traversal technology should use
 automatic tunnels or configured tunnels.  We saw in the previous
 section that one can argue both sides of this issue.  In fact, there
 are already deployed automatic and configured solutions, so the
 reality is that we will probably see both.

2.2.1. Cost of NAT Traversal

 NAT traversal technologies generally involve encapsulating IPv6
 packets inside a transport protocol that is known to traverse NAT,
 such as UDP or TCP.  These transport technologies require
 significantly more overhead than the 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
 maintain a "mapping" in the NAT; solutions based on TCP may not
 require such a mechanism, but they incur the risk of "head of queue
 blocking", which may translate in poor performance.  Given the
 difference in performance, it makes sense to consider two types of
 transition technologies, some capable of traversing NAT and some
 aiming at the 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 port allocations, and
 different types of timers.  It is desirable to find solutions that
 cover "almost all" models of NAT.
 A configured tunnel solution will generally make fewer hypotheses on
 the behavior of the NAT than an automatic solution.  The configured
 solutions only need to establish a connection between an internal
 node and a server; this communication pattern is supported by pretty
 much all NAT configurations.  The variability will come from the type
 of transport protocols that the NAT supports, especially when the NAT
 also implements "firewall" functions.  Some models will allow
 establishment of a single "protocol 41" tunnel, while some may
 prevent this type of transmission.  Some models will allow UDP
 transmission, while other may only allow TCP, or possibly HTTP.

Huitema, et al. Informational [Page 7] RFC 3904 Unmanaged Networks Transition Tools September 2004

 The automatic solutions have to rely on a "lowest common denominator"
 that is likely to be accepted by most models of NAT.  In 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
 support these applications.  In some edge cases, the automatic
 solutions will require explicit configuration of a port in the home
 router, using the so-called "DMZ" functions; however, these functions
 are hard to use in an "unmanaged network" scenario.

2.2.3. Reuse of Existing Mechanisms

 NAT traversal is not a problem for IPv6 alone.  Many IPv4
 applications have developed solutions, or kludges, to enable
 communication across a 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 proposed IETF standard, L2TP, includes a PPP layer that
 can encapsulate IPv6 as well as IPv4.  Several NAT models are
 explicitly designed to pass VPN traffic, and several VPN solutions
 have special provisions to traverse NAT.  When we study the
 establishment of configured tunnels through NAT, it makes a lot of
 sense to consider existing VPN solutions.
 [STUN] is a protocol designed to facilitate the 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 one could consider reusing the STUN
 specification as part of an automatic tunneling solution.  However,
 the automatic solutions also require a mechanism of bubbles to
 establish the initial path through a NAT.  This mechanism is not
 present in STUN.  It is not clear that a combination of STUN and a
 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 case for the development of four
 transition mechanism, covering the following 4 configurations:
  1. Configured tunnel over IPv4 in the absence of NAT;
  2. Automatic tunnel over IPv4 in the absence of NAT;
  3. Configured tunnel across a NAT;
  4. Automatic tunnel across a NAT.

Huitema, et al. Informational [Page 8] RFC 3904 Unmanaged Networks Transition Tools September 2004

 Teredo is an example of an already designed solution for automatic
 tunnels across a NAT; 6to4 is an example of a solution for automatic
 tunnels over IPv4 in the absence of NAT.
 All solutions should be designed to meet generic requirements such as
 security, scalability, support for reverse name lookup, or simple
 management.  In particular, automatic tunneling solutions may need to
 be augmented with a special purpose reverse DNS lookup mechanism,
 while configured tunnel solutions would benefit from an automatic
 service configuration mechanism.

3. Meeting Case A Requirements

 In case A, isolated hosts 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.

3.1. Evaluation of Connectivity Mechanisms

 In case A, IPv6 capable hosts seek IPv6 connectivity in order to
 communicate with applications in the global IPv6 Internet.  The
 connectivity requirement can be met using either configured tunnels
 or automatic tunnels.
 If the host is located behind a NAT, the tunneling technology should
 be designed to traverse NAT; tunneling technologies that do not
 support NAT traversal can obviously be used if the host is not
 located behind a NAT.
 When the local ISP is willing to provide a configured tunnel
 solution, we should make it easy for the host in case A to use it.
 The requirements for such a service will be presented in another
 document.
 An automatic solution like 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".

3.2. Security Considerations in Case A

 A characteristic of case A is that an isolated host 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 are only
 expected to serve local hosts, e.g., those located behind the NAT

Huitema, et al. Informational [Page 9] RFC 3904 Unmanaged Networks Transition Tools September 2004

 when a NAT is present.  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.  The users should be able to configure which
 applications get IPv6 connectivity to the Internet and which should
 not.
 Any solution to the NAT traversal problem is likely to involve
 relays.  There are concerns that improperly designed protocols or
 improperly managed relays could open new avenues for attacks against
 Internet services.  This issue should be addressed and mitigated in
 the design of the NAT traversal protocols and in the deployment
 guides for relays.

4. 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
 is preferable.

4.1. Connectivity

 The gateway must be able to acquire an IPv6 prefix, delegated by the
 ISP.  This can be done through explicit prefix delegation (e.g.,
 [DHCPV6, PREFIXDHCPV6]), or if the ISP is advertising a /64 prefix on
 the link, such a link can be extended by the use of an 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 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
 similar media (mainly, Ethernet segments).  On the other hand, an ND
 proxy must be used if a /64 prefix has to be shared across media
 (e.g., an upstream PPP link and a downstream Ethernet), or if an
 interface cannot be put into promiscuous mode (e.g., an upstream
 wireless link).
 Extending a single subnet to span from the ISP to all of the
 unmanaged network is not recommended, and prefix delegation should be
 used when available.  However, sometimes it is unavoidable.  In

Huitema, et al. Informational [Page 10] RFC 3904 Unmanaged Networks Transition Tools September 2004

 addition, sometimes it's necessary to extend a subnet in the
 unmanaged network, at the "customer-side" of the gateway, and
 changing the topology using routing might require too much expertise.
 The ND 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 [LLMNR] that rely on
 "link local multicast".  These effects need to 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 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.  It is expected that
 the ISP assigns a /48 to the customer.  The gateway should
 automatically assign /64s out of this /48 to its internal links.
 DHCP is insecure unless authentication is used.  This may be a
 particular problem if the link between gateway and ISP is shared by
 multiple subscribers.  DHCP specification includes authentication
 options, but the operational procedures for managing the keys and
 methods for sharing the required information between the customer and
 the ISP are unclear.  To be secure in such an environment in
 practice, the practical details of managing the DHCP authentication
 need to be analyzed.

4.1.3. Recommendation

 The ND proxy and DHCP methods appear to have complementary domains of
 application.  ND proxy is a simple method that corresponds well to
 the "informal sharing" of a link, while explicit delegation provides
 strong administrative control.  Both methods require development:
 specify the 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-
 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, 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 requires communication with

Huitema, et al. Informational [Page 11] RFC 3904 Unmanaged Networks Transition Tools September 2004

 IPv4-only hosts, this device implements an IPv4 stack.  The only
 devices that should have IPv6-only connectivity are those that are
 intended to only communicate with IPv6 hosts.

4.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.  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 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 DNS servers
 accessed over IPv4 can serve arbitrary DNS records, including AAAA
 records.
 Just using DHCPv4 will not be an adequate solution for IPv6-only
 local hosts.  The DHCP working group has defined how to use
 (stateless) DHCPv6 to obtain the 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 to the Internet

 IPv6 capable hosts may be willing to provide services accessible from
 the global Internet.  They will thus need to publish 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. Informational [Page 12] RFC 3904 Unmanaged Networks Transition Tools September 2004

 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 hexadecimal strings
 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 Dynamic DNS (DDNS).

4.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 4.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 4.3.1 will often be the
 address of the gateway itself, and the local server will thus be the
 gateway.
 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.  An 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 [NEIGHBOR]; the
 requirements of 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 IETF should quickly provide a recommended procedure for
 provisioning the DNS resolver in IPv6-only hosts.
 The most plausible candidate for local name resolution appears to be
 LLMNR; the IETF should quickly proceed to the standardization of that
 protocol.

Huitema, et al. Informational [Page 13] RFC 3904 Unmanaged Networks Transition Tools September 2004

4.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, e.g., a prefix advertised as "on link" in a local router
 advertisement.  There is a debate as to whether such restrictions
 should be "per-site" or "per-link", but this is not a serious issue
 when an unmanaged network is composed of a single link.

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

5.1. Connectivity

 Connectivity in case C requires some form of tunneling of IPv6 over
 IPv4.  The various tunneling solutions are discussed in 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 mechanism [TUNNELS], but as the local ISP is not
 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 augmented to include support
 for some form of automatic configuration.
 Due to concerns with potential overload of public 6to4 relays, the
 6to4 implementations should include a configuration option that
 allows the user to take advantage of specific relays.

6. Meeting the Case D Requirements

 In case D, the ISP only provides IPv6 services.

Huitema, et al. Informational [Page 14] RFC 3904 Unmanaged Networks Transition Tools September 2004

6.1. IPv6 Addressing Requirements

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

6.2. IPv4 Connectivity Requirements

 Local IPv4 capable hosts may still want to 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.  There
 are no standardized solutions and the IETF has devoted very little
 effort to this issue, although there is ongoing work with [DSTM] and
 [TSP].  A solution needs to be standardized.  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.

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.

7. Recommendations

 After a careful analysis of the possible solutions, we can list a set
 of recommendations for the V6OPS working group:
    1. To meet case A and case C requirements, we need to develop, or
       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,
       TSP], and configured tunnels with NAT traversal.
    2. To facilitate the use of configured tunnels, we need a
       standardized way for hosts or gateways to discover the tunnel
       server or tunnel broker that may have been configured by the
       local ISP.
    3. To meet case B "informal prefix sharing" requirements, we would
       need a standardized way to perform "ND proxy", possibly as part
       of a "multi-link subnet" specification.  (The explicit prefix
       delegation can be accomplished through [PREFIXDHCPV6].)
    4. To meet case B naming requirements, we need to proceed with the
       standardization of LLMNR.  (The provisioning of DNS parameters
       can be accomplished through [DNSDHCPV6].)

Huitema, et al. Informational [Page 15] RFC 3904 Unmanaged Networks Transition Tools September 2004

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

8. Security Considerations

 This memo describes the general requirements for transition
 mechanisms.  Specific security issues should be studied and addressed
 during the development of the specific mechanisms.
 When hosts which have been behind a NAT are exposed to IPv6, the
 security assumptions may change radically.  This is mentioned in
 sections 3.2 and 4.4.  One way to cope with that is to have a default
 firewall with a NAT-like access configuration; however, any such
 firewall configuration should allow for easy authorization of those
 applications that actually need global connectivity.  One might also
 restrict applications which can benefit from global IPv6 connectivity
 on the nodes.
 Security policies should be consistent between IPv4 and IPv6.  A
 policy which prevents use of v6 while allowing v4 will discourage
 migration to v6 without significantly improving security.  Developers
 and administrators should make sure that global Internet connectivity
 through either IPv4 or IPv6 is restricted to only those applications
 that are expressly designed for global Internet connectivity.
 Several transition technologies require relays.  There are concerns
 that improperly designed protocols or improperly managed relays could
 open new avenues for attacks against Internet services.  This issue
 should be addressed and mitigated in the design of the transition
 technologies and in the deployment guides for relays.

9. Acknowledgements

 This memo has benefited from the comments of Margaret Wasserman,
 Pekka Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms,
 Bill Sommerfeld, and Fred Templin.  Tim Chown provided a lot of the
 analysis for the tunneling requirements work.

10. References

10.1. Normative References

 [UNMANREQ]     Huitema, C., Austein, R., Satapati, S., and R. van der
                Pol, "Unmanaged Networks IPv6 Transition Scenarios",
                RFC 3750, April 2004.

Huitema, et al. Informational [Page 16] RFC 3904 Unmanaged Networks Transition Tools September 2004

 [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.
 [6TO4]         Carpenter, B. and K. Moore, "Connection of IPv6
                Domains via IPv4 Clouds", RFC 3056, February 2001.
 [6TO4ANYCAST]  Huitema, C., "An Anycast Prefix for 6to4 Relay
                Routers", RFC 3068, June 2001.
 [TUNNELS]      Durand, A., Fasano, P., Guardini, I., and D. Lento,
                "IPv6 Tunnel Broker", RFC 3053, January 2001.
 [DHCPV6]       Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                C., and M. Carney, "Dynamic Host Configuration
                Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
 [DNSDHCPV6]    Droms, R., "DNS Configuration options for Dynamic Host
                Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
                December 2003.
 [PREFIXDHCPV6] Troan, O. and R. Droms, "IPv6 Prefix Options for
                Dynamic Host Configuration Protocol (DHCP) version 6",
                RFC 3633, December 2003.

10.2. Informative References

 [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 IPv6 DNS", Work in
                Progress.
 [LLMNR]        Esibov, L., Aboba, B., and D. Thaler, "Linklocal
                Multicast Name Resolution (LLMNR)", Work in Progress.
 [TSP]          Blanchet, M., "IPv6 Tunnel Broker with the Tunnel
                Setup Protocol(TSP)", Work in Progress.
 [DSTM]         Bound, J., "Dual Stack Transition Mechanism", Work in
                Progress.

Huitema, et al. Informational [Page 17] RFC 3904 Unmanaged Networks Transition Tools September 2004

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

11. Authors' Addresses

 Christian Huitema
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052-6399
 EMail: huitema@microsoft.com
 Rob Austein
 Internet Systems Consortium
 950 Charter Street
 Redwood City, CA 94063
 USA
 EMail: sra@isc.org
 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. Informational [Page 18] RFC 3904 Unmanaged Networks Transition Tools September 2004

12. Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the IETF's procedures with respect to rights in IETF Documents can
 be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Huitema, et al. Informational [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3904.txt · Last modified: 2004/09/24 17:51 (external edit)