[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
IPv6 Operations                                                 T. Chown
Internet-Draft                                 University of Southampton
Expires: April 19, 2004                                   R. van der Pol
                                                              NLnet Labs
                                                               P. Savola
                                                               CSC/FUNET
                                                        October 20, 2003


     Considerations for IPv6 Tunneling Solutions in Small End Sites
              draft-chown-v6ops-unmanaged-connectivity-00

Status of this Memo

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

   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.

   This Internet-Draft will expire on April 19, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   Tunneling IPv6 packets over the IPv4 Internet played a major role in
   the early stages of IPv6 deployment. This was useful because in the
   early days the routers in the internet did not support IPv6.
   Nowadays, tunneling is used to get across legacy equipment and ISPs
   that do not support IPv6. Many different tunneling mechanisms have
   been invented. This document describes the drivers for IPv6
   tunneling, the general architectures of existing mechanisms, and a
   set of desirable properties against which subsequent analysis of the
   mechanisms may be made.   The document is aimed at small end sites



Chown, et al.            Expires April 19, 2004                 [Page 1]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


   that may typically utilise tunneling methods in an early IPv6
   deployment.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Motivations for Tunneling  . . . . . . . . . . . . . . . . .   5
   2.1  Using Tunneling To Circumvent Legacy ISPs  . . . . . . . . .   5
   2.2  Using Tunneling To Get Across Legacy NAT Boxes . . . . . . .   5
   3.   Tunneling Architectures  . . . . . . . . . . . . . . . . . .   6
   3.1  Configuration Aspects Of Tunneling Mechanisms  . . . . . . .   6
   3.2  Traffic Concentration  . . . . . . . . . . . . . . . . . . .   6
   3.3  (Un)managed and Dynamic/Fixed Tunneling  . . . . . . . . . .   7
   4.   Desirable Properties of Tunneling Solutions  . . . . . . . .   8
   4.1  Security . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.2  Simplicity . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.3  Ease of Management . . . . . . . . . . . . . . . . . . . . .   8
   4.4  Handling Dynamic IPv4 Addresses  . . . . . . . . . . . . . .   8
   4.5  Support for Hosts or Sites . . . . . . . . . . . . . . . . .   9
   4.6  Scalability  . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.7  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . .   9
   4.8  Can be Used Behind a NAT . . . . . . . . . . . . . . . . . .   9
   4.9  Tunnel Service Ownership . . . . . . . . . . . . . . . . . .   9
   4.10 Tunnel Service Discovery . . . . . . . . . . . . . . . . . .  10
   4.11 Support for Special Services . . . . . . . . . . . . . . . .  10
   4.12 Route Optimisation . . . . . . . . . . . . . . . . . . . . .  10
   4.13 Reverse DNS Lookups Available  . . . . . . . . . . . . . . .  10
   4.14 Accountability . . . . . . . . . . . . . . . . . . . . . . .  10
   5.   Summary  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.   Security Considerations  . . . . . . . . . . . . . . . . . .  12
        Informative References . . . . . . . . . . . . . . . . . . .  13
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  13
        Intellectual Property and Copyright Statements . . . . . . .  15


















Chown, et al.            Expires April 19, 2004                 [Page 2]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


1. Introduction

   Tunneling IPv6 packets over the IPv4 Internet played a major role in
   the early stages of IPv6 deployment. The 6bone testbed made extensive
   use of encapsulating IPv6 packets in IPv4 [1]. This was useful
   because in the early days the routers in the Internet did not support
   IPv6 and tunneling made it possible to build a virtual worldwide IPv6
   network without changes to the IPv4 production routers and to
   experiment with the IPv6 protocol.

   Nowadays, tunneling is used to get across legacy equipment and ISPs
   that do not support IPv6. This document describes the motivations for
   IPv6 tunneling, the general architectures of existing mechanisms, and
   a set of desirable properties against which subsequent analysis of
   the mechanisms may be made.   The document is aimed at small end
   sites that may typically utilise tunneling methods in an early IPv6
   deployment.

   A number of tunneling solutions have been devised, and continue to be
   devised.  While ultimately when consumers really need IPv6 the ISPs
   are very likely to then offer a native service, at present the
   perceived demand at the ISPs is low, thus those sites wanting early
   connectivity need tunneling methods. It can be argued that we should
   not try to force IPv6 deployment by inventing complex protocols and
   setups that are difficult to manage.   Similarly the very presence of
   automatic mechanisms, typically not provided by the ISP in question,
   may reduce the ISPs' perceived customer demand even further.

   We also note that some ISP practices will make the deployment of
   tunneling solutions more difficult, e.g. the use of dynamic IPv4
   address allocations to customers.   This document recognises the need
   to consider current operational practices, so that the
   recommendations we may base upon the considerations in this document,
   and the assumptions we make, may be more likely to be useful.

   The goal of this document is to enable a trade-off analysis for
   existing mechanisms that may include but not be limited to:

   o  Tunnel broker [2], with TSP [5]

   o  6to4 [3]

   o  Teredo [4]

   in addition to as yet undefined mechanisms or minor modifications or
   extensions to current mechanisms.  In this document, rather than
   compare specific methods, we refer to the general methods, e.g. of a
   "6to4-like" service.



Chown, et al.            Expires April 19, 2004                 [Page 3]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


   We aim to keep the analysis logically different from this
   considerations document.  We do not want to be solution-centric,
   rather problem-centric. Analysis should be done in a separate
   document.















































Chown, et al.            Expires April 19, 2004                 [Page 4]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


2. Motivations for Tunneling

   Most tunneling mechanisms are intended for use in the early stages of
   IPv6 deployment. Some try to bypass IPv4-only ISPs that do not offer
   IPv6 services.  Others try to bypass NAT boxes that do not support
   IPv6, while also bypassing the ISPs which do not offer IPv6 services
   (tackling both problems in one). Mechanisms only passing the NAT box
   seem rather rare. None of the mechanisms are needed when the ISP
   starts offering IPv6 services or when the NAT box is replaced by an
   IPv6-aware box.

   When considering the various tunneling mechanisms it is important to
   know what problem they try to solve.  Most do not seem to solve real
   technical problems as such, and are instead a workaround for a lack
   of native IPv6 deployment. The tradeoff between (possibly complex)
   tunneling mechanisms and waiting for IPv6 deployment should be
   carefully analysed.  Similarly, the cost to an ISP of supporting
   "early adopter" tunneling services as opposed to deploying a pilot
   native service should be considered.   However, the reality is that
   tunneling solutions will be an important tool for the introduction of
   IPv6 services for some time to come, hence this document focuses on
   desirable properties for such solutions.

2.1 Using Tunneling To Circumvent Legacy ISPs

   Tunneling can be used to get IPv6 connectivity across ISPs that do
   not offer IPv6 yet. Ideally a customer's ISP would offer them a
   native IPv6 service.   However, in the absence of such a native IPv6
   service a tunneled solution is the only real option for an early
   adopter of IPv6.   We thus need to consider the desirable properties
   of such a tunneled solution.

2.2 Using Tunneling To Get Across Legacy NAT Boxes

   Tunneling can also be used to get across legacy equipment (e.g. a
   SOHO router) that does not support IPv6 yet. When ISPs start to offer
   a native IPv6 service on a large scale, SOHO router manufacturers are
   likely to introduce IPv6-enabled SOHO routers.   In the meantime,
   many customers will require some method to gain an IPv6 service in
   the presence of a NAT.   While trying to invent a complex protocol to
   try to send IPv6 traffic at any cost is probably not the best
   technical solution, it is one of necessity.

   In such a situation ownership and access to the configuration of the
   NAT device is an issue.  Where ownership is held by the customer,
   they have the technical knowledge, and have only one internal host or
   network to establish a tunnel to, Protcol 41 forwarding [6] may
   enable a tunnel to pass through such a NAT.



Chown, et al.            Expires April 19, 2004                 [Page 5]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


3. Tunneling Architectures

   The examples of specific existing solutions listed in the
   Introduction can be generalised, e.g.:

   o  A tunnel brokering service by which a host or network may obtain a
      tunnel service by a one-time interaction which leads to the
      establishment of a tunnel service to a tunnel concentrator, and
      from there to the wider IPv6 internet. The tunnel concentrator may
      reside either at a local or remote ISP. A NAT traversal may also
      be included, using an additional encapsulation.  Tunnel brokering
      services may use a tunnel setup protocol for ease of management,
      whereby tunnels are set up automatically and the mechanism has the
      possibility of authentication.

   o  An automatic tunneling service by which a host or network may
      obtain an automatic tunnel service to any other host or site
      supporting the same service.  While such traffic does not require
      use of a concentrator, connectivity to the native IPv6 internet
      requires use of such a relay.

   o  A NAT traversal service by which a host behind an IPv4 NAT may
      gain tunneled connectivity to the external IPv6 internet by way of
      a tunnel concentrator or server, while a part of communications
      between the service's users is designed to go directly via
      "short-cuts".

   By these general descriptions we can refer to, for example, a "tunnel
   broker-like" service. Each mechanism may have a different philosophy,
   but each may also target a different problem (e.g. NAT traversal).
   Each will have a different architecture.

3.1 Configuration Aspects Of Tunneling Mechanisms

   Tunneling always involves encapsulating at one end of the tunnel and
   decapsulating at the other end of the tunnel. When encapsulating, the
   IPv4 address of the other side of the tunnel is needed. For some
   mechanisms this information needs to be configured manually. For
   other mechanisms the information is obtained via a special protocol
   (e.g. TSP [5]), one time setup (e.g. manually configured tunnel
   broker) or automatically (e.g.  6to4 [3]). Tunnels can be either
   unidirectional or bi-directional.

3.2 Traffic Concentration

   Some tunneling mechanisms send all traffic to the same tunnel
   end-point. This end-point acts as a concentration point. Other
   tunneling mechanisms use a tunnel end-point based on the destination



Chown, et al.            Expires April 19, 2004                 [Page 6]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


   of the traffic. They send traffic over the same path as the IPv4
   traffic. In this case there is no concentration point.

   The use of concentrator points will have implications for the
   scalability of the solution, and may also raise concerns over the
   point of failure it represents (especially where denial of service
   attacks may be directed at that point).  However, a seemingly
   de-centralized model (e.g. deployment using anycast) may in fact also
   practically incur traffic concentration problems if only a small
   amount of concentrators are being used.

3.3 (Un)managed and Dynamic/Fixed Tunneling

   There is a subtle distinction between managed or unmanaged and manual
   or automatic tunnel services.   The distinction from the point of
   view of the tunnel is that it may be fixed (to a pre-configured
   remote IPv4 address) or dynamic (the tunnel is established on demand
   to any given remote IPv4 address, whereby the remote IPv4 address is
   based on the packet destination address and each destination has its
   own remote IPv4 address). Either the fixed or dynamic tunnels may be
   managed or unmanaged, although all dynamic mechanisms are unmanaged.






























Chown, et al.            Expires April 19, 2004                 [Page 7]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


4. Desirable Properties of Tunneling Solutions

   In this section we list the desirable properties that a tunnel
   service may have, from the view of the customer, the ISP, or both the
   customer and ISP.  We do not categorise them as such at this point,
   but may do so in a future revision of this document if it is deemed
   useful to do so; such a future revision may also go into further
   discussion of tradeoffs rather than purelybeing a list of desirable
   properties.

   Note that it is unlikely that a single tunnel solution will meet all
   the desirable properties below.  The properties are merely intended
   to be a yardstick to analyse existing and future solutions against.
   They are not meant to be an all-or-nothing set of requirements.

   The list is in no particular order of importance.

4.1 Security

   There are a number of IPv6 transition-specific issues.  The tunnel
   solution should address these, e.g. the tunnel decapsulators must be
   able to verify that the packets being decapsulated come from a valid
   tunnel-endpoint.  This probably implies bidirectional tunneling and
   some kind of authentication payload.

   Consideration for detection or prevention of (distributed)
   denial-of-service attacks should also be made.

4.2 Simplicity

   A simpler solution should be favoured over a complex one.

4.3 Ease of Management

   The tunnel service should be as easy to manage as possible. For the
   ISP it should thus have minimal configuration load, and it should be
   manageable within the management framework deployed by the ISP.
   Faults should be easy to troubleshoot from the ISP or customer side.

4.4 Handling Dynamic IPv4 Addresses

   The solution should be able to handle the customer-side IPv4 tunnel
   end point address changing, as will be the case where the customer is
   with an ISP that applies a dynamic address assignment policy.
   Ideally the customer should not have to enter a new (one-time) setup
   process each time their ISP-assigned IPv4 address changes. For
   example, a "tunnel brokering"-like solution with good authentication
   may be able to meet this requirement.



Chown, et al.            Expires April 19, 2004                 [Page 8]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


4.5 Support for Hosts or Sites

   The tunnel service should support one host or a site network (/48).
   If it supports a network, it may also be beneficial to support prefix
   delegation (or at least getting a /48).

4.6 Scalability

   All solutions should be scalable, to handle a significant number of
   customer end-points.   This consideration may be more acute where a
   relay or concentrator is "open" and perhaps anonymous, rather than
   restricted to the customers of the ISP, such that "open" or anonymous
   mechanisms are harder to limit.

4.7 NAT Traversal

   The mechanism should be able to traverse a NAT, for end customers who
   have their IPv4 systems behind an IPv4 NAT device.   It may be that
   the solution co-exists on a NAT device or router, with the clients
   behind the NAT using native IPv6 to such a router and IPv4 NAT in
   parallel.

   An important question is also which kinds of NAT boxes one should be
   able to traverse.  One should probably also consider whether it's an
   "IPv4" NAT traversal mechanism or an "IPv6" mechanism. There are many
   IPv4 NAT traversal mechanisms; thus one may ask whether these need
   re-invention, especially when they are already complex.

4.8 Can be Used Behind a NAT

   Some ISPs may only give their customers private addresses, to which
   NAT will be applied somewhere in the ISP's network (e.g., GPRS
   networks, some xDSL networks).  This is a subscenario of NAT
   traversal.  In some cases the ISP might be willing to provide IPv6
   service to these users; the mechanism may not need to be able to
   traverse a NAT, but at least function behind one.

