INTERNET-DRAFT Jari Arkko Internet Engineering Task Force Peter Hedman Gerben Kuijpers Ericsson John Loughney Pertti Suomela Juha Wiljakka Nokia Issued: November 20, 2001 Expires: May 20, 2002 Minimum IPv6 Functionality for a Cellular Host 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 November 20, 2001 Abstract............................................................1 1 Introduction......................................................3 1.1 Abbreviations..................................................5 1.2 Requirement Language...........................................5 1.3 Cellular Host IPv6 Features....................................5 2 Core IP...........................................................6 2.1 RFC1981 - Path MTU Discovery for IP Version 6..................6 2.2 RFC2373 - IP Version 6 Addressing Architecture.................6 2.3 RFC2374 - IPv6 Aggregatable Global Unicast Address Format......6 2.4 RFC2460 - Internet Protocol Version 6..........................7 2.5 RFC2461 - Neighbor Discovery for IPv6..........................7 2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration.............8 2.7 RFC2463 - Internet Control Message Protocol for the IPv6.......8 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.........9 2.14 RFC3056 - Connection of IPv6 Domains Via IPv4 Clouds.........10 2.15 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)........10 2.16 Default Address Selection for IPv6...........................10 2.17 DNS..........................................................10 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...13 3.7 RFC2406 - IP Encapsulating Security Payload (ESP).............13 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP.............13 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 & its Use With IPsec.15 3.12 RFC2411 - IP Security Document Roadmap.......................15 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 4 IP Mobility......................................................15 4.1 Mobility Support in IPv6......................................15 4.2 Fast Handovers for Mobile IPv6................................17 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 Appendix A Revision History........................................24 Manyfolks [Page 2] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 Appendix B Cellular Host IPv6 Addressing in the 3GPP Model.........24 Appendix C Transition Issues.......................................25 1 Introduction Technologies such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), and CDMA2000 are making it possible for cellular hosts to have an always-on connection to the Internet. IPv6 becomes necessary, as it is expected that the number of such cellular hosts will increase rapidly. Standardization organizations working with cellular technologies have recognized this, and are making IPv6 mandatory in their newest specifications. One example of this is that 3GPP 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 implementers who need guidance on what to implement. The IETF that wants to ensure a well- working global IPv6 network, and other standardization organizations that need a reference to how IPv6 can be mandated on their standards. For the purposes of this document, a cellular host is considered to be a terminal which uses an air interface to connect to a cellular access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6 connectivity to an IP network. The functionality to provide this connectivity is outlined in this draft. The description is made from a general cellular host point of view, and this document is intended to be applicable for many types of cellular network standards (or even multi-standard devices). The implementation of parts of the IPv6 specification in specific cellular networks (such as the UMTS) may differ from the general recommendation. Where this applies, additional information is given on how to make that part of IPv6 work in that specific cellular network. This information can also be used to provide standardization bodies insight in which issues it may be necessary to revise in future releases of the particular cellular network specifications. Manyfolks [Page 3] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 Parts of this document may also be applicable in other, non-cellular contexts, such as small IPv6 appliances with similar size and cost restrictions. The scope of this document, however, is the cellular hosts and it may not cover all issues relevant in those other contexts. The use of IPv6 within cellular networks implies an implementation of the IPv6 stack within a wide range of terminals. Such terminals may vary significantly in terms of capacity, task orientation and processing power. For instance, the smallest handheld terminals can have a very limited amount of memory, computational power, and battery capacity. Cellular hosts operate over low bandwidth wireless links with limited throughput. As such, there are certain optimizations that would be required for these hosts in order to fit the largest possible amount of terminals within an area of spectrum. Tough demands are set for interoperability of cellular hosts towards other hosts, the cellular network, and the Internet. It is often hard or impossible to upgrade a large number of cellular hosts to a new software version. The long lifetime of the terminals sets a requirement for old equipment to still work in newer versions of the network and other hosts. The concept of IPv6 covers many aspects, numerous RFCs, a number of different situations, and is also partly still in evolution. For these reasons it is necessary to understand how the IPv6 deployment starts and which parts of IPv6 are necessary under which situations. This document reviews the IPv6 functionality, grouped under three categories: core IP, security, and mobility. For each category and each RFC in them, we discuss the following: - Is this part of functionality needed by cellular hosts and under which conditions? - In some cases individual parts of the RFCs are discussed in more detail and recommendations are given regarding their support. - In some other cases conflicts between some parts of functionality and the current cellular network protocols are identified. The aim of this work is to introduce a minimal set of IPv6 functionality - subject to the particular type of terminal and application - that would be required for cellular IPv6 hosts. As a general guideline, a cellular host should not appear any different from other IPv6 hosts. The set of requirements proposed should be suited to terminals with minimal capabilities, low cost and processing power. Interoperability can be achieved by listing needed IPv6 related IETF specifications according to chapter 1.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 Manyfolks [Page 4] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 header compression work done in the IETF ROHC group, or the TCP work in [TCPWIRELESS]. The history of IPv6 in 3GPP specifications is briefly described in this paragraph. IPv6 was introduced as an option starting in 3GPP Release 97 (that was originally an ETSI release) GSM / GPRS specifications. A wider support for IPv6 (and the introduction of UMTS) shall start with 3GPP Release 99 networks and terminals. IPv6 is specified as the only IP version supported in Release 5 for IP Multimedia Subsystem (IMS). The authors used 3GPP Release 99 and Release 4 specifications as defined when this document was written as a base. Any possible changes to current IPv6 specifications shall be accommodated as they occur. The authors of this document seek feedback to ensure that the proposed functionality set is consistent, interoperable with the rest of the IPv6 Internet, complete, and does not open new security risks. 1.1 Abbreviations 3GPP Third Generation Partnership Project AH Authentication Header CDMA2000 Code Division Multiple Access 2000, the name identifying the third generation technology of IS-95 CDMA standard and ANSI-41 network. ESP Encapsulating Security Payload ETSI European Telecommunications Standards Institute IMS IP Multimedia Subsystem GGSN Gateway GPRS Support Node GPRS General Packet Radio Service GSM Global System for Mobile Communications 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. Manyfolks [Page 5] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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 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. Manyfolks [Page 6] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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 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 Manyfolks [Page 7] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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 B for more details. Neighbor Solicitations 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 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 B 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. Manyfolks [Page 8] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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 Transition mechanisms [TRANSMECH] MAY be supported. See Appendix C 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 Neighbor 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 B for more details on 3GPP IPv6 address assignment and Chapter 5 for the security implications of this. Manyfolks [Page 9] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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. 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 that support DNS. 2.17.4 RFC2874 - DNS Extensions to Support IPv6 Address Aggregation and Renumbering Manyfolks [Page 10] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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 - 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. However, for each service as outlined below the requirements are applicable for either the given mechanisms or their possible future wireless profiles. 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 MAY provide 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 Manyfolks [Page 11] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 security. The fact that just TLS should be the protocol to provide web security relates to current deployment and the suitability of the single-side certificate trust model for this application. Beside web browsing services, other services that require client (or user) authentication may also use the TLS security mechanism. 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 a SA with the next hop router for the purposes of securing the router and neighbor discovery tasks would mean the following. First, both the routers and all cellular hosts would have to be registered to a PKI system. Second, a common root CA would have to be found that encompasses both the visiting cellular host of an operator as well as the infrastructure of another operator. It is not clear if this is possible with today's technology. Furthermore, as [ICMPIKEv6] points out, dynamic SA negotiation can't be used for the protection of the first few connectivity establishment messages in ICMPv6. It may be possible to overcome these problems, however, the added security benefits of the protection in these cases would be minimal: encrypted radio communications exist at a lower layer, and the next hop router can always engage in any denial-of-service attacks (such as dropping all packets) regardless of the existence of any SAs. For these reasons, the 3GPP terminals will not be mandated to support any security for the pure IPv6 router and infrastructure protection purposes. The following subchapters are only applicable for those services where IPsec/IKE is recommended above. The below chapters essentially define a wireless profile for IPsec/IKE. (Note that future versions of this Internet Draft may separate this profiling to an independent draft as is done in the case of TLS.) Manyfolks [Page 12] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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. 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], is not a mandatory part of the IP Security Architecture. Note, however, that in the cellular Manyfolks [Page 13] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 environment the IP addresses of a host may change dynamically. For this reason the use of manually configured Security Associations is not practical, as the newest host address would have to be updated to the SA database of the peer as well. 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 are 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. Interactions with the ICMPv6 packets and IPsec policies may cause unexpected behavior for IKE-based SA negotiation unless some special handling is performed in the implementations. The ICMPv6 protocol provides many functions, which in IPv4 were either non-existent or provided by lower layers. For instance, IPv6 implements address resolution using an IP packet, ICMPv6 Neighbor Solicitation message. In contrast, IPv4 uses an ARP message at a lower layer. The IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is not easy. For instance, a simple policy of protecting all traffic between two hosts on the same network would trap even address resolution messages, leading to a situation where IKE can't establish a Security Association since in order to send the IKE UDP packets one would have had to send the Neighbor Solicitation Message, which would have required an SA. In order to avoid this problem, this specification recommends that Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages MUST NOT lead to the use of IKE-based SA negotiation. The Redirect message SHOULD NOT lead to the use of IKE-based SA negotiation. Other ICMPv6 messages Manyfolks [Page 14] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 MAY use IKE-based SA negotiation as is desired in the Security Policy Data Base. 3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec This RFC [RFC-2410] MUST be supported 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. 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. 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: Manyfolks [Page 15] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 - Correspondent Node (CN) functionality, defined by Mobile IPv6 specification [MIPv6], i.e. the basic functionality needed to correspond with mobile nodes. - Mobile Node (MN) functionality [MIPv6]. This includes the ability to configure Home and Care-of-Addresses (CoA) send Binding Updates (BUs) and receive Binding Acknowledgements and Requests. In addition, this function also includes the ability to maintain a Binding Update List. - Route optimization. The functionality needed to correspond with mobile nodes in an optimal manner. We will discuss the use of each part in turn. The basic functionality of a Correspondent Node, i.e. process the Home Address Option, MUST be supported by all hosts. (Note: at the time this Internet Draft has been written, the Home Address Option is defined only in the MIPv6 Internet Draft, not an RFC, and the security implications of the Home Address Option are being studied by the Mobile IP Working Group. The group is considering whether the option should continue to be understood by all nodes, or only those involved in Route Optimization functionality with a MN. Depending on the results of this discussion, we should either mandate the support of the option here for all cellular hosts, or only those capable of Route Optimization.) 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 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. Manyfolks [Page 16] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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. 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 at reducing 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. Manyfolks [Page 17] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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. - The use of various security services such as IPsec or TLS in the connection of typical applications in cellular hosts is discussed in Chapter 3 and recommendations are given there. - Chapter 3 also discusses under what conditions it is possible to provide IPsec protection of e.g. ICMPv6 communications. Recommendations are given to support VPN-type tunneling to home networks, but to avoid the use of any security services in towards visited network nodes 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. Manyfolks [Page 18] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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. 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-R4] 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-02.txt, October 2001, Work in progress Manyfolks [Page 19] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 [DEFADDR] Draves, R., "Default Address Selection for IPv6", draft-ietf-ipngwg-default-addr-select-06.txt, September 2001, Work in progress. [DHCPv6] Bound, J. et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6- 20.txt, October 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 [ICMPv6] Conta, A. and Deering, S., "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998. [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. Manyfolks [Page 20] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 [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. [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 Manyfolks [Page 21] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 [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. [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-04.txt, October, 2001, 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 Isom„ki, Petter Johnsen, Janne Rinne, Jonne Soininen, Hesham Soliman and Shabnam Sultana for their comments and input. 8 Authors' Addresses Jari Arkko Ericsson 02420 Jorvas Finland Phone: +358 40 5079256 Fax: +358 40 2993401 E-Mail: Jari.Arkko@ericsson.com Manyfolks [Page 22] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 Peter Hedman Ericsson SE-221 83 LUND SWEDEN Phone: +46 46 231760 Fax: +46 46 231650 E-mail: peter.hedman@emp.ericsson.se Gerben Kuijpers Ericsson Skanderborgvej 232 DK-8260 Viby J DENMARK Phone: +45 89385100 Fax: +45 89385101 E-mail: gerben.a.kuijpers@ted.ericsson.dk John Loughney Nokia Research Center It„merenkatu 11 - 13 FIN-00180 HELSINKI FINLAND Phone: +358 7180 36242 Fax: +358 7180 36851 E-mail: john.loughney@nokia.com Pertti Suomela Nokia Mobile Phones 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 Manyfolks [Page 23] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 Appendix A Revision History Changes from draft-manyfolks-ipv6-cellular-host-01.txt: - Minor editorial changes. - Section 3 - Security: Removed SSL from recommended security protocols. - Section 3.10 - Internet Key Exchange: Added recommendation on interaction between ICMPv6 and IPsec Policy. - Section 4.1 - Mobility support in IPv6: added a discussion on whether or not the cellular host should support the Home Address Option. Appendix B 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-R4]. 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 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. Manyfolks [Page 24] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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). Appendix C Transition Issues IETF has specified a number of IPv4 / IPv6 transition mechanisms [RFC-2893] to ensure smooth transition from IPv4 to IPv6 and interoperability between IPv4 and IPv6 during the transition period. The three main transition methods from a cellular network point of view are dual IPv4 / IPv6 stacks, tunneling and protocol translators, such as NAT-PT or SIIT. It is recommended that cellular hosts have dual IPv4 / IPv6 stacks to be able to interoperate with both IPv4 and IPv6 domains and use both IPv6 and IPv4 applications / services. It is recommended that the 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- Manyfolks [Page 25] Internet Draft Min. IPv6 Func. for a Cellular Host November 20, 2001 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 26]