[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:  February 22, 2002
   Expires: August 22, 2002

              Minimum IPv6 Functionality for a Cellular Host
                  <draft-ietf-ipv6-cellular-host-00.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 an increasing number of cellular hosts are being connected to the
   Internet, IPv6 becomes necessary. Examples of such hosts are GPRS,
   UMTS, and CDMA2000 terminals. Standardization organizations are also
   making IPv6 mandatory in their newest specifications, such as the IP
   multimedia terminals specified for UMTS. However, the concept of
   IPv6 covers many aspects, numerous RFCs, a number of different
   situations, and is also partly still evolving. A rapid adoption of
   IPv6 is desired for cellular hosts. Yet these terminals vary greatly
   in terms of their processing capabilities and task orientation.
   Cellular host software often cannot be upgraded and must still meet
   tough demands for interoperability with other hosts, the cellular
   network, and the Internet. For these reasons it is necessary to
   understand how the IPv6 deployment starts and which parts of IPv6
   are necessary under which situations. This document suggests basic
   IPv6 functionality for cellular hosts, and discusses when parts of
   the functionality is needed, and under which conditions.

Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002



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

Manyfolks                                               [Page 2]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   D.1 Mobility Support in IPv6.....................................23
   D.2 Fast Handovers for Mobile IPv6...............................25
   D.3 Hierarchical MIPv6 Mobility Management (HMIPv6)..............25
   D.4 Mobile IP Security...........................................25


1 Introduction

   Technologies such as GPRS (General Packet Radio Service), UMTS
   (Universal Mobile Telecommunications System), and CDMA2000 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. One example of this is that 3GPP (Third
   Generation Partnership Project) specifies IPv6 support as mandatory
   for future UMTS IP multimedia terminals [3GPP-IMS].

   The purpose of this draft is to propose a compact set of IPv6
   specifications and functionality that cellular hosts must support.
   Such a specification is necessary in order to determine the optimal
   way to use IPv6 in a cellular environment.  Important considerations
   are how to minimize footprint and implementation effort for a large
   number of consumer terminals, 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, the IETF that wants to ensure a well-
   working global IPv6 network, and other standardization organizations
   that need a reference to how IPv6 can be mandated on their
   standards.

   For the purposes of this document, a cellular host is considered to
   be a terminal that uses an air interface to connect to a cellular
   access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6
   connectivity to an IP network.  The functionality to provide this
   connectivity is outlined in this draft. The description is made from
   a general cellular host point of view, and this document is intended
   to be applicable for many types of cellular network standards, or
   even multi-standard devices.  The implementation of parts of the
   IPv6 specification in specific cellular networks (such as the UMTS)
   may differ from the general recommendation. Where this applies,
   additional information is given on how to make that part of IPv6
   work in that specific cellular network. This information can also be
   used to provide standardization bodies insight in which issues it
   may be necessary to revise in future releases of the particular
   cellular network specifications.

Manyfolks                                               [Page 3]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002



   Parts of this document may also be applicable in other, non-cellular
   contexts, such as small IPv6 appliances with similar size and cost
   restrictions. The scope of this document, however, is the cellular
   hosts and it may not cover all issues relevant in those other
   contexts.

   The use of IPv6 within cellular networks implies an implementation
   of the IPv6 stack within a wide range of terminals. Such terminals
   may vary significantly in terms of capacity, task orientation and
   processing power. For instance, the smallest handheld terminals can
   have a very limited amount of memory, computational power, and
   battery capacity. Cellular hosts operate over low bandwidth wireless
   links with limited throughput. As such, there are certain
   optimizations that would be required for these hosts in order to fit
   the largest possible amount of terminals within an area of spectrum.

   Tough demands are set for interoperability of cellular hosts towards
   other hosts, the cellular network, and the Internet. It is often
   hard or impossible to upgrade a large number of cellular hosts to a
   new software version. The long lifetime of the terminals sets a
   requirement for old equipment to still work in newer versions of the
   network and other hosts.

   The concept of IPv6 covers many aspects, numerous RFCs, a number of
   different situations, and is also partly still in evolution. For
   these reasons it is necessary to understand how the IPv6 deployment
   starts and which parts of IPv6 are necessary under which situations.
   This document reviews the IPv6 functionality, grouped under three
   categories: core IP, security, and mobility. For each category and
   each RFC in them, we discuss the following:

     - Is this part of functionality needed by cellular hosts and under
       which conditions?
     - In some cases individual parts of the RFCs are discussed in more
       detail and recommendations are given regarding their support.
     - In some other cases conflicts between some parts of
       functionality and the current cellular network protocols are
       identified.

   The aim of this work is to introduce a minimal set of IPv6
   functionality û subject to the particular type of terminal and
   application û that would be required for cellular IPv6 hosts. As a
   general guideline, a cellular host should not appear any different
   from other IPv6 hosts. The set of requirements proposed should be
   suited to terminals with minimal capabilities, low cost and
   processing power. Interoperability can be achieved by listing needed
   IPv6 related IETF specifications according to chapter 1.3.

   The scope of the discussion in this document is the IPv6
   functionality. The reader should be advised that other,non-IPv6

Manyfolks                                               [Page 4]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


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

   The history of IPv6 in 3GPP specifications is briefly described in
   this paragraph. IPv6 was introduced as an option starting in 3GPP
   and ETSI Release 97 GSM / GPRS specifications. A wider support for
   IPv6 and the introduction of UMTS starts with 3GPP Release 99
   networks and terminals. IPv6 is specified as the only IP version
   supported in Release 5 for IP Multimedia Subsystem (IMS). The
   authors used 3GPP Release 99 and Release 4 specifications as defined
   when this document was written as a base. Any possible changes to
   current IPv6 specifications shall be accommodated as they occur.

   The authors of this document seek feedback to ensure that the
   proposed functionality set is consistent, interoperable with the
   rest of the IPv6 Internet, complete, and does not open new security
   risks.

1.1 Abbreviations

   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.
   CDMA2000    Code Division Multiple Access 2000, the name identifying
               the third generation technology of IS-95 CDMA standard
               and ANSI-41 network.
   ESP         Encapsulating Security Payload
   ETSI        European Telecommunications Standards Institute
   IMS         IP Multimedia Subsystem
   GGSN        Gateway GPRS Support Node (a default router for cellular
               3GPP IPv6 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
   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.2 Requirement Language


Manyfolks                                               [Page 5]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC-2119].

1.3 Cellular Host IPv6 Features

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

     Core IP

          In this group we describe the core parts of IPv6.

     IP Security

          In this group we discuss the security functionality suitable
          for cellular hosts. Chapter 3 defines the contents of this
          group, and discusses its usage in different contexts.

     IP Mobility

          In this group we discuss IP layer mobility functionality for
          cellular hosts. Basic functionality needed just to correspond
          with mobile nodes is a part of the Core IP group. Chapter 4
          defines the contents of the IP Mobility group, and discusses
          its usage in different contexts.
2 Core IP

   This section describes the minimum needed IPv6 functionality of a
   cellular host in order to be able to communicate with other IPv6
   hosts.

2.1 RFC1981 - Path MTU Discovery for IP Version 6

   Path MTU Discovery [RFC-1981] MAY be supported.

   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 uplink packet size
   MUST be limited to 1280 octets (standard limit in [RFC-2460]).
   However, the cellular host MUST be able to receive packets with size
   up to the link MTU before reassembly.

2.2 RFC2373 - IP Version 6 Addressing Architecture

   The IPv6 Addressing Architecture [RFC-2373] MUST be supported. IPX &
   NSAP addresses SHOULD NOT be used. Currently, this RFC is being

Manyfolks                                               [Page 6]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   updated by [ADDRARCHv3], therefore this draft MUST be supported as
   well.

2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format

   The IPv6 Aggregatable Global Unicast Address Format is described in
   [RFC-2374]. This RFC MUST be supported.

2.4 RFC2460 - Internet Protocol Version 6

   The Internet Protocol Version 6 is specified in [RFC-2460]. This RFC
   MUST be supported.

   The cellular host is assumed to act as a host, not as a router.
   Implementation requirements for a cellular router are not defined in
   this document.

   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 at least minimal processing of each
   extension header:

     - 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: In the case of the Core IP functionality
       only, AH and ESP headers are treated as if the Security
       Association had not existed, i.e. - packets with these headers
       are dropped.  When the IP Security functionality is in use, they
       are processed as specified in RFCs 2401, 2402, and 2406.
     - 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. A cellular host implementing the Core IP functionality will
   typically send packets containing either no extension headers or the
   Fragment header.  However, a cellular host MAY generate any of the
   extension 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
   terminal's addresses. If not, however, the terminal MUST implement

Manyfolks                                               [Page 7]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   error checks as specified in section 4.4 of RFC 2460. There is no
   need for the terminal to send Routing Headers.

2.5 RFC2461 - Neighbor Discovery for IPv6

   Neighbor Discovery is described in [RFC-2461] and, in general, MUST
   be supported.

   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, a
   mobile terminalÆs only neighbour on the cellular link is the default
   router which 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 implemented for the
   cellular interface. 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.

2.5.1 Neighbor Discovery in 3GPP

   3GPP terminals only need to support 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 needed for 3GPP IPv6
   Stateless Address Autoconfiguration, since Duplicate Address
   Detection is not needed in this address assignment mechanism (see
   section 2.6.1).

2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration

   IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be
   supported.

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

   A cellular host SHOULD 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.



Manyfolks                                               [Page 8]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002



2.7 RFC2463 - Internet Control Message Protocol for the IPv6

   The Internet Control Message Protocol for the IPv6 [RFC-2463] MUST
   be supported.

   As per RFC 2463 section 2, ICMPv6 requirements MUST be fully
   implemented by every IPv6 node. However, references to the use of IP
   Security (sections 5.1 and 5.2) are not relevant for Core IP
   features.

2.8 RFC2472 - IP version 6 over PPP

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

2.8.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.9 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, as specified in chapter
   4.

2.10 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.11 RFC2711 - IPv6 Router Alert Option

   The Router Alert Option [RFC-2711] MAY be supported. Since the
   cellular host is not a router, the receiver side of the Router Alert
   Option may be omitted.


Manyfolks                                               [Page 9]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


2.12 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 RFC. 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.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6

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

2.14 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.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

   The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] MAY be
   supported. DHCP is not needed when IPv6 stateless autoconfiguration
   is used, and no other functions of DHCP are used.
