rfc2450.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

Network Working Group                                      R. Hinden
Request for Comments: 2450                                     Nokia
Category: Informational                                December 1998


                 Proposed TLA and NLA Assignment Rules

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

1.0 Introduction

   This document proposes rules for Top-Level Aggregation Identifiers
   (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined
   in [AGGR].  These proposed rules apply to registries allocating TLA
   ID's and to organizations receiving TLA ID's.

   This proposal is intended as input from the IPng working group to the
   IANA and Registries.  It is not intended for any official IETF
   status.  Its content represents the result of extensive discussion
   between the IPng working group, IANA, and Registries.

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

2.0 Scope

   The proposed TLA and NLA assignment rules described in this document
   are intended for the first two years of IPv6 TLA address assignments.
   As routing technology evolves and we gain additional experience with
   allocating IPv6 addresses the procedures proposed in this document
   may change.











Hinden                       Informational                      [Page 1]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


3.0 IPv6 Aggregatable Global Unicast Address Format

   This document proposes assignment rules for the TLA ID and NLA ID
   fields in the IPv6 Aggregatable Global Unicast Address Format.  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.

   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 its overall route aggregation
   properties.  It will provide efficient route aggregation with only
   provider-based aggregation.

   The aggregatable global unicast address format as defined in [AGGR]
   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

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 that are described in [AGGR].  An extract of the
   technical requirements from [AGGR] is as follows:





Hinden                       Informational                      [Page 2]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


      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 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.  In 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 the current IPv4 default-
      free routing table is 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.






Hinden                       Informational                      [Page 3]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


      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.  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.

   The proposed TLA/NLA assignment rules described in this document are
   consistent with these technical requirements.

   The specific technical motivation for the proposed TLA/NLA assignment
   rules described in this document is as follows:

    - Limit the number of top level prefixes in the Internet to a
      manageable size.  This is important to insure that the default-
      free routing table in the top level routers in the Internet is
      kept within the limits, with a reasonable margin, of current
      routing technology.

    - Only assign top level prefixes to transit providers, not to leaf
      sites even if they are multiply homed.  The aggregation address
      format is designed to have a clear separation between transit
      providers and leaf sites.  Sites which wish to be multihomed to
      multiple transit providers have in IPv6 a number of alternatives
      to having a top level prefix.



Hinden                       Informational                      [Page 4]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


    - Only assign top level prefixes to organizations who are capable
      and intend to provide operational IPv6 transit services within
      three months of assignment.  The goal is to not assign top level
      prefixes to organizations who only want a prefix in case they
      might provide service sometime in the future.  The assignment of
      prefixes is intended to closely match the operational IPv6
      Internet and to be consistent with the current practice of
      registries making assignments when addresses are actually used.

    - Organizations assigned TLA ID's are required to make all the
      assignments publically available.  This is necessary in order for
      the registries to have accurate information on assignments and to
      enable trouble shooting Internet problems.

    - Allocation of prefixes that are consistent with the address format
      in [AGGR].  Specifically the allocation prefixes that are not
      longer than 48 bits as to not infringe into the SLA and Interface
      Identifier fields.  This is to facilitate movement of sites in the
      topology (e.g., changing service providers and multi-homing to
      multiple service providers).

5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's

   TLA ID's are assigned to organizations providing transit topology.
   They are specifically not assigned to organizations only providing
   leaf topology.  TLA ID assignment does not imply ownership.  It does
   imply stewardship over a valuable Internet resource.

   The IAB and IESG have authorized the Internet Assigned Numbers
   Authority (IANA) as the appropriate entity to have the responsibility
   for the management of the IPv6 address space as defined in [ALLOC].

   The IANA will assign small blocks (e.g., few hundred) of TLA ID's to
   registries.  The registries will assign the TLA ID's to organizations
   meeting the requirements for TLA ID assignment.  When the registries
   have assigned all of their TLA ID's they can request that the IANA
   give them another block.  The blocks do not have to be contiguous.
   The IANA may also assign TLA ID's to organizations directly.  This
   includes the temporary TLA assignment for testing and experimental
   usage for activities such as the 6bone or new approaches like
   exchanges.










Hinden                       Informational                      [Page 5]

RFC 2450         Proposed TLA and NLA Assignment Rules     December 1998


5.1 Proposed TLA Allocation Stages

   TLA allocations will be done in two stages.  The first stage is to
   allocate a Sub-TLA ID.  When the recipient has demonstrated that they
   have assigned more than 90% of the NLA ID for their Sub-TLA ID, they
   will be allocated a TLA ID.  The Sub-TLA ID does not have to be
   returned.

   Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows.  Note that
   use of the Reserved field to create the Sub-TLA field is specific to
   TLA ID 0x0001.  It does not affect any other TLA.

      | 3  |    13    |    13   |       19      |
      +----+----------+---------+---------------+
      | FP |   TLA    | Sub-TLA |       NLA     |
      |    |   ID     |         |       ID      |
      +----+----------+---------+---------------+

   where:

    FP = 001 = Format Prefix

       This is the Format Prefix used to identify aggregatable global
       unicast addresses.