GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2374

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:
  1. Public Topology
  2. Site Topology
  3. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2374.txt · Last modified: 1998/07/16 19:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki