[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-manyfolks-ipv6-cellular-host) 00 01 02 RFC 3316

INTERNET-DRAFT                                               Jari Arkko
Internet Engineering Task Force                            Peter Hedman
                                                        Gerben Kuijpers
                                                         Hesham Soliman
                                                               Ericsson
                                                          John Loughney
                                                         Pertti Suomela
                                                          Juha Wiljakka
                                                                  Nokia
Issued:  April 10, 2002
Expires: October 10, 2002

           IPv6 for Second and Third Generation Cellular Hosts
                  <draft-ietf-ipv6-cellular-host-01.txt>

Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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.

Abstract

   As increasing numbers of cellular hosts are being connected to the
   Internet, IPv6 becomes necessary. Examples of such hosts are devices
   used with General Packet Radio Service (GPRS) or Universal Mobile
   Telecommunications System (UMTS) networks. Standardization
   organizations are also making IPv6 mandatory in their newest
   specifications. However, the concept of IPv6 covers many aspects,
   numerous standards, a number of different situations and is still
   evolving. A rapid adoption of IPv6 is desired for cellular hosts. In
   addition, the characteristics of cellular links in terms of
   bandwidth, cost and delay put special requirements on IPv6. For
   these reasons it is necessary to understand how the IPv6 deployment
   in second and third generation cellular networks will start and
   which parts of IPv6 are used in which situations. This informational
   document lists basic components of IPv6 functionality and discusses
   some issues relating to the use of these components when operating
   over cellular interfaces.


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


 Abstract............................................................1
 1 Introduction......................................................3
  1.1 Scope of this Document.........................................3
  1.2 Abbreviations..................................................4
  1.4 Cellular Host IPv6 Features....................................5
 2 Basic IP..........................................................5
  2.1 RFC1981 - Path MTU Discovery for IP Version 6..................5
  2.2 RFC2373 - IP Version 6 Addressing Architecture.................5
  2.3 RFC2460 - Internet Protocol Version 6..........................6
  2.4 RFC2461 - Neighbor Discovery for IPv6..........................6
  2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration.............7
  2.6 RFC2463 - Internet Control Message Protocol for the IPv6.......7
  2.7 RFC2472 - IP version 6 over PPP................................8
  2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification.......8
  2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6..........8
  2.10 RFC2711 - IPv6 Router Alert Option............................8
  2.11 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers....8
  2.12 RFC3041 - Privacy Extensions for Address Configuration in IPv68
  2.13 RFC3056 - Connection of IPv6 Domains via IPv4 Clouds..........9
  2.14 Dynamic Host Configuration Protocol for IPv6 (DHCPv6).........9
  2.15 Default Address Selection for IPv6............................9
  2.16 DNS...........................................................9
 3 IP Security.......................................................9
  3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication......11
  3.2 RFC2401 - Security Architecture for the Internet Protocol.....11
  3.3 RFC2402 - IP Authentication Header............................11
  3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH............11
  3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH............11
  3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV...11
  3.7 RFC2406 - IP Encapsulating Security Payload (ESP).............11
  3.8 RFC2407 - The Internet IP Security DoI for ISAKMP.............11
  3.9 RFC2408 û Internet Security Association & Key Management Prot.12
  3.10 RFC2409 - The Internet Key Exchange (IKE)....................12
  3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec.12
  3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms.................13
  3.13 IP Security Remote Access....................................13
 4 IP Mobility......................................................13
 5 Security Considerations..........................................13
 6 References.......................................................15
  6.1 Normative.....................................................15
  6.2 Non-Normative.................................................17
 7 Acknowledgements.................................................18
 8 Authors' Addresses...............................................18
 Appendix A Revision History........................................19
 Appendix B Cellular Host IPv6 Addressing in the 3GPP Model.........19
 Appendix C Transition Issues.......................................20
 Appendix D Mobility Issues.........................................21

Manyfolks                                                    [Page 2]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


1 Introduction

   Technologies such as GPRS (General Packet Radio Service), UMTS
   (Universal Mobile Telecommunications System), and CDMA2000 (Code
   Division Multiple Access 2000, the name identifying the third
   generation technology of IS-95 CDMA standard and ANSI-41 network)
   are making it possible for cellular hosts to have an always-on
   connection to the Internet. IPv6 becomes necessary, as it is
   expected that the number of such cellular hosts will increase
   rapidly. Standardization organizations working with cellular
   technologies have recognized this and are making IPv6 mandatory in
   their newest specifications. 3GPP (Third Generation Partnership
   Project) has specified IPv6 support [3GPP-IPv6] as mandatory for
   future UMTS IP multimedia hosts [3GPP-IMS].

   Support for IPv6 and the introduction of UMTS starts with 3GPP
   Release 99 networks and hosts. IPv6 is specified as the only IP
   version supported in Release 5 for IP Multimedia Subsystem (IMS).

   Additionally, there is interest within the IPv6 working group about
   how IPv6 will be used by other organizations.  For example, the
   working group has developed Recommendations for IPv6 in 3GPP
   Standards [IPv6-3GPP].

   The functionality necessary to provide the connectivity through the
   cellular interface is outlined in this draft. For this document, the
   cellular interface is considered to be the interface that is used to
   connect to a cellular access network (e.g. GPRS or UMTS) and
   provides connectivity to IPv6 networks. The description is made from
   a cellular host point of view.

