idnits 2.17.1 draft-ietf-v6ops-rfc3316bis-01.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 (February 25, 2013) is 4078 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-03 ** 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 Renesas Mobile 4 Obsoletes: 3316 (if approved) J. Arkko, Ed. 5 Intended status: Informational Ericsson 6 Expires: August 29, 2013 T. Savolainen 7 Nokia 8 S. Krishnan 9 Ericsson 10 February 25, 2013 12 IPv6 for 3GPP Cellular Hosts 13 draft-ietf-v6ops-rfc3316bis-01.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 August 29, 2013. 50 Copyright Notice 52 Copyright (c) 2013 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 . . . 10 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 . . . 11 83 3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.1. Extension header considerations . . . . . . . . . . . . . 11 85 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14 91 8.2. Informative references . . . . . . . . . . . . . . . . . . 15 92 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 15 93 Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17 94 B.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 17 95 B.2. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 Technologies such as GPRS (General Packet Radio Service), UMTS 101 (Universal Mobile Telecommunications System), Evolved Packet System 102 (EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD 103 (Enhanced High Rate Packet Data) are making it possible for cellular 104 hosts to have an always-on connection to the Internet. IPv6 105 [RFC2460] has become essential to such networks as the number of such 106 cellular hosts is increasing rapidly. Standardization organizations 107 working with cellular technologies have recognized this and made IPv6 108 mandatory in their specifications. 110 Support for IPv6 and the introduction of UMTS started with 3GPP 111 Release-99 networks and hosts. For detailed description of IPv6 in 112 3GPP networks including the Evolved Packet System, see [RFC6459]. 114 1.1. Scope of this Document 116 For the purposes of this document, a cellular interface is considered 117 to be the interface to a cellular access network based on the 118 following standards: 3GPP GPRS and UMTS Release-99, Release-4 to 119 Release-11, and EPS Release-8 to Release-11 as well as future UMTS or 120 EPS releases. A cellular host is considered to be a host with such a 121 cellular interface. 123 This document complements the IPv6 node requirements [RFC6434] in 124 places where clarifications are needed with discussion on the use of 125 these selected IPv6 specifications when operating over cellular 126 interfaces. Such a specification is necessary in order for the 127 optimal use of IPv6 in a cellular environment. The description is 128 made from a cellular host point of view. Complementary access 129 technologies may be available in the cellular host, but those are not 130 discussed in detail. Important considerations are given in order to 131 eliminate unnecessary user confusion over configuration options, 132 ensure interoperability and to provide an easy reference for those 133 implementing IPv6 in a cellular host. It is necessary to ensure that 134 cellular hosts are good citizens of the Internet. 136 This document is informational in nature, and it is not intended to 137 replace, update, or contradict any IPv6 standards documents or the 138 IPv6 node requirements [RFC6434]. 140 This document is mainly targeted towards the implementers of cellular 141 hosts that will be used with the cellular networks listed in the 142 scope. The document provides guidance on which IPv6 related 143 specifications are to be implemented in such cellular hosts. Parts 144 of this document may also apply to other cellular link types, but 145 this document does not provide any detailed analysis on other link 146 types. This document should not be used as a definitive list of IPv6 147 functionality for cellular links other than those listed above. 148 Future changes in 3GPP networks that impact host implementations may 149 result in updates to this document. 151 There are different ways to implement cellular hosts: 153 o The host can be a "closed" device with optimized applications, 154 with no possibility to add or download applications that can have 155 IP communications. An example of such a host is a very simple 156 form of a mobile phone. 157 o The host can be an open device, e.g., a "smart phone" where it is 158 possible to download applications to expand the functionality of 159 the device. 160 o The cellular radio modem part can be separated from the host IP 161 stack with an interface. On example of such host is a laptop 162 computer that uses a USB cellular modem for the cellular access. 164 If a cellular host has additional interfaces on which IP is used, 165 (such as Ethernet, WLAN, Bluetooth, etc.) then there may be 166 additional requirements for the device, beyond what is discussed in 167 this document. Additionally, this document does not make any 168 recommendations on the functionality required on laptop computers 169 having a cellular interface such as an embedded modem or a USB modem 170 stick, other than recommending link specific behavior on the cellular 171 link. 173 This document discusses IPv6 functionality as of the time when this 174 document has been written. Ongoing work on IPv6 may affect what is 175 required of future hosts. 177 Transition mechanisms used by cellular hosts are not described in 178 this document and are left for further study. The primary transition 179 mechanism supported by 3GPP is dual-stack [RFC4213]. Dual-stack 180 capable bearers were added to GPRS starting from 3GPP Release-9 and 181 to EPS starting from Release-8 [RFC6459], whereas in earlier releases 182 3GPP multiple single IP version bearers had to be used to support 183 dual stack. 185 1.2. Abbreviations 187 2G Second Generation Mobile Telecommunications, such as GSM and 188 GPRS technologies. 189 3G Third Generation Mobile Telecommunications, such as UMTS 190 technology. 192 4G Fourth Generation Mobile Telecommunications, such as LTE 193 technology. 194 3GPP 3rd Generation Partnership Project. Throughout the document, 195 the term 3GPP (3rd Generation Partnership Project) networks 196 refers to architectures standardized by 3GPP, in Second, Third 197 and Fourth Generation releases: 99, 4, and 5, as well as future 198 releases. 199 APN Access Point Name. The APN is a logical name referring to a 200 GGSN and/or a PGW, and an external network. 201 EPC Evolved Packet Core. 202 EPS Evolved Packet System. 203 ESP Encapsulating Security Payload 204 GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 205 cellular hosts in GPRS). 206 GPRS General Packet Radio Service. 207 LTE Long Term Evolution. 208 MT Mobile Terminal, for example, a mobile phone handset. 209 MTU Maximum Transmission Unit. 210 PDN Packet Data Network. 211 PDP Packet Data Protocol. 212 PGW Packet Data Network Gateway (the default router for 3GPP IPv6 213 cellular hosts in EPS). 214 SGW Serving Gateway. The user plane equivalent of an SGSN in EPS 215 (and the default router for 3GPP IPv6 cellular hosts when using 216 PMIPv6). 217 TE Terminal Equipment, for example, a laptop attached through a 218 3GPP handset. 219 UMTS Universal Mobile Telecommunications System. 220 WLAN Wireless Local Area Network. 222 1.3. Cellular Host IPv6 Features 224 This specification defines IPv6 features for cellular hosts in three 225 groups. 227 Basic IP 229 In this group, basic parts of IPv6 are described. 231 IP Security 233 In this group, the IP Security parts are described. 235 Mobility 237 In this group, IP layer mobility issues are described. 239 2. Basic IP 241 For most parts refer to the IPv6 Node Requirements document 242 [RFC6434]. 244 2.1. Internet Protocol Version 6 246 The Internet Protocol Version 6 (IPv6) is specified in [RFC2460]. 247 This specification is a mandatory part of IPv6. A cellular host must 248 conform the generic IPv6 Host Requirements [RFC6434], unless 249 specifically pointed out otherwise in this document. 251 2.2. Neighbor Discovery in 3GPP Networks 253 A cellular host must support Neighbor Solicitation and Neighbor 254 Advertisement messages. Some further notes on how these are applied 255 in the particular type of an interface can be useful, however: 257 In GPRS, UMTS and EPS networks, some Neighbor Discovery messages can 258 be unnecessary in certain cases. GPRS, UMTS and EPS links resemble a 259 point-to-point link; hence, the cellular host's only neighbor on the 260 cellular link is the default router that is already known through 261 Router Discovery. The cellular host always solicits for routers when 262 the cellular interface is enabled (as described in [RFC4861], Section 263 6.3.7). 265 There are no link layer addresses. Therefore, address resolution and 266 next-hop determination are not needed. If the cellular host still 267 attempts the address resolution e.g., for the default router, it must 268 be understood that the GGSN/PGW may not even answer the address 269 resolution Neighbor Solicitations. And even if it does, the Neighbor 270 Advertisement is unlikely to contain the Target link-layer address 271 option as there are no link-layer addresses. 273 The cellular host must support Neighbor Unreachability Detection 274 (NUD) as specified in [RFC4861]. Note that the link-layer address 275 considerations above also apply to the NUD. The NUD triggered 276 Neighbor Advertisement is also unlikely to contain the Target link- 277 layer address option as there are no link-layer addresses. The 278 cellular host should also be prepared for a router (i.e., GGSN/PGW) 279 initiated NUD. However, it is unlikely a router to host NUD should 280 ever take place on a GPRS, UMTS and EPS links. See Appendix A for 281 more discussion on the router to host NUD. 283 In GPRS, UMTS and EPS networks, it is very desirable to reduce any 284 additional periodic signaling. Therefore, the cellular host should 285 include a mechanism in upper layer protocols to provide reachability 286 confirmations when two-way IP layer reachability can be confirmed 287 (see [RFC4861], Section 7.3.1). These confirmations would allow the 288 suppression of NUD-related messages in most cases. 290 Host TCP implementation should provide reachability confirmation in 291 the manner explained in [RFC4861], Section 7.3.1. 293 The widespread use of UDP in 3GPP networks poses a problem for 294 providing reachability confirmation. As UDP itself is unable to 295 provide such confirmation, applications running on top of UDP should 296 provide the confirmation where possible. In particular, when UDP is 297 used for transporting DNS, the DNS response should be used as a basis 298 for reachability confirmation. Similarly, when UDP is used to 299 transport RTP, the RTCP protocol feedback should be used as a basis 300 for the reachability confirmation. If an RTCP packet is received 301 with a reception report block indicating some packets have gone 302 through, then packets are reaching the peer. If they have reached 303 the peer, they have also reached the neighbor. 305 When UDP is used for transporting SIP, responses to SIP requests 306 should be used as the confirmation that packets sent to the peer are 307 reaching it. When the cellular host is acting as the server side SIP 308 node, no such confirmation is generally available. However, a host 309 may interpret the receipt of a SIP ACK request as confirmation that 310 the previously sent response to a SIP INVITE request has reached the 311 peer. 313 2.3. IPv6 Stateless Address Autoconfiguration 315 IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. 316 This specification is a mandatory part of IPv6 and also the only 317 mandatory method to configure an IPv6 address in a 3GPP cellular 318 host. 320 2.4. Stateless Address Autoconfiguration in 3GPP Networks 322 A cellular host in a 3GPP network must process a Router Advertisement 323 as stated in [RFC4862]. The Router Advertisement contains a maximum 324 of one prefix information option and the advertised prefix cannot 325 ever be used for on-link determination (see [RFC6459], Section 5.2). 327 Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, 328 as each delegated prefix is unique within its scope when advertised 329 using the 3GPP IPv6 Stateless Address Autoconfiguration. In 330 addition, the default router (GGSN/PGW) will not configure any 331 addresses on its interfaces based on prefixes advertised to IPv6 332 cellular hosts on those interfaces. Thus, the host is not required 333 to perform Duplicate Address Detection on the cellular interface. 335 Furthermore, the GGSN/PGW will provide the cellular host with an 336 interface identifier that must be used for link-local address 337 configuration. The link-local address configured from this interface 338 identifier is guaranteed not to collide with the link-local address 339 that the GGSN/PGW uses. Thus, the cellular host is not required to 340 perform Duplicate Address Detection for the link-local address either 341 on the cellular interface. 343 See Appendix A for more details on 3GPP IPv6 Stateless Address 344 Autoconfiguration. 346 2.5. IP version 6 over PPP in 3GPP Networks 348 A cellular host in a 3GPP network that supports PPP, must support the 349 IPv6CP interface identifier option. This option is needed to be able 350 to connect other devices to the Internet using a PPP link between the 351 cellular device (MT) and other devices (TE, e.g., a laptop). The MT 352 performs the PDP Context activation based on a request from the TE. 353 This results in an interface identifier being suggested by the MT to 354 the TE, using the IPv6CP option. To avoid any duplication in link- 355 local addresses between the TE and the GGSN/PGW, the MT must always 356 reject other suggested interface identifiers by the TE. This results 357 in the TE always using the interface identifier suggested by the GGSN 358 for its link-local address. 360 The rejection of interface identifiers suggested by the TE is only 361 done for creation of link-local addresses, according to 3GPP 362 specifications. The use of privacy addresses [RFC4941] for unique 363 local IPv6 unicast addresses (ULA) [RFC4193] and global addresses is 364 not affected by the above procedure. The above procedure is only 365 concerned with assigning the interface identifier used for forming 366 link-local addresses, and does not preclude TE from using other 367 interface identifiers for addresses with larger scopes (i.e., ULAs 368 and global). 370 2.6. MLD in 3GPP Networks 372 Within 3GPP networks, hosts connect to their default routers (GGSN/ 373 PGW) via point-to-point links. Moreover, there are exactly two IP 374 devices connected to the point-to-point link, and no attempt is made 375 (at the link-layer) to suppress the forwarding of multicast traffic. 376 Consequently, sending MLD reports for link-local addresses in a 3GPP 377 environment may not always be necessary. 379 MLD is needed for multicast group knowledge that is not link-local. 381 2.7. Privacy Extensions for Address Configuration in IPv6 383 Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] 384 should be supported. RFC 4941, and privacy in general, is important 385 for the Internet. Cellular hosts may use the temporary addresses as 386 described in RFC 4941. However, the use of the Privacy Extension in 387 an environment where IPv6 addresses are short-lived may not be 388 necessary. At the time this document has been written, there is no 389 experience on how long-lived cellular network address assignments 390 (i.e., attachments to the network) are. The length of the address 391 assignments depends upon many factors such as radio coverage, device 392 status and user preferences. Additionally, the use of temporary 393 address with IPsec may lead to more frequent renegotiation for the 394 Security Associations. 396 Refer to Section 7 for a discussion of the benefits of privacy 397 extensions in a 3GPP network. 399 2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 401 As of 3GPP Release-11 The Dynamic Host Configuration Protocol for 402 IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address 403 autoconfiguration. The IPv6 stateless autoconfiguration still 404 remains the only mandatory address configuration method. However, 405 DHCPv6 may be useful for other configuration needs on a cellular 406 host. e.g. Stateless DHCPv6 [RFC3736] may be used to configure DNS 407 and SIP server addresses, and DHCPv6 prefix delegation [RFC3633] may 408 be used to delegate a prefix to the cellular host for use on its 409 downstream non-cellular links. 411 2.9. DHCPv6 Prefix Delegation 413 Starting from Release-10 DHCPv6 Prefix Delegation was added as an 414 optional feature to the 3GPP system architecture [RFC3633]. The 415 prefix delegation model defined for Release-10 requires that the /64 416 IPv6 prefix assigned for the cellular host on the 3GPP link must 417 aggregate with the shorter delegated IPv6 prefix. The cellular host 418 should implement the Prefix Exclude Option for DHCPv6 Prefix 419 Delegation [RFC6603] (see [RFC6459], Section 5.3 for further 420 discussion). 422 2.10. Router preferences and more specific routes 424 The cellular host should implement the Default Router Preferences and 425 More-Specific Routes extension to extension to Router Advertisement 426 messages [RFC4191]. These options me be useful for cellular hosts 427 that also have additional interfaces on which IPv6 is used. 429 2.11. Neighbor Discovery and additional host configuration 431 The DNS server configuration is learned from 3GPP link layer 432 signaling. However, the cellular host should also implement the IPv6 433 Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6 434 is still optional for cellular hosts, and learning the DNS server 435 addresses from the link layer signaling can be cumbersome when the MT 436 and the TE are separated using other techniques than PPP interface. 438 The cellular host should also honor the MTU option in the Router 439 Advertisement (see [RFC4861], Section 4.6.4). 3GPP system 440 architecture uses extensive tunneling in its packet core network 441 below the 3GPP link and this may lead to packet fragmentation issues. 442 Therefore, the GGSN/PGW may propose a MTU to the cellular host that 443 takes the additional tunneling overhead into account. 445 3. IP Security 447 IPsec [RFC4301] is a fundamental but not mandatory part of IPv6. 448 Refer IPv6 Node Requirements Section 11 of [RFC6434] for the security 449 requirements that also apply to cellular hosts. 451 3.1. Extension header considerations 453 The support for the Routing Header Type 0 (RH0) has been deprecated 454 [RFC5095]. Therefore, the cellular host should as a default setting 455 follow the RH0 processing described in Section 3 of RFC 5095. 457 IPv6 packet fragmentation has known security concerns. The cellular 458 host must follow the handling of overlapping fragments as described 459 in [RFC5722] and the cellular host must not fragment any neighbor 460 discovery messages as described in 461 [I-D.ietf-6man-nd-extension-headers]. 463 4. Mobility 465 For the purposes of this document, IP mobility is not relevant. The 466 movement of cellular hosts within 3GPP networks is handled by link 467 layer mechanisms in majority of cases. 3GPP Release-8 introduced the 468 dual-stack Mobile IPv6 (DSMIPv6) for a client based mobility 469 [RFC5555]. Client based IP mobility is optional in 3GPP 470 architecture. 472 5. IANA Considerations 474 This document has no IANA actions. 476 6. Acknowledgements 478 The authors would like to thank the original authors for their 479 grounding work on this documents: Gerben Kuijpers, John Loughney, 480 Hesham Soliman and Juha Wiljakka. 482 The original RFC 3316 document was based on the results of a team 483 that included Peter Hedman and Pertti Suomela in addition to the 484 authors. Peter and Pertti have contributed both text and their IPv6 485 experience to this document. 487 The authors would like to thank Jim Bound, Brian Carpenter, Steve 488 Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, 489 Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing 490 list for their comments and input. 492 We would also like to thank David DeCamp, Karim El Malki, Markus 493 Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and 494 Shabnam Sultana for their comments and input in preparation of this 495 document. 497 7. Security Considerations 499 This document does not specify any new protocols or functionality, 500 and as such, it does not introduce any new security vulnerabilities. 501 However, specific profiles of IPv6 functionality are proposed for 502 different situations, and vulnerabilities may open or close depending 503 on which functionality is included and what is not. There are also 504 aspects of the cellular environment that make certain types of 505 vulnerabilities more severe. The following issues are discussed: 507 o The suggested limitations (Section 3.1) in the processing of 508 extension headers limits also exposure to Denial-of-Service (DoS) 509 attacks through cellular hosts. 510 o IPv6 addressing privacy [RFC4941] may be used in cellular hosts. 511 However, it should be noted that in the 3GPP model, the network 512 would assign new addresses, in most cases, to hosts in roaming 513 situations and typically, also when the cellular hosts activate a 514 PDP Context or a PDN Connection. This means that 3GPP networks 515 will already provide a limited form of addressing privacy, and no 516 global tracking of a single host is possible through its address. 517 On the other hand, since a GGSN's coverage area is expected to be 518 very large when compared to currently deployed default routers (no 519 handovers between GGSNs are possible), a cellular host can keep an 520 address for a long time. Hence, IPv6 addressing privacy can be 521 used for additional privacy during the time the host is on and in 522 the same area. The privacy features can also be used to e.g., 523 make different transport sessions appear to come from different IP 524 addresses. However, it is not clear that these additional efforts 525 confuse potential observers any further, as they could monitor 526 only the network prefix part. 527 o The use of various security services such as IPsec or TLS in the 528 connection of typical applications in cellular hosts is discussed 529 in Section 3 and further pointer for recommendations are given 530 there. 531 o The airtime used by cellular hosts is expensive. In some cases, 532 users are billed according to the amount of data they transfer to 533 and from their host. It is crucial for both the network and the 534 users that the airtime is used correctly and no extra charges are 535 applied to users due to misbehaving third parties. The cellular 536 links also have a limited capacity, which means that they may not 537 necessarily be able to accommodate more traffic than what the user 538 selected, such as a multimedia call. Additional traffic might 539 interfere with the service level experienced by the user. While 540 Quality of Service mechanisms mitigate these problems to an 541 extent, it is still apparent that DoS aspects may be highlighted 542 in the cellular environment. It is possible for existing DoS 543 attacks that use for instance packet amplification to be 544 substantially more damaging in this environment. How these 545 attacks can be protected against is still an area of further 546 study. It is also often easy to fill the cellular link and queues 547 on both sides with additional or large packets. 548 o Within some service provider networks, it is possible to buy a 549 prepaid cellular subscription without presenting personal 550 identification. Attackers that wish to remain unidentified could 551 leverage this. Note that while the user hasn't been identified, 552 the equipment still is; the operators can follow the identity of 553 the device and block it from further use. The operators must have 554 procedures in place to take notice of third party complaints 555 regarding the use of their customers' devices. It may also be 556 necessary for the operators to have attack detection tools that 557 enable them to efficiently detect attacks launched from the 558 cellular hosts. 559 o Cellular devices that have local network interfaces (such as WLAN 560 or Bluetooth) may be used to launch attacks through them, unless 561 the local interfaces are secured in an appropriate manner. 562 Therefore, local network interfaces should have access control to 563 prevent others from using the cellular host as an intermediary. 565 o The 3GPP link model mitigates most of the known IPv6 on-link and 566 neighbor cache targeted attacks (see Section 2.2 and Appendix A). 567 o Advice for implementations in the face of Neighbor Discovery DoS 568 attacks may be useful in some environments [RFC6583]. 569 o Section 9 of RFC 6459 discusses further some recent concerns 570 related to cellular hosts security. 572 8. References 574 8.1. Normative references 576 [I-D.ietf-6man-nd-extension-headers] 577 Gont, F., "Security Implications of IPv6 Fragmentation 578 with IPv6 Neighbor Discovery", 579 draft-ietf-6man-nd-extension-headers-03 (work in 580 progress), January 2013. 582 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 583 (IPv6) Specification", RFC 2460, December 1998. 585 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 586 for IPv6 Hosts and Routers", RFC 4213, October 2005. 588 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 589 Internet Protocol", RFC 4301, December 2005. 591 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 592 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 593 September 2007. 595 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 596 Address Autoconfiguration", RFC 4862, September 2007. 598 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 599 Extensions for Stateless Address Autoconfiguration in 600 IPv6", RFC 4941, September 2007. 602 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 603 of Type 0 Routing Headers in IPv6", RFC 5095, 604 December 2007. 606 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 607 RFC 5722, December 2009. 609 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 610 Requirements", RFC 6434, December 2011. 612 8.2. Informative references 614 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 615 and M. Carney, "Dynamic Host Configuration Protocol for 616 IPv6 (DHCPv6)", RFC 3315, July 2003. 618 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 619 Host Configuration Protocol (DHCP) version 6", RFC 3633, 620 December 2003. 622 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 623 (DHCP) Service for IPv6", RFC 3736, April 2004. 625 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 626 More-Specific Routes", RFC 4191, November 2005. 628 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 629 Addresses", RFC 4193, October 2005. 631 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 632 Routers", RFC 5555, June 2009. 634 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 635 "IPv6 Router Advertisement Options for DNS Configuration", 636 RFC 6106, November 2010. 638 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 639 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 640 Partnership Project (3GPP) Evolved Packet System (EPS)", 641 RFC 6459, January 2012. 643 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 644 Neighbor Discovery Problems", RFC 6583, March 2012. 646 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 647 "Prefix Exclude Option for DHCPv6-based Prefix 648 Delegation", RFC 6603, May 2012. 650 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model 652 The appendix aims to very briefly describe the 3GPP IPv6 addressing 653 model for 2G (GPRS), 3G (UMTS) and 4G (EPS) cellular networks from 654 Release-99 onwards. More information for 2G and 3G can be found from 655 3GPP Technical Specifications 23.060 and T29.061. The equivalent 656 documentation for 4G can be found from 3GPP Technical Specifications 657 23.401, 23.402 and 29.061. 659 There are two possibilities to allocate the address for an IPv6 node: 660 stateless and stateful autoconfiguration. The stateful address 661 allocation mechanism needs a DHCP server to allocate the address for 662 the IPv6 node. On the other hand, the stateless autoconfiguration 663 procedure does not need any external entity involved in the address 664 autoconfiguration (apart from the GGSN/PGW). At the time of writing 665 this document, the IPv6 stateless address autoconfiguration mechanism 666 is still the only mandatory and supported address configuration 667 method for the cellular 3GPP link. 669 In order to support the standard IPv6 stateless address 670 autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW 671 shall assign a single /64 IPv6 prefix that is unique within its scope 672 to each primary PDP Context or PDN Connection that uses IPv6 673 stateless address autoconfiguration. This avoids the necessity to 674 perform Duplicate Address Detection (DAD) at the network level for 675 every address built by the mobile host. The GGSN/PGW always provides 676 an interface identifier to the mobile host. The Mobile host uses the 677 interface identifier provided by the GGSN to generate its link-local 678 address. The GGSN/PGW provides the cellular host with the interface 679 identifier, usually in a random manner. It must ensure the 680 uniqueness of such identifier on the link (i.e., no collisions 681 between its own link-local address and the cellular host's). 683 In addition, the GGSN/PGW will not use any of the prefixes assigned 684 to cellular hosts to generate any of its own addresses. This use of 685 the interface identifier, combined with the fact that each PDP 686 Context or PDN Connection is allocated a unique prefix, will 687 eliminate the need for DAD messages over the air interface, and 688 consequently reduces inefficient use of radio resources. 689 Furthermore, the allocation of a prefix to each PDP context will 690 allow hosts to implement the privacy extensions in RFC 4941 without 691 the need for further DAD messages. 693 In practice, the GGSN/PGW only needs to route all traffic to the 694 cellular host that fall under the prefix assigned to it. This 695 implies the GGSN/PGW may implement a minimal neighbor discovery 696 protocol subset; since, due the point-to-point link model and the 697 absence of link-layer addressing the address resolution can be 698 entirely statically configured per PDP Context or PDN Connection, and 699 there is no need to defend any other address than the link-local 700 address for very unlikely duplicates. This has also an additional 701 effect on a router to host NUD. There is really no need for one, 702 since from the GGSN/PGW point of view it does not need to care for 703 single addresses, just route the whole prefix to the cellular host 704 direction. Furthermore, 3GPP specifications at the time of writing 705 this document are silent what should happen if the router to host NUD 706 fails. 708 See Sections 5 of RFC 6459 for further discussion on 3GPP address 709 allocation and link model. 711 Appendix B. Changes to RFC 3316 713 B.1. Version -01 715 o Additional clarification on NUD on 3GPP cellular links. 716 o Added an explicit note that the prefix on the link is /64. 717 o Clarified that DHCPv6 (RFC3315) is not used at all for address 718 autoconfiguration. 720 B.2. Version -00 722 o Removal of all sections that can be directly found from RFC 6434. 723 o Clarifications to 3GPP link model and how Neighbor Discovery works 724 on it. 725 o Addition of RFC 4191 recommendations. 726 o Addition of DHCPv6-based Prefix Delegation recommendations. 727 o Addition of RFC 6106 recommendations. 728 o Addition of RFC 5555 regarding client based mobility. 729 o Addition of Router Advertisement MTU option handling. 730 o Addition of Evolved Packet System text. 731 o Clarification on the primary 3GPP IPv6 transition mechanism. 732 o Addition of RFC 5095 that deprecates the RH0 733 o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers 734 regarding the IPv6 fragmentation handling. 735 o Addition of RFC 6583 for Neighbor Discovery denial-of-service 736 attack considerations. 737 o Made the PPP IPV6CP support text conditional. 739 Authors' Addresses 741 Jouni Korhonen (editor) 742 Renesas Mobile 743 Porkkalankatu 24 744 FIN-00180 Helsinki 745 Finland 747 Email: jouni.nospam@gmail.com 748 Jari Arkko (editor) 749 Ericsson 750 Jorvas 02420 751 Finland 753 Email: jari.arkko@piuha.net 755 Teemu Savolainen 756 Nokia 757 Hermiankatu 12 D 758 FI-33720 Tampere 759 FINLAND 761 Email: teemu.savolainen@nokia.com 763 Suresh Krishnan 764 Ericsson 765 8400 Decarie Blvd. 766 Town of Mount Royal, QC 767 Canada 769 Phone: +1 514 345 7900 x42871 770 Email: suresh.krishnan@ericsson.com