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]