rfc1887.txt

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

   group). The widget provider would need to maintain routes to the
   routing domains associated with the various member organizations.
   Similarly, all members of the widget group would need to maintain a
   table of routes to the other members via the widget provider.
   However, since the widget provider does not inform other general
   worldwide TRDs of what addresses it can reach (since the provider is
   not intended for use by other outside organizations), the relatively
   large set of routing prefixes needs to be maintained only in a
   limited number of places. The addresses assigned to the various
   organizations which are members of the widget group would provide a
   `default route' via each members other attachments to TRDs, while
   allowing communications within the widget group to use the preferred
   path.


4.4.4 Solution 4


   A fourth solution involves assignment of a particular address prefix
   for routing domains which are attached to precisely two (or more)
   specific routing domains. For example, suppose that there are two
   providers `SouthNorthNet' and `NorthSouthNet' which have a very large
   number of customers in common (i.e., there are a large number of
   routing domains which are attached to both). Rather than getting two
   address prefixes these organizations could obtain three prefixes.
   Those routing domains which are attached to NorthSouthNet but not
   attached to SouthNorthNet obtain an address assignment based on one
   of the prefixes. Those routing domains which are attached to
   SouthNorthNet but not to NorthSouthNet would obtain an address based
   on the second prefix. Finally, those routing domains which are
   multi-homed to both of these networks would obtain an address based
   on the third prefix.  Each of these two TRDs would then advertise two
   prefixes to other TRDs, one prefix for leaf routing domains attached
   to it only, and one prefix for leaf routing domains attached to both.

   This fourth solution is likely to be important when use of public
   data networks becomes more common. In particular, it is likely that
   at some point in the future a substantial percentage of all routing
   domains will be attached to public data networks. In this case,
   nearly all government-sponsored networks (such as some current
   regionals) may have a set of customers which overlaps substantially
   with the public networks.






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


4.4.5 Summary


   There are therefore a number of possible solutions to the problem of
   assigning IPv6 addresses to multi-homed routing domains. Each of
   these solutions has very different advantages and disadvantages.
   Each solution places a different real (i.e., financial) cost on the
   multi-homed organizations, and on the TRDs (including those to which
   the multi-homed organizations are not attached).

   In addition, most of the solutions described also highlight the need
   for each TRD to develop a policy on whether and under what conditions
   to accept addresses that are not based on its own address prefix, and
   how such non-local addresses will be treated. For example, a somewhat
   conservative policy might be that non-local IPv6 address prefixes
   will be accepted from any attached leaf routing domain, but not
   advertised to other TRDs.  In a less conservative policy, a TRD might
   accept such non-local prefixes and agree to exchange them with a
   defined set of other TRDs (this set could be an a priori group of
   TRDs that have something in common such as geographical location, or
   the result of an agreement specific to the requesting leaf routing
   domain). Various policies involve real costs to TRDs, which may be
   reflected in those policies.


