[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-palet-v6tc-goals-tunneling

   Network Working Group                                      K. Nielsen
   INTERNET-DRAFT                                               Ericsson
                                                              M. Morelli
   Expires: April 4, 2005                             Telecom Italia Lab
                                                                J. Palet
                                                             Consulintel
                                                             J. Soininen
                                                                   Nokia
                                                             J. Wiljakka
                                                                   Nokia

                                                         October 5, 2004

               Goals for Zero-Configuration Tunneling in 3GPP
              <draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt>


Status of this memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668 (BCP 79).

   By submitting this Internet-Draft, I accept the provisions of Section
   [#3] of RFC 3667 (BCP 78).

   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 cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Abstract

   Various types of IPv6-IPv4 tunneling are envisaged to be required in
   the transition period from IPv4 networking to IPv6 networking, or
   more precisely, in the transition period from IPv4 only networking to
   dual or mixed IPv6 and IPv4 networking.




                                                                [Page 1]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   Zero-Configuration Tunneling is the term used for a minimalistic
   IPv6-in-IPv4 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.

   This document describes the set of goals to be fulfilled by a Zero-
   Configuration Tunneling protocol in the 3GPP environment.


Table of Contents

   1. Introduction.....................................................3
   2. Terminology......................................................4
   3. Scope and Limitations............................................5
      3.1. IPv6 address allocation, Scope and Limitations:.............5
      3.2. IPv6 tunnel link characteristics, Scope and Limitations:....5
   4. Assumptions and Prerequisites....................................6
      4.1. Applicability Assumptions...................................6
      4.2. 3GPP Prerequisites..........................................6
   5. Timing...........................................................7
   6. Goals............................................................7
      6.1. Simplicity..................................................8
      6.2. Automated IPv6-in-IPv4 tunnel establishment.................8
      6.3. Use native when available...................................9
      6.4. Easy to deploy and Easy to Phase-out with no modifications on
      existing equipment...............................................9
      6.5. Tunnel Server End-Point Auto-Discovery.....................10
      6.6. Address Assignment.........................................10
      6.7. Tunnel Link Sustainability.................................10
      6.8. Tunnel End-Point Reachability Detection....................11
      6.9. Private and public IPv4 addresses..........................11
      6.10. Scalability, Load Balancing...............................11
      6.11. Security..................................................11
   7. Non Goals.......................................................11
      7.1. NAT and Firewall Traversal.................................12
      7.2. IPv6 DNS...................................................12
      7.3. Extensibility..............................................12
      7.4. Registration burden........................................12
   8. Stateful or Stateless...........................................12
   9. Security Considerations.........................................13
      9.1. Threats to existing network infrastructures................13
      9.2. Threats to nodes implementing Zero-Configuration Tunneling.14
         9.2.1. Threats to end-hosts..................................14
         9.2.2. Threats to Tunnel Servers.............................15
            9.2.2.1. Tunnel State related risks.......................15
            9.2.2.2. Traffic related risks............................15
            9.2.2.3. Packet Delivery related threats..................16
      9.3. Implications of Direct Tunneling...........................16
   10. Acknowledgments................................................17
   11. Authors Addresses..............................................17
   12. Changes from draft-nielsen-v6ops-zeroconf-goals-01.txt.........18



                                                                [Page 2]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   13. Informative References.........................................18
   Appendix A Out of Scope............................................19

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., [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 to denote a simplistic
   automatic IPv6-in-IPv4 tunneling mechanism.

   Zero-Configuration Tunneling is intended to provide a basic set of
   tunneling features only, and intentionally so. The scope of Zero-
   Configuration Tunneling is not to provide emulation of the full suite
   of native IPv6 connectivity functions as defined by [7], [8] and [9];
   rather the focus is to provide a minimal set of features required for
   automatic establishment of IPv6 connectivity.

   IPv6-in-IPv4 tunneling is envisaged to be deployed in 3GPP networks
   as an initial and temporary mechanism to provide limited and basic
   IPv6 connectivity services only. The IPv6-in-IPv4 tunneling mechanism
   demanded by the 3GPP environment falls within the realm of Zero-
   Configuration Tunneling.

   Native IPv6 like 3GPP connectivity services, e.g. services including
   flexible charging and quality of service on demand, will in 3GPP
   environments be feasible by virtue of true native IPv6 only. This is
   due to the interrelation between the native IPv6 3GPP service and
   various 3GPP signaling interfaces. The latter which is not envisaged
   upgraded to support the IPv6-in-IPv4 tunneling situation.

   It is important to note that the IPv6 connectivity provided by 3GPP
   Zero-Configuration IPv6-in-IPv4 tunneling does not compare with the
   native IPv6 3GPP connectivity in terms of the services offered. This
   differentiates the 3GPP IPv6-in-IPv4 tunneling transition case
   somewhat from some of the other transition scenarios considered in
   the IETF v6ops WG and unlike some of these scenarios, the 3GPP IPv6-
   in-IPv4 tunneling deployment case is not a case of progressive and
   gradual roll out of native IPv6-like services. Rather, Zero-




                                                                [Page 3]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   Configuration tunneling will in the 3GPP environment be deployed for
   the following purposes:
      - To provide temporary provisioning of basic IPv6 services, which
        users may deploy for the simplest IPv6 services only.
      - To allow an Operator, possibly a native IPv6 enabled Operator,
        to provide basic IPv6 services to users roaming into foreign
        networks which supports IPv4 bearer connectivity only.


   Unless otherwise specified then in this document the reference, IPv6-
   in-IPv4 encapsulation as defined in [1], 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 [1]. 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 above
   reference.


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:
   A dual-stack node performing IPv6-in-IPv4 tunnel
   encapsulation/decapsulation in accordance with Zero-Configuration
   Tunneling.

   Tunnel Server:
   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 tunneling here refer to the case where end-hosts located
   within the same Zero-Configuration Tunneling site may circumvent the
   Tunnel Server and communicate directly using the tunnel protocol.




                                                                [Page 4]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


3. Scope and Limitations

   The scope of Zero-Configuration Tunneling in the 3GPP network
   environment is restricted to an absolute minimal set of functions
   required to provide automatic IPv6 connectivity establishment to dual
   stack nodes by means of IPv6-in-IPv4 encapsulation as defined in [1]
   to Tunnel Servers under the assumptions and prerequisites described
   in Section 4.

   Zero-Configuration Tunneling in the 3GPP network environment does not
   attempt to provide emulation of the full set of native IPv6
   connectivity functions as defined by [7], [8] and [9].

3.1. IPv6 address allocation, Scope and Limitations:

   The primary goal of 3GPP Zero-Configuration Tunneling is to provide
   IPv6 connectivity to nodes on an individual basis. By this it is
   meant that it is only an explicit goal to have a /128 address
   allocated for global connectivity on the tunnel link. As such optimal
   IPv6 connectivity provisioning in Personal Area Network (PAN)
   scenarios is not explicitly within the scope of Zero-Configuration
   Tunneling.

   It is not explicitly within the scope of Zero-Configuration Tunneling
   in the 3GPP network environment to support usage of privacy IPv6
   extensions as defined in [12].

   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.

3.2. IPv6 tunnel link characteristics, Scope and Limitations:

   Direct tunneling is neither an explicit goal nor explicitly excluded
   in Zero-Configuration Tunneling in the 3GPP network environment.

   It is not an explicit requirement for the 3GPP 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 they are
   communicating (or wish to start communicate). This may be achieved
   using IPv6 Neighbor Discovery mechanism ([13]) based on unicast link-



                                                                [Page 5]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   local packet exchanges (or link-local multicast if such is supported)
   but it may also be achieved by altogether different mechanisms.

4. Assumptions and Prerequisites

4.1. Applicability Assumptions

   The aim of the document is to define the set of goals to be fulfilled
   by 3GPP Zero-Configuration Tunneling when the following assumptions
   are made on the 3GPP deployment environment:

      - IPv4 source addresses spoofing within the Zero-Configuration
        Tunneling site is prevented.
      - The Zero-Configuration Tunneling site is protected from
        protocol-41 encapsulated packets arriving from external IPv4
        networks.
      - 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.
      - The user is being authenticated to the network by means external
        to the tunneling protocol and other than that no additional
        authentication/registration mechanisms are required.

   Plus in addition:

      - There are no NATs in between the tunnel endpoints in the Zero-
        Configuration Tunneling site.
      - The Zero-Configuration Tunneling network is fully penetrable for
        intra-site IPv6-in-IPv4 Protocol 41 traffic.

   Finally, it is a prerequisite that the tunnel protocol must work in
   IPv4 network environments, as the 3GPP network environment, where
   IPv4 multicast is not provided.

   The above assumptions are readily applicable to the 3GPP tunneling
   transition scenario described in [4], section 3.1. The specific
   transition scenario considered there and here is the scenario where a
   3GPP UE deploys IPv6-in-IPv4 tunneling towards a Tunnel Server
   located in its Home Operators network, this regardless of whether the
   UE is located at an IPv4-only segment of its Home Operators network
   or at an IPv4-only segment of a Foreign Operators network. In both
   cases, it is assumed that the 3GPP UE is attached to the logical IPv4
   network of its Home Operator, i.e., the Home Operator provides the
   IPv4 address and the logical first hop link, read the IPv4 PDP
   context, is terminated at a GGSN of its Home Operator.

4.2. 3GPP Prerequisites

   3GPP Zero-Configuration Tunneling must work over 3GPP wireless
   networks. When considering the characteristics of 3GPP network links



                                                                [Page 6]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   and mobile terminals / User Equipment (UE), the following points need
   to be taken into account:
      - Link bandwidth (tunnel overhead / usage cost)
      - Link latency
      - UE battery power and derived implications on memory and
        processing power

   It is thus an explicit requirement for 3GPP Zero-Configuration
   Tunneling to comply well with the constrained conditions put on the
   above parameters by the 3GPP environments. The latter which commonly
   is recognized as translating into requirements for the protocol to
   operate with a limited number of message exchanges, small packet
   sizes and simple message processing.

   In this context it is note worthy that average round trip times in
   3GPP networks can be in the size of 0.2 to 1.5 seconds (0.2 to 0.8
   for 3G, 0.8 to 1.5 for 2.5G). This fact alone illustrates the need to
   keep the number of message exchanges required for tunnel
   initialization at an absolute minimum.

   Here we shall refer to a protocol as being lightweight when its
   demands on message exchanges, packet sizes and message processing
   complexity are sufficiently light for it to be readily applicable in
   environments characterized by the constrained conditions of 3GPP
   networks (as described above).

   As a mean to ensure that the protocol be lightweight it is considered
   preferable for the protocol to provide a simple set of functions
   only, even if it provides only a basic IPv6 service compared to the
   native one. It is although acknowledged that additional functionality
   doesn't necessarily automatically add complexity to the demands on
   the aforementioned parameters.

5. Timing

   For the purpose of 3GPP deployment it is a prerequisite that this
   tunneling protocol is provided within a very restrictive timescale.

   3GPP Release 6 documents, which ideally should refer to an
   appropriate solution, are being finalized at the time of writing of
   this document.

   Trial deployments, in which zero-configuration type of IPv6
   connectivity is provided in 3GPP environments, are starting up using
   experimental protocols at the time of writing this document.

6. Goals

   The goals to be achieved by Zero-Configuration Tunneling in the 3GPP
   network environment are detailed in the following subsections.




                                                                [Page 7]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


6.1. Simplicity

   By simplicity, we understand a tunnel protocol that is easy to
   implement in the targeted environment. Additionally, the protocol
   should provide a reasonable, limited set of basic IPv6 connectivity
   features.

   Further by simplicity we imply that the protocol must be lightweight.

6.2. Automated IPv6-in-IPv4 tunnel establishment

   The protocol should provide for the set up of IPv6-in-IPv4 tunnels,
   based on IPv6-in-IPv4 encapsulation as defined in [1], from dual-
   stack nodes, attached to IPv4-only networks, to Tunnel Servers.

   The IPv6-in-IPv4 tunnels and the IPv6 connectivity must be
   established in an automated manner, i.e., without requiring manual
   intervention at any of the tunnel end-points at tunnel establishment
   time.

   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.

   Comment:

   This goal is set to ensure that tunneled IPv6 connectivity can be
   established in an automated manner by invocation of the Zero-
   Configuration Tunneling function on an IPv4 network link.

   For IPv6 connectivity to be established automatically, processes
   within the node must be responsible for automatic invocation of the
   Zero-Configuration Tunneling function when appropriate. The operation
   of such activation - and deactivation - processes, as well as the
   indicators on which such mechanisms may rely to determine the
   appropriateness of tunneling, is not considered to be part of the
   tunnel protocol processing per se and is considered to be an issue
   for the node implementers.

   Generally speaking, however, it is anticipated that such processes
   will operate on the knowledge of whether IPv6 connectivity can be
   established or not, for a 3GPP UE specifically whether IPv6 PDP
   context activation succeeds or not.

   No goals are set as to whether Zero-Configuration Tunneling should be
   activated as default when native IPv6 connectivity is not available
   or only by an applications demand for (tunneled) IPv6 connectivity.
   As the general PDP context activation policies of an UE, e.g., see
   the considerations given in Section 3.1 of [4], this is considered
   determined by implementers, application developers and operators.



                                                                [Page 8]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004



   Further refinements of how the automated process should be carried
   out, and of the nature of the (IPv6) connectivity that should be
   provided, is given in some of the subsequent goals.

6.3. Use native when available

   The protocol must in no way restrict the native IPv6 capabilities of
   the client node.

   The node should not initiate Zero-Configuration Tunneling when native
   IPv6 connectivity is available.

   Comment:

   The fact that a node should not initiate Zero-Configuration Tunneling
   when native IPv6 connectivity is available is not considered to be a
   functional requirement on the tunnel protocol per se. Rather it is
   related to the activation and deactivation of the Zero-Configuration
   Tunneling function.

   On a 3GPP UE this translates into saying that the PDP context and
   Zero-Configuration Tunneling activation policies implemented on the
   UE should ensure that activation of IPv6 PDP contexts (when possible)
   take precedence over activation of Zero-Configuration Tunneling over
   IPv4 PDP contexts.

   The extend to which a 3GPP UE may try for native IPv6 availability,
   i.e., attempt for IPv6 PDP context activation, while moving around,
   is, as the general PDP context activation policies of an UE, left to
   be determined by UE implementers, application developers and
   operators. Possible choices could be to attempt for IPv6 PDP context
   activation once every time the IPv4 connectivity changes (e.g., IPv4
   PDP context deactivation due to roaming out of operator range) or,
   once every time a new IPv6 connectivity request is received from an
   application. Attempts for IPv6 PDP context activation could in
   principle also be done on the basis of Routing Area changes (change
   of SGSN).

6.4. Easy to deploy and Easy to Phase-out with no modifications on
   existing equipment

   The tunnel protocol should be easy to deploy into the existing IPv4
   and IPv6 network infrastructure.

   The tunnel protocol should have no major impact on protocols and
   infrastructure nodes deployed in existing infrastructures providing
   IPv4 and native IPv6 connectivity.

   The tunnel protocol should coexist and work seamlessly together with
   any native IPv6 infrastructure that gradually may be implemented in



                                                                [Page 9]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   the network. The tunnel protocol should have no negative implications
   on how such are implemented.

   The tunnel protocol must be easy to take out of service once native
   IPv6 is available.

6.5. Tunnel Server End-Point Auto-Discovery

   The tunnel protocol must provide a mechanism for automated end-point
   discovery by the virtue of which end-hosts automatically and at run-
   time can determine the IPv4 addresses of available Tunnel Servers.

   The discovery mechanism should rely on intrinsic services, read
   services already universally deployed, to the particular network
   environment. It should not require the addition of additional IP
   network infrastructure elements for this function only.

   Comment: The analysis done in [6] may apply.

6.6. Address Assignment

   The tunnel protocol must allow for the assignment of at least one
   globally routable (/128) IPv6 unicast address to use for tunneled
   IPv6 connectivity over the link provided by the Zero-Configuration
   Tunneling mechanism.

   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.7. Tunnel Link Sustainability

   The tunnel link established in between a host deploying Zero-
   Configuration Tunneling and an associated Tunnel Server should be
   expected to remain in administrative active state for the lifetime of
   the IPv6 address provided to the host.

   The tunnel protocol must not mandate keep-alive messages to be
   transmitted by the host simply in order to sustain tunnel link
   connectivity.

   Motivation: The fact that a 3GPP terminal, for the single purpose of
   transmitting keep-alive messages, could have to wake up the radio
   periodically, send a packet over the radio and possibly wait for
   response is undesirable for the following reasons:
      - The terminal cannot, as otherwise anticipated, be in dormant
        mode all the time it is idle. This has severe implications for
        the battery consumption of the device.
      - Radio resources are costly and sparse and consequently not to be
        used for what is considered to be unnecessary traffic.



                                                               [Page 10]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004



6.8. 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.

   The unicast neighbor reachability discovery functions provided by
   IPv6 Neighbor Discovery ([13]), i.e., unicast NS/NA exchanges, should
   be supported on the tunnel link.

6.9. 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.

   Motivation: Private IPv4 addresses are widely used in current 3GPP
   networks.

6.10. Scalability, Load Balancing

   In order to ensure the scalability of the tunnel service, in terms of
   not limiting the number of simultaneous connections to the service
   and consequently limiting possible service denial situations, it
   should be possible for a Service Provider to load-balance those
   connections among several available Tunnel Servers.

   Load balancing should be planned already during the early phases of
   deployment. Given adequate planning it should be possible for a
   Service Provider to seamlessly deploy additional Tunnel Servers in
   order to support an increased amount of Tunnel Clients.

   Comment: This may be achieved using load-balancing functions provided
   by the Tunnel Server End-point Discovery mechanism as detailed in
   [14].

6.11. Security

   The tunnel protocol should not impose any new vulnerability to the
   existing 3GPP network infrastructure.

   The tunnel protocol should not impose any new vulnerability to the
   nodes implementing the tunnel protocol than what is already present
   in existing multi-access IPv6 networks, where multiple hosts are
   served by the same router or possibly multiple routers.

7. Non Goals




                                                               [Page 11]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   Non-goals of 3GPP Zero-Configuration Tunneling are detailed in the
   following subsections.

   With the term Non-goals we refer to features that generally are
   believed to be applicable to tunneling, but which are not among the
   minimal set of required features of 3GPP Zero-Configuration
   Tunneling. The latter primarily because of the assumptions made on
   the applicability environments for 3GPP Zero-Configuration Tunneling,
   e.g., see Section 4.

7.1. NAT and Firewall Traversal

   NAT and Firewall traversal is not required due to the assumptions on
   the applicability environment.

   Moreover to minimize the tunneling overhead applied to the packets as
   well as in order to minimize the number of tunnel set-up signaling
   messages exchanged on the link, it is preferable that the protocol
   does not deploy the UDP encapsulation techniques, on which mechanisms
   able to traverse NATs and Firewalls normally rely.

7.2. IPv6 DNS

   By virtue of the assumptions on the applicability environments, the
   dual stack end-hosts can use IPv4 DNS discovery mechanisms and IPv4
   transport for DNS services.

   Given that IPv4 based DNS services are already available, it is not
   considered a requirement that the end-host should be able to deploy
   IPv6 based DNS services. Consequently, the tunnel protocol does not
   need to provide IPv6 DNS discovery mechanisms.

7.3. Extensibility

   As a minimal tunneling mechanism Zero-Configuration Tunneling targets
   IPv6 connectivity provisioning only. The protocol does not need to be
   readily extendable to other encapsulation mechanisms, e.g., IPv4-in-
   IPv6.

7.4. Registration burden

   Tunnel service registration is not required due to the assumptions on
   the applicability environment.

   In order to keep the simplicity and minimize the tunnel overhead it
   is desirable that the tunnel protocol not in itself (e.g., in order
   to meet the goals put forward in this document) mandates
   authenticated registration of the user.

8. Stateful or Stateless




                                                               [Page 12]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   By a stateful mechanism we mean a mechanism that require the Tunnel
   Server to maintain tunnel state per client it serves.

   Tunnel state here is considered to be any parameter kept by the
   server per client and without which the server is unable to serve the
   client (receive packets from/send packets to).

   Tunnel state must be distinguished from state used to optimize the
   packet delivery function of the tunnel server and which is kept in a
   fixed or upper limited amount of memory space, such as, e.g.,
   reachability information.

   It should be emphasized that this document makes no deliberate
   assumptions on whether a Zero-Configuration Tunneling solution should
   be based on a stateful or stateless Tunnel Server mechanism. Indeed
   it is anticipated that the goals of zero-configuration as put forward
   here could be served both by a stateless as well as by a stateful
   mechanism.

9. Security Considerations

   It is considered reasonable to assume that the following assumptions
   of Section 4 are valid in the particular 3GPP network environment:

      - IPv4 source addresses spoofing within the Zero-Configuration
        Tunneling site is prevented.
      - The Zero-Configuration Tunneling site is protected from
        protocol-41 encapsulated packets arriving from external IPv4
        networks.

   It is worthwhile to note that together these assumptions imply that
   the IPv4 source of all protocol-41 tunneled packets is legitimate.

9.1. Threats to existing network infrastructures

   As stated in Section 6.11 the tunnel protocol should not impose any
   new vulnerability to the existing network infrastructure.

   The following have been identified as potential threats opened up for
   by the deployment of Zero-Configuration Tunneling:

      - As the tunnel service is un-authenticated (not registered) it
        may be possible to use a tunnel server to reflect tunneled
        packets into the network, similar to the 6to4-reflection attacks
        identified in [10].
      - The Zero-configuration site must be kept fully 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 bogus protocol-41 encapsulated
        packets.




                                                               [Page 13]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


      - Zero-configuration tunneling may open up for 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
   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.

   The only known additional protocol-41 based mechanism that may be
   deployed in the 3GPP environment are Configured Tunnels ([1]) and in
   this case unauthorized packets should be dropped by the Configured
   Tunnel implementation.

9.2. 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 9.3.

   As stated in Section 6.11 the tunnel protocol should not impose any
   new vulnerability to the nodes implementing the tunnel protocol than
   what is already present in existing multi-access IPv6 networks where
   multiple hosts are served by the same router or possible multiple
   routers.

   Here it is implicitly assumed that the tunnel server(s) take the role
   of default routers and the end-nodes using Zero-Configuration
   Tunneling for IPv6 connectivity the role of hosts in multi-access
   environments.

9.2.1. Threats to end-hosts

   Given that all IPv4 sources of protocol-41 tunneled packets can be
   assumed to be legitimate, threats stemming from encapsulated packets
   sourced by nodes (addresses) other than nodes (addresses) which the
   end-hosts recognize as tunnel servers (identified by addresses) can,
   if not already an intrinsic part of the Zero-Configuration protocol,
   easily be mitigated by the implementation of appropriate
   differentiated (source addresses) drop policies in the end-hosts,
   i.e., accept only if source is tunnel server.

   In current multi-access IPv6 networks hosts need to trust on the
   benevolence of their default routers as well as hosts must trust that




                                                               [Page 14]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   anyone impersonating as a router is indeed one, see, e.g., the trust
   models and threats described in [11].

   Future multi-access IPv6 networks may rely on SEND mechanisms, i.e.,
   mechanisms developed in the SEND WG in order to mitigate the threats
   described in [11], to establish a trust relations ship in between
   host and routers.

   Given that IPv4 source address spoofing is not possible in Zero-
   Configuration Tunneling sites, then
      - for an end-host to trust that packets it perceives as stemming
        from tunnel servers do actually stem from such - as well as รป
      - for an end-host to trust on the benevolence of its tunnel
        servers,
   it suffices that a trustworthy tunnel server end-point discovery
   mechanism, read discovery of benevolent tunnel servers IPv4
   address(es), is implemented.

   In open environments, such as indeed the 3GPP environment, it is
   assumed a prerequisite that a trustworthy Zero-Configuration tunnel
   server end-point discovery mechanism is implemented.

9.2.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.

9.2.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, can
   initiate initialization of tunnel state for other entities than
   itself.

   Further it is a security prerequisite that the amount of tunnel
   state, e.g. one tunnel per client only, created and maintained per
   Tunnel Client, identified by e.g. its IPv4 address, is limited.

   Given these prerequisites, then for tunnel server resource exhaustion
   by tunnel state creation to be categorized as a security threat,
   rather than a case of under provisioning, requires a large number of
   tunnel clients to operate in co-action. This is thus not considered a
   plausible threat.

9.2.2.2. Traffic related risks



                                                               [Page 15]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004



   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
   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.

9.2.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 [11], 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.

9.3. 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 9.2.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 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.





                                                               [Page 16]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   Detailed analysis of the validity of this threat will have to depend
   on the particular zero-configuration solution.

10. Acknowledgments

   Prior work by J. Mulahusic on the requirements for UE tunneling has
   been considered in the initial stage of the work.

   This work has benefited from input and comments provided by Fred
   Templin in the initial phase of the work.

   Thanks are due to Pekka Savola and Radhakrishnan Suryanarayanan for
   many helpful comments and suggestions for improvements.

   Corresponding work on assisted-tunneling, [5], has been an
   inspiration for the Zero-Configuration Tunneling work.

   The authors would like to acknowledge the European Commission support
   in the co-funding of the Euro6IX project, where part of this work is
   being developed.


11. Authors Addresses

              Mario Morelli
              Telecom Italia Lab.
              Via Guglilmo Reiss Romoli, 274
              I-10148 Turin,
              Italy

              Phone: +39 011 228 7790
              Fax: +39 011 228 5069
              Email: mario.morelli@tilab.com


              Karen Egede Nielsen
              Ericsson
              Skanderborgvej 232
              8260 Viby J
              Denmark

              Phone: + 45 89 38 51 00
              Email: karen.e.nielsen@ericsson.com


              Jordi Palet Martinez
              Consulintel
              San Jose Artesano, 1
              Alcobendas - Madrid
              E-28108 - Spain




                                                               [Page 17]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


              Phone: +34 91 151 81 99
              Fax:   +34 91 151 81 98
              EMail: jordi.palet@consulintel.es

              Jonne Soininen
              Nokia
              Linnoitustie 6
              02600 ESPOO
              Finland

              Phone: +358 7180 08000
              EMail: jonne.soininen@nokia.com



              Juha Wiljakka
              Nokia
              Visiokatu 3
              33720 TAMPERE
              Finland

              Phone: +358 7180 48372
              EMail: juha.wiljakka@nokia.com




12. Changes from draft-nielsen-v6ops-zeroconf-goals-01.txt

      - Scope of document has been restricted to the 3GPP deployment
        environment.


13. Informative References

   [1]  Nordmark, E., Basic Transition Mechanisms for IPv6 Hosts and
        Routers, draft-ietf-v6ops-mech-v2-04.txt (work in progress),
        July 2004.
   [2]  Lind, M., Scenarios and Analysis for Introducing IPv6 into ISP
        Networks, draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work
        in progress), June 2004.
   [3]  Huitema, C., Evaluation of Transition Mechanisms for Unmanaged
        Networks, draft-ietf-v6ops-unmaneval-03.txt (work in progress),
        June 2004.
   [4]  Wiljakka, J., Analysis on IPv6 Transition in 3GPP Networks,
        draft-ietf-v6ops-3gpp-analysis-10.txt (work in progress), May
        2004.
   [5]  Durand, A., Requirements for assisted tunneling, draft-ietf-
        v6ops-assisted-tunneling-requirements-00.txt (work in progress),
        June 2004.




                                                               [Page 18]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   [6]  Palet, J., Analysis of IPv6 Tunnel End-point Discovery
        Mechanisms, draft-palet-v6ops-tun-auto-disc-01.txt (work in
        progress), June 2004.
   [7]  Wasserman, M., Recommendations for IPv6 in 3GPP standards, RFC
        3314.
   [8]  Loughney, J., IPv6 Node Requirements, draft-ietf-ipv6-node-
        requirements-10.txt (work in progress), August 2004.
   [9]  IAB, IESG, IAB/IESG Recommendations on IPv6 Address Allocations
        to Sites, RFC 3177.
   [10] Savola, P., Security Considerations for 6to4, draft-ietf-v6ops-
        6to4-security-04.txt (work in progress), July 2004.
   [11] Nikander, P., IPv6 Neighbor Discovery (ND) Trust Models and
        Threats, RFC 3756.
   [12] Narten, T., Privacy Extensions for Stateless Address
        Autoconfiguration in IPv6, RFC 3041.
   [13] Narten, T., Neighbor Discovery for IP Version 6 (IPv6), RFC
        2461.
   [14] Jordi, P., draft-palet-v6ops-solution-tun-auto-disc-00 (work in
        progress), September 2004.


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.


   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.


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in RFC 3667 (BCP 78) and RFC 3668 (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



                                                               [Page 19]

INTERNET-DRAFT          Zeroconf Tunneling Goals          October, 2004


   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.


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.


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.



This Internet-Draft expires April 4, 2005.























                                                               [Page 20]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/