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

Versions: 00 01 02 draft-ietf-ipv6-cellular-host

   INTERNET-DRAFT                                            Jari Arkko
   Internet Engineering Task Force                         Peter Hedman
   Issued:  September 21, 2001                          Gerben Kuijpers
   Expires: March 21, 2002                                     Ericsson
                                                          John Loughney
                                                         Pertti Suomela
                                                          Juha Wiljakka
                                                                  Nokia



              Minimum IPv6 Functionality for a Cellular Host
               <draft-manyfolks-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 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, yet it must 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    July 2, 2001



 Abstract ............................................................1
 1 Introduction ......................................................4
  1.1 Abbreviations ..................................................6
  1.2 Requirement Language ...........................................6
  1.3 Cellular Host IPv6 Features ....................................6
 2 Core IP ...........................................................6
  2.1 RFC1981 - Path MTU Discovery for IP Version 6 ..................7
  2.2 RFC2373 - IP Version 6 Addressing Architecture .................7
  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 ....9
  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 ..........................................................11
  2.18 Security Issues ..............................................11
 3 IP Security ......................................................11
  3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication ......13
  3.2 RFC2401 - Security Architecture for the Internet Protocol .....13
  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 ...14
  3.7 RFC2406 - IP Encapsulating Security Payload (ESP) .............14
  3.8 RFC2407 - The Internet IP Security DoI for ISAKMP .............14
  3.9 RFC2408 - ISA and Key Management Protocol .....................14
  3.10 RFC2409 - The Internet Key Exchange (IKE) ....................14
  3.11 RFC2410 - The NULL Encryption Algorithm and its Use With IPsec14
  3.12 RFC2411 - IP Security Document Roadmap .......................14
  3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms .................15
  3.14 IP Security Remote Access ....................................15
  3.15 The AES Cipher Algorithm and Its Use With IPsec ..............15
  3.16 ICMPv6 and Its Effect to IKE and IPsec Policies ..............15
 4 IP Mobility ......................................................15
  4.1 Mobility Support in IPv6 ......................................15
  4.2 Fast Handovers for Mobile IPv6 ................................16
  4.3 Hierarchical MIPv6 Mobility Management ........................17
  4.4 Mobile IP Security ............................................17
 5 Security Considerations ..........................................17
 6 References .......................................................19
 7 Acknowledgements .................................................22
 8 Authors' Addresses ...............................................22

Manyfolks                                               [Page 2]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


 Appendix A Cellular Host IPv6 Addressing in the 3GPP Model .........23
 Appendix B Transition Issues .......................................25


















































Manyfolks                                               [Page 3]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


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
   specifies IPv6 support as mandatory for future UMTS IP multimedia
   terminals.

   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 implementors 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 which uses a cellular air interface (i.e. GPRS, UMTS,
   CDMA2000) to connect to a cellular access network 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). In some cases
   known exceptions and special cases are however documented for
   specific cellular networks such as the UMTS, as examples and
   additional information for the reader.

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

Manyfolks                                               [Page 4]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


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

   The scope of the discussion in this document is the IPv6
   functionality. The reader should be advised that other work exists
   for various other layers, which is not IPv6 specific such as the
   header compression work done in the IETF ROHC group, or the TCP work
   in [TCPWIRELESS].

   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.



Manyfolks                                               [Page 5]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


1.1 Abbreviations

   3GPP        Third Generation Partnership Project
   AH          Authentication Header
   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
   GGSN        Gateway GPRS Support Node
   GPRS        General Packet Radio Service
   IKE         Internet Key Exchange
   ISAKMP      Internet Security Association and Key Management
               Protocol
   MTU         Maximum Transmission Unit
   SGSN        Serving GPRS Support Node
   UMTS        Universal Mobile Telecommunications System
   WLAN        Wireless LAN

1.2 Requirement Language

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

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. Only RFCs
          needed in all situations and under all conditions are in this
          group.

     IP Security

          In this group we discuss the IP layer 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


Manyfolks                                               [Page 6]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


   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 [PMTU] MAY be supported.

   The IPv6 specification [IPv6] 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 [IPv6]). 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 [ADDRARCH] MUST be supported. IPX &
   NSAP addresses SHOULD NOT be used.

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

   The cellular host is assumed to act as a host, not 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, PadN and Home
       Address 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

Manyfolks                                               [Page 7]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


       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
   error checks as specified in section 4.4 of RFC 2460. Under the
   simplifying assumptions, 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. If a
   cellular link resembles a point-to-point link, a mobile terminal may
   only have its default routers as neighbors. Therefore, in this
   situation, Neighbor Solicitation and Advertisement messages MAY be
   implemented. If a cellular host does not have a MAC address on its
   cellular interface, the link layer suboption SHOULD NOT be
   implemented for this interface.  It is for further study to study in
   which direction this is applicable.

