Internet Engineering Task Force R. Suryanarayanan
Internet-Draft S. Madanapalli
Expires: April 18, 2005 Samsung India Software Operations
K. E. Nielsen
Ericsson
F. Parent
Hexago
J. Palet
Consulintel
October 18, 2004
Zero-Configuration Tunneling Requirements
draft-suryanarayanan-v6ops-zeroconf-reqs-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 April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes the set of goals to be fulfilled by a
Suryanarayanan, et al. Expires April 18, 2005 [Page 1]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
Zero-Configuration Tunneling protocol.
Zero-Configuration Tunneling here denotes an automatic tunneling
mechanism that could be used by a Service Provider to offer IPv6
connectivity to its customers in early phases of IPv4 to IPv6
transition.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5
4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 IPv6 address allocation, Scope and Limitations . . . . . . 6
4.2 IPv6 tunnel link characteristics, Scope and Limitations . 6
5. Basic Assumptions and Prerequistes . . . . . . . . . . . . . 6
6. Requirements for Zero-Configuration Tunneling Mechanisms . . 7
6.1 Basic Requirements . . . . . . . . . . . . . . . . . . . . 7
6.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 8
6.1.2 Automated IPv6-in-IPv4 tunnel establishment . . . . . 8
6.1.3 IPv6 Address Assignment and Prefix Delegation . . . . 8
6.1.4 Use Native Connectivity When available . . . . . . . . 8
6.1.5 Tunnel Server End-Point Discovery . . . . . . . . . . 9
6.1.6 Tunnel End-Point Reachability Detection . . . . . . . 9
6.1.7 Private and public IPv4 addresses . . . . . . . . . . 9
6.1.8 Scalability and Load-Balancing . . . . . . . . . . . . 9
6.1.9 Easy to deploy and Easy to Phase Out . . . . . . . . . 9
6.1.10 Latency in Set-up Phases . . . . . . . . . . . . . . 10
6.1.11 Security . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Advanced Requirements . . . . . . . . . . . . . . . . . . 10
6.2.1 Tunnel Link Sustainability . . . . . . . . . . . . . . 10
6.2.2 NAT Traversal . . . . . . . . . . . . . . . . . . . . 11
6.2.3 Firewall Traversal . . . . . . . . . . . . . . . . . . 11
6.2.4 Extensibility . . . . . . . . . . . . . . . . . . . . 11
6.2.5 IPv6 Address Stability . . . . . . . . . . . . . . . . 11
7. 3GPP Specific Requirements . . . . . . . . . . . . . . . . . 12
8. Unmanaged Networks Specific Requirements . . . . . . . . . . 12
8.1 Address Assignment and Prefix Delegation . . . . . . . . . 12
8.2 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 12
8.3 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13
8.4 Tunnel Link Sustainability . . . . . . . . . . . . . . . . 13
8.5 Extensibility . . . . . . . . . . . . . . . . . . . . . . 13
8.5.1 IPv4-in-IPv6 Tunneling . . . . . . . . . . . . . . . . 13
8.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . 13
9. Enterprise Network Requirements . . . . . . . . . . . . . . 13
9.1 IPv6 Address Assignment and Prefix Delegation . . . . . . 14
9.2 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
9.3 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 14
Suryanarayanan, et al. Expires April 18, 2005 [Page 2]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
9.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . 15
9.4.1 IPv4-in-IPv6 Tunneling . . . . . . . . . . . . . . . . 15
10. ISP Network Specific Requirements . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . 15
11.1 Access Control . . . . . . . . . . . . . . . . . . . . . 15
11.2 General Threats . . . . . . . . . . . . . . . . . . . . 16
11.3 Threats to nodes implementing Zero-Configuration
Tunneling . . . . . . . . . . . . . . . . . . . . . . . 17
11.3.1 Threats to end-hosts . . . . . . . . . . . . . . . . 17
11.3.2 Threats to Tunnel Servers . . . . . . . . . . . . . 18
11.4 Implications of Direct Tunneling . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1 Normative References . . . . . . . . . . . . . . . . . . . 20
13.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
A. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . 24
Suryanarayanan, et al. Expires April 18, 2005 [Page 3]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
1. Introduction
The IETF v6ops Working Group has identified and analyzed deployment
scenarios for IPv4/IPv6 transition mechanisms in various stages of
IPv6 deployment and IPv6 and IPv4 coexistence.
This work has been carried out for a number of different network
environments each with their particular characteristics: Enterprise,
ISP, Unmanaged and 3GPP networks, see e.g. [1], [2], [3] and [4].
The work has identified a need for automatic IPv6-in-IPv4 tunneling
mechanisms that 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 within the Service Providers network.
The term Zero-Configuration Tunneling is used in this document to
denote a tunneling mechanism that fulfills the goals as put forward
here.
A Zero-Configuration Tunneling mechanism provides a set of minimal
features required for automatic establishment of IPv6 connectivity.
For scenarios demanding advanced tunneling features, for example full
emulation of native (though tunneled) IPv6 connectivity, a more
full-fledged tunneling mechanism is envisaged to be deployed, see
[5]. With respect to the latter, an analysis of appropriate
mechanisms for automatic discovery of the tunnel endpoint is being
done in [6], which will be also useful for the zero-configuration
tunneling protocol.
One of the major differences between the zero-configuration tunneling
mechanism and the full-fledged tunneling mechanism is that the former
does not support user authentication, which should not be an issue
because the scope of the users of this mechanism are already users of
the Service Provider actually deploying it. Consequently, the users
are to be authenticated by other means, which are out of the scope of
this document.
It should be emphasized that unless otherwise specified, in this
document the reference, IPv6-in-IPv4 encapsulation as defined in [7],
refers to the aspects of Protocol-41 encapsulation related to IPv4
header construction (except for source and destination address
determination), MTU and Fragmentation, Hop Limits and ICMP handling
as detailed in Section 3.1-3.6 of [7]. The particular aspects of
Configured IPv6-In-IPv4 Tunneling in the areas of IPv4 source and
destination address determination, tunnel link characteristics and
IPv6 Neighbor Discovery operation are not intended referred to by the
Suryanarayanan, et al. Expires April 18, 2005 [Page 4]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
above reference.
This document only identifies requirements for a zero-configuration
tunneling mechanism, based on which solutions can be developed or
identified.
2. Terminology
Zero-Configuration Tunneling site: A logical IPv4 network over which
IPv6 connectivity is provided to dual-stack nodes by means of
Zero-Configuration Tunneling.
Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4
tunnel encapsulation/decapsulation in accordance with
Zero-Configuration Tunneling.
Tunnel Server (TS): A dual-stack server node with IPv6 connectivity
and which provides IPv6 connectivity to client nodes by performing
IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes
in accordance with Zero-Configuration Tunneling. A Tunnel Server is
likely to be a dual-stack router.
Tunnel Client: A dual-stack node that obtains IPv6 connectivity by
means of Zero-Configuration Tunneling. A tunnel client relies on
IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from Tunnel
Servers for IPv6 communications to native IPv6 nodes.
Direct Tunneling: Direct tunnelling here refer to the case where
end-hosts located within the same Zero-Configuration Tunnelling site
may circumvent the Tunnel Server and communicate directly using the
tunnel protocol.
CPE: Customer Premises Equipment.
3. Applicability
Zero-Configuration Tunneling is applicable in different IPv6
transition scenarios. The focus of this document is to define the
requirements for Zero-Configuration Tunnelling mechanism in the
following Service Provider contexts:
o 3GPP scenarios [4].
o Unmanaged network scenarios [3].
o ISP scenarios [2].
o Enterprise scenarios [1].
Suryanarayanan, et al. Expires April 18, 2005 [Page 5]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
Zero-Configuration Tunneling does not attempt to provide emulation of
the full set of native IPv6 connectivity functions as defined by [8],
[9] and [10]
It is possible that the same zero-configuration Tunneling mechanism
can be used in various deployment scenarios. However, it is not
required that same tunnel set-up protocol be deployable in all
scenarios.
4. Limitations
4.1 IPv6 address allocation, Scope and Limitations
It is not explicitly within the scope to support privacy extensions
to IPv6 [11].
It is not explicitly within the scope to support usage of IPv6
multicast.
No goals are defined as to how address configuration should be
performed. This may be done based on legacy stateless or stateful
IPv6 address configuration mechanisms or by some altogether different
mechanism particular to the zero-configuration solution.
4.2 IPv6 tunnel link characteristics, Scope and Limitations
Direct tunneling is neither an explicit goal nor explicitly excluded
in Zero-Configuration Tunneling.
It is not an explicit requirement for the zero-configuration tunnel
link to support IPv6 link-local multicast.
The tunnel protocol should allow for the formation of a link-local
address on the tunnel link, though no particular usage of such an
address is explicitly demanded by the goals set forward here.
It is an explicit goal that nodes attached to a tunnel link must be
able to ascertain the reachability of neighbors with which it is
communicating (or wish to start communicate). This may be achieved
using IPv6 Neighbor Discovery mechanism ([12]) based on unicast
link-local packet exchanges (or link-local multicast if such is
supported) but it may also be achieved by altogether different
mechanisms.
5. Basic Assumptions and Prerequistes
Zero-Configuration Tunneling is a tunneling mechanism by virtue of
which dual-stacks hosts, attached to IPv4-only networks links, can
Suryanarayanan, et al. Expires April 18, 2005 [Page 6]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
use IPv6-in-IPv4 encapsulation as defined in [7] to tunnel servers
for global IPv6 connectivity.
Zero-configuration Tunneling is a simple mode with no user
registration, essentially deployed in a controlled and
"authenticated" environment where the service is made available to
all the IPv4 customers.
The aim of the document is to define the set of goals to be fulfilled
by zero-configured tunneling when the following assumptions are made
on the deployment environment:
o The first-hop ISP is providing IPv6 connectivity.
o The Tunneling protocol must not require prior registration, or
require registration during the protocol set-up phases.
o The Zero-Configuration Tunneling site is protected from proto-41
encapsulated packets arriving from external IPv4 networks.
o At least one authoritative DNS server is IPv4-enabled and at least
one recursive DNS server supports IPv4. Further IPv4 DNS Server
discovery is provided by already existing means/means outside the
scope of the tunnel protocol.
o The user is being authenticated to the network by means external
to the tunneling protocol.
The following assumption is only valid for basic requirements where
there is no NAT in the path.
o The Zero-Configuration Tunneling network is fully penetrable for
intra-site IPv6-in-IPv4 Protocol 41 traffic.
It is a prerequisite that the tunnel protocol must work in IPv4
network environments where IPv4 multicast is not provided.
6. Requirements for Zero-Configuration Tunneling Mechanisms
6.1 Basic Requirements
The basic requirements described below must be supported by any
zero-configuration tunneling protocol. Tunneling protocol satisfying
these basic requirements could be used in a deployment scenarios
which is NAT-free, does not require IPv6 /64 address or prefix
delegation.
Suryanarayanan, et al. Expires April 18, 2005 [Page 7]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
6.1.1 Simplicity
The tunnel protocol is easy to implement in the targeted environment.
Additionally, the protocol should provide a reasonable,limited set of
basic IPv6 connectivity features
6.1.2 Automated IPv6-in-IPv4 tunnel establishment
The Tunnel protocol should provide for the set up of IPv6-in-IPv4
tunnels, based on IPv6-in-IPv4 encapsulation as defined in [7], from
dual-stack nodes, attached to IPv4-only networks, to Tunnel Servers.
Zero-configuration tunneling is defined for simple "plug and play"
scenarios. In this mode, the tunnel establishment is triggered
through the execution of a simple program, without any
pre-configuration or pre-registration required from the end-user.
The mechanism must 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.
6.1.3 IPv6 Address Assignment and Prefix Delegation
Assignment of an IPv6 address to the end-node must be supported.
No goals are defined as to how address configuration should be
performed. This may be done based on legacy stateless or stateful
IPv6 address configuration mechanisms or by some altogether different
mechanism particular to the zero-configuration solution.
Prefix Delegation support is dealt with respect to various deployment
scenarios in sections 6, 7, 8 and 9. It is not however required that
any tunneling protocol supporting only basic requirements provide
support for prefix delegation.
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
6.1.4 Use Native Connectivity When available
The node should not use Zero-Configuration Tunneling when native IPv6
connectivity is available.
The fact that a node should not use Zero-Configuration Tunneling when
native IPv6 connectivity is available is not considered to be a
Suryanarayanan, et al. Expires April 18, 2005 [Page 8]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
functional requirement on the tunnel protocol.
6.1.5 Tunnel Server End-Point Discovery
In order to offer "plug and play", the implementation should allow a
mechanism to discover the address of the tunnel server that will
provide the tunnel connectivity. This discovery should be automatic
within a Service Provider's network.
6.1.6 Tunnel End-Point Reachability Detection
The tunnel protocol must 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.
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 required to be
supported.
6.1.7 Private and public IPv4 addresses
The tunnel protocol must work over IPv4 sites deploying both private
and public IPv4 addresses.
Furthermore, the tunnel protocol should work with both dynamic and
static IPv4 address allocation.
6.1.8 Scalability and Load-Balancing
The tunnel set-up protocol must be scalable.
Load balancing should be planned in advance during the early phases
of deployment. Given adequate planning it should be possible for a
Service Provider to seamlessly deploy additional Tunnel Servers in
order to support an increased amount of Tunnel Clients.
This may be achieved using load balancing functions provided by the
Tunnel Server End-point Discovery mechanism as detailed in [13].
6.1.9 Easy to deploy and Easy to Phase Out
Zero-configuration Tunneling is a transition mechanism to enable
Service Provider to jump start IPv6 service without requiring an
immediate global upgrade of access networks.
The tunneling protocol should be easy to deploy into the existing
network infrastructures.
Suryanarayanan, et al. Expires April 18, 2005 [Page 9]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
Once IPv6 is available natively in the access network, it should be
easy to phase out the tunneling protocol.
6.1.10 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 connectvity either native or
through tunneling is unavailable. The tunnel will be set-up only
once though for the end-node and not per session.
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.
6.1.11 Security
The tunneling Protocol must not introduce any new vulnerability to
the network.
6.2 Advanced Requirements
It is not required that the tunneling protocol support one or all of
the advanced requirements described below. Support to these advanced
requirements by tunneling protocol are driven by the deployment
scenarios.
6.2.1 Tunnel Link Sustainability
In certain environments, like in 3GPP, to minimize the overhead and
latency associated with tunnel initialisation, it is highly desirable
that tunnels remain active for a large amount of time, ideally
infinitely. In such environments, the tunnel protocol must not
mandate keep-alive messages to be transmitted by the host simply in
order to sustain tunnel link connectivity.
In other environments, the Tunnel Server may perform some garbage
collection if it is configured to do so. The keep-alive messages can
enable the tunnel server to perform garbage collection of its
resources when tunnels are not in use anymore.
To enable this functionality, the tunnel set-up protocol must include
the transmission of keep-alive messages and time interval.
Implementations, where keep-alive messages are used, must provide
facility to turn-off transmission of keep-alive messages. In such
cases the tunnel server might use other metrics to perform garbage
Suryanarayanan, et al. Expires April 18, 2005 [Page 10]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
collection.
The tunneling protocol should be able to restart the connectivity
establishment process if the tunnel no longer is available.
6.2.2 NAT Traversal
The Tunnel set-up protocol must be able detect the presence of one or
more NATs in its path. It must be able to adapt to the following
cases, by choosing the most optimal tunnel encapsulation depending on
the presence of a NAT.
a single node,
a leaf network,
using a globally routable IPc4 address,
behind a NAT (customer or ISP owned),
using dynamic IPv4 address (internally or externally to the NAT).
6.2.3 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 will select a tunnel that will not work.
The implementation must allow a user to explicitly specify the
desired tunnel encapsulation, regardless of the NAT detection
process.
6.2.4 Extensibility
The protocol must be extensible to support tunnel encapsulation other
than IPv6 in IPv4 and IPv6 in transport in IPv4. In particular,
encapsulation of IPv4 in IPv6 or IPv6 in IPv6 could be defined.
6.2.5 IPv6 Address Stability
[This section shall be removed after getting more opinions from
others.]
The IPv6 address is "transient" and may change, but the protocol
should offer a mechanism to provide IPv6 address stability (e.g.
cookie mechanism). The implementation of this mechanism must allow
this feature to be turned off.
Suryanarayanan, et al. Expires April 18, 2005 [Page 11]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
7. 3GPP Specific Requirements
The 3GPP goals of zero-configuration tunnelling covers the basic
requirements in section 6.1 and advanced requirement in section
6.2.1.
Any zero-configuration tunneling protocol satisfying the above
mentioned sections must take into account constrained conditions of
the 3GPP environment. For details see [14]
8. Unmanaged Networks Specific Requirements
An unmanaged network is where no network manager or staff is
available to configure network devices. Zero-Configuration Tunneling
Protocol is quite useful in this context where automation of IPv6
connectivity to first-hop ISP and prefix assignment is handled.
Unmanaged Networks [3] may or may not be behind a NAT.
A zero-configuration tunneling mechanism should satisfy the basic
requirements (see section 6.1) and should take into account the
specific requirements described below.
8.1 Address Assignment and Prefix Delegation
In unmanaged networks, assignment of an IPv6 address (/64) to the
end-node must be supported.
Prefix Delegation must also be supported.
8.2 NAT Traversal
Zero-configuration Tunneling must work with the existing
infrastructure, in particular it must be compatible with the various
customer premise equipments available today. This means that, in
particular, the tunnels must be able to traverse one or many NAT
boxes of different kinds. Hence, Tunneling through IPv4 NAT must be
supported.
There are actually two cases where the IPv4 address of the customer
tunnel end point can be dynamic, and both must be supported:
o The device used as tunnel end point is using a dynamic IPv4
address provided by the ISP.
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
case, the device IPv4 address may change after a reboot.
Suryanarayanan, et al. Expires April 18, 2005 [Page 12]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
There is no requirement for any particular NAT traversal technology.
However, as NAT traversal usually requires an extra layer of
encapsulation, the tunnel set-up protocol should be able to detect
automatically the presence of one or more NAT boxes in the path
during the set-up phase.
The implementation must provide an option to to turn on extra
encapsulation manually.In order to assure interoperability, at least
one common tunnel encapsulation type must be supported.
8.3 Firewall Traversal
As indicated in section 6.2.3, the tunneling protocol must be able to
work in networks where the firewall prohibits proto-41 packets.
8.4 Tunnel Link Sustainability
The keep alive messages can enable the ISP tunnel end point to
perform garbage collection of its resources when tunnels are not in
use anymore.
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
usually achieved by sending keep-alive messages across the tunnel.
A client may choose not to send those messages (for example on 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.
8.5 Extensibility
8.5.1 IPv4-in-IPv6 Tunneling
Unmanaged networks [3], calls for providing a connectivity solution
when the first-hop ISP no longer supports v4. In such a scenario,
the connectivity has to be provided by a third party ISP using
assisted/managed methods, and hence it is out of scope of this
document.
8.6 Scalability
Typically, this protocol should be scalable for deployment in
broadband ISP.
9. Enterprise Network Requirements
The zero-configuration Tunneling protocol is not applicable for
Suryanarayanan, et al. Expires April 18, 2005 [Page 13]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
managed enterprise networks to get external IPv6 connectivity. So
the scope of this document is restricted to dealing with
zero-configuration requirements for internal connectivity in
enterprise networks.
In an enterprise network where IPv4 is dominant, a tunneled
infrastructure can be used to provider IPv6 services to the IPv6
islands (hosts or networks) inside the enterprise, before a full IPv6
native infrastructure is built. Zero-Configuration tunneling
protocol can be used to give IPv6 connectivity and prefix information
for the islands. This gives to the enterprise a basic deployment of
IPv6 while maintaining automation and permanence of the IPv6
assignments to the islands.
There can also be a scenario where the remote users use IPv4 VPN to
connect to the enterprise, where they are assigned an IPv4 address
from the enterprise address space. In such case, zero-configuration
tunneling mechanism is applicable since the IPv4 source address is
already authenticated for use. But typically, this is the same case
where the node is inside the enterprise network.
In cases where the network administrator is sure about the absence of
internal NAT and firewalls in the network, and end-nodes will need
only IPv6 /128 address, a tunneling protocol satisfying only the
basic requirements will suffice.
A zero-configuration tunneling mechanism should satisfy the basic
requirements (see section 6.1) and should take into account the
specific requirements described below.
9.1 IPv6 Address Assignment and Prefix Delegation
Assignment of an IPv6 address (/64) to the end-node must be
supported. Prefix Delegation must be supported.
9.2 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 If a NAT
is present, an extra level of encapsulation is necessary to tunnel
IPv6 across the NAT. If no NAT is detected, IPv6-over-IPv4 tunneling
(protocol-41) is enough.
9.3 Firewall Traversal
The tunneling Protocol must be able to handle scenario where firewall
is in the path. See Section 6.2.3.
Suryanarayanan, et al. Expires April 18, 2005 [Page 14]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
9.4 Extensibility
9.4.1 IPv4-in-IPv6 Tunneling
The tunneling Protocol should be able to handle automatic
establishment of IPv4-in-IPv6 tunnels. It must be able to handle
assignment of temporary IPv4 address and other tunnel parameters as
required.
10. ISP Network Specific Requirements
In some scenarios the ISP has IPv4-only customer connection networks
and a backbone that supports both IPv4 and IPv6.
If the customer connections might not yet been upgraded, a tunneling
mechanism has to be used to provide IPv6 connectivity through the
IPv4 customer connection networks. The customer can terminate the
tunnel at the CPE (if it has IPv6 support) or at some set of devices
internal to its network. That is, either the CPE or a device inside
the network could provide global IPv6 connectivity to the rest of the
devices in the customer's network.
Zero-configuration tunneling mechansim is very useful in such
scenarios.
NATs might be present at the ISP, if ISP provides IPv4 connectivity
using private IPv4 address. In many cases, the customer also has a
NAT of his/her own. So its required that the tunneling protocol be
able to work when one or more NATs are present in the path.
These scenarios are very similar to unmanaged networks, the
zero-configuration tunneling requirements described in section 7.1,
7.2, 7.3, 7.4 and 7.6 holds good in ISP networks as well.
In a scenario where connection to customer from ISP supports both
IPv4 and IPv6, but the customer has IPv6-only network and the ISP
backbone is IPv4-only, IPv6 packets from customer needs to be
tunneled over the IPv4 backbone to the next upstream ISP.
Zero-configuration tunneling mechanism can be used in such scenario
as well.
11. Security Considerations
11.1 Access Control
Zero-configuration Tunneling does not require explicit authentication
of the user. This essentially offers the IPv6 service to any of the
provider IPv4 customers.
Suryanarayanan, et al. Expires April 18, 2005 [Page 15]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
Should an Operator/Administrator wish to implement additional access
control, e.g., limiting the service to certain customers, then in the
case where IPv4 source spoofing prevention is performed within the
Operators network, mere filtering on the IPv4 address could give
this. Such mechanisms, however, would be external to the tunnel
protocol itself and are outside the scope of this document.
In any case, the service should be limited to the provider network
and the assumption that the Zero-Configuration Tunneling site is
protected from protocol-41 encapsulated packets arriving from
external IPv4 networks, should indeed effectively prevent access to
the service from outside the provider network.
If for some reason an Operator/Administrator deviates from the above
assumption or if additional security measures are wanted (just in
case) then proper ingress filtering in the ISP core network together
with IPv4 source address filtering would limit the access to internal
customers only.
If the mentioned 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.
11.2 General Threats
The following have been identified as potential threats applicable to
the network and infrastructure nodes within a Zero-Configuration
Tunneling site regardless of whether the individual node implements
Zero-Configuration Tunneling or not:
o It may be possible to use a tunnel server to reflect tunneled
packets into the network, similar to the 6to4-reflection attacks
identified in [15].
o In the case of no internal Firewalls or NATs and no interaction
with such being performed by the tunnel protocol, the
Zero-configuration site must be kept penetrable for intra-site
IPv6-in-IPv4 protocol-41 encapsulated packets. This may open up
for threats to end-hosts that rely on the network infrastructure
to filter out Protocol-41 encapsulated packets.
o Zero-configuration tunneling may open up threats to other
mechanisms in the network that rely on Protocol-41 encapsulation.
Detailed analysis of the validity of these threats will have to
depend on the particular Zero-Configuration solution. In general it
could be noted that attacks based on the above threats largely should
Suryanarayanan, et al. Expires April 18, 2005 [Page 16]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
be preventable if the end-hosts in the network implement appropriate
drop policies, either simple drop all protocol-41 policies or more
differentiated policies based, e.g., on source addresses.
11.3 Threats to nodes implementing Zero-Configuration Tunneling
The following considerations apply to the situation where
Zero-Configuration Tunneling is deployed in between tunnel servers
and end-hosts only.
Special security considerations for the usage of Zero-Configuration
Tunneling for direct tunneling in between end-hosts is given in
Section 12.4.
11.3.1 Threats to end-hosts
In current IPv6 networks hosts need to trust on the benevolence of
their default routers as well as hosts must trust that anyone
impersonating as a router is indeed one, see, e.g., the trust models
and threats described in [16].
Future multi-access IPv6 networks may rely on SEND mechanisms, i.e.,
mechanisms developed in the SEND WG inorder to mitigate the threats
described in [16], to establish a trust relationship in between host
and routers.
In this context is it constructive to look at the following three
categories of Zero-Configuration Tunneling sites:
1. Environments with IPv4 source address spoofing prevention, e.g.
3GPP environments and "filtered" ISP and Unmanaged environments.
2. Open, un-trusted environments without IPv4 source address
spoofing prevention, e.g., ȼun-filteredȫ ISP and Unmanaged
environments.
3. Closed, trusted, environments without IPv4 source address
spoofing prevention, e.g., Enterprise environments.
In all environments, but in open environments in particular, it is
assumed a prerequisite that a trustworthy Zero-Configuration tunnel
server end-point discovery mechanism is implemented.
Given this, then in a Zero-Configuration Tunneling Site of the first
category (1.), end-host can trust that packets they perceive as
stemming from Tunnel Servers (identified by IPv4 address) do actually
stem from such and further they can trust on the benevolence of these
Tunnel Servers.
Suryanarayanan, et al. Expires April 18, 2005 [Page 17]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
In Zero-Configuration Tunneling Sites of the latter two categories (2
and 3), then due to possibility of IPv4 address source spoofing, this
is not possible even when a trustworthy Zero-Configuration Tunnel
Server end-point discovery mechanism is implemented.
For trusted Zero-Configuration Tunneling Sites (category 3), the
threats may be considered to be manageable, as the environment itself
is assumed to be trusted. End-hosts in Zero-Configuration Tunneling
Sites of category 2, however, are exposed to the same threats as
hosts in non-SEND multi-access IPv6 networks.
11.3.2 Threats to Tunnel Servers
Zero-Configuration Tunneling may be deployed over very large IPv4
sites with low density of active tunnel clients but with a very high
number of dormant, but potential tunnel clients. Therefore
Denial-of-Service prevention by strict over provisioning of Tunnel
Server capacity is unlikely to be performed.
11.3.2.1 Tunnel State related risks
If the Tunnel Server relies on state to be kept per tunnel client
that it serves, the server risks resource exhaustion.
In this situation it is a security prerequisite that no node, whether
located within or outside the Zero-Configuration Tunneling site,
cannot initiate initialization of tunnel state for other entities
than itself (identified with IPv4 address).
But even in this case, then in situations where:
o IPv4 address spoofing is possible.
o An unlimited number of tunnels may created per node, e.g. in NAT
traversal environments it may still be possible for one or a
limited number of nodes to exhaust the resources of the server.
Such attacks, however, may be mitigated by performing IPv4 return
routability checks as an intrinsic part of tunnel initialization
(first case) or/and by limiting the number of tunnels that may be
created per node (second case).
11.3.2.2 Traffic related risks
Tunnel encapsulation is recognized as being more resource demanding
than mere packet forwarding. Given the same traffic load a Tunnel
Server must thus be more generously provisioned that a corresponding
router for it not to be more likely to get overthrown by large
Suryanarayanan, et al. Expires April 18, 2005 [Page 18]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
unexpected amounts of traffic than the router.
The authors have found no plausible treats to the tunnel service, due
to large unexpected amounts of traffic needing encapsulation, which
can be classified as a security threat rather than a case of
under-provision. This regardless of whether the traffic is due to a
surge in the density of active tunnel clients or due to a surge in
the traffic streams set-up by active clients.
11.3.2.3 Packet Delivery related threats
One potential risk related to packet delivery has been identified.
This risk is the equivalent of the threat to routers in multi-access
environments described in [16] Section 4.3.2.
The risk is associated with the special case where the tunnel
protocol requires special resource demanding and/or temporary state
creation actions to be taken by the Tunnel Server for delivery of
packets destined for not recently addressed Tunnel Clients. The
situation where such actions must be performed for all packets at all
times is considered to be unlikely. The actions required could be
buffering of packets while the reachability of the destined node is
being verified.
In case a malicious node (located either within or outside the
zero-configuration site) is able to continuously send packets to
continuously changing nodes, which by the Tunnel Server is perceived
as being existing or potential client nodes, the malicious node may
be able to exhaust the Tunnel Servers capability of delivering
packets by saturating the packet buffering mechanism and the
reachability state table as well as by keeping the Tunnel Server busy
determining the reachability state of the ever changing client nodes.
The above threat will not be relevant if reachabilityis performed as
an intrinsic part of the, thus stateful, tunnel protocol, e.g., by
relying on periodically transmitted keep alive messages.
11.4 Implications of Direct Tunneling
In case direct tunneling in between end-hosts is provided by the
tunneling protocol, it will not (as described in Section 1.3.1) be
possibly for end-hosts to filter out received Protocol-41
encapsulated packets based on whether the IPv4 source is an address
belonging to a trusted or perceived Tunnel Server as such behavior
evidently would break direct tunneling.
As other end-hosts generally are non-trusted, direct tunneling may
thus open up for attacks against IPv6 ingress filtering.
Suryanarayanan, et al. Expires April 18, 2005 [Page 19]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
Detailed analysis of the validity of this threat will have to depend
on the particular zero-configuration solution.
12. Acknowledgements
The work done by the authors on the zero-configuration tunneling
requirements for 3GPP ([14]) and on assisted-tunneling ([5]), has
been the main inspiration for the Zero-Configuration Tunneling
requirements work.
This work has benefited from input and comments provided by IPv6 Team
in Samsung India Software Operations (India) for the initial phase of
the work.
The authors would like to acknowledge also the inputs from Pekka
Savola and the European Commission support in the co-funding of the
Euro6IX project, where this work is being developed.
13. References
13.1 Normative References
13.2 Informative References
[1] Bound, J., "IPv6 Enterprise Network Scenarios",
draft-ietf-v6ops-ent-scenarios-05 (work in progress), July
2004.
[2] 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.
[3] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged
Networks", draft-ietf-v6ops-unmaneval-03 (work in progress),
June 2004.
[4] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks",
draft-ietf-v6ops-3gpp-analysis-10 (work in progress), May 2004.
[5] "Requirements for assisted tunneling",
draft-ietf-v6ops-assisted-tunneling-requirements-00 (work in
progress), June 2004.
[6] 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.
Suryanarayanan, et al. Expires April 18, 2005 [Page 20]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
[7] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 (work in
progress), September 2004.
[8] Wasserman, M., "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314, September
2002.
[9] Loughney, J., "IPv6 Node Requirements",
draft-ietf-ipv6-node-requirements-11 (work in progress), August
2004.
[10] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[11] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[12] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[13] Palet, J., "IPv6 Tunnel End-point Automatic Discovery
Mechanism", draft-palet-v6ops-solution-tun-auto-disc-00 (work
in progress), September 2004.
[14] Nielsen, k., "Goals for Zero-Configuration Tunneling in 3GPP",
draft-nielsen-v6ops-3GPP-zeroconf-goals-00 (work in progress),
October 2004.
[15] Savola, P., "Security Considerations for 6to4",
draft-ietf-v6ops-6to4-security-04 (work in progress), July
2004.
[16] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
Authors' Addresses
Radhakrishnan Suryanarayanan
Samsung India Software Operations
No. 3/1 Millers Road
Bangalore
India
Phone: +91 80 51197777
EMail: rkrishnan.s@samsung.com
Suryanarayanan, et al. Expires April 18, 2005 [Page 21]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
Syam Madanapalli
Samsung India Software Operations
No. 3/1 Millers Road
Bangalore
India
Phone: +91 80 51197777
EMail: syam@samsung.com
Karen Egede Nielsen
Ericsson
Skanderborgvej 232
8260 Viby J
Denmark
Phone: +45 89 38 51 00
EMail: karen.e.nielsen@ericsson.com
Florent Parent
Hexago
2875 boul. Laurier, bureau 300
Sainte-Foy, QC G1V 2M2
Canada
EMail: florent.parent@hexago.com
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
Appendix A. Out of Scope
[Editor's Note: This appendix can be removed in a future revision of
this document]
The following issues have been considered as being out of scope of
this work:
o DNS: DNS registration of the IPv6 addresses allocated to dual
Suryanarayanan, et al. Expires April 18, 2005 [Page 22]
Internet-Draft Zero-Configuration Tunneling Requirements October 2004
stack nodes while deploying Zero-Configuration Tunneling for IPv6
connectivity.
o Mobile IPv6: Support of Mobile IPv6 usage over the tunnel-link;
here under potential mechanisms required to support MIPv6 movement
detection as well as fast tunnel set-up for Mobile IPv6 session
survivability.
Suryanarayanan, et al. Expires April 18, 2005 [Page 23]
Internet-Draft Zero-Configuration Tunneling Requirements October 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 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 (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.
Suryanarayanan, et al. Expires April 18, 2005 [Page 24]