idnits 2.17.1 draft-narten-ipv6-3177bis-48boundary-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC3177, but the header doesn't have an 'Obsoletes:' line to match this. -- The draft header indicates that this document updates RFC3177, but the abstract doesn't seem to directly say this. It does mention RFC3177 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3177, updated by this document, for RFC5378 checks: 2001-02-02) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5034 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: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Thomas Narten 3 Internet-Draft IBM 4 Intended Status: BCP Geoff Huston 5 Expires: January 13, 2011 APNIC 6 Updates: 3177 Lea Roberts 7 Stanford University 8 July 12, 2010 10 IPv6 Address Assignment to End Sites 12 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 13, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Abstract 66 RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks 67 in most cases. The Regional Internet Registries (RIRs) adopted that 68 recommendation in 2002, but began reconsidering the policy in 2005. 69 This document revisits and updates the RFC 3177 recommendations on 70 the assignment of IPv6 address space to end sites. The exact choice 71 of how much address space to assign end sites is a policy issue under 72 the purview of the RIRs, subject to IPv6 architectural and 73 operational considerations. This document reviews the architectural 74 and operational considerations of end site assignments as well as the 75 motivations behind the original 3177 recommendations. Moreover, the 76 document clarifies that a one-size-fits-all recommendation of /48 is 77 not nuanced enough for the broad range of end sites and is no longer 78 recommended as a single default. 80 This document updates and replaces RFC 3177. 82 Contents 84 Status of this Memo.......................................... 1 86 1. Introduction............................................. 3 88 2. On /48 Assignments to End Sites.......................... 4 90 3. Other RFC 3177 considerations............................ 6 92 4. Impact on IPv6 Standards................................. 7 93 4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds. 7 94 4.2. IPv6 Multicast Addressing........................... 7 96 5. Summary.................................................. 7 98 6. Security Considerations.................................. 8 100 7. IANA Considerations...................................... 8 102 8. Acknowledgments.......................................... 8 104 9. Normative References..................................... 8 106 10. Informative References.................................. 8 108 11. Author's Address........................................ 9 110 1. Introduction 112 There are a number of considerations that factor into address 113 assignment policies. For example, to provide for the long-term health 114 and scalability of the public routing infrastructure, it is important 115 that addresses aggregate well [ROUTE-SCALING]. Likewise, giving out 116 an excessive amount of address space could result in premature 117 depletion of the address space. This document focuses on the (more 118 narrow) question of what is an appropriate IPv6 address assignment 119 size for end sites. That is, when end sites request IPv6 address 120 space from ISPs, what is an appropriate assignment size. 122 RFC 3177 [RFC3177] called for a default end site IPv6 assignment size 123 of /48. Subsequently, the Regional Internet Registries (RIRs) 124 developed and adopted IPv6 address assignment and allocation policies 125 consistent with the RFC 3177 recommendations [RIR-IPV6]. In 2005, the 126 RIRs began discussing IPv6 address assignment policy again. Since 127 then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE] and RIPE [RIPE- 128 ENDSITE] have revised the end site assignment policy to encourage the 129 assignment of smaller (i.e., /56) blocks to end sites. Additional 130 history and discussion of IPv6 address policy and its long-term 131 implications can be found in [IPV6-HISTORY]. 133 This document updates and replaces the RFC 3177 recommendations. 135 Specifically, this document updates RFC 3177 in the following ways: 137 1) It is no longer recommended that /128s be given out. While there 138 may be some cases where assigning only a single address may be 139 justified, a site by definition implies multiple subnets and 140 multiple devices. 142 2) RFC 3177 specifically recommended using prefix lengths of /48, 143 /64 and /128. Specifying a small number of fixed boundaries has 144 raised concerns that implementations and operational practices 145 might become "hard-coded" to recognize only those fixed 146 boundaries (i.e., a return to "classful addressing"). The actual 147 intention has always been that there be no hard-coded boundaries 148 within addresses, and that CIDR continues to apply to all bits 149 of the routing prefixes. 151 3) This document moves away from the previous recommendation that a 152 single default assignment size (e.g., a /48) makes sense for all 153 end sites in the general case. End sites come in different 154 shapes and sizes, and a one-size-fits-all approach is not 155 necessary or appropriate. 157 This document does, however, reaffirm an important assumption behind 158 RFC 3177: 160 A key principle for address management is that end sites always 161 be able to obtain a reasonable amount of address space for their 162 actual and planned usage, and over time ranges specified in 163 years rather than just months. In practice, that means at least 164 one /64, and in most cases significantly more. One particular 165 situation that must be avoided is having an end site feel 166 compelled to use IPv6-to-IPv6 Network Address Translation or 167 other burdensome address conservation techniques because it 168 could not get sufficient address space. 170 This document does not make a formal recommendation on what the exact 171 assignment size should be. The exact choice of how much address 172 space to assign end sites is a policy issue under the purview of the 173 RIRs, subject to IPv6 architectural and operational considerations. 174 This document provides input into those discussions. The focus of 175 this document is to examine the architectural issues and some of the 176 operational considerations relating to the size of the end site 177 assignment. 179 2. On /48 Assignments to End Sites 181 Looking back at some of the original motivations behind the /48 182 recommendation [RFC3177], there were three main concerns. The first 183 motivation was to ensure that end sites could easily obtain 184 sufficient address space without having to "jump through hoops" to do 185 so. For example, if someone felt they needed more space, just the act 186 of asking would at some level be sufficient justification. As a 187 comparison point, in IPv4, typical home users are given a single 188 public IP address (though even this is not always assured), but 189 getting any more than one address is often difficult or even 190 impossible -- unless one is willing to pay a (significantly) 191 increased fee for what is often considered to be a "higher grade" of 192 service. (It should be noted that increased ISP charges to obtain a 193 small number of additional addresses cannot usually be justified by 194 the real per-address cost levied by RIRs, but additional addresses 195 are frequently only available to end users as part of a different 196 type or "higher grade" of service, for which an additional charge is 197 levied. The point here is that the additional cost is not due to the 198 RIR fee structures, but to business choices ISPs make.) An important 199 goal in IPv6 is to significantly change the default and minimal end 200 site assignment, from "a single address" to "multiple networks" and 201 to ensure that end sites can easily obtain address space. 203 A second motivation behind the original /48 recommendation was to 204 simplify the management of an end site's addressing plan in the 205 presence of renumbering (e.g., when switching ISPs). In IPv6, a site 206 may simultaneously use multiple prefixes, including one or more 207 public prefixes from ISPs as well as Unique Local Addresses [ULA- 208 ADDRESSES]. In the presence of multiple prefixes, it is significantly 209 less complex to manage a numbering plan if the same subnet numbering 210 plan can be used for all prefixes. That is, for a link that has (say) 211 three different prefixes assigned to it, the subnet portion of those 212 prefixes would be identical for all assigned addresses. In contrast, 213 renumbering from a larger set of "subnet bits" into a smaller set is 214 often painful, as it it can require making changes to the network 215 itself (e.g., collapsing subnets). Hence renumbering a site into a 216 prefix that has (at least) the same number of subnet bits is more 217 straightforward, because only the top-level bits of the address need 218 to change. A key goal of the RFC 3177 recommendations is to ensure 219 that upon renumbering, one does not have to deal with renumbering 220 into a smaller subnet size. 222 It should be noted that similar arguments apply to the management of 223 zone files in the DNS. In particular, managing the reverse (ip6.arpa) 224 tree is simplified when all links are numbered using the same subnet 225 ids. 227 A third motivation behind the /48 recommendation was to better 228 support network growth common at many sites. In IPv4, it is usually 229 difficult (or impossible) to obtain public address space for more 230 than a few months worth of projected growth. Thus, even slow growth 231 over several years can lead to the need to renumber into a larger 232 address blocks. With IPv6's vast address space, end sites can easily 233 be given more address space (compared with IPv4) to support expected 234 growth over multi-year time periods. 236 While the /48 recommendation does simplify address space management 237 for end sites, it has also been widely criticized as being wasteful. 238 For example, a large business (which may have thousands of employees) 239 would by default receive the same amount of address space as a home 240 user, who today typically has a single (or small number of) LANs and 241 a small number of devices (dozens or less). While it seems likely 242 that the size of a typical home network will grow over the next few 243 decades, it is hard to argue that home sites will make use of 65K 244 subnets within the foreseeable future. At the same time, it might be 245 tempting to give home sites a single /64, since that is already 246 significantly more address space compared with today's IPv4 practice. 247 However, this precludes the expectation that even home sites will 248 grow to support multiple subnets going forward. Hence, it is strongly 249 intended that even home sites be given multiple subnets worth of 250 space by default. Hence, this document still recommends giving home 251 sites significantly more than a single /64, but does not recommend 252 that every home site be given a /48 either. 254 A change in policy (such as above) would have a significant impact on 255 address consumption projections and the expected longevity for IPv6. 256 For example, changing the default assignment from a /48 to /56 (for 257 the vast majority of end sites, e.g, home sites) would result in a 258 savings of up to 8 bits, reducing the "total projected address 259 consumption" by (up to) 8 bits or two orders of magnitude. (The exact 260 amount of savings depends on the relative number of home users 261 compared with the number of larger sites.) 263 The above-mentioned RFC3177 goals can easily be met by giving home 264 users a default assignment of less than /48, such as a /56. 266 3. Other RFC 3177 considerations 268 RFC3177 suggested that some multihoming approaches (e.g., GSE) might 269 benefit from having a fixed /48 boundary. This no longer appears to 270 be a consideration. 272 RFC3177 argued that having a "one size fits all" default assignment 273 size reduced the need for customers to continually or repeatedly 274 justify usage of existing address space in order to get "a little 275 more". Likewise, it also reduces the need for ISPs to evaluate such 276 requests. Given the large amount of address space in IPv6, there is 277 plenty of space to grant end sites enough space to be consistent with 278 reasonable growth projections over multi-year time frames. Thus, it 279 remains highly desirable to provide end sites with enough space (on 280 both initial and subsequent assignments) to last several years. 281 Fortunately, this goal can be achieved in a number of ways and does 282 not require that all end sites receive the same default size 283 assignment. 285 4. Impact on IPv6 Standards 287 4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds 289 RFC3056 [RFC3056] describes a way of generating IPv6 addresses from 290 an existing public IPv4 address. That document describes an address 291 format in which the first 48 bits concatenate a well-known prefix 292 with a globally unique public IPv4 address. The "SLA ID" field is 293 assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To 294 facilitate transitioning from an RFC3056 address numbering scheme to 295 one based on a prefix obtained from an ISP, an end site would be 296 advised to number out of the right most bits first, using the left 297 most bits only if the size of the site made that necessary. 299 Similar considerations apply to other documents that allow for a 300 subnet id of 16 bits, including [ULA-ADDRESSES]. 302 4.2. IPv6 Multicast Addressing 304 Some IPv6 multicast address assignment schemes embed a unicast IPv6 305 prefix into the multicast address itself [RFC3306]. Such documents do 306 not assume a particular size for the subnet id per se, but do assume 307 that the IPv6 prefix is a /64. Thus, the relative size of the subnet 308 id has no direct impact on multicast address schemes. 310 5. Summary 312 The exact choice of how much address space to assign end sites is a 313 policy issue under the purview of the RIRs, subject to IPv6 314 architectural and operational considerations. The RFC 3177 [RFC3177] 315 recommendation to assign /48s as a default is not a requirement of 316 the IPv6 architecture; anything of length /64 or shorter works from a 317 standards perspective. However, there are important operational 318 considerations as well, some of which are important if users are to 319 share in the key benefit of IPv6: expanding the usable address space 320 of the Internet. The IETF recommends that any policy on IPv6 address 321 assignment policy to end sites take into consideration: 323 - it should be easy for an end site to obtain address space to 324 number multiple subnets (i.e., a block larger than a single /64) 325 and to support reasonable growth projections over long time 326 periods (e.g., a decade or more). 328 - the default assignment size should take into consideration the 329 likelihood that an end site will have need for multiple subnets 330 in the future and avoid the IPv4 practice of having frequent and 331 continual justification for obtaining small amounts of 332 additional space 334 - Although a /64 can (in theory) address an almost unlimited 335 number of devices, sites should be given sufficient address 336 space to be able to lay out subnets as appropriate, and not be 337 forced to use address conservation techniques such as using 338 bridging. Whether or not bridging is an appropriate choice is an 339 end site matter. 341 - assigning a longer prefix to an end site, compared with the 342 existing prefixes the end site already has assigned to it, is 343 likely to increase operational costs and complexity for the end 344 site, with insufficient benefit to anyone. 346 - the operational considerations of managing and delegating the 347 reverse DNS tree under ip6.arpa on nibble vs. non-nibble 348 boundaries should be given adequate consideration 350 6. Security Considerations 352 This document has no known security implications. 354 7. IANA Considerations 356 This document makes no requests to IANA. 358 8. Acknowledgments 360 This document was motivated by and benefited from numerous 361 conversations held during the ARIN XV and RIPE 50 meetings in April- 362 May, 2005. 364 9. Normative References 366 10. Informative References 368 [APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment 369 and utilisation requirement policy," 370 http://www.apnic.net/policy/proposals/prop-031-v002.html 372 [ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and 373 utilisation requirement", 374 http://www.arin.net/policy/proposals/2005_8.html 376 [IPV6-HISTORY] Issues Related to the Management of IPv6 Address 377 Space, draft-narten-iana-rir- 378 ipv6-considerations-00.txt 380 [RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE 381 Document ID: ripe-267, Date: 22 January 2003 382 http://www.ripe.net/ripe/docs/ipv6policy.html; 383 APNIC: 384 http://www.apnic.net/docs/policy/ipv6-address- 385 policy.html 387 [RFC3056] "Connection of IPv6 Domains via IPv4 Clouds," B. Carpenter, 388 K. Moore, RFC 3056, February 2001. 390 [RFC3306] "Unicast-Prefix-based IPv6 Multicast Addresses," B. 391 Haberman, D. Thaler, RFC 3306, August 2002. 393 [RFC3177] IAB/IESG Recommendations on IPv6 Address Allocations to 394 Sites. IAB, IESG. September 2001. 396 [RIPE-ENDSITE] "Proposal to Amend the IPv6 Assignment and Utilisation 397 Requirement Policy", 2005-8, 398 http://ripe.net/ripe/policies/proposals/2005-08.html 400 [ROUTE-SCALING] "Routing and Addressing Problem Statement", draft- 401 narten-radir-problem-statement-05.txt 403 [ULA-ADDRESSES] RFC 4193 "Unique Local IPv6 Unicast Addresses," R. 404 Hinden, B. Haberman, RFC 4193, October 2005. 406 11. Author's Address 408 Thomas Narten 409 IBM Corporation 410 3039 Cornwallis Ave. 411 PO Box 12195 412 Research Triangle Park, NC 27709-2195 414 Phone: 919-254-7798 415 EMail: narten@us.ibm.com 417 Geoff Huston 418 APNIC 420 EMail: gih@apnic.net 422 Rosalea G Roberts 423 Stanford University, Networking Systems 424 P.O. Box 19131 425 Stanford, CA 94309-9131 427 Email: lea.roberts@stanford.edu 428 Phone: +1-650-723-3352