Network Working Group Y. Rekhter INTERNET DRAFT T.J. Watson Research Center, IBM Corp. P. Lothberg STUPI.AB Editors January 1994 An IPv6 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. 1 Introduction This document defines an IPv6 global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 address allocation architecture [1], and is intended to facilitate scalable Internet routing. The format defined in this document doesn't preclude the use of other address formats. 2 Overview of the IPv6 Address This section recapitulates essential information from the IPv6 protocol specifications [2] concerning the basic structure of the IPv6 addresses. Expiration Date July 1995 [Page 1] - 2 - The IPv6 protocol [2] defines an IPv6 address as a 16 octets object. The high-order bits of an IPv6 address are used to indicate a particular type of the address. The variable-length prefix field comprising these bits is called the Format Prefix (FP). This document defines an address format for the 010 (binary) Format Prefix. The same address format can be used for other FPs, as long as these FPs identify IPv6 unicast addresses. 3 IPv6 Global Unicast Address Format for Use in the Internet This document defines an address format for the IPv6 unicast address assignment. It is expected that the defined format would be widely used for systems connected (at IP) to the Internet. The address format defined in this document conforms to the architecture for IPv6 address allocation [1]. Specifically, the format is designed to support aggregation of network layer reachability information at multiple levels of routing hierarchy, as described in [1]. For addresses of the format described in this document the address administration is organized into a three level hierarchy -- registry, provider, and subscriber. The address format defined here allows flexible address allocation at each level of the address administration hierarchy in such a way as to support a wide spectrum of demands for address allocation. This document assumes that the Internet routing system doesn't make any assumptions about specific structure and semantics of an IPv6 address, except for the structure and semantics of the Format Prefix part of the address, and the use of the "longest prefix match" algorithm (on arbitrary bit boundaries) for making a forwarding decision. The address format defined in this document is intended to facilitate scalable Internet-wide routing that doesn't impose any constraints on connectivity among the providers, as well as among the providers and subscribers. The address format defined in this document does not preclude the use of other address formats in the Internet. 3.1 Global IPv6 Unicast Addresses Structure For the purpose of address allocation, the address format defined in this document consists of the following parts: Format Prefix, Registry Identifier, Registry-Specific Component, Provider-Specific Expiration Date July 1995 [Page 2] - 3 - Component, and Subscriber-Specific Component. +-------------------------------+ | Format Prefix | +-------------------------------+ | Registry Identifier Component | +-------------------------------+ | Registry-Specific Component | +-------------------------------+ | Provider-Specific Component | +-------------------------------+ | Subscriber-Specific Component | +-------------------------------+ The following sections suggest some of the alternatives in forming each part of the address. The suggestions are only a small number of the technically possible addressing formats and simultaneously demonstrate different alternatives at different levels in the hierarchy. RFC1219 provides useful information for allocating values within individual components. Ultimately it is the joint responsibility of the registry, the provider and the subscriber to agree on their local addressing structure. 3.2 Registry Identifiers Component (Registry ID) With the growth of the Internet and its increasing globalization, much thought has been given to the evolution of the Network Layer address space allocation and assignment process. RFC 1466, "Guidelines for Management of IP Address Space", proposes a plan that defines distributed allocation and assignment of the IPv4 address space. As the Internet transitions to IPv6, the plan for distributed allocation and assignment of the IPv4 address space established in RFC1466 forms a base for the distributed allocation and assignment of the IPv6 address space. The Internet Registry (IR) acts as the principal registry for the Expiration Date July 1995 [Page 3] - 4 - IPv6 address space; however, the IR may allocate blocks of IPv6 addresses and the assignment of those addresses to qualified Regional Registries. The IR will serve as the default registry in cases where no delegated registration authority has been identified. It is expected that the IANA will act as the IR. The Registry Identifier (Registry ID) Component of the IPv6 address format defined in this document is intended to facilitate a broad geographic address allocation and facilitate the operations of the distributed Regional Registries. The Registry ID Component immediately follows the FP part of an IPv6 address. At present there are three Regional Registries: INTERNIC, RIPE NCC, and APNIC. In addition, address allocation could be done directly by the Internet Registry. Corresponding to this division of address allocation, this document defines the following Registry IDs (and associated with them address blocks): - 0xF8 (5 bits long) - multi-regional (IR) - 0xE8 (5 bits long) - RIPE NCC - 0xD0 (5 bits long) - INTERNIC - 0x90 (5 bits long) - APNIC All other values of the Registry ID Component are reserved by the IANA. Use of the Multi-regional Registry ID permits flexibility in address assignments which are outside of the geographical regions already allocated. It is expected that the IR would be responsible for managing address space registration under the Multi-regional Registry ID. It is expected that the IR, and any designated Regional Registries, allocate addresses in conformance with this overall scheme. Where there are qualifying Regional Registries established, primary responsibility for allocation from within that block will be delegated to that registry. A Regional Registry may have more than one block of addresses allocated to it (as a result the Registry would have multiple Registry IDs associated with it). Expiration Date July 1995 [Page 4] - 5 - 3.3 Registry-Specific Component (RSC) This document assumes that within each Regional Registry there will be a relatively large number of providers that would request relatively small blocks of addresses, medium number of providers that would request medium blocks of addresses, and relatively small number of providers that would request relatively large blocks of addresses. To accommodate a potentially wide range of demands for address space allocation by individual providers a registry should allow the RSC to be of variable length. The length of the RSC associated with the address block a registry allocates to a provider determines the size of the address block granted to that provider by the registry. The value of the RSC associated with an address block a registry allocates to a particular provider uniquely identifies this provider within the registry. Since RSC is of variable length, the uniqueness implies that no two RSC values assigned within a given registry should be equal to each other or should exhibit a substring (subset) relationship. We suggest that within a registry the range of RSC length be limited between 1 and 3 octets. Combined with FP and Registry ID, that leaves 12 to 14 octets for the Provider Specific and Subscriber Specific components. We further suggest that at the minimum a registry would allow address allocation with RSC of the following length: RSC Length Fraction of Registry's Address Space (in bits) (per provider) ---------- ------------------------------------ 24 1/(2^24) 16 1/(2^16) 8 1/(2^8) This document assumes that some subscribers may decide to acquire their addresses space directly out of a registry, thus making their addresses independent of the provider(s) they directly attached to. To accommodate such subscribers we suggest within each registry to reserve the portion of the address space that begins with 0xFF for address allocation to subscribers that elect to use provider- independent addressing (as described in Section 3.6). Expiration Date July 1995 [Page 5] - 6 - 3.4 Provider-Specific Component (PSC) This document assumes that within each provider there will be a relatively large number of subscribers that would request relatively small blocks of addresses, medium number of subscribers that would request medium blocks of addresses, relatively small number of subscribers that would request relatively large blocks of addresses and very few subscribers that would require very large block of addresses. To accommodate a potentially wide range of demands for address space allocation by individual subscribers a provider should allow the PSC to be of variable length. The length of the PSC associated with the address block a provider allocates to a subscriber determines the size of the address block granted to that subscriber by the provider. The value of the PSC associated with an address block a provider allocates to a particular subscriber uniquely identifies this subscriber within the provider. Since the PSC is of variable length, the uniqueness implies no two PSC values assigned within a given provider should be equal to each other or should exhibit a substring (subset) relationship. We suggest that within a provider the range of PSC length be limited between 1 and 4 octets. We further suggest that at the minimum a provider would allow address allocation with PSC of the following length: PSC Length Fraction of Provider's Address Space (in bits) (per subscriber) ---------- ------------------------------------ 32 1/(2^32) 24 1/(2^24) 16 1/(2^16) 8 1/(2^8) A (direct) provider may decide to group its subscribers into regions. This grouping may be useful when the (direct) provider is attached to another (indirect) provider at multiple points, as it allows the direct provider to exert a certain degree of control over the coupling between the attachment points and flow of the traffic destined to a particular subscriber (see Section 5.3.1 of [1]). To accommodate such a grouping we suggest that the (direct) provider should allocate some small number of high-order bits (e.g. between 2 and 4 bits) of PSC as a Region Identifier. The purpose of a Region Expiration Date July 1995 [Page 6] - 7 - Identifier is to identify a group of subscribers that are within a close topological proximity to each other (from the provider's point of view), and thus could be reachable through a particular attachment point between the (direct) provider and other (indirect) provider(s). Regardless of whether the Region Identifier is present, we suggest that the total length of the PSC varies from 1 to 4 octets. Combined with FP, Registry ID, and PSC that leaves 8 to 13 octets for the Subscriber Specific Component. 3.5 Subscriber-Specific Component (SSC) This document leaves the organization of SSC up to individual subscribers. However, this document assumes that for all but relatively small subscribers, there will be sufficient number of bits within the SSC to allow address assignment in such a way as to provide hierarchical routing (at least two levels) within a subscriber. Regardless of how other components are organized, this document suggests that for the subscribers that use IPv6 autoconfiguration capabilities the minimum number of octets allocated to the SSC should be 7. This would allow to embed IEEE 802 MAC addresses as the low order 6 octets of an IPv6 address (stored in IEEE 802 canonical bit order). Observe, that if allocation of all the other components follows recommendations presented in this document, the SSC component would have at least 8 octets. 3.6 Provider-independent Address Format This section describes one possible address format for subscribers that elect to use provider-independent addresses. The format of these addresses is similar to the one described in the previous sections, but it doesn't include the PSC. This document assumes that within each registry there will be a medium number of subscribers that would request medium block of provider-independent addresses and relatively small number of subscribers that would request relatively large block of provider- independent addresses. Each registry is expected to reserve an address block that begins with 0xFF (8 bits) for allocation to subscribers that elect provider-independent addresses. Following this is a variable length Subscriber Identifier (S-ID) field. The length of the S-ID field Expiration Date July 1995 [Page 7] - 8 - associated with the address block a registry allocates to a subscriber determines the size of the address block granted to that subscriber by the registry. The value of the S-ID associated with an address block a registry allocates to a particular subscriber uniquely identifies this subscriber within the registry. Since S-ID is of variable length, the uniqueness implies that no two S-ID values assigned within a given registry should be equal to each other or should exhibit a substring (subset) relationship. We suggest that within a registry the range of S-ID length be limited from 12 to 24 bits. We further suggest that at the minimum a registry should allow address allocation with S-ID of the length of 12 and 24 bits. This would leaves from 12 to 13.5 octets for allocation within individual sites (for the SSC). One possible use of provider-independent addresses is for multihomed sites (as described in Section 5.4.1 of [1]). Allocation and use of provider-independent addresses requires careful judgement. It is crucial to understand that use of such addresses for the purpose of Internet-wide connectivity has negative impact on the overall routing system, as the only possible routing information abstraction above the subscriber level could occur at the continental level (see Section 5.7 of [1]). 4 National Registry As a variation of the proposed format, a Regional Registry may allocate blocks of address space to several National Registries. A National Registry then becomes the entity that allocates address space to individual organizations (e.g. providers) within the country served by the Registry. To support address allocation by National Registries this document allows to include the National Registry Id Component as part of the address format (see below). The Component is immediately follows the Registry Identifier Component and precedes the Registry-Specific Component. +-------------------------------+ | Format Prefix | +-------------------------------+ | Registry Identifier Component | +-------------------------------+ | National Registry ID Component| Expiration Date July 1995 [Page 8] - 9 - +-------------------------------+ | Registry-Specific Component | +-------------------------------+ | Provider-Specific Component | +-------------------------------+ | Subscriber-Specific Component | +-------------------------------+ This document assumes that within each regional registry there will be a relatively small number of national registries. However, within each national registry there will be a relatively large number of providers that would request relatively small blocks of addresses, medium number of providers that would request medium blocks of addresses, and relatively small number of providers that would request relatively large blocks of addresses. To accommodate a potentially wide range of demands for address space allocation by individual national registries a regional registry should allow the National Registry ID to be of variable length. The length of the National Registry ID associated with the address block a regional registry allocates to a national registry determines the size of the address block granted to that provider by the registry. The value of the National Registry ID associated with an address block a regional registry allocates to a particular national registry uniquely identifies this national registry. Since the National Registry ID is of variable length, the uniqueness implies that no two National Registry ID values assigned within a given regional registry should be equal to each other or should exhibit a substring (subset) relationship. We suggest that within a regional registry the range of the National Registry ID length be limited between 1 and 2 octets. We further suggest that within a national registry the range of the RSC length be limited between 1 and 2 octets. Combined with FP, Regional Registry ID, and National Registry ID, that leaves 12 to 14 octets for the Provider Specific and Subscriber Specific components. We further suggest that at the minimum a national registry would allow address allocation with RSC of the following length: RSC Length Fraction of Registry's Address Space (in bits) (per provider) ---------- ------------------------------------ 16 1/(2^16) 8 1/(2^8) Expiration Date July 1995 [Page 9] - 10 - 5 Conclusions [TBD] 6 Acknowledgements We would like to express our thanks to Jim Bound (DEC), Brian Carpenter (CERN), Steve Deering (XEROX), Geoff Huston (AANET), and Tony Li (cisco) for their review and constructive comments. 7 References [1] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address Allocation", Internet Draft [2] Hinden, B., "IP Next Generation Addressing Architecture", Internet Draft 8 Security Considerations Security issues are not discussed in this memo. 9 Authors' Addresses Yakov Rekhter T.J. Watson Research Center, IBM Corporation P.O. Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-7361 email: yakov@watson.ibm.com Peter Lothberg STUPI.AB Box 9129 S-102 72 Stockholm Sweden Phone:+46 8 6699720 email:roll@Stupi.SE Expiration Date July 1995 [Page 10]