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