2.16 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.17 DNS

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

2.17.1 RFC2874 - DNS Extensions to Support IPv6 Address Aggregation and
Renumbering

   DNS Extensions to Support IPv6 Address Aggregation and Renumbering
   [RFC-2874] SHOULD NOT be supported. A6 can cause problems for
   cellular hosts operating over wireless links since several round
   trips may be needed to collect a complete DNS record, when a DNS
   resolver is implemented on a cellular host.

2.17.2 IPv6 Stateless DNS discovery


Manyfolks                                               [Page 10]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   [DNS-DISC] shows a mechanism that allows hosts to discover a DNS in
   a stateless manner. When DNS is supported cellular hosts MUST have
   level 1 compliance.

2.17.3 Using DHCPv6 for DNS Configuration in Hosts

   A cellular host that supports both DHCPv6 and DNS SHOULD support
   [DNS-DHCP] for stateful configuration of DNS server addresses.

2.17.4 DNS use in 3GPP

   Some networks may provide DNS-proxy service for simple cellular
   hosts. Therefore, generally, DNS MAY be supported. A cellular host
   SHOULD perform DNS requests in the recursive mode, to limit
   signaling over the air interface.

3 IP Security

   The need for IP Security [RFC-2401] or other security mechanisms in
   cellular hosts depends on their intended use. The following services
   are discussed here:

    - End-to-end IPsec VPN service, e.g. to a corporate intranet
    - Web browsing service
    - IPv6 control message protection service, e.g. for ICMPv6 to the
       next hop router

   Recommendations are given on what security solution to employ for
   these services. We can not list all possible services here, and in
   general we expect application protocol RFCs to have 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.

   We will now discuss the security mechanisms necessary for each
   service listed above. Note that if a recommended security mechanism
   has a wireless profile in the future, it SHOULD be supported.

  Cellular hosts that provide an end-to-end IPsec VPN service to a
  corporate intranet, for example, or to a transition-tunneling
  gateway MUST support IPsec and IKE. For this purpose an IPsec Remote
  Access solution SHOULD also be supported. This security set is
  defined in sections 3.1 to 3.15.

   Cellular hosts that provide a web browsing service SHOULD provide
   TLS [RFC-2246]. The use of security in a web browser is seen in most
   cases as very useful, as otherwise the user would be blocked from
   some of the sites - such as e-commerce sites - that do require
   security. The fact that just TLS should be the protocol to provide

