rfc1887.txt

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

   If a direct service provider is connected to another provider(s)
   (either direct or indirect) via multiple attachment points, then in
   certain cases it may be advantageous to the direct provider to exert
   a certain degree of control over the coupling between the attachment
   points and flow of the traffic destined to a particular subscriber.
   Such control can be facilitated by first partitioning all the
   subscribers into groups, such that traffic destined to all the
   subscribers within a group should flow through a particular
   attachment point. Once the partitioning is done, the address space of
   the provider is subdivided along the group boundaries. A leaf routing
   domain that is willing to accept prefixes derived from its direct
   provider gets a prefix from the provider's address space subdivision
   associated with the group the domain belongs to.

   At the attachment point (between the direct and indirect providers)
   the direct provider advertises both an address prefix that
   corresponds to the address space of the provider, and one or more
   address prefixes that correspond to the address space associated with
   each subdivision.  The latter prefixes match the former prefix, but
   are longer than the former prefix. Use of the "longest match"
   forwarding algorithm by the recipients of these prefixes (e.g., a
   router within the indirect provider) results in forcing the flow of
   the traffic to destinations depicted by the longer address prefixes
   through the attachment point where these prefixes are advertised to
   the indirect provider.

   For example, assume that SURANet is connected to another regional
   provider, NEARNet, at two attachment points, A1 and A2. SURANet is
   assigned a unique IPv6 address prefix 43DC:0A21/32. To exert control
   over the traffic flow destined to a particular subscriber within
   SURANet, SURANet may subdivide the address space assigned to it into
   two groups, 43DC:0A21:8/34 and 43DC:0A21:C/34. The former group may
   be used for sites attached to SURANet that are closer (as determined
   by the topology within SURANet) to A1, while the latter group may be
   used for sites that are closer to A2.  The SURANet router at A1
   advertises both 43DC:0A21/32 and 43DC:0A21:8/34 address prefixes to
   the router in NEARNet. Likewise, the SURANet router at A2 advertises
   both 43DC:0A21/32 and 43DC:0A21:C/34 address prefixes to the router
   in NEARNet. Traffic that flows through NEARNet to destinations that
   match 43DC:0A21:8/34 address prefix would enter SURANet at A1, while
   traffic to destinations that match 43DC:0A21:C/34 address prefix
   would enter SURANet at A2.

   Note that the advertisement by the direct provider of the routing
   information associated with each subdivision must be done with care
   to ensure that such an advertisement would not result in a global
   distribution of separate reachability information associated with
   each subdivision, unless such distribution is warranted for some



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


   other purposes (e.g., supporting certain aspects of policy-based
   routing).


4.3.2   Indirect Providers (Backbones)


   There does not at present appear to be a strong case for direct
   providers to take their address spaces from the the IPv6 space of an
   indirect provider (e.g., backbone). The benefit in routing data
   abstraction is relatively small. The number of direct providers today
   is in the tens and an order of magnitude increase would not cause an
   undue burden on the backbones.  Also, it may be expected that as time
   goes by there will be increased direct interconnection of the direct
   providers, leaf routing domains directly attached to the backbones,
   and international links directly attached to the providers. Under
   these circumstances, the distinction between direct and indirect
   providers may become blurred.

   An additional factor that discourages allocation of IPv6 addresses
   from a backbone prefix is that the backbones and their attached
   providers are perceived as being independent. Providers may take
   their long-haul service from one or more backbones, or may switch
   backbones should a more cost-effective service be provided elsewhere.
   Having IPv6 addresses derived from a backbone is inconsistent with
   the nature of the relationship.


4.4   Multi-homed Routing Domains


   The discussions in Section 4.3 suggest methods for allocating IPv6
   addresses based on direct or indirect provider connectivity. This
   allows a great deal of information reduction to be achieved for those
   routing domains which are attached to a single TRD. In particular,
   such routing domains may select their IPv6 addresses from a space
   delegated to them by the direct provider. This allows the provider,
   when announcing the addresses that it can reach to other providers,
   to use a single address prefix to describe a large number of IPv6
   addresses corresponding to multiple routing domains.

   However, there are additional considerations for routing domains
   which are attached to multiple providers. Such `multi-homed' routing
   domains may, for example, consist of single-site campuses and
   companies which are attached to multiple backbones, large
   organizations which are attached to different providers at different
   locations in the same country, or multi-national organizations which
   are attached to backbones in a variety of countries worldwide. There



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


   are a number of possible ways to deal with these multi-homed routing
   domains.


4.4.1 Solution 1


   One possible solution is for each multi-homed organization to obtain
   its IPv6 address space independently of the providers to which it is
   attached.  This allows each multi-homed organization to base its IPv6
   assignments on a single prefix, and to thereby summarize the set of
   all IPv6 addresses reachable within that organization via a single
   prefix.  The disadvantage of this approach is that since the IPv6
   address for that organization has no relationship to the addresses of
   any particular TRD, the TRDs to which this organization is attached
   will need to advertise the prefix for this organization to other
   providers.  Other providers (potentially worldwide) will need to
   maintain an explicit entry for that organization in their routing
   tables.

   For example, suppose that a very large North American company `Mega
   Big International Incorporated' (MBII) has a fully interconnected
   internal network and is assigned a single prefix as part of the North
   American prefix.  It is likely that outside of North America, a
   single entry may be maintained in routing tables for all North
   American Destinations.  However, within North America, every provider
   will need to maintain a separate address entry for MBII. If MBII is
   in fact an international corporation, then it may be necessary for
   every provider worldwide to maintain a separate entry for MBII
   (including backbones to which MBII is not attached). Clearly this may
   be acceptable if there are a small number of such multi-homed routing
   domains, but would place an unacceptable load on routers within
   backbones if all organizations were to choose such address
   assignments.  This solution may not scale to internets where there
   are many hundreds of thousands of multi-homed organizations.


