idnits 2.17.1 draft-colitti-v6ops-host-addr-availability-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 : ---------------------------------------------------------------------------- == 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 23, 2015) is 3199 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) -- Looks like a reference, but probably isn't: '1' on line 487 -- Looks like a reference, but probably isn't: '2' on line 489 -- Looks like a reference, but probably isn't: '3' on line 492 == 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 (==), 8 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: January 24, 2016 S. Cheshire 6 D. Schinazi 7 Apple Inc. 8 July 23, 2015 10 Host address availability recommendations 11 draft-colitti-v6ops-host-addr-availability-01 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 January 24, 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 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 In most aspects, the IPv6 protocol is very similar to IPv4. This 79 similarity can create a tendency to think of IPv6 as 128-bit IPv4, 80 and thus lead network designers and operators to apply identical 81 configurations and operational practices to both. This is generally 82 a good thing because it eases the transition to IPv6 and the 83 operation of dual-stack networks. However, in some areas it can lead 84 to carrying over IPv4 practices that are not appropriate in IPv6 due 85 to significant differences between the protocols. 87 One such area is IP adressing, particularly IP addressing of hosts. 88 This is substantially different because unlike IPv4 addresses, IPv6 89 addresses are not a scarce resource. In IPv6, each link has a 90 virtually unlimited amount of address space [RFC7421]. Thus, unlike 91 IPv4, IPv6 networks are not forced by address availability 92 considerations to assign only one address per host. On the other 93 hand, assigning multiple addresses has many benefits including 94 application functionality and simplicity, privacy, future 95 applications, and the ability to deploy the Internet without the use 96 of NAT. Assigning only one IPv6 address per host negates these 97 benefits. 99 This document describes the benefits of assigning multiple addresses 100 per host and the problems with not doing so. It recommends that 101 networks provide general-purpose end hosts with multiple global 102 addresses when they attach, and lists current options for doing so. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2. Common IPv6 deployment model 112 IPv6 is designed to support multiple addresses, including multiple 113 global addresses, per interface ([RFC4291] section 2.1, [RFC6434] 114 section 5.9.4). Today, many general-purpose IPv6 hosts are 115 configured with three or more addresses per interface: a link-local 116 address, a stable address (e.g., using EUI-64 or [RFC7217]), one or 117 more privacy addresses [RFC4941], and possibly one or more temporary 118 or non-temporary addresses assigned using DHCPv6 [RFC3315]. 120 In most general-purpose IPv6 networks, including all 3GPP networks 121 (see [RFC6459] section 5.2) and Ethernet and Wi-Fi networks using 122 SLAAC [RFC4862], IPv6 hosts have the ability to configure additional 123 IPv6 addresses from the link prefix(es) without explicit requests to 124 the network. 126 3. Benefits of multiple addresses 128 Today, there are many host functions that require more than one IP 129 address to be available to the host: 131 o Privacy addressing to prevent tracking by off-network hosts (e.g., 132 [RFC4941]). 134 o Multiple processors inside the same device. For example, in many 135 mobile devices both the application processor and baseband 136 processor need to communicate with the network, particularly for 137 recent technologies like ePDG. 139 o Extending the network (e.g., tethering). 141 o Running virtual machines on hosts. 143 o Translation-based transition technologies such as 464XLAT that 144 provide IPv4 over IPv6. Current implementations require the 145 availability of a dedicated IPv6 address in order to determine 146 whether inbound packets are translated or native. 148 o ILA ("Identifier-locator addressing"): https://tools.ietf.org/ 149 html/draft-herbert-nvo3-ila 151 o Future applications (e.g., per-application IPv6 addresses, such as 152 described in [TARP]). 154 Example of how the availability of multiple addresses per host has 155 already allowed substantial deployment of new applications without 156 explicit requests to the network are: 158 o 464XLAT [RFC6877]. 464XLAT is usually deployed within a particular 159 network operator's network, but there are deployment models where 160 the PLAT is provided as a service by a different network (e.g., 161 [1]) 163 o /64 sharing [RFC7278]. This was a way to provide IPv6 tethering 164 without needing to wait for network operators to deploy DHCPv6 PD, 165 which is only available in 3GPP release 10. 167 4. Problems with assigning a limited number of addresses per host 169 Assigning a limited number of addresses per host implies that 170 functions that require multiple addresses will either be unavailable 171 (e.g., if the network provides only one IPv6 address per host, or if 172 the host has reached the limit of the number of addresses available), 173 or that the functions will only be available after an explicit 174 request to the network is granted. The necessity of explicit 175 requests has the following drawbacks: 177 o Increased latency, because a provisioning operation, and possibly 178 human intervention with an update to the service level agreement, 179 must complete before the functionality is available. 181 o Uncertainty, because it is not known in advance if a particular 182 operation function will be available. 184 o Complexity, because implementations need to deal with failures and 185 somehow present them to the user. Failures may manifest as 186 timeouts, which may be slow and frustrating to users. 188 o Increased load on the network's provisioning servers. 190 Some operators may desire to configure their networks to limit the 191 number of IPv6 addresses per host. Reasons might include hardware 192 limitations (e.g., TCAM or neighbour cache table size constraints), 193 operational consistency with IPv4 (e.g., an IP address management 194 system that only supports one address per host), or business models 195 (e.g., a desire to charge the network's users on a per-device basis). 197 5. Overcoming limits using Network Address Translation 199 These limits can mostly be overcome by end hosts by using NAT, and 200 indeed in IPv4 most of these functions are provided by using NAT on 201 the host. Thus, the limits could be overcome in IPv6 as well by 202 implementing NAT66 on the host. 204 Unfortunately NAT has well-known drawbacks. For example, it causes 205 application complexity due to the need to implement NAT traversal. 206 It hinders development of new applications. On mobile devices, it 207 reduces battery life due to the necessity of frequent keepalives, 208 particularly for UDP. Applications using UDP that need to work on 209 most of the Internet are forced to send keepalives at least every 30 210 seconds [2]. For example, the QUIC protocol uses a 15-second 211 keepalive [I-D.tsvwg-quic-protocol]. Other drawbacks are described 212 in [RFC2993]. While IPv4 NAT is inevitable due to the limited amount 213 of IPv4 space available, that argument does not apply to IPv6. 214 Guidance 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: [3] ). One reason 324 frequently cited for this is protection from liability for copyright 325 infringement or other illegal activity by maintaining persistent logs 326 that map user IP addresses and timestamps to hardware identifiers 327 such as MAC addresses. 329 It is worth noting that using DHCPv6 does not by itself ensure that 330 hosts will actually use the addresses assigned to them by the network 331 as opposed to using any other address on the prefix. Such guarantees 332 can only be provided by link-layer security mechanisms that enforce 333 that particular IPv6 addresses are used by particular link-layer 334 addresses (for example: SAVI [RFC7039]). If those mechanisms are 335 available, it is possible to use them to provide tracking, instead. 336 This form of tracking is much more reliable because it operates 337 independently of how addresses are allocated. 339 Additionally, attempts to track this sort of information via DHCPv6 340 are likely to become decreasingly viable due to ongoing efforts to 341 improve the privacy of DHCP: [I-D.ietf-dhc-anonymity-profile]. 343 Many large enterprise networks, including the enterprise networks of 344 the authors, are fully dual-stack but do not currently use or support 345 DHCPv6. 347 9.2. Address space management 349 In IPv4, all but the world's largest networks can be addressed using 350 private space [RFC1918], and with each host receiving one IPv4 351 address. Many networks can be numbered in 192.168.0.0/16 which has 352 roughly 64k addresses. In IPv6, that is equivalent to assigning one 353 /64 per host out of a /48. Under current RIR policies, a /48 is easy 354 to obtain for an enterprise network. 356 Networks that need a bigger block of private space use 10.0.0.0/8, 357 which is is roughly 16 million addresses. In IPv6, that is 358 equivalent to assigning a /64 per host out of a /40. Enterprises of 359 such size can easily obtain a /40 under current RIR policies. 361 Currently, residential users receive one IPv4 address and a /48, /56 362 or /60 IPv6 prefix. While such networks do not have enough space to 363 assign a /64 per device, today such networks almost universally use 364 SLAAC. 366 Unlike IPv4 where addresses came at a premium, in all these networks, 367 there is enough IPv6 address space to supply clients with multiple 368 IPv6 addresses. 370 9.3. Addressing link layer scalability issues via IP routing 372 The number of IPv6 addresses on a link has direct impact for 373 networking infrastructure nodes (routers, switches) and other nodes 374 on the link. Setting aside exhaustion attacks via Layer 2 address 375 spoofing, every (Layer 2, IP) address pair impacts networking 376 hardware requirements in terms of memory, MLD snooping, solicited 377 node multicast groups, etc. Many of these same impacts can be felt 378 by neighboring hosts. Switching to a DHCPv6 PD model means there are 379 only forwarding decisions, with only one routing entry and one ND 380 cache entry per device on the network. 382 10. Acknowledgements 384 The authors thank Dieter Siegmund, Mark Smith, Sander Steffann, James 385 Woodyatt and Tore Anderson for their input and contributions. 387 11. IANA Considerations 389 This memo includes no request to IANA. 391 12. Security Considerations 393 None so far. 395 13. References 397 13.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 13.2. Informative References 404 [I-D.ietf-dhc-anonymity-profile] 405 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 406 profile for DHCP clients", draft-ietf-dhc-anonymity- 407 profile-01 (work in progress), June 2015. 409 [I-D.tsvwg-quic-protocol] 410 Jana, J. and I. Swett, "QUIC: A UDP-Based Secure and 411 Reliable Transport for HTTP/2", draft-tsvwg-quic- 412 protocol-01 (work in progress), July 2015. 414 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 415 and E. Lear, "Address Allocation for Private Internets", 416 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 417 . 419 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 420 DOI 10.17487/RFC2993, November 2000, 421 . 423 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 424 and M. Carney, "Dynamic Host Configuration Protocol for 425 IPv6 (DHCPv6)", RFC 3315, July 2003. 427 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 428 Host Configuration Protocol (DHCP) version 6", RFC 3633, 429 December 2003. 431 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 432 Architecture", RFC 4291, February 2006. 434 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 435 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 436 2006, . 438 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 439 Address Autoconfiguration", RFC 4862, September 2007. 441 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 442 Extensions for Stateless Address Autoconfiguration in 443 IPv6", RFC 4941, September 2007. 445 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 446 IPv6 Network Address Translation", RFC 5902, July 2010. 448 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 449 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 450 2011, . 452 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 453 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 454 Partnership Project (3GPP) Evolved Packet System (EPS)", 455 RFC 6459, January 2012. 457 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 458 Combination of Stateful and Stateless Translation", RFC 459 6877, April 2013. 461 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 462 "Source Address Validation Improvement (SAVI) Framework", 463 RFC 7039, DOI 10.17487/RFC7039, October 2013, 464 . 466 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 467 Interface Identifiers with IPv6 Stateless Address 468 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 470 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 471 /64 Prefix from a Third Generation Partnership Project 472 (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 473 2014. 475 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 476 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 477 Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/ 478 RFC7421, January 2015, 479 . 481 [TARP] Gleitz, PM. and SM. Bellovin, "Transient Addressing for 482 Related Processes: Improved Firewalling by Using IPv6 and 483 Multiple Addresses per Host", August 2001. 485 13.3. URIs 487 [1] http://www.jpix.ad.jp/en/service/ipv6v4.html 489 [2] http://www.ietf.org/proceedings/88/slides/ 490 slides-88-tsvarea-10.pdf 492 [3] https://code.google.com/p/android/issues/detail?id=32621#c60 494 Authors' Addresses 496 Lorenzo Colitti 497 Google 498 Roppongi 6-10-1 499 Minato, Tokyo 106-6126 500 JP 502 Email: lorenzo@google.com 504 Vint Cerf 505 Google 506 1600 Amphitheatre Parkway 507 Mountain View, CA 94043 508 US 510 Email: vint@google.com 512 Stuart Cheshire 513 Apple Inc. 514 1 Infinite Loop 515 Cupertino, CA 95014 516 US 518 Email: cheshire@apple.com 519 David Schinazi 520 Apple Inc. 521 1 Infinite Loop 522 Cupertino, CA 95014 523 US 525 Email: dschinazi@apple.com