1.1 Scope of this Document

   This document lists IPv6 specifications and discusses some issues
   relating to the use of these specifications when operating over
   cellular interfaces. Such a specification is necessary in order to
   determine the optimal way to use IPv6 in a cellular environment.
   Important considerations are given in order to eliminate unnecessary
   user confusion with regards to configuration options, ensure
   interoperability and to provide an easy reference for those
   implementing IPv6 in a cellular host. The overarching desire is to
   ensure that cellular hosts are good citizens on the Internet.

   The main audiences of this document are the implementers who need
   guidance on what to implement in their cellular hosts, and cellular
   standardization organizations that need a reference to how IPv6
   should be used in their specifications.  Note that, at the time of
   writing this document, there is on-going work to define a general-
   purpose requirements document for IPv6 nodes.


Manyfolks                                                    [Page 3]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   For the purposes of this document, a cellular host is considered to
   be a host with a cellular interface (for example, one based on GPRS
   or UMTS standards). There are different ways to implement cellular
   hosts:

      - The host can be a "closed 2G or 3G host" with a very compact
         size and optimized applications, with no possibility to add
         or download applications that can have IP communications. An
         example of such a host is a very simple form of a mobile
         phone.
      -  The host can be an "open 2G or 3G host" with a compact size,
         but where it is possible to download applications; such as a
         PDA-type of phone.

   If a cellular host has additional interfaces on which IP is used,
   (such as Ethernet, WLAN, Bluetooth, etc.) then there may be
   additional requirements for the device, beyond what is discussed in
   this document.  Additionally, this document does not make any
   recommendations on the functionality required on laptop computers
   having a cellular interface such as a PC card, other than
   recommending link specific behavior on the cellular link.

   This document discusses IPv6 functionality as specified when this
   draft is written. Ongoing work on IPv6 may affect what is needed
   from future hosts. The reader should also be advised other relevant
   work exists for various other layers. Examples of this include the
   header compression work done in the IETF ROHC group, or the TCP work
   in [TCPWIRELESS].

1.2 Abbreviations

   2G          Second Generation Mobile Telecommunications, for example
               GSM and GPRS technologies.
   3G          Third Generation Mobile Telecommunications, for example
               UMTS technology.
   3GPP        Third Generation Partnership Project
   AH          Authentication Header
   APN         Access Point Name. The APN is a logical name referring
               to a GGSN and an external network.
   ESP         Encapsulating Security Payload
   ETSI        European Telecommunications Standards Institute
   IMS         IP Multimedia Subsystem
   GGSN        Gateway GPRS Support Node (a default router for 3GPP
               IPv6 cellular hosts)
   GPRS        General Packet Radio Service
   GSM         Global System for Mobile Communications
   IKE         Internet Key Exchange
   ISAKMP      Internet Security Association and Key Management
               Protocol
   MT          Mobile Terminal, for example, a mobile phone handset.
   MTU         Maximum Transmission Unit

Manyfolks                                                    [Page 4]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   PDP         Packet Data Protocol
   SGSN        Serving GPRS Support Node
   TE          Terminal Equipment, for example, a laptop attached
               through a 3GPP handset.
   UMTS        Universal Mobile Telecommunications System
   WLAN        Wireless LAN

1.4 Cellular Host IPv6 Features

   This specification defines IPv6 features for cellular hosts in three
   groups.

     Basic IP

          In this group, we describe the basic parts of IPv6.

     IP Security

          In this group, we discuss IP Security parts, as well as
          discuss the suitability of various security functions for
          different applications in cellular hosts.

     IP Mobility

          In this group, we discuss IP layer mobility functionality,
          and its usage scenarios in cellular hosts.

2 Basic IP

2.1 RFC1981 - Path MTU Discovery for IP Version 6

   Path MTU Discovery [RFC-1981] may be used.

   The IPv6 specification [RFC-2460] states in chapter 5 that "a
   minimal IPv6 implementation (e.g., in a boot ROM) may simply
   restrict itself to sending packets no larger than 1280 octets, and
   omit implementation of Path MTU Discovery."

   If Path MTU Discovery is not implemented then the sending packet
   size is limited to 1280 octets (standard limit in [RFC-2460]).
   However, if this is done, the cellular host must be able to receive
   packets with size up to the link MTU before reassembly. This is
   because the node at the other side of the link has no way of knowing
   less than the MTU is accepted.

2.2 RFC2373 - IP Version 6 Addressing Architecture

   The IPv6 Addressing Architecture [RFC-2373] is a mandatory part of
   IPv6. IPX & NSAP addresses should not be used. Currently, this
   standard is being updated by [ADDRARCHv3]; therefore, when this
   draft is approved, this must be supported as well.

Manyfolks                                                    [Page 5]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002



2.3 RFC2460 - Internet Protocol Version 6

   The Internet Protocol Version 6 is specified in [RFC-2460]. This
   standard is a mandatory part of IPv6.

   By definition, a cellular host acts as a host, not as a router.
   Implementation requirements for a cellular router are not defined in
   this document.

   Consequently, the cellular host must implement all non-router packet
   receive processing as described in RFC 2460.  This includes the
   generation of ICMPv6 error reports, and the processing of at least
   the following extension headers:

     - Hop-by-Hop Options header: at least the Pad1 and PadN options
     - Destination Options header: at least the Pad1 and PadN options
     - Routing (Type 0) header: final destination (host) processing
       only
     - Fragment header
     - AH and ESP headers (see also a discussion on the use of IPsec
       for various purposes in Section 3)
     - The No Next Header value

   Unrecognized options in Hop-by-Hop Options or Destination Options
   extensions must be processed as described in RFC 2460.

   The cellular host must follow the packet transmission rules in RFC
   2460.

   The cellular host must always be able to receive fragment headers.
   However, if it does not implement path MTU (Section 2.1) it may not
   need to send fragment headers.

   Cellular Hosts will act as the destination when processing the
   Routing Header. This will also ensure that the cellular hosts will
   not be inappropriately used as relays or components in Denial-of-
   Service attacks. Acting as the destination involves the following.
   The cellular hosts must check the Segments Left field in the header,
   and proceed if it is zero or one and the next address is one of the
   host's addresses. If not, however, the host must implement error
   checks as specified in section 4.4 of RFC 2460. There is no need for
   the host to send Routing Headers.