4.5   Private Links


   The discussion up to this point concentrates on the relationship
   between IPv6 addresses and routing between various routing domains
   over transit routing domains, where each transit routing domain
   interconnects a large number of routing domains and offers a more-
   or-less public service.

   However, there may also exist a number of links which interconnect
   two routing domains in such a way, that usage of these links may be
   limited to carrying traffic only between the two routing domains.
   We'll refer to such links as "private".

   For example, let's suppose that the XYZ corporation does a lot of
   business with MBII. In this case, XYZ and MBII may contract with a
   carrier to provide a private link between the two corporations, where
   this link may only be used for packets whose source is within one of
   the two corporations, and whose destination is within the other of
   the two corporations. Finally, suppose that the point-to-point link
   is connected between a single router (router X) within XYZ
   corporation and a single router (router M) within MBII. It is
   therefore necessary to configure router X to know which addresses can



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


   be reached over this link (specifically, all addresses reachable in
   MBII). Similarly, it is necessary to configure router M to know which
   addresses can be reached over this link (specifically, all addresses
   reachable in XYZ Corporation).

   The important observation to be made here is that the additional
   connectivity due to such private links may be ignored for the purpose
   of IPv6 address allocation, and do not pose a problem for routing on
   a larger scale. This is because the routing information associated
   with such connectivity is not propagated throughout the internet, and
   therefore does not need to be collapsed into a TRD's prefix.

   In our example, let's suppose that the XYZ corporation has a single
   connection to a regional, and has therefore uses the IPv6 address
   space from the space given to that regional.  Similarly, let's
   suppose that MBII, as an international corporation with connections
   to six different providers, has chosen the second solution from
   Section 4.4, and therefore has obtained six different address
   allocations. In this case, all addresses reachable in the XYZ
   Corporation can be described by a single address prefix (implying
   that router M only needs to be configured with a single address
   prefix to represent the addresses reachable over this link). All
   addresses reachable in MBII can be described by six address prefixes
   (implying that router X needs to be configured with six address
   prefixes to represent the addresses reachable over the link).

   In some cases, such private links may be permitted to forward traffic
   for a small number of other routing domains, such as closely
   affiliated organizations. This will increase the configuration
   requirements slightly. However, provided that the number of
   organizations using the link is relatively small, then this still
   does not represent a significant problem.

   Note that the relationship between routing and IPv6 addressing
   described in other sections of this paper is concerned with problems
   in scaling caused by large, essentially public transit routing
   domains which interconnect a large number of routing domains.
   However, for the purpose of IPv6 address allocation, private links
   which interconnect only a small number of private routing domains do
   not pose a problem, and may be ignored. For example, this implies
   that a single leaf routing domain which has a single connection to a
   `public' provider (e.g., the Alternet), plus a number of private
   links to other leaf routing domains, can be treated as if it were
   single-homed to the provider for the purpose of IPv6 address
   allocation.  We expect that this is also another way of dealing with
   multi-homed domains.





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


4.6   Zero-Homed Routing Domains


   Currently, a very large number of organizations have internal
   communications networks which are not connected to any service
   providers.  Such organizations may, however, have a number of private
   links that they use for communications with other organizations. Such
   organizations do not participate in global routing, but are satisfied
   with reachability to those organizations with which they have
   established private links. These are referred to as zero-homed
   routing domains.

   Zero-homed routing domains can be considered as the degenerate case
   of routing domains with private links, as discussed in the previous
   section, and do not pose a problem for inter-domain routing. As
   above, the routing information exchanged across the private links
   sees very limited distribution, usually only to the routing domain at
   the other end of the link. Thus, there are no address abstraction
   requirements beyond those inherent in the address prefixes exchanged
   across the private link.

   However, it is important that zero-homed routing domains use valid
   globally unique IPv6 addresses. Suppose that the zero-homed routing
   domain is connected through a private link to a routing domain.
   Further, this routing domain participates in an internet that
   subscribes to the global IPv6 addressing plan. This domain must be
   able to distinguish between the zero-homed routing domain's IPv6
   addresses and any other IPv6 addresses that it may need to route to.
   The only way this can be guaranteed is if the zero-homed routing
   domain uses globally unique IPv6 addresses.

   Whereas globally unique addresses are necessary to differentiate
   between destinations in the Internet, globally unique addresses may
   not be sufficient to guarantee global connectivity.  If a zero-homed
   routing domain gets connected to the Internet, the block of addresses
   used within the domain may not be related to the block of addresses
   allocated to the domain's direct provider. In order to maintain the
   gains given by hierarchical routing and address assignment the zero-
   homed domain should under such circumstances change addresses
   assigned to the systems within the domain.



4.7   Continental aggregation


   Another level of hierarchy may also be used in this addressing scheme
   to further reduce the amount of routing information necessary for



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


   global routing.  Continental aggregation is useful because
   continental boundaries provide natural barriers to topological
   connection and administrative boundaries.  Thus, it presents a
   natural boundary for another level of aggregation of inter-domain
   routing information.  To make use of this, it is necessary that each
   continent be assigned an appropriate contiguous block of addresses.
   Providers (both direct and indirect) within that continent would
   allocate their addresses from this space.  Note that there are
   numerous exceptions to this, in which a service provider (either
   direct or indirect) spans a continental division.  These exceptions
   can be handled similarly to multi-homed routing domains, as discussed
   above.

   The benefit of continental aggregation is that it helps to absorb the
   entropy introduced within continental routing caused by the cases
   where an organization must use an address prefix which must be
   advertised beyond its direct provider.  In such cases, if the address
   is taken from the continental prefix, the additional cost of the
   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