diff options
Diffstat (limited to 'doc/rfc/rfc3316.txt')
| -rw-r--r-- | doc/rfc/rfc3316.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc3316.txt b/doc/rfc/rfc3316.txt new file mode 100644 index 0000000..7b2e790 --- /dev/null +++ b/doc/rfc/rfc3316.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group J. Arkko +Request for Comments: 3316 G. Kuijpers +Category: Informational H. Soliman + Ericsson + J. Loughney + J. Wiljakka + Nokia + April 2003 + + + Internet Protocol Version 6 (IPv6) + for Some Second and Third Generation Cellular Hosts + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + As the deployment of second and third generation cellular networks + progresses, a large number of cellular hosts are being connected to + the Internet. Standardization organizations are making Internet + Protocol version 6 (IPv6) mandatory in their specifications. + However, the concept of IPv6 covers many aspects and numerous + specifications. In addition, the characteristics of cellular links + in terms of bandwidth, cost and delay put special requirements on how + IPv6 is used. This document considers IPv6 for cellular hosts that + attach to the General Packet Radio Service (GPRS), or Universal + Mobile Telecommunications System (UMTS) networks. This document also + lists basic components of IPv6 functionality and discusses some + issues relating to the use of these components when operating in + these networks. + + + + + + + + + + + + + +Arkko, et al. Informational [Page 1] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +Table of Contents + + 1. Introduction.....................................................3 + 1.1 Scope of this Document......................................3 + 1.2 Abbreviations...............................................4 + 1.3 Cellular Host IPv6 Features.................................5 + 2. Basic IP.........................................................5 + 2.1 RFC1981 - Path MTU Discovery for IP Version 6...............5 + 2.2 RFC3513 - IP Version 6 Addressing Architecture..............6 + 2.3 RFC2460 - Internet Protocol Version 6.......................6 + 2.4 RFC2461 - Neighbor Discovery for IPv6.......................7 + 2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration..........8 + 2.6 RFC2463 - Internet Control Message Protocol for the IPv6....8 + 2.7 RFC2472 - IP version 6 over PPP.............................9 + 2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification....9 + 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6.......9 + 2.10 RFC2711 - IPv6 Router Alert Option.........................10 + 2.11 RFC3041 - Privacy Extensions for Address Configuration + in IPv6 .........................................10 + 2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)......10 + 2.13 RFC3484 - Default Address Selection for IPv6...............11 + 2.14 DNS........................................................11 + 3. IP Security.....................................................11 + 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication...12 + 3.2 RFC2401 - Security Architecture for the Internet Protocol..12 + 3.3 RFC2402 - IP Authentication Header.........................12 + 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.........12 + 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.........12 + 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With + Explicit IV......................................12 + 3.7 RFC2406 - IP Encapsulating Security Payload (ESP)..........12 + 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP..........12 + 3.9 RFC2408 - The Internet Security Association and Key + Management Protocol..............................13 + 3.10 RFC2409 - The Internet Key Exchange (IKE)..................13 + 3.11 RFC2410 - The NULL Encryption Algorithm & its Use + With IPsec.......................................14 + 3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms...............14 + 4. Mobility........................................................14 + 5. Security Considerations.........................................14 + 6. References......................................................16 + 6.1 Normative..................................................16 + 6.2 Informative................................................18 + 7. Contributors....................................................19 + 8. Acknowledgements................................................19 + Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model.......20 + Authors' Addresses.................................................21 + Full Copyright Statement...........................................22 + + + +Arkko, et al. Informational [Page 2] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + +1 Introduction + + Technologies such as GPRS (General Packet Radio Service), UMTS + (Universal Mobile Telecommunications System) and CDMA2000 (Code + Division Multiple Access 2000) 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 specifications. + + Support for IPv6 and the introduction of UMTS starts with 3GPP + Release 99 networks and hosts. IPv6 is specified as the only IP + version supported for IP Multimedia Subsystem (IMS) starting from + Release 5. + +1.1 Scope of this Document + + For the purposes of this document, a cellular interface is considered + to be the interface to a cellular access network based on the + following standards: 3GPP GPRS and UMTS Release 99, Release 4, + Release 5, as well as future UMTS releases. A cellular host is + considered to be a host with such a cellular interface. + + This document lists IPv6 specifications with discussion on the use of + these specifications when operating over cellular interfaces. Such a + specification is necessary in order for the optimal use of IPv6 in a + cellular environment. The description is made from a cellular host + point of view. Important considerations are given in order to + eliminate unnecessary user confusion over configuration options, + ensure interoperability and to provide an easy reference for those + implementing IPv6 in a cellular host. It is necessary to ensure that + cellular hosts are good citizens of the Internet. + + This document is informational in nature, and it is not intended to + replace, update, or contradict any IPv6 standards documents [RFC- + 2026]. + + The main audience of this document are: the implementers of cellular + hosts that will be used with GPRS, 3GPP UMTS Release 99, Release 4, + Release 5, or future releases of UMTS. The document provides + guidance on which parts of IPv6 to implement in such cellular hosts. + Parts of this document may also apply to other cellular link types, + but no such detailed analysis has been done yet and is a topic of + future work. This document should not be used as a definitive list + + + + + +Arkko, et al. Informational [Page 3] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + of IPv6 functionality for cellular links other than those listed + above. Future changes in 3GPP networks that require changes in host + implementations may result in updates to this document. + + There are different ways to implement cellular hosts: + + - The host can be a "closed 2G or 3G host" with a very compact size + and optimized applications, with no possibility to add or download + applications that can have IP communications. An example of such a + host is a very simple form of a mobile phone. + + - The host can be an "open 2G or 3G host" with a compact size, but + where it is possible to download applications; such as a PDA-type + of phone. + + If a cellular host has additional interfaces on which IP is used, + (such as Ethernet, WLAN, Bluetooth, etc.) then there may be + additional requirements for the device, beyond what is discussed in + this document. Additionally, this document does not make any + recommendations on the functionality required on laptop computers + having a cellular interface such as a PC card, other than + recommending link specific behavior on the cellular link. + + This document discusses IPv6 functionality as specified when this + document has been written. Ongoing work on IPv6 may affect what is + needed from future hosts. The reader should also be advised other + relevant work exists for various other layers. Examples of this + include the header compression work done in the IETF ROHC group, the + analysis of the effects of error-prone links to performance in [RFC- + 3155], or the TCP work in [RFC-3481]. + + Transition mechanisms used by cellular hosts are not described in + this document and are left for further study. + +1.2 Abbreviations + + 2G Second Generation Mobile Telecommunications, such as GSM and + GPRS technologies. + 3G Third Generation Mobile Telecommunications, such as UMTS + technology. + 3GPP 3rd Generation Partnership Project. Throughout the document, + the term 3GPP (3rd Generation Partnership Project) networks + refers to architectures standardized by 3GPP, in Second and + Third Generation releases: 99, 4, and 5, as well as future + releases. + AH Authentication Header + APN Access Point Name. The APN is a logical name referring to a + GGSN and an external network. + + + +Arkko, et al. Informational [Page 4] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + ESP Encapsulating Security Payload + ETSI European Telecommunications Standards Institute + IMS IP Multimedia Subsystem + GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 + cellular hosts) + GPRS General Packet Radio Service + GSM Global System for Mobile Communications + IKE Internet Key Exchange + ISAKMP Internet Security Association and Key Management Protocol + MT Mobile Terminal, for example, a mobile phone handset. + MTU Maximum Transmission Unit + PDP Packet Data Protocol + SGSN Serving GPRS Support Node + TE Terminal Equipment, for example, a laptop attached through a + 3GPP handset. + UMTS Universal Mobile Telecommunications System + WLAN Wireless Local Area Network + +1.3 Cellular Host IPv6 Features + + This specification defines IPv6 features for cellular hosts in three + groups. + + Basic IP + + In this group, basic parts of IPv6 are described. + + IP Security + + In this group, the IP Security parts are described. + + Mobility + + In this group, IP layer mobility issues are described. + +2 Basic IP + +2.1 RFC1981 - Path MTU Discovery for IP Version 6 + + Path MTU Discovery [RFC-1981] may be used. Cellular hosts with a + link MTU larger than the minimum IPv6 link MTU (1280 octets) can use + Path MTU Discovery in order to discover the real path MTU. The + relative overhead of IPv6 headers is minimized through the use of + longer packets, thus making better use of the available bandwidth. + + + + + + + +Arkko, et al. Informational [Page 5] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + The IPv6 specification [RFC-2460] states in Section 5 that "a minimal + IPv6 implementation (e.g., in a boot ROM) may simply restrict itself + to sending packets no larger than 1280 octets, and omit + implementation of Path MTU Discovery." + + If Path MTU Discovery is not implemented then the sending packet size + is limited to 1280 octets (standard limit in [RFC-2460]). However, + if this is done, the cellular host must be able to receive packets + with size up to the link MTU before reassembly. This is because the + node at the other side of the link has no way of knowing less than + the MTU is accepted. + +2.2 RFC3513 - IP Version 6 Addressing Architecture + + The IPv6 Addressing Architecture [RFC-3513] is a mandatory part of + IPv6. + +2.3 RFC2460 - Internet Protocol Version 6 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification is a mandatory part of IPv6. + + By definition, a cellular host acts as a host, not as a router. + Implementation requirements for a cellular router are not defined in + this document. + + Consequently, the cellular host must implement all non-router packet + receive processing as described in RFC 2460. This includes the + generation of ICMPv6 error reports, and the processing of at least + the following extension headers: + + - Hop-by-Hop Options header: at least the Pad1 and PadN options + + - Destination Options header: at least the Pad1 and PadN options + + - Routing (Type 0) header: final destination (host) processing only + + - Fragment header + + - AH and ESP headers (see also a discussion on the use of IPsec for + various purposes in Section 3) + + - The No Next Header value + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions must be processed as described in RFC 2460. + + + + + +Arkko, et al. Informational [Page 6] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + The cellular host must follow the packet transmission rules in RFC + 2460. + + The cellular host must always be able to receive and reassemble + fragment headers. It will also need to be able to send a fragment + header in cases where it communicates with an IPv4 host through a + translator (see Section 5 of RFC2460). + + Cellular hosts should only process routing headers when they are the + final destination and return errors if the processing of the routing + header requires them to forward the packet to another node. This + will also ensure that the cellular hosts will not be inappropriately + used as relays or components in Denial-of-Service (DoS) attacks. + Acting as the destination involves the following: the cellular hosts + must check the Segments Left field in the header, and proceed if it + is zero or one and the next address is one of the host's addresses. + If not, however, the host must implement error checks as specified in + Section 4.4 of RFC 2460. There is no need for the host to send + Routing Headers. + +2.4 RFC2461 - Neighbor Discovery for IPv6 + + Neighbor Discovery is described in [RFC-2461]. This specification is + a mandatory part of IPv6. + +2.4.1 Neighbor Discovery in 3GPP Networks + + A cellular host must support Neighbor Solicitation and Advertisement + messages. + + In GPRS and UMTS networks, some Neighbor Discovery messages can be + unnecessary in certain cases. GPRS and UMTS links resemble a point- + to-point link; hence, the cellular host's only neighbor on the + cellular link is the default router that is already known through + Router Discovery. There are no link layer addresses. Therefore, + address resolution and next-hop determination are not needed. + + The cellular host must support neighbor unreachability detection as + specified in [RFC-2461]. + + In GPRS and UMTS networks, it is very desirable to conserve + bandwidth. Therefore, the cellular host should include a mechanism + in upper layer protocols to provide reachability confirmation when + two-way IP layer reachability can be confirmed (see RFC-2461, Section + 7.3.1). These confirmations will allow the suppression of most NUD- + related messages in most cases. + + + + + +Arkko, et al. Informational [Page 7] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + Host TCP implementation should provide reachability confirmation in + the manner explained in RFC 2461, Section 7.3.1. + + The common use of UDP in 3GPP networks poses a problem for providing + reachability confirmation. UDP itself is unable to provide such + confirmation. Applications running over UDP should provide the + confirmation where possible. In particular, when UDP is used for + transporting RTP, the RTCP protocol feedback should be used as a + basis for the reachability confirmation. If an RTCP packet is + received with a reception report block indicating some packets have + gone through, then packets are reaching the peer. If they have + reached the peer, they have also reached the neighbor. + + When UDP is used for transporting SIP, responses to SIP requests + should be used as the confirmation that packets sent to the peer are + reaching it. When the cellular host is acting as the server side SIP + node, no such confirmation is generally available. However, a host + may interpret the receipt of a SIP ACK request as confirmation that + the previously sent response to a SIP INVITE request has reached the + peer. + +2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification is a mandatory part of IPv6. + +2.5.1 Stateless Address Autoconfiguration in 3GPP Networks + + A cellular host in a 3GPP network must process a Router Advertisement + as stated in Section 2.4. + + Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, + as each delegated prefix is unique within its scope when allocated + using the 3GPP IPv6 Stateless Address Autoconfiguration. In + addition, the default router (GGSN) will not configure or assign to + its interfaces, any addresses based on prefixes delegated to IPv6 + hosts. Thus, the host is not required to perform Duplicate Address + Detection on the cellular interface. + + See Appendix A for more details on 3GPP IPv6 Stateless Address + Autoconfiguration. + +2.6 RFC2463 - Internet Control Message Protocol for the IPv6 + + The Internet Control Message Protocol for the IPv6 is defined [RFC- + 2463]. This specification is a mandatory part of IPv6. Currently, + this work is being updated. + + + + +Arkko, et al. Informational [Page 8] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + As per RFC 2463 Section 2, ICMPv6 requirements must be fully + implemented by every IPv6 node. See also Section 3 for an + explanation of the use of IPsec for protecting ICMPv6 communications. + +2.7 RFC2472 - IP version 6 over PPP + + IPv6 over PPP [RFC-2472] must be supported for cellular hosts that + implement PPP. + +2.7.1 IP version 6 over PPP in 3GPP Networks + + A cellular host in a 3GPP network must support the IPv6CP interface + identifier option. This option is needed to be able to connect other + devices to the Internet using a PPP link between the cellular device + (MT) and other devices (TE, e.g., a laptop). The MT performs the PDP + Context activation based on a request from the TE. This results in + an interface identifier being suggested by the MT to the TE, using + the IPv6CP option. To avoid any duplication in link-local addresses + between the TE and the GGSN, the MT must always reject other + suggested interface identifiers by the TE. This results in the TE + always using the interface identifier suggested by the GGSN for its + link-local address. + + The rejection of interface identifiers suggested by the TE is only + done for creation of link-local addresses, according to 3GPP + specifications. The use of privacy addresses [RFC-3041] for site- + local and global addresses is not affected by the above procedure. + The above procedure is only concerned with assigning the interface + identifier used for forming link-local addresses, and does not + preclude TE from using other interface identifiers for addresses with + larger scopes (i.e., site-local and global). + +2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification + + Generic Packet Tunneling [RFC-2473] may be supported if needed for + transition mechanisms. + +2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 + + Multicast Listener Discovery [RFC-2710] must be supported by cellular + hosts. + + MLD requires that MLD messages be sent for link-local multicast + addresses (excluding the all-nodes address). The requirement that + MLD be run even for link-local addresses aids layer-two devices + (e.g., Ethernet bridges) that attempt to suppress the forwarding of + link-layer multicast packets to portions of the layer-two network + where there are no listeners. If MLD is used to announce the + + + +Arkko, et al. Informational [Page 9] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + presence of listeners for all IP multicast addresses (including + link-local multicast addresses), layer 2 devices can snoop MLD + messages to reliably determine which portions of a network IP + multicast messages need to be forwarded to. + +2.9.1 MLD in 3GPP Networks + + Within 3GPP networks, hosts connect to their default routers (GGSN) + via point-to-point links. Moreover, there are exactly two IP devices + connected to the point-to-point link, and no attempt is made (at the + link-layer) to suppress the forwarding of multicast traffic. + Consequently, sending MLD reports for link-local addresses in a 3GPP + environment may not always be necessary. + + MLD is needed for multicast group knowledge that is not link-local. + +2.10 RFC2711 - IPv6 Router Alert Option + + The Router Alert Option [RFC-2711] must be supported, and its use is + required when MLD is used (see Section 2.9) or when RSVP [RFC-2205] + is used. + +2.11 RFC3041 - Privacy Extensions for Address Configuration in IPv6 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + should be supported. RFC 3041, and privacy in general, is important + for the Internet. Cellular hosts may use the temporary addresses as + described in RFC 3041. However, the use of the Privacy Extension in + an environment where IPv6 addresses are short-lived may not be + necessary. At the time this document has been written, there is no + experience on how long-lived cellular network address assignments + (i.e., attachments to the network) are. The length of the address + assignments depends upon many factors such as radio coverage, device + status and user preferences. Additionally, the use of temporary + address with IPsec may lead to more frequent renegotiation for the + Security Associations. + + Refer to Section 5 for a discussion of the benefits of privacy + extensions in a 3GPP network. + +2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + + The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be + used. DHCPv6 is not required for address autoconfiguration when IPv6 + stateless autoconfiguration is used. However, DHCPv6 may be useful + for other configuration needs on a cellular host. + + + + + +Arkko, et al. Informational [Page 10] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +2.13 RFC3484 - Default Address Selection for IPv6 + + Default Address Selection [RFC-3484] is needed for cellular hosts. + +2.14 DNS + + Cellular hosts should support DNS, as described in [RFC-1034], [RFC- + 1035], [RFC-1886], and [RFC-3152]. + + If DNS is used, a cellular host can perform DNS requests in the + recursive mode, to limit signaling over the air interface. Both the + iterative and the recursive approach should be supported, however, as + the specifications require implementation of the iterative approach, + and allow the recursive approach as an option. Furthermore, all DNS + servers may not support recursive queries, and the security benefits + of DNS Security cannot always be achieved with them. + +3 IP Security + + IPsec [RFC-2401] is a fundamental part of IPv6, and support for AH + and ESP is described as mandatory in the specifications. + + The first part of this section discusses the applicability of IP + Security and other security mechanisms for common tasks in cellular + hosts. The second part, Sections 3.1 to 3.13, lists the + specifications related to IPsec and discusses the use of these parts + of IPsec in a cellular context. + + In general, the need to use a security mechanism depends on the + intended application for it. Different security mechanisms are + useful in different contexts, and have different limitations. Some + applications require the use of TLS [RFC-2246], in some situations + IPsec is used. + + It is not realistic to list all possible services here, and it is + expected that application protocol specifications have requirements + on what security services they require. Note that cellular hosts + able to download applications must be prepared to offer sufficient + security services for these applications regardless of the needs of + the initial set of applications in those hosts. + + The following sections list specifications related to the IPsec + functionality, and discuss their applicability in a cellular context. + This discussion focuses on the use of IPsec. In some applications, a + different set of protocols may need to be employed. In particular, + the below discussion is not relevant for applications that use other + security services than IPsec. + + + + +Arkko, et al. Informational [Page 11] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication + + This specification [RFC-2104] must be supported. It is referenced by + RFC 2403 that describes how IPsec protects the integrity of packets. + +3.2 RFC2401 - Security Architecture for the Internet Protocol + + This specification [RFC-2401] must be supported. + +3.3 RFC2402 - IP Authentication Header + + This specification [RFC-2402] must be supported. + +3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH + + This specification [RFC-2403] must be supported. + +3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH + + This specification [RFC-2404] must be supported. + +3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV + + This specification [RFC-2405] may be supported. It is, however, + recommended that stronger algorithms than DES be used. Algorithms, + such as AES, are undergoing work in the IPsec working group. These + new algorithms are useful, and should be supported as soon as their + standardization is ready. + +3.7 RFC2406 - IP Encapsulating Security Payload (ESP) + + This specification [RFC-2406] must be supported. + +3.8 RFC2407 - The Internet IP Security DoI for ISAKMP + + Automatic key management, [RFC-2408] and [RFC-2409], is not a + mandatory part of the IP Security Architecture. Note, however, that + in the cellular environment the IP addresses of a host may change + dynamically. For this reason the use of manually configured Security + Associations is not practical, as the newest host address would have + to be updated to the SA database of the peer as well. + + Even so, it is not clear that all applications would use IKE for key + management. For instance, hosts may use IPsec ESP [RFC-2406] for + protecting SIP signaling in the IMS [3GPP-ACC] but provide + authentication and key management through another mechanism such as + UMTS AKA (Authentication and Key Agreement) [UMTS-AKA]. + + + + +Arkko, et al. Informational [Page 12] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + It is likely that several simplifying assumptions can be made in the + cellular environment, with respect to the mandated parts of the IP + Security DoI, ISAKMP, and IKE. Work on such simplifications would be + useful, but is outside the scope of this document. + +3.9 RFC2408 - The Internet Security Association and Key Management + Protocol + + This specification [RFC-2408] is optional according to the IPv6 + specifications, but may be necessary in some applications, as + described in Section 3.8. + +3.10 RFC2409 - The Internet Key Exchange (IKE) + + This specification [RFC-2409] is optional according to the IPv6 + specifications, but may be necessary in some applications, as + described in Section 3.8. + + Interactions with the ICMPv6 packets and IPsec policies may cause + unexpected behavior for IKE-based SA negotiation unless some special + handling is performed in the implementations. + + The ICMPv6 protocol provides many functions, which in IPv4 were + either non-existent or provided by lower layers. For instance, IPv6 + implements address resolution using an IP packet, ICMPv6 Neighbor + Solicitation message. In contrast, IPv4 uses an ARP message at a + lower layer. + + The IPsec architecture has a Security Policy Database that specifies + which traffic is protected, and how. It turns out that the + specification of policies in the presence of ICMPv6 traffic is not + easy. For instance, a simple policy of protecting all traffic + between two hosts on the same network would trap even address + resolution messages, leading to a situation where IKE can't establish + a Security Association since in order to send the IKE UDP packets one + would have had to send the Neighbor Solicitation Message, which would + have required an SA. + + In order to avoid this problem, Neighbor Solicitation, Neighbor + Advertisement, Router Solicitation, and Router Advertisement messages + must not lead to the use of IKE-based SA negotiation. The Redirect + message should not lead to the use of IKE-based SA negotiation. + Other ICMPv6 messages may use IKE-based SA negotiation as is desired + in the Security Policy Data Base. + + Note that the above limits the usefulness of IPsec in protecting all + ICMPv6 communications. For instance, it may not be possible to + protect the ICMPv6 traffic between a cellular host and its next hop + + + +Arkko, et al. Informational [Page 13] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + router. (Which may be hard in any case due to the need to establish + a suitable public key infrastructure. Since roaming is allowed, this + infrastructure would have to authenticate all hosts to all routers.) + +3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec + + This specification [RFC-2410] must be supported. + +3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms + + This specification [RFC-2451] must be supported if encryption + algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA, + Blowfish, 3DES. + +4. Mobility + + For the purposes of this document, IP mobility is not relevant. When + Mobile IPv6 specification is approved, a future update to this + document may address these issues, as there may be some effects on + all IPv6 hosts due to Mobile IP. The movement of cellular hosts + within 3GPP networks is handled by link layer mechanisms. + +5. Security Considerations + + This document does not specify any new protocols or functionality, + and as such, it does not introduce any new security vulnerabilities. + However, specific profiles of IPv6 functionality are proposed for + different situations, and vulnerabilities may open or close depending + on which functionality is included and what is not. There are also + aspects of the cellular environment that make certain types of + vulnerabilities more severe. The following issues are discussed: + + - The suggested limitations (Section 2.3) in the processing of + routing headers limits also exposure to DoS attacks through + cellular hosts. + + - IPv6 addressing privacy [RFC3041] may be used in cellular hosts. + However, it should be noted that in the 3GPP model, the network + would assign new addresses, in most cases, to hosts in roaming + situations and typically, also when the cellular hosts activate a + PDP context. This means that 3GPP networks will already provide a + limited form of addressing privacy, and no global tracking of a + single host is possible through its address. On the other hand, + since a GGSN's coverage area is expected to be very large when + compared to currently deployed default routers (no handovers + between GGSNs are possible), a cellular host can keep an address + for a long time. Hence, IPv6 addressing privacy can be used for + additional privacy during the time the host is on and in the same + + + +Arkko, et al. Informational [Page 14] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + area. The privacy features can also be used to e.g., make + different transport sessions appear to come from different IP + addresses. However, it is not clear that these additional efforts + confuse potential observers any further, as they could monitor only + the network prefix part. + + - The use of various security services such as IPsec or TLS in the + connection of typical applications in cellular hosts is discussed + in Section 3 and recommendations are given there. + + - Section 3 also discusses under what conditions it is possible to + provide IPsec protection of e.g., ICMPv6 communications. + + - The airtime used by cellular hosts is expensive. In some cases, + users are billed according to the amount of data they transfer to + and from their host. It is crucial for both the network and the + users that the airtime is used correctly and no extra charges are + applied to users due to misbehaving third parties. The cellular + links also have a limited capacity, which means that they may not + necessarily be able to accommodate more traffic than what the user + selected, such as a multimedia call. Additional traffic might + interfere with the service level experienced by the user. While + Quality of Service mechanisms mitigate these problems to an extent, + it is still apparent that DoS aspects may be highlighted in the + cellular environment. It is possible for existing DoS attacks that + use for instance packet amplification to be substantially more + damaging in this environment. How these attacks can be protected + against is still an area of further study. It is also often easy + to fill the cellular link and queues on both sides with additional + or large packets. + + - Within some service provider networks, it is possible to buy a + prepaid cellular subscription without presenting personal + identification. Attackers that wish to remain unidentified could + leverage this. 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, local network interfaces should have access control to + prevent others from using the cellular host as an intermediary. + + + +Arkko, et al. Informational [Page 15] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +6. References + +6.1. Normative + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6, RFC 1886, December 1995. + + [RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery + for IP version 6", RFC 1981, August 1996. + + [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC-2104] Krawczyk, K., Bellare, M. and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", + RFC 2402, November 1998. + + [RFC-2403] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP + and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within + ESP and AH", RFC 2404, November 1998. + + [RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2406] Kent, S. and R. Atkinson, "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 J. Turner, + "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + + + +Arkko, et al. Informational [Page 16] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + [RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and + Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC-2463] Conta, A. and S. Deering, "ICMP for the Internet Protocol + Version 6 (IPv6)", RFC 2463, December 1998. + + [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in + IPv6 Specification", RFC 2473, December 1998. + + [RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", + RFC 2711, October 1999. + + [RFC-2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, July + 2000. + + [RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC-3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. + Vaidya, "End-to-end Performance Implications of Links + with Errors", BCP 50, RFC 3155, August 2001. + + + + + +Arkko, et al. Informational [Page 17] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + + [RFC-3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + +6.2. Informative + + [3GPP-ACC] 3GPP Technical Specification 3GPP TS 33.203, "Technical + Specification Group Services and System Aspects; 3G + Security; Access security for IP-based services (Release + 5)", 3rd Generation Partnership Project, March 2002. + + [3GPP-IMS] 3rd Generation Partnership Project; Technical + Specification Group Services and System Aspects; IP + Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228) + + [3GPP-IPv6] 3rd Generation Partnership Project; Technical + Specification Group Services and System Aspects + "Architectural requirements" (TS 23.221) + + [DHCPv6] Bound, J., et al., "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", Work in progress. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC-2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over + IPv4 Domains without Explicit Tunnels", RFC 2529, March + 1999. + + [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, September 1997. + + [RFC-3314] Wasserman, M., Editor, "Recommendations for IPv6 in Third + Generation Partnership Project (3GPP) Standards, RFC + 3314, September 2002. + + [RFC-3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and + F. Khafizov, "TCP over Second (2.5G) and Third (3G) + Generation Wireless Networks", BCP 71, RFC 3481, February + 2003. + + [UMTS-AKA] 3GPP Technical Specification 3GPP TS 33.102, "Technical + Specification Group Services and System Aspects; 3G + Security; Security Architecture (Release 4)", 3rd + Generation Partnership Project, December 2001. + + + +Arkko, et al. Informational [Page 18] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +7. Contributors + + This document is based on the results of a team that included Peter + Hedman and Pertti Suomela in addition to the authors. Peter and + Pertti have contributed both text and their IPv6 experience to this + document. + +8. Acknowledgements + + The authors would like to thank Jim Bound, Brian Carpenter, Steve + Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, + Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing + list for their comments and input. + + We would also like to thank David DeCamp, Karim El Malki, Markus + Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and + Shabnam Sultana for their comments and input in preparation of this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 19] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model + + The appendix aims to very briefly describe the 3GPP IPv6 addressing + model for 2G (GPRS) and 3G (UMTS) cellular networks from Release 99 + onwards. More information can be found from 3GPP Technical + Specification 23.060. + + There are two possibilities to allocate the address for an IPv6 node: + stateless and stateful autoconfiguration. The stateful address + allocation mechanism needs a DHCP server to allocate the address for + the IPv6 node. On the other hand, the stateless autoconfiguration + procedure does not need any external entity involved in the address + autoconfiguration (apart from the GGSN). + + In order to support the standard IPv6 stateless address + autoconfiguration mechanism, as recommended by the IETF, the GGSN + shall assign a prefix that is unique within its scope to each primary + PDP context that uses IPv6 stateless address autoconfiguration. This + avoids the necessity to perform Duplicate Address Detection at the + network level for every address built by the mobile host. The GGSN + always provides an Interface Identifier to the mobile host. The + Mobile host uses the interface identifier provided by the GGSN to + generate its link-local address. The GGSN provides the cellular host + with the interface identifier, usually in a random manner. It must + ensure the uniqueness of such identifier on the link (i.e., no + collisions between its own link-local address and the cellular + host's). + + In addition, the GGSN will not use any of the prefixes assigned to + cellular hosts to generate any of its own addresses. This use of the + interface identifier, combined with the fact that each PDP context is + allocated a unique prefix, will eliminate the need for DAD messages + over the air interface, and consequently allows an efficient use of + bandwidth. Furthermore, the allocation of a prefix to each PDP + context will allow hosts to implement the privacy extensions in RFC + 3041 without the need for further DAD messages. + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 20] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +Authors' Addresses + + Jari Arkko + Ericsson + 02420 Jorvas + Finland + + EMail: jari.arkko@ericsson.com + + + Gerben Kuijpers + Ericsson + Skanderborgvej 232 + DK-8260 Viby J + Denmark + + EMail: gerben.a.kuijpers@ted.ericsson.se + + + John Loughney + Nokia Research Center + Itamerenkatu 11 - 13 + FIN-00180 HELSINKI + Finland + + EMail: john.loughney@nokia.com + + + Hesham Soliman + Ericsson Radio Systems AB + Torshamnsgatan 23, Kista, Stockholm + Sweden + + EMail: hesham.soliman@era.ericsson.se + + + Juha Wiljakka + Nokia Mobile Phones + Sinitaival 5 + FIN-33720 TAMPERE + Finland + + EMail: juha.wiljakka@nokia.com + + + + + + + + +Arkko, et al. Informational [Page 21] + +RFC 3316 IPv6 for Some 2G and 3G Cellular Hosts April 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Arkko, et al. Informational [Page 22] + |