idnits 2.17.1 draft-palet-v6ops-rfc6177-bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2018) is 2019 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) -- Obsolete informational reference (is this intentional?): RFC 3177 (Obsoleted by RFC 6177) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations (v6ops) J. Palet Martinez 3 Internet-Draft The IPv6 Company 4 Obsoletes: 6177 (if approved) L. Roberts 5 Intended status: Best Current Practice Stanford University, UIT 6 Expires: April 12, 2019 October 9, 2018 8 IPv6 Address Assignment to End-Sites 9 draft-palet-v6ops-rfc6177-bis-02 11 Abstract 13 The Regional Internet Registries (RIRs) policies have different views 14 regarding the recommendation of the prefix to be assigned to end- 15 sites. However, all them allow up to a /48 without further 16 justification and clearly state that the exact choice of how much 17 address space should be assigned to end-sites is a decision of each 18 operator. 20 This document reviews the architectural and operational 21 considerations of end-site assignments, and reiterates that 22 assignment policy and guidelines belong to the RIR community. This 23 revision is being made to emphasize that IPv6 protocol evolution 24 requires an ever-increasing availability of subnets at the end-site, 25 so policy should reflect that assignment of a single subnet is never 26 recommended. 28 This document obsoletes RFC6177 (IPv6 Address Assignment to End 29 Sites). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 12, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Considerations Regarding the Prefix Length . . . . . . . . . 4 67 3. On /48 Assignments to End-Sites . . . . . . . . . . . . . . . 5 68 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Informative References . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 There are a number of considerations that factor into address and 78 prefix assignment policies. For example, to provide for the long- 79 term health and scalability of the public routing infrastructure, it 80 is important that prefixes aggregate well [Route-Scaling]. Likewise, 81 giving out an excessive amount of address space could result in 82 premature depletion of the address space. This document focuses on 83 the (narrower) question of what is an appropriate IPv6 address 84 assignment size for end-sites. That is, when end-sites request IPv6 85 address space from ISPs, what is an appropriate assignment size. 87 [RFC3177] called for a default end-site IPv6 assignment size of /48. 88 Subsequently, the Regional Internet Registries (RIRs) developed and 89 adopted IPv6 address assignment and allocation policies consistent 90 with ISP practices, and it triggered the development of [RFC6177]. 91 Current RIR policies still allow using /48, but leave the decision in 92 the hands of the ISP. In some cases, encourage the assignment /48 93 blocks for all, while other RIRs encourage the assignment of smaller 94 (e.g., /56) blocks to residential end-sites, while keeping /48 for 95 business. 97 More recently, a Global IPv6 Deployment Survey (for residential/ 98 household services) has been conducted since May 2016, with responses 99 from over 1.559 ISPs, from 105 different countries, which latest 100 results have been presented in January 2018 [IPv6-Survey]. This 101 survey is showing that 23% of the responders (generally in more 102 advanced countries, in terms of IPv6 deployment) assign a /48, 35% 103 assign a /56 and 33% assign a single /64. 105 This raises the question of over-zealous interpretation of [RFC6177] 106 by at least one third of the ISP community and consequently, the need 107 to revisit it. 109 This document obsoletes [RFC6177], updating its recommendations in 110 the following ways: 112 1. It is extremely discouraged that /128s are assigned. While there 113 may be some applications where assigning only a single address 114 may be tolerated (e.g., an IoT object), a site, by definition, 115 implies multiple subnets and multiple devices. Also, a /128 116 prevents any form of privacy-based addressing. 118 2. [RFC3177] specifically recommended using prefix lengths of /48, 119 /64, and /128. Specifying a small number of fixed boundaries has 120 raised concerns that implementations and operational practices 121 might become "hard-coded" to recognize only those fixed 122 boundaries (i.e., a return to "classful addressing"). The actual 123 intention has always been that there must be no hard-coded 124 boundaries within addresses, and that Classless Inter-Domain 125 Routing (CIDR) continues to apply to all bits of the routing 126 prefixes [RFC7608]. 128 3. [RFC6177] moved away from the previous recommendation that a 129 single default assignment size (e.g., a /48) makes sense for all 130 end-sites in the general case. End-sites come in different 131 shapes and sizes, and a one-size-fits-all approach is not 132 necessary or appropriate. 134 4. This revision has been created to more clearly assert the 135 requirement to ensure that address assignments to end-sites 136 provide a sufficiently big number of subnets (/64 on classic 137 networks) to each end-site, taking under consideration the end- 138 site's future expected needs, new deployment expectations and new 139 protocol requirements, among others. Once all these are 140 considered, it seems unlikely that a single subnet (/64) or even 141 a small number of them should be assigned. 143 This document reaffirms, as [RFC6177] did, an important assumption 144 behind [RFC3177], using however, a much stronger and clearer 145 language: 147 A key principle for address management is that end-sites always be 148 able to obtain a reasonable number of /64 subnets for their actual 149 and planned usage, and over time ranges specified in many years, 150 probably decades, rather than just months. In practice, that 151 means that a single /64 subnet is not a choice, even for a small 152 residential network, which following technology trends will need a 153 sufficiently big number of /64 subnets. One particular situation 154 that must be avoided is having an end-site feel compelled to use 155 IPv6-to-IPv6 Network Address Translation or other burdensome 156 address conservation techniques (e.g., [RFC7278]) because it could 157 not get sufficient address space. 159 This document does not make a formal recommendation on what the exact 160 assignment size should be, beyond what has been indicated in the 161 precedent paragraph. The exact choice of how much address space to 162 assign end-sites is an operational issue and under that context, 163 discussed already in [RIPE-690]. 165 The IETF's role in this case is limited to providing guidance on IPv6 166 architectural and operational considerations. This document provides 167 input into those discussions. The focus of this document is to 168 examine the architectural issues and some of the operational 169 considerations relating to the size of the end-site assignment. 171 2. Considerations Regarding the Prefix Length 173 [RFC7608] already discusses about the IPv6 prefix length 174 recommendations for forwarding, and the need for routing and 175 forwarding implementations to ensure that longest-prefix-match works 176 on any prefix length. 178 Any prefix length up to /128 is treated identically by routing 179 protocols, however for a given network, end-site, subnet or link, 180 there always exists a Longest Acceptable Prefix (LAP, 181 [I-D.carpenter-6man-lap]), whose length is locally determined, e.g., 182 a site or link that uses SLAAC has a LAP of /64 and will not work 183 with a longer one. 185 This consideration should be noticed, across this document, in the 186 sense that end-sites usually have subnets that use, by default, 187 SLAAC, and consequently, the LAP is mandatorily a /64. Future 188 technologies, may have a different LAP, which must be used 189 accordingly. 191 3. On /48 Assignments to End-Sites 193 Looking back at some of the original motivations behind the /48 194 recommendation [RFC3177], there were three main concerns. The first 195 motivation was to ensure that end-sites could easily obtain 196 sufficient address space without having to "jump through hoops" to do 197 so. For example, if someone felt they needed more space, just the 198 act of asking would at some level be sufficient justification. As a 199 comparison point, in IPv4, typical home users are given a single 200 public IP address (though even this is not always assured), but 201 getting any more than one address is often difficult or even 202 impossible -- unless one is willing to pay a (significantly) 203 increased fee for what is often considered to be a "higher grade" of 204 service. It should be noted that increased ISP charges to obtain a 205 small number of additional addresses cannot usually be justified by 206 the real per-address cost levied by RIRs, but additional addresses 207 are frequently only available to end users as part of a different 208 type or "higher grade" of service, for which an additional charge is 209 levied. The point here is that the additional cost is not due to the 210 RIR fee structures, but to business choices ISPs make. An important 211 goal in IPv6 is to significantly change the default and minimal end 212 site assignment, from "a single address" to "multiple networks" and 213 to ensure that end-sites can easily obtain address space. 215 Furthermore, as the operational costs of carrier-grade NAT and 216 address+port sharing have shown, availability of multiple addresses 217 and prefixes to end-sites will be a considerable saving to their 218 ISPs. 220 It might be tempting to give home sites a single /64, since that is 221 already significantly more address space compared with today's IPv4 222 practice. However, this precludes the certainty that even home sites 223 will grow to support multiple subnets going forward, as expected by 224 the "IPv6 Home Networking Architecture" [RFC7368]. Hence, it is 225 strongly intended that even home sites be given a big number of 226 subnets worth of space, by default. Hence, this document still 227 recommends giving home sites significantly many more than a single 228 /64. 230 A second motivation behind the original /48 recommendation was to 231 simplify the management of an end-site's addressing plan in the 232 presence of renumbering (e.g., when switching ISPs). In IPv6, a site 233 may simultaneously use multiple prefixes, including one or more 234 public prefixes from ISPs as well as Unique Local Addresses 235 [RFC4193]. In the presence of multiple prefixes, it is significantly 236 less complex to manage a numbering plan if the same subnet numbering 237 plan can be used for all prefixes. That is, for a link that has 238 (say) three different prefixes assigned to it, the subnet portion of 239 those prefixes would be identical for all assigned addresses. In 240 contrast, renumbering from a larger set of "subnet bits" into a 241 smaller set is often painful, as it can require making changes to the 242 network itself (e.g., collapsing subnets). Hence, renumbering a site 243 into a prefix that has (at least) the same number of subnet bits is 244 more straightforward, because only the top-level bits of the address 245 need to change. A key goal of the recommendations in [RFC3177] was 246 to ensure that upon renumbering, one does not have to deal with 247 renumbering into a smaller subnet size. In particular, this would 248 apply to any site that switches to an ISP that provides a longer 249 prefix. 251 It should be noted that similar arguments apply to the management of 252 zone files in the DNS. In particular, managing the reverse 253 (ip6.arpa) tree is simplified when all links are renumbered using the 254 same subnet ids. 256 Furthermore, to keep addressing plans usable and understandable, and 257 to align with DNS reverse zone delegations, the size of the assigned 258 prefix should be aligned with a nibble boundary. Each hexadecimal 259 character in an IPv6 prefix represents one nibble, which is 4 bits. 260 The length of a delegated prefix should therefore always be a 261 multiple of 4, so the possible choices are /48, /52, /56 and /60. 263 A third motivation behind the /48 recommendation was to better 264 support network growth common at many sites. In IPv4, it is usually 265 difficult (or impossible) to obtain public address space for more 266 than a few months' worth of projected growth. Thus, even slow growth 267 over several years can lead to the need to renumber into a larger 268 address block. With IPv6's vast address space, end-sites can easily 269 be given more address space (compared with IPv4) to support expected 270 growth over multi-year time periods. 272 While the /48 recommendation does simplify address space management 273 for end-sites, it has also been widely criticized as being wasteful. 274 While reasonable people may disagree over whether all end sites 275 should get a /48 assignment by default, reasonable people do agree 276 that an end-site should be able to get up to a /48 by request. It is 277 important to stress that the strength of IPv6 is the vast size of its 278 address space, which should allow users to easily acquire as many 279 subnets as required for their applications, plus room to grow. 280 Math's show that even assuming 32 billion of humans (2^35), and 281 assigning each of them 4 /48's, with a 50% routing efficiency, we can 282 repeat that 2^10 times, so if average life span of each human is 100 283 years, and we don't recover back the /48's, we will be able to use 284 IPv6 addressing space for over 102.400 years. 286 This document does not advocate careless use of address space, but 287 shows that there is objectively no reason to be restrictive. It is 288 important to leave behind the mind set of IPv4 address scarcity and 289 embrace the wealth of IPv6 address abundance. 291 A large business (which may have thousands of employees) would, by 292 default, receive the same amount of address space, for each of its 293 end-sites, as a home user. However, it is clear that that for each 294 corporate end-site it is perfectly feasible to justify further needs 295 if that becomes the case, and RIR policies allow that. 297 Today typically, a home has already a considerable number of possible 298 subnets (a common CE has 4 LAN ports, 2 WiFi radios which support 299 several SSIDs each one, VoIP subnet, IPTV subnet, additional VLANs) 300 and if downstream routers are used, there is a need for further 301 subnets. This means that in a short term, assigning a /60 (16 302 subnets), it is already a really bad decision. 304 It will become very common that homes start using technologies like 305 HNCP [RFC7788], and this increases the need for more subnets, which 306 means that /56 (256 subnets) may be too short also in very few years. 308 Finally, considerations about multiple addresses per host [RFC7934] 309 and techniques to allow a single /64 per host/interface [RFC7934], 310 means that we will see in the short term, many home devices that will 311 take advantage of that, either for security reasons, or because they 312 may need to run internally multiple virtual machines, or many other 313 reasons, which will again, push the limit of the regular home needs, 314 beyond the /56, and consequently, suggesting that /48 is a smarter 315 choice. 317 The above-mentioned goals of [RFC3177] could be met by giving home 318 users a default assignment of less than /48, such as a /56, as 319 suggested in [RFC6177], however, there are new motivations and 320 technologies, to reconsider that a /48 is a much better choice. 322 4. Summary 324 The exact choice of how much address space to assign end-sites is an 325 issue for the operational community, discussed with much more detail 326 in a recent document [RIPE-690]. 328 While the recommendation to assign /48s as a default, is not a 329 requirement of the IPv6 architecture and anything of length /64 or 330 shorter works from a standards perspective, there are important 331 operational considerations as well, some of which are important if 332 users are to share in the key benefit of IPv6: expanding the usable 333 address space of the Internet. 335 The IETF recommends that any policy on IPv6 address assignment to 336 end-sites take into consideration the following: 338 a. It should be easy and inexpensive for an end-site to obtain 339 address space to deploy a sufficiently big number of subnets 340 (i.e., a big number of /64's) and to support reasonable growth 341 projections over long time periods (e.g., more than a decade). 343 b. An end-user should be able to receive any prefix length up to /48 344 simply by asking. it is critical that the community shed the 345 restrictive view of IP addresses that grew up during the end of 346 IPv4. IPv6 addresses should be freely available, not a tiered 347 cost structure. 349 c. The default assignment size should take into consideration the 350 likelihood that an end-site will have need for multiple subnets 351 in the near future and many more in a medium and longer terms, 352 avoiding the IPv4 practice of having frequent and continual 353 justification for obtaining small amounts of additional space. 355 d. Although a /64 can (in theory) address an almost unlimited number 356 of devices, end-sites should be given sufficient address space to 357 be able to lay out subnets as appropriate, and not be forced to 358 use address conservation techniques such as using bridging, NAT, 359 proxy or other techniques. Whether or not those techniques are 360 an appropriate choice is an end-site matter. 362 e. Assigning a longer prefix to an end-site, compared with the 363 existing prefixes the end-site already has assigned to it, is 364 likely to increase operational costs and complexity for the end- 365 site, with insufficient benefit to anyone. 367 f. The operational considerations of managing and delegating the 368 reverse DNS tree under ip6.arpa on nibble versus non-nibble 369 boundaries should be given adequate consideration. 371 As a consequence, it is strongly discouraged to assign to end-sites a 372 single /64 or even a reduced number of them. 374 Instead, it is strongly suggested considering a /48, or 375 alternatively, a trade-off choice is to reserve a /48 for each end- 376 site, and actually assign them only the first /56, so in the future 377 renumbering is not needed and either in a case by case, by demand, or 378 across all the network, the complete /48 can be re-assigned to each 379 end-site. 381 The considerations of this document are meant mainly for end-sites, 382 regardless of being connected by cellular, wired or other 383 technologies. They don't apply to single cellular devices such as 384 smartphones, which typically will get a single /64 for each 385 connection (PDP context). Even in the case of a handset, assigning a 386 single /64 may require some hacks on the handset, for example to 387 support tethering. This is typically the reason [RFC7849] argued for 388 aligning prefix assignments practices in both cellular and wired 389 networks. Indeed, cellular networks are more and more perceived as 390 an alternative to non-cellular networks for home IP-based services 391 delivery; especially with the advent of 3GPP data dongles. There is 392 a need for an efficient mechanism to assign larger prefixes to 393 cellular hosts so that each LAN segment can get its own /64 prefix 394 and multi-link subnet issues to be avoided. The support of this 395 functionality in both cellular and non-cellular networks is key for 396 fixed-mobile convergence. 398 A broadband cellular router connecting an end-site falls within the 399 scope of this document. 401 5. Security Considerations 403 A shorter prefix has more potential space for scanning attacks, which 404 would require more time, especially if the subnets and hosts are 405 "sparsely assigned". 407 More prefix space allows the use of slightly randomized prefixes and/ 408 or prefix-per-host [RFC8273]. 410 The use of /128 would prevent any form of privacy-based addressing. 412 6. IANA Considerations 414 This document has no actions for IANA. 416 7. Acknowledgements 418 The authors of this document will like to acknowledge the authors and 419 contributors of previous versions ([RFC3177], [RFC6177]) and the 420 inputs to this version from Brian Carpenter, Mohamed Boucadair, Dusan 421 Mudric, David Farmer, Fred Baker, Barbara Stark, Rajiv Asati, Owen 422 DeLong, .... TBD. 424 8. Informative References 426 [I-D.carpenter-6man-lap] 427 Carpenter, B., "The Longest Acceptable Prefix for IPv6 428 Links", draft-carpenter-6man-lap-01 (work in progress), 429 June 2018. 431 [IPv6-Survey] 432 Palet Martinez, J., "IPv6 Deployment Survey (Residential/ 433 Household Services)", January 2018, 434 . 437 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 438 Allocations to Sites", RFC 3177, DOI 10.17487/RFC3177, 439 September 2001, . 441 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 442 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 443 . 445 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 446 Assignment to End Sites", BCP 157, RFC 6177, 447 DOI 10.17487/RFC6177, March 2011, 448 . 450 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 451 /64 Prefix from a Third Generation Partnership Project 452 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 453 DOI 10.17487/RFC7278, June 2014, 454 . 456 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 457 Weil, "IPv6 Home Networking Architecture Principles", 458 RFC 7368, DOI 10.17487/RFC7368, October 2014, 459 . 461 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 462 Length Recommendation for Forwarding", BCP 198, RFC 7608, 463 DOI 10.17487/RFC7608, July 2015, 464 . 466 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 467 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 468 2016, . 470 [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, 471 N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, 472 "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, 473 DOI 10.17487/RFC7849, May 2016, 474 . 476 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 477 "Host Address Availability Recommendations", BCP 204, 478 RFC 7934, DOI 10.17487/RFC7934, July 2016, 479 . 481 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 482 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 483 . 485 [RIPE-690] 486 RIPE, "Best Current Operational Practice for Operators: 487 IPv6 prefix assignment for end-users - persistent vs non- 488 persistent, and what size to choose", October 2017, 489 . 491 [Route-Scaling] 492 "Routing and Addressing Problem Statement", February 2010, 493 . 496 Authors' Addresses 498 Jordi Palet Martinez 499 The IPv6 Company 500 Molino de la Navata, 75 501 La Navata - Galapagar, Madrid 28420 502 Spain 504 EMail: jordi.palet@theipv6company.com 505 URI: http://www.theipv6company.com/ 507 Rosalea G Roberts 508 Stanford University, UIT 509 P.O. Box 19131 510 Stanford CA 94309-9131 512 Phone: +1-650-723-3352 513 EMail: lea.roberts@stanford.edu