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 backbone. For example, lets
suppose that the U.S. National Widget Manufacturers and
Researchers have set up a U.S.-wide backbone, 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
Rekhter & Li [Page 14]
RFC 1518 CIDR Address Allocation Architecture September 1993
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 backbone 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 backbone. However, since the widget backbone does not
inform other general worldwide TRDs of what addresses it can reach
(since the backbone 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 IP addresses to multi-homed routing domains. Each of
Rekhter & Li [Page 15]
RFC 1518 CIDR Address Allocation Architecture September 1993
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 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 IP 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.