2.4 RFC2461 - Neighbor Discovery for IPv6

   Neighbor Discovery is described in [RFC-2461]. This standard is a
   mandatory part of IPv6.

2.4.1 Neighbor Discovery in 3GPP


Manyfolks                                                    [Page 6]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   In cellular networks, some Neighbor Discovery messages can cause
   unnecessary traffic and consume valuable (limited) bandwidth. All
   current cellular links resemble a point-to-point link; hence, the
   host's only neighbor on the cellular link is the default router that
   is already known through Router Discovery. This router most likely
   will not be a final destination for the host's traffic.
   Additionally, due to special characteristics of the cellular link,
   lower layer connectivity information should make it unnecessary to
   track the reachability of the router. Therefore, Neighbor
   Solicitation and Advertisement messages may be used for the cellular
   interface, but are not required. In addition, a cellular host should
   not send the link layer sub-option on its cellular interface, and
   should silently ignore it if received on the same interface.

   3GPP hosts only need to use Router Solicitations and Router
   Advertisements for 3GPP IPv6 Address Autoconfiguration. Neighbor
   Solicitations and Advertisements may be used for Neighbor
   Unreachability Detection (NUD). They are not required for 3GPP IPv6
   Stateless Address Autoconfiguration, since address duplication is
   not possible in this address assignment mechanism (see section
   2.5.1).

2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration

   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
   This standard is a mandatory part of IPv6.

2.5.1 Stateless Address Autoconfiguration in 3GPP

   A 3GPP cellular host must process a Router Advertisement as stated
   in chapter 5.5.3 of [RFC-2462].

   These cellular hosts need not perform Duplicate Address Detection on
   its cellular interface, as each delegated prefix is unique within
   its scope when allocated using the 3GPP IPv6 Stateless Address
   Autoconfiguration.

   See appendix B for more details on 3GPP IPv6 Stateless Address
   Autoconfiguration.

2.6 RFC2463 - Internet Control Message Protocol for the IPv6

   The Internet Control Message Protocol for the IPv6 is defined [RFC-
   2463]. This standard is a mandatory part of IPv6.  Currently, this
   work is being updated.

   As per RFC 2463 section 2, ICMPv6 requirements must be fully
   implemented by every IPv6 node. See also Section 3 for an
   explanation of the use of IPsec for protecting ICMPv6
   communications.


Manyfolks                                                    [Page 7]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


2.7 RFC2472 - IP version 6 over PPP

   IPv6 over PPP [RFC-2472] must be supported for cellular hosts that
   implement PPP.

2.7.1 IP version 6 over PPP in 3GPP

   A 3GPP cellular host must support the IPv6CP interface identifier
   option. This option is needed to be able to connect other non-3GPP
   devices to the Internet using a PPP link between the 3GPP device
   (MT) and other devices (TE, e.g. a laptop). The MT performs the PDP
   Context activation based on a request from the TE. This results in
   an interface identifier to be suggested by the MT to the TE, using
   the IPv6CP option. To avoid any duplication in link-local addresses
   between the TE and the GGSN, the MT must always reject other
   suggested interface identifiers by the TE. This results in the TE
   always using the interface identifier suggested by the GGSN for its
   link-local address.

2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification

   Generic Packet Tunneling [RFC-2473] may be supported if needed for
   transition mechanisms and must be supported if the Mobile Node
   functionality of Mobile IP is implemented.

2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6

   Multicast Listener Discovery [RFC-2710] may be supported, if the
   cellular host supports multicast functionality. There is no need for
   MLD if the host supports only the well-known multicast addresses,
   such as the All Nodes Address or Solicited Node Multicast Address.

2.10 RFC2711 - IPv6 Router Alert Option

   The Router Alert Option [RFC-2711] may be supported. If the cellular
   host does not perform packet forwarding at the IP layer, the
   receiver side of the Router Alert Option may be omitted.

2.11 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers

   [RFC-2893] specifies a number of transition mechanisms for IPv6 hosts.
   Cellular hosts may support the dual stack mechanism mentioned in this
   standard. This also includes resolving addresses from the DNS and
   selecting the type of address for the correspondent host (IPv4 vs.
   IPv6). Cellular hosts should not support configured or automatic
   tunnels to avoid unnecessary tunneling over the air interface.

2.12 RFC3041 - Privacy Extensions for Address Configuration in IPv6


Manyfolks                                                    [Page 8]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   Privacy Extensions for Stateless Address Autoconfiguration [RFC-
   3041] may be used. Refer to section 5 for a discussion of the
   benefits of privacy extensions in a 3GPP environment.

2.13 RFC3056 - Connection of IPv6 Domains via IPv4 Clouds

   Connection of IPv6 domains via IPv4 clouds [RFC-3056] should not be
   supported to avoid unnecessary tunneling over the air interface. For
   a cellular host, this specification would mean capability to create
   6to4 tunnels starting from the cellular host itself. In a cellular
   environment, tunneling over the air interface should be minimized.
   Hence, 6to4 tunneling should be carried out by intermediate 6to4
   routers rather than the cellular host.

