HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 03:50:56 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 13 Jun 1998 01:33:00 GMT ETag: "2f531b-5c38-3581d6cc" Accept-Ranges: bytes Content-Length: 23608 Connection: close Content-Type: text/plain INTERNET-DRAFT R. Hinden, Nokia June 11, 1998 Proposed TLA and NLA Assignment Rules Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This internet draft expires on December 11, 1998. 1.0 Introduction This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. This proposal is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA, and Registries. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", draft-ietf-ipngwg-tla-assignment-04.txt [Page 1] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2.0 Scope The proposed TLA and NLA assignment rules described in this document are intended for the first two years of IPv6 TLA address assignments. As routing technology evolves and we gain additional experience with allocating IPv6 addresses the procedures proposed in this document may change. 3.0 IPv6 Aggregatable Global Unicast Address Format This document proposes assignment rules for the TLA ID and NLA ID fields in the IPv6 Aggregatable Global Unicast Address Format. This address format is designed to support both the current provider-based aggregation and a new type of exchange-based aggregation. The combination will allow efficient routing aggregation for sites that connect directly to providers and for sites that connect to exchanges. Sites will have the choice to connect to either type of aggregation entity. While this address format is designed to support exchange-based aggregation (in addition to current provider-based aggregation) it is not dependent on exchanges for its overall route aggregation properties. It will provide efficient route aggregation with only provider-based aggregation. The aggregatable global unicast address format as defined in [AGGR] is as follows: | 3| 13 | 8 | 24 | 16 | 64 bits | +--+-----+---+--------+--------+--------------------------------+ |FP| TLA |RES| NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+-----+---+--------+--------+--------------------------------+ <--Public Topology---> Site <--------> Topology <------Interface Identifier-----> Where FP Format Prefix (001) TLA ID Top-Level Aggregation Identifier draft-ietf-ipngwg-tla-assignment-04.txt [Page 2] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 RES Reserved for future use NLA ID Next-Level Aggregation Identifier SLA ID Site-Level Aggregation Identifier INTERFACE ID Interface Identifier 4.0 Technical Motivation The design choices for the size of the fields in the aggregatable address format were based on the need to meet a number of technical requirements that are described in [AGGR]. An extract of the technical requirements from [AGGR] is as follows: The size of the Top-Level Aggregation Identifier is 13 bits. This allows for 8,192 TLA ID's. This size was chosen to insure that the default-free routing table in top level routers in the Internet is kept within the limits, with a reasonable margin, of the current routing technology. The margin is important because default-free routers will also carry a significant number of longer (i.e., more-specific) prefixes for optimizing paths internal to a TLA and between TLAs. The important issue is not only the size of the default-free routing table, but the complexity of the topology that determines the number of copies of the default-free routes that a router must examine while computing a forwarding table. In current practice with IPv4, it is common to see a prefix announced fifteen times via different paths. The complexity of Internet topology is very likely to increase in the future. It is important that IPv6 default-free routing support additional complexity as well as a considerably larger internet. It should be noted for comparison that the current IPv4 default- free routing table is approximately 50,000 prefixes. While this shows that it is possible to support more routes than 8,192 it is matter of debate if the number of prefixes supported today in IPv4 is already too high for current routing technology. There are serious issues of route stability as well as cases of providers not supporting all top level prefixes. The technical requirement was to pick a TLA ID size that was below, with a reasonable margin, what was being done with IPv4. The choice of 13 bits for the TLA field was an engineering compromise. Fewer bits would have been too small by not supporting enough top level organizations. More bits would have exceeded what can be reasonably accommodated, with a reasonable margin, with current routing technology in order to deal with the issues described in the previous paragraphs. draft-ietf-ipngwg-tla-assignment-04.txt [Page 3] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 If in the future, routing technology improves to support a larger number of top level routes in the default-free routing tables there are two choices on how to increase the number TLA identifiers. The first is to expand the TLA ID field into the reserved field. This would increase the number of TLA ID's to approximately 2 million. The second approach is to allocate another format prefix (FP) for use with this address format. Either or a combination of these approaches allows the number of TLA ID's to increase significantly. The size of the Reserved field is 8 bits. This size was chosen to allow significant growth of either the TLA ID and/or the NLA ID fields. The size of the Next-Level Aggregation Identifier field is 24 bits. This allows for approximately sixteen million NLA ID's if used in a flat manner. Used hierarchically it allows for a complexity roughly equivalent to the IPv4 address space (assuming an average network size of 254 interfaces). If in the future additional room for complexity is needed in the NLA ID, this may be accommodated by extending the NLA ID into the Reserved field. The size of the Site-Level Aggregation Identifier field is 16 bits. This supports 65,535 individual subnets per site. The design goal for the size of this field was to be sufficient for all but the largest of organizations. Organizations which need additional subnets can arrange with the organization they are obtaining Internet service from to obtain additional site identifiers and use this to create additional subnets. The Site-Level Aggregation Identifier field was given a fixed size in order to force the length of all prefixes identifying a particular site to be the same length (i.e., 48 bits). This facilitates movement of sites in the topology (e.g., changing service providers and multi-homing to multiple service providers). The Interface ID Interface Identifier field is 64 bits. This size was chosen to meet the requirement specified in [ARCH] to support EUI-64 based Interface Identifiers. The proposed TLA/NLA assignment rules described in this document are consistent with these technical requirements. The specific technical motivation for the proposed TLA/NLA assignment rules described in this document is as follows: - Limit the number of top level prefixes in the Internet to a manageable size. This is important to insure that the default- draft-ietf-ipngwg-tla-assignment-04.txt [Page 4] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 free routing table in the top level routers in the Internet is kept within the limits, with a reasonable margin, of current routing technology. - Only assign top level prefixes to transit providers, not to leaf sites even if they are multiply homed. The aggregation address format is designed to have a clear separation between transit providers and leaf sites. Sites which wish to be multihomed to multiple transit providers have in IPv6 a number of alternatives to having a top level prefix. - Only assign top level prefixes to organizations who are capable and intend to provide operational IPv6 transit services within three months of assignment. The goal is to not assign top level prefixes to organizations who only want a prefix in case they might provide service sometime in the future. The assignment of prefixes is intended to closely match the operational IPv6 Internet and to be consistent with the current practice of registries making assignments when addresses are actually used. - Organizations assigned TLA ID's are required to make all the assignments publically available. This is necessary in order for the registries to have accurate information on assignments and to enable trouble shooting Internet problems. - Allocation of prefixes that are consistent with the address format in [AGGR]. Specifically the allocation prefixes that are not longer than 48 bits as to not infringe into the SLA and Interface Identifier fields. This is to facilitate movement of sites in the topology (e.g., changing service providers and multi-homing to multiple service providers). 5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's TLA ID's are assigned to organizations providing transit topology. They are specifically not assigned to organizations only providing leaf topology. TLA ID assignment does not imply ownership. It does imply stewardship over a valuable Internet resource. 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 IANA will assign small blocks (e.g., few hundred) of TLA ID's to registries. The registries will assign the TLA ID's to organizations meeting the requirements for TLA ID assignment. When the registries have assigned all of their TLA ID's they can request that the IANA draft-ietf-ipngwg-tla-assignment-04.txt [Page 5] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 give them another block. The blocks do not have to be contiguous. The IANA may also assign 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. 5.1 Proposed TLA Allocation Stages TLA allocations will be done in two stages. The first stage is to allocate a Sub-TLA ID. When the recipient has demonstrated that they have assigned more than 90% of the NLA ID for their Sub-TLA ID, they will be allocated a TLA ID. The Sub-TLA ID does not have to be returned. 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. 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 draft-ietf-ipngwg-tla-assignment-04.txt [Page 6] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 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. See Section 6.0 for more detail. Sub-TLA allocations are interim until the organization receiving the Sub-TLA can show evidence of IPv6 Internet transit service. If transit service can not be demonstrated by three months from the date of allocation the Sub-TLA allocation will be revoked. As part of assigning a TLA ID to an organization, the IANA or Registries may initially only assign a fraction of the NLA ID space for a particular TLA ID to the organization receiving the TLA ID assignment. When the organization has assigned more than 90% of the NLA ID space it may request additional NLA ID space in its TLA ID. 5.2 Proposed Assignment Requirements The proposed assignment requirements are intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Registries enforce the following requirements for organizations assigned Sub-TLA and TLA ID's: 1) Must have a plan to offer native IPv6 service within 3 months from assignment. The plan must include NLA ID allocation and registration procedures. NLA ID allocation and registration may be subcontracted to other organizations such as a registry. Native IPv6 service is defined as providing IPv6 service as defined in the appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc., for the link at the boundary of the organization. This should include running Neighbor Discovery (as appropriate) and exchanging IPv6 routing information. The method the organization uses to carry IPv6 traffic across its network is independent of this definition and is a local issue for the organization. 2) Must have a verifiable track record of providing Internet transit to other organizations. Sub-TLA and/or TLA ID's must not be draft-ietf-ipngwg-tla-assignment-04.txt [Page 7] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 assigned to organizations that are only providing leaf service even if multihomed. Verification of an organization's track record in providing Internet transit service must be verified by techniques such as traceroute, BGP advertisements, etc. 3) Payment of a registration fee to the Internet Assigned Numbers Authority (IANA). Registries may also charge some fee for services rendered, generally in relation to the cost of providing those services. All payment of registration and service fees must be made prior to the actual Sub-TLA ID and/or TLA ID assignment. 4) Must provide registry services for the NLA ID address space it is responsible for under its Sub-TLA ID and/or TLA ID. This must include both sites and next level providers. The database of NLA assignments must be public and made available to the registries. 5) Periodically (interval set by registry) provide to registry utilization statistics of the Sub-TLA ID and/or TLA ID it has custody of. The organization must also show evidence of carrying TLA routing and transit traffic. This can be in the form of traffic statistics, traceroutes, routing table dumps, or similar means. 6) Organizations requesting another Sub-TLA and/or TLA ID must show evidence to the registries that they have assigned more than 90% of the NLA ID space in their previous allocations. Organizations which are given custody of a Sub-TLA ID and/or TLA ID, and fail to continue to meet all the above requirements may have the Sub-TLA ID and/or TLA ID custody revoked. 6.0 Proposed Rules Assignment of Next-Level Aggregation ID's Next-Level Aggregation ID's are used by organizations assigned a Sub- TLA ID and/or 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. Registries may initially only assign a fraction of the NLA ID space for a particular Sub-TLA ID and/or TLA ID to the organization receiving the Sub-TLA ID and/or TLA ID assignment. When the organization has assigned more than 90% of the NLA ID space it may request additional NLA ID space in its Sub-TLA ID and/or TLA ID. draft-ietf-ipngwg-tla-assignment-04.txt [Page 8] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 Organizations assigned Sub-TLA ID and/or TLA ID's are required to assume (directly or indirectly) registry duties for the NLA ID's they assign. Each organization assigned a NLA ID is required to assume registry duties for the next level NLA ID's it assigns and follow Registry guidelines. This responsibility includes passing this information back to the registry that assigned the TLA and/or Sub- TLA. The TLA ID and/or Sub-TLA ID holder collects this information from the next level, the next level holder collects this information from the level below, etc. The design of the bit layout of the NLA ID space for a specific Sub- TLA ID and/or TLA ID is left to the organization responsible for that Sub-TLA ID and/or TLA ID. Likewise the design of the bit layout of the next level NLA ID is the responsibility of the organization assigned the previous level NLA ID. It is recommended that organizations assigning NLA address space use "slow start" allocation procedures as is currently done with IPv4 CIDR blocks [CIDR]. The design of an NLA ID allocation plan is a tradeoff between routing aggregation efficiency and flexibility. Creating hierarchies allows for greater amount of aggregation and results in smaller routing tables. Flat NLA ID assignment provides for easier allocation and attachment flexibility, but results in larger routing tables. 7.0 Acknowledgments The author would like to express his thanks to Thomas Narten, Steve Deering, Bob Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart, Eric Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard, Mirjam Kuehne, Paula Caslav, David Conrad, and David Kessens for their review and constructive comments. 8.0 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. draft-ietf-ipngwg-tla-assignment-04.txt [Page 9] INTERNET-DRAFT Proposed TLA and NLA Assignment Rules June 11, 1998 9.0 References [AGGR] Hinden, R., Deering, S., O'Dell, M., "An Aggregatable Global Unicast Address Format", Internet Draft, , March 1998. [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", RFC1881, December 1995. [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", Internet Draft, , January 1998. [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 1995. [CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, September 1993. [ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet Networks", Internet Draft, , November 1997. [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", Internet Draft, , November 1997. [IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC1883, December 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP14, March 1997. 10.0 Authors' Address Robert M. Hinden phone: +1 408 990-2004 Nokia email: hinden@iprg.nokia.com 232 Java Drive Sunnyvale, CA 94089 USA draft-ietf-ipngwg-tla-assignment-04.txt [Page 10]