From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2073.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2073.txt (limited to 'doc/rfc/rfc2073.txt') diff --git a/doc/rfc/rfc2073.txt b/doc/rfc/rfc2073.txt new file mode 100644 index 0000000..c2c538e --- /dev/null +++ b/doc/rfc/rfc2073.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group Y. Rekhter +Request for Comments: 2073 cisco +Category: Standards Track P. Lothberg + STUPI.AB + R. Hinden + Ipsilon Networks + S. Deering + Xerox PARC + J. Postel + ISI + Editors + January 1997 + + + An IPv6 Provider-Based Unicast Address Format + +Status 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 1997 + + +3.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 in + RFC1466 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 1997 + + +3.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 1997 + + +7.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.edu + + + + +Rekhter, et. al. Standards Track [Page 7] + -- cgit v1.2.3