2.14 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

   The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be
   used. DHCPv6 is not needed when IPv6 stateless autoconfiguration is
   used, and no other functions of DHCPv6 are used.

2.15 Default Address Selection for IPv6

   Default Address Selection for IPv6 [DEFADDR] should be supported
   since cellular hosts can have more than one IPv6 address.

2.16 DNS

   Cellular hosts should support DNS, as described in [RFC-1034], [RFC-
   1035] and [RFC-1886].

   If DNS is used, a cellular host should perform DNS requests in the
   recursive mode, to limit signaling over the air interface.

3 IP Security

   IPsec [RFC-2401] is a fundamental part of IPv6, and support for AH
   and ESP is described as mandatory in the standards.

   The first part of this section discusses the applicability of IP
   Security and other security mechanisms for certain types of common
   tasks in cellular hosts. The second part, subsections 3.1 to 3.13,
   lists the RFCs related to IPsec and discusses the use of these parts
   of IPsec in a cellular context.

   In general, the need to use a security mechanism depends on the
   intended application for it. In order to gain an understanding on
   where different security mechanisms are useful and what limitations
   they have, we discuss a few example applications common in cellular
   hosts: end-to-end VPNs, web browsing, and IPv6 control message
   protection. We cannot list all possible services here, and in
   general, we expect application protocol standards to have

Manyfolks                                                    [Page 9]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   requirements on what security services they must employ. For new
   applications, it is strongly suggested that some of the existing set
   of security mechanisms be used rather than new ones developed,
   adding to the amount of memory and implementation effort needed for
   a host supporting multiple services. Note that cellular hosts able
   to download applications must be prepared to offer sufficient
   security services for these applications regardless of the needs of
   the initial set of applications in those hosts.

   Cellular hosts that provide an end-to-end VPN service to a corporate
   intranet, for example, should use IPsec and IKE for this purpose. An
   IPsec Remote Access solution should also be supported. The set of
   standards necessary for such an "application" are discussed in
   sections 3.1 to 3.13.

   Note that in other applications it may not be necessary to use IKE.
   For instance, hosts may use IPsec ESP [RFC-2406] for protecting SIP
   signaling in the IMS [3GPP-ACC] but provide authentication and key
   management through another mechanism such as UMTS AKA
   (Authentication and Key Agreement) [UMTS-AKA].

   Cellular hosts that provide a web browsing service should use TLS
   [RFC-2246]. The fact that just TLS should be the protocol to provide
   web security relates to current deployment and the suitability of
   the single-side certificate trust model for this application.
   Without security, the user would be blocked from some of the sites -
   such as e-commerce sites - that do require security.

   Cellular hosts may also wish to protect their IPv6 control
   communications, e.g. ICMPv6 or Neighbor Discovery. IPsec is the
   recommended approach for this purpose, and it works well towards a
   specific home server, such as a corporate gateway. However, neither
   IPsec nor other existing security services are very helpful in
   securing communications to the local next hop routers (GGSNs) or
   other 3GPP nodes in a global roaming situation. This is in part due
   to the difficulties in establishing a suitable trust infrastructure
   for creating the necessary Security Associations (SAs). In order for
   a host to create a SA with the next hop router for the purposes of
   securing the router and neighbor discovery tasks would mean the
   following. First, both the routers and all cellular hosts would have
   to be registered to a PKI system. Second, a trusted Certificate
   Authority (CA) would have to be found that encompasses both the
   visiting cellular host of an operator as well as the infrastructure
   of another operator. It is not clear if this is possible with
   today's technology. Furthermore, as [ICMPIKEv6] points out, dynamic
   SA negotiation can't be used for the protection of the first few
   connectivity establishment messages in ICMPv6. Roaming nodes may
   have difficulty providing manually keyed SAs with their current
   local routers. For these reasons, it is typically not possible to
   provide pure IPv6 router and infrastructure protection except in a
   very limited manner.

Manyfolks                                                    [Page 10]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002



   The following sections list standards related to the IPsec
   functionality, and discuss their applicability in a cellular
   context. The latter discussion focuses on the use of IPsec as a VPN
   mechanism towards a particular corporate network, and does not
   necessarily apply to other usage scenarios; in some other context, a
   different set of protocols may need to be employed. In particular,
   the below discussion is not relevant for applications that use other
   security services than IPsec.

3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication

   This standard [RFC-2104] must be supported. It is referenced by RFC
   2403 that describes how IPsec protects the integrity of packets.

3.2 RFC2401 - Security Architecture for the Internet Protocol

   This standard [RFC-2401] must be supported.

3.3 RFC2402 - IP Authentication Header

   This standard [RFC-2402] must be supported. The IPsec WG has
   discussed the role of AH in the future, and it is possible that it
   will be made optional in the future versions of the IPsec protocol
   set. Implementers are recommended to take this in account.

3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH

   This standard [RFC-2403] must be supported.

3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH

   This standard [RFC-2404] must be supported.

3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV

   This standard [RFC-2405] may be supported. It is, however,
   recommended that stronger algorithms than DES be used.  Algorithms,
   such as AES, are undergoing work in the IPsec working group.

3.7 RFC2406 - IP Encapsulating Security Payload (ESP)

   This standard [RFC-2406] must be supported.