2.5.1 Neighbor Discovery in 3GPP

   3GPP terminals only need to support Router Solicitations and Router
   Advertisements for 3GPP IPv6 Stateless Address Autoconfiguration.
   See appendix A for more details. Neighbor Sollicitations and
   Advertisements may be supported for Neighbor Unreachability
   Detection. They are not needed for 3GPP IPv6 Stateless Address
   Autoconfiguration, since Duplicate Address Detection is not needed
   in this address assignment mechanism.

2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration


Manyfolks                                               [Page 8]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


   IPv6 Stateless Address Autoconfiguration [ADDRCONF] MAY be
   supported. It is recommended not to perform the Duplicate Address
   Detection if the IPv6 address (suffix) uniqueness is taken care of
   by a network element (on the same link). It will avoid unnecessary
   (valuable) bandwidth consumption in the cellular environment.

2.6.1 Stateless Address Autoconfiguration in 3GPP

   A 3GPP Cellular host MUST be able to process a Router Advertisement
   as stated in chapter 5.5.3 of [ADDRCONF]. However, a cellular host
   in a 3GPP Architecture does not generate its own IPv6 address
   (suffix), therefore Duplicate Address Detection is not needed.
   See appendix A for more details on 3GPP IPv6 Stateless Address
   Autoconfiguration.

2.7 RFC2463 - Internet Control Message Protocol for the IPv6

   The Internet Control Message Protocol for the IPv6 [ICMPv6] 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 [IPv6PPP] MUST be supported for cellular hosts that
   implement PPP.

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 [MLD] SHOULD be supported if the
   cellular host supports multicast functionality.

2.11 RFC2711 - IPv6 Router Alert Option

   The Router Alert Option [RFC-2711] MAY be supported. Since the
   cellular host will not function as a router, the receiver side of
   the Router Alert Option can be omitted even in case the Router Alert
   Option is supported.

2.12 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers


Manyfolks                                               [Page 9]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


   Transition mechanisms [TRANSMECH] MAY be supported. See Appendix B
   for more details.

2.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6

   Privacy Extensions for Stateless Address Autoconfiguration [RFC-
   3041] MAY be supported.

2.13.1 Privacy Extensions for Stateless AA in 3GPP

   The Privacy Extensions for Stateless Autoconfiguration RFC [RFC-
   3041] is incompatible with the 3GPP model and MUST NOT be supported
   if the 3GPP IPv6 Stateless Address Autoconfiguration is used. 3GPP
   IPv6 Stateless Address Autoconfiguration uses Neigbor Discovery
   messages, but the host is not allowed to propose its own interface
   identifier. The network provides the complete IPv6 address to the
   3GPP host. A host implementing Privacy Extensions for Stateless
   Autoconfiguration will periodically change its interface identifier.
   Depending on the specific implementation of the 3GPP network, the
   packets originated from and destined for the new address will most
   likely be dropped. See Appendix A for more details on 3GPP IPv6
   address assignment and Chapter 5 for the security implications of
   this.

2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds

   Connection of IPv6 domains via IPv4 clouds [RFC-3056] MAY be
   supported.

   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)

   Dynamic Host Configuration Protocol for IPv6 [DHCPv6] MAY be
   supported.

   It is possible for the DHCP client to be implemented on the cellular
   host.

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.However,
   note that the rules in [DEFADDR] can be greatly simplified  when
   cellular hosts do not implement the optional policy table, and/or
   have just one global IPv6 address.


Manyfolks                                               [Page 10]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


2.17 DNS

   Some networks may provide DNS-proxy service for simple cellular
   hosts. Therefore, generally, DNS MAY be supported.

2.17.1 RFC1034 - Domain Names _ Concepts and Facilities

   The concepts and facilities of domain names are specified in [RFC-
   1034]. This RFC MUST be supported for cellular hosts which support
   DNS.

2.17.2 RFC1035 - Domain Names _ Implementation and Specification

   The implementation and specification are described in [RFC-1035].
   This RFC MUST be supported for cellular hosts which support DNS.

