Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET
Expires: August 30, 2004 J. Soininen
Nokia
Mar 2004
Evaluation of v6ops Tunneling Scenarios and Mechanisms
draft-savola-v6ops-tunneling-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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 August 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo analyses the v6ops scenarios/analysis work (Unmanaged,
3GPP, ISP and Enterprise) for their requirements for tunneling
solutions, and analyses the proposed mechanisms on how they might fit
in these requirements, and discusses possibilities for choosing
solution(s).
Savola & Soininen Expires August 30, 2004 [Page 1]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Selection Process . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 3GPP Networks . . . . . . . . . . . . . . . . . . . . . 3
3.2 Unmanaged Networks . . . . . . . . . . . . . . . . . . . 4
3.3 Enterprise Scenarios . . . . . . . . . . . . . . . . . . 5
3.4 ISP Scenarios . . . . . . . . . . . . . . . . . . . . . 5
3.5 Additional Scenarios: IP Mobility . . . . . . . . . . . 6
4. Scenarios and Mechanisms Evaluation . . . . . . . . . . . . . 6
4.1 Scenarios Evaluation . . . . . . . . . . . . . . . . . . 6
4.2 Mechanisms Evaluation . . . . . . . . . . . . . . . . . 7
4.3 Evaluation Summary . . . . . . . . . . . . . . . . . . . 8
4.4 Features of the Mechanisms . . . . . . . . . . . . . . . 8
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 10
Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Savola & Soininen Expires August 30, 2004 [Page 2]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
1. Introduction
This memo analyzes the v6ops scenarios/analysis work (Unmanaged [1],
3GPP [2], ISP [3], Enterprise [4]) at a bit more length, summarizes
the exact requirements for tunneling in the scenarios, and analyzes
how different mechanisms would fit into those specific tunneling
requirements.
The mechanisms analyzed in this document are Teredo [5], ISATAP [6],
STEP [7], and TSP [8]. Already-specified, and in many cases
applicable tunneling mechanisms are 6to4 [9] and configured tunneling
[10].
2. The Selection Process
It is strongly desirable to be able to recommend as few mechanisms as
reasonably possible. This is an important tradeoff to consider.
However, it is likely that one has to give up some features to
achieve that goal.
However, it is recognized that there are implementations out there:
therefore, one can submit I-Ds specifying currently implemented (but
only that; no additions) mechanisms to RFC-editor as invidial
contributions for Informational or Experimental RFC. These documents
will include a clear IESG Note and/or an applicability statement that
these are not recommended mechanisms. The goal of this process is to
improve interoperability of the implementations that already exist,
and some have deemed fit to implement. XXX: anything about the
timing when these can be submitted to the RFC-editor?
3. Scenarios
This section described the specific cases indentified inside the
scenarios where a form of tunneling is desirable.
3.1 3GPP Networks
There are two closely related cases:
1. Providing IPv6 connectivity to User Equipment (UE) when it roams
to an another operator's network, and the other operator does not
support IPv6 PDP contexts.
2. Providing IPv6 connectivity to UEs when the "home" 3GPP operator
has not deployed even minimal IPv6 PDP context support yet in its
network -- but would like to enable IPv6 connectivity through a
transition mechanism which can be transparently overlayed on the
existing IPv4 3GPP network.
Savola & Soininen Expires August 30, 2004 [Page 3]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
Note that the current document strongly recommends at least initial
IPv6 PDP context support: this only requires support from HLR, SGSN
and one GGSN.
The case where there is no IPv6 connectivity at all in the 3GPP
network is considered out of scope (but a solution can be achieved
using one of the Unmanaged connectivity mechanisms if appropriate).
In this scenario, it is assumed that the users are typically using
private IPv4 addresses, but there is no NAT in the path between the
different users in the same 3GPP network.
There are a couple of differences with the two cases described above:
in the first case, the operator has deployed IPv6 PDP context
support, as recommended, but some other ISP has not: waiting for all
the operators to deploy IPv6 PDP context support prior to launching
the service would be unacceptable -- so there has to be a solution to
this. Also, note that the tunnel from the foreign 3GPP network is
terminated at the local 3GPP operator's network, inducing delay and a
bottle-neck; "direct connectivity" optimization is not much different
whether the tunnel would be terminated at a tunnel server, or
communicating directly. In the second case, one could argue that the
deployment should only be temporary, with at least minimal IPv6 PDP
context support being the goal.
In any case, the critical question in this specific scenario is, how
desirable is it to have direct tunneling between the UEs in the same
3GPP network -- instead of a slightly longer "leg" through a tunnel
server? Clearly, this would be desirable -- but not a strict
requirement.
3.2 Unmanaged Networks
The unmanaged scenarios seem to include two cases, with a subcase,
totalling 3 different cases.
1. When the user's direct ISP does not offer any IPv6 service at
all, and connectivity must be obtained automatically.
1. When the connectivity must be obtained with as little
infrastructure as possible, without any signups or contracts,
etc.
2. When the connectivity can be obtained from a third party,
through a sign-up, contract, etc. -- for higher
manageability, more control, increased security benefits, or
for other reasons. (Whether such "3rd party connectivity" is
feasible or good enough is a separate question.)
Savola & Soininen Expires August 30, 2004 [Page 4]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
2. When the user's direct ISP would like to offer IPv6 service, but
would require tunneling for some reason (e.g., access router,
access link, or the gateway in the unmanaged network is incapable
of IPv6). In this case the options are basically tunneling from
the gateway, a separate IPv6 gateway or tunneling from the
host(s).
It should be noted that a solution to problem 1.2) would solve
problem 2) as well, but a solution to problem 2) would not
necessarily be adequate for solving 1.2).
NAT traversal must be supported. Dynamic IPv4 addresses must be
supported -- but the solution does not necessarily have to be better
than dynamic IPv4 addresses are today; e.g., a dynamic IPv6 address
would be acceptable as well.
It seems obvious that direct tunneling between users is required at
least when there is no ISP support -- to minimize the latency
increase, and to decrease the bandwidth aggregation. However, it is
not a strict requirement with hosts in the same ISP: in such a case,
the slight increase in latency and concentration of traffic is
probably manageable.
One should note that direct connectivity that traverses NATs, as is
requirement here, is a very difficult thing to do right; essentially,
this is what Teredo is doing. On the other hand, if the ISP is
offering service which does not provide direct connectivity between
hosts, the use of another mechanism (such as 6to4 or Teredo) "on the
side" could perhaps provide at least partial direct connectivity.
3.3 Enterprise Scenarios
This scenario/analysis work is still incomplete, so it is not fully
addressed in this memo.
The only scenario which is obvious at the moment is when the
enterprise wishes to deploy IPv6 without changing the gear to be
dual-stack, without injecting IPv6 into existing VLANs, or without
adding additional IPv6 routers in the VLANs. In particular, this may
be the case when the IPv6 deployment is "sparse" -- because if it was
sufficiently "dense", it would make sense to expand the
infrastructure in one of the several ways. It would be nice if the
tunneling between the nodes is direct from node-to-node, but this is
not a strict requirement.
3.4 ISP Scenarios
ISPs do not have specific scenarios which need to be addresses which
Savola & Soininen Expires August 30, 2004 [Page 5]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
haven't been already mentioned: some ISPs want to provide IPv6
connectivity, possibly over a tunnel, to their unmanaged or
enterprise customers, or ISPs. However, these requirements have
already been discussed; only two particular considerations should be
explicitly mentioned: 1) mechanisms used must be very simple if we
want them to be adopted by many ISPs, and 2) very few ISPs want to be
providing service, for free at least, to the users which are not
their customers.
3.5 Additional Scenarios: IP Mobility
Recently, there some concerns have been raised about additional
scenarios work, which might be partially worked under v6ops WG. One
such is work on the scenarios where IP nodes are not stationary,
i.e., are expected to change IPv4 or IPv6 address relatively rapidly.
In many cases this implies that either MIPv4 or MIPv6 is being run to
ensure a relatively stable IP address being available, and to make
the changes in IP addresses as transparent as possible.
This is not a formal scenario as such, but in these events it would
be extremely desirable to have minimal amount of signalling when the
attachment point (whether a care-of or home address) changes -- to
ensure seamless IP mobility.
4. Scenarios and Mechanisms Evaluation
4.1 Scenarios Evaluation
NAT-T Direct ISP Secure Simple Low
Overhead
Unman 1.1 * * N - - -
Unman 1.2 * N * -/* - -
Unman 2 * - * - * -
3GPP 1 N -/* * - * *
3GPP 2 N -/* * - * *
Legend: * = MUST; - = Nice to have; N = No
NAT traversal specifies whether NAT traversal is a requirement.
Direct tunneling states whether direct tunneling between the nodes
using the same mechanism is a requirement.
ISP support indicates whether the mechanism must be able to operate
(at least to a degree) without explicit support from an ISP.
"Secure" is an overly simplistic term to evaluate whether the
scenario requires some specific amount of security. Here, security
Savola & Soininen Expires August 30, 2004 [Page 6]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
implies security issues which may not be trivially fixable, whether
the operational mode or in the mechanism, such that it is difficult
to secure, whether it creates new significant threats to either IPv4
or IPv6 infrastructures, etc.
Simple is a term which refers to the simplicity of the protocol or
the operational model in which it operates; simple protocols and
specifications are easy to understand, evaluate, implement, and
deploy, and thus preferable to more complex ones.
"Low overhead" refers to both minimal encapsulation -- as few added
bytes in the messages or signalling as possible -- and signalling
latency (e.g., the number of messages/round-trips to set-up, change,
or tear down a tunnel).
4.2 Mechanisms Evaluation
One should note that we are not evaluating the specific version of
the specification, but rather the mechanism in a more generic sense
("which features could this mechanism easily be made to work with?").
NAT-T Direct ISP Secure Simple Low Impl. Depl.
Overhead
Teredo Y Y N Y N N R Y
ISATAP N Y@ Y N/R R Y Y R?
TSP Y N Y? Y R N R R?
STEP Y N Y Y Y/R Y N N
@: intra-site, no NATs in the path
Legend: Y = Yes; R = Relatively good; N = No
NAT traversal states whether the mechanism is able to perform full
NAT traversal.
Direct tunneling states whether the mechanism is able to provide
direct tunneling between the nodes using the same mechanism.
ISP support indicates whether the mechanism is able to operate (at
least to a degree) without explicit support from an ISP.
"Secure" is an overly simplistic term to evaluate whether the
mechanism has obvious security issues which may not be trivially
fixable, whether the operational mode or in the mechanism, such that
it is difficult to secure, whether it creates new significant threats
to either IPv4 or IPv6 infrastructures, etc.
Simple is a term which refers to the simplicity of the protocol or
Savola & Soininen Expires August 30, 2004 [Page 7]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
the operational model in which it operates; simple protocols and
specifications are easy to understand, evaluate, implement, and
deploy, and thus preferable to more complex ones.
"Low overhead" refers to both minimal encapsulation -- as few added
bytes in the messages or signalling as possible -- and signalling
latency (e.g., the number of messages/round-trips to set-up, change,
or tear down a tunnel).
Implemented refers how widely the mechanism has been implemented
(e.g., no implementations, one implementation, multiple interoperable
implementations), and how large part of the mechanism has been
implemented.
"Widely deployed" refers to how widely the mechanism has been
deployed: is it in use as deployed by multiple vendors, or in many
operational scenarios?
4.3 Evaluation Summary
By combining the two matrices, we obtain the following:
o Unmanaged scenario 1.1) requires Teredo.
o Unmanaged 1.2) and 2) require STEP or TSP.
o 3GPP 1) can be filled by STEP or ISATAP; if a higher level of
security is required, ISATAP may not be applicable.
o 3GPP 2) can be filled by STEP or ISATAP; only ISATAP if direct
tunneling is a MUST requirement.
Therefore we get that Teredo and STEP is the lowest common
denominator, after having to take a few tough issues in the
consideration, with Teredo and TSP coming somewhat behind.
Actually, it would be preferable in some sense to combine TSP and
STEP as they are best applicable in quite similar scenarios. This
might allow one to combine the best features of both proposals.
4.4 Features of the Mechanisms
If we would assume that we'd prefer to recommend two solutions, in
addition to 6to4 and configured tunneling, which are already there,
we would have to judge, based on the scenario requirements, three
critical features:
1. NAT traversal
Savola & Soininen Expires August 30, 2004 [Page 8]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
2. Direct connectivity inside a site/ISP/enterprise
3. Operation with third party ISPs
In several scenarios, it's impossible to have both 1) and 2) without
a relatively complex solution. Similarly, there is often a conflict
with 2) and 3).
Therefore, we must be able to make a decision which features/
requirements we are willing to give up in which specific scenarios,
or whether we have to specify more mechanism to satisfy all the
features.
For example, by picking Teredo and {TSP or STEP}, we would have to
give up direct connectivity inside the 3GPP, Enterprise and the
unmanaged scenarios where the ISP is offering service -- except where
it would automatically come along where Teredo (or 6to4) service is
active in any case.
On the other hand, ISATAP is unable to properly perform NAT
traversal, and it is not designed to securely interact with third
party ISPs. By picking Teredo and ISATAP, we would not have a
solution to operate with 3rd party ISPs, ISPs which do not properly
secure their borders, or in the cases where NAT traversal is required
and Teredo is seen as too cumbersome a choice. However, Teredo does
provide a means to interoperate with a specifically crafted,
simplistic Tunnel Server implementation; if we assume that it would
be acceptable to recommend implementation and deployment of Teredo to
be able to use a tunnel server service, implementing a stub tunnel
server could provide a means to achieve support in the 3rd party ISP
case.
As Teredo is the only solution available for scenario 1.1), it seems
that it cannot be left out.
5. Conclusions
TBD.
6. Security Considerations
This memo analyses the tunneling scenario requirements and mechanisms
trying to address these requirements. As such, it does not have
significant security considerations. When considering which
mechanism(s) to adopt, the security properties of the mechanisms vary
considerably -- and this has to be taken in consideration in the
evaluation and selection. However, mechanism-specific considerations
are to be addressed in the respective documents.
Savola & Soininen Expires August 30, 2004 [Page 9]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
7. Acknowledgements
This memo was written from scratch at IETF59, and it has been
improved based on feedback received both prior, during, and after the
session by numerous people.
Normative References
[1] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged
Networks", draft-ietf-v6ops-unmaneval-01 (work in progress),
February 2004.
[2] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks",
draft-ietf-v6ops-3gpp-analysis-08 (work in progress), January
2004.
[3] Lind, M., "Scenarios and Analysis for Introducing IPv6 into ISP
Networks", draft-ietf-v6ops-isp-scenarios-analysis-01 (work in
progress), February 2004.
[4] Bound, J., "IPv6 Enterprise Network Scenarios",
draft-ietf-v6ops-ent-scenarios-01 (work in progress), February
2004.
[5] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
draft-huitema-v6ops-teredo-01 (work in progress), February 2004.
[6] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)",
draft-ietf-ngtrans-isatap-20 (work in progress), February 2004.
[7] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure
(STEP)", draft-savola-v6ops-conftun-setup-02 (work in progress),
January 2004.
[8] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup
Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00 (work
in progress), February 2004.
Informative References
[9] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-02 (work in
progress), February 2004.
Savola & Soininen Expires August 30, 2004 [Page 10]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
Authors' Addresses
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail: psavola@funet.fi
Jonne Soininen
Nokia
EMail: jonne.soininen@nokia.com
Savola & Soininen Expires August 30, 2004 [Page 11]
Internet-Draft Evaluation of v6ops Tunneling Mar 2004
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Savola & Soininen Expires August 30, 2004 [Page 12]