3.8 RFC2407 - The Internet IP Security DoI for ISAKMP

   Automatic key management, [RFC-2408] and [RFC-2409], is not a
   mandatory part of the IP Security Architecture. Note, however, that
   in the cellular environment the IP addresses of a host may change
   dynamically. For this reason the use of manually configured Security
   Associations is not practical, as the newest host address would have

Manyfolks                                                    [Page 11]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   to be updated to the SA database of the peer as well. Any key
   management mechanism may be used, but ISAKMP/IKE is the standard one
   and recommended here for the VPN service.

   It is likely that several simplifying assumptions can be made in the
   cellular environment, with respect to the mandated parts of the IP
   Security DoI, ISAKMP, and IKE. Although work on such simplifications
   would be useful, is not described here.

3.9 RFC2408 û Internet Security Association and Key Management Protocol

   This standard [RFC-2408] may be supported according to the IPv6
   standards, but may be necessary in some applications, as described
   in Section 3.8.

3.10 RFC2409 - The Internet Key Exchange (IKE)

   This standard [RFC-2409] may be supported according to the IPv6
   standards, but may be necessary in some applications, as described
   in Section 3.8.

   Interactions with the ICMPv6 packets and IPsec policies may cause
   unexpected behavior for IKE-based SA negotiation unless some special
   handling is performed in the implementations.

   The ICMPv6 protocol provides many functions, which in IPv4 were
   either non-existent or provided by lower layers. For instance, IPv6
   implements address resolution using an IP packet, ICMPv6 Neighbor
   Solicitation message. In contrast, IPv4 uses an ARP message at a
   lower layer.

   The IPsec architecture has a Security Policy Database that specifies
   which traffic is protected, and how. It turns out that the
   specification of policies in the presence of ICMPv6 traffic is not
   easy. For instance, a simple policy of protecting all traffic
   between two hosts on the same network would trap even address
   resolution messages, leading to a situation where IKE can't
   establish a Security Association since in order to send the IKE UDP
   packets one would have had to send the Neighbor Solicitation
   Message, which would have required an SA.

   In order to avoid this problem, this specification recommends that
   Neighbor Solicitation, Neighbor Advertisement, Router Solicitation,
   and Router Advertisement messages must not lead to the use of IKE-
   based SA negotiation. The Redirect message should not lead to the
   use of IKE-based SA negotiation. Other ICMPv6 messages may use IKE-
   based SA negotiation as is desired in the Security Policy Data Base.

3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec

   This standard [RFC-2410] must be supported.

Manyfolks                                                    [Page 12]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002



3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms

   This standard [RFC-2451] must be supported if encryption algorithms
   other than DES are implemented, e.g.: CAST-128, RC5, IDEA, Blowfish,
   3DES.

3.13 IP Security Remote Access

   IPsec is often used in situations where legacy RADIUS or other
   authentication is desired instead of PKI-based authentication.
   Cellular hosts offering DES services to corporate intranets should
   support remote access solutions, which are currently being defined
   by the IETF.

4 IP Mobility

   Mobile IPv6 manages IP mobility resulting from the change in Care of
   Address when a host moves within the Internet topology.

   However, at the time this is being written Mobile IPv6 specification
   is not yet a standard and may change. Some aspects of securing MIPv6
   are also currently being debated. Yet, at the same time the first
   cellular IPv6 hosts need to be produced. The implementers should
   therefore consider the implications of relying on preliminary
   information. Appendix D discusses certain functions that are
   particularly prone to modifications, and describe the tradeoffs
   involved.

5 Security Considerations

   This document does not specify any new protocols or functionality,
   and as such, it does not introduce any new security vulnerabilities.
   However, specific profiles of IPv6 functionality are proposed for
   different situations, and vulnerabilities may open or close
   depending on which functionality is included and what is not. There
   are also aspects of the cellular environment that make certain types
   of vulnerabilities more severe. In the following, we discuss both of
   these issues:

    -  The suggested limitations (Section 2.3) in the processing of
       routing headers limits also exposure to Denial-of-Service
       attacks through cellular hosts.

    -  IPv6 addressing privacy [RFC3041] may be used in cellular
       hosts. However, it should be noted that in the 3GPP model, the
       network would assign new addresses, in most cases, to hosts in
       roaming situations and typically, also when the cellular hosts
       activate a PDP context. This means that 3GPP networks will
       already provide a limited form of addressing privacy, and no
       global tracking of a single host is possible through its

Manyfolks                                                    [Page 13]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


       address. On the other hand, since a GGSN's coverage area is
       expected to be very large when compared to currently deployed
       default routers (no handovers between GGSNs are possible), a
       cellular host can keep an address for a long time. Hence, IPv6
       addressing privacy can be used for additional privacy during
       the time the host is on and in the same area. The privacy
       features can also be used to e.g. make different transport
       sessions appear to come from different IP addresses. However,
       it is not clear that these additional efforts confuse potential
       observers any further, as they could monitor only the network
       prefix part.

    -  The use of various security services such as IPsec or TLS in
       the connection of typical applications in cellular hosts is
       discussed in Chapter 3 and recommendations are given there.

    -  Chapter 3 also discusses under what conditions it is possible
       to provide IPsec protection of e.g. ICMPv6 communications

    -  The airtime used by cellular hosts is expensive. In some cases,
       users are billed according to the amount of data they transfer
       to and from their host. It is crucial for both the network and
       the users that the airtime is used correctly and no extra
       charges are applied to users due to misbehaving third parties.
       The cellular links also have a limited capacity, which means
       that they may not necessarily be able to accommodate more
       traffic than what the user selected, such as a multimedia call.
       Additional traffic might interfere with the service level
       experienced by the user. While QoS mechanisms mitigate these
       problems to an extent, it is still apparent that Denial-of-
       Service aspects may be highlighted in the cellular environment.
       It is possible for existing DoS attacks that use for instance
       packet amplification to be substantially more damaging in this
       environment. How these attacks can be protected against is
       still an area of further study. It is also often easy to fill
       the cellular link and queues on both sides with additional or
       large packets.

    -  In certain areas of the world, it is possible to buy a prepaid
       cellular subscription without presenting personal
       identification. This could be leveraged by attackers that wish
       to remain unidentified. We note that while the user hasn't been
       identified, the equipment still is; the operators can follow
       the identity of the device and block it from further use. The
       operators must have procedures in place to take notice of third
       party complaints regarding the use of their customers' devices.
       It may also be necessary for the operators to have attack
       detection tools that enable them to efficiently detect attacks
       launched from the cellular hosts.


