rfc2374.txt

bind-3.2.

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]