idnits 2.17.1 draft-ietf-ipngwg-iana-tla-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 57, but not defined == Unused Reference: 'IPV6' is defined on line 194, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 198, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) ** Downref: Normative reference to an Informational RFC: RFC 1881 (ref. 'ALLOC') ** Obsolete normative reference: RFC 2373 (ref. 'ARCH') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. 'AUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'TLA-RULES' -- Possible downref: Non-RFC (?) normative reference: ref. 'TST-ALLOC' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 November 16, 1998 S. Deering, Cisco 3 R. Fink, LBNL 4 T. Hain, Microsoft 6 Initial IPv6 Sub-TLA ID Assignments 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 This internet draft expires on May 16, 1999. 31 1.0 Introduction 33 This document proposes initial assignments of IPv6 Sub-TLA 34 Aggregation Identifiers (Sub-TLA ID) to the Address Registries and 35 continued management of the IP6.INT domain. It is intended as input 36 to the IANA from the IETF IP Next Generation (IPNG) and Next 37 Generation Transition (NGTRANS) working groups as an aid in starting 38 the process of allocating IPv6 addresses. It is not intended for any 39 official IETF status. 41 INTERNET-DRAFT Initial IPv6 Sub-TLA ID Assignments 16-Nov-98 43 The IAB and IESG have authorized the Internet Assigned Numbers 44 Authority (IANA) as the appropriate entity to have the responsibility 45 for the management of the IPv6 address space as defined in [ALLOC]. 47 The proposed initial assignment described in the document is 48 consistent with: 50 - RFC 2373,"IP Version 6 Addressing Architecture" [ARCH] 51 - RFC 2374 "An Aggregatable Global Unicast Address Format" [AGGR] 52 - "Proposed TLA and NLA Assignment Rules" [TLA-RULES] 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC 2119]. 58 2.0 Background 60 [TLA-RULES] specifies that TLA assignments will be done in two 61 stages. The first stage is to allocate a Sub-TLA ID. This document 62 specifies the initial assignments of Sub-TLA ID's to the Registries. 64 As defined in [TLA-RULES] Section 5.1: 66 "Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows. Note 67 that use of the Reserved field to create the Sub-TLA field is 68 specific to TLA ID 0x0001. It does not affect any other TLA. 70 | 3 | 13 | 13 | 19 | 71 +----+----------+---------+---------------+ 72 | FP | TLA | Sub-TLA | NLA | 73 | | ID | | ID | 74 +----+----------+---------+---------------+ 76 where: 78 FP = 001 = Format Prefix 80 This is the Format Prefix used to identify aggregatable global 81 unicast addresses. 83 TLA ID = 0x0001 = Top-Level Aggregation Identifier 85 This is the TLA ID assigned by the IANA for Sub-TLA 86 allocation. 88 Sub-TLA ID = Sub-TLA Aggregation Identifier 90 INTERNET-DRAFT Initial IPv6 Sub-TLA ID Assignments 16-Nov-98 92 The Sub-TLA ID field is used by the registries for initial 93 allocations to organizations meeting the requirements in 94 Section 5.2 of this document. The IANA will assign small 95 blocks (e.g., few hundred) of Sub-TLA ID's to registries. The 96 registries will assign the Sub-TLA ID's to organizations 97 meeting the requirements specified in Section 5.2. When the 98 registries have assigned all of their Sub-TLA ID's they can 99 request that the IANA give them another block. The blocks do 100 not have to be contiguous. The IANA may also assign Sub-TLA 101 ID's to organizations directly. This includes the temporary 102 TLA assignment for testing and experimental usage for 103 activities such as the 6bone or new approaches like exchanges. 105 NLA ID = Next-Level Aggregation Identifier 107 Next-Level Aggregation ID's are used by organizations assigned 108 a TLA ID to create an addressing hierarchy and to identify 109 sites. The organization can assign the top part of the NLA ID 110 in a manner to create an addressing hierarchy appropriate to 111 its network." 113 3.0 Initial Assignments 115 As specified in [TLA-RULES] assignments of Sub-TLA ID's will be done 116 in blocks. The initial assignment of Sub-TLA ID's to registries will 117 be in blocks of 64 Sub-TLA ID's. These assignments are as follows: 119 Binary Range (Hex) Assignment 120 ---------------- --------------- ------------------- 121 0 0000 00XX XXXX 0x0000 - 0x003F IANA 122 0 0000 01XX XXXX 0x0040 - 0x007F APNIC 123 0 0000 10XX XXXX 0x0080 - 0x00BF ARIN 124 0 0000 11XX XXXX 0x00C0 - 0x00FF RIPE 125 0 0001 00XX XXXX 0x0100 - 0x013F (future assignment) 126 0 0001 01XX XXXX 0x0140 - 0x017F (future assignment) 127 0 0001 10XX XXXX 0x0180 - 0x01BF (future assignment) 128 0 0001 11XX XXXX 0x01C0 - 0x01FF (future assignment) 129 0 0010 00XX XXXX 0x0200 - 0x023F (future assignment) 130 . . . 131 . . . 132 . . . 133 1 1111 11XX XXXX 0x1FC0 - 0x1FFF (future assignment) 135 Where "X" indicates "0" or "1". 137 When a registry has assigned all of the Sub-TLA ID's in their block 138 they can request that the IANA provide another block. The blocks 139 assigned to a registry do not have to be contiguous. 141 INTERNET-DRAFT Initial IPv6 Sub-TLA ID Assignments 16-Nov-98 143 The block of Sub-TLA ID's assigned to the IANA (i.e., 0x0000 - 144 0x003F) is for assignment for testing and experimental usage to 145 support activities such as the 6bone, and for new approaches like 146 exchanges. 148 4.0 IP6.INT DOMAIN Management 150 In RFC-1886, "DNS Extensions to support IP version 6", a special 151 domain is defined to look up a record given an address. The intent of 152 this domain is to provide a way of mapping an IPv6 address to a host 153 name, although it may be used for other purposes as well. The domain 154 is rooted at IP6.INT. 156 The IP6.INT domain has been in use for the IPv6 "6bone" testbed 157 network to provide mapping from IPv6 Test addresses to domain names 158 under the special IPv6 Testing Address Allocation [TST-ALLOC] and has 159 been managed by direction of the IANA at ISI. 161 The management of the IP6.INT domain will continue to be done in the 162 same manner for the Sub-TLA ID's as they are assigned based on the 163 assignment defined in this document. 165 5.0 Acknowledgments 167 The authors would like to express their thanks to Joyce Reynolds and 168 Thomas Narten for their help with this document. 170 6.0 Security Considerations 172 IPv6 addressing documents do not have any direct impact on Internet 173 infrastructure security. Authentication of IPv6 packets is defined 174 in [AUTH]. Authentication of the ownership of prefixes to avoid 175 "prefix stealing" is a related security issue but is beyond the scope 176 of this document. 178 7.0 References 180 [AGGR] Hinden, R., Deering, S., O'Dell, M., "An Aggregatable 181 Global Unicast Address Format", RFC 2374, July 1998. 183 [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", 184 RFC1881, December 1995. 186 INTERNET-DRAFT Initial IPv6 Sub-TLA ID Assignments 16-Nov-98 188 [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC 189 2373, July 1998. 191 [AUTH] Atkinson, R., S. Kent, "IP Authentication Header", 192 Internet Draft, July 1998. 194 [IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol, 195 Version 6 (IPv6) Specification", Internet Draft, November 196 1997. 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", RFC2119, BCP14, March 1997. 201 [TLA-RULES] Hinden, R., "Proposed TLA and NLA Assignment Rules", 202 Internet Draft, August 1998. 204 [TST-ALLOC] Hinden, R., R. Fink, J. Postel, "IPv6 Testing Address 205 Allocation", Internet-Draft, July 1997. 207 8.0 Authors' Addresses 209 Robert M. Hinden phone: +1 408 990-2004 210 Nokia email: hinden@iprg.nokia.com 211 232 Java Drive 212 Sunnyvale, CA 94089 213 USA 215 Stephen E. Deering phone: +1 408 527-8213 216 Cisco Systems, Inc. email: deering@cisco.com 217 170 West Tasman Drive 218 San Jose, CA 95134-1706 219 USA 221 Robert L. Fink phone: +1 510 486-5692 222 Lawrence Berkeley National Lab email: rlfink@lbl.gov 223 1 Cyclotron Rd. 224 Bldg 50A, Room 3111 225 Berkeley, CA 94720 226 USA 228 Tony Hain phone: +1 425 703-6619 229 Microsoft email: tonyhain@microsoft.com