Manyfolks                                                    [Page 14]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


    -  Cellular devices that have local network interfaces (such as
       IrDA or Bluetooth) may be used to launch attacks through them,
       unless the local interfaces are secured in an appropriate
       manner. Therefore, we recommend that any local network
       interface should have access controls to prevent by passers
       from using the cellular host as an intermediary.

6 References

6.1 Normative

   [ADDRARCHv3]   Hinden, R. and Deering, S. "IP Version 6 Addressing
                  Architecture", Work in progress.

   [DEFADDR]      Draves, R., "Default Address Selection for IPv6",
                  Work in progress.

   [DHCPv6]       Bound, J. et al., "Dynamic Host Configuration
                  Protocol for IPv6 (DHCPv6)", Work in progress.

   [RFC-1981]     McCann, J., Mogul, J. and Deering, S., "Path MTU
                  Discovery for IP version 6", RFC 1981, August 1996.

   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
                  specification", STD 13, RFC 1035, November 1987.

   [RFC-1886]     Thomson, S. and Huitema, C., "DNS Extensions to
                  support IP version 6, RFC 1886, December 1995.

   [RFC-2104]     Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
                  Keyed-Hashing for Message Authentication", RFC 2104,
                  February 1997.

   [RFC-2246]     Dierks, T. and Allen, C., "The TLS Protocol Version
                  1.0", RFC 2246, January 1999

   [RFC-2373]     Hinden, R. and Deering, S., "IP Version 6 Addressing
                  Architecture", RFC 2373, July 1998.

   [RFC-2401]     Kent, S. and Atkinson, R., "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [RFC-2402]     Kent, S. and Atkinson, R.,  "IP Authentication
                  Header", RFC 2402, November 1998.

   [RFC-2403]     Madson, C., and Glenn, R., "The Use of HMAC-MD5
                  within ESP and AH", RFC 2403, November 1998.

   [RFC-2404]     Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
                  within ESP and AH", RFC 2404, November 1998.


Manyfolks                                                    [Page 15]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   [RFC-2405]     Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
                  Algorithm With Explicit IV", RFC 2405, November 1998.

   [RFC-2406]     Kent, S. and Atkinson, R., "IP Encapsulating Security
                  Protocol (ESP)", RFC 2406, November 1998.

   [RFC-2407]     Piper, D., "The Internet IP Security Domain of
                  Interpretation for ISAKMP", RFC 2407, November 1998.

   [RFC-2408]     Maughan, D., Schertler, M., Schneider, M., and
                  Turner, J., "Internet Security Association and Key
                  Management Protocol (ISAKMP)", RFC 2408, November
                  1998.

   [RFC-2409]     Harkins, D., and Carrel, D., "The Internet Key
                  Exchange (IKE)", RFC 2409, November 1998.

   [RFC-2410]     Glenn, R. and Kent, S., "The NULL Encryption
                  Algorithm and Its Use With IPsec", RFC 2410, November
                  1998

   [RFC-2451]     Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
                  Algorithms", RFC 2451, November 1998

   [RFC-2460]     Deering, S. and Hinden, R., "Internet Protocol,
                  Version 6 (IPv6) Specification", RFC 2460, December
                  1998.

   [RFC-2461]     Narten, T., Nordmark, E. and Simpson, W., "Neighbor
                  Discovery for IP Version 6 (IPv6)", RFC 2461,
                  December 1998.

   [RFC-2462]     Thomson, S. and Narten, T., "IPv6 Stateless Address
                  Autoconfiguration", RFC 2462.

   [RFC-2463]     Conta, A. and Deering, S., "ICMP for the Internet
                  Protocol Version 6 (IPv6)", RFC 2463, December 1998.

   [RFC-2473]     Conta, A. and Deering, S., "Generic Packet Tunneling
                  in IPv6 Specification", RFC 2473, December 1998.

   [RFC-2710]     Deering, S., Fenner, W. and Haberman, B., "Multicast
                  Listener Discovery (MLD) for IPv6", RFC 2710, October
                  1999.

   [RFC-2711]     Partridge, C. and Jackson, A., "IPv6 Router Alert
                  Option", RFC 2711, October 1999.

   [RFC-2874]     Crawford, M. and Huitema, C., "DNS Extensions to
                  Support IPv6 Address Aggregation and Renumbering",
                  RFC 2874, July 2000.

Manyfolks                                                    [Page 16]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002



   [RFC-3041]     Narten, T. and Draves, R., "Privacy Extensions for
                  Stateless Address Autoconfiguration in IPv6", RFC
                  3041, January 2001.

