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/rfc2471.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc2471.txt (limited to 'doc/rfc/rfc2471.txt') 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 ). + 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 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] + -- cgit v1.2.3