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/rfc2921.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2921.txt (limited to 'doc/rfc/rfc2921.txt') diff --git a/doc/rfc/rfc2921.txt b/doc/rfc/rfc2921.txt new file mode 100644 index 0000000..b944a15 --- /dev/null +++ b/doc/rfc/rfc2921.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group B. Fink +Request for Comments: 2921 ESnet +Category: Informational September 2000 + + + 6BONE pTLA and pNLA Formats (pTLA) + +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 (2000). All Rights Reserved. + +Abstract + + This memo defines how the 6bone uses the 3FFE::/16 IPv6 address + prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", + [6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers + (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). + +Acknowledgements + + The address formats here are contributions of various early + participants of the 6bone testbed project, and of the IPng and + NGtrans IETF working groups. + +Table of Contents + + 1. Introduction................................................. 1 + 2. 6BONE pTLA/pNLA Format....................................... 2 + 3. Security Considerations...................................... 6 + References....................................................... 6 + Author's Address................................................. 6 + Full Copyright Statement......................................... 7 + +1. Introduction + + This memo defines how the 6bone uses the 3FFE::/16 IPv6 address + prefix, allocated in RFC 2471 [6BONE-TLA], to create pseudo Top-Level + Aggregation Identifiers (pTLA) and pseudo Next-Level Aggregation + Identifiers (pNLA). + + + + + + +Fink Informational [Page 1] + +RFC 2921 6BONE pTLA and pNLA Formats September 2000 + + + The guiding specifications for IPv6 addressing relating to the 6bone + prefix, and the pTLA and pNLA formats, are "IP Version 6 Addressing + Architecture" [ADDRARCH], and "An IPv6 Aggregatable Global Unicast + Address Format" [AGGR]. + + The purpose of creating pseudo TLA and NLA formats for the 6bone is + to provide a prototype of the actual TLA and NLA formats as they + might be used in production IPv6 networks. To do this economically, + using only a minimum of real production IPv6 address space, a single + TLA, 3FFE::/16, was reserved by the IANA (Internet Assigned Numbers + Authority) for testing on the 6bone. Thus it was necessary to define + a pretend-to-be, or pseudo, TLA and NLA structure to use under the + 3FFE::/16 prefix. + + Given the 48-bit length of the IPv6 Aggregatable Global Unicast + Address external routing prefix (that contains the TLA and NLA + identifiers), there is enough room to extend the TLA ID to contain a + pTLA and shorten the NLA ID to become a pNLA. This document specifies + this. + + In early 1999, it was decided to change the 6bone's pTLA format to + allow greater expansion of the testbed network, thus accommodating + more than the original 256 pTLA-s. Thus there are now two 6bone pTLA + and pNLA formats. This document specifies this. + +2. 6BONE pTLA and pNLA Formats + +2.1 Original 8-bit pTLA and 24-bit pNLA Format + + The original pTLA and pNLA format was intended to accommodate 256 + pTLA-s, i.e., backbone networks carrying IPv6 transit traffic. + + The original TLA and NLA ID-s as specified in [AGGR] are as follows: + + | 3 | 13 | 32 | 16 | 64 bits | + +---+-----+---------------------+--------+-----------------+ + |001| TLA | NLA ID | SLA ID | Interface ID | + +---+-----+---------------------+--------+-----------------+ + + The TLA value 1FFE was assigned to the 6bone, which when viewed with + the 3-bit format prefix in prefix notation form is 3FFE::/16. + + The first 8-bits of the NLA ID space are assigned as the pTLA that + defines the top level of aggregation (backbone) for the 6bone. This + provides for 256 6bone backbone networks, or pTLA-s, and leaves a + 24-bit pNLA ID for each pTLA to assign as needed. + + + + + +Fink Informational [Page 2] + +RFC 2921 6BONE pTLA and pNLA Formats September 2000 + + + | 16 | 8 | 24 | 16 | 64 bits | + +-+---------+-----+-------------+--------+-----------------+ + | 0x3FFE |pTLA | pNLA | SLA ID | Interface ID | + +-+---------+-----+-------------+--------+-----------------+ + + In prefix notation form the pTLA is 3FFE:nn00::/24, where nn is the + pTLA assignment. + + The remaining NLA ID space can be used by each pTLA for their + downward aggregated delegation: + + | n | 24-n bits | 16 | 64 bits | + +-----+--------------------+--------+-----------------+ + |pNLA1| Site | SLA ID | Interface ID | + +-----+--------------------+--------+-----------------+ + + | m | 24-n-m | 16 | 64 bits | + +-----+--------------+--------+-----------------+ + |pNLA2| Site | SLA ID | Interface ID | + +-----+--------------+--------+-----------------+ + + | o |24-n-m-o| 16 | 64 bits | + +-----+--------+--------+-----------------+ + |pNLA3| Site | SLA ID | Interface ID | + +-----+--------+--------+-----------------+ + + The pNLA delegation works in the same manner as specified in [AGGR]. + pTLA's are required to assume registry duties for the pNLA's below + them, pNLA1's for those below them, etc. + +2.2 New 12-bit pTLA and 20-bit pNLA Format + + After it became clear that the 6bone would become a useful testbed + for transition, in addition to its early role as a testbed for + specifications and implementations, the 6bone community decided to + expand the size of the pTLA ID. + + Several important decisions regarding this expansion of the pTLA + field are: + + 1. to leave the currently allocated 8-bit pTLA-s in use until the + space was needed, thus relying on a range value check to indicate + the new pTLA format, + + 2. to use a modulo 4-bit sized pTLA ID to make reverse path entry + into the DNS easier, + + + + + +Fink Informational [Page 3] + +RFC 2921 6BONE pTLA and pNLA Formats September 2000 + + + 3. given 2. above, to keep the pTLA ID size as small as possible + to not restrict pNLA ID size. + + Therefore, the first 12-bits of the NLA ID space are assigned as the + pTLA that defines the top level of aggegation (backbone) for the + 6bone. This would eventually provide for 4096 6bone backbone + networks, or pTLA-s, and leaves a 20-bit pNLA ID for each pTLA to + assign as needed. + + | 16 | 12 | 20 | 16 | 64 bits | + +-+---------+-------+-----------+--------+-----------------+ + | 0x3FFE | pTLA | pNLA | SLA ID | Interface ID | + +-+---------+-------+-----------+--------+-----------------+ + + In prefix notation form the pTLA is 3FFE:nnn0::/28, where nnn is the + pTLA assignment. However, as the existing 8-bit pTLA's are being left + in use for the present, the nnn value starts at 0x800 for now, thus + yielding only 2048 pTLA's in this new format. + + The remaining NLA ID space can be used by each pTLA for their + downward aggregated delegation: + + | n | 20-n bits | 16 | 64 bits | + +-----+--------------------+--------+-----------------+ + |pNLA1| Site | SLA ID | Interface ID | + +-----+--------------------+--------+-----------------+ + + | m | 20-n-m | 16 | 64 bits | + +-----+--------------+--------+-----------------+ + |pNLA2| Site | SLA ID | Interface ID | + +-----+--------------+--------+-----------------+ + + | o |20-n-m-o| 16 | 64 bits | + +-----+--------+--------+-----------------+ + |pNLA3| Site | SLA ID | Interface ID | + +-----+--------+--------+-----------------+ + + As with the original pTLA format, the pNLA delegation works in the + same manner as specified in [AGGR]. pTLA's are required to assume + registry duties for the pNLA's below them, pNLA1's for those below + them, etc. + +2.3 Example Format For pNLA's + + An example usage of the pNLA space is given to demonstrate what is + reasonable and possible. It should not be assumed that this implies + the pNLA space must be used this way. As the new pTLA and pNLA format + is now the default, the example here assumes the 20-bit pNLA format. + + + +Fink Informational [Page 4] + +RFC 2921 6BONE pTLA and pNLA Formats September 2000 + + + The following example provides for up to 255 intermediate transit + ISP's (called pNLA1 below). The pNLA1 value of zero is meant to + indicate that there is no intermediate transit ISP between the + backbone pTLA network and the end user site. + + |<-----20-bit pNLA ID----->| + | | + | 8 | 12 bits | 16 | 64 bits | + +-----+--------------------+--------+-----------------+ + |pNLA1| Site ID | SLA ID | Interface ID | + +-----+--------------------+--------+-----------------+ + + Intermediate transit networks (pNLA1's) would assign uniques Site + ID's for eachend user site served. + + As an example of this, assuming a backbone pTLA of 0x800, no + intermediate transit ISP (thus a pNLA1 of 0x00) and a sequential site + ID (with start at the right edge numbering) of 0x0001, the routing + prefix for the first site would look like: + + 3FFE:8000:0001/48 + 6bone _|||| |||| ||||___site + |||| | + b/b site____|||| | + | | + transit________|_| + + Another example of this usage, assuming the same backbone pTLA1 of + 0x800 and an intermediate transit ISP under it (numbering from the + left edge) with an NLA1 of 0x80, and a sequential site ID of 0x0001, + the routing prefix for the first site connected would look like: + + 3FFE:0180:0001/48 + 6bone _|||| |||| ||||___site + |||| + b/b site____|||| + || + transit_______|| + + Note 1: the two sites numbered 0x001 in the above examples are really + two different sites as their pNLA1 authority above them is different + (i.e., in the first case no transit exists thus the site is directly + connected to the pTLA backbone ISP, and in the second case the site + is directly connected to intermediate transit ISP 0x80). + + Note 2: there would be nothing to prevent an pNLA1 transit site from + further allocating pNLA's below, but that becomes the policy of the + pTLA and pNLA's above them to work out. + + + +Fink Informational [Page 5] + +RFC 2921 6BONE pTLA and pNLA Formats September 2000 + + + Note 3: The 6bone registry, which is a RIPE-style database for + documenting IPv6 sites connected to the 6bone, has an "inet6num" + object to allow documentation of all IPv6 addresses allocated. + +3. Security Considerations + + IPv6 addressing documents do not have any direct impact on Internet + infrastructure security. + +References + + [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 + Aggregatable Global Unicast Address Format", RFC 2374, + July 1998. + + [HARDEN] Rockell, R. and R. Fink, "6Bone Backbone Routing + Guidelines", RFC 2772, February 2000. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [6BONE-TLA] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address + Allocation", RFC 2471, December 1998. + +Author's Address + + Bob Fink, ESnet + Lawrence Berkeley National Lab + MS 50A-3111 + 1 Cyclotron Road + Berkeley, CA 94720 + USA + + Phone: +1 510 486 5692 + Fax: +1 510 486 4790 + EMail: fink@es.net + + + + + + + + + + + + +Fink Informational [Page 6] + +RFC 2921 6BONE pTLA and pNLA Formats September 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Fink Informational [Page 7] + -- cgit v1.2.3