6.2 Non-Normative

   [3GPP-ACC]     3GPP Technical Specification 3GPP TS 33.203,
                  "Technical Specification Group Services and System
                  Aspects; 3G Security; Access security for IP-based
                  services (Release 5)", 3rd Generation Partnership
                  Project, March 2002.

   [3GPP-IMS]     3rd Generation Partnership Project; Technical
                  Specification Group Services and System Aspects; IP
                  Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228)

   [3GPP-IPv6]    3rd Generation Partnership Project; Technical
                  Specification Group Services and System Aspects
                  "Architectural requirements" (TS 23.221)

   [ICMPIKEv6]    Arkko, J., "Effects of ICMPv6 on IKE and IPsec
                  Policies", Expired Internet Draft, Available at
                  http://www.arkko.com/publications/draft-arkko-icmpv6-
                  ike-effects-00.txt.

   [IPv6-3GPP]    Wasserman, M (editor), "Recommendations for IPv6 in
                  3GPP Standards" Work in Progress.

   [MIPv6]        Johnson D. and Perkins, C., "Mobility Support in
                  IPv6", Work in progress.

   [RFC-1034]     Mockapetris, P., "Domain names û concepts and
                  facilities", RFC 1034, November 1987

   [RFC-2529]     Carpenter, B. and Jung, C., "Transmission of IPv6
                  over IPv4 Domains without Explicit Tunnels", RFC
                  2529, March 1999.

   [RFC-2893]     Gilligan, R. and Nordmark, E., "Transition Mechanisms
                  for IPv6 Hosts and Routers", RFC 2893, August 2000.

   [RFC-3056]     Carpenter, B. and Moore, K., "Connection of IPv6
                  domains via IPv4 clouds", RFC 3056, February 2001.

   [TCPWIRELESS]  Inamura, H. et al. "TCP over 2.5G and 3G Networks".
                  IETF, Work in progress.

   [UMTS-AKA]     3GPP Technical Specification 3GPP TS 33.102,
                  "Technical Specification Group Services and System
                  Aspects; 3G Security; Security Architecture (Release

Manyfolks                                                    [Page 17]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


                  4)", 3rd Generation Partnership Project, December
                  2001.

7 Acknowledgements

   The authors would like to thank Jim Bound, Brian Carpenter, Steve
   Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark,
   Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing
   list for their comments and input.

   We would also like to thank David DeCamp, Karim El Malki, Markus
   Isom„ki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu
   and Shabnam Sultana for their comments and input in preparation of
   this document.

8 Authors' Addresses

   Jari Arkko
   Ericsson
   02420 Jorvas
   Finland

   Phone:  +358 40 5079256
   Fax:    +358 40 2993401
   E-Mail: Jari.Arkko@ericsson.com

   Peter Hedman
   Ericsson
   SE-221 83 LUND
   SWEDEN

   Phone:  +46 46 231760
   Fax:    +46 46 231650
   E-mail: peter.hedman@emp.ericsson.se

   Gerben Kuijpers
   Ericsson
   Skanderborgvej 232
   DK-8260 Viby J
   DENMARK

   Phone:  +45 89385100
   Fax:    +45 89385101
   E-mail: gerben.a.kuijpers@ted.ericsson.se

   Hesham Soliman
   Ericsson Radio Systems AB
   Torshamnsgatan 23, Kista, Stockholm
   SWEDEN

   Phone:  +46 8 4046619

Manyfolks                                                    [Page 18]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   Fax:    +46 8 4047020
   E-mail: Hesham.Soliman@era.ericsson.se


   John Loughney
   Nokia Research Center
   It„merenkatu 11 û 13
   FIN-00180 HELSINKI
   FINLAND

   Phone:  +358 7180 36242
   Fax:    +358 7180 36851
   E-mail: john.loughney@nokia.com

   Pertti Suomela
   Nokia Mobile Phones
   Visiokatu 3
   FIN-33720 TAMPERE
   Finland

   Phone:  +358 7180 40546
   Fax:    +358 7180 48381
   E-mail: pertti.suomela@nokia.com

   Juha Wiljakka
   Nokia Mobile Phones
   Visiokatu 3
   FIN-33720 TAMPERE
   Finland

   Phone:  +358 7180 47562
   Fax:    +358 7180 48381
   E-mail: juha.wiljakka@nokia.com

Appendix A Revision History

  Changes from draft-ietf-ipv6-cellular-host-00.txt:

    - Introduction edited
    - 1.1 on scoping added
    - keywords removed
    - DNS discovery removed
    - some more to be added here.

Appendix B Cellular Host IPv6 Addressing in the 3GPP Model

   The appendix aims to very briefly describe the 3GPP IPv6 addressing
   model for 2G (GPRS) and 3G (UMTS) cellular networks from Release 99
   onwards. More information can be found from 3GPP Technical
   Specification 23.060.


