draft-ietf-v6ops-assisted-tunneling-requirements-00.txt   draft-ietf-v6ops-assisted-tunneling-requirements-01.txt 
Network Working Group F. Parent
Internet-Draft Hexago
Expires: April 1, 2005 A. Durand
SUN Microsystems,inc.
A. Baudot
France Telecom R&D
Oct 2004
Internet Engineering Task Force A.Durand Goals for Registered Assisted Tunneling
INTERNET-DRAFT SUN Microsystems,inc. draft-ietf-v6ops-assisted-tunneling-requirements-01
June, 24, 2004 F. Parent
Expires December 23, 2004 Hexago
Requirements for assisted tunneling
<draft-ietf-v6ops-assisted-tunneling-requirements-00.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 28, 2004. This Internet-Draft will expire on April 1, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document defines requirements for a tunnel set-up protocol that This document defines requirements for a tunnel set-up protocol that
could be used by an ISP to jumpstart its IPv6 offering to its could be used by an ISP to jumpstart its IPv6 offering to its
customers by providing them IPv6 connectivity without having to customers by providing them IPv6 connectivity through tunneling.
upgrade its access network.
Table of Contents
1. Goal and Scope of the Document . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for Simplicity . . . . . . . . . . . . . . . . . 5
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
4.1 Address and Prefix Delegation . . . . . . . . . . . . . . 6
4.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Authentication . . . . . . . . . . . . . . . . . . . . . . 6
4.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 7
4.5 Service Discovery . . . . . . . . . . . . . . . . . . . . 7
4.6 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7
4.7 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 7
4.8 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 8
5. General Requirements . . . . . . . . . . . . . . . . . . . . . 8
5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 NAT Considerations . . . . . . . . . . . . . . . . . . . . 8
5.3 Keep-alive . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5 Traceability . . . . . . . . . . . . . . . . . . . . . . . 9
5.6 Phase Out . . . . . . . . . . . . . . . . . . . . . . . . 9
5.7 Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
6. Compatibility with other Transition Mechanisms . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
9.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Changes from version 00 . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14
1. Goal and Scope of the Document 1. Goal and Scope of the Document
The v6ops working group has worked on requirements and scenarios for The v6ops working group has worked on requirements and scenarios for
IPv6 deployment by soliciting input from network operators. This work IPv6 deployment by soliciting input from network operators. This
has identified a need for an "assisted tunneling" mechanism. For work has identified a need for an "assisted tunneling" mechanism.
example, an ISP starting its IPv6 offering to its customers without For example, an ISP starting its IPv6 offering to its customers
upgrading its access network to support IPv6 could use a "tunnel without upgrading its access network to support IPv6 could use a
brokering solution" [ISP, section 5.1.] a la [3053]. What has been "tunnel brokering solution" (section 5.1
identified as missing from that RFC is a tunnel set-up protocol. [I-D.ietf-v6ops-isp-scenarios-analysis]) a la [RFC3053]. What has
been identified as missing from that document is a tunnel set-up
protocol.
In an ISP network, getting IPv6 connectivity to the customers In an ISP network, getting IPv6 connectivity to the customers
involves upgrading the access network to support IPv6, which can take involves upgrading the access network to support IPv6, which can take
a long time and/or be costly. A tunneled infrastructure can be used a long time and/or be costly. A tunneled infrastructure can be used
as a low cost migration path [ISP, section 5.1]. as a low cost migration path (section 5.1
[I-D.ietf-v6ops-isp-scenarios-analysis]).
With such an infrastructure, the ISP can connect its customers to its With such an infrastructure, the ISP can connect its customers to its
IPv6 network using its production IPv6 address space, thus IPv6 network using its production IPv6 address space, thus
facilitating migration towards native IPv6 deployment. The IPv6 facilitating migration towards native IPv6 deployment. The IPv6
deployment roadmap for connecting customers becomes: deployment roadmap for connecting customers may become:
- assisted tunneling infrastructure to early adopters, o assisted tunneling infrastructure to early adopters,
- native IPv6 to customers where economically justified,
- native IPv6 to all customers.
Note that, as the addressing space used during the transition to o native IPv6 to customers where economically justified,
native remains the same the customer routing, filtering, accounting
[ISP, section 5.] stay the same, and there is no need to maintain any
kind of relay.
"Assisted tunneling" is used in this document to described a o native IPv6 to all customers.
transition mechanism where the parameters to configure a bi-
directional tunnel between an end-node (or leaf network) and a router
in the core of an ISP are exchanged through a tunnel set-up protocol.
Although this exchange can be automated, this remains different from
transition mechanisms like 6to4 that is fully automatic. Teredo and
ISATAP, on the other hand, practically require receiving information
about the available prefix or address from the server/router,
comparable to the most simple form of assisted tunneling.
In particular, the 'registered' mode defined in section 4 enables Contrary to automatic tunneling mechanism where the IPv4 address is
explicit access control to the tunneled IPv6 connectivity, where the embedded inside the IPv6 address, no special format are imposed on
other transion mechanisms have to rely on other kinds of control the IPv6 address used in assisted tunneling. Prefix delegation is
(e.g., access control based on the IPv4 address). also possible. As the addressing space used during the transition to
native remains the same, the customer routing, filtering, accounting
stay the same, and there is no need to maintain any kind of relay.
This document analyze the requirements for such a tunnel set-up "Assisted tunneling" is used in this document to describe a
transition mechanism where the parameters to configure a
bi-directional tunnel between an end-node (or leaf network) and a
router in the core of an ISP are exchanged through a tunnel set-up
protocol. Although this exchange can be automated, this remains
different from transition mechanisms like 6to4, Teredo or ISATAP. In
particular, assisted tunneling enables explicit access control to the
tunneled IPv6 connectivity, where the other transion mechanisms have
to rely on other kinds of control (e.g., access control based on the
IPv4 address). Also, assisted tunneling protocol negotiate the
tunnel parameters and does not depend on having the IPv4 address
inside the IPv6 address, for example.
This document analyzes the requirements for such a tunnel set-up
protocol. The v6ops WG scenario and evaluation documents for protocol. The v6ops WG scenario and evaluation documents for
deploying IPv6 within common network environments are used as input deploying IPv6 within common network environments are used as input
to this document. to this document.
2. Applicability 2. Applicability
Assisted tunneling is applicable in different IPv6 transition Assisted tunneling is applicable in different IPv6 transition
scenarios. The focus of this document is to define the requirements scenarios. The focus of this document is to define the requirements
to apply this mechanism in the IPv4 ISP context making the following to apply this mechanism in the IPv4 ISP context making the following
assumptions: assumptions:
- ISP is offering IPv6 connectivity to its customers initially o ISP is offering IPv6 connectivity to its customers initially using
using controlled tunneling infrastructure [ISP, 5.1 Steps in controlled tunneling infrastructure
Transitioning Customer Connection Networks] [I-D.ietf-v6ops-isp-scenarios-analysis], section 5.1 "Steps in
Transitioning Customer Connection Networks"
- The customer configuration may be diverse, and not necessarily o Provider network where deployment of IPv6 is done in a more
controlled manner or when the provider cannot rely on IPv4 related
authentication (e.g. roaming customers, users not connected to
ISP access network). In such networks, ease of debugging,
traceability, filtering and so on are important features.
o The customer configuration may be diverse, and not necessarily
predictable by the ISP. The protocol must be able to adapt to the predictable by the ISP. The protocol must be able to adapt to the
following cases, for example by choosing the most optimal tunnel following cases, for example by choosing the most optimal tunnel
encapsulation depending on the presence of a NAT. encapsulation depending on the presence of a NAT.
- a single node,
- a leaf network, * a single node,
- using a globally routable IPv4 address,
- behind a NAT (customer or ISP owned), * a leaf network,
- using dynamic IPv4 address (internally or externally to the
* using a globally routable IPv4 address,
* behind a NAT (customer or ISP owned),
* using dynamic IPv4 address (internally or externally to the
NAT) NAT)
There are actually two cases where the IPv4 address of the customer There are actually two cases where the IPv4 address of the customer
tunnel end point can be dynamic, and both must be supported: tunnel end point can be dynamic, and both must be supported:
- The device used as tunnel end point is using a dynamic IPv4 o The device used as tunnel end point is using a dynamic IPv4
address provided by the ISP. address provided by the ISP.
- The device used as tunnel end point is located behind a customer
o The device used as tunnel end point is located behind a customer
owned NAT box that is also acting as a local DHCP server. In that owned NAT box that is also acting as a local DHCP server. In that
case, the device IPv4 address may change after a reboot. case, the device IPv4 address may change after a reboot.
Althought the main focus of this document is the ISP scenario, Althought the main focus of this document is the ISP scenario,
assisted tunneling is applicable in all the other scenarios: assisted tunneling is applicable in other scenarios:
unmanaged, enterprise and 3GPP.
In unmanaged networks, assisted tunneling is applicable in the case A In unmanaged networks [RFC3904], assisted tunneling is applicable in
(a gateway which does not provide IPv6 at all) [UNMANAGED, section 3] the case A where a gateway does not provide IPv6 at all (section 3),
and C (a dual-stack gateway connected to an IPv4-only ISP) and case C where a dual-stack gateway is connected to an IPv4-only
[UNMANAGED, section 5]. ISP (section 5).
In 3GPP networks, assisted tunneling can be used in the context of In the enterprise scenario [I-D.ietf-v6ops-ent-analysis], assisted
dual stack UE connecting to IPv6 nodes through a 3GPP network that tunneling can be used to support remote users connecting to the
only supports IPv4 PDP contexts [3GPP, 3.1]. enterprise network (section 7.5.2).
3. Requirements for Simplicity 3. Requirements for Simplicity
The tunnel set-up protocol must be simple to implement and easy to The tunnel set-up protocol must be simple to implement and easy to
deploy. In particular, it should not depend on any complex, yet to be deploy. In particular, it should not depend on any complex, yet to
designed, protocols or infrastructure pieces. be designed, protocols or infrastructure pieces.
This protocol is a transition mechanism, thus does not need to be This protocol is a transition mechanism, thus does not need to be
perfect. As a matter of fact, making it perfect would be counter perfect. As a matter of fact, making it perfect would be counter
productive, at it would first delay its definition, then make its productive, at it would first delay its definition, then make its
deployment more cumbersome and, last but not least, diminish the deployment more cumbersome and, last but not least, diminish the
incentives to deploy native IPv6. incentives to deploy native IPv6.
4. Protocol Requirements 4. Protocol Requirements
Assisted tunneling can be provided in two different modes. "Non- Assisted tunneling is aimed at production deployment which requires
registered" mode is a simple mode with no user registration, the user to be authenticated (such as using a shared secret mechanism
essentially deployed in a controlled and "authenticated" environment Section 4.3). This can be to offer the tunneling service to roaming
where the service is made available to all the IPv4 customers.. The users (users that are not directly connected to the ISP access
"registered" mode is aimed at production deployment which requires network), and/or restrict the service to specific users.
the user to be authenticated. This mode can be used to offer the
tunneling service to roaming users or restrict the service to
specific (authenticated) users. The tunnel set-up protocol must
support both modes, however ISP deploying it may choose to only
support one mode of operation.
Assisted tunneling in the non-registered mode is defined for simple From a user point of view, an initial registration process may be
"plug & play" scenarios. In this mode, the tunnel establishment is required before using the service. If the service provider uses an
triggered through the execution of a simple program, without any pre- existing authentication database (Section 4.2), this step may not be
configuration or pre-registration required from the end-user. needed.
The tunnel established is "anonymous" in a sense as the end-user does From an ISP point of view, this makes a clear link between a tunnel
not register explicitly to the server. An ISP using the protocol in and a user (account). It provides some means to :
this mode may be offering a free service and doesn't wish to require
any form of registration. This free service can also be used to offer
trial IPv6 service limited to the ISP customers by relying on IPv4
access control.
The registered mode offers some extra features documented in latter o meet requirements such as tracing (section 5.4
sections. This mode is most valuable in a provider network where [I-D.ietf-v6ops-isp-scenarios-analysis])
deployment of IPv6 is done in a more controlled manner or when the
provider cannot rely on IPv4 related authentication (e.g. roaming
customers). In such networks, ease of debugging, traceability,
filtering and so on are important features.
4.1. Address and Prefix Delegation o control service provision to valid and/or identified or even
selected users (section 5.2
[I-D.ietf-v6ops-isp-scenarios-analysis])
Assignment of an IPv6 address (/128) to the end-node must be o less prone to denial of service attacks: Since every tunnel
supported in both modes. request are authenticated, it is more difficult to request
multiple tunnels to saturate the service.
In non-registered mode, the IPv6 address is "transient" and may o stay in touch with users
change, but the protocol SHOULD offer a mechanism to provide IPv6
address stability in this mode (e.g. cookie mechanism). The
implementation of this mechanism MUST allow this feature to be turned
off. In registered mode, the protocol MUST be able to support
servers willing to offer stable IPv6 prefixes to the authenticated
customers.
The registered mode MUST support delegation of a single address or a 4.1 Address and Prefix Delegation
whole prefix. The length of the IPv6 prefix delegated MUST be
configurable on the server. The non-registered mode MAY support
prefix delegation.
See section 5.9 for DNS considerations. The protocol must support delegation of an IPv6 prefix. The length
of the IPv6 prefix delegated must be configurable on the server. The
protocol must be able to offer stable IPv6 prefixes to the
authenticated customers.
Assignment of an IPv6 address (/64) to the end-node must be
supported.
Since no special address format is imposed, the ISP's address space
can be used in the delegation (section 5.1
[I-D.ietf-v6ops-isp-scenarios-analysis])
4.2 Registration 4.2 Registration
The registration of credentials is external to the protocol. A The registration of credentials is external to the protocol. The
service provider SHOULD be able to use its existing authentication user may require registration prior to using this service (through
database. If necessary, an implementation may provide hooks to some web based service or other means). Or service provider may use
an existing authentication database to pre-register its users.
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. facilitate integration with the ISP management infrastructure (e.g.
RADIUS for AAA, billing). RADIUS for AAA, billing) ([I-D.ietf-v6ops-isp-scenarios-analysis],
section 5.2).
The protocol MAY send information about registration procedure when a The protocol may send information about registration procedure when a
non-registered client requests registered mode (ex: URL to provider non-registered client requests registered mode (ex: URL to provider
registration web page). registration web page).
4.3. Authentication 4.3 Authentication
Authentication can be used to control user has access to the IPv6
services (section 5.2 [I-D.ietf-v6ops-isp-scenarios-analysis])
The authentication mechanism supported should be compatible with The authentication mechanism supported should be compatible with
standardized methods that are generally deployed. In order to assure standardized methods that are generally deployed. In order to assure
interoperability, at least one common authentication method MUST be interoperability, at least one common authentication method must be
supported. Other authentication MAY be supported and should be supported. Other authentication may be supported and should be
negotiated between the client and server (e.g., SASL [2222]). negotiated between the client and server (e.g., SASL [RFC2222]).
4.4. Service Discovery 4.4 Confidentiality
In order to offer "plug & play", the implementation SHOULD allow a Assisted tunneling can be used across networks which are not under
the service provider control (e.g., roaming users). The tunnel
set-up protocol should allow protection of the authentication data
Section 4.3. 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.
A possible usage scenario is when an enterprise's users is working
off-site and tunneling to the enterprise network (7.5.2
[I-D.ietf-v6ops-ent-analysis]). Mechanisms do exist to make this
possible, such as using IPsec over IPv6 [RFC2401].
[I-D.tschofenig-v6ops-secure-tunnels] may be applicable here but is
not analysed further.
4.5 Service Discovery
In order to facilitate deployment, the implementation should allow a
mechanism to discover the address of the server that will provide the mechanism to discover the address of the server that will provide the
tunnel connectivity. This discovery should be automatic within an ISP tunnel connectivity.
network.
4.5. NAT Traversal This discovery should be automatic when the protocol is used within
an ISP network. There is no service discovery requirements when used
outside the provider network (roaming users, 3rd party ISP).
Tunneling through IPv4 NAT MUST be supported. The protocol should Tunnel end-point discovery mechanism work
detect if an IPv4 NAT is in the path during the set-up phase (section ([I-D.palet-v6ops-tun-auto-disc] may be applicable here.
5.3). If a NAT is present, an extra level of encapsulation is
4.6 NAT Traversal
Tunneling through IPv4 NAT must be supported. The protocol should
detect if an IPv4 NAT is in the path during the set-up phase (Section
5.2). If a NAT is present, an extra level of encapsulation is
necessary to tunnel IPv6 across the NAT. If no NAT is detected, necessary to tunnel IPv6 across the NAT. If no NAT is detected,
IPv6-over-IPv4 tunneling (IP protocol 41) is enough. IPv6-over-IPv4 tunneling (IP protocol 41) is usually enough (see also
Section 4.7).
4.6. Firewall Traversal NAT traversal is identified as a requirement in ISP scenarios
(section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis]) and unmanaged
scanarios (section 7, Recommendation 1 [RFC3904])
4.7 Firewall Traversal
Even if no NAT is in the tunnel path, there may be a firewall which Even if no NAT is in the tunnel path, there may be a firewall which
prohibits IP protocol 41. In such case, the tunnel encapsulation prohibits IP protocol 41. In such case, the tunnel encapsulation
selection based on NAT detection (section 5.3) will select a tunnel selection based on NAT detection (Section 5.2) will select a tunnel
that will not work. that will not work.
The implementation MUST allow a user to explicitly specify the
desired tunnel encapsulation, regardless of the NAT detection
process.
4.7. Accounting
The assisted tunneling should include tools for managing and In some cases, when the firewall is managed by the ISP or customer,
monitoring the provided service. Such information can be used to plan it can be configured to allow IP protocol 41. In such cases this may
service capacity (traffic load) or billing information. not be an issue (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis])
Some useful accounting data are (not exhaustive list): But in order to be functional in any situation (e.g., firewall
- Tunnel counters (traffic in/out) lacking feature), the assisted tunneling implementation must allow a
- User utilization (tunnel uptime) user to explicitly specify the desired tunnel encapsulation,
- System logging (authentication failures, resource exhaustion, regardless of the NAT detection process.
etc.)
The interface used to provide such information can be through SNMP or 4.8 Accounting
an AAA protocol (e.g., RADIUS accounting).
4.8. Security Threat Analysis The assisted tunneling should include tools for managing and
monitoring the provided service. Such information can be used to
plan service capacity (traffic load) or billing information.
The non registered mode does not require explicit authentication of Some useful accounting data are (not exhaustive list):
the user. Access control may be performed using e.g., IPv4 address.
The mode essentially offer the IPv6 service to any of its IPv4
customers. Deployment of the service with this mode must be done
carefully. In particular, security considerations must be taken into
account.
Non registered service should be limited to the provider network, o Tunnel counters (traffic in/out)
where access of the service can be controlled based on the IPv4
address of the users (filtering). If specific filtering is not in
place in the ISP core network, anyone on the Internet could start
using its tunneling infrastructure to get free IPv6 connectivity,
transforming effectively the ISP into a IPv6 transit provider.
If IPv4 address spoofing is possible within the access network, a o User utilization (tunnel uptime)
number of DoS attack can happen. For example, customer A can
impersonate someone else's IPv4 address during the set-up phase and
redirect a tunnel to that IP address. A then can, for example, start
a high bandwidth multimedia flow across that tunnel and saturate its
victim's up-link.
But even with filtering in place, the non registered mode is o System logging (authentication failures, resource exhaustion,
vulnerable to denial of service attacks: a customer A behind a NAT etc.)
can use a large number of (private) IPv4 addresses and request
multiple tunnels.That would quickly saturate the ISP tunnel server
infrastructure. In order to minimize such attacks, IPv4 return
routability checks could help blocking many DoS attack. Also, the
server implementation should offer a way to throttle and limit the
number of tunnel established to the same (non-private) IPv4 address.
In registered mode, the protocol must make sure that the tunnel is The interface used to provide such information can be through SNMP or
established to the legitimate and authenticated destination, again to an AAA protocol (e.g., RADIUS accounting).
avoid having someone establish a tunnel to a potential victim. IPv4
return routability checks could help block possible DoS attacks.
5. General Requirements 5. General Requirements
5.1 Scalability 5.1 Scalability
The tunnel set-up protocol must be scalable. Typically, this protocol The tunnel set-up protocol must be scalable. Typically, this
should be deployable in broadband ISP. protocol should be deployable in an ISP or enterprise network.
5.2 Service discovery requirements
The discovery part of the tunnel set-up protocol should be as
automatic as possible.
The discovery mechanism must be able to scale for large ISP who cover
different geographical areas and/or have a large number of customers.
Customers may very well try to use this tunnel set-up protocol even A scalability requirement which is not related to the protocol itself
if their ISP is not offering the service. In this case, without any is to be able to deploy multiple servers inside the ISP network. To
previous action taken by their ISP, the discovery part of the tunnel do so, the server implementation would possibly need some load
set-up protocol must be able to abort immediately and display the balancing feature and an IPv6 IGP.
customers a message explaining that no service is available.
5.3 NAT Considerations 5.2 NAT Considerations
The assisted tunnel established by the protocol to be designed must The assisted tunnel established by the protocol to be designed must
work with the existing infrastructure, in particular it must be work with the existing infrastructure, in particular it must be
compatible with the various customer premise equipments available compatible with the various customer premise equipments available
today. This means that, in particular, the tunnels must be able to today. This means that, in particular, the tunnels must be able to
traverse one or many NAT boxes of different kinds. There is no traverse one or many NAT boxes of different kinds. There is no
requirement for any particular NAT traversal technology. However, as requirement for any particular NAT traversal technology. However, as
NAT traversal usually requires an extra layer of encapsulation, the NAT traversal usually requires an extra layer of encapsulation, the
tunnel set-up protocol SHOULD be able to detect automatically the tunnel set-up protocol should be able to detect automatically the
presence of one or more NAT boxes in the path. presence of one or more NAT boxes in the path.
The implementation MUST provide an option to to turn on extra
The implementation¬ must provide an option to turn on extra
encapsulation manually. In order to assure interoperability, at encapsulation manually. In order to assure interoperability, at
least one common tunnel encapsulation type MUST be supported. least one common tunnel encapsulation type must be supported.
5.4 Keep-alive 5.3 Keep-alive
When a tunnel has to cross a NAT box, the mapping established by the When a tunnel has to cross a NAT box, the mapping established by the
NAT must be preserved as long as the tunnel is in use. This is NAT must be preserved as long as the tunnel is in use. This is
usually achieved by sending keep alive messages across the tunnel. usually achieved by sending keep alive messages across the tunnel.
Also, the same keep alive messages can enable the ISP tunnel end Also, the same keep alive messages can enable the ISP tunnel end
point to perform garbage collection of its resources when tunnels are point to perform garbage collection of its resources when tunnels are
not in use anymore. To enable those two functionalities, the tunnel not in use anymore. To enable those two functionalities, the tunnel
set-up protocol must include the transmission of keep-alive messages. set-up protocol must include the transmission of keep-alive messages.
A client MAY choose not to send those messages (for example on ISDN A client may choose not to send those messages (for example on ISDN
type links), but should then expect that the tunnel may be type links). In this case, the client should be able to handle a
disconnected at any time by the ISP and be prepared to restart the tunnel disconnect event and be able to restart the set-up phase to
set-up phase. re-establish the tunnel.
5.5 Latency in Set-up Phases
In certain type of networks, keeping tunnels active all the time is
not possible (e.g., limited number of tunnels on server) or simply
too expensive (e.g., wireless environments where periodic
transmission is expensive). In those environments, the protocol must
be able to set-up tunnels on demand of the IPv6 applications
requiring external connectivity.
The tunnel set-up 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.
5.6 Security 5.4 Security
The tunnel set-up protocol must not introduce any new vulnerability The tunnel set-up protocol must not introduce any new vulnerability
to the network. to the network. See security considerations in Section 7.
5.7 Traceability 5.5 Traceability
In production environment, traceability is an important In some production environment, traceability is an important
consideration. The tunnel set-up protocol must be instrumentable to consideration ([I-D.ietf-v6ops-isp-scenarios-analysis], section 5.4).
enable the collection of usage data that can be used, for example, The tunnel set-up protocol must be instrumentable to enable the
for capacity planning. collection of usage data that can be used, for example, for capacity
planning.
5.8 Phase Out 5.6 Phase Out
This assisted tunneling mode is only a transition mechanism to enable This assisted tunneling mode is only a transition mechanism to enable
ISP to jump start IPv6 service without requiring an immediate global ISP to jump start IPv6 service without requiring an immediate global
upgrade of access networks and instead enabling a progressive roll upgrade of access networks and instead enabling a progressive roll
out. Once IPv6 is available natively in the access network out. Once IPv6 is available natively in the access network
connecting a customer, there is no reason to keep using tunnels. So connecting a customer, there is no reason to keep using tunnels. So
the implementation SHOULD have a provision to enable the ISP to the implementation should have a provision to enable the ISP to
signal the user to use native IPv6 instead. signal the user to use native IPv6 instead.
5.9 Extensibility 5.7 Extensibility
The protocol MUST be extensible to support tunnel encapsulation other
than IPv6 over IPv4 and IPv6 over transport over IPv4. In particular,
encapsulation of IPv4 over IPv6 or IPv6 over IPv6 could be defined.
5.10 DNS considerations
It should be possible to have the server side of the protocol
automatically register the assigned IPv6 address in the DNS system
(AAAA and PTR records) using the ISP name space. Nothing specific is
required in the protocol to support this. The details can be
implementation specific.
If stable prefix delegation is done, it is expected that the DNS The protocol must be extensible to support tunnel encapsulation other
delegation of the associated reverse DNS zone will be also stable and than IPv6 over IPv4 and IPv6 over transport over IPv4. In
thus can be performed out of band, so there is no requirement to particular, encapsulation of IPv4 over IPv6 (section 7
perform this delegation at the tunnel set-up time. [I-D.ietf-v6ops-isp-scenarios-analysis], section 7 [RFC3904], section
6 [I-D.ietf-v6ops-ent-analysis]) or IPv6 over IPv6 could be defined.
6. Compatibility with other Transition Mechanisms 6. Compatibility with other Transition Mechanisms
6.1 TSP The tunnel set-up protocol is not required to be compatible with any
existing transition mechanism. Although, a great deal of experience
The tunnel set-up protocol is not required to be compatible with TSP can be drawn from the operation of tunnel brokers currently using the
[TSP] or any particular implementation of the tunnel broker model TSP protocol [I-D.blanchet-v6ops-tunnelbroker-tsp].
[3053]. Although, a great deal of experience can be drawn from the
operation of tunnel brokers currently using the TSP protocol.
6.2 TEREDO
There is a large number of Teredo clients already deployed, the
tunnel set-up protocol should explore the avenue of providing a
compatibility mode with Teredo, at least in the 'simple' mode
described in section 4. However, it may turn out that supporting a
compatibility mode with Teredo either requires to change the Teredo
specifications and/or implement Teredo on the tunnel server side. In
that case, it might be simpler to say that the compatibility mode
should be manage on the client side instead of the server side, that
is leave it up to the client to use either one of them.
6.3 ISATAP
Similar considerations as Teredo, section 6.2, applies to Isatap.
However, as Isatap can not work accross NAT, it is of much less
interest in the framework of this document.
7. Security Considerations 7. Security Considerations
The establishment of a tunnel can be compared to Mobile IP The establishment of a tunnel can be compared to Mobile IP
technology, where traffic can be redirected to go from one place to technology, where traffic can be redirected to go from one place to
another one. So similar threats exists. In particular, when a another one. So similar threats exists. In particular, when a
customer is asking for the set-up of a tunnel ending at IP address X, customer is asking for the set-up of a tunnel ending at IP address X,
the ISP should check: the ISP should check:
- the customer is allowed to set-up this tunnel, i.e. he "owns"
the IPv6 prefix.
- the customer is allowed to terminate the tunnel where he said he
would, i.e. he "owns" the IPv4 tunnel endpoint.
The first check is simply an authentication issue. The second may be o the customer is allowed to set-up this tunnel, i.e. he "owns" the
more complex, but can be omitted if strict ingress filtering is in IPv6 prefix.
place in the access network, i.e. the customer is effectively
prevented from sending packet with an IPv4 source address he does not
own.
See section 4.4 for specific security consideration in the non- o the customer is allowed to terminate the tunnel where he said he
authenticated mode. would, i.e. he "owns" the IPv4 tunnel endpoint.
The first check is an authentication issue. The second may be more
complex. The protocol must make sure that the tunnel is established
to the legitimate and authenticated destination. IPv4 return
routability checks could help this validation. Also, when the user
is within the ISP access network, strict ingress filtering can help
prevent IPv4 address spoofing.
8. Acknowlegements 8. Acknowlegements
9. Author Addresses This draft has greatly benefited from substantial inputs by Pekka
Savola.
Alain Durand The following people provided feedback on this work (in no particular
SUN Microsystems, Inc order): Carl Williams, Brian Carpenter, Christian Huitema, Jordi
17 Network circle UMPK17-202 Palet, Jeroen Massar, Erik Nordmark, Soohong Daniel Park, Suresh
Menlo Park, CA, 94025 Satapati, Fred Tremplin, Karim El-Malki, Tim Chown, Gert Doering,
USA Soliman Hesham.
Mail: Alain.Durand@sun.com
Thanks to Mark Prior and Bernard Tuy for providing input from an ISP
perspective to validate many requirements.
9. References
9.1 Normative References
[I-D.ietf-v6ops-ent-analysis]
Bound, J., "IPv6 Enterprise Network Analysis",
draft-ietf-v6ops-ent-analysis-00 (work in progress),
September 2004.
[I-D.ietf-v6ops-isp-scenarios-analysis]
Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola,
"Scenarios and Analysis for Introducing IPv6 into ISP
Networks", draft-ietf-v6ops-isp-scenarios-analysis-03
(work in progress), June 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[RFC3904] Huitema, C., Austein, R., Satapati, S. and R. van der Pol,
"Evaluation of IPv6 Transition Mechanisms for Unmanaged
Networks", RFC 3904, September 2004.
9.2 Informative References
[I-D.blanchet-v6ops-tunnelbroker-tsp]
Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol(TSP)",
draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in
progress), June 2004.
[I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-02 (work in progress),
June 2004.
[I-D.ietf-ngtrans-isatap]
Templin, F., Gleeson, T., Talwar, M. and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", draft-ietf-ngtrans-isatap-22 (work in
progress), May 2004.
[I-D.palet-v6ops-tun-auto-disc]
Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery
for Tunneling Mechanisms",
draft-palet-v6ops-tun-auto-disc-01 (work in progress),
June 2004.
[I-D.tschofenig-v6ops-secure-tunnels]
Tschofenig, H., "Using IPsec to Secure IPv6-over-IPv4
Tunnels", draft-tschofenig-v6ops-secure-tunnels-01 (work
in progress), July 2004.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
Authors' Addresses
Florent Parent Florent Parent
Hexago Hexago
2875 boul. Laurier, bureau 300 2875 boul. Laurier, suite 300
Sainte-Foy, QC G1V 2M2 Sainte-Foy, QC G1V 2M2
Canada Canada
Mail: Florent.Parent@hexago.com
10. Normative References
[2119] Bradner, S., "Key Words for Use in RFCs to Indicate EMail: Florent.Parent@hexago.com
Requirement Levels", BCP 14, RFC 2119, March 1997.
[3053] A. Durand, P. Fasano, I. Guardini, D. Lento.,
"IPv6 Tunnel Broker", January 2001.
[ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6 Alain Durand
into ISP Networks", SUN Microsystems,inc.
draft-ietf-v6ops-isp-scenarios-analysis-01 (work in 17 Network circle UMPK17-202
progress), February 2004. Menlo Park, CA 94025
USA
[UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for EMail: Alain.Durand@sun.com
Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work
in progress), February 2004.
[3GPP] J. Wiljakka, "Analysis on IPv6 Transition in 3GPP Networks", Alain Baudot
draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March 2004. France Telecom R&D
42, rue des coutures
14066 Caen,
France
11. Informative References EMail: alain.baudot@rd.francetelecom.com
[2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Appendix A. Changes from version 00
Mechanism", RFC 2831, May 2000. o Non-registered mode removed (now covered in generic zero-conf
tunneling draft). Text throughout the document changed to reflect
this.
[2222] Myers, J., "Simple Authentication and Security Layer (SASL)", o
RFC2222, October 1997.
[ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, o Renamed title from "requirements" to "goals"
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", draft-ietf-ngtrans-isatap-21 (work in
progress), April 2004.
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through o Changed imperatives to lowercase
NATs", draft-huitema-v6ops-teredo-01 (work in progress),
February 2004.
[TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup o /128 endpoints replaced by /64
Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00
(work in progress), February 2004.
Appendix 1. Summary of the Protocol Requirements o Removed DNS considerations
The non registered mode: o Added many references to other v6ops scenario documents
- MUST be supported by the protocol to be designed
- RECOMMENDED to be implemented on client and servers/brokers
- implementation SHOULD turn it on be default
- implementation MUST allow it to be turned off
- MUST support single address assignment
- SHOULD support stable IPv6 address
- MAY support prefix delegation
The registered mode: o Removed the appendix on protocol requirements summary
- MUST be supported by the protocol
- RECOMMENDED to be implemented on clients and servers/brokers
- implementation SHOULD turn it off by default
- implementation MUST allow it to be turned on
- MUST support single address assignment
- MUST support stable IPv6 address
- MUST support prefix delegation, SHOULD be able to turn off
The registered part of the protocol SHOULD not be too different from
the non registered one, so as to minimize code difference between the
two modes
12. Full Copyright Statement o Removed references to 3GPP scenario
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/