idnits 2.17.1 draft-ietf-v6ops-rfc3316bis-05.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 (September 14, 2013) is 3874 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 3316 (Obsoleted by RFC 7066) -- 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 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 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: March 18, 2014 T. Savolainen 7 Nokia 8 S. Krishnan 9 Ericsson 10 September 14, 2013 12 IPv6 for 3GPP Cellular Hosts 13 draft-ietf-v6ops-rfc3316bis-05.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 have made 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 functionalities that need to be 29 implemented in addition what is already prescribed in the IPv6 Node 30 Requirements document. It also discusses some issues related 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 March 18, 2014. 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. Stateless Address Autoconfiguration . . . . . . . . . . . 8 75 2.4. IP version 6 over PPP . . . . . . . . . . . . . . . . . . 9 76 2.5. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 10 77 2.6. Privacy Extensions for Address Configuration in IPv6 . . . 10 78 2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10 79 2.8. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10 80 2.9. Router preferences and more specific routes . . . . . . . 11 81 2.10. Neighbor Discovery and additional host configuration . . . 11 82 3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.1. Extension header considerations . . . . . . . . . . . . . 11 84 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14 90 8.2. Informative references . . . . . . . . . . . . . . . . . . 15 91 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 16 92 Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 Technologies such as GPRS (General Packet Radio Service), UMTS 98 (Universal Mobile Telecommunications System), Evolved Packet System 99 (EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD 100 (Enhanced High Rate Packet Data) are making it possible for cellular 101 hosts to have an always-on connection to the Internet. IPv6 102 [RFC2460] has become essential to such networks as the number of 103 cellular hosts is increasing rapidly. Standardization organizations 104 working with cellular technologies have recognized this and made IPv6 105 mandatory in their specifications. 107 Support for IPv6 and the introduction of UMTS started with 3GPP 108 Release-99 networks and hosts. For the detailed description of IPv6 109 in 3GPP networks including the Evolved Packet System, see [RFC6459]. 111 1.1. Scope of this Document 113 For the purpose of this document, a cellular interface is considered 114 to be the interface to a cellular access network based on the 115 following standards: 3GPP GPRS and UMTS Release-99, Release-4 to 116 Release-11, and EPS Release-8 to Release-11 as well as future UMTS or 117 EPS releases. A cellular host is considered to be a host with such a 118 cellular interface. 120 This document complements the IPv6 node requirements [RFC6434] in 121 places where clarifications are needed with discussion on the use of 122 these selected IPv6 specifications when operating over a cellular 123 interface. Such a specification is necessary in order to enable the 124 optimal use of IPv6 in a cellular network environment. The 125 description is made from a cellular host point of view. 126 Complementary access technologies may be supported by the cellular 127 host, but those are not discussed in detail. Important 128 considerations are given in order to eliminate unnecessary user 129 confusion over configuration options, ensure interoperability and to 130 provide an easy reference for those who are implementing IPv6 in a 131 cellular host. It is necessary to ensure that cellular hosts are 132 good citizens of the Internet. 134 This document is informational in its nature, and it is not intended 135 to replace, update, or contradict any IPv6 standards documents or the 136 IPv6 node requirements [RFC6434]. 138 This document is primarily targeted to the implementers of cellular 139 hosts that will be used with the cellular networks listed in the 140 scope. The document provides guidance on which IPv6 related 141 specifications are to be implemented in such cellular hosts. Parts 142 of this document may also apply to other cellular link types, but 143 this document does not provide any detailed analysis on other link 144 types. This document should not be used as a definitive list of IPv6 145 functionalies for cellular links other than those listed above. 146 Future changes in 3GPP networks that impact host implementations may 147 result in updates to this document. 149 There are different ways to implement cellular hosts: 151 o The host can be a "closed" device with optimized built-in 152 applications, with no possibility to add or download applications 153 that can have IP communications. An example of such a host is a 154 very simple form of a mobile phone. 155 o The host can be an open device, e.g., a "smart phone" where it is 156 possible to download applications to expand the functionality of 157 the device. 158 o The cellular radio modem part can be separated from the host IP 159 stack with an interface. One example of such host is a laptop 160 computer that uses a USB cellular modem for the cellular access. 162 If a cellular host has additional IP capable interfaces, (such as 163 Ethernet, WLAN, Bluetooth, etc.) then there may be additional 164 requirements for the device, beyond what is discussed in this 165 document. Additionally, this document does not make any 166 recommendations on the functionality required on laptop computers 167 having a cellular interface such as an embedded modem or a USB modem 168 stick, other than recommending link specific behavior on the cellular 169 link. 171 This document discusses IPv6 functionality as of the time when this 172 document has been written. Ongoing work on IPv6 may affect what is 173 required of future hosts. 175 Transition mechanisms used by cellular hosts are not in the scope of 176 this document and are left for further study. The primary transition 177 mechanism supported by the 3GPP is dual-stack [RFC4213]. Dual-stack 178 capable bearer support has been added to GPRS starting from the 3GPP 179 Release-9 and to EPS starting from the Release-8 [RFC6459], whereas 180 the earlier 3GPP releases required multiple single IP version bearers 181 to support dual-stack. 183 1.2. Abbreviations 185 2G Second Generation Mobile Telecommunications, such as GSM and 186 GPRS technologies. 188 3G Third Generation Mobile Telecommunications, such as UMTS 189 technology. 190 4G Fourth Generation Mobile Telecommunications, such as LTE 191 technology. 192 3GPP 3rd Generation Partnership Project. Throughout the document, 193 the term 3GPP (3rd Generation Partnership Project) networks 194 refers to architectures standardized by 3GPP, in Second, Third 195 and Fourth Generation releases: 99, 4, and 5, as well as future 196 releases. 197 APN Access Point Name. The APN is a logical name referring to a 198 GGSN and/or a PGW, and an external network. 199 EPC Evolved Packet Core. 200 EPS Evolved Packet System. 201 ESP Encapsulating Security Payload 202 GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6 203 cellular hosts in GPRS). 204 GPRS General Packet Radio Service. 205 LTE Long Term Evolution. 206 MT Mobile Terminal, for example, a mobile phone handset. 207 MTU Maximum Transmission Unit. 208 PDN Packet Data Network. 209 PDP Packet Data Protocol. 210 PGW Packet Data Network Gateway (the default router for 3GPP IPv6 211 cellular hosts in EPS). 212 SGW Serving Gateway. The user plane equivalent of an SGSN in EPS 213 (and the default router for 3GPP IPv6 cellular hosts when using 214 PMIPv6). 215 TE Terminal Equipment, for example, a laptop attached through a 216 3GPP handset. 217 UMTS Universal Mobile Telecommunications System. 218 WLAN Wireless Local Area Network. 220 1.3. Cellular Host IPv6 Features 222 This document lists IPv6 features for cellular hosts that are split 223 into three groups. 225 Basic IP 227 In this group, a list of the basic IPv6 features essential for 228 cellular hosts are described. 230 IP Security 232 In this group, the IP Security related 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 to 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 [RFC4861]. Some further notes on how these 254 are applied in the particular type of an interface can be useful, 255 however: 257 In 3GPP networks, some Neighbor Discovery messages can be unnecessary 258 in certain cases. GPRS, UMTS and EPS links resemble a point-to-point 259 link; hence, the cellular host's only neighbor on the cellular link 260 is the default router that is already known through Router Discovery. 261 The cellular host always solicits for routers when the cellular 262 interface is brought up (as described in [RFC4861], Section 6.3.7). 264 There are no link layer addresses on the 3GPP cellular link 265 technology. Therefore, address resolution and next-hop determination 266 are not needed. If the cellular host still attempts to do the 267 address resolution e.g., for the default router, it must be 268 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 on the 3GPP cellular link 272 technology. 274 The cellular host must support Neighbor Unreachability Detection 275 (NUD) as specified in [RFC4861]. Note that the link-layer address 276 considerations above also apply to the NUD. The NUD triggered 277 Neighbor Advertisement is also unlikely to contain the Target link- 278 layer address option as there are no link-layer addresses. The 279 cellular host should also be prepared for a router (i.e., GGSN/PGW) 280 initiated NUD. However, it is unlikely a router to host NUD should 281 ever take place on a GPRS, UMTS and EPS links. See Appendix A for 282 more discussion on the router to host NUD. 284 In 3GPP networks, it is desirable to reduce any additional periodic 285 signaling. Therefore, the cellular host should include a mechanism 286 in upper layer protocols to provide reachability confirmations when 287 two-way IP layer reachability can be confirmed (see [RFC4861], 288 Section 7.3.1). These confirmations would allow the suppression of 289 NUD-related messages in most cases. 291 Host TCP implementation should provide reachability confirmation in 292 the manner explained in [RFC4861], Section 7.3.1. 294 The widespread use of UDP in 3GPP networks poses a problem for 295 providing reachability confirmation. As UDP itself is unable to 296 provide such confirmation, applications running on top of UDP should 297 provide the confirmation where possible. In particular, when UDP is 298 used for transporting DNS, the DNS response should be used as a basis 299 for reachability confirmation. Similarly, when UDP is used to 300 transport RTP [RFC3550], the RTCP protocol [RFC3550] feedback should 301 be used as a basis for the reachability confirmation. If an RTCP 302 packet is received with a reception report block indicating some 303 packets have gone through, then packets are reaching the peer. If 304 they have reached the peer, they have also reached the neighbor. 306 When UDP is used for transporting SIP [RFC3261], responses to SIP 307 requests should be used as the confirmation that packets sent to the 308 peer are reaching it. When the cellular host is acting as the server 309 side SIP node, no such confirmation is generally available. However, 310 a host may interpret the receipt of a SIP ACK request as confirmation 311 that the previously sent response to a SIP INVITE request has reached 312 the peer. 314 2.3. Stateless Address Autoconfiguration 316 IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. 317 This specification is a mandatory part of IPv6 and also the only 318 mandatory method to configure an IPv6 address in a 3GPP cellular 319 host. 321 A cellular host in a 3GPP network must process a Router Advertisement 322 as stated in [RFC4862]. The Router Advertisement contains a maximum 323 of one prefix information option with lifetimes set to infinite (both 324 valid and preferred lifetimes). The advertised prefix cannot ever be 325 used for on-link determination (see [RFC6459], Section 5.2) and the 326 lifetime of the advertised prefix is tied to the PDP Context/PDN 327 Connection lifetime. Keeping the forward compatibility in mind there 328 is no reason for the 3GPP cellular host to have 3GPP specific 329 handling of the prefix information option(s) although 3GPP 330 specifications state that the Router Advertisement may contain a 331 maximum of one prefix information option and the lifetimes are set to 332 infinite. 334 Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, 335 as each assigned prefix is unique within its scope when advertised 336 using the 3GPP IPv6 Stateless Address Autoconfiguration. In 337 addition, the default router (GGSN/PGW) will not configure any 338 addresses on its interfaces based on prefixes advertised to IPv6 339 cellular hosts on those interfaces. Thus, the host is not required 340 to perform Duplicate Address Detection on the cellular interface. 342 Furthermore, the GGSN/PGW will provide the cellular host with an 343 interface identifier that must be used for link-local address 344 configuration. The link-local address configured from this interface 345 identifier is guaranteed not to collide with the link-local address 346 that the GGSN/PGW uses. Thus, the cellular host is not required to 347 perform Duplicate Address Detection for the link-local address on the 348 cellular interface. 350 See Appendix A for more details on 3GPP IPv6 Stateless Address 351 Autoconfiguration. 353 2.4. IP version 6 over PPP 355 A cellular host in a 3GPP network that supports PPP [RFC1661] on the 356 interface between the MT and the TE, must support the IPv6CP 357 [RFC5072] interface identifier option. This option is needed to be 358 able to connect other devices to the Internet using a PPP link 359 between the cellular device (MT, e.g., a USB dongle) and other 360 devices (TE, e.g., a laptop). The MT performs the PDP Context 361 activation based on a request from the TE. This results in an 362 interface identifier being suggested by the MT to the TE, using the 363 IPv6CP option. To avoid any duplication in link-local addresses 364 between the TE and the GGSN/PGW, the MT must always reject other 365 suggested interface identifiers by the TE. This results in the TE 366 always using the interface identifier suggested by the GGSN/PGW for 367 its link-local address. 369 The rejection of interface identifiers suggested by the TE is only 370 done for creation of link-local addresses, according to 3GPP 371 specifications. The use of privacy addresses [RFC4941] or similar 372 technologies for unique local IPv6 unicast addresses (ULA) [RFC4193] 373 and global addresses is not affected by the above procedure. 375 2.5. Multicast Listener Discovery (MLD) for IPv6 377 Within 3GPP networks, hosts connect to their default routers (GGSN/ 378 PGW) via point-to-point links. Moreover, there are exactly two IP 379 devices connected to the point-to-point link, and no attempt is made 380 (at the link-layer) to suppress the forwarding of multicast traffic. 381 Consequently, sending MLD reports for link-local addresses in a 3GPP 382 environment is not necessary, although sending those cause no harm or 383 interoperability issues. Refer Section 5.10 of [RFC6434] for MLD 384 usage for multicast group knowledge that is not link-local. 386 2.6. Privacy Extensions for Address Configuration in IPv6 388 Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] 389 or other similar technologies may be supported by a cellular host. 390 Privacy in general, is important for the Internet. In 3GPP networks 391 the lifetime of an address assignment depends on many factors such as 392 radio coverage, device status and user preferences. As a result also 393 the prefix the cellular host uses is a subject to frequent changes. 395 Refer to Section 7 for a discussion of the benefits of privacy 396 extensions in a 3GPP network. 398 2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 400 As of 3GPP Release-11 The Dynamic Host Configuration Protocol for 401 IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address 402 autoconfiguration. The IPv6 stateless autoconfiguration still 403 remains the only mandatory address configuration method. However, 404 DHCPv6 may be useful for other configuration needs on a cellular 405 host. e.g. Stateless DHCPv6 [RFC3736] may be used to configure DNS 406 and SIP server addresses, and DHCPv6 prefix delegation [RFC3633] may 407 be used to delegate a prefix to the cellular host for use on its 408 downstream non-cellular links. 410 2.8. DHCPv6 Prefix Delegation 412 Starting from Release-10 DHCPv6 Prefix Delegation was added as an 413 optional feature to the 3GPP system architecture [RFC3633]. The 414 prefix delegation model defined for Release-10 requires that the /64 415 IPv6 prefix assigned to the cellular host on the 3GPP link must 416 aggregate with the shorter delegated IPv6 prefix. The cellular host 417 should implement the Prefix Exclude Option for DHCPv6 Prefix 418 Delegation [RFC6603] (see [RFC6459], Section 5.3 for further 419 discussion). 421 2.9. Router preferences and more specific routes 423 The cellular host should implement the Default Router Preferences and 424 More-Specific Routes extension to Router Advertisement messages 425 [RFC4191]. These options may be useful for cellular hosts that also 426 have additional interfaces on which IPv6 is used. 428 2.10. Neighbor Discovery and additional host configuration 430 The DNS server configuration is learned from the 3GPP link layer 431 signaling. However, the cellular host should also implement the IPv6 432 Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6 433 is still optional for cellular hosts, and learning the DNS server 434 addresses from the link layer signaling can be cumbersome when the MT 435 and the TE are separated using other techniques than PPP interface. 437 The cellular host should also honor the MTU option in the Router 438 Advertisement (see [RFC4861], Section 4.6.4). 3GPP system 439 architecture uses extensive tunneling in its packet core network 440 below the 3GPP link and this may lead to packet fragmentation issues. 441 Therefore, the GGSN/PGW may propose a MTU to the cellular host that 442 takes the additional tunneling overhead into account. 444 3. IP Security 446 IPsec [RFC4301] is a fundamental but not mandatory part of IPv6. 447 Refer to the IPv6 Node Requirements Section 11 of [RFC6434] for the 448 security requirements that also apply to cellular hosts. 450 3.1. Extension header considerations 452 The support for the Routing Header Type 0 (RH0) has been deprecated 453 [RFC5095]. Therefore, the cellular host should as a default setting 454 follow the RH0 processing described in Section 3 of [RFC5095]. 456 IPv6 packet fragmentation has known security concerns. The cellular 457 host must follow the handling of overlapping fragments as described 458 in [RFC5722] and the cellular host must not fragment any neighbor 459 discovery messages as described in [RFC6980]. 461 4. Mobility 463 For the purposes of this document, IP mobility is not relevant. The 464 movement of cellular hosts within 3GPP networks is handled by link 465 layer mechanisms in majority of cases. 3GPP Release-8 introduced the 466 dual-stack Mobile IPv6 (DSMIPv6) for a client based mobility 468 [RFC5555]. Client based IP mobility is optional in 3GPP 469 architecture. 471 5. IANA Considerations 473 This document has no IANA actions. 475 6. Acknowledgements 477 The authors would like to thank the original authors for their 478 grounding work on this documents: Gerben Kuijpers, John Loughney, 479 Hesham Soliman and Juha Wiljakka. 481 The original [RFC3316] document was based on the results of a team 482 that included Peter Hedman and Pertti Suomela in addition to the 483 authors. Peter and Pertti have contributed both text and their IPv6 484 experience to this document. 486 The authors would like to thank Jim Bound, Brian Carpenter, Steve 487 Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, 488 Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing 489 list for their comments and input. 491 We would also like to thank David DeCamp, Karim El Malki, Markus 492 Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and 493 Shabnam Sultana for their comments and input in preparation of this 494 document. 496 For the revised version of the [RFC3316] the authors would like thank 497 Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter, Charlie Kaufman, 498 Owen DeLong and Alexey Melnikov for their comments, reviews and 499 inputs. 501 7. Security Considerations 503 This document does not specify any new protocols or functionalities, 504 and as such, it does not introduce any new security vulnerabilities. 505 However, specific profiles of IPv6 functionality are proposed for 506 different situations, and vulnerabilities may open or close depending 507 on which functionality is included and what is not. There are also 508 aspects of the cellular environment that make certain types of 509 vulnerabilities more severe. The following issues are discussed: 511 o The suggested limitations (Section 3.1) in the processing of 512 extension headers limits also exposure to Denial-of-Service (DoS) 513 attacks through cellular hosts. 514 o IPv6 addressing privacy [RFC4941] or similar technology may be 515 used in cellular hosts. However, it should be noted that in the 516 3GPP model, the network would assign a new prefix, in most cases, 517 to hosts in roaming situations and typically, also when the 518 cellular hosts activate a PDP Context or a PDN Connection. 3GPP 519 devices must not use interface identifiers that are unique to the 520 device, so the only difference in address between to 3GPP devices 521 using SLAAC is in the prefix. This means that 3GPP networks will 522 already provide a limited form of addressing privacy, and no 523 global tracking of a single host is possible through its address. 524 On the other hand, since a GGSN/PGW's coverage area is expected to 525 be very large when compared to currently deployed default routers 526 (no handovers between GGSN/PGWs are possible), a cellular host can 527 keep a prefix for a long time. Hence, IPv6 addressing privacy can 528 be used for additional privacy during the time the host is on and 529 in the same area. The privacy features can also be used to e.g., 530 make different transport sessions appear to come from different IP 531 addresses. However, it is not clear that these additional efforts 532 confuse potential observers any further, as they could monitor 533 only the network prefix part. 534 o The use and recommendations of various security services such as 535 IPsec or TLS [RFC5246] in the connection of typical applications 536 that also apply to cellular hosts are discussed in Section 11 of 537 [RFC6434]. 538 o The use of various security services such as IPsec or TLS in the 539 connection of typical applications in cellular hosts is discussed 540 in Section 3 and further pointer for recommendations are given 541 there. 542 o The airtime used by cellular hosts is expensive. In some cases, 543 users are billed according to the amount of data they transfer to 544 and from their host. It is crucial for both the network and the 545 users that the airtime is used correctly and no extra charges are 546 applied to users due to misbehaving third parties. The cellular 547 links also have a limited capacity, which means that they may not 548 necessarily be able to accommodate more traffic than what the user 549 selected, such as a multimedia call. Additional traffic might 550 interfere with the service level experienced by the user. While 551 Quality of Service mechanisms mitigate these problems to an 552 extent, it is still apparent that DoS aspects may be highlighted 553 in the cellular environment. It is possible for existing DoS 554 attacks that use for instance packet amplification to be 555 substantially more damaging in this environment. How these 556 attacks can be protected against is still an area of further 557 study. It is also often easy to fill the cellular link and queues 558 on both sides with additional or large packets. 560 o Within some service provider networks, it is possible to buy a 561 prepaid cellular subscription without presenting personal 562 identification. Attackers that wish to remain unidentified could 563 leverage this. Note that while the user hasn't been identified, 564 the equipment still is; the operators can follow the identity of 565 the device and block it from further use. The operators must have 566 procedures in place to take notice of third party complaints 567 regarding the use of their customers' devices. It may also be 568 necessary for the operators to have attack detection tools that 569 enable them to efficiently detect attacks launched from the 570 cellular hosts. 571 o Cellular devices that have local network interfaces (such as WLAN 572 or Bluetooth) may be used to launch attacks through them, unless 573 the local interfaces are secured in an appropriate manner. 574 Therefore, local network interfaces should have access control to 575 prevent others from using the cellular host as an intermediary. 576 o The 3GPP link model mitigates most of the known IPv6 on-link and 577 neighbor cache targeted attacks (see Section 2.2 and Appendix A). 578 o Advice for implementations in the face of Neighbor Discovery DoS 579 attacks may be useful in some environments [RFC6583]. 580 o Section 9 of [RFC6459] discusses further some recent concerns 581 related to cellular hosts security. 583 8. References 585 8.1. Normative references 587 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 588 (IPv6) Specification", RFC 2460, December 1998. 590 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 591 for IPv6 Hosts and Routers", RFC 4213, October 2005. 593 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 594 Internet Protocol", RFC 4301, December 2005. 596 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 597 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 598 September 2007. 600 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 601 Address Autoconfiguration", RFC 4862, September 2007. 603 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 604 Extensions for Stateless Address Autoconfiguration in 605 IPv6", RFC 4941, September 2007. 607 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 608 of Type 0 Routing Headers in IPv6", RFC 5095, 609 December 2007. 611 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 612 RFC 5722, December 2009. 614 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 615 Requirements", RFC 6434, December 2011. 617 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 618 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 620 8.2. Informative references 622 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 623 RFC 1661, July 1994. 625 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 626 A., Peterson, J., Sparks, R., Handley, M., and E. 627 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 628 June 2002. 630 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 631 and M. Carney, "Dynamic Host Configuration Protocol for 632 IPv6 (DHCPv6)", RFC 3315, July 2003. 634 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 635 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 636 Second and Third Generation Cellular Hosts", RFC 3316, 637 April 2003. 639 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 640 Jacobson, "RTP: A Transport Protocol for Real-Time 641 Applications", STD 64, RFC 3550, July 2003. 643 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 644 Host Configuration Protocol (DHCP) version 6", RFC 3633, 645 December 2003. 647 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 648 (DHCP) Service for IPv6", RFC 3736, April 2004. 650 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 651 More-Specific Routes", RFC 4191, November 2005. 653 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 654 Addresses", RFC 4193, October 2005. 656 [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 657 PPP", RFC 5072, September 2007. 659 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 660 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 662 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 663 Routers", RFC 5555, June 2009. 665 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 666 "IPv6 Router Advertisement Options for DNS Configuration", 667 RFC 6106, November 2010. 669 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 670 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 671 Partnership Project (3GPP) Evolved Packet System (EPS)", 672 RFC 6459, January 2012. 674 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 675 Neighbor Discovery Problems", RFC 6583, March 2012. 677 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 678 "Prefix Exclude Option for DHCPv6-based Prefix 679 Delegation", RFC 6603, May 2012. 681 [TS.23060] 682 3GPP, "General Packet Radio Service (GPRS); Service 683 description; Stage 2", 3GPP TS 23.060 11.5.0, March 2013. 685 [TS.23401] 686 3GPP, "General Packet Radio Service (GPRS) enhancements 687 for Evolved Universal Terrestrial Radio Access Network 688 (E-UTRAN) access", 3GPP TS 23.401 11.5.0, March 2013. 690 [TS.23402] 691 3GPP, "Architectural enhancements for non-3GPP accesses", 692 3GPP TS 23.402 11.6.0, March 2013. 694 [TS.29061] 695 3GPP, "Interworking between the Public Land Mobile Network 696 (PLMN) supporting packet based services and Packet Data 697 Networks (PDN)", 3GPP TS 29.061 11.4.0, March 2013. 699 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model 701 The appendix aims to very briefly describe the 3GPP IPv6 addressing 702 model for 2G (GPRS), 3G (UMTS) and 4G (EPS) cellular networks from 703 Release-99 onwards. More information for 2G and 3G can be found from 704 3GPP Technical Specifications [TS.23060] and [TS.29061]. The 705 equivalent documentation for 4G can be found from 3GPP Technical 706 Specifications [TS.23401], [TS.23402] and [TS.29061]. 708 There are two possibilities to allocate the address for an IPv6 node: 709 stateless and stateful autoconfiguration. The stateful address 710 allocation mechanism needs a DHCP server to allocate the address for 711 the IPv6 node. On the other hand, the stateless autoconfiguration 712 procedure does not need any external entity involved in the address 713 autoconfiguration (apart from the GGSN/PGW). At the time of writing 714 this document, the IPv6 stateless address autoconfiguration mechanism 715 is still the only mandatory and supported address configuration 716 method for the cellular 3GPP link. 718 In order to support the standard IPv6 stateless address 719 autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW 720 shall assign a single /64 IPv6 prefix that is unique within its scope 721 to each primary PDP Context or PDN Connection that uses IPv6 722 stateless address autoconfiguration. This avoids the necessity to 723 perform Duplicate Address Detection (DAD) at the network level for 724 any address built by the mobile host. The GGSN/PGW always provides 725 an interface identifier to the mobile host. The Mobile host uses the 726 interface identifier provided by the GGSN/PGW to generate its link- 727 local address. The GGSN/PGW provides the cellular host with the 728 interface identifier, usually in a random manner. It must ensure the 729 uniqueness of such identifier on the link (i.e., no collisions 730 between its own link-local address and the cellular host's). 732 In addition, the GGSN/PGW will not use any of the prefixes assigned 733 to cellular hosts to generate any of its own addresses. This use of 734 the interface identifier, combined with the fact that each PDP 735 Context or PDN Connection is allocated a unique prefix, will 736 eliminate the need for DAD messages over the air interface, and 737 consequently reduces inefficient use of radio resources. 738 Furthermore, the allocation of a prefix to each PDP Context or PDN 739 Connection will allow hosts to implement the Privacy Extensions in 740 [RFC4941] without the need for further DAD messages. 742 In practice, the GGSN/PGW only needs to route all traffic destined to 743 the cellular host that falls under the prefix assigned to it. This 744 implies the GGSN/PGW may implement a minimal neighbor discovery 745 protocol subset; since, due the point-to-point link model and the 746 absence of link-layer addressing the address resolution can be 747 entirely statically configured per PDP Context or PDN Connection, and 748 there is no need to defend any other address than the link-local 749 address for very unlikely duplicates. This has also an additional 750 effect on a router to host NUD. There is really no need for it, 751 since from the GGSN/PGW point of view it does not need to care for a 752 single address, just routes the whole prefix to the cellular host. 753 However, the cellular host must be prepared for the unlikely event of 754 receiving a NUD against its link-local address. It should be noted 755 that the 3GPP specifications at the time of writing this document are 756 silent what should happen if the router to host NUD fails. 758 See Sections 5 of [RFC6459] for further discussion on 3GPP address 759 allocation and link model. 761 Appendix B. Changes to RFC 3316 763 o Clarified that [RFC4941] or similar technologies instead of plain 764 [RFC4941] may be used for privacy purposes (as stated in 765 [RFC6459]). 766 o Clarified that MLD for link-local addresses is not necessary but 767 doing it causes no harm (instead of saying it may not be needed in 768 some cases). 769 o Clarified that a cellular host should not do any changes in its 770 stack to meet the 3GPP link restriction on the RA PIO options. 771 o Clarified that a cellular host should not do any changes in its 772 stack to meet the infinite prefix lifetime requirement the 3GPP 773 link has. 774 o Clarified that the prefix lifetime is tied to the PDP Context/PDN 775 Connection lifetime. 776 o Clarified explicitly that a NUD from the gateway side to the UE's 777 link-local address is possible. 778 o Added references to 3GPP specifications. 779 o Additional clarification on NUD on 3GPP cellular links. 780 o Added an explicit note that the prefix on the link is /64. 781 o Clarified that DHCPv6 ([RFC3315]) is not used at all for address 782 autoconfiguration. 783 o Removal of all sections that can be directly found from [RFC6434]. 784 o Clarifications to 3GPP link model and how Neighbor Discovery works 785 on it. 786 o Addition of [RFC4191] recommendations. 787 o Addition of DHCPv6-based Prefix Delegation recommendations. 788 o Addition of [RFC6106] recommendations. 789 o Addition of [RFC5555] regarding client based mobility. 790 o Addition of Router Advertisement MTU option handling. 791 o Addition of Evolved Packet System text. 792 o Clarification on the primary 3GPP IPv6 transition mechanism. 793 o Addition of [RFC5095] that deprecates the RH0. 794 o Addition of [RFC5722] and [RFC6980] regarding the IPv6 795 fragmentation handling. 797 o Addition of [RFC6583] for Neighbor Discovery denial-of-service 798 attack considerations. 799 o Made the PPP IPv6CP [RFC5072] support text conditional. 801 Authors' Addresses 803 Jouni Korhonen (editor) 804 Renesas Mobile 805 Porkkalankatu 24 806 FIN-00180 Helsinki 807 Finland 809 Email: jouni.nospam@gmail.com 811 Jari Arkko (editor) 812 Ericsson 813 Jorvas 02420 814 Finland 816 Email: jari.arkko@piuha.net 818 Teemu Savolainen 819 Nokia 820 Hermiankatu 12 D 821 FI-33720 Tampere 822 FINLAND 824 Email: teemu.savolainen@nokia.com 826 Suresh Krishnan 827 Ericsson 828 8400 Decarie Blvd. 829 Town of Mount Royal, QC 830 Canada 832 Phone: +1 514 345 7900 x42871 833 Email: suresh.krishnan@ericsson.com