idnits 2.17.1 draft-korhonen-v6ops-rfc3316bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-6man-nd-extension-headers-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations (V6OPS) J. Korhonen, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Obsoletes: 3316 (if approved) J. Arkko, Ed. 5 Intended status: Informational Ericsson 6 Expires: April 18, 2013 T. Savolainen 7 Nokia 8 S. Krishnan 9 Ericsson 10 October 15, 2012 12 IPv6 for 3GPP Cellular Hosts 13 draft-korhonen-v6ops-rfc3316bis-00.txt 15 Abstract 17 As the deployment of third and fourth generation cellular networks 18 progresses, a large number of cellular hosts are being connected to 19 the Internet. Standardization organizations are making Internet 20 Protocol version 6 (IPv6) mandatory in their specifications. 21 However, the concept of IPv6 covers many aspects and numerous 22 specifications. In addition, the characteristics of cellular links 23 in terms of bandwidth, cost and delay put special requirements on how 24 IPv6 is used. This document considers IPv6 for cellular hosts that 25 attach to the General Packet Radio Service (GPRS), Universal Mobile 26 Telecommunications System (UMTS), or Evolved Packet System (EPS) 27 networks (Hereafter collectively referred to as 3GPP networks). This 28 document also lists out specific IPv6 functionality that needs to be 29 implemented in addition what is already prescribed in the IPv6 Node 30 Requirements document. It also discusses some issues relating to the 31 use of these components when operating in these networks. This 32 document obsoletes RFC 3316. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 18, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4 69 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 70 1.3. Cellular Host IPv6 Features . . . . . . . . . . . . . . . 6 71 2. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.1. Internet Protocol Version 6 . . . . . . . . . . . . . . . 7 73 2.2. Neighbor Discovery in 3GPP Networks . . . . . . . . . . . 7 74 2.3. IPv6 Stateless Address Autoconfiguration . . . . . . . . . 8 75 2.4. Stateless Address Autoconfiguration in 3GPP Networks . . . 8 76 2.5. IP version 6 over PPP in 3GPP Networks . . . . . . . . . . 9 77 2.6. MLD in 3GPP Networks . . . . . . . . . . . . . . . . . . . 9 78 2.7. Privacy Extensions for Address Configuration in IPv6 . . . 9 79 2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10 80 2.9. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10 81 2.10. Router preferences and more specific routes . . . . . . . 10 82 2.11. Neighbor Discovery and additional host configuration . . . 10 83 3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.1. Extension header considerations . . . . . . . . . . . . . 11 85 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14 91 8.2. Informative references . . . . . . . . . . . . . . . . . . 14 92 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 15 93 Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 16 94 B.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 Technologies such as GPRS (General Packet Radio Service), UMTS 100 (Universal Mobile Telecommunications System), Evolved Packet System 101 (EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD 102 (Enhanced High Rate Packet Data) are making it possible for cellular 103 hosts to have an always-on connection to the Internet. IPv6 104 [RFC2460] has become essential to such networks as the number of such 105 cellular hosts is increasing rapidly. Standardization organizations 106 working with cellular technologies have recognized this and made IPv6 107 mandatory in their specifications. 109 Support for IPv6 and the introduction of UMTS started with 3GPP 110 Release-99 networks and hosts. For detailed description of IPv6 in 111 3GPP networks including the Evolved Packet System, see [RFC6459]. 113 1.1. Scope of this Document 115 For the purposes of this document, a cellular interface is considered 116 to be the interface to a cellular access network based on the 117 following standards: 3GPP GPRS and UMTS Release-99, Release-4 to 118 Release-11, and EPS Release-8 to Release-11 as well as future UMTS or 119 EPS releases. A cellular host is considered to be a host with such a 120 cellular interface. 122 This document complements the IPv6 node requirements [RFC6434] in 123 places where clarifications are needed with discussion on the use of 124 these selected IPv6 specifications when operating over cellular 125 interfaces. Such a specification is necessary in order for the 126 optimal use of IPv6 in a cellular environment. The description is 127 made from a cellular host point of view. Complementary access 128 technologies may be available in the cellular host, but those are not 129 discussed in detail. Important considerations are given in order to 130 eliminate unnecessary user confusion over configuration options, 131 ensure interoperability and to provide an easy reference for those 132 implementing IPv6 in a cellular host. It is necessary to ensure that 133 cellular hosts are good citizens of the Internet. 135 This document is informational in nature, and it is not intended to 136 replace, update, or contradict any IPv6 standards documents or the 137 IPv6 node requirements [RFC6434]. 139 This document is mainly targeted towards the implementers of cellular 140 hosts that will be used with the cellular networks listed in the 141 scope. The document provides guidance on which IPv6 related 142 specifications are to be implemented in such cellular hosts. Parts 143 of this document may also apply to other cellular link types, but 144 this document does not provide any detailed analysis on other link 145 types. This document should not be used as a definitive list of IPv6 146 functionality for cellular links other than those listed above. 147 Future changes in 3GPP networks that impact host implementations may 148 result in updates to this document. 150 There are different ways to implement cellular hosts: 152 o The host can be a "closed" device with optimized applications, 153 with no possibility to add or download applications that can have 154 IP communications. An example of such a host is a very simple 155 form of a mobile phone. 156 o The host can be an open device, e.g., a "smart phone" where it is 157 possible to download applications to expand the functionality of 158 the device. 159 o The cellular radio modem part can be separated from the host IP 160 stack with an interface. On example of such host is a laptop 161 computer that uses a USB cellular modem for the cellular access. 163 If a cellular host has additional interfaces on which IP is used, 164 (such as Ethernet, WLAN, Bluetooth, etc.) then there may be 165 additional requirements for the device, beyond what is discussed in 166 this document. Additionally, this document does not make any 167 recommendations on the functionality required on laptop computers 168 having a cellular interface such as an embedded modem or a USB modem 169 stick, other than recommending link specific behavior on the cellular 170 link. 172 This document discusses IPv6 functionality as of the time when this 173 document has been written. Ongoing work on IPv6 may affect what is 174 required of future hosts. 176 Transition mechanisms used by cellular hosts are not described in 177 this document and are left for further study. The primary transition 178 mechanism supported by 3GPP is dual-stack [RFC4213]. Dual-stack 179 capable bearers were added to GPRS starting from 3GPP Release-9 and 180 to EPS starting from Release-8 [RFC6459], whereas in earlier releases 181 3GPP multiple single IP version bearers had to be used to support 182 dual stack. 184 1.2. Abbreviations 186 2G Second Generation Mobile Telecommunications, such as GSM and 187 GPRS technologies. 188 3G Third Generation Mobile Telecommunications, such as UMTS 189 technology. 191 4G Fourth Generation Mobile Telecommunications, such as LTE 192 technology. 193 3GPP 3rd Generation Partnership Project. Throughout the document, 194 the term 3GPP (3rd Generation Partnership Project) networks 195 refers to architectures standardized by 3GPP, in Second, Third 196 and Fourth Generation releases: 99, 4, and 5, as well as future 197 releases. 198 APN Access Point Name. The APN is a logical name referring to a 199 GGSN and/or a PGW, and an external network. 200 EPC Evolved Packet Core. 201 EPS Evolved Packet System. 202 ESP Encapsulating Security Payload 203 GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 204 cellular hosts in GPRS). 205 GPRS General Packet Radio Service. 206 LTE Long Term Evolution. 207 MT Mobile Terminal, for example, a mobile phone handset. 208 MTU Maximum Transmission Unit. 209 PDN Packet Data Network. 210 PDP Packet Data Protocol. 211 PGW Packet Data Network Gateway (the default router for 3GPP IPv6 212 cellular hosts in EPS). 213 SGW Serving Gateway. The user plane equivalent of an SGSN in EPS 214 (and the default router for 3GPP IPv6 cellular hosts when using 215 PMIPv6). 216 TE Terminal Equipment, for example, a laptop attached through a 217 3GPP handset. 218 UMTS Universal Mobile Telecommunications System. 219 WLAN Wireless Local Area Network. 221 1.3. Cellular Host IPv6 Features 223 This specification defines IPv6 features for cellular hosts in three 224 groups. 226 Basic IP 228 In this group, basic parts of IPv6 are described. 230 IP Security 232 In this group, the IP Security parts are described. 234 Mobility 236 In this group, IP layer mobility issues are described. 238 2. Basic IP 240 For most parts refer to the IPv6 Node Requirements document 241 [RFC6434]. 243 2.1. Internet Protocol Version 6 245 The Internet Protocol Version 6 (IPv6) is specified in [RFC2460]. 246 This specification is a mandatory part of IPv6. A cellular host must 247 conform the generic IPv6 Host Requirements [RFC6434], unless 248 specifically pointed out otherwise in this document. 250 2.2. Neighbor Discovery in 3GPP Networks 252 A cellular host must support Neighbor Solicitation and Neighbor 253 Advertisement messages. Some further notes on how these are applied 254 in the particular type of an interface can be useful, however: 256 In GPRS, UMTS and EPS networks, some Neighbor Discovery messages can 257 be unnecessary in certain cases. GPRS, UMTS and EPS links resemble a 258 point- to-point link; hence, the cellular host's only neighbor on the 259 cellular link is the default router that is already known through 260 Router Discovery. The cellular host always solicits for routers when 261 the cellular interface is enabled (as described in [RFC4861], Section 262 6.3.7). 264 There are no link layer addresses. Therefore, address resolution and 265 next-hop determination are not needed. If the cellular host still 266 attempts the address resolution e.g., for the default router, it must 267 be understood that the GGSN/PGW may not even answer the address 268 resolution Neighbor Solicitations. And even if it does, the Neighbor 269 Advertisement is unlikely to contain the Target link-layer address 270 option as there are no link-layer addresses. 272 The cellular host must support Neighbor Unreachability Detection 273 (NUD) as specified in [RFC4861]. Note that the link-layer address 274 considerations above also apply to the Neighbor Unreachability 275 Detection. The NUD triggered Neighbor Advertisement is also unlikely 276 to contain the Target link-layer address option as there are no link- 277 layer addresses. 279 In GPRS, UMTS and EPS networks, it is very desirable to reduce any 280 additional periodic signaling. Therefore, the cellular host should 281 include a mechanism in upper layer protocols to provide reachability 282 confirmations when two-way IP layer reachability can be confirmed 283 (see [RFC4861], Section 7.3.1). These confirmations would allow the 284 suppression of NUD-related messages in most cases. 286 Host TCP implementation should provide reachability confirmation in 287 the manner explained in [RFC4861], Section 7.3.1. 289 The widespread use of UDP in 3GPP networks poses a problem for 290 providing reachability confirmation. As UDP itself is unable to 291 provide such confirmation, applications running on top of UDP should 292 provide the confirmation where possible. In particular, when UDP is 293 used for transporting DNS, the DNS response should be used as a basis 294 for reachability confirmation. Similarly, when UDP is used to 295 transport RTP, the RTCP protocol feedback should be used as a basis 296 for the reachability confirmation. If an RTCP packet is received 297 with a reception report block indicating some packets have gone 298 through, then packets are reaching the peer. If they have reached 299 the peer, they have also reached the neighbor. 301 When UDP is used for transporting SIP, responses to SIP requests 302 should be used as the confirmation that packets sent to the peer are 303 reaching it. When the cellular host is acting as the server side SIP 304 node, no such confirmation is generally available. However, a host 305 may interpret the receipt of a SIP ACK request as confirmation that 306 the previously sent response to a SIP INVITE request has reached the 307 peer. 309 2.3. IPv6 Stateless Address Autoconfiguration 311 IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. 312 This specification is a mandatory part of IPv6 and also the only 313 mandatory method to configure an IPv6 address in a 3GPP cellular 314 host. 316 2.4. Stateless Address Autoconfiguration in 3GPP Networks 318 A cellular host in a 3GPP network must process a Router Advertisement 319 as stated in [RFC4862]. The Router Advertisement contains a maximum 320 of one prefix information option and the advertised prefix cannot 321 ever be used for on-link determination (see [RFC6459], Section 5.2). 323 Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, 324 as each delegated prefix is unique within its scope when advertised 325 using the 3GPP IPv6 Stateless Address Autoconfiguration. In 326 addition, the default router (GGSN/PGW) will not configure any 327 addresses on its interfaces based on prefixes advertised to IPv6 328 cellular hosts on those interfaces. Thus, the host is not required 329 to perform Duplicate Address Detection on the cellular interface. 331 Furthermore, the GGSN/PGW will provide the cellular host with an 332 interface identifier that must be used for link-local address 333 configuration. The link-local address configured from this interface 334 identifier is guaranteed not to collide with the link-local address 335 that the GGSN/PGW uses. Thus, the cellular host is not required to 336 perform Duplicate Address Detection for the link-local address either 337 on the cellular interface. 339 See Appendix A for more details on 3GPP IPv6 Stateless Address 340 Autoconfiguration. 342 2.5. IP version 6 over PPP in 3GPP Networks 344 A cellular host in a 3GPP network that supports PPP, must support the 345 IPv6CP interface identifier option. This option is needed to be able 346 to connect other devices to the Internet using a PPP link between the 347 cellular device (MT) and other devices (TE, e.g., a laptop). The MT 348 performs the PDP Context activation based on a request from the TE. 349 This results in an interface identifier being suggested by the MT to 350 the TE, using the IPv6CP option. To avoid any duplication in link- 351 local addresses between the TE and the GGSN/PGW, the MT must always 352 reject other suggested interface identifiers by the TE. This results 353 in the TE always using the interface identifier suggested by the GGSN 354 for its link-local address. 356 The rejection of interface identifiers suggested by the TE is only 357 done for creation of link-local addresses, according to 3GPP 358 specifications. The use of privacy addresses [RFC4941] for unique 359 local IPv6 unicast addresses (ULA) [RFC4193] and global addresses is 360 not affected by the above procedure. The above procedure is only 361 concerned with assigning the interface identifier used for forming 362 link-local addresses, and does not preclude TE from using other 363 interface identifiers for addresses with larger scopes (i.e., ULAs 364 and global). 366 2.6. MLD in 3GPP Networks 368 Within 3GPP networks, hosts connect to their default routers (GGSN/ 369 PGW) via point-to-point links. Moreover, there are exactly two IP 370 devices connected to the point-to-point link, and no attempt is made 371 (at the link-layer) to suppress the forwarding of multicast traffic. 372 Consequently, sending MLD reports for link-local addresses in a 3GPP 373 environment may not always be necessary. 375 MLD is needed for multicast group knowledge that is not link-local. 377 2.7. Privacy Extensions for Address Configuration in IPv6 379 Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] 380 should be supported. RFC 4941, and privacy in general, is important 381 for the Internet. Cellular hosts may use the temporary addresses as 382 described in RFC 4941. However, the use of the Privacy Extension in 383 an environment where IPv6 addresses are short-lived may not be 384 necessary. At the time this document has been written, there is no 385 experience on how long-lived cellular network address assignments 386 (i.e., attachments to the network) are. The length of the address 387 assignments depends upon many factors such as radio coverage, device 388 status and user preferences. Additionally, the use of temporary 389 address with IPsec may lead to more frequent renegotiation for the 390 Security Associations. 392 Refer to Section 7 for a discussion of the benefits of privacy 393 extensions in a 3GPP network. 395 2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 397 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 398 may be used. As of 3GPP Release-11 DHCPv6 is neither required nor 399 supported for address autoconfiguration. The IPv6 stateless 400 autoconfiguration still remains the only mandatory address 401 configuration method. However, DHCPv6 may be useful for other 402 configuration needs on a cellular host. e.g. Stateless DHCPv6 403 [RFC3736] may be used to configure DNS and SIP server addresses, and 404 DHCPv6 prefix delegation [RFC3633] may be used to delegate a prefix 405 to the cellular host for use on its non-cellular links. 407 2.9. DHCPv6 Prefix Delegation 409 Starting from Release-10 DHCPv6 Prefix Delegation was added as an 410 optional feature to the 3GPP system architecture [RFC3633]. The 411 prefix delegation model defined for Release-10 requires that the /64 412 IPv6 prefix assigned for the cellular host on the 3GPP link must 413 aggregate with the shorter delegated IPv6 prefix. The cellular host 414 should implement the Prefix Exclude Option for DHCPv6 Prefix 415 Delegation [RFC6603] (see [RFC6459], Section 5.3 for further 416 discussion). 418 2.10. Router preferences and more specific routes 420 The cellular host should implement the Default Router Preferences and 421 More-Specific Routes extension to extension to Router Advertisement 422 messages [RFC4191]. These options me be useful for cellular hosts 423 that also have additional interfaces on which IPv6 is used. 425 2.11. Neighbor Discovery and additional host configuration 427 The DNS server configuration is learned from 3GPP link layer 428 signaling. However, the cellular host should also implement the IPv6 429 Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6 430 is still optional for cellular hosts, and learning the DNS server 431 addresses from the link layer signaling can be cumbersome when the MT 432 and the TE are separated using other techniques than PPP interface. 434 The cellular host should also honor the MTU option in the Router 435 Advertisement (see [RFC4861], Section 4.6.4). 3GPP system 436 architecture uses extensive tunneling in its packet core network 437 below the 3GPP link and this may lead to packet fragmentation issues. 438 Therefore, the GGSN/PGW may propose a MTU to the cellular host that 439 takes the additional tunneling overhead into account. 441 3. IP Security 443 IPsec [RFC4301] is a fundamental but not mandatory part of IPv6. 444 Refer IPv6 Node Requirements Section 11 of [RFC6434] for the security 445 requirements that also apply to cellular hosts. 447 3.1. Extension header considerations 449 The support for the Routing Header Type 0 (RH0) has been deprecated 450 [RFC5095]. Therefore, the cellular host should as a default setting 451 follow the RH0 processing described in Section 3 of RFC 5095. 453 IPv6 packet fragmentation has known security concerns. The cellular 454 host must follow the handling of overlapping fragments as described 455 in [RFC5722] and the cellular host must not fragment any neighbor 456 discovery messages as described in 457 [I-D.ietf-6man-nd-extension-headers]. 459 4. Mobility 461 For the purposes of this document, IP mobility is not relevant. The 462 movement of cellular hosts within 3GPP networks is handled by link 463 layer mechanisms in majority of cases. 3GPP Release-8 introduced the 464 dual-stack Mobile IPv6 (DSMIPv6) for a client based mobility 465 [RFC5555]. Client based IP mobility is optional in 3GPP 466 architecture. 468 5. IANA Considerations 470 This document has no IANA actions. 472 6. Acknowledgements 474 The authors would like to thank the original authors for their 475 grounding work on this documents: Gerben Kuijpers, John Loughney, 476 Hesham Soliman and Juha Wiljakka. 478 The original RFC 3316 document was based on the results of a team 479 that included Peter Hedman and Pertti Suomela in addition to the 480 authors. Peter and Pertti have contributed both text and their IPv6 481 experience to this document. 483 The authors would like to thank Jim Bound, Brian Carpenter, Steve 484 Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, 485 Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing 486 list for their comments and input. 488 We would also like to thank David DeCamp, Karim El Malki, Markus 489 Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and 490 Shabnam Sultana for their comments and input in preparation of this 491 document. 493 7. Security Considerations 495 This document does not specify any new protocols or functionality, 496 and as such, it does not introduce any new security vulnerabilities. 497 However, specific profiles of IPv6 functionality are proposed for 498 different situations, and vulnerabilities may open or close depending 499 on which functionality is included and what is not. There are also 500 aspects of the cellular environment that make certain types of 501 vulnerabilities more severe. The following issues are discussed: 503 o The suggested limitations (Section 3.1) in the processing of 504 extension headers limits also exposure to Denial-of-Service (DoS) 505 attacks through cellular hosts. 506 o IPv6 addressing privacy [RFC4941] may be used in cellular hosts. 507 However, it should be noted that in the 3GPP model, the network 508 would assign new addresses, in most cases, to hosts in roaming 509 situations and typically, also when the cellular hosts activate a 510 PDP context. This means that 3GPP networks will already provide a 511 limited form of addressing privacy, and no global tracking of a 512 single host is possible through its address. On the other hand, 513 since a GGSN's coverage area is expected to be very large when 514 compared to currently deployed default routers (no handovers 515 between GGSNs are possible), a cellular host can keep an address 516 for a long time. Hence, IPv6 addressing privacy can be used for 517 additional privacy during the time the host is on and in the same 518 area. The privacy features can also be used to e.g., make 519 different transport sessions appear to come from different IP 520 addresses. However, it is not clear that these additional efforts 521 confuse potential observers any further, as they could monitor 522 only the network prefix part. 523 o The use of various security services such as IPsec or TLS in the 524 connection of typical applications in cellular hosts is discussed 525 in Section 3 and further pointer for recommendations are given 526 there. 527 o The airtime used by cellular hosts is expensive. In some cases, 528 users are billed according to the amount of data they transfer to 529 and from their host. It is crucial for both the network and the 530 users that the airtime is used correctly and no extra charges are 531 applied to users due to misbehaving third parties. The cellular 532 links also have a limited capacity, which means that they may not 533 necessarily be able to accommodate more traffic than what the user 534 selected, such as a multimedia call. Additional traffic might 535 interfere with the service level experienced by the user. While 536 Quality of Service mechanisms mitigate these problems to an 537 extent, it is still apparent that DoS aspects may be highlighted 538 in the cellular environment. It is possible for existing DoS 539 attacks that use for instance packet amplification to be 540 substantially more damaging in this environment. How these 541 attacks can be protected against is still an area of further 542 study. It is also often easy to fill the cellular link and queues 543 on both sides with additional or large packets. 544 o Within some service provider networks, it is possible to buy a 545 prepaid cellular subscription without presenting personal 546 identification. Attackers that wish to remain unidentified could 547 leverage this. Note that while the user hasn't been identified, 548 the equipment still is; the operators can follow the identity of 549 the device and block it from further use. The operators must have 550 procedures in place to take notice of third party complaints 551 regarding the use of their customers' devices. It may also be 552 necessary for the operators to have attack detection tools that 553 enable them to efficiently detect attacks launched from the 554 cellular hosts. 555 o Cellular devices that have local network interfaces (such as WLAN 556 or Bluetooth) may be used to launch attacks through them, unless 557 the local interfaces are secured in an appropriate manner. 558 Therefore, local network interfaces should have access control to 559 prevent others from using the cellular host as an intermediary. 560 o The 3GPP link model mitigates most of the known IPv6 on-link and 561 neighbor cache targeted attacks (see Section 2.2 and Appendix A). 562 o Advice for implementations in the face of Neighbor Discovery DoS 563 attacks may be useful in some environments [RFC6583]. 564 o Section 9 of RFC 6459 discusses further some recent concerns 565 related to cellular hosts security. 567 8. References 569 8.1. Normative references 571 [I-D.ietf-6man-nd-extension-headers] 572 Gont, F., "Security Implications of the Use of IPv6 573 Extension Headers with IPv6 Neighbor Discovery", 574 draft-ietf-6man-nd-extension-headers-00 (work in 575 progress), June 2012. 577 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 578 (IPv6) Specification", RFC 2460, December 1998. 580 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 581 for IPv6 Hosts and Routers", RFC 4213, October 2005. 583 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 584 Internet Protocol", RFC 4301, December 2005. 586 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 587 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 588 September 2007. 590 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 591 Address Autoconfiguration", RFC 4862, September 2007. 593 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 594 Extensions for Stateless Address Autoconfiguration in 595 IPv6", RFC 4941, September 2007. 597 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 598 of Type 0 Routing Headers in IPv6", RFC 5095, 599 December 2007. 601 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 602 RFC 5722, December 2009. 604 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 605 Requirements", RFC 6434, December 2011. 607 8.2. Informative references 609 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 610 and M. Carney, "Dynamic Host Configuration Protocol for 611 IPv6 (DHCPv6)", RFC 3315, July 2003. 613 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 614 Host Configuration Protocol (DHCP) version 6", RFC 3633, 615 December 2003. 617 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 618 (DHCP) Service for IPv6", RFC 3736, April 2004. 620 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 621 More-Specific Routes", RFC 4191, November 2005. 623 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 624 Addresses", RFC 4193, October 2005. 626 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 627 Routers", RFC 5555, June 2009. 629 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 630 "IPv6 Router Advertisement Options for DNS Configuration", 631 RFC 6106, November 2010. 633 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 634 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 635 Partnership Project (3GPP) Evolved Packet System (EPS)", 636 RFC 6459, January 2012. 638 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 639 Neighbor Discovery Problems", RFC 6583, March 2012. 641 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 642 "Prefix Exclude Option for DHCPv6-based Prefix 643 Delegation", RFC 6603, May 2012. 645 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model 647 The appendix aims to very briefly describe the 3GPP IPv6 addressing 648 model for 2G (GPRS), 3G (UMTS) and 4G (EPS) cellular networks from 649 Release-99 onwards. More information for 2G and 3G can be found from 650 3GPP Technical Specifications 23.060 and T29.061. The equivalent 651 documentation for 4G can be found from 3GPP Technical Specifications 652 23.401, 23.402 and 29.061. 654 There are two possibilities to allocate the address for an IPv6 node: 655 stateless and stateful autoconfiguration. The stateful address 656 allocation mechanism needs a DHCP server to allocate the address for 657 the IPv6 node. On the other hand, the stateless autoconfiguration 658 procedure does not need any external entity involved in the address 659 autoconfiguration (apart from the GGSN/PGW). At the time of writing 660 this document, the IPv6 stateless address autoconfiguration mechanism 661 is still the only madatory and supported address configuration method 662 for the cellular 3GPP link. 664 In order to support the standard IPv6 stateless address 665 autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW 666 shall assign a prefix that is unique within its scope to each primary 667 PDP context that uses IPv6 stateless address autoconfiguration. This 668 avoids the necessity to perform Duplicate Address Detection (DAD) at 669 the network level for every address built by the mobile host. The 670 GGSN/PGW always provides an Interface Identifier to the mobile host. 671 The Mobile host uses the interface identifier provided by the GGSN to 672 generate its link-local address. The GGSN/PGW provides the cellular 673 host with the interface identifier, usually in a random manner. It 674 must ensure the uniqueness of such identifier on the link (i.e., no 675 collisions between its own link-local address and the cellular 676 host's). 678 In addition, the GGSN/PGW will not use any of the prefixes assigned 679 to cellular hosts to generate any of its own addresses. This use of 680 the interface identifier, combined with the fact that each PDP 681 Context or PDN Connection is allocated a unique prefix, will 682 eliminate the need for DAD messages over the air interface, and 683 consequently reduces inefficient use of radio resources. 684 Furthermore, the allocation of a prefix to each PDP context will 685 allow hosts to implement the privacy extensions in RFC 4941 without 686 the need for further DAD messages. 688 In practice, the GGSN/PGW only needs to route all traffic to the 689 cellular host that fall under the prefix assigned to it. This 690 implies the GGSN/PGW may implement a minimal neighbor discovery 691 protocol subset; since, due the point-to-point link model and the 692 absence of link-layer addressing the address resolution can be 693 entirely statically configured per PDP Context or PDN Connection, and 694 there is no need to defend any other address than the link-local 695 address for very unlikely duplicates. 697 See Sections 5 of RFC 6459 for further discussion on 3GPP address 698 allocation and link model. 700 Appendix B. Changes to RFC 3316 702 B.1. Version -00 704 o Removal of all sections that can be directly found from RFC 6434. 705 o Clarifications to 3GPP link model and how Neighbor Discovery works 706 on it. 708 o Addition of RFC 4191 recommendations. 709 o Addition of DHCPv6-based Prefix Delegation recommendations. 710 o Addition of RFC 6106 recommendations. 711 o Addition of RFC 5555 regarding client based mobility. 712 o Addition of Router Advertisement MTU option handling. 713 o Addition of Evolved Packet System text. 714 o Clarification on the primary 3GPP IPv6 transition mechanism. 715 o Addition of RFC 5095 that deprecates the RH0 716 o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers 717 regarding the IPv6 fragmentation handling. 718 o Addition of RFC 6583 for Neighbor Discovery denial-of-service 719 attack considerations. 720 o Made the PPP IPV6CP support text conditional. 722 Authors' Addresses 724 Jouni Korhonen (editor) 725 Nokia Siemens Networks 726 Linnoitustie 6 727 FIN-02600 Espoo 728 Finland 730 Email: jouni.nospam@gmail.com 732 Jari Arkko (editor) 733 Ericsson 734 Jorvas 02420 735 Finland 737 Email: jari.arkko@piuha.net 739 Teemu Savolainen 740 Nokia 741 Hermiankatu 12 D 742 FI-33720 Tampere 743 FINLAND 745 Email: teemu.savolainen@nokia.com 746 Suresh Krishnan 747 Ericsson 748 8400 Decarie Blvd. 749 Town of Mount Royal, QC 750 Canada 752 Phone: +1 514 345 7900 x42871 753 Email: suresh.krishnan@ericsson.com