4.9 Tunnel Service Ownership

   It is desirable that each ISP implement their own tunnel service. It
   may also be advantageous to the customer that their IPv4 ISP offers
   IPv6 tunnel services as well.   We may not even be able to assume
   that the customer gets their IPv6 service from a specific ISP, rather
   than just from an anonymous service somewhere.   However, the user
   may not have control over which anonymous service they use, or that
   it may be local to their network, e.g. where selection of the service
   is automatic and based on a publicly advertised anycast address from
   some remote ISP.   In such a case the relay may be far away in terms



Chown, et al.            Expires April 19, 2004                 [Page 9]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


   of RTT and be loaded with many other customers who (probably
   automatically) select that service.

4.10 Tunnel Service Discovery

   The customer should have some method for discovering the location
   and/or configuration for the tunnel service as transparently as
   possible. Such service discovery would be ideal, perhaps making use
   of a feature like anycast.

   If such a transparent system is not possible, the solution should
   involve only a one-time setup (as would be the case for VPN creation,
   or DSL dial-up parameters).

4.11 Support for Special Services

   The tunnel mechanism (as opposed to the service) may need to support
   special functions for the customer, e.g. IPv6 Multicast.  Route
   optimization or NBMA links may typically eliminate the possibility
   without significant added complexity, while a plain bidirectional
   tunnel will probably be fine.

