{\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset0 Courier New;}} \viewkind4\uc1\pard\lang1053\f0\fs20\par INTERNET-DRAFT Jari Arkko\par Internet Engineering Task Force Peter Hedman\par Gerben Kuijpers\par Ericsson\par John Loughney\par Pertti Suomela\par Juha Wiljakka\par Nokia\par Issued: November 20, 2001\par Expires: May 20, 2002\par \par Minimum IPv6 Functionality for a Cellular Host\par \par \par Status of This Memo\par \par This document is an Internet-Draft and is in full conformance with\par all provisions of Section 10 of RFC 2026.\par \par Internet-Drafts are working documents of the Internet Engineering\par Task Force (IETF), its areas, and its working groups. Note that\par other groups may also distribute working documents as Internet-\par Drafts.\par \par Internet-Drafts are draft documents valid for a maximum of six\par months and may be updated, replaced, or obsoleted by other documents\par at any time. It is inappropriate to use Internet-Drafts as\par reference material or to cite them other than as 'work in progress.'\par \par The list of current Internet-Drafts can be accessed at\par http://www.ietf.org/ietf/1id-abstracts.txt\par \par The list of Internet-Draft Shadow Directories can be accessed at\par http://www.ietf.org/shadow.html.\par \par Abstract\par \par As an increasing number of cellular hosts are being connected to the\par Internet, IPv6 becomes necessary. Examples of such hosts are GPRS,\par UMTS, and CDMA2000 terminals. Standardization organizations are also\par making IPv6 mandatory in their newest specifications, such as the IP\par multimedia terminals specified for UMTS. However, the concept of\par IPv6 covers many aspects, numerous RFCs, a number of different\par situations, and is also partly still evolving. A rapid adoption of\par IPv6 is desired for cellular hosts. Yet these terminals vary greatly\par in terms of their processing capabilities and task orientation.\par Cellular host software often cannot be upgraded, yet it must meet\par tough demands for interoperability with other hosts, the cellular\par network, and the Internet. For these reasons it is necessary to\par understand how the IPv6 deployment starts and which parts of IPv6\par are necessary under which situations. This document suggests basic\par IPv6 functionality for cellular hosts, and discusses when parts of\par the functionality is needed, and under which conditions. \par \par \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par \par Abstract............................................................1\par 1 Introduction......................................................3\par 1.1 Abbreviations..................................................5\par 1.2 Requirement Language...........................................5\par 1.3 Cellular Host IPv6 Features....................................5\par 2 Core IP...........................................................6\par 2.1 RFC1981 - Path MTU Discovery for IP Version 6..................6\par 2.2 RFC2373 - IP Version 6 Addressing Architecture.................6\par 2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format......6\par 2.4 RFC2460 - Internet Protocol Version 6..........................7\par 2.5 RFC2461 - Neighbor Discovery for IPv6..........................7\par 2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration.............8\par 2.7 RFC2463 - Internet Control Message Protocol for the IPv6.......8\par 2.8 RFC2472 - IP version 6 over PPP................................9\par 2.9 RFC2473 - Generic Packet Tunneling in IPv6 Specification.......9\par 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6.........9\par 2.11 RFC2711 - IPv6 Router Alert Option............................9\par 2.12 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers....9\par 2.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6.........9\par 2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds.........10\par 2.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)........10\par 2.16 Default Address Selection for IPv6...........................10\par 2.17 DNS..........................................................10\par 2.18 Security Issues..............................................11\par 3 IP Security......................................................11\par 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication......13\par 3.2 RFC2401 - Security Architecture for the Internet Protocol.....13\par 3.3 RFC2402 - IP Authentication Header............................13\par 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH............13\par 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH............13\par 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV...13\par 3.7 RFC2406 - IP Encapsulating Security Payload (ESP).............13\par 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP.............13\par 3.9 RFC2408 - ISA and Key Management Protocol.....................14\par 3.10 RFC2409 - The Internet Key Exchange (IKE)....................14\par 3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec.15\par 3.12 RFC2411 - IP Security Document Roadmap.......................15\par 3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms.................15\par 3.14 IP Security Remote Access....................................15\par 3.15 The AES Cipher Algorithm and Its Use With IPsec..............15\par 4 IP Mobility......................................................15\par 4.1 Mobility Support in IPv6......................................15\par 4.2 Fast Handovers for Mobile IPv6................................17\par 4.3 Hierarchical MIPv6 Mobility Management........................17\par 4.4 Mobile IP Security............................................17\par 5 Security Considerations..........................................17\par 6 References.......................................................19\par 7 Acknowledgements.................................................22\par 8 Authors' Addresses...............................................22\par Appendix A Revision History........................................24\par \par Manyfolks [Page 2]\par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par Appendix B Cellular Host IPv6 Addressing in the 3GPP Model.........24\par Appendix C Transition Issues.......................................25\par \par \par 1 Introduction\par \par Technologies such as GPRS (General Packet Radio Service), UMTS\par (Universal Mobile Telecommunications System), and CDMA2000 are\par making it possible for cellular hosts to have an always-on\par connection to the Internet. IPv6 becomes necessary, as it is\par expected that the number of such cellular hosts will increase\par rapidly. Standardization organizations working with cellular\par technologies have recognized this, and are making IPv6 mandatory in\par their newest specifications. One example of this is that 3GPP\par specifies IPv6 support as mandatory for future UMTS IP multimedia\par terminals.\par \par The purpose of this draft is to propose a compact set of IPv6\par specifications and functionality that cellular hosts must support.\par Such a specification is necessary in order to determine the optimal\par way to use IPv6 in a cellular environment. Important considerations\par are how to minimize footprint and implementation effort for a large\par number of consumer terminals, eliminate unnecessary user confusion\par with regards to configuration options, ensure interoperability and\par to provide an easy reference for those implementing IPv6 in a\par cellular host. The overarching desire is to ensure that cellular\par hosts are good citizens on the Internet.\par \par The main audiences of this document are the implementers who need\par guidance on what to implement. The IETF that wants to ensure a well-\par working global IPv6 network, and other standardization organizations\par that need a reference to how IPv6 can be mandated on their\par standards.\par \par For the purposes of this document, a cellular host is considered to\par be a terminal which uses an air interface to connect to a cellular\par access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6\par connectivity to an IP network. The functionality to provide this\par connectivity is outlined in this draft. The description is made from\par a general cellular host point of view, and this document is intended\par to be applicable for many types of cellular network standards (or\par even multi-standard devices). The implementation of parts of the\par IPv6 specification in specific cellular networks (such as the UMTS)\par may differ from the general recommendation. Where this applies,\par additional information is given on how to make that part of IPv6\par work in that specific cellular network. This information can also be\par used to provide standardization bodies insight in which issues it\par may be necessary to revise in future releases of the particular\par cellular network specifications.\par \par \par \par Manyfolks [Page 3] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par Parts of this document may also be applicable in other, non-cellular\par contexts, such as small IPv6 appliances with similar size and cost\par restrictions. The scope of this document, however, is the cellular\par hosts and it may not cover all issues relevant in those other\par contexts.\par \par The use of IPv6 within cellular networks implies an implementation\par of the IPv6 stack within a wide range of terminals. Such terminals\par may vary significantly in terms of capacity, task orientation and\par processing power. For instance, the smallest handheld terminals can\par have a very limited amount of memory, computational power, and\par battery capacity. Cellular hosts operate over low bandwidth wireless\par links with limited throughput. As such, there are certain\par optimizations that would be required for these hosts in order to fit\par the largest possible amount of terminals within an area of spectrum.\par \par Tough demands are set for interoperability of cellular hosts towards\par other hosts, the cellular network, and the Internet. It is often\par hard or impossible to upgrade a large number of cellular hosts to a\par new software version. The long lifetime of the terminals sets a\par requirement for old equipment to still work in newer versions of the\par network and other hosts.\par \par The concept of IPv6 covers many aspects, numerous RFCs, a number of\par different situations, and is also partly still in evolution. For\par these reasons it is necessary to understand how the IPv6 deployment\par starts and which parts of IPv6 are necessary under which situations.\par This document reviews the IPv6 functionality, grouped under three\par categories: core IP, security, and mobility. For each category and\par each RFC in them, we discuss the following:\par \par - Is this part of functionality needed by cellular hosts and under\par which conditions?\par - In some cases individual parts of the RFCs are discussed in more\par detail and recommendations are given regarding their support.\par - In some other cases conflicts between some parts of\par functionality and the current cellular network protocols are\par identified.\par \par The aim of this work is to introduce a minimal set of IPv6\par functionality - subject to the particular type of terminal and\par application - that would be required for cellular IPv6 hosts. As a\par general guideline, a cellular host should not appear any different\par from other IPv6 hosts. The set of requirements proposed should be\par suited to terminals with minimal capabilities, low cost and\par processing power. Interoperability can be achieved by listing needed\par IPv6 related IETF specifications according to chapter 1.2.\par \par The scope of the discussion in this document is the IPv6\par functionality. The reader should be advised that other work exists\par for various other layers, which is not IPv6 specific such as the\par \par Manyfolks [Page 4] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par header compression work done in the IETF ROHC group, or the TCP work\par in [TCPWIRELESS].\par \par The history of IPv6 in 3GPP specifications is briefly described in\par this paragraph. IPv6 was introduced as an option starting in 3GPP\par Release 97 (that was originally an ETSI release) GSM / GPRS\par specifications. A wider support for IPv6 (and the introduction of\par UMTS) shall start with 3GPP Release 99 networks and terminals. IPv6\par is specified as the only IP version supported in Release 5 for IP\par Multimedia Subsystem (IMS). The authors used 3GPP Release 99 and\par Release 4 specifications as defined when this document was written\par as a base. Any possible changes to current IPv6 specifications shall\par be accommodated as they occur.\par \par The authors of this document seek feedback to ensure that the\par proposed functionality set is consistent, interoperable with the\par rest of the IPv6 Internet, complete, and does not open new security\par risks.\par \par 1.1 Abbreviations\par \par 3GPP Third Generation Partnership Project\par AH Authentication Header\par CDMA2000 Code Division Multiple Access 2000, the name identifying\par the third generation technology of IS-95 CDMA standard\par and ANSI-41 network.\par ESP Encapsulating Security Payload\par ETSI European Telecommunications Standards Institute\par IMS IP Multimedia Subsystem\par GGSN Gateway GPRS Support Node\par GPRS General Packet Radio Service\par GSM Global System for Mobile Communications\par IKE Internet Key Exchange\par ISAKMP Internet Security Association and Key Management\par Protocol\par MTU Maximum Transmission Unit\par SGSN Serving GPRS Support Node\par UMTS Universal Mobile Telecommunications System\par WLAN Wireless LAN\par \par 1.2 Requirement Language\par \par The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,\par SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this\par document, are to be interpreted as described in [KEYWORDS].\par \par 1.3 Cellular Host IPv6 Features\par \par This specification defines IPv6 features for cellular hosts in three\par groups.\par \par \par Manyfolks [Page 5] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par Core IP\par \par In this group we describe the core parts of IPv6. Only RFCs\par needed in all situations and under all conditions are in this\par group.\par \par IP Security\par \par In this group we discuss the IP layer security functionality\par suitable for cellular hosts. Chapter 3 defines the contents\par of this group, and discusses its usage in different contexts.\par \par IP Mobility\par \par In this group we discuss IP layer mobility functionality for\par cellular hosts. Basic functionality needed just to correspond\par with mobile nodes is a part of the Core IP group. Chapter 4\par defines the contents of the IP Mobility group, and discusses\par its usage in different contexts.\par \par \par \par 2 Core IP\par \par This section describes the minimum needed IPv6 functionality of a\par cellular host in order to be able to communicate with other IPv6\par hosts.\par \par 2.1 RFC1981 - Path MTU Discovery for IP Version 6\par \par Path MTU Discovery [PMTU] MAY be supported.\par \par The IPv6 specification [IPv6] states in chapter 5 that "a minimal\par IPv6 implementation (e.g., in a boot ROM) may simply restrict itself\par to sending packets no larger than 1280 octets, and omit\par implementation of Path MTU Discovery."\par \par If Path MTU Discovery is not implemented then the uplink packet size\par MUST be limited to 1280 octets (standard limit in [IPv6]). However,\par the cellular host MUST be able to receive packets with size up to\par the link MTU before reassembly.\par \par 2.2 RFC2373 - IP Version 6 Addressing Architecture\par \par The IPv6 Addressing Architecture [ADDRARCH] MUST be supported. IPX &\par NSAP addresses SHOULD NOT be used.\par \par 2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format\par \par The IPv6 Aggregatable Global Unicast Address Format is described in\par [RFC-2374]. This RFC MUST be supported.\par \par Manyfolks [Page 6] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par \par 2.4 RFC2460 - Internet Protocol Version 6\par \par The Internet Protocol Version 6 is specified in [IPv6]. This RFC\par MUST be supported.\par \par The cellular host is assumed to act as a host, not a router.\par Implementation requirements for a cellular router are not defined in\par this document.\par \par The cellular host MUST implement all non-router packet receive\par processing as described in RFC 2460. This includes the generation\par of ICMPv6 error reports, and at least minimal processing of each\par extension header:\par \par - Hop-by-Hop Options header: at least the Pad1 and PadN options\par - Destination Options header: at least the Pad1, PadN and Home\par Address options\par - Routing (Type 0) header: final destination (host) processing\par only\par - Fragment header\par - AH and ESP headers: In the case of the Core IP functionality\par only, AH and ESP headers are treated as if the Security\par Association had not existed, i.e. - packets with these headers\par are dropped. When the IP Security functionality is in use, they\par are processed as specified in RFCs 2401, 2402, and 2406.\par - The No Next Header value\par \par Unrecognized options in Hop-by-Hop Options or Destination Options\par extensions must be processed as described in RFC 2460.\par \par The cellular host must follow the packet transmission rules in RFC\par 2460. A cellular host implementing the Core IP functionality will\par typically send packets containing either no extension headers or the\par Fragment header. However, a cellular host MAY generate any of the\par extension headers.\par \par Cellular Hosts will act as the destination when processing the\par Routing Header. This will also ensure that the cellular hosts will\par not be inappropriately used as relays or components in Denial-of-\par Service attacks. Acting as the destination involves the following.\par The cellular hosts MUST check the Segments Left field in the header,\par and proceed if it is zero or one and the next address is one of the\par terminal's addresses. If not, however, the terminal MUST implement\par error checks as specified in section 4.4 of RFC 2460. Under the\par simplifying assumptions, there is no need for the terminal to send\par Routing Headers.\par \par 2.5 RFC2461 - Neighbor Discovery for IPv6\par \par \par \par Manyfolks [Page 7] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par Neighbor Discovery is described in [RFC-2461] and, in general, MUST\par be supported.\par \par In cellular networks, some Neighbor Discovery messages can cause\par unnecessary traffic and consume valuable (limited) bandwidth. If a\par cellular link resembles a point-to-point link, a mobile terminal may\par only have its default routers as neighbors. Therefore, in this\par situation, Neighbor Solicitation and Advertisement messages MAY be\par implemented. If a cellular host does not have a MAC address on its\par cellular interface, the link layer suboption SHOULD NOT be\par implemented for this interface. It is for further study to study in\par which direction this is applicable.\par \par 2.5.1 Neighbor Discovery in 3GPP\par \par 3GPP terminals only need to support Router Solicitations and Router\par Advertisements for 3GPP IPv6 Stateless Address Autoconfiguration.\par See appendix B for more details. Neighbor Solicitations and\par Advertisements may be supported for Neighbor Unreachability\par Detection. They are not needed for 3GPP IPv6 Stateless Address\par Autoconfiguration, since Duplicate Address Detection is not needed\par in this address assignment mechanism.\par \par 2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration\par \par IPv6 Stateless Address Autoconfiguration [ADDRCONF] MAY be\par supported. It is recommended not to perform the Duplicate Address\par Detection if the IPv6 address (suffix) uniqueness is taken care of\par by a network element (on the same link). It will avoid unnecessary\par (valuable) bandwidth consumption in the cellular environment.\par \par 2.6.1 Stateless Address Autoconfiguration in 3GPP\par \par A 3GPP Cellular host MUST be able to process a Router Advertisement\par as stated in chapter 5.5.3 of [ADDRCONF]. However, a cellular host\par in a 3GPP Architecture does not generate its own IPv6 address\par (suffix), therefore Duplicate Address Detection is not needed.\par See appendix B for more details on 3GPP IPv6 Stateless Address\par Autoconfiguration.\par \par 2.7 RFC2463 - Internet Control Message Protocol for the IPv6\par \par The Internet Control Message Protocol for the IPv6 [ICMPv6] MUST be\par supported.\par \par As per RFC 2463 section 2, ICMPv6 requirements MUST be fully\par implemented by every IPv6 node. However, references to the use of IP\par Security (sections 5.1 and 5.2) are not relevant for Core IP\par features.\par \par \par \par Manyfolks [Page 8] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par 2.8 RFC2472 - IP version 6 over PPP\par \par IPv6 over PPP [IPv6PPP] MUST be supported for cellular hosts that\par implement PPP.\par \par 2.9 RFC2473 - Generic Packet Tunneling in IPv6 Specification\par \par Generic Packet Tunneling [RFC-2473] MAY be supported if needed for\par transition mechanisms and MUST be supported if the Mobile Node\par functionality of Mobile IP is implemented, as specified in chapter\par 4.\par \par 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6\par \par Multicast Listener Discovery [MLD] SHOULD be supported if the\par cellular host supports multicast functionality.\par \par 2.11 RFC2711 - IPv6 Router Alert Option\par \par The Router Alert Option [RFC-2711] MAY be supported. Since the\par cellular host will not function as a router, the receiver side of\par the Router Alert Option can be omitted even in case the Router Alert\par Option is supported.\par \par 2.12 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers\par \par Transition mechanisms [TRANSMECH] MAY be supported. See Appendix C\par for more details.\par \par 2.13 RFC3041 - Privacy Extensions for Stateless AA in IPv6\par \par Privacy Extensions for Stateless Address Autoconfiguration [RFC-\par 3041] MAY be supported.\par \par 2.13.1 Privacy Extensions for Stateless AA in 3GPP\par \par The Privacy Extensions for Stateless Autoconfiguration RFC [RFC-\par 3041] is incompatible with the 3GPP model and MUST NOT be supported\par if the 3GPP IPv6 Stateless Address Autoconfiguration is used. 3GPP\par IPv6 Stateless Address Autoconfiguration uses Neighbor Discovery\par messages, but the host is not allowed to propose its own interface\par identifier. The network provides the complete IPv6 address to the\par 3GPP host. A host implementing Privacy Extensions for Stateless\par Autoconfiguration will periodically change its interface identifier.\par Depending on the specific implementation of the 3GPP network, the\par packets originated from and destined for the new address will most\par likely be dropped. See Appendix B for more details on 3GPP IPv6\par address assignment and Chapter 5 for the security implications of\par this.\par \par \par \par Manyfolks [Page 9] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par 2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds\par \par Connection of IPv6 domains via IPv4 clouds [RFC-3056] MAY be\par supported.\par \par For a cellular host, this specification would mean capability to\par create 6to4 tunnels starting from the cellular host itself. In a\par cellular environment, tunneling over the air interface should be\par minimized. Hence, 6to4 tunneling SHOULD be carried out by\par intermediate 6to4 routers rather than the cellular host.\par \par 2.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)\par \par Dynamic Host Configuration Protocol for IPv6 [DHCPv6] MAY be\par supported.\par \par It is possible for the DHCP client to be implemented on the cellular\par host.\par \par 2.16 Default Address Selection for IPv6\par \par Default Address Selection for IPv6 [DEFADDR] SHOULD be supported\par since cellular hosts can have more than one IPv6 address. However,\par note that the rules in [DEFADDR] can be greatly simplified when\par cellular hosts do not implement the optional policy table, and/or\par have just one global IPv6 address.\par \par 2.17 DNS\par \par Some networks may provide DNS-proxy service for simple cellular\par hosts. Therefore, generally, DNS MAY be supported.\par \par 2.17.1 RFC1034 - Domain Names - Concepts and Facilities\par \par The concepts and facilities of domain names are specified in [RFC-\par 1034]. This RFC MUST be supported for cellular hosts which support\par DNS.\par \par 2.17.2 RFC1035 - Domain Names - Implementation and Specification\par \par The implementation and specification are described in [RFC-1035].\par This RFC MUST be supported for cellular hosts which support DNS.\par \par 2.17.3 RFC1886 - DNS Extension to support IP version 6\par \par DNS Extension for IPv6 [RFC-1886] MUST be supported for cellular\par hosts that support DNS.\par \par 2.17.4 RFC2874 - DNS Extensions to Support IPv6 Address Aggregation and\par Renumbering\par \par \par Manyfolks [Page 10] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par DNS Extensions to Support IPv6 Address Aggregation and Renumbering\par [RFC-2874] MAY be supported. A6 can cause problems for cellular\par hosts operating over wireless links since several round trips may be\par needed to collect a complete DNS record, when a DNS resolver is\par implemented on a cellular host.\par \par 2.18 Security Issues\par \par Chapter 3 describes where IP Security [RFC-2401] should or should\par not be used. Nevertheless, even if a particular terminal does not\par support IP Security, it MUST be able to refuse IKE [RFC-2409]\par connection attempts. The purpose of this is to provide a clean\par indication to the other host that this particular host is not\par willing to provide security associations.\par \par It is for further study whether IKE response messages are needed for\par the clean indication or if ICMP port unreachable reports are\par sufficient.\par \par 3 IP Security\par \par The use of IP Security [RFC-2401] or other security services in\par cellular hosts depends on their intended use. The following services\par are discussed here:\par \par - VPN service to a corporate intranet\par - Web browsing service\par - IP Multimedia Service as defined by 3GPP\par - Mobility service as defined by Mobile IP\par - Protection of IPv6 infrastructure communications in the local\par network\par \par Recommendations are given on what security solution to employ in\par these situations, though in some cases work by other bodies or\par working groups hasn't progressed far enough to state the solution\par yet. It is however strongly suggested that some of the existing set\par of security mechanisms be used rather than new ones developed,\par adding to the amount of memory and implementation effort needed for\par a host supporting multiple services. However, for each service as\par outlined below the requirements are applicable for either the given\par mechanisms or their possible future wireless profiles.\par \par Cellular hosts that provide a VPN service to a corporate intranet,\par for example, or to a transition tunneling gateway MUST support IPsec\par and IKE. This security set is defined in this chapter. For this\par purpose an IPsec Remote Access solution SHOULD also be supported.\par \par Cellular hosts that provide only a simple web browsing service MAY\par provide TLS [RFC-2246]. The use of security in a web browser is seen\par in most cases as necessary, as otherwise the user would be blocked\par from some of the sites - such as e-commerce sites - that do require\par \par Manyfolks [Page 11] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par security. The fact that just TLS should be the protocol to provide\par web security relates to current deployment and the suitability of\par the single-side certificate trust model for this application. Beside\par web browsing services, other services that require client (or user)\par authentication may also use the TLS security mechanism.\par \par It is likely that no end-to-end security will be mandated for the\par multimedia streams themselves in the first releases of the 3GPP IMS\par service specifications. However, it is necessary to provide security\par for the signaling parts. The 3GPP SA3 group is currently evaluating\par the use of IPsec, S/MIME/CMS-based approaches, and other techniques.\par When this work completes, more can be said about the mandated\par security services for the IMS.\par \par Hosts supporting mobility services [MIPv6] will need a security\par solution, which is also currently under development in the IETF.\par \par The use of IPsec, IKE, or other security services directly in the\par underlying IPv6 infrastructure communications (e.g. ICMPv6 or\par Neighbor Discovery) can also be discussed. The use of IPsec towards\par a specific home server in the context of a VPN service is easy.\par However, the use of any security service within the context of local\par next hop routers (GGSNs) or other 3GPP nodes seems hard due to the\par difficulties in establishing a suitable trust infrastructure for\par creating the necessary Security Associations (SAs). In order for a\par terminal to create a SA with the next hop router for the purposes of\par securing the router and neighbor discovery tasks would mean the\par following. First, both the routers and all cellular hosts would have\par to be registered to a PKI system. Second, a common root CA would\par have to be found that encompasses both the visiting cellular host of\par an operator as well as the infrastructure of another operator. It is\par not clear if this is possible with today's technology.\par \par Furthermore, as [ICMPIKEv6] points out, dynamic SA negotiation can't\par be used for the protection of the first few connectivity\par establishment messages in ICMPv6. It may be possible to overcome\par these problems, however, the added security benefits of the\par protection in these cases would be minimal: encrypted radio\par communications exist at a lower layer, and the next hop router can\par always engage in any denial-of-service attacks (such as dropping all\par packets) regardless of the existence of any SAs. For these reasons,\par the 3GPP terminals will not be mandated to support any security for\par the pure IPv6 router and infrastructure protection purposes.\par \par The following subchapters are only applicable for those services\par where IPsec/IKE is recommended above. The below chapters essentially\par define a wireless profile for IPsec/IKE. (Note that future versions\par of this Internet Draft may separate this profiling to an independent\par draft as is done in the case of TLS.)\par \par \par \par Manyfolks [Page 12] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication\par \par This RFC [RFC-2104] MUST be supported, as it is referenced from RFC\par 2403 which is mandatory in this set.\par \par 3.2 RFC2401 - Security Architecture for the Internet Protocol\par \par This RFC [RFC-2401] MUST be supported.\par \par 3.3 RFC2402 - IP Authentication Header\par \par This RFC [RFC-2402] SHOULD be supported. The AH protocol is one of\par the alternative protocols in the IPsec protocol family, the other\par alternative being ESP.\par \par In the interest of minimizing implementation complexity and in\par particular configuration options, both protocols may not be needed\par in a cellular host. It is suggested that the ESP protocol be\par preferred for its confidentiality protection function. We also note\par that the IPsec WG has discussed the removal of AH, it is no longer\par certain that AH be used for securing Mobile IP Binding Updates, and\par tunnel mode ESP with integrity protection can perhaps be used to\par provide some of the functions of AH.\par \par For these reasons AH is made a SHOULD and ESP a MUST. However,\par feedback is sought on the matter since this is against the\par traditional standard rules, and the protection offered by AH is\par different from ESP.\par \par 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH\par \par This RFC [RFC-2403] MUST be supported.\par \par 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH\par \par This RFC [RFC-2404] MUST be supported.\par \par 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV\par \par This RFC [RFC-2405] MAY be supported. It is, however, recommended\par that stronger algorithms than DES be supported.\par \par 3.7 RFC2406 - IP Encapsulating Security Payload (ESP)\par \par This RFC [RFC-2406] MUST be supported.\par \par 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP\par \par This RFC [RFC-2407] SHOULD be supported. Automatic key management,\par [RFC-2408] and [RFC-2409], is not a mandatory part of the IP\par Security Architecture. Note, however, that in the cellular\par \par Manyfolks [Page 13] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par environment the IP addresses of a host may change dynamically. For\par this reason the use of manually configured Security Associations is\par not practical, as the newest host address would have to be updated\par to the SA database of the peer as well. Regardless of this,\par automatic key management is not made a mandatory requirement here.\par This is because there may be other special-purpose keying schemes\par for particular applications.\par \par In the cellular environment, the detailed MUSTs within the IP\par Security DoI, ISAKMP, and IKE are for further study. It is likely\par that several simplifying assumptions can be made. For instance, the\par use of pre-shared secrets as an authentication method in IKE is not\par feasible in practice in the context of a large number of hosts.\par \par 3.9 RFC2408 - ISA and Key Management Protocol\par \par This RFC [RFC-2408] MUST be supported where IKE is necessary for the\par particular service provided, as described in the start of chapter 3,\par and MAY be supported otherwise.\par \par 3.10 RFC2409 - The Internet Key Exchange (IKE)\par \par This RFC [RFC-2409] SHOULD be supported where IKE is necessary for\par the particular service provided, as described in the start of\par chapter 3, and MAY be supported otherwise.\par \par Interactions with the ICMPv6 packets and IPsec policies may cause\par unexpected behavior for IKE-based SA negotiation unless some special\par handling is performed in the implementations.\par \par The ICMPv6 protocol provides many functions, which in IPv4 were\par either non-existent or provided by lower layers. For instance, IPv6\par implements address resolution using an IP packet, ICMPv6 Neighbor\par Solicitation message. In contrast, IPv4 uses an ARP message at a\par lower layer.\par \par The IPsec architecture has a Security Policy Database that specifies\par which traffic is protected, and how. It turns out that the\par specification of policies in the presence of ICMPv6 traffic is not\par easy. For instance, a simple policy of protecting all traffic\par between two hosts on the same network would trap even address\par resolution messages, leading to a situation where IKE can't\par establish a Security Association since in order to send the IKE UDP\par packets one would have had to send the Neighbor Solicitation\par Message, which would have required an SA.\par \par In order to avoid this problem, this specification recommends\par that Neighbor Solicitation, Neighbor Advertisement, Router\par Solicitation, and Router Advertisement messages MUST NOT lead to the\par use of IKE-based SA negotiation. The Redirect message SHOULD NOT\par lead to the use of IKE-based SA negotiation. Other ICMPv6 messages\par \par Manyfolks [Page 14] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par MAY use IKE-based SA negotiation as is desired in the Security\par Policy Data Base.\par \par 3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec\par \par This RFC [RFC-2410] MUST be supported where IKE is necessary for the\par particular service provided, as described in the start of chapter 3,\par and MAY be supported otherwise.\par \par 3.12 RFC2411 - IP Security Document Roadmap\par \par This RFC [RFC-2411] is of informational nature only.\par \par 3.13 RFC2451 - The ESP CBC-Mode Cipher Algorithms\par \par This RFC [RFC-2451] MUST be supported if encryption algorithms other\par than DES are implemented, e.g.: CAST-128, RC5, IDEA, Blowfish, 3DES.\par \par 3.14 IP Security Remote Access\par \par The IETF IPSRA WG is working on solutions to provide remote access\par mechanisms on top of IPsec in situations where legacy RADIUS or\par other authentication is desired instead of PKI-based authentication.\par These solutions are currently under development, but SHOULD be\par supported by cellular hosts offering VPN services to corporate\par intranets.\par \par 3.15 The AES Cipher Algorithm and Its Use With IPsec\par \par This specification [AESIPSEC] MUST be supported. We suggest here\par that in a new environment such as the cellular IPv6 older and\par insecure algorithms such as DES should not be used, and that the\par most secure and lightweight new ones should be used instead. Due to\par better efficiency we suggest the use of AES instead of 3DES.\par \par \par 4 IP Mobility\par \par Mobile IPv6 manages IP mobility resulting from the change in CoA\par when a host moves within the Internet topology. This section will\par detail the level of support of MIPv6 required by cellular hosts and\par highlight the scenarios in which such support is needed.\par \par 4.1 Mobility Support in IPv6\par \par Mobile IPv6 is specified in [MIPv6].\par \par Mobile IP is required for hosts moving within the Internet topology.\par At the highest level, the Mobile IPv6 functionality within Mobile\par Nodes can be divided to the following parts:\par \par \par Manyfolks [Page 15] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par - Correspondent Node (CN) functionality, defined by Mobile IPv6\par specification [MIPv6], i.e. the basic functionality needed to\par correspond with mobile nodes.\par - Mobile Node (MN) functionality [MIPv6]. This includes the\par ability to configure Home and Care-of-Addresses (CoA) send\par Binding Updates (BUs) and receive Binding Acknowledgements and\par Requests. In addition, this function also includes the ability\par to maintain a Binding Update List.\par - Route optimization. The functionality needed to correspond with\par mobile nodes in an optimal manner.\par \par We will discuss the use of each part in turn.\par \par The basic functionality of a Correspondent Node, i.e. process the\par Home Address Option, MUST be supported by all hosts. (Note: at the\par time this Internet Draft has been written, the Home Address Option\par is defined only in the MIPv6 Internet Draft, not an RFC, and the\par security implications of the Home Address Option are being studied\par by the Mobile IP Working Group. The group is considering whether the\par option should continue to be understood by all nodes, or only those\par involved in Route Optimization functionality with a MN. Depending on\par the results of this discussion, we should either mandate the support\par of the option here for all cellular hosts, or only those capable of\par Route Optimization.)\par \par The mobile node functionality is needed when the host itself will\par move within the Internet topology i.e. changes it's care-of address.\par This function is needed in cellular systems where MIPv6 is used for\par intra-domain mobility. In other cellular systems where intra-domain\par mobility is handled by other means (e.g. GTP in a 3GPP system), only\par hosts with additional, non-cellular interfaces MUST have this\par functionality if they need to retain session or IP layer\par reachability while moving between different access technologies,\par i.e. - to use MIPv6 for inter-system IP handovers.\par \par For instance, when a hosts has both a Wireless LAN (WLAN) and an\par UMTS interface, MIPv6 MN functionality is needed to retain sessions\par when moving from UMTS area to a WLAN area. The UMTS network provides\par a basic mobility service (layer 2 mobility) to all hosts without\par requiring the implementation of IP layer mobility. Hosts that have\par interfaces only to networks providing such other mobility services,\par or hosts that do not require session mobility through interface\par handovers MAY have this functionality.\par \par \par The Route Optimized functionality for a CN, i.e. processing of\par Binding Updates, SHOULD be supported by all hosts when the\par communication benefits from this optimization.\par \par \par \par \par Manyfolks [Page 16] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par 4.2 Fast Handovers for Mobile IPv6\par \par Fast handovers for Mobile IPv6 is specified in [MIPv6-FH].\par \par This draft SHOULD be supported if Mobile IPv6 [MIPv6] is supported\par and when communication benefits from this optimization.\par \par 4.2.1 3GPP and Fast Handoffs\par \par Within the current 3GPP architecture, a cellular host will always\par keep the connection to the same GGSN (default router) for a context.\par Movement between default routers is not permitted. The only scenario\par where a MN would change default routers is in the case of a handover\par between two different access technologies. In this case the MN will\par be simultaneously connected to both routers which would eliminate\par the need for anticipation through the current router. Hence the Fast\par Handoffs draft will not be required within the current 3GPP\par architecture.\par \par 4.3 Hierarchical MIPv6 Mobility Management\par \par Hierarchical MIPv6 is specified in [HMIPv6].\par \par Hierarchy SHOULD be supported to run MIPv6 efficiently over the air.\par This aims at reducing the number of MIPv6 BUs sent over the air\par while moving within the topology.\par \par 4.3.1 HMIPv6 in 3GPP\par \par As mentioned above, Inter-GGSN handovers are not allowed within the\par current 3GPP architecture. Hence, the benefit of implementing HMIPv6\par in 3GPP will only appear during the inter-access technology\par handover, which may not be as common as intra-access technology\par ones. However the architecture can benefit from the per-flow\par movement explained in the draft which allows a MN to receive\par different traffic flows on different interfaces.\par \par 4.4 Mobile IP Security\par \par The security design for Mobile IP is currently being performed in\par the IETF. Before this work completes it will not be possible to\par state in detail the security requirements for cellular hosts using\par Mobile IP. However, we expect that security solutions will be\par provided both for the protection of binding updates to correspondent\par nodes, as well as secure tunneling support between the mobile node\par and its home.\par \par 5 Security Considerations\par \par This document does not specify any new protocols or functionality,\par and as such it does not introduce any new security vulnerabilities.\par \par Manyfolks [Page 17] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par However, specific profiles of IPv6 functionality are proposed for\par different situations, and vulnerabilities may open or close\par depending on which functionality is included and what is not. In the\par following, we discuss such situations:\par \par - The suggested limitations (Section 2.4) in the processing of\par routing headers limits also exposure to Denial-of-Service\par attacks through cellular hosts.\par \par - The incompatibility of the addressing privacy [RFC3041] and\par 3GPP address autoconfiguration model prevents the use of\par exactly the same kind of privacy functionality as provided in\par IPv6. However, it should be noted that in the 3GPP model the\par network will assign new addresses to hosts in roaming\par situations and typically also when the cellular terminals are\par turned on. This means that a limited form of addressing privacy\par will already be provided by 3GPP networks, and no global\par tracking of a single terminal is possible through its address.\par \par - The use of various security services such as IPsec or TLS in\par the connection of typical applications in cellular hosts is\par discussed in Chapter 3 and recommendations are given there.\par \par - Chapter 3 also discusses under what conditions it is possible\par to provide IPsec protection of e.g. ICMPv6 communications.\par Recommendations are given to support VPN-type tunneling to home\par networks, but to avoid the use of any security services in\par towards visited network nodes due to problems setting up\par sufficient PKI infrastructure for such usage.\par \par - Chapter 3 further discusses a specific profile of IPsec\par suitable for cellular implementations. Deviations from the\par standard RFCs are suggested mainly due to a desire to adopt the\par latest advances, such as the AES algorithm. On the other hand\par it is suggested to employ only the ESP protocol for reasons of\par reducing complexity. ESP provides a different protection than\par AH, which may have security implications.\par \par - As Chapter 4 mandates only the support of the Mobile IP Home\par Address option and not the full, optimized correspondent node\par behavior, the security problems related to Binding Updates are\par not relevant for nodes supporting only the Core IP features.\par \par - The air-time used by cellular hosts is expensive. In some cases\par users are billed according to the amount of data they transfer\par to and from their host. It is crucial for both the network and\par the users that the air-time is used correctly and no extra\par charges are applied to users due to misbehaving third parties.\par The wireless links also have a limited capacity, which means\par that they may not necessarily be able to accommodate more\par traffic than what the user selected, such as a multimedia call.\par \par Manyfolks [Page 18] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par Additional traffic might interfere with the service level\par experienced by the user. While QoS mechanisms mitigate these\par problems to an extent, it is still apparent that Denial-of-\par Service aspects may be highlighted in the cellular environment.\par It is possible for existing DoS attacks that use for instance\par packet amplification to be substantially more damaging in this\par environment. How these attacks can be protected against is\par still an area of further study. It is also often easy to fill\par the wireless link and queues on both sides with additional or\par large packets.\par \par - In certain areas of the world it is possible to buy a prepaid\par cellular subscription without presenting personal\par identification. This could be leveraged by attackers that wish\par to remain unidentified. We note that while the user hasn't been\par identified, the equipment still is; the operators can follow\par the identity of the device and block it from further use. The\par operators MUST have procedures in place to take notice of third\par party complaints regarding the use of their customers' devices.\par It MAY also be necessary for the operators to have attack\par detection tools that enable them to efficiently detect attacks\par launched from the cellular hosts.\par \par - Cellular devices that have local network interfaces (such as\par IrDA or Bluetooth) may be used to launch attacks through them,\par unless the local interfaces are secured in an appropriate\par manner. Therefore, we recommend that any local network\par interface SHOULD have access controls to prevent bypassers from\par using the cellular host as an intermediary.\par \par \par 6 References\par \par [3GPPADDR-R4] 3GPP 23.060, version 4.00, chapter 9.2.1.1\par \par [3GPP-IMS] 3rd Generation Partnership Project; Technical\par Specification Group Services and System Aspects; IP\par Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228\par version 5.0.0)\par \par [ADDRARCH] Hinden, R. and Deering, S., "IP Version 6 Addressing\par Architecture", RFC 2373, July 1998.\par \par [ADDRCONF] Thomson, S. and Narten, T., "IPv6 Stateless Address\par Autoconfiguration". RFC 2462.\par \par [AESIPSEC] Frankel, S., Kelly, S. and Glenn, R., "The Candidate\par AES Cipher Algorithms and Their Use With IPsec",\par draft-ietf-ipsec-ciph-aes-cbc-02.txt, October 2001,\par Work in progress\par \par \par Manyfolks [Page 19] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par [DEFADDR] Draves, R., "Default Address Selection for IPv6",\par draft-ietf-ipngwg-default-addr-select-06.txt,\par September 2001, Work in progress.\par \par [DHCPv6] Bound, J. et al., "Dynamic Host Configuration\par Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-\par 20.txt, October 2001 Work in progress.\par \par [HMIPv6] Soliman, H., Castelluccia, C., El-Malki, K. and\par Bellier, L., "Hierarchical MIPv6 mobility\par management", draft-ietf-mobileip-hmipv6-04.txt, July\par 2001, Work in progress\par \par \par [ICMPv6] Conta, A. and Deering, S., "ICMP for the Internet\par Protocol Version 6 (IPv6)", RFC 2463, December 1998.\par \par [IPv6] Deering, S. and Hinden, R., "Internet Protocol,\par Version 6 (IPv6) Specification", RFC 2460, December\par 1998.\par \par [IPv6PPP] Haskin, D. and Allen, E., "IP Version 6 over PPP",\par RFC 2472, December 1998\par \par [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate\par Requirement Levels", BCP 14, RFC 2119, March 1997.\par \par [MIPv6] Johnson D. and Perkins, C., "Mobility Support in\par IPv6", draft-ietf-mobileip-ipv6-14.txt, July 2001,\par Work in progress.\par \par [MIPv6-FH] Tsirtsis, G. et al., "Fast Handovers for Mobile\par IPv6", draft-ietf-mobileip-fast-mipv6-02.txt, July\par 2001, Work in progress.\par \par [MLD] Deering, S., Fenner, W. and Haberman, B., "Multicast\par Listener Discovery (MLD) for IPv6", RFC 2710, October\par 1999\par \par [PMTU] McCann, J., Mogul, J. and Deering, S., "Path MTU\par Discovery for IP version 6", RFC 1981, August 1996.\par \par [RFC-1034] Mockapetris, P., "Domain names - concepts and\par facilities", RFC 1034, November 1987\par \par [RFC-1035] Mockapetris, P., "Domain names - implementation and\par specification", STD 13, RFC 1035, November 1987.\par \par [RFC-1886] Thomson, S. and Huitema, C., "DNS Extensions to\par support IP version 6, RFC 1886, December 1995.\par \par \par Manyfolks [Page 20] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:\par Keyed-Hashing for Message Authentication", RFC 2104,\par February 1997.\par \par [RFC-2246] Dierks, T. and Allen, C., "The TLS Protocol Version\par 1.0", RFC 2246, January 1999\par \par [RFC-2374] Hinden, R., O'Dell, M. and Deering, S., "An IPv6\par Aggregatable Global Unicast Address Format", RFC\par 2374, July 1998.\par \par [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for\par the Internet Protocol", RFC 2401, November 1998.\par \par [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication\par Header", RFC 2402, November 1998.\par \par [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5\par within ESP and AH", RFC 2403, November 1998.\par \par [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1\par within ESP and AH", RFC 2404, November 1998.\par \par [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher\par Algorithm With Explicit IV", RFC 2405, November 1998.\par \par [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security\par Protocol (ESP)", RFC 2406, November 1998.\par \par [RFC-2407] Piper, D., "The Internet IP Security Domain of\par Interpretation for ISAKMP", RFC 2407, November 1998.\par \par [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and\par Turner, J., "Internet Security Association and Key\par Management Protocol (ISAKMP)", RFC 2408, November\par 1998.\par \par [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key\par Exchange (IKE)", RFC 2409, November 1998.\par \par [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption\par Algorithm and Its Use With IPsec", RFC 2410, November\par 1998\par \par [RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security\par Document Roadmap", RFC 2411, November 1998.\par \par [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher\par Algorithms", RFC 2451, November 1998\par \par \par \par Manyfolks [Page 21] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor\par Discovery for IP Version 6 (IPv6)", RFC 2461,\par December 1998.\par \par [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling\par in IPv6 Specification", RFC 2473, December 1998.\par \par [RFC-2529] Carpenter, B. and Jung, C., "Transmission of IPv6\par over IPv4 Domains without Explicit Tunnels?, RFC\par 2529, March 1999.\par \par [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert\par Option", RFC 2711, October 1999.\par \par [RFC-2874] Crawford, M. and Huitema, C., "DNS Extensions to\par Support IPv6 Address Aggregation and Renumbering",\par RFC 2874, July 2000.\par \par [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms\par for IPv6 Hosts and Routers", RFC 2893, August 2000.\par \par [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for\par Stateless Address Autoconfiguration in IPv6", RFC\par 3041, January 2001.\par \par [RFC-3056] Carpenter, B. and Moore, K., "Connection of Ipv6\par domains via IPv4 clouds", RFC 3056, February 2001.\par \par [TCPWIRELESS] Inamura, H. et al. ?TCP over 2.5G and 3G Networks?.\par IETF, draft-ietf-pilc-2.5g3g-04.txt, October, 2001,\par Work in progress.\par \par [TRANSMECH] Gilligan, R. and Nordmark, E., "Transition Mechanisms\par for IPv6 Hosts and Routers", RFC 2893, August 2000.\par \par 7 Acknowledgements\par \par The authors would like to thank David DeCamp, Markus Isom\'e4ki, Petter\par Johnsen, Janne Rinne, Jonne Soininen, Hesham Soliman and Shabnam\par Sultana for their comments and input.\par \par 8 Authors' Addresses\par \par Jari Arkko\par Ericsson\par 02420 Jorvas\par Finland\par \par Phone: +358 40 5079256\par Fax: +358 40 2993401\par E-Mail: Jari.Arkko@ericsson.com\par \par Manyfolks [Page 22] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par \par Peter Hedman\par Ericsson\par SE-221 83 LUND\par SWEDEN\par \par Phone: +46 46 231760\par Fax: +46 46 231650\par E-mail: peter.hedman@emp.ericsson.se\par \par Gerben Kuijpers\par Ericsson\par Skanderborgvej 232\par DK-8260 Viby J\par DENMARK\par \par Phone: +45 89385100\par Fax: +45 89385101\par E-mail: gerben.a.kuijpers@ted.ericsson.dk\par \par John Loughney\par Nokia Research Center\par It\'e4merenkatu 11 - 13\par FIN-00180 HELSINKI\par FINLAND\par \par Phone: +358 7180 36242\par Fax: +358 7180 36851\par E-mail: john.loughney@nokia.com\par \par Pertti Suomela\par Nokia Mobile Phones\par Sinitaival 5\par FIN-33720 TAMPERE\par Finland\par \par Phone: +358 7180 40546\par Fax: +358 7180 48215\par E-mail: pertti.suomela@nokia.com\par \par Juha Wiljakka\par Nokia Mobile Phones\par Sinitaival 5\par FIN-33720 TAMPERE\par Finland\par \par Phone: +358 7180 47562\par Fax: +358 7180 48215\par E-mail: juha.wiljakka@nokia.com\par \par \par \par Manyfolks [Page 23] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par Appendix A Revision History\par \par Changes from draft-manyfolks-ipv6-cellular-host-01.txt:\par \par - Minor editorial changes.\par - Section 3 - Security: Removed SSL from recommended security\par protocols.\par - Section 3.10 - Internet Key Exchange: Added recommendation on\par interaction between ICMPv6 and IPsec Policy.\par - Section 4.1 - Mobility support in IPv6: added a discussion on\par whether or not the cellular host should support the Home\par Address Option.\par \par \par \par Appendix B Cellular Host IPv6 Addressing in the 3GPP Model\par \par The appendix aims to describe 3GPP (Third Generation Partnership\par Project) IPv6 addressing model for 2G (GPRS) and 3G (UMTS) cellular\par networks [3GPPADDR-R4].\par \par There are two possibilities to allocate an address for an IPv6 node\par - stateless and stateful autoconfiguration. The stateful address\par allocation mechanism needs a DHCP server to allocate the address for\par the IPv6 node. In the stateless autoconfiguration, the IPv6 node is\par more involved in the allocation and the stateless autoconfiguration\par procedure does not need any external entity involved in the address\par autoconfiguration.\par \par The two important network elements in the 3GPP packet based\par architecture are SGSN (Serving GPRS Support node) and GGSN (Gateway\par GPRS Support Node). GGSN is the nearest router for the mobile\par terminal / cellular host and it is responsible for giving an IP\par address to the mobile terminal. The logical link established\par between the GGSN Access Point and the mobile terminal is called PDP\par (Packet Data Protocol) context.\par \par To support dynamic IPv6 address allocation by the PLMN (Public Land\par Mobile Network) operator, the GGSN provides a unique interface\par identifier (see RFC 2462) to the mobile terminal. This enables the\par cellular host to perform the IPv6 stateless autoconfiguration\par procedures to generate its full IPv6 address.\par \par In the first phase the mobile terminal sends an Activate PDP Context\par Request message to the SGSN. The mobile terminal shall leave PDP\par Address empty and set PDP Type to IPv6. The GGSN shall create the\par unique link-local address for the mobile terminal and send it in the\par PDP Address information element in the Create PDP Context Response\par message. The link local address consists of a fixed 10-bit prefix\par (IPv6 link-local prefix), zero or more 0 bits, and the interface\par identifier.\par \par Manyfolks [Page 24] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par \par After that the mobile terminal may send a Router Solicitation\par message to the GGSN to activate the sending of the Router\par Advertisement message.\par \par The GGSN should automatically send the Router Advertisement message\par after the PDP context is activated. In 3GPP Release 99 the GGSN\par shall be configured to advertise only one network prefix per APN\par (Access Point Name).\par \par After the mobile terminal has received the Router Advertisement\par message, it constructs its full IPv6 address by concatenating the\par interface identifier contained in the link-local address provided in\par the Create PDP Context Response Message and the network prefix of\par the selected APN received in the Router Advertisement. Subsequently,\par the mobile terminal is ready to start communicating to the Internet.\par \par Because the GGSN provides a unique interface identifier during the\par PDP context activation procedure, there is no need for the mobile\par terminal to perform Duplicate Address Detection for this IPv6\par address. Therefore, the GGSN shall intercept and discard Neighbor\par Solicitation messages that the mobile terminal may send to perform\par Duplicate Address Detection. It is possible for the mobile terminal\par to perform Neighbor Unreachability Detection, as defined in RFC\par 2461; therefore if the GGSN receives a Neighbor Solicitation as part\par of this procedure, the GGSN shall provide a Neighbor Advertisement\par as described in RFC 2461.\par \par Finally, the GGSN updates the PDP context in the SGSN and mobile\par terminal with the full IPv6 address (so-called GGSN-Initiated PDP\par Context Modification Procedure).\par \par Appendix C Transition Issues\par \par IETF has specified a number of IPv4 / IPv6 transition mechanisms\par [RFC-2893] to ensure smooth transition from IPv4 to IPv6 and\par interoperability between IPv4 and IPv6 during the transition period.\par The three main transition methods from a cellular network point of\par view are dual IPv4 / IPv6 stacks, tunneling and protocol\par translators, such as NAT-PT or SIIT.\par \par It is recommended that cellular hosts have dual IPv4 / IPv6 stacks\par to be able to interoperate with both IPv4 and IPv6 domains and use\par both IPv6 and IPv4 applications / services. It is recommended that\par the majority of the transition mechanisms are provided by the\par network in order to save the limited resources of the cellular host.\par Tunneling (for example RFC 3056 - Connection of IPv6 Domains via\par IPv4 Clouds) should be carried out in the network. Also any\par protocol translation function, such as NAT-PT, should be implemented\par in the network, not in the cellular host. The tunneling mechanism\par specified by [RFC-2529] is not relevant for a cellular host. [RFC-\par \par Manyfolks [Page 25] \par \page\par Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001\par \par \par 2529] allows isolated IPv6-only hosts to connect to an IPv6 router\par via an IPv4 domain. The scenario of an IPv6-only host in an IPv4-\par only cellular network is considered unlikely.\par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par \par Manyfolks [Page 26]\par }