IPv6ユニキャストアドレス割り当て体系（マルチホームルーティングドメイン）

   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
   are a number of possible ways to deal with these multi-homed routing
   domains.

   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.

   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
   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
   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.

   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.

   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
   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.

   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.

   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.