rfc1887.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

RFC 1887      IPv6 Unicast Address Allocation Architecture December 1995


   occur at each level of the hierarchy (over a given period of time),
   compared to the number of routing domains and address prefixes that
   can conveniently and efficiently be handled via dynamic inter-domain
   routing protocols.


3.1 Efficiency versus Decentralized Control.


   If the Internet plans to support a decentralized address
   administration, then there is a balance that must be sought between
   the requirements on IPv6 addresses for efficient routing and the need
   for decentralized address administration.  A coherent addressing plan
   at any level within the Internet must take the alternatives into
   careful consideration.

   As an example of administrative decentralization, suppose the IPv6
   address prefix 43/8 identifies part of the IPv6 address space
   allocated for North America. All addresses within this prefix may be
   allocated along topological boundaries in support of increased data
   abstraction.  Within this prefix, addresses may be allocated on a
   per-provider bases, based on geography or some other topologically
   significant criteria.  For the purposes of this example, suppose that
   this prefix is allocated on a per-provider basis.  Subscribers within
   North America use parts of the IPv6 address space that is underneath
   the IPv6 address space of their service providers.  Within a routing
   domain addresses for subnetworks and hosts are allocated from the
   unique IPv6 prefix assigned to the domain according to the addressing
   plan for that domain.


4.   IPv6 Address Administration and Routing in the Internet


   Internet routing components -- service providers (e.g., backbones,
   regional networks), and service subscribers (e.g., sites or campuses)
   -- are arranged hierarchically for the most part. A natural mapping
   from these components to IPv6 routing components is for providers and
   subscribers to act as routing domains.

   Alternatively, a subscriber (e.g., a site) may choose to operate as a
   part of a domain formed by a service provider. We assume that some,
   if not most, sites will prefer to operate as part of their provider's
   routing domain, exchanging routing information directly with the
   provider.  The site is still allocated a prefix from the provider's
   address space, and the provider will advertise its own prefix into
   inter-domain routing.




Rekhter & Li                 Informational                      [Page 6]

RFC 1887      IPv6 Unicast Address Allocation Architecture December 1995


   Given such a mapping, where should address administration and
   allocation be performed to satisfy both administrative
   decentralization and data abstraction? The following possibilities
   are considered:

     1) At some part within a routing domain,

     2) At the leaf routing domain,

     3) At the transit routing domain (TRD), and

     4) At some other, more general boundaries, such as at the
        continental boundary.

   A part within a routing domain corresponds to any arbitrary connected
   set of subnetworks. If a domain is composed of multiple subnetworks,
   they are interconnected via routers.  Leaf routing domains correspond
   to sites, where the primary purpose is to provide intra-domain
   routing services.  Transit routing domains are deployed to carry
   transit (i.e., inter-domain) traffic; backbones and providers are
   TRDs.  More general boundaries can be seen as topologically
   significant collections of TRDs.

   The greatest burden in transmitting and operating on reachability
   information is at the top of the routing hierarchy, where
   reachability information tends to accumulate. In the Internet, for
   example, providers must manage reachability information for all
   subscribers directly connected to the provider. Traffic destined for
   other providers is generally routed to the backbones (which act as
   providers as well).  The backbones, however, must be cognizant of the
   reachability information for all attached providers and their
   associated subscribers.

   In general, the advantage of abstracting routing information at a
   given level of the routing hierarchy is greater at the higher levels
   of the hierarchy. There is relatively little direct benefit to the
   administration that performs the abstraction, since it must maintain
   routing information individually on each attached topological routing
   structure.

   For example, suppose that a given site is trying to decide whether to
   obtain an IPv6 address prefix directly from the IPv6 address space
   allocated for North America, or from the IPv6 address space allocated
   to its service provider. If considering only their own self-interest,
   the site itself and the attached provider have little reason to
   choose one approach or the other. The site must use one prefix or
   another; the source of the prefix has little effect on routing
   efficiency within the site. The provider must maintain information



Rekhter & Li                 Informational                      [Page 7]

RFC 1887      IPv6 Unicast Address Allocation Architecture December 1995


   about each attached site in order to route, regardless of any
   commonality in the prefixes of the sites.

   However, there is a difference when the provider distributes routing
   information to other providers (e.g., backbones or TRDs).  In the
   first case, the provider cannot aggregate the site's address into its
   own prefix; the address must be explicitly listed in routing
   exchanges, resulting in an additional burden to other providers which
   must exchange and maintain this information.

   In the second case, each other provider (e.g., backbone or TRD) sees
   a single address prefix for the provider, which encompasses the new
   site. This avoids the exchange of additional routing information to
   identify the new site's address prefix. Thus, the advantages
   primarily accrue to other providers which maintain routing
   information about this site and provider.

   One might apply a supplier/consumer model to this problem: the higher
   level (e.g., a backbone) is a supplier of routing services, while the
   lower level (e.g., a TRD) is the consumer of these services. The
   price charged for services is based upon the cost of providing them.
   The overhead of managing a large table of addresses for routing to an
   attached topological entity contributes to this cost.

   At present the Internet, however, is not a market economy.  Rather,
   efficient operation is based on cooperation.  The recommendations
   discussed below describe simple and tractable ways of managing the
   IPv6 address space that benefit the entire community.


