idnits 2.17.1 draft-ietf-ipngwg-tla-assignment-04.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-19) 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.) -- The document date (June 11, 1998) is 9444 days in the past. Is this intentional? 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 43, but not defined == Unused Reference: 'IPV6' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 443, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AGGR' ** Downref: Normative reference to an Informational RFC: RFC 1881 (ref. 'ALLOC') -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' ** Obsolete normative reference: RFC 1826 (ref. 'AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETHER' -- Possible downref: Non-RFC (?) normative reference: ref. 'FDDI' ** Obsolete normative reference: RFC 1883 (ref. 'IPV6') (Obsoleted by RFC 2460) Summary: 13 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 June 11, 1998 4 Proposed TLA and NLA Assignment Rules 6 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 Please check the 1id-abstracts.txt listing contained in the internet- 22 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 23 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 24 current status of any Internet Draft. 26 This internet draft expires on December 11, 1998. 28 1.0 Introduction 30 This document proposes rules for Top-Level Aggregation Identifiers 31 (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined 32 in [AGGR]. These proposed rules apply to registries allocating TLA 33 ID's and to organizations receiving TLA ID's. 35 This proposal is intended as input from the IPng working group to the 36 IANA and Registries. It is not intended for any official IETF 37 status. Its content represents the result of extensive discussion 38 between the IPng working group, IANA, and Registries. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC 2119]. 44 2.0 Scope 46 The proposed TLA and NLA assignment rules described in this document 47 are intended for the first two years of IPv6 TLA address assignments. 48 As routing technology evolves and we gain additional experience with 49 allocating IPv6 addresses the procedures proposed in this document 50 may change. 52 3.0 IPv6 Aggregatable Global Unicast Address Format 54 This document proposes assignment rules for the TLA ID and NLA ID 55 fields in the IPv6 Aggregatable Global Unicast Address Format. This 56 address format is designed to support both the current provider-based 57 aggregation and a new type of exchange-based aggregation. The 58 combination will allow efficient routing aggregation for sites that 59 connect directly to providers and for sites that connect to 60 exchanges. Sites will have the choice to connect to either type of 61 aggregation entity. 63 While this address format is designed to support exchange-based 64 aggregation (in addition to current provider-based aggregation) it is 65 not dependent on exchanges for its overall route aggregation 66 properties. It will provide efficient route aggregation with only 67 provider-based aggregation. 69 The aggregatable global unicast address format as defined in [AGGR] 70 is as follows: 72 | 3| 13 | 8 | 24 | 16 | 64 bits | 73 +--+-----+---+--------+--------+--------------------------------+ 74 |FP| TLA |RES| NLA | SLA | Interface ID | 75 | | ID | | ID | ID | | 76 +--+-----+---+--------+--------+--------------------------------+ 78 <--Public Topology---> Site 79 <--------> 80 Topology 81 <------Interface Identifier-----> 83 Where 85 FP Format Prefix (001) 86 TLA ID Top-Level Aggregation Identifier 87 RES Reserved for future use 88 NLA ID Next-Level Aggregation Identifier 89 SLA ID Site-Level Aggregation Identifier 90 INTERFACE ID Interface Identifier 92 4.0 Technical Motivation 94 The design choices for the size of the fields in the aggregatable 95 address format were based on the need to meet a number of technical 96 requirements that are described in [AGGR]. An extract of the 97 technical requirements from [AGGR] is as follows: 99 The size of the Top-Level Aggregation Identifier is 13 bits. This 100 allows for 8,192 TLA ID's. This size was chosen to insure that 101 the default-free routing table in top level routers in the 102 Internet is kept within the limits, with a reasonable margin, of 103 the current routing technology. The margin is important because 104 default-free routers will also carry a significant number of 105 longer (i.e., more-specific) prefixes for optimizing paths 106 internal to a TLA and between TLAs. 108 The important issue is not only the size of the default-free 109 routing table, but the complexity of the topology that determines 110 the number of copies of the default-free routes that a router must 111 examine while computing a forwarding table. In current practice 112 with IPv4, it is common to see a prefix announced fifteen times 113 via different paths. The complexity of Internet topology is very 114 likely to increase in the future. It is important that IPv6 115 default-free routing support additional complexity as well as a 116 considerably larger internet. 118 It should be noted for comparison that the current IPv4 default- 119 free routing table is approximately 50,000 prefixes. While this 120 shows that it is possible to support more routes than 8,192 it is 121 matter of debate if the number of prefixes supported today in IPv4 122 is already too high for current routing technology. There are 123 serious issues of route stability as well as cases of providers 124 not supporting all top level prefixes. The technical requirement 125 was to pick a TLA ID size that was below, with a reasonable 126 margin, what was being done with IPv4. 128 The choice of 13 bits for the TLA field was an engineering 129 compromise. Fewer bits would have been too small by not 130 supporting enough top level organizations. More bits would have 131 exceeded what can be reasonably accommodated, with a reasonable 132 margin, with current routing technology in order to deal with the 133 issues described in the previous paragraphs. 135 If in the future, routing technology improves to support a larger 136 number of top level routes in the default-free routing tables 137 there are two choices on how to increase the number TLA 138 identifiers. The first is to expand the TLA ID field into the 139 reserved field. This would increase the number of TLA ID's to 140 approximately 2 million. The second approach is to allocate 141 another format prefix (FP) for use with this address format. 142 Either or a combination of these approaches allows the number of 143 TLA ID's to increase significantly. 145 The size of the Reserved field is 8 bits. This size was chosen to 146 allow significant growth of either the TLA ID and/or the NLA ID 147 fields. 149 The size of the Next-Level Aggregation Identifier field is 24 150 bits. This allows for approximately sixteen million NLA ID's if 151 used in a flat manner. Used hierarchically it allows for a 152 complexity roughly equivalent to the IPv4 address space (assuming 153 an average network size of 254 interfaces). If in the future 154 additional room for complexity is needed in the NLA ID, this may 155 be accommodated by extending the NLA ID into the Reserved field. 157 The size of the Site-Level Aggregation Identifier field is 16 158 bits. This supports 65,535 individual subnets per site. The 159 design goal for the size of this field was to be sufficient for 160 all but the largest of organizations. Organizations which need 161 additional subnets can arrange with the organization they are 162 obtaining Internet service from to obtain additional site 163 identifiers and use this to create additional subnets. 165 The Site-Level Aggregation Identifier field was given a fixed size 166 in order to force the length of all prefixes identifying a 167 particular site to be the same length (i.e., 48 bits). This 168 facilitates movement of sites in the topology (e.g., changing 169 service providers and multi-homing to multiple service providers). 171 The Interface ID Interface Identifier field is 64 bits. This size 172 was chosen to meet the requirement specified in [ARCH] to support 173 EUI-64 based Interface Identifiers. 175 The proposed TLA/NLA assignment rules described in this document are 176 consistent with these technical requirements. 178 The specific technical motivation for the proposed TLA/NLA assignment 179 rules described in this document is as follows: 181 - Limit the number of top level prefixes in the Internet to a 182 manageable size. This is important to insure that the default- 183 free routing table in the top level routers in the Internet is 184 kept within the limits, with a reasonable margin, of current 185 routing technology. 187 - Only assign top level prefixes to transit providers, not to leaf 188 sites even if they are multiply homed. The aggregation address 189 format is designed to have a clear separation between transit 190 providers and leaf sites. Sites which wish to be multihomed to 191 multiple transit providers have in IPv6 a number of alternatives 192 to having a top level prefix. 194 - Only assign top level prefixes to organizations who are capable 195 and intend to provide operational IPv6 transit services within 196 three months of assignment. The goal is to not assign top level 197 prefixes to organizations who only want a prefix in case they 198 might provide service sometime in the future. The assignment of 199 prefixes is intended to closely match the operational IPv6 200 Internet and to be consistent with the current practice of 201 registries making assignments when addresses are actually used. 203 - Organizations assigned TLA ID's are required to make all the 204 assignments publically available. This is necessary in order for 205 the registries to have accurate information on assignments and to 206 enable trouble shooting Internet problems. 208 - Allocation of prefixes that are consistent with the address format 209 in [AGGR]. Specifically the allocation prefixes that are not 210 longer than 48 bits as to not infringe into the SLA and Interface 211 Identifier fields. This is to facilitate movement of sites in the 212 topology (e.g., changing service providers and multi-homing to 213 multiple service providers). 215 5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's 217 TLA ID's are assigned to organizations providing transit topology. 218 They are specifically not assigned to organizations only providing 219 leaf topology. TLA ID assignment does not imply ownership. It does 220 imply stewardship over a valuable Internet resource. 222 The IAB and IESG have authorized the Internet Assigned Numbers 223 Authority (IANA) as the appropriate entity to have the responsibility 224 for the management of the IPv6 address space as defined in [ALLOC]. 226 The IANA will assign small blocks (e.g., few hundred) of TLA ID's to 227 registries. The registries will assign the TLA ID's to organizations 228 meeting the requirements for TLA ID assignment. When the registries 229 have assigned all of their TLA ID's they can request that the IANA 230 give them another block. The blocks do not have to be contiguous. 231 The IANA may also assign TLA ID's to organizations directly. This 232 includes the temporary TLA assignment for testing and experimental 233 usage for activities such as the 6bone or new approaches like 234 exchanges. 236 5.1 Proposed TLA Allocation Stages 238 TLA allocations will be done in two stages. The first stage is to 239 allocate a Sub-TLA ID. When the recipient has demonstrated that they 240 have assigned more than 90% of the NLA ID for their Sub-TLA ID, they 241 will be allocated a TLA ID. The Sub-TLA ID does not have to be 242 returned. 244 Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows. Note that 245 use of the Reserved field to create the Sub-TLA field is specific to 246 TLA ID 0x0001. It does not affect any other TLA. 248 | 3 | 13 | 13 | 19 | 249 +----+----------+---------+---------------+ 250 | FP | TLA | Sub-TLA | NLA | 251 | | ID | | ID | 252 +----+----------+---------+---------------+ 254 where: 256 FP = 001 = Format Prefix 258 This is the Format Prefix used to identify aggregatable global 259 unicast addresses. 261 TLA ID = 0x0001 = Top-Level Aggregation Identifier 263 This is the TLA ID assigned by the IANA for Sub-TLA allocation. 265 Sub-TLA ID = Sub-TLA Aggregation Identifier 267 The Sub-TLA ID field is used by the registries for initial 268 allocations to organizations meeting the requirements in Section 269 5.2 of this document. The IANA will assign small blocks (e.g., 270 few hundred) of Sub-TLA ID's to registries. The registries will 271 assign the Sub-TLA ID's to organizations meeting the requirements 272 specified in Section 5.2. When the registries have assigned all 273 of their Sub-TLA ID's they can request that the IANA give them 274 another block. The blocks do not have to be contiguous. The 275 IANA may also assign Sub-TLA ID's to organizations directly. 276 This includes the temporary TLA assignment for testing and 277 experimental usage for activities such as the 6bone or new 278 approaches like exchanges. 280 NLA ID = Next-Level Aggregation Identifier 282 Next-Level Aggregation ID's are used by organizations assigned a 283 TLA ID to create an addressing hierarchy and to identify sites. 284 The organization can assign the top part of the NLA ID in a 285 manner to create an addressing hierarchy appropriate to its 286 network. See Section 6.0 for more detail. 288 Sub-TLA allocations are interim until the organization receiving the 289 Sub-TLA can show evidence of IPv6 Internet transit service. If 290 transit service can not be demonstrated by three months from the date 291 of allocation the Sub-TLA allocation will be revoked. 293 As part of assigning a TLA ID to an organization, the IANA or 294 Registries may initially only assign a fraction of the NLA ID space 295 for a particular TLA ID to the organization receiving the TLA ID 296 assignment. When the organization has assigned more than 90% of the 297 NLA ID space it may request additional NLA ID space in its TLA ID. 299 5.2 Proposed Assignment Requirements 301 The proposed assignment requirements are intended as input from the 302 IPng working group to the IANA and Registries. It is not intended 303 for any official IETF status. 305 Registries enforce the following requirements for organizations 306 assigned Sub-TLA and TLA ID's: 308 1) Must have a plan to offer native IPv6 service within 3 months from 309 assignment. The plan must include NLA ID allocation and 310 registration procedures. NLA ID allocation and registration may 311 be subcontracted to other organizations such as a registry. 313 Native IPv6 service is defined as providing IPv6 service as 314 defined in the appropriate "IPv6 over " specification such 315 as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc., 316 for the link at the boundary of the organization. This should 317 include running Neighbor Discovery (as appropriate) and exchanging 318 IPv6 routing information. The method the organization uses to 319 carry IPv6 traffic across its network is independent of this 320 definition and is a local issue for the organization. 322 2) Must have a verifiable track record of providing Internet transit 323 to other organizations. Sub-TLA and/or TLA ID's must not be 324 assigned to organizations that are only providing leaf service 325 even if multihomed. 327 Verification of an organization's track record in providing 328 Internet transit service must be verified by techniques such as 329 traceroute, BGP advertisements, etc. 331 3) Payment of a registration fee to the Internet Assigned Numbers 332 Authority (IANA). Registries may also charge some fee for 333 services rendered, generally in relation to the cost of providing 334 those services. All payment of registration and service fees must 335 be made prior to the actual Sub-TLA ID and/or TLA ID assignment. 337 4) Must provide registry services for the NLA ID address space it is 338 responsible for under its Sub-TLA ID and/or TLA ID. This must 339 include both sites and next level providers. The database of NLA 340 assignments must be public and made available to the registries. 342 5) Periodically (interval set by registry) provide to registry 343 utilization statistics of the Sub-TLA ID and/or TLA ID it has 344 custody of. The organization must also show evidence of carrying 345 TLA routing and transit traffic. This can be in the form of 346 traffic statistics, traceroutes, routing table dumps, or similar 347 means. 349 6) Organizations requesting another Sub-TLA and/or TLA ID must show 350 evidence to the registries that they have assigned more than 90% 351 of the NLA ID space in their previous allocations. 353 Organizations which are given custody of a Sub-TLA ID and/or TLA ID, 354 and fail to continue to meet all the above requirements may have the 355 Sub-TLA ID and/or TLA ID custody revoked. 357 6.0 Proposed Rules Assignment of Next-Level Aggregation ID's 359 Next-Level Aggregation ID's are used by organizations assigned a Sub- 360 TLA ID and/or TLA ID to create an addressing hierarchy and to 361 identify sites. The organization can assign the top part of the NLA 362 ID in a manner to create an addressing hierarchy appropriate to its 363 network. 365 Registries may initially only assign a fraction of the NLA ID space 366 for a particular Sub-TLA ID and/or TLA ID to the organization 367 receiving the Sub-TLA ID and/or TLA ID assignment. When the 368 organization has assigned more than 90% of the NLA ID space it may 369 request additional NLA ID space in its Sub-TLA ID and/or TLA ID. 371 Organizations assigned Sub-TLA ID and/or TLA ID's are required to 372 assume (directly or indirectly) registry duties for the NLA ID's they 373 assign. Each organization assigned a NLA ID is required to assume 374 registry duties for the next level NLA ID's it assigns and follow 375 Registry guidelines. This responsibility includes passing this 376 information back to the registry that assigned the TLA and/or Sub- 377 TLA. The TLA ID and/or Sub-TLA ID holder collects this information 378 from the next level, the next level holder collects this information 379 from the level below, etc. 381 The design of the bit layout of the NLA ID space for a specific Sub- 382 TLA ID and/or TLA ID is left to the organization responsible for that 383 Sub-TLA ID and/or TLA ID. Likewise the design of the bit layout of 384 the next level NLA ID is the responsibility of the organization 385 assigned the previous level NLA ID. It is recommended that 386 organizations assigning NLA address space use "slow start" allocation 387 procedures as is currently done with IPv4 CIDR blocks [CIDR]. 389 The design of an NLA ID allocation plan is a tradeoff between routing 390 aggregation efficiency and flexibility. Creating hierarchies allows 391 for greater amount of aggregation and results in smaller routing 392 tables. Flat NLA ID assignment provides for easier allocation and 393 attachment flexibility, but results in larger routing tables. 395 7.0 Acknowledgments 397 The author would like to express his thanks to Thomas Narten, Steve 398 Deering, Bob Fink, Matt Crawford, Allison Mankin, Jim Bound, 399 Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart, Eric 400 Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard, Mirjam Kuehne, 401 Paula Caslav, David Conrad, and David Kessens for their review and 402 constructive comments. 404 8.0 Security Considerations 406 IPv6 addressing documents do not have any direct impact on Internet 407 infrastructure security. Authentication of IPv6 packets is defined 408 in [AUTH]. Authentication of the ownership of prefixes to avoid 409 "prefix stealing" is a related security issue but is beyond the scope 410 of this document. 412 9.0 References 414 [AGGR] Hinden, R., Deering, S., O'Dell, M., "An Aggregatable 415 Global Unicast Address Format", Internet Draft, , March 1998. 418 [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", 419 RFC1881, December 1995. 421 [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", 422 Internet Draft, , 423 January 1998. 425 [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 426 1995. 428 [CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Classless Inter- 429 Domain Routing (CIDR): an Address Assignment and 430 Aggregation Strategy", RFC1519, September 1993. 432 [ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet 433 Networks", Internet Draft, , November 1997. 436 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 437 Networks", Internet Draft, , November 1997. 440 [IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol, 441 Version 6 (IPv6) Specification", RFC1883, December 1995. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", RFC2119, BCP14, March 1997. 446 10.0 Authors' Address 448 Robert M. Hinden phone: +1 408 990-2004 449 Nokia email: hinden@iprg.nokia.com 450 232 Java Drive 451 Sunnyvale, CA 94089 452 USA