DNSOP Working Group P. Vixie, ISC INTERNET-DRAFT R. Hinden, Nokia G. Huston, APNIC T. Narten, IBM Globally Assigned Locally Reachable Unique IPv6 Unicast Addresses 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines globally allocated locally reachable IPv6 unique unicast addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not intended or expected to be routable on the global Internet. Expires January 2008 [Page 1] INTERNET-DRAFT July 2007 ULA-GLOBAL-00 1 - Introduction and Overview 1.1. This document defines the characteristics and technical allocation requirements for globally assigned locally reachable IPv6 unique unicast addresses in the framework defined in [ULA]. These addresses are not intended or expected to be routable on the global Internet. They are routable inside of a more limited area such as a site, autonomous system, or private association. 1.2. Local IPv6 unicast addresses, as defined in [ULA], have the following characteristics: +o Globally unique prefix. +o Well known prefix to allow for easy filtering at site boundaries. +o Internet Service Provider independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity. +o In practice, applications may treat these addresses like global scoped addresses. 1.3. It is a highly desirable property of ULAs that they are unique, as ULA uniqueness would allow sites to be combined or privately interconnected without creating any address conflicts. 1.4. 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 [RFC2119]. 2 - Acknowledgments The authors would like to thank Alan Beard, Alex Zinin, Bill Fenner, Brian Carpenter, Brian Haberman Charlie Perkins, Christian Huitema, Hans Kruse, Harald Alvestrand, Keith Moore, Leslie Daigle, Margaret Wasserman, Pekka Savola, Shannon Behrens, Steve Bellovin, Tim Chown, Tony Hain, Fred Templin, and David Conrad for their comments and suggestions on this document. Expires January 2008 [Page 2] INTERNET-DRAFT July 2007 ULA-GLOBAL-00 3 - Globally Assigned Locally Reachable IPv6 Unique Unicast Addresses 3.1. The globally assigned locally reachable IPv6 unique unicast addresses, based on Unique Local Addresses [ULA], have the following format: | 7 bits |1| 12 bits | 24 bits | 80 bits | +--------+-+---------+-----------+----------+ | Prefix |L| RIR Num | Local Num | User Num | +--------+-+---------+-----------+----------+ Where: Prefix FC00::/7 prefix to identify Local IPv6 unicast addresses. L Set to 0 if the prefix is globally assigned, Note: [ULA] defined L=1 for locally assigned ULAs. This document defines L=0 for globally assigned ULA addresses. RIR Num Identifiers assigned by IANA for each /20 as allocated to an Regional Internet Address Registry (RIR). It is expected that IANA will allocate blocks of 100 consecutive RIR Nums to each RIR, to amortize administrative workload. Local Num Identifiers assigned by an RIR (or LIR) for each /48 as allocated to an end site or user. It is expected that allocations by an RIR to an LIR will be in blocks of 1000 consecutive Local Nums, to amortize administrative workload. User Num Identifier assigned by an end user or network operator who implements this specification based on a /48 prefix assignment from an RIR or LIR. 4 - Operational Guidelines 4.1. DNS, WHOIS and other RIR/LIR services including any future security key material used for secure routing should be collected, preserved, and published for globally allocated locally reachable IPv6 unicast addresses in the same way as for globally reachable IPv6 unicast addresses. Expires January 2008 [Page 3] INTERNET-DRAFT July 2007 ULA-GLOBAL-00 5 - Global Routing Considerations 5.1. Since [ULA] was first published, the Regional Internet Address Registries (RIR) created a new policy to allocate IPv6 Provider Independent Addresses [RIR-PI]. Given the availability of RIR allocated provider-independent addresses the authors believe that there is considerably less concern that ULAs of either type will be used as IPv6 provider-independent addresses. 5.2. The operational guidelines regarding routing of centrally assigned local addresses is that such address prefixes should be readily routed within a site or comparable administrative routing domain. 5.3. By default, such prefixes should not be announced beyond such a local scope, due to the non-aggregateability of these prefixes within the routing system and the potential negative impact on the total size of the routing space in large scale internet environments. 5.4. Entities wishing to use IPv6 Provider Independent Addresses (PI Space) in such larger routing contexts should consult the Regional Internet Registries policies relating to the allocation of PI Space [RIR-PI]. 5.5. IANA and all RIR/LIRs are encouraged to avoid allocating aligned blocks of address space under this specification, in order to specifically discourage aggregation and wide area routing of such address space. 5.6. Availability and cost of address space allocated under this specification shall be wide and nominal, respectively. It is expected that hundreds of millions of /48 allocations will be made over time, and so, qualification should be an administrative activity having more to do with keeping contact information up to date than with the intended use of the address space. Fee levels for a /48 should be similar to fee levels for domain names. 6 - Security Considerations 6.1. Local IPv6 addresses do not provide any inherent security to the nodes that use them. They may be used with filters at site boundaries to keep Local IPv6 traffic inside of the site, but this is no more or less secure than filtering any other type of global IPv6 unicast addresses. Expires January 2008 [Page 4] INTERNET-DRAFT July 2007 ULA-GLOBAL-00 7 - IANA Considerations 7.1. IANA is hereby instructed to reserve address block FC00::/7 for private unique addresses, and to allocate blocks of /20 prefixes to Regional Internet Address Registries (RIRs) who request such after adopting policies consistent with this specification. Allocation shall be similar in all ways to normal IANA address allocation to RIRs, including but not limited to IN-ADDR.ARPA delegations and WHOIS records. 8 - References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1997. [ULA] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC-4193, October 2005. 8.2. Informative References [RIR-PI] O. DeLong, K. Loch, A. Dul, "Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites", http://www.arin.net/policy/proposals/2005_1.html, May 2006. Expires January 2008 [Page 5] INTERNET-DRAFT July 2007 ULA-GLOBAL-00 9 - Authors' Addresses Paul Vixie ISC Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA phone: +1 650 625-2004 email: bob.hinden@nokia.com Geoff Huston APNIC Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 Phone: +1 919 254 7798 email: narten@us.ibm.com 10 - Change Log Draft +o New proposal based on Draft . Expires January 2008 [Page 6] INTERNET-DRAFT July 2007 ULA-GLOBAL-00 11 - Full Copyright Statement Copyright (C) The Internet Society (2007). 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Expires January 2008 [Page 7]