doc: Add RFC documents

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]
+