[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-suryanarayanan-v6ops-zeroconf-reqs)
00
Internet Engineering Task Force J. Palet
Internet-Draft Consulintel
Expires: August 18, 2005 K. Nielsen
Ericsson
F. Parent
Hexago
A. Durand
Sun Microsystems, inc.
R. Suryanarayanan
Samsung India Software Operations
P. Savola
CSC/FUNET
February 14, 2005
Goals for Tunneling Configuration
draft-palet-v6tc-goals-tunneling-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Palet, et al. Expires August 18, 2005 [Page 1]
Internet-Draft Goals for Tunneling Configuration February 2005
Abstract
This memo describes the set of goals for a tunneling setup protocol
that could be used in several network cases to jumpstart its IPv6
offering to its customers by providing them IPv6 connectivity through
a simplistic tunneling mechanism.
The basic network cases, which may have different sets of goals, are
also introduced, including 3GPP and other Service Providers. Two
cases are analyzed in the Service Provider scenario, one which apply
to simplistic mechanism where the user is already authenticated by
other network existing means, and another which also takes care of
the user authentication.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions and Prerequisites . . . . . . . . . . . . . . . . 6
4. Goals of the Tunneling Configuration Protocol . . . . . . . . 7
4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2 Easy to deploy and Easy to Phase-out . . . . . . . . . 7
4.2 Tunnel Set-up . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1 Tunnel End-Point Auto-Discovery and tunnel
establishment . . . . . . . . . . . . . . . . . . . . 8
4.2.2 Tunnel End-Point Reachability Detection . . . . . . . 8
4.2.3 Scalability and Load-Balancing . . . . . . . . . . . . 9
4.2.4 Latency in Set-up Phases . . . . . . . . . . . . . . . 9
4.2.5 Tunnel Link Sustainability . . . . . . . . . . . . . . 9
4.2.6 NAT Traversal . . . . . . . . . . . . . . . . . . . . 10
4.2.7 Firewall Traversal . . . . . . . . . . . . . . . . . . 10
4.2.8 Use Native Connectivity when Available . . . . . . . . 10
4.3 IPv6 Configuration . . . . . . . . . . . . . . . . . . . . 10
4.3.1 IPv6 Address Assignment . . . . . . . . . . . . . . . 10
4.3.2 IPv6 Address Stability . . . . . . . . . . . . . . . . 11
4.3.3 IPv6 Prefix Delegation . . . . . . . . . . . . . . . . 11
4.3.4 IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Implementation Considerations . . . . . . . . . . . . . . 11
4.4.1 Private and Public IPv4 Addresses . . . . . . . . . . 11
4.4.2 Extensibility . . . . . . . . . . . . . . . . . . . . 11
4.4.3 Stateful or Stateless . . . . . . . . . . . . . . . . 12
4.5 Management and Security . . . . . . . . . . . . . . . . . 12
4.5.1 Security . . . . . . . . . . . . . . . . . . . . . . . 12
4.5.2 Traceability . . . . . . . . . . . . . . . . . . . . . 12
4.5.3 Registration . . . . . . . . . . . . . . . . . . . . . 12
4.5.4 Authentication . . . . . . . . . . . . . . . . . . . . 13
4.5.5 Confidentiality . . . . . . . . . . . . . . . . . . . 13
Palet, et al. Expires August 18, 2005 [Page 2]
Internet-Draft Goals for Tunneling Configuration February 2005
4.5.6 Accounting . . . . . . . . . . . . . . . . . . . . . . 13
5. Applicability of the Tunneling Configuration to Different
Network Cases . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 3GPP Access Networks . . . . . . . . . . . . . . . . . . . 14
5.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2 Automated IPv6-in-IPv4 tunnel establishment . . . . . 15
5.1.3 IPv6 Address Assignment and Prefix Delegation . . . . 15
5.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Narrowband Access Networks . . . . . . . . . . . . . . . . 16
5.3 Broadband Access Networks . . . . . . . . . . . . . . . . 16
5.4 Unmanaged Networks . . . . . . . . . . . . . . . . . . . . 16
5.5 Enterprise Networks . . . . . . . . . . . . . . . . . . . 16
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 21
Palet, et al. Expires August 18, 2005 [Page 3]
Internet-Draft Goals for Tunneling Configuration February 2005
1. Introduction
Regardless of which is the network that is involved in the transition
from IPv4 to IPv6, generally this could involve several phases, often
in different networks parts (i.e., core, access).
The transition of the core network usually can be done in a much more
easy way than the access network. This is the case even if the core
network is only connected via tunnels to other IPv6 networks. The
setup of those tunnels involves a small effort and is not a big
trouble, even in the case of a manual configuration.
However, this is not the case for the access network, which may
involve different types of layer two technologies. In all the cases,
in order to facilitate the transition of those access networks, which
will be impossible to do manually and efficiently, there is a need
for an automatic IPv6-in-IPv4 tunneling mechanism. The goal is to
provide bidirectional IPv6-in-IPv4 tunneled connectivity between
dual-stack end-nodes located at an IPv4-only access network and
dual-stack tunnel servers located at IPv6/IPv4 network boundaries.
This should be applicable to all kind of ISPs and access networks.
They could be regular ISPs, providing service through DSL, PSTN,
ISDN, cable, PLC or any other technologies, but could be also a
wireless ISP, or even an enterprise with its own service provider
infrastructure for the employees at remote locations.
In order to simplify the text, "customers" is used in the rest of
this document to refer to both Customers of Service Providers (3GPP,
other ISPs) and users (Enterprise, others).
In this document, the refereces to "Service Provider" is a general
one, meaning whatever network/technology is used for providing access
to IP connectivity.
In the case of an ISP starting its IPv6 offering to its customers,
without initially upgrading its access network to support IPv6, as
indicated in section 5.1 of [3], could use a "tunnel brokering
solution", as described in [5]. However the tunnel set-up protocol
has been identified as a missing piece.
Similarly, in an 3GPP, ISP or enterprise network, the provision of
the native IPv6 connectivity to the customers/users, can take a long
time and may be costly, while a tunneled infrastructure can be used
as a low cost transition path, which can be deployed easily and in a
short time, enabling progressive native IPv6 deployment when/where
justified.
Palet, et al. Expires August 18, 2005 [Page 4]
Internet-Draft Goals for Tunneling Configuration February 2005
Such tunneling infrastructure can connect the customers/users to the
IPv6 network using available production IPv6 address space, thus
facilitating the transition towards native IPv6 deployment, so the
roadmap may become:
o Tunneling infrastructure for early adopters.
o Native IPv6 to some customers/user groups once economically
justified.
o Native IPv6 to all customers/users.
"Tunneling Configuration" (TC) is used in this document to describe a
protocol which takes care of the setup and maintenance of the
bidirectional tunnel between a dual-stack end-node (or leaf network)
and a dual-stack tunnel server. The exchange of parameters needed
for the setup and maintenance of the tunnel (such as address, prefix,
routing, encapsulation, filtering, authentication, accounting, ...),
should be automated to avoid manual user/operator intervention.
The tunneling configuration protocol is envisaged to be deployed as
an initial and temporary mechanism to provide basic IPv6 connectivity
services only. This basic IPv6 connectivity may be limited, in the
sense than may be not 100% comparable to a native IPv6 service.
However this basic IPv6 connectivity should be enough while it allows
the communication through IPv6 during the transition phase, until the
native IPv6 service is available, and consequently is expected that
the tunneling will be phased out as soon as native IPv6 access
service is available.
This document analyzes the goals for a such tunnel setup protocol,
taking in consideration the different possible common network cases
for deploying IPv6.
2. Terminology
Tunneling-Configured Site (TCS): A logical network over which IPv6
connectivity is provided by means of Tunneling Configuration. At
least one dual-stack node is required in this logical network.
Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4
tunnel encapsulation/decapsulation in accordance with Tunneling
Configuration. There will be always two TEPs in order to establish
the communication, the local one at the customer site (TCS) and the
remote one at the ISP site.
Tunnel Server (TS): A dual-stack server node with IPv6 connectivity
and which provides IPv6 connectivity to client nodes by performing
Palet, et al. Expires August 18, 2005 [Page 5]
Internet-Draft Goals for Tunneling Configuration February 2005
IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes
in accordance with Tunneling Configuration. A Tunnel Server is
likely to be a dual-stack router, but could be also a node behaving
as a router. The TS is often the ISP TEP.
Tunnel Client (TCL): A dual-stack node that obtains IPv6 connectivity
by means of Tunneling Configuration. A tunnel client relies on
IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from Tunnel
Servers for IPv6 communications to native IPv6 nodes. This is often
the customer TEP.
Direct Tunneling (DT): Direct tunnelling here refer to the case where
end-hosts located within different Tunneling-Configured Sites, in the
same ISP network, may circumvent the Tunnel Server and communicate
directly using the tunnel protocol.
CPE: Customer Premises Equipment.
3. Assumptions and Prerequisites
Tunneling Configuration may be applicable in different IPv6
transition network cases. The focus of this document is to define
the goals to apply this mechanism in the Service Provider context
making the following assumptions and prerequisites:
o The customer configuration may be diverse and not necessarily
predictable. Consequently the tunneling configuration protocol
must be able to adapt to different cases or combinations of:
* The TCS is a single node or leaf network.
* The TCL at the TCS has a global IPv4 address or is behind one
or more NATs.
* The TCL at the TCS has a static or dynamic IPv4 address.
* In case of NAT, the external IPv4 address is a static or
dynamic.
* In case of NAT, it can be customer or ISP owned.
o IPv4 multicast is not widely available, so the tunnel
configuration protocol should work in IPv4 network environments
where IPv4 multicast is not provided.
o The tunnel configuration protocol should be simple to implement
and easy to deploy. In particular, it should not depend on any
complex, yet to be designed, protocols or infrastructure pieces.
Palet, et al. Expires August 18, 2005 [Page 6]
Internet-Draft Goals for Tunneling Configuration February 2005
o This tunneling configuration protocol is provided within a
restrictive timescale, in the sense that it should be phased out
as soon as native access can be provided.
o The tunneling configuration is a protocol to be used in the
transition phase, thus does not need to be perfect. As a matter
of fact, making it perfect would be counter productive, as it
would first delay its definition, then make its deployment more
cumbersome and, last but not least, diminish the incentives to
deploy native IPv6. Furhermore, should not rely in a complex set
of devices, which may not be readily available, and could even
mean a more expensive cost than the support of native IPv6 itself.
4. Goals of the Tunneling Configuration Protocol
As introduced above, there are different ISP types and different
access networks. This means that that there are different goals
related to different network cases and situations. For instance,
factors as presence of NAT or not, low/high bandwidth,
expensive/cheap, strong internal access control or not, etc.
Different access media or network cases brings up different sets of
goals. Obviously, once choice will be to create a protocol for each
specific case, but this is not optimal. Instead, the motivation of
this document is to combine all the goals and look for a common
solution, which can fit as much as possible and in the most optimal
way, in all the cases. Some of those goals could be conflictual and
that need to be resolved as well.
This section groups these different goals.
4.1 General
4.1.1 Simplicity
The Tunneling Configuration protocol should be easy to implement,
implying a lightweight protocol. The protocol should provide a
reasonable, even if limited, set of basic IPv6 connectivity features.
4.1.2 Easy to deploy and Easy to Phase-out
The Tunneling Configuration protocol should be easy to deploy into
the existing IPv4 and IPv6 network infrastructure.
The Tunneling Configuration protocol should have no major impact on
protocols and infrastructure nodes deployed in existing
infrastructures providing IPv4 and native IPv6 connectivity.
Palet, et al. Expires August 18, 2005 [Page 7]
Internet-Draft Goals for Tunneling Configuration February 2005
The Tunneling Configuration protocol should coexist and work
seamlessly together with any native IPv6 infrastructure that
gradually may be implemented in the network. The Tunneling
Configuration protocol should have no negative implications on how
such infrastructure is implemented.
The Tunneling Configuration protocol should be easy to take out of
service once native IPv6 is available.
4.2 Tunnel Set-up
4.2.1 Tunnel End-Point Auto-Discovery and tunnel establishment
The tunnel protocol should provide a mechanism for the automated
discovery of the Tunnel End-Point, by the virtue of which end-hosts
automatically and at run-time can determine the IPv4 addresses of
available Tunnel Servers.
The discovery mechanism should rely on intrinsic services, read
services already universally deployed, to the particular network
environment. It should not require the addition of additional IP
network infrastructure elements for this function only.
The mechanism should be fully dynamic in the sense that it must not
require IP address information such as the IPv4 address of a Tunnel
Server and/or the IPv6 address(es) to use for IPv6 connectivity to be
configured on the Tunnel Clients beforehand.
The analysis done in [11] may apply.
The Tunneling Configuration protocol should provide for the set of
IPv6-in-IPv4 tunnels, based on IPv6-in-IPv4 encapsulation as defined
in [10], from dual-stack nodes, attached to IPv4-only networks, to
Tunnel Servers.
The IPv6-in-IPv4 tunnels and the IPv6 connectivity should be
established in an automated manner, i.e., without requiring manual
intervention at any of the tunnel end-points at tunnel establishment
time. We can typically describe it as a "plug and play" protocol,
which can be triggered through the execution of a simple program.
4.2.2 Tunnel End-Point Reachability Detection
The Tunneling Configuration protocol should allow for means for one
tunnel end-point to verify the reachability of other tunnel
end-points towards which it intends to send packets in a method
similar to IPv6 NUD.
Palet, et al. Expires August 18, 2005 [Page 8]
Internet-Draft Goals for Tunneling Configuration February 2005
The unicast neighbor reachability discovery functions provided by
IPv6 Neighbor Discovery ([6]), i.e., unicast NS/NA exchanges, should
be supported on the tunnel link.
It is preferable that a Tunnel Server monitors the reachability of
the tunnel client towards which it is sending packets. Full
emulation of IPv6 NUD mechanism is however not an explicit goal.
4.2.3 Scalability and Load-Balancing
In order to ensure the scalability of the tunnel service, in terms of
not limiting the number of simultaneous connections to the service
and consequently limiting possible service denial situations, it
should be possible for a Service Provider to load-balance those
connections among several available Tunnel Servers.
Load balancing should be planned already during the early phases of
deployment. Given adequate planning it should be possible for an ISP
to seamlessly deploy additional Tunnel Servers in order to support an
increased amount of Tunnel Clients.
This may be achieved, for example, by using the load balancing
functions provided by the Tunnel Server End-point discovery mechanism
as detailed in [12].
4.2.4 Latency in Set-up Phases
In certain type of networks, keeping tunnels active all the time is
not possible. In such environments, the protocol must be able to
set-up tunnels on demand when the IPv6 connectivity either natively
or through tunneling is unavailable. The tunnel will be set-up only
once though for the tunnel client and not per session.
The Tunneling Configuration protocol must then have a low enough
latency to enable quasi-instant configuration. Latency is usually a
function of the number of packet exchanges required, so minimizing
this parameter is important.
4.2.5 Tunnel Link Sustainability
The tunnel link established in between a host deploying Tunneling
Configuration and an associated Tunnel Server should be expected to
remain in administrative active state for the lifetime of the IPv6
address provided to the host.
The Tunneling Configuration protocol should not mandate keep-alive
messages to be transmitted by the host simply in order to sustain
tunnel link connectivity. However, this may be required when a
Palet, et al. Expires August 18, 2005 [Page 9]
Internet-Draft Goals for Tunneling Configuration February 2005
tunnel has to cross a NAT box. In this case, the mapping established
by the NAT must be preserved as long as the tunnel is in use. This
is usually achieved by sending keep-alive messages across the tunnel.
Also, the same keep-alive messages can enable the ISP tunnel end
point to perform garbage collection of its resources when tunnels are
not in use anymore. To enable those two functionalities, the tunnel
set-up protocol must include the transmission of keep-alive messages.
A client may choose not to send those messages (for example on 3GPP
or ISDN type links). In this case, the client should be able to
handle a tunnel disconnect event and be able to restart the set-up
phase to re-establish the tunnel.
4.2.6 NAT Traversal
The Tunneling Configuration protocol should be able to detect the
presence of one or more NATs in its path.
The tunnel should be able to traverse NAT, if present, so it may be
necessary to choose among several tunnel encapsulation protocols for
the most optimal one.
4.2.7 Firewall Traversal
Even if no NAT is in the tunnel path, there may be a firewall which
prohibits proto-41. In such case, the tunnel encapsulation selection
based on NAT detection could select a tunnel that will not work.
To cope with this situation, the Tunnel Configuration protocol
implementation may allow a user to explicitly specify the desired
tunnel encapsulation, regardless of the NAT detection process.
4.2.8 Use Native Connectivity when Available
The node should not use the Tunneling Configuration protocol when
native IPv6 connectivity is available.
The fact that a node should not initiate the Tunneling Configuration
protocol when native IPv6 connectivity is available is not considered
to be a functional goal on the tunnel protocol per se. For example,
rather it is related to the activation and deactivation of the
protocol.
4.3 IPv6 Configuration
4.3.1 IPv6 Address Assignment
Assignment of at least one globally routable IPv6 unicast address
Palet, et al. Expires August 18, 2005 [Page 10]
Internet-Draft Goals for Tunneling Configuration February 2005
(/128) to the end-node should be supported.
No goals are defined as to how address configuration should be
performed. This may be done based on stateless or stateful IPv6
address configuration mechanisms or by some altogether different
mechanism particular to the Tunneling Configuration protocol.
4.3.2 IPv6 Address Stability
The IPv6 address is "transient" and may change, but the protocol
should offer a mechanism to provide IPv6 address stability (for
example, a cookie mechanism). The implementation of this mechanism
should allow this feature to be turned off.
It is preferable that the address assignment provides a stable
address, that is, an address that can be used for IPv6 connectivity
for a certain amount of time rather than solely one address per
higher layer session initiation.
4.3.3 IPv6 Prefix Delegation
Prefix Delegation support may depend on the different deployment
cases. It is not however required that a Tunneling Configuration
protocol supporting only basic requirements provides support for
prefix delegation.
4.3.4 IPv6 DNS
Dual-stack nodes could use both IPv4 and IPv6 DNS discovery
mechanisms and both, IPv4 and IPv6 transport for DNS services.
Consequently IPv6 DNS discovery and IPv6 transport for DNS services
should not be a goal of the Tunneling Configuration protocol.
4.4 Implementation Considerations
4.4.1 Private and Public IPv4 Addresses
The Tunneling Configuration protocol should work over IPv4 sites
deploying both private and public IPv4 addresses.
Furthermore, the Tunneling Configuration protocol should work with
both dynamic and static IPv4 address allocation.
4.4.2 Extensibility
The Tunneling Configuration protocol should be extensible to support
tunnel encapsulation other than IPv6 in IPv4 and IPv6 in transport in
Palet, et al. Expires August 18, 2005 [Page 11]
Internet-Draft Goals for Tunneling Configuration February 2005
IPv4. In particular, encapsulation of IPv4 in IPv6 or IPv6 in IPv6
could be defined.
4.4.3 Stateful or Stateless
By a stateful mechanism we mean a mechanism that require the Tunnel
Server to maintain tunnel state per client it serves.
Tunnel state here is considered to be any parameter kept by the
server per client and without which the server is unable to serve the
client (receive packets from/send packets to).
Tunnel state must be distinguished from state used to optimize the
packet delivery function of the tunnel server and which is kept in a
fixed or upper limited amount of memory space, such as, e.g.,
reachability information.
It should be emphasized that this document makes no deliberate
assumptions on whether a Tunneling Configuration protocol should be
based on a stateful or stateless Tunnel Server mechanism. Indeed it
is anticipated that the goals of Tunneling Configuration as put
forward here could be served both by a stateless as well as by a
stateful mechanism.
4.5 Management and Security
4.5.1 Security
The Tunneling Configuration protocol should not impose any new
vulnerability to the existing network infrastructure.
The Tunneling Configuration protocol should not impose any new
vulnerability to the nodes implementing it than what is already
present in existing multi-access IPv6 networks, where multiple hosts
are served by the same router or possibly multiple routers.
4.5.2 Traceability
In some environments, traceability is an important consideration.
The Tunneling Configuration protocol should be instrumentable to
enable the collection of usage data which can be used, for example,
for capacity planning.
4.5.3 Registration
The registration of credentials should be external to the Tunneling
Configuration protocol. The user may require registration prior to
using this service (through some web based service or other means).
Palet, et al. Expires August 18, 2005 [Page 12]
Internet-Draft Goals for Tunneling Configuration February 2005
Alternatively, the service provider may use an existing
authentication database to pre-register its users, or even not
require registration at all, depending on the network configuration.
In order to allow a service provider to use its existing
authentication database, an implementation may provide hooks to
facilitate integration with the ISP management infrastructure (e.g.
RADIUS for AAA, billing).
The protocol may send information about registration procedure when a
non-registered client requests access to a registered mode (e.g. URL
to provider registration web page).
4.5.4 Authentication
Authentication can be used to control that the user has access to the
IPv6 services.
The authentication mechanism supported should be compatible with
standardized methods that are generally deployed. In order to assure
interoperability, at least one common authentication method should be
supported. Other authentication may be supported and should be
negotiated between the client and server (e.g., SASL [13]).
4.5.5 Confidentiality
Tunneling Configuration can be used across networks which are not
under the service provider control (e.g., roaming users). The
Tunneling Configuration protocol should allow protection of the
authentication data. This can be achieve by selecting an
authentication mechanism that protects the credentials (e.g.,
digest-md5).
Protecting the tunneled data (IPv6 in this case) should be possible,
for instance by means of using IPsec tunneling.
4.5.6 Accounting
The Tunneling Configuration should include tools for managing and
monitoring the provided service. Such information can be used to
plan service capacity (traffic load) or billing information.
Some useful accounting data are (not exhaustive list):
o Tunnel counters (traffic in/out).
o User utilization (tunnel uptime).
Palet, et al. Expires August 18, 2005 [Page 13]
Internet-Draft Goals for Tunneling Configuration February 2005
o System logging (authentication failures, resource exhaustion,
etc.).
The interface used to provide such information can be through SNMP or
an AAA protocol (e.g., RADIUS accounting).
5. Applicability of the Tunneling Configuration to Different Network
Cases
Note: Section to be completed in a new version.
The goals enumerated in the precedent section are not all necessarily
applicable and not in the same degree to different network cases.
However seems feasible to build a common ground to these different
network cases in order to define a single Tunneling Configuration
protocol, which can accommodate to the different combinations of
those goals and network cases.
The v6ops working group has identified and analyzed several
deployment scenarios for IPv4/IPv6 transition mechanisms in various
stages of the IPv6 deployment and its coexistence with IPv4.
This work has been carried out for a number of different network
environments each with their particular characteristics including
3GPP [1], Unmanaged [2], ISP [3] and Enterprise networks [4].
The following sub-sections basically look into those different
network environments to provide an analysis of the common and
uncommon goals.
5.1 3GPP Access Networks
IPv6-in-IPv4 tunneling is envisaged to be deployed in 3GPP networks
as an initial and temporary mechanism to provide limited and basic
IPv6 connectivity services only. The IPv6-in-IPv4 tunneling
mechanism demanded by the 3GPP environment falls within the realm of
Tunneling Configuration.
Native IPv6-like 3GPP connectivity services, e.g. services including
flexible charging and quality of service on demand, will be feasible,
in 3GPP environments by virtue of true native IPv6 only. This is due
to the interrelation between the native IPv6 3GPP service and various
3GPP signaling interfaces. The latter which is not envisaged
upgraded to support the IPv6-in-IPv4 tunneling situation.
It is important to note that the IPv6 connectivity provided by 3GPP
Tunneling Configuration IPv6-in-IPv4 tunneling does not compare with
the native IPv6 3GPP connectivity in terms of the services offered.
Palet, et al. Expires August 18, 2005 [Page 14]
Internet-Draft Goals for Tunneling Configuration February 2005
This differentiates the 3GPP IPv6-in-IPv4 tunneling transition case
somewhat from some of the other transition scenarios considered in
the IETF v6ops WG and unlike some of these scenarios, the 3GPP
IPv6-in-IPv4 tunneling deployment case is not a case of progressive
and gradual roll out of native IPv6-like services. Rather, Tunneling
Configuration will in the 3GPP environment be deployed for the
following purposes:
o To provide temporary provisioning of basic IPv6 services, which
users may deploy for the simplest IPv6 services only.
o To allow an Operator, possibly a native IPv6 enabled Operator, to
provide basic IPv6 services to users roaming into foreign networks
which supports IPv4 bearer connectivity only.
The scope of Tunneling Configuration in the 3GPP network environment
is restricted to an absolute minimal set of functions required to
provide automatic IPv6 connectivity establishment to dual stack nodes
by means of IPv6-in-IPv4 encapsulation as defined in [10] to Tunnel
Servers.
Tunneling Configuration in the 3GPP network environment does not
attempt to provide emulation of the full set of native IPv6
connectivity functions as defined by [14], [15] and [16].
With this in mind the following goals are applicable to the 3GPP
Access Networks:
5.1.1 Simplicity
.
5.1.2 Automated IPv6-in-IPv4 tunnel establishment
.
5.1.3 IPv6 Address Assignment and Prefix Delegation
It is only an explicit goal to have a /128 address allocated for
global connectivity on the tunnel link.
5.1.4
.
5.1.5
.
Palet, et al. Expires August 18, 2005 [Page 15]
Internet-Draft Goals for Tunneling Configuration February 2005
5.1.6
.
5.1.7
.
5.2 Narrowband Access Networks
Somehow this type of networks are very similar to the 3GPP case,
because the main constrain is the low bandwidth and the high cost of
the usage of the access network. Examples of this are PSTN and ISDN
access networks.
.
5.3 Broadband Access Networks
This is typically the case when an ISP is offering IPv6 connectivity
to its customers, initially using controlled tunneling
infrastructure, as described in section 5.1 "Steps in Transitioning
Customer Connection Networks" of [3].
.
5.4 Unmanaged Networks
In unmanaged networks [2], Tunneling Configuration is applicable in
the case A where a gateway does not provide IPv6 at all (section 3),
and case C where a dual-stack gateway is connected to an IPv4-only
ISP (section 5).
In the case the link is not IPv4 capable, Tunneling Configuration is
applicable by means of IPv4 in IPv6 tunneling.
This will actually fall into the same set of goals as already
described for narrow or broadband access networks, depending on the
media.
5.5 Enterprise Networks
In the enterprise scenario [4], Tunneling Configuration can be used
to support both, remote users connecting to the enterprise network
(section 7.5.2) and internal users if the native infrastructure is
not yet available.
Palet, et al. Expires August 18, 2005 [Page 16]
Internet-Draft Goals for Tunneling Configuration February 2005
6. Conclusions
TBD.
7. Security Considerations
TBD.
8. Acknowledgements
This memo was written starting from previous existing work at v6ops,
such as "Goals for Zero-Configuration Tunneling in 3GPP" [7],
"Zero-Configuration Tunneling Requirements" [8] and "Goals for
Registered Assisted Tunneling" [9]. The authors would also like to
acknowledge inputs from Tim Chown and the European Commission support
in the co-funding of the Euro6IX project, where this work is being
developed.
9. References
9.1 Normative References
[1] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks",
Internet-Draft draft-ietf-v6ops-3gpp-analysis-11, October 2004.
[2] Huitema, C., Austein, R., Satapati, S. and R. van der Pol,
"Evaluation of IPv6 Transition Mechanisms for Unmanaged
Networks", RFC 3904, September 2004.
[3] Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola,
"Scenarios and Analysis for Introducing IPv6 into ISP Networks",
Internet-Draft draft-ietf-v6ops-isp-scenarios-analysis-03, June
2004.
[4] Bound, J., "IPv6 Enterprise Network Scenarios",
Internet-Draft draft-ietf-v6ops-ent-scenarios-05, July 2004.
[5] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
Broker", RFC 3053, January 2001.
[6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
9.2 Informative References
[7] Nielsen, k., "Goals for Zero-Configuration Tunneling in 3GPP",
Internet-Draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00,
October 2004.
Palet, et al. Expires August 18, 2005 [Page 17]
Internet-Draft Goals for Tunneling Configuration February 2005
[8] Suryanarayanan, R., "Zero-Configuration Tunneling
Requirements",
Internet-Draft draft-suryanarayanan-v6ops-zeroconf-reqs-00,
October 2004.
[9] Parent, F., "Goals for Registered Assisted Tunneling",
Internet-Draft draft-ietf-v6ops-assisted-tunneling-requirements-01
, October 2004.
[10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers",
Internet-Draft draft-ietf-v6ops-mech-v2-06, September 2004.
[11] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
Discovery Mechanisms",
Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January
2005.
[12] Palet, J., "IPv6 Tunnel End-point Automatic Discovery
Mechanism",
Internet-Draft draft-palet-v6ops-solution-tun-auto-disc-01,
October 2004.
[13] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[14] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314, September
2002.
[15] Loughney, J., "IPv6 Node Requirements",
Internet-Draft draft-ietf-ipv6-node-requirements-11, August
2004.
[16] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
Palet, et al. Expires August 18, 2005 [Page 18]
Internet-Draft Goals for Tunneling Configuration February 2005
Authors' Addresses
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Alcobendas - Madrid
E-28108 - Spain
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
Karen Egede Nielsen
Ericsson
Skanderborgvej 232
8260 Viby J
zip - Denmark
Phone: +45 89 38 51 00
Fax:
Email: karen.e.nielsen@ericsson.com
Florent Parent
Hexago
2875 boul. Laurier, suite 300
Sainte-Foy, QC G1V 2M2
Canada
Phone:
Fax:
Email: florent.parent@hexago.com
Alain Durand
Sun Microsystems, inc.
17 Network Circle UMPK17-202
Menlo Park, CA 94025
USA
Phone:
Fax:
Email: alain.durand@sun.com
Palet, et al. Expires August 18, 2005 [Page 19]
Internet-Draft Goals for Tunneling Configuration February 2005
Radhakrishnan Suryanarayanan
Samsung India Software Operations
No. 3/1 Millers Road
Bangalore
India
Phone: +91 80 51197777
Fax:
Email: rkrishnan.s@samsung.com
Pekka Savola
CSC/FUNET
Espoo
Finland
Phone:
Fax:
Email: psavola@funet.fi
Palet, et al. Expires August 18, 2005 [Page 20]
Internet-Draft Goals for Tunneling Configuration February 2005
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 procedures with respect to rights in RFC 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 (2005). 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.
Palet, et al. Expires August 18, 2005 [Page 21]
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/