2.17.3 RFC1886 - DNS Extension to support IP version 6

   DNS Extension for IPv6 [RFC-1886] MUST be supported for cellular
   hosts which support DNS.

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

   DNS Extensions to Support IPv6 Address Aggregation and Renumbering
   [RFC-2874] MAY 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.18 Security Issues

   Chapter 3 describes where IP Security [RFC-2401] should or should
   not be used. Nevertheless, even if a particular terminal does not
   support IP Security, it MUST be able to refuse IKE [RFC-2409]
   connection attempts. The purpose of this is to provide a clean
   indication to the other host that this particular host is not
   willing to provide security associations.

   It is for further study whether IKE response messages are needed for
   the clean indication or if ICMP port unreachable reports are
   sufficient.

3 IP Security

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

    -  VPN service to a corporate intranet
    -  Web browsing service

Manyfolks                                               [Page 11]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


    -  IP Multimedia Service as defined by 3GPP
    -  Mobility service as defined by Mobile IP
    -  Protection of IPv6 infrastructure communications in the local
       network

   Recommendations are given on what security solution to employ in
   these situations, though in some cases work by other bodies or
   working groups hasn't progressed far enough to state the solution
   yet. It is however 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.

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

   Cellular hosts that provide only a simple web browsing service
   SHOULD provide SSL or TLS [RFC-2246]. The use of security in a web
   browser is seen in most cases as necessary, 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 SSL/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.

   It is likely that no end-to-end security will be mandated for the
   multimedia streams themselves in the first releases of the 3GPP IMS
   service specifications. However, it is necessary to provide security
   for the signaling parts. The 3GPP SA3 group is currently evaluating
   the use of IPsec, S/MIME/CMS-based approaches, and other techniques.
   When this work completes, more can be said about the mandated
   security services for the IMS.

   Hosts supporting mobility services [MIPv6], will need a security
   solution which is also currently under development in the IETF.

   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 within the context of 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 an 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 common root CA would
   have to be found that encompasses both the visiting cellular host of

Manyfolks                                               [Page 12]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


   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.

3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication

   This RFC [RFC-2104] MUST be supported, as it is referenced from RFC
   2403 which is mandatory in this set.

3.2 RFC2401 - Security Architecture for the Internet Protocol

   This RFC [RFC-2401] MUST be supported.

3.3 RFC2402 - IP Authentication Header

   This RFC [RFC-2402] SHOULD 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. We also note
   that the IPsec WG has discussed the removal of AH, it is no longer
   certain that AH be used for securing Mobile IP Binding Updates, and
   tunnel mode ESP with integrity protection can perhaps be used to
   provide some of the functions of AH.

   For these reasons AH is made a SHOULD and ESP a MUST. However,
   feedback is sought on the matter since this is against the
   traditional standard rules, and the protection offered by AH is
   different from ESP.

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.


Manyfolks                                               [Page 13]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


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] SHOULD be supported. Automatic key management,
   [RFC-2408] and [RFC-2409], are 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 data base of the peer as well. Regardless of this,
   automatic key management is not made a mandatory requirement here.
   This is because there may be other special-purpose keying schemes
   for particular applications.

   In the cellular environment, the detailed MUSTs within the IP
   Security DoI, ISAKMP, and IKE is for further study. It is likely
   that several simplifying assumptions can be made. 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.

3.9 RFC2408 - ISA and Key Management Protocol

   This RFC [RFC-2408] MUST be supported where IKE is necessary for the
   particular service provided, as described in the start of chapter 3,
   and MAY be supported otherwise.

3.10 RFC2409 - The Internet Key Exchange (IKE)

   This RFC [RFC-2409] SHOULD be supported where IKE is necessary for
   the particular service provided, as described in the start of
   chapter 3, and MAY be supported otherwise.

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

   This RFC [RFC-2410] MUST be supported where IKE is necessary for the
   particular service provided, as described in the start of chapter 3,
   and MAY be supported otherwise.

3.12 RFC2411 - IP Security Document Roadmap

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



Manyfolks                                               [Page 14]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


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

   The IETF IPSRA WG is working on solutions to provide remote access
   mechanisms on top of IPsec in situations where legacy RADIUS or
   other authentication is desired instead of PKI-based authentication.
   These solutions are currently under development, but SHOULD be
   supported by cellular hosts offering VPN services to corporate
   intranets.

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.

3.16 ICMPv6 and Its Effect to IKE and IPsec Policies

   This specification [ICMPIKEv6] MUST be supported by hosts, if they
   also support IKE. Without this specification, there may be certain
   undesirable interactions between ICMPv6 and IKE.

4 IP Mobility

   Mobile IPv6 manages IP mobility resulting from the change in CoA
   when a host moves within the Internet topology. This section will
   detail the level of support of MIPv6 required by cellular hosts and
   highlight the scenarios in which such support is needed.

