INTERNET-DRAFT Thomas Narten IBM Geoff Huston APNIC Lea Roberts Stanford University June 26, 2006 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 in six months. Abstract RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted those recommendations in 2002 and they have been in effect ever since. This document revisits and updates the IAB/IESG recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is a policy issue under the purview of the RIRs, subject to IPv6 architectural and draft-narten-ipv6-3177bis-48boundary-02.txt [Page 1] INTERNET-DRAFT June 26, 2006 operational considerations. This document reviews the architectural considerations and some of the operational issues and reiterates that changing the /48 recommendation is one of policy, and has minimal impact on the IPv6 architecture and on IETF Standards. 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............................ 4 4. Impact on IPv6 Standards................................. 5 4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds. 5 4.2. IPv6 Multicast Addressing........................... 5 5. Summary.................................................. 5 6. Security Considerations.................................. 6 7. IANA Considerations...................................... 6 8. Acknowledgments.......................................... 6 9. Normative References..................................... 6 10. Informative References.................................. 6 11. Author's Address........................................ 7 1. Introduction There are a number of considerations that factor into address assignment policies. For example, to provide for the long-term health and scalability of the public routing infrastructure, it is important that addresses aggregate well. Likewise, giving out an excessive amount of address space could result in premature depletion. This document focuses on the (more narrow) question of what is an appropriate IPv6 address assignment size for end sites. That is, when end sites request IPv6 address space from ISPs, what is an appropriate assignment size. draft-narten-ipv6-3177bis-48boundary-02.txt [Page 2] INTERNET-DRAFT June 26, 2006 RFC 3177 [RFC3177] called for a default end site IPv6 assignment size of /48. Subsequently, the RIRs developed and adopted IPv6 address assignment and allocation policies consistent with the RFC 3177 recommendations [RIR-IPV6]. Additional history and discussion of IPv6 address policy and its long-term implications can be found in [IPV6-HISTORY]. This document performs two functions: 1) It revisits the RFC 3177 recommendations and concludes that the default IPv6 assignment size could be changed from /48 to some other value (e.g., /56) with essentially no impact on existing IPv6 standards and no impact to (standards-compliant) implementations. 2) It obsoletes RFC 3177 and reclassifies it historic. 2. On /48 Assignments to End Sites This document does not make a specific recommendation on what the assignment size should be. The exact choice of how much address space to assign end sites is a policy issue under the purview of the RIRs, subject to IPv6 architectural and opertational considerations. The focus of this document is to examine the architectural issues and some of the operational considerations relating to the size of the end site assignment. Looking back at some of the original motivations behind the /48 recommendation [RFC 3177], there were two main concerns. The first motivation 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 (though even this is not always assured), but getting any more than one address is typically significantly more expensive either in terms of the justification effort needed to obtain additional addresses, or in the actual monthly service cost. (It should be noted that an end-user additional "cost" for obtaining more than one address is difficult to justify by the actual effective per-address cost charged by the RIRs, but providing additional addresses is frequently only available as part of a different type or "higher grade" of service, for which an additional charge is levied.) Thus, an important goal in IPv6 is to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks". draft-narten-ipv6-3177bis-48boundary-02.txt [Page 3] INTERNET-DRAFT June 26, 2006 A second motivation behind the original /48 recommendation was to simplify the management of an end site's numbering plan in the presence of renumbering (e.g., when switching ISPs) and multiple prefixes. In IPv6, a site may simultaneously use multiple prefixes, including one or more public prefixes from ISPs as well as Unique Local Addresses [ULA-ADDRESSES]. In the presences of multiple prefixes, it is signficantly less complex to manage a numbering plans if the same subnet numbering plan can be used for all prefixes. That is, for a link that has (say) three different prefixes assigned to it, the subnet portion of those prefixes would be identical for all assigned addresses. In addition, renumbering from a larger set of "subnet bits" into a smaller set is relatively painful, as it it can require making changes to the network itself (e.g., collapsing subnets). In contrast, renumbering a site into a prefix that has the same number (or more) of subnet bits is more straightforward, 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. It should be noted that similar arguments apply to the management of zone files in the DNS. In particular, managing the reverse (ip6.arpa) tree is simplified when all links are numbered using the same subnet ids. The above concerns were met by the original /48 recommendation, but could also be realized through a more conservative approach. A key goal, however, is to avoid the need for a site to renumber into a smaller number of subnet bits when adding a new prefix. This could be achieved, for instance, by having it be easy for an end site to obtain an address block of the same size (or larger) as any existing assignments it already has. 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 consideration. There is no such requirement coming out of the IETF multi6 or shim6 efforts. RFC3177 argued that having a "one size fits all" default assignment size reduced the need for customers to continually or repeatedly justify usage of existing address space in order to get "a little more". Likewise, it also reduces the need for ISPs to evaluate such requests. Given the large amount of address space in IPv6, there is plenty of space to grant end sites enough space to consistent with reasonable growth projections over multi-year time frames. Thus, it draft-narten-ipv6-3177bis-48boundary-02.txt [Page 4] INTERNET-DRAFT June 26, 2006 remains highly desirable to provide end sites with enough space (on both initial and subsequent assignments) to last several years. Fortunately, this goal can be achieved in a number of ways and does not require that all end sites receive the same default size assignment. 4. Impact on IPv6 Standards 4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds RFC3056 [RFC 3056] describes a way of generating IPv6 addresses from an existing public IPv4 address. That document describes an address format in which the first 48 bits concatenate a well-known prefix with a globally unique public IPv4 address. The "SLA ID" field is assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To facilitate transitioning from an RFC3056 address numbering scheme to one based on a prefix obtained from an ISP, an end site would be advised to number out of the right most bits first, using the left most bits only if the size of the site made that necessary. Similar considerations apply to other documents that allow for a subnet id of 16 bits, including [ULA-ADDRESSES]. 4.2. IPv6 Multicast Addressing Some IPv6 multicast address assignment schemes embed a unicast IPv6 prefix into the multicast address itself [RFC3306]. Such documents do not assume a particular size for the subnet id per se, but do assume that the IPv6 prefix is a /64. Thus, the relative size of the subnet id has no direct impact on multicast address schemes. 5. Summary The exact choice of how much address space to assign end sites is a policy issue under the purview of the RIRs, subject to IPv6 architectural and operational considerations. However, the RFC 3177 recommendation to assign /48s as a default is not a requirement of the IPv6 architecture; anything of length /64 or shorter works from a standards perspective. However, there are important operational considerations as well. The IETF recommends that any policy on IPv6 address assignment policy to end sites take into consideration: - it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64) draft-narten-ipv6-3177bis-48boundary-02.txt [Page 5] INTERNET-DRAFT June 26, 2006 - the default assignment size should take into consideration the likelihood that an end site will have need to have multiple subnets in the future and avoid the IPv4 practice of having frequent and continual justification for obtaining small amounts of additional space - it is generally undesirable to have one ISP assign a longer prefix to an end site when compared with the existing prefixes the end site already has assigned to it - the operational considerations of managing and delegating the reverse DNS tree under ip6.arpa on nibble vs. non-nibble boundaries should be given adequate consideration 6. Security Considerations This document has no known security implications. 7. IANA Considerations This document makes no requests to IANA. 8. Acknowledgments This document was motivated by and benefited from numerous conversations held during the ARIN XV and RIPE 50 meetings in April- May, 2005. 9. Normative References 10. Informative References [HUSTON-RIPE] "Report from the ARIN XV IPv6 Roundtable" http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary- wed-ipv6-roundtable-report.pdf [IPV6-HISTORY] Issues Related to the Management of IPv6 Address Space, draft-narten-iana-rir- ipv6-considerations-00.txt draft-narten-ipv6-3177bis-48boundary-02.txt [Page 6] INTERNET-DRAFT June 26, 2006 [RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; 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 3056] "Connection of IPv6 Domains via IPv4 Clouds," B. Carpenter, K. Moore, RFC 3056, February 2001. [RFC 3306] "Unicast-Prefix-based IPv6 Multicast Addresses," B. Haberman, D. Thaler, RFC 3306, August 2002. [RFC 3177] IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. [ULA-ADDRESSES] RFC 4193 "Unique Local IPv6 Unicast Addresses," R. Hinden, B. Haberman, RFC 4193, October 2005. 11. Author's Address Thomas Narten IBM Corporation 3039 Cornwallis Ave. 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 draft-narten-ipv6-3177bis-48boundary-02.txt [Page 7] INTERNET-DRAFT June 26, 2006 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. 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 (2006). 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, draft-narten-ipv6-3177bis-48boundary-02.txt [Page 8] INTERNET-DRAFT June 26, 2006 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-02.txt [Page 9]