rfc1887.txt

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

   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. For example,
   the solutions vary with respect to:

     - Resources used within routers within the TRDs;

     - Administrative cost on TRD personnel; and,

     - Difficulty of configuration of policy-based inter-domain routing
        information within leaf routing domains.

   Also, the solution used may affect the actual routes which packets
   follow, and may effect the availability of backup routes when the
   primary route fails.

   For these reasons it is not possible to mandate a single solution for
   all situations. Rather, economic considerations will require a
   variety of solutions for different routing domains, service
   providers, and backbones.


6.   Security Considerations


   Security issues are not discussed in this document.


7.   Acknowledgments


   This document is largely based on RFC 1518.  The section on Private
   Addresses borrowed heavily from RFC 1597.

   We'd like to thank Havard Eidnes, Bill Manning, Roger Fajman for
   their review and constructive comments.









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


REFERENCES



   [1]  Deering, S., and R. Hinden, Editors, "Internet Protocol, Version
        6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks,
        December 1995.