idnits 2.17.1 draft-ietf-v6ops-host-addr-availability-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2015) is 3185 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-dhc-anonymity-profile-01 == Outdated reference: A later version (-02) exists of draft-tsvwg-quic-protocol-01 -- 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 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations L. Colitti 3 Internet-Draft V. Cerf 4 Intended status: Best Current Practice Google 5 Expires: February 1, 2016 S. Cheshire 6 D. Schinazi 7 Apple Inc. 8 July 31, 2015 10 Host address availability recommendations 11 draft-ietf-v6ops-host-addr-availability-00 13 Abstract 15 This document recommends that networks provide general-purpose end 16 hosts with multiple global addresses when they attach, and describes 17 the benefits of and the options for doing so. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 1, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Common IPv6 deployment model . . . . . . . . . . . . . . . . 3 56 3. Benefits of multiple addresses . . . . . . . . . . . . . . . 3 57 4. Problems with assigning a limited number of addresses per 58 host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Overcoming limits using Network Address Translation . . . . . 5 60 6. Options for obtaining more than one address . . . . . . . . . 6 61 7. Number of addresses required . . . . . . . . . . . . . . . . 7 62 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 63 9. Operational considerations . . . . . . . . . . . . . . . . . 7 64 9.1. Stateful addressing and host tracking . . . . . . . . . . 7 65 9.2. Address space management . . . . . . . . . . . . . . . . 8 66 9.3. Addressing link layer scalability issues via IP routing . 8 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 12. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 13.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 In most aspects, the IPv6 protocol is very similar to IPv4. This 78 similarity can create a tendency to think of IPv6 as 128-bit IPv4, 79 and thus lead network designers and operators to apply identical 80 configurations and operational practices to both. This is generally 81 a good thing because it eases the transition to IPv6 and the 82 operation of dual-stack networks. However, in some areas it can lead 83 to carrying over IPv4 practices that are not appropriate in IPv6 due 84 to significant differences between the protocols. 86 One such area is IP adressing, particularly IP addressing of hosts. 87 This is substantially different because unlike IPv4 addresses, IPv6 88 addresses are not a scarce resource. In IPv6, each link has a 89 virtually unlimited amount of address space [RFC7421]. Thus, unlike 90 IPv4, IPv6 networks are not forced by address availability 91 considerations to assign only one address per host. On the other 92 hand, assigning multiple addresses has many benefits including 93 application functionality and simplicity, privacy, future 94 applications, and the ability to deploy the Internet without the use 95 of NAT. Assigning only one IPv6 address per host negates these 96 benefits. 98 This document describes the benefits of assigning multiple addresses 99 per host and the problems with not doing so. It recommends that 100 networks provide general-purpose end hosts with multiple global 101 addresses when they attach, and lists current options for doing so. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Common IPv6 deployment model 111 IPv6 is designed to support multiple addresses, including multiple 112 global addresses, per interface ([RFC4291] section 2.1, [RFC6434] 113 section 5.9.4). Today, many general-purpose IPv6 hosts are 114 configured with three or more addresses per interface: a link-local 115 address, a stable address (e.g., using EUI-64 or [RFC7217]), one or 116 more privacy addresses [RFC4941], and possibly one or more temporary 117 or non-temporary addresses assigned using DHCPv6 [RFC3315]. 119 In most general-purpose IPv6 networks, including all 3GPP networks 120 (see [RFC6459] section 5.2) and Ethernet and Wi-Fi networks using 121 SLAAC [RFC4862], IPv6 hosts have the ability to configure additional 122 IPv6 addresses from the link prefix(es) without explicit requests to 123 the network. 125 3. Benefits of multiple addresses 127 Today, there are many host functions that require more than one IP 128 address to be available to the host: 130 o Privacy addressing to prevent tracking by off-network hosts (e.g., 131 [RFC4941]). 133 o Multiple processors inside the same device. For example, in many 134 mobile devices both the application processor and baseband 135 processor need to communicate with the network, particularly for 136 recent technologies like ePDG. 138 o Extending the network (e.g., tethering). 140 o Running virtual machines on hosts. 142 o Translation-based transition technologies such as 464XLAT that 143 provide IPv4 over IPv6. Current implementations require the 144 availability of a dedicated IPv6 address in order to determine 145 whether inbound packets are translated or native. 147 o ILA ("Identifier-locator addressing"): 148 https://tools.ietf.org/html/draft-herbert-nvo3-ila 150 o Future applications (e.g., per-application IPv6 addresses, such as 151 described in [TARP]). 153 Example of how the availability of multiple addresses per host has 154 already allowed substantial deployment of new applications without 155 explicit requests to the network are: 157 o 464XLAT [RFC6877]. 464XLAT is usually deployed within a particular 158 network operator's network, but there are deployment models where 159 the PLAT is provided as a service by a different network (e.g., 160 ) 162 o /64 sharing [RFC7278]. This was a way to provide IPv6 tethering 163 without needing to wait for network operators to deploy DHCPv6 PD, 164 which is only available in 3GPP release 10. 166 4. Problems with assigning a limited number of addresses per host 168 Assigning a limited number of addresses per host implies that 169 functions that require multiple addresses will either be unavailable 170 (e.g., if the network provides only one IPv6 address per host, or if 171 the host has reached the limit of the number of addresses available), 172 or that the functions will only be available after an explicit 173 request to the network is granted. The necessity of explicit 174 requests has the following drawbacks: 176 o Increased latency, because a provisioning operation, and possibly 177 human intervention with an update to the service level agreement, 178 must complete before the functionality is available. 180 o Uncertainty, because it is not known in advance if a particular 181 operation function will be available. 183 o Complexity, because implementations need to deal with failures and 184 somehow present them to the user. Failures may manifest as 185 timeouts, which may be slow and frustrating to users. 187 o Increased load on the network's provisioning servers. 189 Some operators may desire to configure their networks to limit the 190 number of IPv6 addresses per host. Reasons might include hardware 191 limitations (e.g., TCAM or neighbour cache table size constraints), 192 operational consistency with IPv4 (e.g., an IP address management 193 system that only supports one address per host), or business models 194 (e.g., a desire to charge the network's users on a per-device basis). 196 5. Overcoming limits using Network Address Translation 198 These limits can mostly be overcome by end hosts by using NAT, and 199 indeed in IPv4 most of these functions are provided by using NAT on 200 the host. Thus, the limits could be overcome in IPv6 as well by 201 implementing NAT66 on the host. 203 Unfortunately NAT has well-known drawbacks. For example, it causes 204 application complexity due to the need to implement NAT traversal. 205 It hinders development of new applications. On mobile devices, it 206 reduces battery life due to the necessity of frequent keepalives, 207 particularly for UDP. Applications using UDP that need to work on 208 most of the Internet are forced to send keepalives at least every 30 209 seconds . For example, the QUIC protocol uses a 15-second keepalive 211 [I-D.tsvwg-quic-protocol]. Other drawbacks are described in 212 [RFC2993]. While IPv4 NAT is inevitable due to the limited amount of 213 IPv4 space available, that argument does not apply to IPv6. Guidance 214 from the IAB is that deployment of IPv6 NAT is not desirable 215 [RFC5902]. 217 If networks that provide limited amount of addresses become widely 218 deployed, then the desire to overcome the problems listed in 219 Section 4 without disabling any features may result in operating 220 system manufacturers implementing IPv6 NAT. 222 This is not a desirable outcome. It is not desirable for users 223 because they may experience application brittleness. It is likely 224 not desirable for network operators either, as they may suffer higher 225 support costs, and even when the decision to assign only one IPv6 226 address per device is dictated by the network's business model, there 227 may be little in the way of incremental revenue, because devices can 228 share their IPv6 address with other devices. Finally, it is not 229 desirable for operating system manufacturers and application 230 developers, who will have to build more complexity, lengthening 231 development time and/or reducing the time spent on other features. 233 Indeed, it could be argued that the main reason for deploying IPv6, 234 instead of continuing to scale the Internet using only IPv4 and 235 large-scale NAT44, is because doing so can provide all the hosts on 236 the planet with end-to-end connectivity that is limited not by 237 technical factors but only by security policies. 239 6. Options for obtaining more than one address 241 Multiple IPv6 addresses can be obtained in the following ways: 243 o Using Stateless Address Autoconfiguration [RFC4862]. SLAAC allows 244 hosts to create global IPv6 addresses on demand by simply forming 245 new addresses from the global prefix assigned to the link. 247 o Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 248 clients only ask for one non-temporary address, but the protocol 249 allows requesting multiple temporary and even multiple non- 250 temporary addresses, and the server could choose to assign the 251 client multiple addresses. It is also possible for a client to 252 request additional addresses using a different DUID. The DHCPv6 253 server will decide whether to grant or reject the request based on 254 information about the client, including its DUID, MAC address, and 255 so on. 257 o DHCPv6 prefix delegation [RFC3633]. DHCPv6 PD allows the client 258 to request and be delegated a prefix, from which it can 259 autonomously form other addresses. The prefix can also be 260 hierarchically delegated to downstream clients, or, if it is a 261 /64, it be reshared with downstream clients via ND proxying 262 [RFC4389] or /64 sharing [RFC7278]. 264 +------------------------+---------+------------+---------+---------+ 265 | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | 266 | | | IA_NA / | PD | | 267 | | | IA_TA | | | 268 +------------------------+---------+------------+---------+---------+ 269 | Autonomously form | Yes | No | Yes | Yes | 270 | addresses | (/64 | | (/64 | (NAT44) | 271 | | share) | | share) | | 272 | "Unlimited" endpoints | Yes* | Yes* | No | No | 273 | Stateful, request- | No | Yes | Yes | Yes | 274 | based | | | | | 275 | Immune to layer 3 on- | No | Yes | Yes | Yes | 276 | link resource | | | | | 277 | exhaustion attacks | | | | | 278 +------------------------+---------+------------+---------+---------+ 280 [*] Subject to network limitations, e.g., ND cache entry size limits. 282 Table 1: Comparison of multiple address assigment options 284 7. Number of addresses required 286 If we itemize the use cases from section Section 3, we can estimate 287 the number of addresses currently used in normal operations. In 288 typical implementations, privacy addresses use up to 8 addresses (one 289 per day). Current mobile devices may typically support 8 clients, 290 with each one requiring one or more addresses. A client might choose 291 to run several virtual machines. Current implementations of 464XLAT 292 require use of a separate address. Some devices require another 293 address for their baseband chip. Even a host performing only several 294 of these functions simultaneously might need on the order of 20 295 addresses at the same time. Future applications designed to use an 296 address per application or even per resource will require many more. 297 These will not function on networks that enforce a hard limit on the 298 number of addresses provided to hosts. 300 8. Recommendations 302 In order to avoid the problems described above, and preserve the 303 Internet's ability to support new applications that use more than one 304 IPv6 address, it is RECOMMENDED that IPv6 network deployments provide 305 multiple IPv6 addresses from each prefix to general-purpose hosts 306 when they connect to the network. To support future use cases, it is 307 RECOMMENDED to not impose a hard limit on the size of the address 308 pool assigned to a host. If the network requires explicit requests 309 for address space, a /64 prefix is desirable. Using DHCPv6 IA_NA or 310 IA_TA to request a sufficient number of addresses (e.g. 32) would 311 accomodate current clients but sets a limit on the number of 312 addresses available to hosts when they attach and would limit the 313 development of future applications. 315 9. Operational considerations 317 9.1. Stateful addressing and host tracking 319 Some network operators - often operators of networks that provide 320 services to third parties such as university campus networks - have 321 made the argument that the only feasible IPv6 deployment mechanism is 322 DHCPv6, due to the need to be able to track at all times IPv6 323 addresses are assigned to which hosts. (Example: 324 ). 325 One reason frequently cited for this is protection from liability for 326 copyright infringement or other illegal activity by maintaining 327 persistent logs that map user IP addresses and timestamps to hardware 328 identifiers such as MAC addresses. 330 It is worth noting that using DHCPv6 does not by itself ensure that 331 hosts will actually use the addresses assigned to them by the network 332 as opposed to using any other address on the prefix. Such guarantees 333 can only be provided by link-layer security mechanisms that enforce 334 that particular IPv6 addresses are used by particular link-layer 335 addresses (for example: SAVI [RFC7039]). If those mechanisms are 336 available, it is possible to use them to provide tracking, instead. 337 This form of tracking is much more reliable because it operates 338 independently of how addresses are allocated. 340 Additionally, attempts to track this sort of information via DHCPv6 341 are likely to become decreasingly viable due to ongoing efforts to 342 improve the privacy of DHCP: [I-D.ietf-dhc-anonymity-profile]. 344 Many large enterprise networks, including the enterprise networks of 345 the authors, are fully dual-stack but do not currently use or support 346 DHCPv6. 348 9.2. Address space management 350 In IPv4, all but the world's largest networks can be addressed using 351 private space [RFC1918], and with each host receiving one IPv4 352 address. Many networks can be numbered in 192.168.0.0/16 which has 353 roughly 64k addresses. In IPv6, that is equivalent to assigning one 354 /64 per host out of a /48. Under current RIR policies, a /48 is easy 355 to obtain for an enterprise network. 357 Networks that need a bigger block of private space use 10.0.0.0/8, 358 which is is roughly 16 million addresses. In IPv6, that is 359 equivalent to assigning a /64 per host out of a /40. Enterprises of 360 such size can easily obtain a /40 under current RIR policies. 362 Currently, residential users receive one IPv4 address and a /48, /56 363 or /60 IPv6 prefix. While such networks do not have enough space to 364 assign a /64 per device, today such networks almost universally use 365 SLAAC. 367 Unlike IPv4 where addresses came at a premium, in all these networks, 368 there is enough IPv6 address space to supply clients with multiple 369 IPv6 addresses. 371 9.3. Addressing link layer scalability issues via IP routing 373 The number of IPv6 addresses on a link has direct impact for 374 networking infrastructure nodes (routers, switches) and other nodes 375 on the link. Setting aside exhaustion attacks via Layer 2 address 376 spoofing, every (Layer 2, IP) address pair impacts networking 377 hardware requirements in terms of memory, MLD snooping, solicited 378 node multicast groups, etc. Many of these same impacts can be felt 379 by neighboring hosts. Switching to a DHCPv6 PD model means there are 380 only forwarding decisions, with only one routing entry and one ND 381 cache entry per device on the network. 383 10. Acknowledgements 385 The authors thank Dieter Siegmund, Mark Smith, Sander Steffann, James 386 Woodyatt and Tore Anderson for their input and contributions. 388 11. IANA Considerations 390 This memo includes no request to IANA. 392 12. Security Considerations 394 None so far. 396 13. References 398 13.1. Normative References 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, 402 DOI 10.17487/RFC2119, March 1997, 403 . 405 13.2. Informative References 407 [I-D.ietf-dhc-anonymity-profile] 408 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 409 profile for DHCP clients", draft-ietf-dhc-anonymity- 410 profile-01 (work in progress), June 2015. 412 [I-D.tsvwg-quic-protocol] 413 Jana, J. and I. Swett, "QUIC: A UDP-Based Secure and 414 Reliable Transport for HTTP/2", draft-tsvwg-quic- 415 protocol-01 (work in progress), July 2015. 417 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 418 and E. Lear, "Address Allocation for Private Internets", 419 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 420 . 422 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 423 DOI 10.17487/RFC2993, November 2000, 424 . 426 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 427 C., and M. Carney, "Dynamic Host Configuration Protocol 428 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 429 2003, . 431 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 432 Host Configuration Protocol (DHCP) version 6", RFC 3633, 433 DOI 10.17487/RFC3633, December 2003, 434 . 436 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 437 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 438 2006, . 440 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 441 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 442 2006, . 444 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 445 Address Autoconfiguration", RFC 4862, 446 DOI 10.17487/RFC4862, September 2007, 447 . 449 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 450 Extensions for Stateless Address Autoconfiguration in 451 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 452 . 454 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 455 IPv6 Network Address Translation", RFC 5902, 456 DOI 10.17487/RFC5902, July 2010, 457 . 459 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 460 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 461 2011, . 463 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 464 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 465 Partnership Project (3GPP) Evolved Packet System (EPS)", 466 RFC 6459, DOI 10.17487/RFC6459, January 2012, 467 . 469 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 470 Combination of Stateful and Stateless Translation", 471 RFC 6877, DOI 10.17487/RFC6877, April 2013, 472 . 474 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 475 "Source Address Validation Improvement (SAVI) Framework", 476 RFC 7039, DOI 10.17487/RFC7039, October 2013, 477 . 479 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 480 Interface Identifiers with IPv6 Stateless Address 481 Autoconfiguration (SLAAC)", RFC 7217, 482 DOI 10.17487/RFC7217, April 2014, 483 . 485 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 486 /64 Prefix from a Third Generation Partnership Project 487 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 488 DOI 10.17487/RFC7278, June 2014, 489 . 491 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 492 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 493 Boundary in IPv6 Addressing", RFC 7421, 494 DOI 10.17487/RFC7421, January 2015, 495 . 497 [TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for 498 Related Processes: Improved Firewalling by Using IPv6 and 499 Multiple Addresses per Host", August 2001. 501 Authors' Addresses 503 Lorenzo Colitti 504 Google 505 Roppongi 6-10-1 506 Minato, Tokyo 106-6126 507 JP 509 Email: lorenzo@google.com 511 Vint Cerf 512 Google 513 1600 Amphitheatre Parkway 514 Mountain View, CA 94043 515 US 517 Email: vint@google.com 518 Stuart Cheshire 519 Apple Inc. 520 1 Infinite Loop 521 Cupertino, CA 95014 522 US 524 Email: cheshire@apple.com 526 David Schinazi 527 Apple Inc. 528 1 Infinite Loop 529 Cupertino, CA 95014 530 US 532 Email: dschinazi@apple.com