4.4.2 Solution 2


   A second possible approach would be for multi-homed organizations to
   be assigned a separate IPv6 address space for each connection to a
   TRD, and to assign a single prefix to some subset of its domain(s)
   based on the closest interconnection point. For example, if MBII had
   connections to two providers in the U.S. (one east coast, and one
   west coast), as well as three connections to national backbones in
   Europe, and one in the far east, then MBII may make use of six
   different address prefixes.  Each part of MBII would be assigned a



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


   single address prefix based on the nearest connection.

   For purposes of external routing of traffic from outside MBII to a
   destination inside of MBII, this approach works similarly to treating
   MBII as six separate organizations. For purposes of internal routing,
   or for routing traffic from inside of MBII to a destination outside
   of MBII, this approach works the same as the first solution.

   If we assume that incoming traffic (coming from outside of MBII, with
   a destination within MBII) is always to enter via the nearest point
   to the destination, then each TRD which has a connection to MBII
   needs to announce to other TRDs the ability to reach only those parts
   of MBII whose address is taken from its own address space. This
   implies that no additional routing information needs to be exchanged
   between TRDs, resulting in a smaller load on the inter-domain routing
   tables maintained by TRDs when compared to the first solution. This
   solution therefore scales better to extremely large internets
   containing very large numbers of multi-homed organizations.

   One problem with the second solution is that backup routes to multi-
   homed organizations are not automatically maintained. With the first
   solution, each TRD, in announcing the ability to reach MBII,
   specifies that it is able to reach all of the hosts within MBII. With
   the second solution, each TRD announces that it can reach all of the
   hosts based on its own address prefix, which only includes some of
   the hosts within MBII. If the connection between MBII and one
   particular TRD were severed, then the hosts within MBII with
   addresses based on that TRD would become unreachable via inter-domain
   routing. The impact of this problem can be reduced somewhat by
   maintenance of additional information within routing tables, but this
   reduces the scaling advantage of the second approach.

   The second solution also requires that when external connectivity
   changes, internal addresses also change.

   Also note that this and the previous approach will tend to cause
   packets to take different routes. With the first approach, packets
   from outside of MBII destined for within MBII will tend to enter via
   the point which is closest to the source (which will therefore tend
   to maximize the load on the networks internal to MBII). With the
   second solution, packets from outside destined for within MBII will
   tend to enter via the point which is closest to the destination
   (which will tend to minimize the load on the networks within MBII,
   and maximize the load on the TRDs).

   These solutions also have different effects on policies. For example,
   suppose that country `X' has a law that traffic from a source within
   country X to a destination within country X must at all times stay



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


   entirely within the country. With the first solution, it is not
   possible to determine from the destination address whether or not the
   destination is within the country. With the second solution, a
   separate address may be assigned to those hosts which are within
   country X, thereby allowing routing policies to be followed.
   Similarly, suppose that `Little Small Company' (LSC) has a policy
   that its packets may never be sent to a destination that is within
   MBII. With either solution, the routers within LSC may be configured
   to discard any traffic that has a destination within MBII's address
   space. However, with the first solution this requires one entry; with
   the second it requires many entries and may be impossible as a
   practical matter.


4.4.3 Solution 3


   There are other possible solutions as well. A third approach is to
   assign each multi-homed organization a single address prefix, based
   on one of its connections to a TRD. Other TRDs to which the multi-
   homed organization are attached maintain a routing table entry for
   the organization, but are extremely selective in terms of which other
   TRDs are told of this route. This approach will produce a single
   `default' routing entry which all TRDs will know how to reach (since
   presumably all TRDs will maintain routes to each other), while
   providing more direct routing in some cases.

   There is at least one situation in which this third approach is
   particularly appropriate. Suppose that a special interest group of
   organizations have deployed their own provider. For example, lets
   suppose that the U.S. National Widget Manufacturers and Researchers
   have set up a U.S.-wide provider, which is used by corporations who
   manufacture widgets, and certain universities which are known for
   their widget research efforts. We can expect that the various
   organizations which are in the widget group will run their internal
   networks as separate routing domains, and most of them will also be
   attached to other TRDs (since most of the organizations involved in
   widget manufacture and research will also be involved in other
   activities). We can therefore expect that many or most of the
   organizations in the widget group are dual-homed, with one attachment
   for widget-associated communications and the other attachment for
   other types of communications. Let's also assume that the total
   number of organizations involved in the widget group is small enough
   that it is reasonable to maintain a routing table containing one
   entry per organization, but that they are distributed throughout a
   larger internet with many millions of (mostly not widget-associated)
   routing domains.




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


   With the third approach, each multi-homed organization in the widget
   group would make use of an address assignment based on its other
   attachment(s) to TRDs (the attachments not associated with the widget