doc: Add RFC documents

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]
+