6. 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 IP addresses. As
CIDR [1] is introduced in the Internet, it is therefore essential
Rekhter & Li [Page 22]
RFC 1518 CIDR Address Allocation Architecture September 1993
to choose a hierarchical structure for IP addresses with great
care.
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 IP address allocation, this again means that routing data
abstraction must be encouraged.
In order for data abstraction to be possible, the assignment of IP
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 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 IP addresses
assigned within a single routing domain use a single address
prefix assigned to that domain. Specifically, this allows the set
of all IP 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.
6.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 (Alternet, ANSnet, CIX, EBone, PSI,
SprintLink);
- a number of regional or national networks; and,
Rekhter & Li [Page 23]
RFC 1518 CIDR Address Allocation Architecture September 1993
- 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). However, the total number of such TRDs
is expected to remain (for the foreseeable future) small enough to
allow addressing of this set of TRDs via a flat address space. 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 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 IP 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 abbreviation. 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.
Further, in order to allow aggregation of IP addresses at national
and continental boundaries into as few prefixes as possible, we
further recommend that IP addresses allocated to routing domains
should be assigned based on each routing domain's connectivity to
national and continental Internet backbones.
Rekhter & Li [Page 24]
RFC 1518 CIDR Address Allocation Architecture September 1993
6.2 Recommendations for Multi-Homed Routing Domains
There are several possible ways that these multi-homed routing
domains may be handled, as described in Section 5.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.3 Recommendations for the Administration of IP addresses
A companion document [3] provides recommendations for the
administrations of IP addresses.