1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc3587.txt b/doc/rfc/rfc3587.txt
new file mode 100644
index 0000000..50b239c
--- /dev/null
+++ b/doc/rfc/rfc3587.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          R. Hinden
+Request for Comments: 3587                                         Nokia
+Obsoletes: 2374                                               S. Deering
+Category: Informational                                            Cisco
+                                                             E. Nordmark
+                                                                     Sun
+                                                             August 2003
+
+
+                   IPv6 Global Unicast Address Format
+
+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 (2003).  All Rights Reserved.
+
+Abstract
+
+   This document obsoletes RFC 2374, "An IPv6 Aggregatable Global
+   Unicast Address Format".  It defined an IPv6 address allocation
+   structure that includes Top Level Aggregator (TLA) and Next Level
+   Aggregator (NLA).  This document makes RFC 2374 and the TLA/NLA
+   structure historic.
+
+1.  Introduction
+
+   RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format",
+   defined an IPv6 address allocation structure that includes TLA and
+   NLA.  This document replaces RFC 2374, and makes RFC 2374 and the
+   TLA/NLA structure historic.
+
+2.  TLA/NLA Made Historic
+
+   The TLA/NLA scheme has been replaced by a coordinated allocation
+   policy defined by the Regional Internet Registries (RIRs) [IPV6RIR].
+
+   Part of the motivation for obsoleting the TLA/NLA structure is
+   technical; for instance, there is concern that TLA/NLA is not the
+   technically best approach at this stage of the deployment of IPv6.
+   Moreover, the allocation of IPv6 addresses is related to policy and
+   to the stewardship of the IP address space and routing table size,
+   which the RIRs have been managing for IPv4.  It is likely that the
+   RIRs' policy will evolve as IPv6 deployment proceeds.
+
+
+
+Hinden, et al.               Informational                      [Page 1]
+
+RFC 3587           IPv6 Global Unicast Address Format        August 2003
+
+
+   The IETF has provided technical input to the RIRs (for example,
+   [RFC3177]), which the RIRs have taken into account when defining
+   their address allocation policy.
+
+   RFC 2374 was the definition of addresses for Format Prefix 001
+   (2000::/3) which is formally made historic by this document.  Even
+   though currently only 2000::/3 is being delegated by the IANA,
+   implementations should not make any assumptions about 2000::/3 being
+   special.  In the future, the IANA might be directed to delegate
+   currently unassigned portions of the IPv6 address space for the
+   purpose of Global Unicast as well.
+
+   The Subnet Local Aggregator (SLA) field in RFC 2374 remains in
+   function but with a different name in [ARCH].  Its new name is
+   "subnet ID".
+
+3.  Address Format
+
+   The general format for IPv6 global unicast addresses as defined in
+   "IP Version 6 Addressing Architecture" [ARCH] is as follows:
+
+    |         n bits          |   m bits  |       128-n-m bits         |
+    +-------------------------+-----------+----------------------------+
+    | global routing prefix   | subnet ID |       interface ID         |
+    +-------------------------+-----------+----------------------------+
+
+   where the global routing prefix is a (typically
+   hierarchically-structured) value assigned to a site (a cluster of
+   subnets/links), the subnet ID is an identifier of a subnet within the
+   site, and the interface ID is as defined in section 2.5.1 of [ARCH].
+   The global routing prefix is designed to be structured hierarchically
+   by the RIRs and ISPs.  The subnet field is designed to be structured
+   hierarchically by site administrators.
+
+   [ARCH] also requires that all unicast addresses, except those that
+   start with binary value 000, have Interface IDs that are 64 bits long
+   and to be constructed in Modified EUI-64 format.  The format of
+   global unicast address in this case is:
+
+    |         n bits          | 64-n bits |       64 bits              |
+    +-------------------------+-----------+----------------------------+
+    | global routing prefix   | subnet ID |       interface ID         |
+    +-------------------------+-----------+----------------------------+
+
+
+
+
+
+
+
+
+Hinden, et al.               Informational                      [Page 2]
+
+RFC 3587           IPv6 Global Unicast Address Format        August 2003
+
+
+   where the routing prefix is a value assigned to identify a site (a
+   cluster of subnets/links), the subnet ID is an identifier of a subnet
+   within the site, and the interface ID is a modified EUI-64 format as
+   defined in [ARCH].
+
+   An example of the resulting format of global unicast address under
+   the 2000::/3 prefix that is currently being delegated by the IANA and
+   consistent with the recommendations in RFC 3177 is:
+
+    | 3 |     45 bits         |  16 bits  |       64 bits              |
+    +---+---------------------+-----------+----------------------------+
+    |001|global routing prefix| subnet ID |       interface ID         |
+    +---+---------------------+-----------+----------------------------+
+
+4.  Acknowledgments
+
+   The authors would like to express our thanks to Alain Durand, Brian
+   Carpenter, Fred Templin, Julian Sellers, Jun-ichiro Itojun Hagino,
+   Margaret Wasserman, Michel Py, Pekka Savola, Tatuya Jinmei, and
+   Thomas Narten for their review and constructive comments.
+
+5.  References
+
+5.1.  Normative References
+
+   [ARCH]    Hinden, R. and S. Deering, "IP Version 6 Addressing
+             Architecture", RFC 3513, April 2003.
+
+   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+5.2.  Informative References
+
+   [IPV6RIR] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and
+             Assignment Policy", Document ID: ripe-267,
+             http://www.ripe.net/ripe/docs/ipv6policy.html, January 22,
+             2003.
+
+   [RFC3177] IAB/IESG, "Recommendations on IPv6 Address Allocations to
+             Sites", RFC 3177, September 2001.
+
+6.  Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.
+
+
+
+
+
+
+Hinden, et al.               Informational                      [Page 3]
+
+RFC 3587           IPv6 Global Unicast Address Format        August 2003
+
+
+7.  Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA
+   USA
+
+   EMail: bob.hinden@nokia.com
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+
+   Erik Nordmark
+   Sun Microsystems Laboratories
+   180, avenue de l'Europe
+   38334 SAINT ISMIER Cedex
+   France
+
+   EMail: erik.nordmark@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et al.               Informational                      [Page 4]
+
+RFC 3587           IPv6 Global Unicast Address Format        August 2003
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et al.               Informational                      [Page 5]
+