Manyfolks                                                    [Page 19]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   There are two possibilities to allocate the address for an IPv6 node
   û stateless and stateful autoconfiguration. The stateful address
   allocation mechanism needs a DHCP server to allocate the address for
   the IPv6 node.  On the other hand, the stateless autoconfiguration
   procedure does not need any external entity involved in the address
   autoconfiguration (apart from the GGSN).

   In order to support the standard IPv6 stateless address
   autoconfiguration mechanism, as defined by the IETF, the GGSN shall
   assign a prefix that is unique within its scope to each primary PDP
   context that uses IPv6 stateless address autoconfiguration. This
   avoids the necessity to perform Duplicate Address Detection at the
   network level for every address built by the mobile host. The GGSN
   always provides an Interface Identifier to the mobile host. The
   Mobile host uses the interface identifier provided by the GGSN to
   generate its link-local address. Since the GGSN provides the
   cellular host with the interface identifier, it must ensure the
   uniqueness of such identifier on the link (I.e. no collisions
   between its own link local address and the cellular host's).
   In addition, the GGSN will not use any of the prefixes assigned to
   cellular hosts to generate any of its own addresses.
   This use of the interface identifier, combined with the fact that
   each PDP context is allocated a unique prefix, will eliminate the
   need for DAD messages over the air interface, and consequently
   allows an efficient use of bandwidth. Furthermore, the allocation of
   a prefix to each PDP context will allow hosts to implement the
   privacy extensions in RFC 3041 without the need for further DAD
   messages.

Appendix C Transition Issues

   IETF has specified a number of IPv4 / IPv6 transition mechanisms
   [RFC-2893] to ensure smooth transition from IPv4 to IPv6 and
   interoperability between IPv4 and IPv6 during the transition period.
   The three main transition methods from a cellular network point of
   view are dual IPv4 / IPv6 stacks, tunneling and protocol
   translators, such as NAT-PT or SIIT.

   It is recommended that cellular hosts have dual IPv4 / IPv6 stacks
   to be able to interoperate with both IPv4 and IPv6 domains and use
   both IPv6 and IPv4 applications / services. It is recommended that
   most transition mechanisms be provided by the network in order to
   save the limited resources of the cellular host.  Tunneling (for
   example RFC 3056 - Connection of IPv6 Domains via IPv4 Clouds)
   should be carried out in the network.  In addition, any protocol
   translation function, such as NAT-PT, should be implemented in the
   network, not in the cellular host.

   The tunneling mechanism specified by [RFC-2529] is not relevant for
   a cellular host. [RFC-2529] allows isolated IPv6-only hosts to
   connect to an IPv6 router via an IPv4 domain. The scenario of an

Manyfolks                                                    [Page 20]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   IPv6-only host in an IPv4-only cellular network is considered
   unlikely.

Appendix D Mobility Issues

   This appendix discusses the level of support of MIPv6 required by
   cellular hosts and highlight the scenarios in which such support is
   needed. Mobile IPv6 is specified in [MIPv6].

   Mobile IP is required for hosts moving within the Internet topology.
   At the highest level, the Mobile IPv6 functionality within Mobile
   Nodes can be divided to the following parts:

     - Correspondent Node (CN) functionality, defined by Mobile IPv6
       specification [MIPv6], i.e. the basic functionality needed to
       correspond with mobile nodes.
     - Mobile Node (MN) functionality [MIPv6]. This includes the
       ability to configure Home and Care-of-Addresses (CoA) send
       Binding Updates (BUs) and receive Binding Acknowledgements and
       Requests. In addition, this function also includes the ability
       to maintain a Binding Update List.
     - Route optimization. The functionality needed to correspond with
       mobile nodes in an optimal manner.

   We will discuss the use of each part in turn.

   The basic functionality of a Correspondent Node, i.e. process the
   Home Address Option, must be supported by all hosts. However, at the
   time this is being written, the Home Address Option is defined only
   in preliminary form in [MIPv6]. Furthermore, at present it is
   unclear whether this option can be understood by all nodes or only
   in conjunction with Route Optimization. This is due to the possible
   use of the option in Denial-of-Service attacks that employ CNs as
   reflectors. Cellular host implementers are advised that leaving out
   Home Address Option support may prevent their hosts to communicate
   with future MIPv6 MNs. On the other hand, the inclusion of Home
   Address Option without Route Optimization being active for that host
   may present a threat that allows the cellular hosts to be used as
   reflectors in Denial-of-Service attacks.

   The mobile node functionality is needed when the host itself will
   move within the Internet topology i.e. changes its care-of address.
   This function is needed in cellular systems where MIPv6 is used for
   intra-access technology mobility. In other cellular systems where
   intra-access technology mobility is handled by other means (e.g. GTP
   in a 3GPP system), hosts with additional, non-cellular interfaces
   must have this functionality if they need to retain session or IP
   layer reachability while moving between different access
   technologies, i.e. - to use MIPv6 for inter-system IP handovers.
   For instance, when a hosts has both a Wireless LAN (WLAN) and an
   UMTS interface, MIPv6 MN functionality is needed to retain sessions

Manyfolks                                                    [Page 21]


Internet Draft      IPv6 for 2G and 3G Cellular Hosts    April 10, 2002


   when moving from UMTS area to a WLAN area. The UMTS network provides
   a basic mobility service (layer 2 mobility) to all hosts without
   requiring the implementation of IP layer mobility. Hosts that have
   interfaces only to networks providing such other mobility services,
   or hosts that do not require session mobility through interface
   handovers may have this functionality for reachability when the DNS
   is used to locate a host. That is, when roaming between different
   cellular operators. A host, in this case, would require a home
   address in the DNS and a Home agent. When connected to a default
   router for the host, the host would update its Home Agent with its
   new address.

   Mobile node functionality is fully defined in the Mobile IPv6
   specifications and should only be implemented according to an
   official standard.

   The Route Optimization functionality for a CN, i.e. processing of
   Binding Updates, should be supported by all hosts supporting the
   Mobile Node functions and may be supported by all hosts.

   Route Optimization functionality should also only be implemented
   according to an official standard.

   Hosts that implement MIPv6 must support the security features
   defined in [MIPv6]. Note that MNs, CNs, and Route Optimization
   functionality may have different requirements.


Manyfolks                                                    [Page 22]

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