INTERNET-DRAFT R. Hinden, Nokia January 22, 1998 M. O'Dell, UUNET S. Deering, Cisco An IPv6 Aggregatable Global Unicast Address Format 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 August 22, 1998. 1.0 Introduction This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the ''IPv6 Addressing Architecture'' [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, ''An IPv6 Provider-Based Unicast Address Format''. RFC 2073 will become historic. 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]. draft-ietf-ipngwg-unicast-aggr-03.txt [Page 1] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 2.0 Overview of the IPv6 Address IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast, Anycast, and Multicast. This document defines a specific type of Unicast address. In this document, fields in addresses are given specific names, for example "subnet". When this name is used with the term "ID" (for "identifier") after the name (e.g., "subnet ID"), it refers to the contents of the named field. When it is used with the term "prefix" (e.g. "subnet prefix") it refers to all of the addressing bits to the left of and including this field. IPv6 unicast addresses are designed assuming that the Internet routing system makes forwarding decisions based on a "longest prefix match" algorithm on arbitrary bit boundaries and does not have any knowledge of the internal structure of IPv6 addresses. The structure in IPv6 addresses is for assignment and allocation. The only exception to this is the distinction made between unicast and multicast addresses. The specific type of an IPv6 address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP). This document defines an address format for the 001 (binary) Format Prefix for Aggregatable Global Unicast addresses. The same address format could be used for other Format Prefixes, as long as these Format Prefixes also identify IPv6 unicast addresses. Only the "001" Format Prefix is defined here. 3.0 IPv6 Aggregatable Global Unicast Address Format This document defines an address format for the IPv6 aggregatable global unicast address assignment. The authors believe that this address format will be widely used for IPv6 nodes connected to the Internet. 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 it's overall route aggregation draft-ietf-ipngwg-unicast-aggr-03.txt [Page 2] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 properties. It will provide efficient route aggregation with only provider-based aggregation. Aggregatable addresses are organized into a three level hierarchy: - Public Topology - Site Topology - Interface Identifier Public topology is the collection of providers and exchanges who provide public Internet transit services. Site topology is local to a specific site or organization which does not provide public transit service to nodes outside of the site. Interface identifiers identify interfaces on links. ______________ ______________ --+/ \+--------------+/ \+---------- ( P1 ) +----+ ( P3 ) +----+ +\______________/ | |----+\______________/+--| |-- | +--| X1 | +| X2 | | ______________ / | |-+ ______________ / | |-- +/ \+ +-+--+ \ / \+ +----+ ( P2 ) / \ +( P4 ) --+\______________/ / \ \______________/ | / \ | | | / | | | | / | | | _|_ _/_ _|_ _|_ _|_ / \ / \ / \ / \ / \ ( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C ) \___/ \___/ \___/ \___/ \___/ | / \ _|_ _/_ \ ___ / \ / \ +-/ \ ( S.D ) ( S.E ) ( S.F ) \___/ \___/ \___/ As shown in the figure above, the aggregatable address format is designed to support long-haul providers (shown as P1, P2, P3, and P4), exchanges (shown as X1 and X2), multiple levels of providers (shown at P5 and P6), and subscribers (shown as S.x) Exchanges (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses. Organizations who connect to these exchanges will also subscribe (directly, indirectly via the exchange, etc.) for long-haul service from one or more long-haul providers. Doing so, they will achieve addressing independence from long-haul transit providers. They will be able to change long-haul providers without having to renumber their organization. They can also be multihomed via the exchange to draft-ietf-ipngwg-unicast-aggr-03.txt [Page 3] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 more than one long-haul provider without having to have address prefixes from each long-haul provider. Note that the mechanisms used for this type of provider selection and portability are not discussed in the document. 3.1 Aggregatable Global Unicast Address Structure The aggregatable global unicast address format 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 The following sections specify each part of the IPv6 Aggregatable Global Unicast address format. 3.2 Top-Level Aggregation ID Top-Level Aggregation Identifiers (TLA ID) are the top level in the routing hierarchy. Default-free routers must have a routing table entry for every active TLA ID and will probably have additional entries providing routing information for the TLA ID in which they are located. They may have additional entries in order to optimize routing for their specific topology, but the routing topology at all levels must be designed to minimize the number of additional entries fed into the default free routing tables. This addressing format supports 8,192 (2^13) TLA ID's. Additional TLA ID's may be added by either growing the TLA field to the right into the reserved field or by using this format for additional format draft-ietf-ipngwg-unicast-aggr-03.txt [Page 4] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 prefixes. The issues relating to TLA ID assignment are beyond the scope of this document. They will be described in a document under preparation. 3.3 Reserved The Reserved field is reserved for future use and must be set to zero. The Reserved field allows for future growth of the TLA and NLA fields as appropriate. See section 4.0 for a discussion. 3.4 Next-Level Aggregation Identifier Next-Level Aggregation Identifier'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. It can use the remainder of the bits in the field to identify sites it wishes to serve. This is shown as follows: | n | 24-n bits | 16 | 64 bits | +-----+--------------------+--------+-----------------+ |NLA1 | Site ID | SLA ID | Interface ID | +-----+--------------------+--------+-----------------+ Each organization assigned a TLA ID receives 24 bits of NLA ID space. This NLA ID space allows each organization to provide service to approximately as many organizations as the current IPv4 Internet can support total networks. Organizations assigned TLA ID's may also support NLA ID's in their own Site ID space. This allows the organization assigned a TLA ID to provide service to organizations providing public transit service and to organizations who do not provide public transit service. These organizations receiving an NLA ID may also choose to use their Site ID space to support other NLA ID's. This is shown as follows: draft-ietf-ipngwg-unicast-aggr-03.txt [Page 5] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 | n | 24-n bits | 16 | 64 bits | +-----+--------------------+--------+-----------------+ |NLA1 | Site ID | SLA ID | Interface ID | +-----+--------------------+--------+-----------------+ | m | 24-n-m | 16 | 64 bits | +-----+--------------+--------+-----------------+ |NLA2 | Site ID | SLA ID | Interface ID | +-----+--------------+--------+-----------------+ | o |24-n-m-o| 16 | 64 bits | +-----+--------+--------+-----------------+ |NLA3 | Site ID| SLA ID | Interface ID | +-----+--------+--------+-----------------+ The design of the bit layout of the NLA ID space for a specific TLA ID is left to the organization responsible for that TLA ID. Likewise the design of the bit layout of the next level NLA ID is the responsibility of the previous level NLA ID. It is recommended that organizations assigning NLA address space use "slow start" allocation procedures similar to [RFC2050]. 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. 3.5 Site-Level Aggregation Identifier The SLA ID field is used by an individual organization to create its own local addressing hierarchy and to identify subnets. This is analogous to subnets in IPv4 except that each organization has a much greater number of subnets. The 16 bit SLA ID field support 65,535 individual subnets. Organizations may choose to either route their SLA ID "flat" (e.g., not create any logical relationship between the SLA identifiers that results in larger routing tables), or to create a two or more level hierarchy (that results in smaller routing tables) in the SLA ID field. The latter is shown as follows: draft-ietf-ipngwg-unicast-aggr-03.txt [Page 6] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 | n | 16-n | 64 bits | +-----+------------+-------------------------------------+ |SLA1 | Subnet | Interface ID | +-----+------------+-------------------------------------+ | m |16-n-m | 64 bits | +----+-------+-------------------------------------+ |SLA2|Subnet | Interface ID | +----+-------+-------------------------------------+ The approach chosen for structuring an SLA ID field is the responsibility of the individual organization. The number of subnets supported in this address format should 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. 3.6 Interface ID Interface identifiers are used to identify interfaces on a link. They are required to be unique on that link. They may also be unique over a broader scope. In many cases an interfaces identifier will be the same or be based on the interface's link-layer address. Interface IDs used in the aggregatable global unicast address format are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI-64]. These identifiers may have global scope when a global token (e.g., IEEE 48bit MAC) is available or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE EUI-64 terminology) in the EUI-64 identifier must be set correctly, as defined in [ARCH], to indicate global or local scope. The procedures for creating EUI-64 based Interface Identifiers is defined in [ARCH]. The details on forming interface identifiers is defined in the appropriate "IPv6 over " specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 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. These are described in the following paragraphs. The size of the Top-Level Aggregation Identifier is 13 bits. This draft-ietf-ipngwg-unicast-aggr-03.txt [Page 7] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 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. 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 47,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. 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. draft-ietf-ipngwg-unicast-aggr-03.txt [Page 8] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 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. 5.0 Acknowledgments The authors would like to express our thanks to Thomas Narten, Bob Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg for their review and constructive comments. draft-ietf-ipngwg-unicast-aggr-03.txt [Page 9] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 6.0 References [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", RFC1881, December 1995. [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", Internet Draft, , July 1997. [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 1995. [AUTO] Thompson, S., T. Narten., "IPv6 Stateless Address Autoconfiguration", RFC1971, August 1996. [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", Internet Draft, , March 1997. [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", Internet Draft, , March 1997. [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC1883, December 1995. [RFC2050] Hubbard, K., M. Kosters, D. Conrad, D. Karrenberg, J. Postel, "Internet Registry IP Allocation Guidelines", RFC1466, BCP12, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP14, March 1997. 7.0 Security Considerations IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH]. draft-ietf-ipngwg-unicast-aggr-03.txt [Page 10] INTERNET-DRAFT Aggregatable Global Unicast Address Format January 1998 8.0 Authors' Addresses Robert M. Hinden phone: 1 408 990-2004 Nokia . email: hinden@ipsilon.com 232 Java Drive Sunnyvale, CA 94089 USA Mike O'Dell phone: 1 703 206-5890 UUNET Technologies, Inc. email: mo@uunet.uu.net 3060 Williams Drive Fairfax, VA 22030 USA Stephen E. Deering phone: 1 408 527-8213 Cisco Systems, Inc. email: deering@cisco.com 170 West Tasman Drive San Jose, CA 95134-1706 USA draft-ietf-ipngwg-unicast-aggr-03.txt [Page 11]