summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4147.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4147.txt')
-rw-r--r--doc/rfc/rfc4147.txt563
1 files changed, 563 insertions, 0 deletions
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]
+