1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc2471.txt b/doc/rfc/rfc2471.txt
new file mode 100644
index 0000000..09f23e6
--- /dev/null
+++ b/doc/rfc/rfc2471.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                         R. Hinden
+Request for Comments: 2471				          Nokia
+Obsoletes: 1897                                                 R. Fink
+Category: Experimental                                             LBNL
+                                                              J. Postel
+                                                                    ISI
+                                                          December 1998
+
+
+                    IPv6 Testing Address Allocation
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.0 Introduction
+
+   This document describes an allocation plan for IPv6 addresses to be
+   used in testing IPv6 prototype software.  These addresses are
+   temporary and will be reclaimed in the future.  Any IPv6 system using
+   these addresses will have to renumber at some time in the future.
+   These addresses will not to be routable in the Internet other than
+   for IPv6 testing.
+
+   The address format for the IPv6 test address is consistent with the
+   "Aggregatable Global Unicast Address Allocation" [AGGR] and "TLA and
+   NLA Assignment Rules" [TLAASN].
+
+   This document is intended to replace RFC 1897 "IPv6 Testing Address
+   Allocation", January 1996.  RFC 1897 will become historic.
+
+   The addresses described in this document are consistent with the IPv6
+   Addressing Architecture [ARCH].  They may be assigned to nodes
+   manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for
+   IPv6 [DHCPv6].
+
+   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].
+
+
+
+
+
+Hinden, et. al.               Experimental                      [Page 1]
+
+RFC 2471            IPv6 Testing Address Allocation        December 1998
+
+
+2.0 Address Format
+
+   The Aggregatable Global Unicast Address Allocation format defined in
+   [AGGR] is as follows:
+
+      | 3 |  13 |    32     |   16   |          64 bits               |
+      +---+-----+-----------+--------+--------------------------------+
+      |FP | TLA | NLA ID    | SLA ID |         Interface ID           |
+      |   | ID  |           |        |                                |
+      +---+-----+-----------+--------+--------------------------------+
+
+   where:
+
+      FP = 001 = Format Prefix
+
+           This is the Format Prefix used to identify aggregatable
+           global unicast addresses.
+
+      TLA = 0x1FFE = Top-Level Aggregation Identifier
+
+           This is a TLA ID assigned by the IANA for 6bone testing under
+           the auspices of the IETF IPng Transition Working Group 6bone
+           testbed activity.  It is to be administered by the chair of
+           the 6bone activity (currently Bob Fink <rlfink@lbl.gov>).
+           The use of this TLA ID is temporary.  All users of these
+           addresses in this TLA ID will be required to renumber at some
+           time in the future.
+
+      NLA ID = Next-Level Aggregation Identifier
+
+           The NLA ID space will be assigned, by the TLA ID
+           administrator, in an addressing hierarchy sufficient to
+           identify transit networks and end user sites consistent with
+           the architecture and topology of the 6bone. This will provide
+           a multi-level transit service consistent with the 6bone goals
+           of fully testing IPv6 technology in real use environments.
+
+      SLA ID = Site-Level Aggregation Identifier
+
+           The SLA ID field is used by an individual organization to
+           create its own local addressing hierarchy and to identify
+           subnets.  Assignment of the SLA ID field is the
+           responsibility of each individual organization.
+
+
+
+
+
+
+
+
+Hinden, et. al.               Experimental                      [Page 2]
+
+RFC 2471            IPv6 Testing Address Allocation        December 1998
+
+
+      Interface ID
+
+           This is the interface identifier of the interface on the link
+           as defined in the appropriate IPv6 over <link> document, such
+           as [ETHER], [FDDI], etc.
+
+4.0 References
+
+   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
+             RFC 2373, July 1998.
+
+   [AGGR]    Hinden, R., Deering, S., O'Dell, M., "An Aggregatable
+             Global Unicast Address Format", RFC 2374, July 1998.
+
+   [AUTO]    Thompson, S. and T. Narten, "IPv6 Stateless Address
+             Autoconfiguration", RFC 1971, August 1996.
+
+   [DHCP6]   Bound, J., "Host Configuration Protocol for IPv6", Work in
+             Progress.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", RFC 2464, December 1998.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", RFC 2467, December 1998.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [TLAASN]  Hinden, R., "TLA and NLA Assignment Rules", Work in
+             Progress.
+
+5.0 Security Considerations
+
+   This document defines a test approach for creating aggregatable
+   address consistent with [AGGR].  It does not have any direct impact
+   on Internet infrastructure security.  Authentication of IPv6 packets
+   is defined in [AUTH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.               Experimental                      [Page 3]
+
+RFC 2471            IPv6 Testing Address Allocation        December 1998
+
+
+6.0  Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: +1 408 990-2004
+   EMail: hinden@iprg.nokia.com
+
+
+   Robert Fink
+   Lawrence Berkeley National Laboratory
+   MS 50A-3111
+   Berkeley, CA 94720
+   USA
+
+   Phone: +1 510 486-5692
+   EMail: rlfink@lbl.gov
+
+
+   Jon Postel (Deceased)
+   Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+   USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.               Experimental                      [Page 4]
+
+RFC 2471            IPv6 Testing Address Allocation        December 1998
+
+
+7.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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 assigns.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.               Experimental                      [Page 5]
+