Manyfolks                                               [Page 11]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   web security relates to current deployment and the suitability of
   the single-side certificate trust model for this application.

   Even if a particular terminal does not support IP Security, it MUST
   be able to provide a clean indication to the other host that it is
   not willing to provide security associations. It is recommended that
   the terminal use ICMP Port Unreachable message for this.

   The use of IPsec, IKE, or other security services directly in the
   underlying IPv6 infrastructure communications (e.g. ICMPv6 or
   Neighbor Discovery) can also be discussed. The use of IPsec towards
   a specific home server in the context of a VPN service is easy.
   However, the use of any security service to local next hop routers
   (GGSNs) or other 3GPP nodes seems hard due to the difficulties in
   establishing a suitable trust infrastructure for creating the
   necessary Security Associations (SAs). In order for a terminal 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. It may be possible to
   overcome these problems, however, the added security benefits of the
   protection in these cases would be minimal: encrypted radio
   communications exist at a lower layer, and the next hop router can
   always engage in any denial-of-service attacks (such as dropping all
   packets) regardless of the existence of any SAs. For these reasons,
   the 3GPP terminals will not be mandated to support any security for
   the pure IPv6 router and infrastructure protection purposes.

   The following subchapters are only applicable for those services
   where IPsec/IKE is recommended above. The below chapters define a
   simple wireless minimum profile for IPsec/IKE.  What is recommended
   here for a specific service does not apply to other services, and
   use of a security service for some other service may imply a
   different set of protocols to be employed

