idnits 2.17.1 draft-ietf-ipv6-cellular-host-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 2002) is 8007 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TCPWIRELESS' is mentioned on line 817, but not defined == Missing Reference: 'RFC-2472' is mentioned on line 362, but not defined ** Obsolete undefined reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) == Missing Reference: 'RFC-2205' is mentioned on line 813, but not defined == Missing Reference: 'RFC-2893' is mentioned on line 966, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Missing Reference: 'RFC-3056' is mentioned on line 810, but not defined == Missing Reference: 'RFC-1034' is mentioned on line 800, but not defined == Missing Reference: '3GPP-ACC' is mentioned on line 783, but not defined == Missing Reference: 'UMTS-AKA' is mentioned on line 820, but not defined == Missing Reference: 'RFC3041' is mentioned on line 620, but not defined ** Obsolete undefined reference: RFC 3041 (Obsoleted by RFC 4941) == Missing Reference: '3GPP-IMS' is mentioned on line 789, but not defined == Missing Reference: '3GPP-IPv6' is mentioned on line 793, but not defined == Missing Reference: 'IPv6-3GPP' is mentioned on line 797, but not defined == Missing Reference: 'RFC-2529' is mentioned on line 981, but not defined == Unused Reference: 'RFC-2407' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC-2874' is defined on line 773, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRARCHv3' -- Possible downref: Non-RFC (?) normative reference: ref. 'DEFADDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Downref: Normative reference to an Historic RFC: RFC 2874 ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) Summary: 23 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Jari Arkko 3 Internet Engineering Task Force Peter Hedman 4 Gerben Kuijpers 5 Hesham Soliman 6 Ericsson 7 John Loughney 8 Pertti Suomela 9 Juha Wiljakka 10 Nokia 11 Issued: May 17, 2002 12 Expires: November 17, 2002 14 IPv6 for Some Second and Third Generation Cellular Hosts 15 17 Status of This Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC 2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as 'work in progress.' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 As the deployment of second and third generation cellular networks 41 progresses, a large number of cellular hosts are being connected to 42 the Internet. Standardization organizations are making IPv6 43 mandatory in their specifications. However, the concept of IPv6 44 covers many aspects and numerous specifications. In addition, the 45 characteristics of cellular links in terms of bandwidth, cost and 46 delay put special requirements on how IPv6 is used. This document 47 considers IPv6 for cellular hosts that attach to the General Packet 48 Radio Service (GPRS), or Universal Mobile Telecommunications System 49 (UMTS) networks. The document lists basic components of IPv6 50 functionality and discusses some issues relating to the use of these 51 components when operating in these networks. 53 Abstract.............................................................1 54 1 Introduction.......................................................3 55 1.1 Scope of this Document..........................................3 56 1.2 Abbreviations...................................................4 57 1.4 Cellular Host IPv6 Features.....................................5 58 2 Basic IP...........................................................5 59 2.1 RFC1981 - Path MTU Discovery for IP Version 6...................5 60 2.2 RFC2373 - IP Version 6 Addressing Architecture..................5 61 2.3 RFC2460 - Internet Protocol Version 6...........................6 62 2.4 RFC2461 - Neighbor Discovery for IPv6...........................6 63 2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration..............7 64 2.6 RFC2463 - Internet Control Message Protocol for the IPv6........7 65 2.7 RFC2472 - IP version 6 over PPP.................................8 66 2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification........8 67 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6...........8 68 2.10 RFC2711 - IPv6 Router Alert Option.............................9 69 2.11 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers.....9 70 2.12 RFC3041 - Privacy Extensions for Address Configuration in IPv6.9 71 2.13 RFC3056 - Connection of IPv6 Domains via IPv4 Clouds...........9 72 2.14 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)..........9 73 2.15 Default Address Selection for IPv6.............................9 74 2.16 DNS............................................................9 75 3 IP Security.......................................................10 76 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication.......10 77 3.2 RFC2401 - Security Architecture for the Internet Protocol......10 78 3.3 RFC2402 - IP Authentication Header.............................10 79 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.............11 80 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.............11 81 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV....11 82 3.7 RFC2406 - IP Encapsulating Security Payload (ESP)..............11 83 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP..............11 84 3.9 RFC2408 - The Internet Security Association and Key Management 11 85 Protocol...........................................................11 86 3.10 RFC2409 - The Internet Key Exchange (IKE).....................11 87 3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec..12 88 3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms..................12 89 4. Mobility.........................................................12 90 5. Security Considerations..........................................13 91 6. References.......................................................14 92 6.1. Normative.....................................................14 93 6.2. Non-Normative.................................................16 94 7. Acknowledgements.................................................17 95 8. Authors' Addresses...............................................17 96 Appendix A Revision History.........................................19 97 Appendix B Cellular Host IPv6 Addressing in the 3GPP Model..........19 98 Appendix C Transition Issues........................................20 100 1 Introduction 102 Technologies such as GPRS (General Packet Radio Service), UMTS 103 (Universal Mobile Telecommunications System) and CDMA2000 (Code 104 Division Multiple Access 2000) are making it possible for cellular 105 hosts to have an always-on connection to the Internet. IPv6 becomes 106 necessary, as it is expected that the number of such cellular hosts 107 will increase rapidly. Standardization organizations working with 108 cellular technologies have recognized this and are making IPv6 109 mandatory in their specifications. 110 Support for IPv6 and the introduction of UMTS starts with 3GPP 111 Release 99 networks and hosts. IPv6 is specified as the only IP 112 version supported in Release 5 for IP Multimedia Subsystem (IMS). 114 1.1 Scope of this Document 116 For the purposes of this document, a cellular interface is 117 considered to be the interface to a cellular access network based on 118 the following standards: 3GPP GPRS and UMTS Release 99, Release 4, 119 Release 5, as well as future UMTS releases. A cellular host is 120 considered to be a host with such a cellular interface. 122 This document lists IPv6 specifications and discusses some issues 123 relating to the use of these specifications when operating over 124 cellular interfaces. Such a specification is necessary in order for 125 the optimal use of IPv6 in a cellular environment. The description 126 is made from a cellular host point of view. Important considerations 127 are given in order to eliminate unnecessary user confusion over 128 configuration options, ensure interoperability and to provide an 129 easy reference for those implementing IPv6 in a cellular host. It is 130 necessary to ensure that cellular hosts are good citizens of the 131 Internet. 133 The main audience of this document are the implementers of cellular 134 hosts that will be used with GPRS, 3GPP UMTS Release 99, Release 4, 135 Release 5, or future releases of UMTS. The document provides 136 guidance on which parts of IPv6 to implement in such cellular hosts. 137 Parts of this document may also apply to other cellular link types, 138 but no such detailed analysis has been done yet and is a topic of 139 future work. This document should not be used as a definitive list 140 of IPv6 functionality for cellular links other than those listed 141 above. Future changes in 3GPP networks that require changes in host 142 implementations may result in updates to this document. 144 There are different ways to implement cellular hosts: 146 - The host can be a "closed 2G or 3G host" with a very compact 147 size and optimized applications, with no possibility to add 148 or download applications that can have IP communications. An 149 example of such a host is a very simple form of a mobile 150 phone. 152 - The host can be an "open 2G or 3G host" with a compact size, 153 but where it is possible to download applications; such as a 154 PDA-type of phone. 156 If a cellular host has additional interfaces on which IP is used, 157 (such as Ethernet, WLAN, Bluetooth, etc.) then there may be 158 additional requirements for the device, beyond what is discussed in 159 this document. Additionally, this document does not make any 160 recommendations on the functionality required on laptop computers 161 having a cellular interface such as a PC card, other than 162 recommending link specific behavior on the cellular link. 164 This document discusses IPv6 functionality as specified when this 165 draft is written. Ongoing work on IPv6 may affect what is needed 166 from future hosts. The reader should also be advised other relevant 167 work exists for various other layers. Examples of this include the 168 header compression work done in the IETF ROHC group, or the TCP work 169 in [TCPWIRELESS]. 171 1.2 Abbreviations 173 2G Second Generation Mobile Telecommunications, such as GSM 174 and GPRS technologies. 175 3G Third Generation Mobile Telecommunications, such as UMTS 176 technology. 177 3GPP 3rd Generation Partnership Project. Throughout the 178 document, the term 3GPP (3rd Generation Partnership 179 Project) networks refers to architectures standardized 180 by 3GPP, in Second and Third Generation releases: 99, 4, 181 and 5, as well as future releases. 182 AH Authentication Header 183 APN Access Point Name. The APN is a logical name referring 184 to a GGSN and an external network. 185 ESP Encapsulating Security Payload 186 ETSI European Telecommunications Standards Institute 187 IMS IP Multimedia Subsystem 188 GGSN Gateway GPRS Support Node (a default router for 3GPP 189 IPv6 cellular hosts) 190 GPRS General Packet Radio Service 191 GSM Global System for Mobile Communications 192 IKE Internet Key Exchange 193 ISAKMP Internet Security Association and Key Management 194 Protocol 195 MT Mobile Terminal, for example, a mobile phone handset. 196 MTU Maximum Transmission Unit 197 PDP Packet Data Protocol 198 SGSN Serving GPRS Support Node 199 TE Terminal Equipment, for example, a laptop attached 200 through a 3GPP handset. 201 UMTS Universal Mobile Telecommunications System 202 WLAN Wireless Local Area Network 204 1.4 Cellular Host IPv6 Features 206 This specification defines IPv6 features for cellular hosts in three 207 groups. 209 Basic IP 211 In this group, basic parts of IPv6 are described. 213 IP Security 215 In this group, the IP Security parts, as well as, the 216 suitability of various security functions to different 217 applications in cellular hosts are discussed. 219 Mobility 221 In this group, IP layer mobility issues are discussed. 223 2 Basic IP 225 2.1 RFC1981 - Path MTU Discovery for IP Version 6 227 Path MTU Discovery [RFC-1981] may be used. Cellular hosts with a 228 link MTU larger than the minimum IPv6 link MTU (1280 octets) can use 229 Path MTU Discovery in order to discover the real path MTU. The 230 relative overhead of IPv6 headers is minimized through the use of 231 longer packets, thus making better use of the available bandwidth. 233 The IPv6 specification [RFC-2460] states in chapter 5 that "a 234 minimal IPv6 implementation (e.g., in a boot ROM) may simply 235 restrict itself to sending packets no larger than 1280 octets, and 236 omit implementation of Path MTU Discovery." 238 If Path MTU Discovery is not implemented then the sending packet 239 size is limited to 1280 octets (standard limit in [RFC-2460]). 240 However, if this is done, the cellular host must be able to receive 241 packets with size up to the link MTU before reassembly. This is 242 because the node at the other side of the link has no way of knowing 243 less than the MTU is accepted. 245 2.2 RFC2373 - IP Version 6 Addressing Architecture 247 The IPv6 Addressing Architecture [RFC-2373] is a mandatory part of 248 IPv6. Currently, this specification is being updated by 249 [ADDRARCHv3]; therefore, this specification may be made obsolete by 250 the new one, in which case the new specification must be supported. 252 2.3 RFC2460 - Internet Protocol Version 6 254 The Internet Protocol Version 6 is specified in [RFC-2460]. This 255 specification is a mandatory part of IPv6. 257 By definition, a cellular host acts as a host, not as a router. 258 Implementation requirements for a cellular router are not defined in 259 this document. 261 Consequently, the cellular host must implement all non-router packet 262 receive processing as described in RFC 2460. This includes the 263 generation of ICMPv6 error reports, and the processing of at least 264 the following extension headers: 266 - Hop-by-Hop Options header: at least the Pad1 and PadN options 267 - Destination Options header: at least the Pad1 and PadN options 268 - Routing (Type 0) header: final destination (host) processing 269 only 270 - Fragment header 271 - AH and ESP headers (see also a discussion on the use of IPsec 272 for various purposes in Section 3) 273 - The No Next Header value 275 Unrecognized options in Hop-by-Hop Options or Destination Options 276 extensions must be processed as described in RFC 2460. 278 The cellular host must follow the packet transmission rules in RFC 279 2460. 281 The cellular host must always be able to receive and reassemble 282 fragment headers. It will also need to be able to send a fragment 283 header in cases where it communicates with an IPv4 host through a 284 translator. 286 Cellular hosts should only process routing headers when they are the 287 final destination and return errors if the processing of the routing 288 header requires them to forward the packet to another node. This 289 will also ensure that the cellular hosts will not be inappropriately 290 used as relays or components in Denial-of-Service attacks. Acting as 291 the destination involves the following: the cellular hosts must 292 check the Segments Left field in the header, and proceed if it is 293 zero or one and the next address is one of the host's addresses. If 294 not, however, the host must implement error checks as specified in 295 section 4.4 of RFC 2460. There is no need for the host to send 296 Routing Headers. 298 2.4 RFC2461 - Neighbor Discovery for IPv6 300 Neighbor Discovery is described in [RFC-2461]. This specification is 301 a mandatory part of IPv6. 303 2.4.1 Neighbor Discovery in 3GPP Networks 305 In GPRS and UMTS networks, some Neighbor Discovery messages can 306 cause unnecessary traffic and consume valuable (limited) bandwidth. 307 GPRS and UMTS links resemble a point-to-point link; hence, the 308 host's only neighbor on the cellular link is the default router that 309 is already known through Router Discovery. This router is 310 typically not the final destination for the host's traffic. 311 Additionally, due to special characteristics of the cellular link, 312 lower layer connectivity information should make it unnecessary to 313 track the reachability of the router. Therefore, while the host must 314 support Neighbor Solicitation and Advertisement messages, their use 315 is not necessary and the host may choose to not initiate them. 317 In addition, a cellular host should not send the link layer option 318 on its cellular interface, and should silently ignore it when 319 received on the same interface. 321 Hosts in a UMTS network, only need to use Router Solicitations and 322 Router Advertisements for 3GPP IPv6 Address Autoconfiguration (see 323 appendix B). Neighbor Solicitations and Advertisements may be used 324 for Neighbor Unreachability Detection (NUD). They are not required 325 for 3GPP IPv6 Stateless Address Autoconfiguration, since address 326 duplication is not possible in this address assignment mechanism 327 (see section 2.5.1). 329 2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration 331 IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. 332 This specification is a mandatory part of IPv6. 334 2.5.1 Stateless Address Autoconfiguration in 3GPP Networks 336 A cellular host in a 3GPP network must process a Router 337 Advertisement as stated in section 2.4. 339 Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, 340 as each delegated prefix is unique within its scope when allocated 341 using the 3GPP IPv6 Stateless Address Autoconfiguration. Thus, 342 Duplicate Address Detection is not required on the cellular 343 interface. DAD messages will not be sent or received by the IPv6 344 cellular host on the cellular interface. 346 See appendix B for more details on 3GPP IPv6 Stateless Address 347 Autoconfiguration. 349 2.6 RFC2463 - Internet Control Message Protocol for the IPv6 351 The Internet Control Message Protocol for the IPv6 is defined [RFC- 352 2463]. This specification is a mandatory part of IPv6. Currently, 353 this work is being updated. 355 As per RFC 2463 section 2, ICMPv6 requirements must be fully 356 implemented by every IPv6 node. See also Section 3 for an 357 explanation of the use of IPsec for protecting ICMPv6 358 communications. 360 2.7 RFC2472 - IP version 6 over PPP 362 IPv6 over PPP [RFC-2472] must be supported for cellular hosts that 363 implement PPP. 365 2.7.1 IP version 6 over PPP in 3GPP Networks 367 A cellular host in a 3GPP network must support the IPv6CP interface 368 identifier option. This option is needed to be able to connect other 369 devices to the Internet using a PPP link between the cellular device 370 (MT) and other devices (TE, e.g. a laptop). The MT performs the PDP 371 Context activation based on a request from the TE. This results in 372 an interface identifier being suggested by the MT to the TE, using 373 the IPv6CP option. To avoid any duplication in link-local addresses 374 between the TE and the GGSN, the MT must always reject other 375 suggested interface identifiers by the TE. This results in the TE 376 always using the interface identifier suggested by the GGSN for its 377 link-local address. 379 The rejection of interface identifiers suggested by the TE is only 380 done for creation of link local addresses, according to 3GPP 381 specifications. The use of privacy addresses [RFC-3041] for site- 382 local and global addresses is not affected by the above procedure. 383 The above procedure is only concerned with assigning the interface 384 identifier used for forming link-local addresses, and does not 385 preclude TE from using other interface identifiers for addresses 386 with larger scopes (i.e. site-local and global). 388 2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification 390 Generic Packet Tunneling [RFC-2473] may be supported if needed for 391 transition mechanisms. 393 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 395 Multicast Listener Discovery [RFC-2710] may be supported, if the 396 cellular host is supporting applications that require the use of 397 multicast services. There is no need for MLD if the host only 398 supports the well-known (hard coded in IPv6 implementations) link 399 local multicast addresses. MLD is not used for listening on such 400 addresses. 402 2.10 RFC2711 - IPv6 Router Alert Option 404 The Router Alert Option [RFC-2711] may be supported. Currently, this 405 option is needed for MLD implementations (see section 2.9) or when 406 RSVP [RFC-2205] is used. 408 2.11 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers 410 [RFC-2893] specifies a number of transition mechanisms for IPv6 411 hosts. Cellular hosts may support the dual stack mechanism mentioned 412 in this specification. This also includes resolving addresses from 413 the DNS and selecting the type of address for the correspondent host 414 (IPv4 vs. IPv6). Cellular hosts should not support configured or 415 automatic tunnels to avoid unnecessary tunneling over the air 416 interface, unless there are no other mechanisms available. Tunneling 417 can lead to poor usage of available bandwidth. 419 2.12 RFC3041 - Privacy Extensions for Address Configuration in IPv6 421 Privacy Extensions for Stateless Address Autoconfiguration [RFC- 422 3041] may be used. Refer to section 5 for a discussion of the 423 benefits of privacy extensions in a 3GPP network. 425 2.13 RFC3056 - Connection of IPv6 Domains via IPv4 Clouds 427 Connection of IPv6 domains via IPv4 clouds [RFC-3056] should not be 428 supported to avoid unnecessary tunneling over the air interface. For 429 a cellular host, this specification would mean capability to create 430 6to4 tunnels starting from the cellular host itself. In a cellular 431 environment, tunneling over the air interface should be minimized as 432 tunneling can lead to poor usage of available bandwidth. Hence, 433 intermediate 6to4 routers should carry out 6to4 tunneling, instead 434 of cellular hosts. 436 2.14 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 438 The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be 439 used. DHCPv6 is not required for address autoconfiguration when IPv6 440 stateless autoconfiguration is used. However, DHCPv6 may be useful 441 for other configuration needs on a cellular host. 443 2.15 Default Address Selection for IPv6 445 Default Address Selection for IPv6 [DEFADDR] is needed for cellular 446 hosts with more than one address. 448 2.16 DNS 450 Cellular hosts should support DNS, as described in [RFC-1034], [RFC- 451 1035] and [RFC-1886]. 453 If DNS is used, a cellular host should perform DNS requests in the 454 recursive mode, to limit signaling over the air interface. 456 3 IP Security 458 IPsec [RFC-2401] is a fundamental part of IPv6, and support for AH 459 and ESP is described as mandatory in the specifications. 461 The first part of this section discusses the applicability of IP 462 Security and other security mechanisms for common tasks in cellular 463 hosts. The second part, subsections 3.1 to 3.13, lists the RFCs 464 related to IPsec and discusses the use of these parts of IPsec in a 465 cellular context. 467 In general, the need to use a security mechanism depends on the 468 intended application for it. Different security mechanisms are 469 useful in different contexts, and have different limitations. Some 470 applications require the use of TLS [RFC-2246], in some situations 471 IPsec is used. 473 It is not realistic to list all possible services here, and it is 474 expected that application protocol specifications have requirements 475 on what security services they require. Note that cellular hosts 476 able to download applications must be prepared to offer sufficient 477 security services for these applications regardless of the needs of 478 the initial set of applications in those hosts. 480 The following sections list specifications related to the IPsec 481 functionality, and discuss their applicability in a cellular 482 context. In some applications, a different set of protocols may 483 need a different set of protocols may need to be employed. 484 In particular, the below discussion is not relevant for applications 485 that use other security services than IPsec. 487 3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication 489 This specification [RFC-2104] must be supported. It is referenced by 490 RFC 2403 that describes how IPsec protects the integrity of packets. 492 3.2 RFC2401 - Security Architecture for the Internet Protocol 494 This specification [RFC-2401] must be supported. 496 3.3 RFC2402 - IP Authentication Header 498 This specification [RFC-2402] must be supported. The IPsec WG has 499 discussed the role of AH in the future, and it is possible that it 500 will be made optional in the future versions of the IPsec protocol 501 set. Implementers are recommended to take this in account. 503 3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH 505 This specification [RFC-2403] must be supported. 507 3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH 509 This specification [RFC-2404] must be supported. 511 3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV 513 This specification [RFC-2405] may be supported. It is, however, 514 recommended that stronger algorithms than DES be used. Algorithms, 515 such as AES, are undergoing work in the IPsec working group. 517 3.7 RFC2406 - IP Encapsulating Security Payload (ESP) 519 This specification [RFC-2406] must be supported. 521 3.8 RFC2407 - The Internet IP Security DoI for ISAKMP 523 Automatic key management, [RFC-2408] and [RFC-2409], is not a 524 mandatory part of the IP Security Architecture. Note, however, that 525 in the cellular environment the IP addresses of a host may change 526 dynamically. For this reason the use of manually configured Security 527 Associations is not practical, as the newest host address would have 528 to be updated to the SA database of the peer as well. 530 Even so, it is not clear that all applications would use IKE for key 531 management. For instance, hosts may use IPsec ESP [RFC-2406] for 532 protecting SIP signaling in the IMS [3GPP-ACC] but provide 533 authentication and key management through another mechanism such as 534 UMTS AKA (Authentication and Key Agreement) [UMTS-AKA]. 536 It is likely that several simplifying assumptions can be made in the 537 cellular environment, with respect to the mandated parts of the IP 538 Security DoI, ISAKMP, and IKE. Although work on such simplifications 539 would be useful, is not described here. 541 3.9 RFC2408 - The Internet Security Association and Key Management 542 Protocol 544 This specification [RFC-2408] is optional according to the IPv6 545 specifications, but may be necessary in some applications, as 546 described in Section 3.8. 548 3.10 RFC2409 - The Internet Key Exchange (IKE) 550 This specification [RFC-2409] is optional according to the IPv6 551 specifications, but may be necessary in some applications, as 552 described in Section 3.8. 554 Interactions with the ICMPv6 packets and IPsec policies may cause 555 unexpected behavior for IKE-based SA negotiation unless some special 556 handling is performed in the implementations. 558 The ICMPv6 protocol provides many functions, which in IPv4 were 559 either non-existent or provided by lower layers. For instance, IPv6 560 implements address resolution using an IP packet, ICMPv6 Neighbor 561 Solicitation message. In contrast, IPv4 uses an ARP message at a 562 lower layer. 564 The IPsec architecture has a Security Policy Database that specifies 565 which traffic is protected, and how. It turns out that the 566 specification of policies in the presence of ICMPv6 traffic is not 567 easy. For instance, a simple policy of protecting all traffic 568 between two hosts on the same network would trap even address 569 resolution messages, leading to a situation where IKE can't 570 establish a Security Association since in order to send the IKE UDP 571 packets one would have had to send the Neighbor Solicitation 572 Message, which would have required an SA. 574 In order to avoid this problem, Neighbor Solicitation, Neighbor 575 Advertisement, Router Solicitation, and Router Advertisement 576 messages must not lead to the use of IKE-based SA negotiation. The 577 Redirect message should not lead to the use of IKE-based SA 578 negotiation. Other ICMPv6 messages may use IKE-based SA negotiation 579 as is desired in the Security Policy Data Base. 581 Note that the above limits the usefulness of IPsec in protecting all 582 ICMPv6 communications. For instance, it may not be possible to 583 protect the ICMPv6 traffic between a cellular host and its next hop 584 router. (Which may be hard in any case due to the need to establish 585 a suitable public key infrastructure. Since roaming is allowed, this 586 infrastructure would have to authenticate all hosts to all routers.) 588 3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec 590 This specification [RFC-2410] must be supported. 592 3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms 594 This specification [RFC-2451] must be supported if encryption 595 algorithms other than DES are implemented, e.g.: CAST-128, RC5, 596 IDEA, Blowfish, 3DES. 598 4. Mobility 600 For the purposes of this document, IP mobility is not relevant. When 601 Mobile IPv6 specification is approved, a future update to this 602 document may address these issues, as there may be some effects on 603 IPv6 hosts due to Mobile IP. The movement of cellular hosts within 604 3GPP networks is handled by link layer mechanisms. 606 5. Security Considerations 608 This document does not specify any new protocols or functionality, 609 and as such, it does not introduce any new security vulnerabilities. 610 However, specific profiles of IPv6 functionality are proposed for 611 different situations, and vulnerabilities may open or close 612 depending on which functionality is included and what is not. There 613 are also aspects of the cellular environment that make certain types 614 of vulnerabilities more severe. The following issues are discussed: 616 - The suggested limitations (Section 2.3) in the processing of 617 routing headers limits also exposure to Denial-of-Service attacks 618 through cellular hosts. 620 - IPv6 addressing privacy [RFC3041] may be used in cellular hosts. 621 However, it should be noted that in the 3GPP model, the network 622 would assign new addresses, in most cases, to hosts in roaming 623 situations and typically, also when the cellular hosts activate a 624 PDP context. This means that 3GPP networks will already provide a 625 limited form of addressing privacy, and no global tracking of a 626 single host is possible through its address. On the other hand, 627 since a GGSN's coverage area is expected to be very large when 628 compared to currently deployed default routers (no handovers 629 between GGSNs are possible), a cellular host can keep an address 630 for a long time. Hence, IPv6 addressing privacy can be used for 631 additional privacy during the time the host is on and in the same 632 area. The privacy features can also be used to e.g. make different 633 transport sessions appear to come from different IP addresses. 634 However, it is not clear that these additional efforts confuse 635 potential observers any further, as they could monitor only the 636 network prefix part. 638 - The use of various security services such as IPsec or TLS in the 639 connection of typical applications in cellular hosts is discussed 640 in Chapter 3 and recommendations are given there. 642 - Chapter 3 also discusses under what conditions it is possible to 643 provide IPsec protection of e.g. ICMPv6 communications 645 - The airtime used by cellular hosts is expensive. In some cases, 646 users are billed according to the amount of data they transfer to 647 and from their host. It is crucial for both the network and the 648 users that the airtime is used correctly and no extra charges are 649 applied to users due to misbehaving third parties. The cellular 650 links also have a limited capacity, which means that they may not 651 necessarily be able to accommodate more traffic than what the user 652 selected, such as a multimedia call. Additional traffic might 653 interfere with the service level experienced by the user. While 654 Quality of Service mechanisms mitigates these problems to an 655 extent, it is still apparent that Denial-of-Service (DoS) aspects 656 may be highlighted in the cellular environment. It is possible for 657 existing DoS attacks that use for instance packet amplification to 658 be substantially more damaging in this environment. How these 659 attacks can be protected against is still an area of further 660 study. It is also often easy to fill the cellular link and queues 661 on both sides with additional or large packets. 663 - Within some service provider networks, it is possible to buy a 664 prepaid cellular subscription without presenting personal 665 identification. Attackers that wish to remain unidentified could 666 leverage this. Note that while the user hasn't been identified, 667 the equipment still is; the operators can follow the identity of 668 the device and block it from further use. The operators must have 669 procedures in place to take notice of third party complaints 670 regarding the use of their customers' devices. It may also be 671 necessary for the operators to have attack detection tools that 672 enable them to efficiently detect attacks launched from the 673 cellular hosts. 675 - Cellular devices that have local network interfaces (such as IrDA 676 or Bluetooth) may be used to launch attacks through them, unless 677 the local interfaces are secured in an appropriate manner. 678 Therefore, local network interfaces should have access control to 679 prevent others from using the cellular host as an intermediary. 681 6. References 683 6.1. Normative 685 [ADDRARCHv3] Hinden, R. and Deering, S. "IP Version 6 Addressing 686 Architecture", Work in progress. 688 [DEFADDR] Draves, R., "Default Address Selection for IPv6", 689 Work in progress. 691 [DHCPv6] Bound, J. et al., "Dynamic Host Configuration 692 Protocol for IPv6 (DHCPv6)", Work in progress. 694 [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU 695 Discovery for IP version 6", RFC 1981, August 1996. 697 [RFC-1035] Mockapetris, P., "Domain names - implementation and 698 specification", STD 13, RFC 1035, November 1987. 700 [RFC-1886] Thomson, S. and Huitema, C., "DNS Extensions to 701 support IP version 6, RFC 1886, December 1995. 703 [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: 704 Keyed-Hashing for Message Authentication", RFC 2104, 705 February 1997. 707 [RFC-2246] Dierks, T. and Allen, C., "The TLS Protocol Version 708 1.0", RFC 2246, January 1999 710 [RFC-2373] Hinden, R. and Deering, S., "IP Version 6 Addressing 711 Architecture", RFC 2373, July 1998. 713 [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for 714 the Internet Protocol", RFC 2401, November 1998. 716 [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication 717 Header", RFC 2402, November 1998. 719 [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 720 within ESP and AH", RFC 2403, November 1998. 722 [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 723 within ESP and AH", RFC 2404, November 1998. 725 [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher 726 Algorithm With Explicit IV", RFC 2405, November 1998. 728 [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security 729 Protocol (ESP)", RFC 2406, November 1998. 731 [RFC-2407] Piper, D., "The Internet IP Security Domain of 732 Interpretation for ISAKMP", RFC 2407, November 1998. 734 [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and 735 Turner, J., "Internet Security Association and Key 736 Management Protocol (ISAKMP)", RFC 2408, November 737 1998. 739 [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key 740 Exchange (IKE)", RFC 2409, November 1998. 742 [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption 743 Algorithm and Its Use With IPsec", RFC 2410, November 744 1998 746 [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher 747 Algorithms", RFC 2451, November 1998 749 [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, 750 Version 6 (IPv6) Specification", RFC 2460, December 751 1998. 753 [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 754 Discovery for IP Version 6 (IPv6)", RFC 2461, 755 December 1998. 757 [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address 758 Autoconfiguration", RFC 2462. 760 [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet 761 Protocol Version 6 (IPv6)", RFC 2463, December 1998. 763 [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling 764 in IPv6 Specification", RFC 2473, December 1998. 766 [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast 767 Listener Discovery (MLD) for IPv6", RFC 2710, October 768 1999. 770 [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert 771 Option", RFC 2711, October 1999. 773 [RFC-2874] Crawford, M. and Huitema, C., "DNS Extensions to 774 Support IPv6 Address Aggregation and Renumbering", 775 RFC 2874, July 2000. 777 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 778 Stateless Address Autoconfiguration in IPv6", RFC 779 3041, January 2001. 781 6.2. Non-Normative 783 [3GPP-ACC] 3GPP Technical Specification 3GPP TS 33.203, 784 "Technical Specification Group Services and System 785 Aspects; 3G Security; Access security for IP-based 786 services (Release 5)", 3rd Generation Partnership 787 Project, March 2002. 789 [3GPP-IMS] 3rd Generation Partnership Project; Technical 790 Specification Group Services and System Aspects; IP 791 Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228) 793 [3GPP-IPv6] 3rd Generation Partnership Project; Technical 794 Specification Group Services and System Aspects 795 "Architectural requirements" (TS 23.221) 797 [IPv6-3GPP] Wasserman, M (editor), "Recommendations for IPv6 in 798 3GPP Standards" Work in Progress. 800 [RFC-1034] Mockapetris, P., "Domain names - concepts and 801 facilities", RFC 1034, November 1987 803 [RFC-2529] Carpenter, B. and Jung, C., "Transmission of IPv6 804 over IPv4 Domains without Explicit Tunnels", RFC 805 2529, March 1999. 807 [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms 808 for IPv6 Hosts and Routers", RFC 2893, August 2000. 810 [RFC-3056] Carpenter, B. and Moore, K., "Connection of IPv6 811 domains via IPv4 clouds", RFC 3056, February 2001. 813 [RFC-2205] Resource ReSerVation Protocol (RSVP) -- Version 1 814 Functional Specification. R. Braden, Ed., L. Zhang, 815 S. Berson, S. Herzog, S. Jamin, RFC 2205September 816 1997. 817 [TCPWIRELESS] Inamura, H. et al. "TCP over 2.5G and 3G Networks". 818 IETF, Work in progress. 820 [UMTS-AKA] 3GPP Technical Specification 3GPP TS 33.102, 821 "Technical Specification Group Services and System 822 Aspects; 3G Security; Security Architecture (Release 823 4)", 3rd Generation Partnership Project, December 824 2001. 826 7. Acknowledgements 828 The authors would like to thank Jim Bound, Brian Carpenter, Steve 829 Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, 830 Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing 831 list for their comments and input. 833 We would also like to thank David DeCamp, Karim El Malki, Markus 834 Isom�ki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu 835 and Shabnam Sultana for their comments and input in preparation of 836 this document. 838 8. Authors' Addresses 840 Jari Arkko 841 Ericsson 842 02420 Jorvas 843 Finland 845 Phone: +358 40 5079256 846 Fax: +358 40 2993401 847 E-Mail: Jari.Arkko@ericsson.com 849 Peter Hedman 850 Ericsson 851 SE-221 83 LUND 852 SWEDEN 854 Phone: +46 46 231760 855 Fax: +46 46 231650 856 E-mail: peter.hedman@emp.ericsson.se 857 Gerben Kuijpers 858 Ericsson 859 Skanderborgvej 232 860 DK-8260 Viby J 861 DENMARK 863 Phone: +45 89385100 864 Fax: +45 89385101 865 E-mail: gerben.a.kuijpers@ted.ericsson.se 867 Hesham Soliman 868 Ericsson Radio Systems AB 869 Torshamnsgatan 23, Kista, Stockholm 870 SWEDEN 872 Phone: +46 8 4046619 873 Fax: +46 8 4047020 874 E-mail: Hesham.Soliman@era.ericsson.se 876 John Loughney 877 Nokia Research Center 878 It�merenkatu 11 � 13 879 FIN-00180 HELSINKI 880 FINLAND 882 Phone: +358 7180 36242 883 Fax: +358 7180 36851 884 E-mail: john.loughney@nokia.com 886 Pertti Suomela 887 Nokia Mobile Phones 888 Sinitaival 5 889 FIN-33720 TAMPERE 890 Finland 892 Phone: +358 7180 40546 893 Fax: +358 7180 47518 894 E-mail: pertti.suomela@nokia.com 896 Juha Wiljakka 897 Nokia Mobile Phones 898 Sinitaival 5 899 FIN-33720 TAMPERE 900 Finland 902 Phone: +358 7180 47562 903 Fax: +358 7180 47518 904 E-mail: juha.wiljakka@nokia.com 906 Appendix A Revision History 908 Changes from draft-ietf-ipv6-cellular-host-01.txt: 910 - Additional clarification to the scope of the document. 911 - Additional text on Path MTU added. 912 - Additional explanation in section 2.5.1 913 - Additional text (chapter 2.3) to show that hosts need to be 914 able to send the fragmentation header. 915 - Discussion on the use of Privacy addresses added. 916 - Clarification on the use of DHCPv6 added. 917 - Additional text to clarify the use of DAD 918 - Removed some references to application-specific security 919 mechanisms in chapter 3. 920 - Removed the reference to MIPv6 from 2.8 921 - Clarified when MLD was needed in chapter 2.9 922 - Removed Appendix D and references to MIPv6 923 - Several editorial changes. 925 Appendix B Cellular Host IPv6 Addressing in the 3GPP Model 927 The appendix aims to very briefly describe the 3GPP IPv6 addressing 928 model for 2G (GPRS) and 3G (UMTS) cellular networks from Release 99 929 onwards. More information can be found from 3GPP Technical 930 Specification 23.060. 932 There are two possibilities to allocate the address for an IPv6 933 node: stateless and stateful autoconfiguration. The stateful address 934 allocation mechanism needs a DHCP server to allocate the address for 935 the IPv6 node. On the other hand, the stateless autoconfiguration 936 procedure does not need any external entity involved in the address 937 autoconfiguration (apart from the GGSN). 939 In order to support the standard IPv6 stateless address 940 autoconfiguration mechanism, as recommended by the IETF, the GGSN 941 shall assign a prefix that is unique within its scope to each 942 primary PDP context that uses IPv6 stateless address 943 autoconfiguration. This avoids the necessity to perform Duplicate 944 Address Detection at the network level for every address built by 945 the mobile host. The GGSN always provides an Interface Identifier to 946 the mobile host. The Mobile host uses the interface identifier 947 provided by the GGSN to generate its link-local address. Since the 948 GGSN provides the cellular host with the interface identifier, it 949 must ensure the uniqueness of such identifier on the link (I.e. no 950 collisions between its own link local address and the cellular 951 host's). 953 In addition, the GGSN will not use any of the prefixes assigned to 954 cellular hosts to generate any of its own addresses. 955 This use of the interface identifier, combined with the fact that 956 each PDP context is allocated a unique prefix, will eliminate the 957 need for DAD messages over the air interface, and consequently 958 allows an efficient use of bandwidth. Furthermore, the allocation of 959 a prefix to each PDP context will allow hosts to implement the 960 privacy extensions in RFC 3041 without the need for further DAD 961 messages. 963 Appendix C Transition Issues 965 IETF has specified a number of IPv4 / IPv6 transition mechanisms 966 [RFC-2893] to ensure smooth transition from IPv4 to IPv6 and 967 interoperability between IPv4 and IPv6 during the transition period. 968 The three main transition methods from a cellular network point of 969 view are dual IPv4 / IPv6 stacks, tunneling and protocol 970 translators, such as NAT-PT or SIIT. 972 It is recommended that cellular hosts have dual IPv4 / IPv6 stacks 973 to be able to interoperate with both IPv4 and IPv6 domains and use 974 both IPv6 and IPv4 applications / services. Tunneling (for example 975 RFC 3056 - Connection of IPv6 Domains via IPv4 Clouds) should be 976 carried out in the network. In addition, any protocol translation 977 function, such as NAT-PT, should be implemented in the network, not 978 in the cellular host. 980 The tunneling mechanism specified by [RFC-2529] is not relevant for 981 a cellular host. [RFC-2529] allows isolated IPv6-only hosts to 982 connect to an IPv6 router via an IPv4 domain. The scenario of an 983 IPv6-only host in an IPv4-only cellular network is considered 984 unlikely.