INTERNET-DRAFT Thomas Narten IBM Geoff Huston APNIC Lea Roberts Stanford University July 11, 2005 IPv6 Address Allocation to End Sites Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft expires on January 11, 2006. Abstract This document revisits the IAB/IESG recommendations on the assignment of IPv6 address space to end sites. Specifically, it indicates that changing the default end-site assignment for typical home and SOHO sites from /48 to /56 is consistent with the goals of IPv6 and RFC 3177. Although it is for the RIR community to make adjustments to the IPv6 address space allocation and end site assignment policies, the IETF community would be comfortable with RIRs changing the default draft-narten-ipv6-3177bis-48boundary-00.txt [Page 1] INTERNET-DRAFT July 11, 2005 assignment size to /56 for smaller end sites. This document obsoletes RFC 3177 and reclassifies it as historic. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 2. On /48 Assignments to End Sites.......................... 3 3. Other RFC 3177 considerations............................ 5 4. Security Considerations.................................. 5 5. IANA Considerations...................................... 6 6. Acknowledgments.......................................... 6 7. Normative References..................................... 6 8. Informative References................................... 6 9. Author's Address....................................... 6 1. Introduction RFC 3177 [RFC3177] called for the default IPv6 assignment size to end sites being a /48. Subsequently, the RIRs developed and adopted IPv6 address assignment and allocation policies consistent with the RFC 3177 recommendations [RIR-IPV6]. In addition to the /48 recommendation, an HD-Ratio metric [RFC 3194] of .8 was adopted to determine how much space an LIR can obtain from an RIR, and when an LIR may go back to an RIR for an additional allocation. Additional history and discussion of IPv6 address policy and its long-term implications can be found in [IPV6-HISTORY]. By late 2004, informal discussions began raising the question of whether the current IPv6 address allocation policies were achieving a proper balance between conservation and ease of access. In particular, projections of address space usage over the next 50-100 years under the existing RIR assignment and allocation policies indicate that one cannot argue that IPv6 has an "infinite supply" of addresses. Furthermore, there are plausible scenarios where a significant fraction of the total IPv6 address space could be consumed in 60 years. For example, projections show a consumption range of /7 [IPV6-HISTORY] all the way to a /1 (or 1/2 of the entire draft-narten-ipv6-3177bis-48boundary-00.txt [Page 2] INTERNET-DRAFT July 11, 2005 IPv6 address space) [HUSTON-RIPE]. Due to the inherent uncertainties in long-term address consumption rates, and the difficulties that arise when operating in an environment where address depletion becomes a real concern (i.e., the current IPv4 experience) it would be prudent for the RIRs to update and revise the current IPv6 address allocation and assignment policies to ensure that IPv6 address space remains plentiful across the next 50-100 years. This document performs three functions: 1) It revisits the RFC 3177 recommendations and makes the case that the default IPv6 assignment size for smaller end sites could be changed from /48 to /56 with essentially no impact on end users. In addition, there are no impacts on existing IPv6 standards or implementations. 2) It is a message to the RIR community that the IETF community would be comfortable with the RIR community revising and updating its IPv6 assignment policy to change the default end assignment for small end sites to a /56. 3) It obsoletes RFC 3177 and reclassifies it historic. 2. On /48 Assignments to End Sites [note: this section was taken mostly verbatim from Section 5.2 of [IPV6-HISTORY]; future versions will decide how to better split the text between the two documents, since it is generally not ideal to have the identical text in multiple documents.] Per existing policy, the RIRs assume that end site assignments are /48s, and thus utilization measurements are based on an HD-ratio that counts numbers of /48 assignments. Granting a /48 to an end site, allows a site to have up to 65,536 subnets. While that number may make sense for larger sites, it is hard to imagine a typical home user requiring so much space. Indeed, the default end site assignment today is in practice the same for home users and larger businesses. Looking back at some of the original motivations behind the /48 recommendation [RFC 3177], one overriding concern was to ensure that end sites could easily obtain sufficient address space without having to "jump through hoops" to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification. As a comparison point, in IPv4, typical home users are given a single public IP address (even this is not draft-narten-ipv6-3177bis-48boundary-00.txt [Page 3] INTERNET-DRAFT July 11, 2005 always assured), but getting even a small number more is typically more expensive either in terms of the effort needed to obtain additional addresses, or in the actual monthly cost. (It should be noted that the "cost" of additional addresses cannot be justified by the actual cost of those addresses as charged by the RIRs, but the need for additional addresses is sometimes used to imply a different type or "higher grade" of service, for which some ISPs charge extra.) Thus, an important goal in IPv6 was to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks". Another concern was that if a site changes ISPs and subsequently renumbers, renumbering from a larger set of "subnet bits" into a smaller set is particularly painful, as it it can require making changes to the network itself (e.g., collapsing links). In contrast, renumbering a site into a prefix that has the same number (or more) of subnet bits is easier, because only the top-level bits of the address need to change. Thus, another goal of the RFC 3177 recommendation is to ensure that upon renumbering, one does not have to deal with renumbering into a smaller subnet size. The above concerns were met by the /48 recommendation, but could also be realized through a more conservative approach. For example, one can imagine "classes" of network types, with default sizes for each class. For example: - a PDA-type device with a low bandwidth WAN connection and one additional PAN connection - a single network or /64 assignment. A /64 assignment allows for the addressing of a number of hosts, each connected to the same PAN (personal area network, e.g., Bluetooth) link as the device. This would be appropriate in deployments where the end device is not expected to provide connectivity for a larger site, but is intended to provide connectivity for the device and a small number of additional devices directly connected to the same PAN as the device. - home user - expected to have a small number of subnets, e.g., less than 10 - a /56 assignment - small business/organization - one having a small number of networks, e.g., less than 100 - a /56 assignment - large business/organization - an organization having more than 100 subnets - a /48. A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for draft-narten-ipv6-3177bis-48boundary-00.txt [Page 4] INTERNET-DRAFT July 11, 2005 the vast majority of end sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.) One can, of course, imagine a policy supporting the entire range of assignments between /48 and /64, depending on the size or type of end site. However, there are a number of arguments in favor of having a small number of classes of sizes: - It becomes easier for end users to identify an assignment size that is appropriate for them - It increases the likelihood that there will be agreement among ISPs on the appropriate assignment sizes for the various customer classes. - Having excess flexibility in selecting an appropriate assignment size for a given customer type can lead to different ISPs offering different assignment sizes to the same customer. This is undesirable because it may result in - an end site needing to renumber into a smaller subnet space when switching ISPs, or - it may lead to ISPs attempting to differentiate their service offerings by offering the most liberal address assignment policies (to attract customers), defeating the purpose of having multiple class assignment sizes. - The operational management of the reverse DNS tree is simplified if delegations are on nibble boundaries (e.g., /48, /52, /56, and /64). 3. Other RFC 3177 considerations RFC3177 suggested that some multihoming approaches (e.g., GSE) might benefit from having a fixed /48 boundary. This no longer appears to be a significant issue. There is no such requirement coming out of the current IETF multi6 or shim6 efforts. 4. Security Considerations This document has no known security implications. draft-narten-ipv6-3177bis-48boundary-00.txt [Page 5] INTERNET-DRAFT July 11, 2005 5. IANA Considerations This document makes no requests to IANA. 6. Acknowledgments This document was motivated by and benefited from numerous conversations held during the ARIN XV and RIPE 50 meetings in April- May, 2005. 7. Normative References 8. Informative References [HUSTON-RIPE] "Report from the ARIN XV IPv6 Roundtable" http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary- wed-itu-ipv6-proposal.pdf [IPV6-HISTORY] Issues Related to the Management of IPv6 Address Space, draft-narten-iana-rir- ipv6-considerations-00.txt [RIR-IPV6] ARIN: http://www.arin.net/policy/index.html#six; RIPE Document ID: ripe-267, Date: 22 January 2003 http://www.ripe.net/ripe/docs/ipv6policy.html; APNIC: http://www.apnic.net/docs/policy/ipv6-address- policy.html [RFC 3177] IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. [RFC 3194] The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio. A. Durand, C. Huitema. November 2001. 9. Author's Address Thomas Narten IBM Corporation 3039 Cornwallis Ave. draft-narten-ipv6-3177bis-48boundary-00.txt [Page 6] INTERNET-DRAFT July 11, 2005 PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: narten@us.ibm.com Geoff Huston APNIC EMail: gih@apnic.net Rosalea G Roberts Stanford University, Networking Systems 241 Panama Street Pine Hall, room 175B Stanford, CA 94305-4102 Email: lea.roberts@stanford.edu Phone: +1-650-723-3352 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. draft-narten-ipv6-3177bis-48boundary-00.txt [Page 7] INTERNET-DRAFT July 11, 2005 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. draft-narten-ipv6-3177bis-48boundary-00.txt [Page 8]