Internet Draft T. Hain Document: draft-hain-prefix-consider-00.txt Cisco Expires: September 2005 April 2005 Considerations for prefix length assignments in the Global Unicast Address Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. IPR Statement "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." (See RFC 3978[RFC3978] section 5.1.) All Internet-Drafts must include the following statements near the end of the document: "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." Abstract Hain Expires - October 2005 1 Considerations for prefix length assignments April 2005 in the Global Unicast Address Format This document discusses the issues that should be considered by service providers as they assign address space to customers. It is informational in nature as allocation policies are developed elsewhere. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Hain Expires - October 2005 2 Considerations for prefix length assignments April 2005 in the Global Unicast Address Format Introduction Several service providers have expressed concern that a single policy of always allocating a ::/48 to a site is both ambiguous and constraining on their business practice. First the definition of 'site' leaves open the question of is this a customer, a customer campus, or a single building (to some degree that language is intentionally ambiguous to allow for any of the above without being restrictive). Then the apparent single value for all customers removes their ability to differentiate levels of service through the amount of address space provided. History The single prefix length policy recommendation was specifically targeted to counter the IPv4 practice of assigning a single address and/or charging customers per active address. Extreme conservation embodied in per address charging is naturally countered by consumers through the use of NAT technologies to conform to the restriction on one hand while achieving their real goal on the other. Since NAT devices introduce an impediment to new application deployment, and/or require operationally complex helper technologies, the community developing IPv6 wanted to ensure that all the effort to provide sufficient address space to remove the need for NAT was not undermined by misguided business practices. While the global policy does allow for the assignment of ::/128 values, this is expected to be rare as the service provider will never know if the receiving device is really a router meaning it should have handed out a minimum of a subnet prefix. The ::/48 value was selected in recognition that larger organizations would need a sufficient number of bits for local subnet management, coupled with the realization that even if they were handed out to individuals there would be enough to provide multiple ::/48 prefixes to every person projected to be alive in 2050. The intense focus on conservation that has developed among the service providers for managing IPv4 can't seem to adjust to the reality that there are and will be enough ::/48's to cover the need. Technical issues to consider While any length prefix may be assigned, there are technical reasons to restrict the set. Consistent management oversight of the forward address space assignments and the reverse DNS tree suggest that all assignments should be on nibble boundaries. Choosing other than nibble boundaries ensures that multiple organizations will need to manage the affected DNS reverse zone. Assigning individual ::/64 subnet prefixes is likely to lead to discontiguous assignments over time (even in the initial discussions Hain Expires - October 2005 3 Considerations for prefix length assignments April 2005 in the Global Unicast Address Format about DOCSIS 3.0 it was clear that multiple subnets per customer were likely due to the differing media types involved). Aggregation per customer simplifies several management issues, so planning ahead by avoiding individual ::/64 prefix assignments will minimize future renumbering. Recommendation Allocating on nibble boundaries would lead to the choices of ::/48, ::/52, ::/56, ::/60, and ::/64. Future proofing by avoiding the assignment of individual ::/64's would take that off the list. Very large global enterprises are likely to acquire substantial multiples of ::/48 prefixes so they are not a real concern here. For those service providers that believe they absolutely need to differentiate levels of service through address space this leads to a recommendation of: Large businesses -> ::/48 Medium businesses -> ::/52 Small business/home office -> ::/56 Commodity consumer -> ::/60 RIR Considerations Future versions of the global IPv6 allocation policy could soften the wording around recommended prefix lengths, but really should include the technical discussion about reverse zone alignment. Security Considerations There are no security issues discussed in this informational document. RFC Editor Considerations This space left intentionally blank. IANA Considerations This space left intentionally blank. Acknowledgments Discussion of these issues have occurred over time at many venues, and unfortunately I don't recall everyone involved. Author's Addresses Tony Hain Cisco Systems 500 108th Ave. N.E. Suite 400 Bellevue, Wa. 98004 Email: alh-ietf@tndh.net Hain Expires - October 2005 4 Considerations for prefix length assignments April 2005 in the Global Unicast Address Format References 1 RFC-2026, Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 RFC-2119, Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Hain Expires - October 2005 5