Movatterモバイル変換

Network Working Group                                         Y. RekhterRequest for Comments: 2073                                         ciscoCategory: Standards Track                                    P. Lothberg                                                                STUPI.AB                                                               R. Hinden                                                        Ipsilon Networks                                                              S. Deering                                                              Xerox PARC                                                               J. Postel                                                                     ISI                                                                 Editors                                                            January 1997An IPv6 Provider-Based Unicast Address FormatStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.1.0 Introduction   This document defines an IPv6 provider-based unicast address format   for use in the Internet.  The address format defined in this document   is consistent with the "IPv6 Addressing Architecture" [ARCH] and the   "An Architecture for IPv6 Unicast Address Allocation" [ALLOC], and is   intended to facilitate scalable Internet routing.   The unicast address format defined in this document doesn't preclude   the use of other unicast address formats.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 "subscriber".  When this name is used with the term "ID" (for   "identifier") after the name (e.g., "subscriber ID"), it refers to   the contents of the named field.  When it is used with the term   "prefix" (e.g., "subscriber prefix") it refers to all of the address   up to and including this field.Rekhter, et. al.            Standards Track                     [Page 1]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997   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 010 (binary) Format   Prefix for Provider-Based 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 "010" Format   Prefix is defined here.3.0 IPv6 Provider-Based Unicast Address Format   This document defines an address format for the IPv6 provider-based   unicast address assignment.  It is expected that this address format   will be widely used for IPv6 nodes connected to the Internet.   The address format defined in this document conforms to the   "Architecture for IPv6 Unicast Address Allocation" [ALLOC].   Specifically, the format is designed to support aggregation of   network layer reachability information at multiple levels of routing   hierarchy.   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 the 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 does not impose any constraints   on connectivity among the providers, as well as among the providers   and subscribers.Rekhter, et. al.            Standards Track                     [Page 2]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 19973.1 Provider-Based Unicast Address Structure   For the purpose of address allocation, the address format defined in   this document consists of the following parts:  Format Prefix,   Registry ID, Provider ID, Subscriber ID, and an Intra-Subscriber   part.  The Intra-Subscriber part definition is the responsibility of   the subscriber and is not defined in this document.  The provider-   based unicast address format is as follows:      | 3 |  5 bits  |   n bits   |   56-n bits  |        64 bits     |      +---+----------+------------+--------------+--------------------+      |010|RegistryID| ProviderID | SubscriberID |  Intra-Subscriber  |      +---+----------+------------+--------------+--------------------+   The following sections specify each part of the IPv6 Provider-Based   Unicast address format.  In general other allocation strategies are   possible within this framework, but the ones described in this   document will be used to assign IPv6 provider-based addresses.   3.2 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 inRFC1466 forms a base for the distributed allocation and assignment of   the IPv6 address space.   The Internet Assigned Number Authority (IANA) is the principal   registry for the IPv6 address space.  The IANA may allocate blocks of   IPv6 addresses and delegate the assignment of those blocks to   qualified Regional Registries.  The IANA will serve as the default   registry in cases where no delegated registration authority has been   identified.   The Registry ID of the IPv6 provider-based unicast address format is   intended to facilitate a broad geographic address allocation and   facilitate the operations of the distributed Regional Registries.   The Registry ID immediately follows the format prefix part of an IPv6   address.Rekhter, et. al.            Standards Track                     [Page 3]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997   At present there are three Regional Registries: INTERNIC, RIPE NCC,   and APNIC.  In addition, address allocation could be done directly by   the IANA.  Corresponding to this division of address allocation, this   document defines the following Registry IDs:        Regional Registry                     Value (binary)        --------------------                  --------------        Multi-Regional (IANA)                 10000        RIPE NCC                              01000        INTERNIC                              11000        APNIC                                 00100   All other values of the Registry ID 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.  The IANA will be responsible for managing address space   registration under the Multi-Regional Registry ID.   It is expected that the IANA, 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).3.3 Provider ID and Subscriber ID   This document leaves the organization of the Provider ID and   Subscriber ID portions of address up to individual registries.   Particularly the registry needs to define how much address space is   given to providers and their subscribers.  There are several issues   which must be addressed when doing this.  These include:      o There will likely be a mixture of providers of different sizes.      o Small providers will grow to become large providers.      o Large providers will lose customers and become small providers.        In extreme cases, the registry will require them to return some        of their address space to the registry.      o Organizations which need to be multi-homed to more than one        provider will request a Provider ID assignment.   It is important that a registry design its Provider ID space to allow   flexibility and at the same time use the address space efficiently.Rekhter, et. al.            Standards Track                     [Page 4]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 19973.3.1 Provider ID   The value of the Provider ID associated with an address block a   registry allocates to a particular provider uniquely identifies this   provider within the registry.   This document assumes that some subscribers may decide to acquire   their address space directly from a registry, thus making their   addresses independent of the provider(s) they are directly attached.3.3.2 Subscriber ID   The structure and assignment strategy of Subscriber ID's is specified   by each provider.   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 [ALLOC]).   To accommodate such a grouping the (direct) provider may allocate   some small number of high-order bits of the Subscriber ID as a   Subscriber-Region ID.  The purpose of a Subscriber-Region ID 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).3.4 Intra-Subscriber Part   This document leaves the organization of Intra-Subscriber portion of   the address up to individual subscribers.   The provider-based unicast address format described in this document   leaves 64 bits for the local portion of the address.  The editors of   this document recommend that subscribers use IPv6 auto-configuration   capabilities [AUTO] to generate addresses using link-specific   addresses as Interface ID such as 48 bit IEEE-802 MAC addresses.  In   this case 16 bits are left for the Subnet ID.  This should sufficient   (e.g., 65,535 subnets) for all but the largest of subscribers.  This   is shown as follows:      |            64 bits             |  16 bits  |     48 bits      |      +--------------------------------+-----------+------------------+      |       Subscriber Prefix        | Subnet ID |   Interface ID   |      +--------------------------------+-----------+------------------+Rekhter, et. al.            Standards Track                     [Page 5]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 1997   Subscribers who need additional subnets (and who desire to continue   to use 48 bit IEEE-802 MAC addresses for Interface ID's) can be   accommodated by having the provider assign them a block of subscriber   prefixes.  Alternatively, an extremely large subscriber could be   assigned its own Provider ID which would give it additional bits of   address space to create its own local address hierarchy.4.0 National Registries   A Regional Registry may allocate blocks of address space to several   National Registries.  The National Registry then becomes the entity   that allocates address space to individual providers within the   country served by the National Registry.   To create National Registries the Regional Registry may add a layer   of hierarchy in the Provider ID field to create National Registries.   The resulting Provider Prefix is as follows:   | 3 |  5 bits  |  n bits  |  m bits  |   56-n-m   |    64 bits     |   +---+----------+----------+----------+------------+----------------+   |010|RegistryID| National | Provider | Subscriber |Intra-Subscriber|   |   |          |RegistryID|   ID     |     ID     |                |   +---+----------+----------+----------+------------+----------------+   This document assumes that within each regional registry there will   be a relatively small number of national registries.  The size of the   National-Registry ID should be related to the number of countries in   the region administrated by the regional registry and the number of   providers expected to be in each country.5.0 Acknowledgments   The editors would like to express our thanks to Jim Bound (Digital),   Scott Bradner (Harvard), Brian Carpenter (CERN), Geoff Huston   (AANET), and Tony Li (cisco) for their review and constructive   comments.6.0 References   [ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast           Address Allocation",RFC 1887, December 1995.   [ARCH]  Hinden, R., "IP Version 6 Addressing Architecture",RFC 1884, December 1995.   [AUTO]  Thompson, S., "IPv6 Stateless Address Autoconfiguration",RFC 1972, August 1996.Rekhter, et. al.            Standards Track                     [Page 6]

RFC 2073       IPv6 Provider-Based Unicast Address Format   January 19977.0 Security Considerations   Security issues are not discussed in this memo.8.0 Editors' Addresses   Yakov Rekhter   Cisco Systems, Inc.   170 West Tasman Drive   San Jose, CA 95134-1706   USA   Phone:  +1 914 528-0090   EMail:  yakov@cisco.com   Peter Lothberg   STUPI.AB   Box 9129   S-102 72 Stockholm   Sweden   Phone:+46 8 6699720   EMail: roll@Stupi.SE   Robert M. Hinden   Ipsilon Networks, Inc.   2191 E. Bayshore Road   Palo Alto, CA 94303   USA   Phone: +1 415 846 4604   EMail: hinden@ipsilon.com   Stephen E. Deering   Xerox Palo Alto Research Center   3333 Coyote Hill Road   Palo Alto, CA 94304   USA   Phone: +1 415 812 4839   Fax:   +1 415 812 4471   EMail: deering@parc.xerox.com   Jon Postel   Information Sciences Institute   4676 Admiralty Way   Marina del Rey, CA 90292-6695   USA   Phone: +1 310 822 1511   Fax:   +1 310 823 6714   EMail: postel@isi.eduRekhter, et. al.            Standards Track                     [Page 7]