summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2374.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2374.txt')
-rw-r--r--doc/rfc/rfc2374.txt675
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]
+