From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4147.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc4147.txt (limited to 'doc/rfc/rfc4147.txt') diff --git a/doc/rfc/rfc4147.txt b/doc/rfc/rfc4147.txt new file mode 100644 index 0000000..96b87ae --- /dev/null +++ b/doc/rfc/rfc4147.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group G. Huston +Request for Comments: 4147 APNIC +Category: Informational August 2005 + + + Proposed Changes to the Format of the IANA IPv6 Registry + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document proposes a revised format for the IANA IPv6 address + registries. Rather than providing a formal definition of the format, + it is described by giving examples of the (current as of preparation + of this document) contents of the registries in the proposed format. + The proposed format would bring the IANA IPv6 address registries into + alignment with the current IPv6 Address Architecture specification, + as well as update it to a more useful and generally accepted format. + +1. Introduction + + This document proposes a revised format for the IANA IPv6 address + registries. The proposed format would bring the IANA IPv6 address + registries into alignment with the current IPv6 Address Architecture + specification, as well as update it to a more useful and generally + accepted format. + + The current (as of preparation of this document) IANA IPv6 registries + [iana-ipv6-registry] [iana-ipv6-tla] are based on a now-deprecated + address architecture that used the concept of Top Level Aggregation + Identifiers (TLAs) and sub-TLAs. The current IPv6 Address + Architecture [RFC3513] uses the terminology of Global Identifiers + instead of TLAs and sub-TLAs. + + + + + + + + + + +Huston Informational [Page 1] + +RFC 4147 IANA IPv6 Registry August 2005 + + +2. IPv6 Address Registry + + The proposed format for the IPv6 address registry is indicated by + example, using the registry state that is current as of preparation + of this document, in Figure 1. The registry explicitly notes which + entity is placing a reservation on an address block and notes the + defining RFC document for each allocation. + + The proposed format of the registry is a title line, the date of the + last change to the registry, the registry in a tabular format, notes + and references. + + The table uses 4 columns. Within the table, the first column + contains an IPv6 address prefix, using a hexadecimal notation of the + address prefix and a prefix length. There are no overlapping address + blocks in the first column, and the set of address blocks in the + registry spans the entire IPv6 address space. The second column + denotes the current disposition of the address block, using notation + derived from the defining RFC document. The third column contains a + reference to the RFC that describes the current disposition of the + address block. The fourth column uses numeric footnote notation to + reference any additional text associated with the address block. + + The notes in the registry may include a summary of previous + disposition status values associated with an address block, as this + summary is specifically not included in the registry table. The + notes are numbered sequentially. + + The reference section uses a conventional citation format. The + references include documents referenced in the registry table and + documents referenced in the notes. + + ----------------------------------------------------- + + INTERNET PROTOCOL VERSION 6 ADDRESS SPACE + + [last updated 13 January 2005] + + IPv6 Prefix Allocation Reference Note + ----------- ---------- --------- ---- + 0000::/8 Reserved by IETF RFC3513 [1] + 0100::/8 Reserved by IETF RFC3513 + 0200::/7 Reserved by IETF RFC4048 [2] + 0400::/6 Reserved by IETF RFC3513 + 0800::/5 Reserved by IETF RFC3513 + 1000::/4 Reserved by IETF RFC3513 + 2000::/3 Global Unicast RFC3513 [3] + 4000::/3 Reserved by IETF RFC3513 + + + +Huston Informational [Page 2] + +RFC 4147 IANA IPv6 Registry August 2005 + + + 6000::/3 Reserved by IETF RFC3513 + 8000::/3 Reserved by IETF RFC3513 + A000::/3 Reserved by IETF RFC3513 + C000::/3 Reserved by IETF RFC3513 + E000::/4 Reserved by IETF RFC3513 + F000::/5 Reserved by IETF RFC3513 + F800::/6 Reserved by IETF RFC3513 + FA00::/7 Reserved by IETF RFC3513 + FC00::/7 Reserved by IETF RFC3513 + FE00::/9 Reserved by IETF RFC3513 + FE80::/10 Link Local Unicast RFC3513 + FEC0::/10 Reserved by IETF RFC3879 [4] + FF00::/8 Multicast RFC3513 + + Notes: + + [0] The IPv6 address management function was formally delegated to + IANA in December 1995 [RFC1881]. + + [1] The "unspecified address", the "loopback address", and the + IPv6 Addresses with Embedded IPv4 Addresses are assigned out + of the 0000::/8 address block. + + [2] 0200::/7 was previously defined as an OSI NSAP-mapped prefix + set [RFC1888]. This definition has been deprecated as of + December 2004 [RFC4048]. + + [3] The IPv6 Unicast space encompasses the entire IPv6 address + range with the exception of FF00::/8. [RFC3513] IANA unicast + address assignments are currently limited to the IPv6 unicast + address range of 2000::/3. IANA assignments from this block + are registered in the IANA registry: iana-ipv6-unicast- + address-assignments. + + [4] FEC0::/10 was previously defined as a Site-Local scoped + address prefix. This definition has been deprecated as of + September 2004 [RFC3879]. + + References: + + [RFC1881] The IAB and IESG, "IPv6 Address Allocation Management", + RFC 1881, December 1995. + + [RFC1888] J. Bound et al, "OSI NSAPs and IPv6", RFC 1888, August + 1996. + + [RFC3513] R. Hinden and S. Deering, "IP Version 6 Addressing + Architecture", RFC 3513, April 2003. + + + +Huston Informational [Page 3] + +RFC 4147 IANA IPv6 Registry August 2005 + + + [RFC3879] C. Huitema and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC4048] B. Carpenter, "RFC 1888 Is Obsolete", RFC 4048, April + 2005. + + ----------------------------------------------------- + + Figure 1 + + +2.1. Notes on Proposed Format Changes to the Registry + + o The textual preamble at the start of the registry has been + removed, in deference to the use of standard IPv6 prefix notation + in the registry. + + o Binary prefix notation has been replaced by standard IPv6 prefix + hexadecimal notation, and the fraction of address space column has + been replaced with the reference to the relevant RFC that defines + the disposition of the address block. Footnote references are + also displayed in a consistent fashion. + + o The terminology "Unassigned" has been replaced by the more precise + phrase "Reserved by IETF", indicating the body that has the token + to permit reassignment of the status of this address block. + + o The "Formerly Site-Local" entry in the body of the registry has + been replaced with an explicit reference to deprecation. A + similar treatment is proposed for 0200::/8, although the RFC + number for the deprecation document has yet to be assigned. There + is a distinction drawn between the current status of a registry + and the set of registry actions that have lead to the current + state. The registry table describes the current status of the + registry, while the text footnotes are used to describe the set of + transactions leading to the current state, including any former + states. + + o Annotations that are references to footnotes are included in the + registry in a separate column. + + o The text commentary on unicast, multicast and anycast addresses + has been removed, as there is no distinction between anycast and + unicast addresses and multicast addresses are explicitly flagged + in the registry. + + + + + + +Huston Informational [Page 4] + +RFC 4147 IANA IPv6 Registry August 2005 + + + o A note and a corresponding reference to RFC1881 was added to + record the formal delegation of the IPv6 address management + function to IANA. + +3. Global Unicast IPv6 Address Registry + + The proposed registry format for Global Unicast IPv6 address block + allocations is indicated by example, using the registry state that + was current as of preparation of this document, in Figure 2. The + registry notes the current allocations, and does not include any + notation of intended future allocations or reservations. All address + space not listed in this registry forms the IANA unallocated address + pool, to be allocated by IANA as per the prevailing address + allocation policies. + + The proposed format of the registry is a title line, the date of the + last change to the registry, the registry in a tabular format, notes + and references. + + The table uses 4 columns. Within the table, the first column is an + IPv6 address prefix, using a hexadecimal notation of the address + prefix and a prefix length. There are no overlapping address blocks + in the first column. The entries here describe only IANA allocations + of address blocks. Temporary IANA reservations for future + allocations, allocation expansion windows and any other internal IANA + states are not described in this registry. The second column + describes the current disposition of the address block, by noting + either the Regional Internet Registry (RIR) to whom the address block + was assigned, or the intended use of the address block. The third + column is the date of the IANA allocation, including the day of the + month. The fourth column uses numeric footnote notation to reference + any additional text associated with the address block. + + The notes in the registry may include a summary of previous + disposition status values associated with an address block, as this + summary is specifically not included in the registry table. The + notes are numbered sequentially. + + The reference section uses a conventional citation format. The + references include documents referenced in the registry table and + documents referenced in the notes. + + + + + + + + + + +Huston Informational [Page 5] + +RFC 4147 IANA IPv6 Registry August 2005 + + + ----------------------------------------------------- + + IPV6 GLOBAL UNICAST ADDRESS ASSIGNMENTS + + [last updated 13 January 2005] + + Global Unicast Prefix Assignment Date Note + --------------------- ---------- ------ ---- + 2001:0000::/23 IANA 01 Jul 99 [1] + 2001:0200::/23 APNIC 01 Jul 99 + 2001:0400::/23 ARIN 01 Jul 99 + 2001:0600::/23 RIPE NCC 01 Jul 99 + 2001:0800::/23 RIPE NCC 01 May 02 + 2001:0A00::/23 RIPE NCC 02 Nov 02 + 2001:0C00::/23 APNIC 01 May 02 [2] + 2001:0E00::/23 APNIC 01 Jan 03 + 2001:1200::/23 LACNIC 01 Nov 02 + 2001:1400::/23 RIPE NCC 01 Feb 03 + 2001:1600::/23 RIPE NCC 01 Jul 03 + 2001:1800::/23 ARIN 01 Apr 03 + 2001:1A00::/23 RIPE NCC 01 Jan 04 + 2001:1C00::/22 RIPE NCC 01 May 04 + 2001:2000::/20 RIPE NCC 01 May 04 + 2001:3000::/21 RIPE NCC 01 May 04 + 2001:3800::/22 RIPE NCC 01 May 04 + 2001:4000::/23 RIPE NCC 11 Jun 04 + 2001:4200::/23 ARIN 01 Jun 04 + 2001:4400::/23 APNIC 11 Jun 04 + 2001:4600::/23 RIPE NCC 17 Aug 04 + 2001:4800::/23 ARIN 24 Aug 04 + 2001:4A00::/23 RIPE NCC 15 Oct 04 + 2001:4C00::/23 RIPE NCC 17 Dec 04 + 2001:5000::/20 RIPE NCC 10 Sep 04 + 2001:8000::/19 APNIC 30 Nov 04 + 2001:A000::/20 APNIC 30 Nov 04 + 2002::/16 6to4 01 Feb 01 [3] + 2003:0000::/18 RIPE NCC 12 Jan 05 + 3FFE::/16 6BONE 01 Dec 98 [4] + + Notes: + + [0] The assignable Global Unicast Address space is defined + in [RFC3513] as being the address block defined by the + prefix 2000::/3. All address space in this block not + listed in the table above is reserved by IANA for + future allocation. + + + + + +Huston Informational [Page 6] + +RFC 4147 IANA IPv6 Registry August 2005 + + + [1] The prefix assigned to the IANA, 2001:0000::/23, is for + assignment for testing, experimental and trial usage by IANA + [RFC2928]. + + [2] 2001:0DB8::/32 has been assigned as a NON-ROUTABLE + range to be used for documentation purposes [RFC3849]. + + [3] 2002::/16 is reserved for use in 6to4 deployments [RFC3056] + + [4] 3FFE::/16 is an experimental allocation to the 6BONE + [RFC2471]. This prefix will be returned to the unassigned + address pool on the 6th June 2006 [RFC3701]. + + References: + + [RFC2471] R. Hinden, R. Fink and J. Postel, "IPv6 Testing + Address Allocation", RFC 2471, December 1998. + + [RFC2928] R. Hinden, S. Deering, R. Fink and T. Hain, + "Initial IPv6 Sub-TLA ID Assignments", RFC 2928, + September 2000. + + [RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3513] R. Hinden and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [RFC3701] R. Fink and R. Hinden, "6bone (IPv6 Testing Address + Allocation) Phaseout", RFC 3701, March 2004. + + [RFC3849] G. Huston, A. Lord, A and P. Smith, "IPv6 Address + Prefix Reserved for Documentation", RFC 3849, July + 2004. + + ----------------------------------------------------- + + Figure 2 + + + + + + + + + + + + + +Huston Informational [Page 7] + +RFC 4147 IANA IPv6 Registry August 2005 + + +3.1. Notes on Proposed Format Changes to the Registry + + o The current registry name "iana-ipv6-tla-assignments" should be + changed to "iana-ipv6-unicast-address-assignments". + + o The title of the registry has been altered to remove the reference + to "TOP LEVEL AGGREGATION IDENTIFIER". + + o The TLA and Sub-TLA identifier assignments have been rolled into a + single set of address prefixes and their assignment. + + o The text commentary at the start of the registry contents has been + removed. + + o Binary value notation of the address prefixes has been removed. + + o Further commentary on assignments, such as the planned phaseout of + the 6BONE, is placed in a footnote. + + o The registry continuation lines using ellipsis notation have been + removed. + + o Only assigned addresses are listed. All unassigned addresses, + marked in the original IANA registry with the assignment note of + "(future assignment)" have been removed, as has the entry marked + "reserved *)". + + o Address assignments are listed using prefix size notation of the + actual allocation, rather than reporting the allocation in sub- + units of /23 prefixes. + + o The date of the IANA action includes the day of the month as well + as the month and year. + +4. IANA Considerations + + IANA is advised to adopt these formats for the IPv6 address registry + and the IPv6 Global Unicast address registry. + +5. Security Considerations + + Security of the Internet's routing system relies on the ability to + authenticate an assertion of unique control of an address block. + Measures to authenticate such assertions rely on validation that the + address block forms part of an existing allocated address block, and + that there is a trustable reference from the IANA address registry to + the RIR, and a trustable reference from the RIR's registry to a Local + Internet Registry or end-user Internet Service Provider. + + + +Huston Informational [Page 8] + +RFC 4147 IANA IPv6 Registry August 2005 + + + The proposed format for the IANA registry is a small step towards the + creation of a registry that can be used as a trust point for + commencing a chain of address validation. Consideration should be + given to IANA registry publication formats that are machine + parseable, and also the use of file signatures and associated + certificate mechanisms to allow applications to confirm that the + registry contents are current, and that they have been published by + the IANA. + +6. Acknowledgements + + This document was prepared with the assistance of Kurt Lindqvist, + Thomas Narten, Paul Wilson, David Kessens, Bob Hinden and Brian + Haberman. Pekka Savola, Brian Carpenter, Christian Huitema and + Michael Patton provided helpful review comments. + +7. References + +7.1. Normative References + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol + Version 6 (IPv6) Addressing Architecture", + RFC 3513, April 2003. + +7.2. Informative References + + [iana-ipv6-registry] IANA, "IANA IPv6 Address Registry", + December 2004. + + [iana-ipv6-tla] IANA, "IANA Registry of IPv6 Top Level + Aggregation Identifier Assignments", + December 2004. + +Author's Address + + Geoff Huston + Asia Pacific Network Information Centre + + EMail: gih@apnic.net + URI: http://www.apnic.net + + + + + + + + + + + +Huston Informational [Page 9] + +RFC 4147 IANA IPv6 Registry August 2005 + + +Full 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. + +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 currently provided by the + Internet Society. + + + + + + + +Huston Informational [Page 10] + -- cgit v1.2.3