4.12 Route Optimisation

   The tunnel service should ideally offer no worse routing for the IPv6
   tunnel than the best IPv4 path between two sites.   If customers
   perceive higher round trip time or latency for a tunneled IPv6
   service, they will not wish to adopt the new protocol.   It may be
   desirable for the mechanism should create "short cuts" between two
   parties which implement the same mechanism.

4.13 Reverse DNS Lookups Available

   Some network services use reverse DNS lookups as a (weak)
   authentication mechanism.  The tunnel service should thus offer an
   IPv6 address or prefix to the customer against which a reverse DNS
   entry can be configured (ideally by the customer, failing that by the
   ISP, but anonymous services may fail to meet this requirement).

4.14 Accountability

   If the solution uses the prefix of the ISP who offers the service,
   the return routing is simplifed, but also some level of
   accountability exists. However, we need to consider whether we need a
   solution which can be offered anonymously by ISPs which don"t want to
   provide tunnel brokers with their own addresses.





Chown, et al.            Expires April 19, 2004                [Page 10]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


5. Summary

   This document consdiers the motivations for deployment of tunneled
   IPv6 connectivity solutions for small end sites.  It outlines
   existing architectures and lists a condidate set of desirable
   properties against which existing or emerging tunnel solutions may be
   analysed.  That analysis should be undertaken in a subsequent
   document.











