3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication

   This RFC [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 RFC [RFC-2401] MUST be supported.


Manyfolks                                               [Page 12]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


3.3 RFC2402 - IP Authentication Header

   This RFC [RFC-2402] MAY be supported.

   The AH protocol is one of the alternative protocols in the IPsec
   protocol family, the other alternative being ESP. In the interest of
   minimizing implementation complexity and in particular configuration
   options, both protocols may not be needed in a cellular host. It is
   suggested that the ESP protocol be preferred for its confidentiality
   protection function.

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

   This RFC [RFC-2403] MUST be supported.

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

   This RFC [RFC-2404] MUST be supported.

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

   This RFC [RFC-2405] MAY be supported. It is, however, recommended
   that stronger algorithms than DES be supported.

3.7 RFC2406 - IP Encapsulating Security Payload (ESP)

   This RFC [RFC-2406] MUST be supported.

3.8 RFC2407 - The Internet IP Security DoI for ISAKMP

   This RFC [RFC-2407] MUST be supported.

   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
   to be updated to the SA database of the peer as well.

  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. For instance, the use of pre-shared
  secrets as an authentication method in IKE is not feasible in
  practice in the context of a large number of hosts. Although work on
  such simplifications is useful, is not described here.

3.9 RFC2408 û Internet Security Association and Key Management Protocol

   This RFC [RFC-2408] MUST be supported.


Manyfolks                                               [Page 13]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


3.10 RFC2409 - The Internet Key Exchange (IKE)

   This RFC [RFC-2409] MUST be supported.  Note that a new version of
   the IKE protocol is being developed and is expected to replace it at
   a future time.

   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 RFC [RFC-2410] MUST be supported.

3.12 RFC2411 - IP Security Document Roadmap

   This RFC [RFC-2411] is of informational nature only.

3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms

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

3.14 IP Security Remote Access

   IPsec is often used in situations where legacy RADIUS or other
   authentication is desired instead of PKI-based authentication.

Manyfolks                                               [Page 14]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   Cellular hosts offering VPN services to corporate intranets SHOULD
   support PIC [PIC].

3.15 The AES Cipher Algorithm and Its Use With IPsec

   This specification [AESIPSEC] MUST be supported. We suggest here
   that in a new environment such as the cellular IPv6 older and
   insecure algorithms such as DES should not be used, and that the
   most secure and lightweight new ones should be used instead. Due to
   better efficiency we suggest the use of AES instead of 3DES.

4 IP Mobility

     Mobile IPv6 manages IP mobility resulting from the change in Care
     of Address (CoA) when a host moves within the Internet topology.
     However, at the time this is being written Mobile IPv6
     specification is not yet an RFC and may change. Appendix D
     discusses the level of support of MIPv6 needed by cellular hosts
     and highlights the scenarios in which such support is useful.

     Some aspects of securing MIPv6 are also currently being debated.
     Yet at the same time the first cellular IPv6 hosts need to be
     produced. Implementors should therefore consider the implications
     of relying on preliminary information. We will also indicate
     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. In the
   following, we discuss such situations:

    - The suggested limitations (Section 2.4) 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, in most cases, assign new addresses to hosts in
       roaming situations and typically also when the cellular
       terminals 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 terminal is possible through its
       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 is likely to keep an address for a long time in

Manyfolks                                               [Page 15]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


       practise. Hence, IPv6 addressing privacy can be used for
       additional privacy during the time the terminal 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.
       Recommendations are given to support VPN-type tunneling to home
       networks, but to avoid the use of any security services in
       towards visited network nodes. This does not appear to open any
       new vulnerabilities, as ICMPv6 protection isnÆt possible in
       large scale today either.

    - Chapter 3 further discusses a specific profile of IPsec
       suitable for cellular implementations. Deviations from the
       standard RFCs are suggested mainly due to a desire to adopt the
       latest advances, such as the AES algorithm. On the other hand
       it is suggested to employ only the ESP protocol for reasons of
       reducing complexity. ESP provides a different protection than
       AH, which may have security implications.

    - As Chapter 4 mandates only the support of the Mobile IP Home
       Address option and not the full, optimized correspondent node
       behavior, the security problems related to Binding Updates are
       not relevant for nodes supporting only the Core IP features.
       However, security issues involving the Home Address Option MUST
       be solved before Chapter 2 recommendation of mandatory support
       can go forward.

    - The air-time 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 air-time is used correctly and no extra
       charges are applied to users due to misbehaving third parties.
       The wireless 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

Manyfolks                                               [Page 16]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


       still an area of further study. It is also often easy to fill
       the wireless 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.

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

   [AESIPSEC]     Frankel, S., Kelly, S. and Glenn, R., "The Candidate
                  AES Cipher Algorithms and Their Use With IPsec", 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.

   [DNS-DHCP]     Aboba, B., Droms R. and Narten T., ôUsing DHCPv6 for
                  DNS Configuration in Hostsö, Work in progress.

   [DNS-DISC]     Thaler, D. and Hagina, J., ôIPv6 Stateless DNS
                  Discoveryö, Work in progress.

   [PIC]          Sheffer, Y., Aboba, B. and Krawczyk, H., ôPIC, a Pre-
                  IKE Credential Provisioning Protocolö, Work in
                  progress.


Manyfolks                                               [Page 17]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   [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-2374]     Hinden, R., O'Dell, M. and Deering, S., "An IPv6
                  Aggregatable Global Unicast Address Format", RFC
                  2374, 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.

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

Manyfolks                                               [Page 18]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002



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

   [RFC-2411]     Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
                  Document Roadmap", RFC 2411, 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.

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

6.2 Non-Normative

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


Manyfolks                                               [Page 19]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   [HMIPv6]       Soliman, H., Castelluccia, C., ElMalki, K., Bellier,
                  L., "Hierarchical MIPv6 mobility management (HMIPv6)"
                  Work in progress.

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

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

   [MIPv6-FH]     Dommety, G., Editor, et al, "Fast Handovers for
                  Mobile IPv6", Work in progress.


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

   [RFC-2119]     Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

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


7 Acknowledgements

   The authors would like to thank David DeCamp, Karim ElMalki, Markus
   Isom„ki, Petter Johnsen, Janne Rinne, Jonne Soininen and Shabnam
   Sultana for their comments and input.

8 Authors' Addresses

   Jari Arkko
   Ericsson
   02420 Jorvas
   Finland

   Phone:  +358 40 5079256
   Fax:    +358 40 2993401

Manyfolks                                               [Page 20]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


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


Manyfolks                                               [Page 21]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   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-manyfolks-ipv6-cellular-host-02.txt:

    - Added [ADDRARCHv3] to section 2.2.
    - Minor change to section 2.5.
    - Minor change to section 2.6 and 2.6.1.
    - Added section 2.8.1 on IPv6 over PPP in 3GPP.
    - Removed section 2.13.1 on privacy extensions to stateless
       address autoconfiguration in 3GPP.
    - Added recommendation on use of recursive mode DNS in section
       2.17.
    - Changed recommendation on DNS extensions to support IPv6 from
       MAY to SHOULD NOT in section 2.17.1.
    - Added section 2.17.2 and 2.17.3 on DNS discovery.
    - Moved section 2.18 to the introduction of section 3.
    - Section 3: Minor revisions throughout this section.
    -  Section 4: revised to reflect current situation of MIPv6,
       specific drafts moved to a new appendix, Appendix D.
    -  Section 5: revised the discussion on IP address privacy.
    - Seperated references into Normative and Non-normative
       references.

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.

   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

Manyfolks                                               [Page 22]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


   avoids the necessity to perform Duplicate Address Detection at the
   network level for every address built by the mobile terminal. The
   GGSN always provides an Interface Identifier to the mobile terminal.
   The Mobile terminal 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
   the most transition mechanisms are 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.  Also 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
   IPv6-only host in an IPv4-only cellular network is considered
   unlikely.

Appendix D Mobility Issues

D.1 Mobility Support in IPv6

   Mobile IPv6 is specified in [MIPv6].


Manyfolks                                               [Page 23]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


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

Manyfolks                                               [Page 24]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


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

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

D.2 Fast Handovers for Mobile IPv6

   Fast handovers for Mobile IPv6 is specified in [MIPv6-FH]. This
   draft should be supported.

D.2.1 3GPP and Fast Handovers

   Within the current 3GPP architecture, a cellular host will always
   keep the connection to the same GGSN (default router) for a context.
   Movement between default routers is not permitted. The only scenario
   where a MN would change default routers is in the case of a handover
   between two different access technologies. In this case the MN will
   be simultaneously connected to both routers, which would eliminate
   the need for anticipation through the current router. Hence the Fast
   Handovers draft will not be required within the current 3GPP
   architecture.

D.3 Hierarchical MIPv6 Mobility Management (HMIPv6)

   Hierarchical MIPv6 is specified in [HMIPv6]. HMIPv6 should be
   supported to run MIPv6 efficiently over the air. This aims at
   reducing the number of MIPv6 BUs sent over the air while moving
   within the topology.

D.3.1 HMIPv6 in 3GPP

   As mentioned above, Inter-GGSN handovers are not allowed within the
   current 3GPP architecture. Hence, the benefit of implementing HMIPv6
   in 3GPP will only appear during the inter-access technology
   handover, which may not be as common as intra-access technology
   ones. However the architecture can benefit from the per-flow
   movement explained in the draft that allows a MN to receive
   different traffic flows on different interfaces.

D.4 Mobile IP Security


Manyfolks                                               [Page 25]


Internet Draft  Min. IPv6 Func. for a Cellular Host  February 22, 2002


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


Manyfolks                                               [Page 26]


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