4.1   Administration of IPv6 addresses within a domain.


   If individual hosts take their IPv6 addresses from a myriad of
   unrelated IPv6 address spaces, there will be effectively no data
   abstraction beyond what is built into existing intra-domain routing
   protocols.  For example, assume that within a routing domain uses
   three independent prefixes assigned from three different IPv6 address
   spaces associated with three different attached providers.

   This has a negative effect on inter-domain routing, particularly on
   those other domains which need to maintain routes to this domain.
   There is no common prefix that can be used to represent these IPv6
   addresses and therefore no summarization can take place at the
   routing domain boundary. When addresses are advertised by this
   routing domain to other routing domains, an enumerated list of the
   three individual prefixes must be used.




Rekhter & Li                 Informational                      [Page 8]

RFC 1887      IPv6 Unicast Address Allocation Architecture December 1995


   The number of IPv6 prefixes that leaf routing domains would advertise
   is on the order of the number of prefixes assigned to the domain; the
   number of prefixes a provider's routing domain would advertise is
   approximately the number of prefixes attached to the client leaf
   routing domains; and for a backbone this would be summed across all
   attached providers.  This situation is just barely acceptable in the
   current Internet, and is intractable for the IPv6 Internet.  A
   greater degree of hierarchical information reduction is necessary to
   allow continued growth in the Internet.


4.2   Administration at the Leaf Routing Domain


   As mentioned previously, the greatest degree of data abstraction
   comes at the lowest levels of the hierarchy. Providing each leaf
   routing domain (that is, site) with a contiguous block of addresses
   from its provider's address block results in the biggest single
   increase in abstraction. From outside the leaf routing domain, the
   set of all addresses reachable in the domain can then be represented
   by a single prefix.  Further, all destinations reachable within the
   provider's prefix can be represented by a single prefix.

   For example, consider a single campus which is a leaf routing domain
   which would currently require 4 different IPv6 prefixes.  Instead,
   they may be given a single prefix which provides the same number of
   destination addresses.  Further, since the prefix is a subset of the
   provider's prefix, they impose no additional burden on the higher
   levels of the routing hierarchy.

   There is a close relationship between hosts and routing domains.  The
   routing domain represents the only path between a host and the rest
   of the internetwork. It is reasonable that this relationship also
   extend to include a common IPv6 addressing space. Thus, the hosts
   within the leaf routing domain should take their IPv6 addresses from
   the prefix assigned to the leaf routing domain.


4.3   Administration at the Transit Routing Domain


   Two kinds of transit routing domains are considered, direct providers
   and indirect providers. Most of the subscribers of a direct provider
   are domains that act solely as service subscribers (they carry no
   transit traffic). Most of the subscribers of an indirect provider are
   domains that, themselves, act as service providers. In present
   terminology a backbone is an indirect provider, while an NSFnet
   regional is an example of a direct provider. Each case is discussed



Rekhter & Li                 Informational                      [Page 9]

RFC 1887      IPv6 Unicast Address Allocation Architecture December 1995


   separately below.


4.3.1   Direct Service Providers


   In a provider-based addressing plan, direct service providers should
   use their IPv6 address space for assigning IPv6 addresses from a
   unique prefix to the leaf routing domains that they serve. The
   benefits derived from data abstraction are greater than in the case
   of leaf routing domains, and the additional degree of data
   abstraction provided by this may be necessary in the short term.

   As an illustration consider an example of a direct provider that
   serves 100 clients. If each client takes its addresses from 4
   independent address spaces then the total number of entries that are
   needed to handle routing to these clients is 400 (100 clients times 4
   providers).  If each client takes its addresses from a single address
   space then the total number of entries would be only 100. Finally, if
   all the clients take their addresses from the same address space then
   the total number of entries would be only 1.

   We expect that in the near term the number of routing domains in the
   Internet will grow to the point that it will be infeasible to route
   on the basis of a flat field of routing domains. It will therefore be
   essential to provide a greater degree of information abstraction with
   IPv6.

   Direct providers may give part of their address space (prefixes) to
   leaf domains, based on an address prefix given to the provider.  This
   results in direct providers advertising to other providers a small
   fraction of the number of address prefixes that would be necessary if
   they enumerated the individual prefixes of the leaf routing domains.
   This represents a significant savings given the expected scale of
   global internetworking.

   The efficiencies gained in inter-domain routing clearly warrant the
   adoption of IPv6 address prefixes derived from the IPv6 address space
   of the providers.

   The mechanics of this scenario are straightforward. Each direct
   provider is given a unique small set of IPv6 address prefixes, from
   which its attached leaf routing domains can allocate slightly longer
   IPv6 address prefixes.  For example assume that NIST is a leaf
   routing domain whose inter-domain link is via SURANet. If SURANet is
   assigned an unique IPv6 address prefix 43DC:0A21/32, NIST could use a
   unique IPv6 prefix of 43DC:0A21:7652:34/56.




Rekhter & Li                 Informational                     [Page 10]

RFC 1887      IPv6 Unicast Address Allocation Architecture December 1995