rfc1887.txt

RFC 的详细文档！

   route is not propagated past the point where continental aggregation
   takes place.

   Note that, in contrast to the case of providers, the aggregation of
   continental routing information may not be done on the continent to
   which the prefix is allocated.  The cost of inter-continental links
   (and especially trans-oceanic links) is very high.  If aggregation is
   performed on the `near' side of the link, then routing information
   about unreachable destinations within that continent can only reside
   on that continent.  Alternatively, if continental aggregation is done
   on the `far' side of an inter-continental link, the `far' end can
   perform the aggregation and inject it into continental routing.  This
   means that destinations which are part of the continental
   aggregation, but for which there is not a corresponding more specific
   prefix can be rejected before leaving the continent on which they
   originated.

   For example, suppose that Europe is assigned a prefix of 46/8, such
   that European routing also contains the longer prefixes 46DC:0A01/32
   and 46DC:0A02/32 .  All of the longer European prefixes may be
   advertised across a trans-Atlantic link to North America.  The router
   in North America would then aggregate these routes, and only
   advertise the prefix 46/8 into North American routing.  Packets which
   are destined for 46DC:0A01:1234:5678:ABCD:8765:4321:AABB would
   traverse North American routing, but would encounter the North
   American router which performed the European aggregation.  If the
   prefix 46DC:0A01/32 is unreachable, the router would drop the packet
   and send an unreachable message without using the trans-Atlantic
   link.




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


4.8   Private (Local Use) Addresses


   Many domains will have hosts which, for one reason or another, will
   not require globally unique IPv6 addresses.  A domain which decides
   to use IPv6 addresses out of the private address space is able to do
   so without address allocation from any authority.  Conversely, the
   private address prefix need not be advertised throughout the public
   portion of the Internet.

   In order to use private address space, a domain needs to determine
   which hosts do not need to have network layer connectivity outside
   the domain in the foreseeable future.  Such hosts will be called
   private hosts, and may use the private addresses described above if
   it is topologically convenient.  Private hosts can communicate with
   all other hosts inside the domain, both public and private.  However,
   they cannot have IPv6 connectivity to any external host.  While not
   having external network layer connectivity, a private host can still
   have access to external services via application layer relays.
   Public hosts do not have connectivity to private hosts outside of
   their own domain.

   Because private addresses have no global meaning, reachability
   information associated with the private address space shall not be
   propagated on inter-domain links, and packets with private source or
   destination addresses should not be forwarded across such links.
   Routers in domains not using private address space, especially those
   of Internet service providers, are expected to be configured to
   reject (filter out) routing information that carries reachability
   information associated with private addresses.  If such a router
   receives such information the rejection shall not be treated as a
   routing protocol error.

   In addition, indirect references to private addresses should be
   contained within the enterprise that uses these addresses. Prominent
   example of such references are DNS Resource Records.  A possible
   approach to avoid leaking of DNS RRs is to run two nameservers, one
   external server authoritative for all globally unique IP addresses of
   the enterprise and one internal nameserver authoritative for all IP
   addresses of the enterprise, both public and private.  In order to
   ensure consistency both these servers should be configured from the
   same data of which the external nameserver only receives a filtered
   version.  The resolvers on all internal hosts, both public and
   private, query only the internal nameserver.  The external server
   resolves queries from resolvers outside the enterprise and is linked
   into the global DNS.  The internal server forwards all queries for
   information outside the enterprise to the external nameserver, so all
   internal hosts can access the global DNS.  This ensures that



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


   information about private hosts does not reach resolvers and
   nameservers outside the enterprise.


4.9   Interaction with Policy Routing


   We assume that any inter-domain routing protocol will have difficulty
   trying to aggregate multiple destinations with dissimilar policies.
   At the same time, the ability to aggregate routing information while
   not violating routing policies is essential. Therefore, we suggest
   that address allocation authorities attempt to allocate addresses so
   that aggregates of destinations with similar policies can be easily
   formed.