Chown, et al.            Expires April 19, 2004                [Page 11]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


6. Security Considerations

   This draft analyses tunneling mechanisms and requirements. It does
   not raise any new security issues.















































Chown, et al.            Expires April 19, 2004                [Page 12]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


Informative References

   [1]  Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
        Specification", RFC 2473, December 1998.

   [2]  Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
        Broker", RFC 3053, January 2001.

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

   [4]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
        draft-huitema-v6ops-teredo-00 (work in progress), June 2003.

   [5]  Blanchet, M., "Tunnel Setup Protocol (TSP)A Control Protocol to
        Setup IPv6 or IPv4  Tunnels", draft-vg-ngtrans-tsp-01 (work in
        progress), July 2002.

   [6]  Palet, J., "Forwarding Protocol 41 in NAT Boxes",
        draft-palet-v6ops-proto41-nat-01 (work in progress), July 2003.


Authors' Addresses

   Tim Chown
   University of Southampton

   School of Electronics and Computer Science
   Southampton, Hampshire  SO17 1BJ
   United Kingdom

   EMail: tjc@ecs.soton.ac.uk


   Ronald van der Pol
   NLnet Labs
   Kruislaan 419
   Amsterdam,   1098 VA
   Netherlands

   EMail: Ronald.vanderPol@nlnetlabs.nl










Chown, et al.            Expires April 19, 2004                [Page 13]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


   Pekka Savola
   CSC/FUNET

   Espoo,
   Finland

   EMail: psavola@funet.fi












































Chown, et al.            Expires April 19, 2004                [Page 14]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


Intellectual Property Statement

   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 of the 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 implementors 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.


Full Copyright Statement

   Copyright (C) The Internet Society (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



Chown, et al.            Expires April 19, 2004                [Page 15]


Internet-Draft     IPv6 Tunneling in Small End Sites        October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Chown, et al.            Expires April 19, 2004                [Page 16]