summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2928.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2928.txt')
-rw-r--r--doc/rfc/rfc2928.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc2928.txt b/doc/rfc/rfc2928.txt
new file mode 100644
index 0000000..3248be0
--- /dev/null
+++ b/doc/rfc/rfc2928.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group R. Hinden
+Request for Comments: 2928 Nokia
+Category: Informational S. Deering
+ Cisco
+ R. Fink
+ LBNL
+ T. Hain
+ Microsoft
+ September 2000
+
+
+ Initial IPv6 Sub-TLA ID Assignments
+
+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 document defines initial assignments of IPv6 Sub-Top-Level
+ Aggregation Identifiers (Sub-TLA ID) to the Address Registries. It
+ is intended as technical input to the Internet Assigned Numbers
+ Authority (IANA) from the Internet Engineering Task Force (IETF)
+ Internet Protocol Next Generation (IPNG) and Next Generation
+ Transition (NGTRANS) working groups, as an input to the process of
+ developing guidelines for the allocation of IPv6 addresses.
+
+ This document was originally developed to provide advice to IANA in
+ the fall of 1998 and is being published at this time for the
+ historical record. The Internet Architecture Board (IAB)
+ subsequently requested that the IANA delegate these assignments to
+ the Address Registries. The IANA did this and the Address Registries
+ are now using them to assign IPv6 addresses.
+
+1. Introduction
+
+ This document was originally developed to provide advice to IANA in
+ the fall of 1998 and is being published at this time for the
+ historical record. The IAB subsequently requested that the IANA
+ delegate these assignments to the Address Registries. The IANA did
+ this and the Address Registries are now using them to assign IPv6
+ addresses.
+
+
+
+Hinden, et al. Informational [Page 1]
+
+RFC 2928 Initial IPv6 Sub-TLA ID Assignments September 2000
+
+
+ This document defines initial assignments of IPv6 Sub-TLA Aggregation
+ Identifiers (Sub-TLA ID) to the Address Registries. It is intended
+ as technical input to the IANA from the IETF IP Next Generation
+ (IPNG) and Next Generation Transition (NGTRANS) working groups, as an
+ input to the process of developing guidelines for the allocation of
+ IPv6 addresses.
+
+ The IAB and IESG have authorized the Internet Assigned Numbers
+ Authority (IANA) as the appropriate entity to have the responsibility
+ for the management of the IPv6 address space as defined in [ALLOC].
+
+ The proposed initial assignment described in the document is
+ consistent with:
+
+ - RFC 2373,"IP Version 6 Addressing Architecture" [ARCH]
+ - RFC 2374 "An Aggregatable Global Unicast Address Format" [AGGR]
+ - RFC 2450 "Proposed TLA and NLA Assignment Rules" [TLA-RULES]
+
+2. Background
+
+ [TLA-RULES] specifies that TLA assignments will be done in two
+ stages. The first stage is to allocate a Sub-TLA ID. This document
+ specifies the initial assignments of Sub-TLA ID's to the Registries.
+
+ As defined in [TLA-RULES] Section 5.1:
+
+ "Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows. Note
+ that use of the Reserved field to create the Sub-TLA field is
+ specific to TLA ID 0x0001. It does not affect any other TLA.
+
+ | 3 | 13 | 13 | 19 |
+ +----+----------+---------+---------------+
+ | FP | TLA | Sub-TLA | NLA |
+ | | ID | | ID |
+ +----+----------+---------+---------------+
+
+ where:
+
+ FP = 001 = Format Prefix
+
+ This is the Format Prefix used to identify aggregatable global
+ unicast addresses.
+
+ TLA ID = 0x0001 = Top-Level Aggregation Identifier
+
+ This is the TLA ID assigned by the IANA for Sub-TLA
+ allocation.
+
+
+
+
+Hinden, et al. Informational [Page 2]
+
+RFC 2928 Initial IPv6 Sub-TLA ID Assignments September 2000
+
+
+ Sub-TLA ID = Sub-TLA Aggregation Identifier
+
+ The Sub-TLA ID field is used by the registries for initial
+ allocations to organizations meeting the requirements in
+ Section 5.2 of this document. The IANA will assign small
+ blocks (e.g., few hundred) of Sub-TLA ID's to registries. The
+ registries will assign the Sub-TLA ID's to organizations
+ meeting the requirements specified in Section 5.2. When the
+ registries have assigned all of their Sub-TLA ID's they can
+ request that the IANA give them another block. The blocks do
+ not have to be contiguous. The IANA may also assign Sub-TLA
+ ID's to organizations directly. This includes the temporary
+ TLA assignment for testing and experimental usage for
+ activities such as the 6bone or new approaches like exchanges.
+
+ NLA ID = Next-Level Aggregation Identifier
+
+ Next-Level Aggregation ID's are used by organizations assigned
+ a TLA ID to create an addressing hierarchy and to identify
+ sites. The organization can assign the top part of the NLA ID
+ in a manner to create an addressing hierarchy appropriate to
+ its network."
+
+ Note: In the above quote from [TLA-RULES] the references to "Section
+ 5.2" refer to section 5.2 in [TLA-RULES].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et al. Informational [Page 3]
+
+RFC 2928 Initial IPv6 Sub-TLA ID Assignments September 2000
+
+
+3. Initial Assignments
+
+ As specified in [TLA-RULES], Sub-TLA ID assignments are made in
+ blocks. The initial Sub-TLA ID assignments to IP address registries
+ are in blocks of 64 Sub-TLA IDs. These assignments are listed below.
+
+ Binary Value IPv6 Prefix Range Assignment
+ ---------------- ------------------------------- -------------------
+ 0000 000X XXXX X 2001:0000::/29 - 2001:01F8::/29 IANA
+ 0000 001X XXXX X 2001:0200::/29 - 2001:03F8::/29 APNIC
+ 0000 010X XXXX X 2001:0400::/29 - 2001:05F8::/29 ARIN
+ 0000 011X XXXX X 2001:0600::/29 - 2001:07F8::/29 RIPE NCC
+ 0000 100X XXXX X 2001:0800::/29 - 2001:09F8::/29 (future assignment)
+ 0000 101X XXXX X 2001:0A00::/29 - 2001:0BF8::/29 (future assignment)
+ 0000 110X XXXX X 2001:0C00::/29 - 2001:0DF8::/29 (future assignment)
+ 0000 111X XXXX X 2001:0E00::/29 - 2001:0FF8::/29 (future assignment)
+ 0001 000X XXXX X 2001:1000::/29 - 2001:11F8::/29 (future assignment)
+ . . .
+ . . .
+ . . .
+ 1111 111X XXXX X 2001:FE00::/29 - 2001:FFF8::/29 (future assignment)
+
+ Where "X" indicates "0" or "1".
+
+ All other Sub-TLA ID values not listed above are reserved.
+
+ When a registry has assigned all of the Sub-TLA IDs in their block
+ they can request that the IANA provide another block. The blocks
+ assigned to a registry do not have to be contiguous.
+
+ The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:0000::/29 -
+ 2001:01F8::/29) is for assignment for testing and experimental usage
+ to support activities such as the 6bone, and for new approaches like
+ exchanges.
+
+4. Acknowledgments
+
+ The authors would like to express their thanks to Joyce K. Reynolds,
+ Thomas Narten, Kim Hubbard, Mirjam Kuehne, and Brian Carpenter for
+ their help with this document.
+
+5. Security Considerations
+
+ IPv6 addressing documents do not have any direct impact on Internet
+ infrastructure security. Authentication of IPv6 packets is defined
+ in [AUTH]. Authentication of the ownership of prefixes to avoid
+ "prefix stealing" is a related security issue but is beyond the scope
+ of this document.
+
+
+
+Hinden, et al. Informational [Page 4]
+
+RFC 2928 Initial IPv6 Sub-TLA ID Assignments September 2000
+
+
+6. References
+
+ [AGGR] Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable
+ Global Unicast Address Format", RFC 2374, July 1998.
+
+ [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", RFC
+ 1881, December 1995.
+
+ [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC
+ 2373, July 1998.
+
+ [AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+ 2402, November 1998.
+
+ [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [TLA-RULES] Hinden, R., "Proposed TLA and NLA Assignment Rules", RFC
+ 2450, December 1998.
+
+ [TST-ALLOC] Hinden, R., Fink R. and J. Postel, "IPv6 Testing Address
+ Allocation", RFC 2471, December 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et al. Informational [Page 5]
+
+RFC 2928 Initial IPv6 Sub-TLA ID Assignments September 2000
+
+
+7. Authors' Addresses
+
+ Robert M. Hinden
+ Nokia
+ 313 Fairchild Drive
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 625-2004
+ EMail: hinden@iprg.nokia.com
+
+
+ Stephen E. Deering
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ USA
+
+ Phone: +1 408 527-8213
+ EMail: deering@cisco.com
+
+
+ Robert L. Fink
+ Lawrence Berkeley National Lab
+ 1 Cyclotron Rd.
+ Bldg 50A, Room 3111
+ Berkeley, CA 94720
+ USA
+
+ Phone: +1 510 486-5692
+ EMail: rlfink@lbl.gov
+
+
+ Tony Hain
+ Microsoft
+
+ Phone: +1 425 703-6619
+ EMail: tonyhain@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et al. Informational [Page 6]
+
+RFC 2928 Initial IPv6 Sub-TLA ID Assignments September 2000
+
+
+8. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et al. Informational [Page 7]
+