4.1 Mobility Support in IPv6

   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:

     - Mobile Node (MN) functionality, defined by Mobile IPv6
       specification [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.
     - Correspondent Node (CN) functionality [MIPv6], i.e. the basic
       functionality needed to correspond with mobile nodes.

Manyfolks                                               [Page 15]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


     - 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 mobile node
   functionality is needed when the host itself will move within the
   Internet topology i.e. changes it's care-of address. This function
   is needed in cellular systems where MIPv6 is used for intra-domain
   mobility. In other cellular systems where intra-domain mobility is
   handled by other means (e.g. GTP in a 3GPP system), only 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.

   The basic functionality of a Correspondent Node, i.e. process the
   Home Address Option, MUST be supported by all hosts.

   The Route Optimized functionality for a CN, i.e. processing of
   Binding Updates, SHOULD be supported by all hosts when the
   communication benefits from this optimization.



4.2 Fast Handovers for Mobile IPv6

   Fast handovers for Mobile IPv6 is specified in [MIPv6-FH].

   This draft SHOULD be supported if Mobile IPv6 [MIPv6] is supported
   and when communication benefits from this optimization.

4.2.1 3GPP and Fast Handoffs

   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
   Handoffs draft will not be required within the current 3GPP
   architecture.


Manyfolks                                               [Page 16]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


4.3 Hierarchical MIPv6 Mobility Management

   Hierarchical MIPv6 is specified in [HMIPv6].

   Hierarchy SHOULD be supported to run MIPv6 efficiently over the air.
   This aims to reduce the number of MIPv6 BUs sent over the air while
   moving within the topology.

4.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 which allows a MN to receive different traffic flows on
   different interfaces.

4.4 Mobile IP Security

   The security design for Mobile IP is currently being performed in
   the IETF. Before this work completes it will not be possible to
   state in detail the security requirements for cellular hosts using
   Mobile IP. However, we expect that security solutions will be
   provided both for the protection of binding updates to correspondent
   nodes, as well as secure tunneling support between the mobile node
   and its home.

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.

    - The incompatibility of the addressing privacy [RFC3041] and 3GPP
      address autoconfiguration model prevents the use of exactly the
      same kind of privacy functionality as provided in IPv6. However,
      it should be noted that in the 3GPP model the network will
      assign new addresses to hosts in roaming situations and
      typically also when the cellular terminals are turned on. This
      means that a limited form of addressing privacy will already be
      provided by 3GPP networks, and no global tracking of a single
      terminal is possible through its address.


Manyfolks                                               [Page 17]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


    - The use of various security services such as IPsec or SSL 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 due to problems setting up
      sufficient PKI infrastructure for such usage.

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

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

Manyfolks                                               [Page 18]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


      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

   [3GPPADDR]     3GPP 23.060, version 4.00, chapter 9.2.1.1

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

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

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

   [AESIPSEC]     Frankel, S., Kelly, S. and Glenn, R., "The Candidate
                  AES Cipher Algorithms and Their Use With IPsec",
                  draft-ietf-ipsec-ciph-aes-cbc-01.txt, November 2000,
                  Work in progress

   [DEFADDR]      Draves, R., "Default Address Selection for IPv6",
                  draft-ietf-ipngwg-default-addr-select-05.txt, June
                  2001, Work in progress.

   [DHCPv6]       Bound, J. et al., "Dynamic Host Configuration
                  Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-
                  19.txt, June 2001 Work in progress.

   [HMIPv6]       Soliman, H., Castelluccia, C., El-Malki, K. and
                  Bellier, L., "Hierarchical MIPv6 mobility
                  management", draft-ietf-mobileip-hmipv6-04.txt, July
                  2001, Work in progress

   [ICMPIKEv6]    Arkko, J., "Effects of ICMPv6 on IKE and IPsec
                  Policies", draft-arkko-icmpv6-ike-effects-00.txt,
                  February 2001, Work in progress

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

Manyfolks                                               [Page 19]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001



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

   [IPv6PPP]      Haskin, D. and Allen, E., "IP Version 6 over PPP",
                  RFC 2472, December 1998

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

   [MIPv6]        Johnson D. and Perkins, C., "Mobility Support in
                  IPv6", draft-ietf-mobileip-ipv6-14.txt, July 2001,
                  Work in progress.

   [MIPv6-FH]     Tsirtsis, G. et al., "Fast Handovers for Mobile
                  IPv6", draft-ietf-mobileip-fast-mipv6-02.txt, July
                  2001, Work in progress.

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

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

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

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

Manyfolks                                               [Page 20]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001



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

   [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-2461]     Narten, T., Nordmark, E. and Simpson, W., "Neighbor
                  Discovery for IP Version 6 (IPv6)", RFC 2461,
                  December 1998.

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

   [RFC-2529]     Carpenter, B. and Jung, C., "Transmission of IPv6
                  over IPv4 Domains without Explicit Tunnels_, RFC
                  2529, March 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 21]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001



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

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

   [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, draft-ietf-pilc-2.5g3g-02.txt, Work in
                  progress.

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

7 Acknowledgements

   The authors would like to thank David DeCamp, Markus Isomaki, Petter
   Johnsen, Janne Rinne, Jonne Soininen, Hesham Soliman and Shabnam
   Sultana for there comments and input.

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.n.hedman@ecs.ericsson.se

   Gerben Kuijpers
   Ericsson
   Skanderborgvej 232
   DK-8260 Viby J
   DENMARK

   Phone:  +45 89385100

Manyfolks                                               [Page 22]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


   Fax:    +45 89385101
   E-mail: gerben.a.kuijpers@ted.ericsson.dk

   John Loughney
   Nokia Research Center
   Itamerenkatu 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
   Sinitaival 5
   FIN-33720 TAMPERE
   Finland

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

   Juha Wiljakka
   Nokia Mobile Phones
   Sinitaival 5
   FIN-33720 TAMPERE
   Finland

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

Appendix A Cellular Host IPv6 Addressing in the 3GPP Model

   The appendix aims to describe 3GPP (Third Generation Partnership
   Project) IPv6 addressing model for 2G (GPRS) and 3G (UMTS) cellular
   networks [3GPPADDR].

   There are two possibilities to allocate an 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. In the stateless autoconfiguration, the IPv6 node is
   more involved in the allocation and the stateless autoconfiguration
   procedure does not need any external entity involved in the address
   autoconfiguration.

   The two important network elements in the 3GPP packet based
   architecture are SGSN (Serving GPRS Support node) and GGSN (Gateway
   GPRS Support Node).  GGSN is the nearest router for the mobile
   terminal / cellular host and it is responsible for giving an IP

Manyfolks                                               [Page 23]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


   address to the mobile terminal.  The logical link established
   between the GGSN Access Point and the mobile terminal is called PDP
   (Packet Data Protocol) context.

   To support dynamic IPv6 address allocation by the PLMN (Public Land
   Mobile Network) operator, the GGSN provides a unique interface
   identifier (see RFC 2462) to the mobile terminal.  This enables the
   cellular host to perform the IPv6 stateless autoconfiguration
   procedures to generate its full IPv6 address.

   In the first phase the mobile terminal sends an Activate PDP Context
   Request message to the SGSN. The mobile terminal shall leave PDP
   Address empty and set PDP Type to IPv6. The GGSN shall create the
   unique link-local address for the mobile terminal and send it in the
   PDP Address information element in the Create PDP Context Response
   message. The link local address consists of a fixed 10-bit prefix
   (IPv6 link-local prefix), zero or more 0 bits, and the interface
   identifier.

   After that the mobile terminal may send a Router Solicitation
   message to the GGSN to activate the sending of the Router
   Advertisement message.

   The GGSN should automatically send the Router Advertisement message
   after the PDP context is activated. In 3GPP Release 99 the GGSN
   shall be configured to advertise only one network prefix per APN
   (Access Point Name).

   After the mobile terminal has received the Router Advertisement
   message, it constructs its full IPv6 address by concatenating the
   interface identifier contained in the link-local address provided in
   the Create PDP Context Response Message and the network prefix of
   the selected APN received in the Router Advertisement. Subsequently,
   the mobile terminal is ready to start communicating to the Internet.

   Because the GGSN provides a unique interface identifier during the
   PDP context activation procedure, there is no need for the mobile
   terminal to perform Duplicate Address Detection for this IPv6
   address.  Therefore, the GGSN shall intercept and discard Neighbor
   Solicitation messages that the mobile terminal may send to perform
   Duplicate Address Detection.  It is possible for the mobile terminal
   to perform Neighbor Unreachability Detection, as defined in RFC
   2461; therefore if the GGSN receives a Neighbor Solicitation as part
   of this procedure, the GGSN shall provide a Neighbor Advertisement
   as described in RFC 2461.

   Finally, the GGSN updates the PDP context in the SGSN and mobile
   terminal with the full IPv6 address (so-called GGSN-Initiated PDP
   Context Modification Procedure).



Manyfolks                                               [Page 24]


Internet Draft    Min. IPv6 Func. for a Cellular Host    July 2, 2001


Appendix B 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 majority of the 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.






























Manyfolks                                               [Page 25]


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