summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2073.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2073.txt')
-rw-r--r--doc/rfc/rfc2073.txt395
1 files changed, 395 insertions, 0 deletions
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]
+