diff options
Diffstat (limited to 'doc/rfc/rfc2450.txt')
| -rw-r--r-- | doc/rfc/rfc2450.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2450.txt b/doc/rfc/rfc2450.txt new file mode 100644 index 0000000..c4e2133 --- /dev/null +++ b/doc/rfc/rfc2450.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group R. Hinden +Request for Comments: 2450 Nokia +Category: Informational December 1998 + + + Proposed TLA and NLA Assignment Rules + +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 (1998). All Rights Reserved. + +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", + "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. + + + + + + + + + + + +Hinden Informational [Page 1] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + +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 + 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: + + + + + +Hinden Informational [Page 2] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + + 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. + + 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. + + + + + + +Hinden Informational [Page 3] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + + 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- + 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. + + + +Hinden Informational [Page 4] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + + - 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 + 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. + + + + + + + + + + +Hinden Informational [Page 5] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + +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 + experimental usage for activities such as the 6bone or new + approaches like exchanges. + + + + + + + +Hinden Informational [Page 6] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + + 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 <link>" 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 + assigned to organizations that are only providing leaf service + even if multihomed. + + + + + +Hinden Informational [Page 7] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + + 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. + + 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 + + + +Hinden Informational [Page 8] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + + 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, Rebecca Nitzan, 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. + +9.0 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. + + + + +Hinden Informational [Page 9] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + + [AUTH] Atkinson, R. and S. Kent, "IP Authentication Header", RFC + 2402, November 1998. + + [CIDR] Fuller, V., Li, T., Varadhan, K. and J. Yu, "Classless + Inter-Domain Routing (CIDR): an Address Assignment and + Aggregation Strategy", RFC 1519, September 1993. + + [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2464, December 1998. + + [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI + Networks", RFC 2467, December 1998. + + [IPV6] Deering, S. and R. Hinden, Editors, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +10.0 Author's Address + + Robert M. Hinden + Nokia + 232 Java Drive + Sunnyvale, CA 94089 + USA + + Phone: +1 408 990-2004 + EMail: hinden@iprg.nokia.com + + + + + + + + + + + + + + + + + + + + + + +Hinden Informational [Page 10] + +RFC 2450 Proposed TLA and NLA Assignment Rules December 1998 + + +11.0 Full Copyright Statement + + Copyright (C) The Internet Society (1998). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Hinden Informational [Page 11] + |