5.   Recommendations


   We anticipate that the current exponential growth of the Internet
   will continue or accelerate for the foreseeable future. In addition,
   we anticipate a rapid internationalization of the Internet. The
   ability of routing to scale is dependent upon the use of data
   abstraction based on hierarchical IPv6 addresses.  It is therefore
   essential to choose a hierarchical structure for IPv6 addresses with
   great care.

   Great attention must be paid to the definition of addressing
   structures to balance the conflicting goals of:

     - Route optimality

     - Routing algorithm efficiency

     - Ease and administrative efficiency of address registration

     - Considerations for what addresses are assigned by what addressing
        authority

   It is in the best interests of the internetworking community that the
   cost of operations be kept to a minimum where possible. In the case
   of IPv6 address allocation, this again means that routing data
   abstraction must be encouraged.

   In order for data abstraction to be possible, the assignment of IPv6
   addresses must be accomplished in a manner which is consistent with
   the actual physical topology of the Internet. For example, in those
   cases where organizational and administrative boundaries are not



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


   related to actual network topology, address assignment based on such
   organization boundaries is not recommended.

   The intra-domain routing protocols allow for information abstraction
   to be maintained within a domain.  For zero-homed and single-homed
   routing domains (which are expected to remain zero-homed or single-
   homed), we recommend that the IPv6 addresses assigned within a single
   routing domain use a single address prefix assigned to that domain.
   Specifically, this allows the set of all IPv6 addresses reachable
   within a single domain to be fully described via a single prefix.

   We anticipate that the total number of routing domains existing on a
   worldwide Internet to be great enough that additional levels of
   hierarchical data abstraction beyond the routing domain level will be
   necessary.

   In most cases, network topology will have a close relationship with
   national boundaries. For example, the degree of network connectivity
   will often be greater within a single country than between countries.
   It is therefore appropriate to make specific recommendations based on
   national boundaries, with the understanding that there may be
   specific situations where these general recommendations need to be
   modified.

   Further, from experience with IPv4, we feel that continental
   aggregation is beneficial and should be supported where possible as a
   means of limiting the unwarranted spread of routing exceptions.


5.1   Recommendations for an address allocation plan


   We anticipate that public interconnectivity between private routing
   domains will be provided by a diverse set of TRDs, including (but not
   necessarily limited to):

     - Backbone networks;

     - A number of regional or national networks; and,

     - A number of commercial Public Data Networks.

   These networks will not be interconnected in a strictly hierarchical
   manner (for example, there is expected to be direct connectivity
   between regionals, and all of these types of networks may have direct
   international connections).  These TRDs will be used to interconnect
   a wide variety of routing domains, each of which may comprise a
   single corporation, part of a corporation, a university campus, a



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


   government agency, or other organizational unit.

   In addition, some private corporations may be expected to make use of
   dedicated private TRDs for communication within their own
   corporation.

   We anticipate that the great majority of routing domains will be
   attached to only one of the TRDs. This will permit hierarchical
   address aggregation based on TRD. We therefore strongly recommend
   that addresses be assigned hierarchically, based on address prefixes
   assigned to individual TRDs.

   To support continental aggregation of routes, we recommend that all
   addresses for TRDs which are wholly within a continent be taken from
   the continental prefix.

   For the proposed address allocation scheme, this implies that
   portions of IPv6 address space should be assigned to each TRD
   (explicitly including the backbones and regionals). For those leaf
   routing domains which are connected to a single TRD, they should be
   assigned a prefix value from the address space assigned to that TRD.

   For routing domains which are not attached to any publically
   available TRD, there is not the same urgent need for hierarchical
   address aggregation. We do not, therefore, make any additional
   recommendations for such `isolated' routing domains.  Where such
   domains are connected to other domains by private point-to-point
   links, and where such links are used solely for routing between the
   two domains that they interconnect, again no additional technical
   problems relating to address abbreviation is caused by such a link,
   and no specific additional recommendations are necessary.  We do
   recommend that since such domains may wish to use a private address
   space, that the addressing plan specify a specific prefix for private
   addressing.

   Further, in order to allow aggregation of IPv6 addresses at national
   and continental boundaries into as few prefixes as possible, we
   further recommend that IPv6 addresses allocated to routing domains
   should be assigned based on each routing domain's connectivity to
   national and continental Internet backbones.


5.2   Recommendations for Multi-Homed Routing Domains


   Some routing domains will be attached to multiple TRDs within the
   same country, or to TRDs within multiple different countries. We
   refer to these as `multi-homed' routing domains. Clearly the strict



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


   hierarchical model discussed above does not neatly handle such
   routing domains.

   There are several possible ways that these multi-homed routing
   domains may be handled, as described in Section 4.4.  Each of these
   methods vary with respect to the amount of information that must be
   maintained for inter-domain routing and also with respect to the
   inter-domain routes. In addition, the organization that will bear the
   brunt of this cost varies with the possible solutions. Fo