doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc2374.txt b/doc/rfc/rfc2374.txt
new file mode 100644
index 0000000..e3c7f0d
--- /dev/null
+++ b/doc/rfc/rfc2374.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                        R. Hinden
+Request for Comments: 2374                                       Nokia
+Obsoletes: 2073                                              M. O'Dell
+Category: Standards Track                                        UUNET
+                                                            S. Deering
+                                                                 Cisco
+                                                             July 1998
+
+
+           An IPv6 Aggregatable Global 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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.0 Introduction
+
+   This document defines an IPv6 aggregatable global unicast address
+   format for use in the Internet.  The address format defined in this
+   document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
+   Addressing Architecture" [ARCH].  It is designed to facilitate
+   scalable Internet routing.
+
+   This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
+   Address Format".  RFC 2073 will become historic.  The Aggregatable
+   Global Unicast Address Format is an improvement over RFC 2073 in a
+   number of areas.  The major changes include removal of the registry
+   bits because they are not needed for route aggregation, support of
+   EUI-64 based interface identifiers, support of provider and exchange
+   based aggregation, separation of public and site topology, and new
+   aggregation based terminology.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 1]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+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 "subnet".  When this name is used with the term "ID" (for
+   "identifier") after the name (e.g., "subnet ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g.  "subnet prefix") it refers to all of the addressing bits to
+   the left of and including this field.
+
+   IPv6 unicast addresses are designed assuming that the Internet
+   routing system makes forwarding decisions based on a "longest prefix
+   match" algorithm on arbitrary bit boundaries and does not have any
+   knowledge of the internal structure of IPv6 addresses.  The structure
+   in IPv6 addresses is for assignment and allocation.  The only
+   exception to this is the distinction made between unicast and
+   multicast addresses.
+
+   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 001 (binary) Format
+   Prefix for Aggregatable Global 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 "001"
+   Format Prefix is defined here.
+
+3.0 IPv6 Aggregatable Global Unicast Address Format
+
+   This document defines an address format for the IPv6 aggregatable
+   global unicast address assignment.  The authors believe that this
+   address format will be widely used for IPv6 nodes connected to the
+   Internet.  This address format is designed to support both the
+   current provider-based aggregation and a new type of exchange-based
+   aggregation.  The combination will allow efficient routing
+   aggregation for sites that connect directly to providers and for
+   sites that connect to exchanges.  Sites will have the choice to
+   connect to either type of aggregation entity.
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 2]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   While this address format is designed to support exchange-based
+   aggregation (in addition to current provider-based aggregation) it is
+   not dependent on exchanges for it's overall route aggregation
+   properties.  It will provide efficient route aggregation with only
+   provider-based aggregation.
+
+   Aggregatable addresses are organized into a three level hierarchy:
+
+      - Public Topology
+      - Site Topology
+      - Interface Identifier
+
+   Public topology is the collection of providers and exchanges who
+   provide public Internet transit services.  Site topology is local to
+   a specific site or organization which does not provide public transit
+   service to nodes outside of the site.  Interface identifiers identify
+   interfaces on links.
+
+        ______________                  ______________
+    --+/              \+--------------+/              \+----------
+      (       P1       )    +----+    (       P3       )  +----+
+      +\______________/     |    |----+\______________/+--|    |--
+      |                  +--| X1 |                       +| X2 |
+      | ______________  /   |    |-+    ______________  / |    |--
+      +/              \+    +-+--+  \  /              \+  +----+
+      (       P2       )     / \     +(      P4        )
+    --+\______________/     /   \      \______________/
+           |               /     \           |      |
+           |              /       |          |      |
+           |             /        |          |      |
+          _|_          _/_       _|_        _|_    _|_
+         /   \        /   \     /   \      /   \  /   \
+        ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
+         \___/        \___/     \___/      \___/  \___/
+                                  |          / \
+                                 _|_       _/_  \   ___
+                                /   \     /   \  +-/   \
+                               ( S.D )   ( S.E )  ( S.F )
+                                \___/     \___/    \___/
+
+   As shown in the figure above, the aggregatable address format is
+   designed to support long-haul providers (shown as P1, P2, P3, and
+   P4), exchanges (shown as X1 and X2), multiple levels of providers
+   (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
+   (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
+   Organizations who connect to these exchanges will also subscribe
+   (directly, indirectly via the exchange, etc.) for long-haul service
+   from one or more long-haul providers.  Doing so, they will achieve
+
+
+
+Hinden, et. al.             Standards Track                     [Page 3]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   addressing independence from long-haul transit providers.  They will
+   be able to change long-haul providers without having to renumber
+   their organization.  They can also be multihomed via the exchange to
+   more than one long-haul provider without having to have address
+   prefixes from each long-haul provider.  Note that the mechanisms used
+   for this type of provider selection and portability are not discussed
+   in the document.
+
+3.1 Aggregatable Global Unicast Address Structure
+
+   The aggregatable global unicast address format is as follows:
+
+     | 3|  13 | 8 |   24   |   16   |          64 bits               |
+     +--+-----+---+--------+--------+--------------------------------+
+     |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
+     |  | ID  |   |  ID    |  ID    |                                |
+     +--+-----+---+--------+--------+--------------------------------+
+
+     <--Public Topology--->   Site
+                           <-------->
+                            Topology
+                                     <------Interface Identifier----->
+
+   Where
+
+      FP           Format Prefix (001)
+      TLA ID       Top-Level Aggregation Identifier
+      RES          Reserved for future use
+      NLA ID       Next-Level Aggregation Identifier
+      SLA ID       Site-Level Aggregation Identifier
+      INTERFACE ID Interface Identifier
+
+   The following sections specify each part of the IPv6 Aggregatable
+   Global Unicast address format.
+
+3.2 Top-Level Aggregation ID
+
+   Top-Level Aggregation Identifiers (TLA ID) are the top level in the
+   routing hierarchy.  Default-free routers must have a routing table
+   entry for every active TLA ID and will probably have additional
+   entries providing routing information for the TLA ID in which they
+   are located.  They may have additional entries in order to optimize
+   routing for their specific topology, but the routing topology at all
+   levels must be designed to minimize the number of additional entries
+   fed into the default free routing tables.
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 4]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   This addressing format supports 8,192 (2^13) TLA ID's.  Additional
+   TLA ID's may be added by either growing the TLA field to the right
+   into the reserved field or by using this format for additional format
+   prefixes.
+
+   The issues relating to TLA ID assignment are beyond the scope of this
+   document.  They will be described in a document under preparation.
+
+3.3 Reserved
+
+   The Reserved field is reserved for future use and must be set to
+   zero.
+
+   The Reserved field allows for future growth of the TLA and NLA fields
+   as appropriate.  See section 4.0 for a discussion.
+
+3.4 Next-Level Aggregation Identifier
+
+   Next-Level Aggregation Identifier's are used by organizations
+   assigned a TLA ID to create an addressing hierarchy and to identify
+   sites.  The organization can assign the top part of the NLA ID in a
+   manner to create an addressing hierarchy appropriate to its network.
+   It can use the remainder of the bits in the field to identify sites
+   it wishes to serve.  This is shown as follows:
+
+      |  n  |      24-n bits     |   16   |    64 bits      |
+      +-----+--------------------+--------+-----------------+
+      |NLA1 |      Site ID       | SLA ID | Interface ID    |
+      +-----+--------------------+--------+-----------------+
+
+   Each organization assigned a TLA ID receives 24 bits of NLA ID space.
+   This NLA ID space allows each organization to provide service to
+   approximately as many organizations as the current IPv4 Internet can
+   support total networks.
+
+   Organizations assigned TLA ID's may also support NLA ID's in their
+   own Site ID space.  This allows the organization assigned a TLA ID to
+   provide service to organizations providing public transit service and
+   to organizations who do not provide public transit service.  These
+   organizations receiving an NLA ID may also choose to use their Site
+   ID space to support other NLA ID's.  This is shown as follows:
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 5]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   |  n  |      24-n bits     |   16   |    64 bits      |
+   +-----+--------------------+--------+-----------------+
+   |NLA1 |      Site ID       | SLA ID | Interface ID    |
+   +-----+--------------------+--------+-----------------+
+
+         |  m  |    24-n-m    |   16   |    64 bits      |
+         +-----+--------------+--------+-----------------+
+         |NLA2 |   Site ID    | SLA ID | Interface ID    |
+         +-----+--------------+--------+-----------------+
+
+               |  o  |24-n-m-o|   16   |    64 bits      |
+               +-----+--------+--------+-----------------+
+               |NLA3 | Site ID| SLA ID | Interface ID    |
+               +-----+--------+--------+-----------------+
+
+   The design of the bit layout of the NLA ID space for a specific TLA
+   ID is left to the organization responsible for that TLA ID.  Likewise
+   the design of the bit layout of the next level NLA ID is the
+   responsibility of the previous level NLA ID.  It is recommended that
+   organizations assigning NLA address space use "slow start" allocation
+   procedures similar to [RFC2050].
+
+   The design of an NLA ID allocation plan is a tradeoff between routing
+   aggregation efficiency and flexibility.  Creating hierarchies allows
+   for greater amount of aggregation and results in smaller routing
+   tables.  Flat NLA ID assignment provides for easier allocation and
+   attachment flexibility, but results in larger routing tables.
+
+3.5 Site-Level Aggregation Identifier
+
+   The SLA ID field is used by an individual organization to create its
+   own local addressing hierarchy and to identify subnets.  This is
+   analogous to subnets in IPv4 except that each organization has a much
+   greater number of subnets.  The 16 bit SLA ID field support 65,535
+   individual subnets.
+
+   Organizations may choose to either route their SLA ID "flat" (e.g.,
+   not create any logical relationship between the SLA identifiers that
+   results in larger routing tables), or to create a two or more level
+   hierarchy (that results in smaller routing tables) in the SLA ID
+   field.  The latter is shown as follows:
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 6]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   |  n  |   16-n     |              64 bits                |
+   +-----+------------+-------------------------------------+
+   |SLA1 |   Subnet   |            Interface ID             |
+   +-----+------------+-------------------------------------+
+
+         | m  |16-n-m |              64 bits                |
+         +----+-------+-------------------------------------+
+         |SLA2|Subnet |            Interface ID             |
+         +----+-------+-------------------------------------+
+
+   The approach chosen for structuring an SLA ID field is the
+   responsibility of the individual organization.
+
+   The number of subnets supported in this address format should be
+   sufficient for all but the largest of organizations.  Organizations
+   which need additional subnets can arrange with the organization they
+   are obtaining Internet service from to obtain additional site
+   identifiers and use this to create additional subnets.
+
+3.6 Interface ID
+
+   Interface identifiers are used to identify interfaces on a link.
+   They are required to be unique on that link.  They may also be unique
+   over a broader scope.  In many cases an interfaces identifier will be
+   the same or be based on the interface's link-layer address.
+   Interface IDs used in the aggregatable global unicast address format
+   are required to be 64 bits long and to be constructed in IEEE EUI-64
+   format [EUI-64].  These identifiers may have global scope when a
+   global token (e.g., IEEE 48bit MAC) is available or may have local
+   scope where a global token is not available (e.g., serial links,
+   tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
+   EUI-64 terminology) in the EUI-64 identifier must be set correctly,
+   as defined in [ARCH], to indicate global or local scope.
+
+   The procedures for creating EUI-64 based Interface Identifiers is
+   defined in [ARCH].  The details on forming interface identifiers is
+   defined in the appropriate "IPv6 over <link>" specification such as
+   "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
+
+4.0 Technical Motivation
+
+   The design choices for the size of the fields in the aggregatable
+   address format were based on the need to meet a number of technical
+   requirements.  These are described in the following paragraphs.
+
+   The size of the Top-Level Aggregation Identifier is 13 bits.  This
+   allows for 8,192 TLA ID's.  This size was chosen to insure that the
+   default-free routing table in top level routers in the Internet is
+
+
+
+Hinden, et. al.             Standards Track                     [Page 7]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   kept within the limits, with a reasonable margin, of the current
+   routing technology.  The margin is important because default-free
+   routers will also carry a significant number of longer (i.e., more-
+   specific) prefixes for optimizing paths internal to a TLA and between
+   TLAs.
+
+   The important issue is not only the size of the default-free routing
+   table, but the complexity of the topology that determines the number
+   of copies of the default-free routes that a router must examine while
+   computing a forwarding table.  Current practice with IPv4 it is
+   common to see a prefix announced fifteen times via different paths.
+
+   The complexity of Internet topology is very likely to increase in the
+   future.  It is important that IPv6 default-free routing support
+   additional complexity as well as a considerably larger internet.
+
+   It should be noted for comparison that at the time of this writing
+   (spring, 1998) the IPv4 default-free routing table contains
+   approximately 50,000 prefixes.  While this shows that it is possible
+   to support more routes than 8,192 it is matter of debate if the
+   number of prefixes supported today in IPv4 is already too high for
+   current routing technology.  There are serious issues of route
+   stability as well as cases of providers not supporting all top level
+   prefixes.  The technical requirement was to pick a TLA ID size that
+   was below, with a reasonable margin, what was being done with IPv4.
+
+   The choice of 13 bits for the TLA field was an engineering
+   compromise.  Fewer bits would have been too small by not supporting
+   enough top level organizations.  More bits would have exceeded what
+   can be reasonably accommodated, with a reasonable margin, with
+   current routing technology in order to deal with the issues described
+   in the previous paragraphs.
+
+   If in the future, routing technology improves to support a larger
+   number of top level routes in the default-free routing tables there
+   are two choices on how to increase the number TLA identifiers.  The
+   first is to expand the TLA ID field into the reserved field.  This
+   would increase the number of TLA ID's to approximately 2 million.
+   The second approach is to allocate another format prefix (FP) for use
+   with this address format.  Either or a combination of these
+   approaches allows the number of TLA ID's to increase significantly.
+
+   The size of the Reserved field is 8 bits.  This size was chosen to
+   allow significant growth of either the TLA ID and/or the NLA ID
+   fields.
+
+   The size of the Next-Level Aggregation Identifier field is 24 bits.
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 8]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   This allows for approximately sixteen million NLA ID's if used in a
+   flat manner.  Used hierarchically it allows for a complexity roughly
+   equivalent to the IPv4 address space (assuming an average network
+   size of 254 interfaces).  If in the future additional room for
+   complexity is needed in the NLA ID, this may be accommodated by
+   extending the NLA ID into the Reserved field.
+
+   The size of the Site-Level Aggregation Identifier field is 16 bits.
+   This supports 65,535 individual subnets per site.  The design goal
+   for the size of this field was to be sufficient for all but the
+   largest of organizations.  Organizations which need additional
+   subnets can arrange with the organization they are obtaining Internet
+   service from to obtain additional site identifiers and use this to
+   create additional subnets.
+
+   The Site-Level Aggregation Identifier field was given a fixed size in
+   order to force the length of all prefixes identifying a particular
+   site to be the same length (i.e., 48 bits).  This facilitates
+   movement of sites in the topology (e.g., changing service providers
+   and multi-homing to multiple service providers).
+
+   The Interface ID Interface Identifier field is 64 bits.  This size
+   was chosen to meet the requirement specified in [ARCH] to support
+   EUI-64 based Interface Identifiers.
+
+5.0 Acknowledgments
+
+   The authors would like to express our thanks to Thomas Narten, Bob
+   Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
+   Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
+   for their review and constructive comments.
+
+6.0 References
+
+   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
+             RFC 1881, December 1995.
+
+   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
+             RFC 2373, July 1998.
+
+   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
+             1995.
+
+   [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
+             Autoconfiguration", RFC 1971, August 1996.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", Work in Progress.
+
+
+
+Hinden, et. al.             Standards Track                     [Page 9]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+             Registration Authority",
+             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
+             March 1997.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", Work in Progress.
+
+   [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 1883, December 1995.
+
+   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
+             and J. Postel, "Internet Registry IP Allocation
+             Guidelines", BCP 12, RFC 1466, November 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+7.0 Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.  Authentication of IPv6 packets is defined
+   in [AUTH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 10]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+8.0 Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: 1 408 990-2004
+   EMail: hinden@iprg.nokia.com
+
+
+   Mike O'Dell
+   UUNET Technologies, Inc.
+   3060 Williams Drive
+   Fairfax, VA 22030
+   USA
+
+   Phone: 1 703 206-5890
+   EMail: mo@uunet.uu.net
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: 1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 11]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+9.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 12]
+