As per Relevance of the word location, we have this rfc below:
Network Working Group Y.
Request for Comments: 1518 T.J. Watson Research Center, IBM Corp
Category: Standards Track T.
cisco
September 1993
An Architecture for IP Address Allocation with
Status of this
This RFC specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
1.
This paper provides an architecture and a plan for allocating
addresses in the Internet. This architecture and the plan
intended to play an important role in steering the Internet
the Address Assignment and Aggregating Strategy outlined in [1].
The IP address space is a scarce shared resource that must be
for the good of the community. The managers of this resource
acting as its custodians. They have a responsibility to the
to manage it for the common good
2.
The global Internet can be modeled as a collection of
interconnected via transmission and switching facilities.
over the collection of hosts and the transmission and
facilities that compose the networking resources of the
Internet is not homogeneous, but is distributed among
administrative authorities. Resources under control of a
administration form a domain. For the rest of this paper, "domain
and "routing domain" will be used interchangeably. Domains
share their resources with other domains are called network
providers (or just providers). Domains that utilize other domain'
resources are called network service subscribers (or
subscribers). A given domain may act as a provider and a
simultaneously
Rekhter & Li [Page 1]
RFC 1518 CIDR Address Allocation Architecture September 1993
There are two aspects of interest when discussing IP
allocation within the Internet. The first is the set
administrative requirements for obtaining and allocating
addresses; the second is the technical aspect of such assignments
having largely to do with routing, both within a routing
(intra-domain routing) and between routing domains (inter-
routing). This paper focuses on the technical issues
In the current Internet many routing domains (such as corporate
campus networks) attach to transit networks (such as regionals)
only one or a small number of carefully controlled access points
The former act as subscribers, while the latter act as providers
The architecture and recommendations provided in this paper
intended for immediate deployment. This paper specifically does
address long-term research issues, such as complex policy-
routing requirements
Addressing solutions which require substantial changes or
on the current topology are not considered
The architecture and recommendations in this paper are
primarily toward the large-scale division of IP address allocation
the Internet. Topics covered include
- Benefits of encoding some topological information in
addresses to significantly reduce routing protocol overhead
- The anticipated need for additional levels of hierarchy
Internet addressing to support network growth
- The recommended mapping between Internet topological
(i.e., service providers, and service subscribers) and
addressing and routing components
- The recommended division of IP address assignment among
providers (e.g., backbones, regionals), and service
(e.g., sites);
- Allocation of the IP addresses by the Internet Registry
- Choice of the high-order portion of the IP addresses in
routing domains that are connected to more than one
provider (e.g., backbone or a regional network).
It is noted that there are other aspects of IP address allocation
both technical and administrative, that are not covered in
paper. Topics not covered or mentioned only superficially include
Rekhter & Li [Page 2]
RFC 1518 CIDR Address Allocation Architecture September 1993
- Identification of specific administrative domains in
Internet
- Policy or mechanisms for making registered information known
third parties (such as the entity to which a specific IP
or a portion of the IP address space has been allocated);
- How a routing domain (especially a site) should organize
internal topology or allocate portions of its IP address space
the relationship between topology and addresses is discussed
but the method of deciding on a particular topology or
addressing plan is not; and
- Procedures for assigning host IP addresses
3.
Some background information is provided in this section that
helpful in understanding the issues involved in IP
allocation. A brief discussion of IP routing is provided
IP partitions the routing problem into three parts
- routing exchanges between end systems and routers (ARP),
- routing exchanges between routers in the same routing
(interior routing), and
- routing among routing domains (exterior routing).
4. IP Addresses and
For the purposes of this paper, an IP prefix is an IP address
some indication of the leftmost contiguous significant bits
this address. Throughout this paper IP address prefixes will
expressed as tuples, such that a bitwise
AND operation on the IP-address and IP-mask components of a
yields the sequence of leftmost contiguous significant bits that
the IP address prefix. For example a tuple with the value <193.1.0.0
255.255.0.0> denotes an IP address prefix with 16 leftmost
significant bits
When determining an administrative policy for IP address assignment
it is important to understand the technical consequences.
objective behind the use of hierarchical routing is to achieve
level of routing data abstraction, or summarization, to reduce
cpu, memory, and transmission bandwidth consumed in support
routing
Rekhter & Li [Page 3]
RFC 1518 CIDR Address Allocation Architecture September 1993
While the notion of routing data abstraction may be applied
various types of routing information, this paper focuses on
particular type, namely reachability information.
information describes the set of reachable destinations.
of reachability information dictates that IP addresses be
according to topological routing structures. However,
assignment falls along organizational or political boundaries.
may not be congruent to topological boundaries and therefore
requirements of the two may collide. It is necessary to find
balance between these two needs
Routing data abstraction occurs at the boundary
hierarchically arranged topological routing structures. An
lower in the hierarchy reports summary routing information to
parent(s).
At routing domain boundaries, IP address information is
(statically or dynamically) with other routing domains. If
addresses within a routing domain are all drawn from non-
IP address spaces (allowing no abstraction), then the
information consists of an enumerated list of all the IP addresses
Alternatively, should the routing domain draw IP addresses for
the hosts within the domain from a single IP address prefix,
routing information can be summarized into the single IP
prefix. This permits substantial data reduction and allows
scaling (as compared to the uncoordinated addressing discussed in
previous paragraph).
If routing domains are interconnected in a more-or-less random (i.e.,
non-hierarchical) scheme, it is quite likely that no
abstraction of routing data can occur. Since routing domains
have no defined hierarchical relationship, administrators would
be able to assign IP addresses within the domains out of some
prefix for the purpose of data abstraction. The result would be
inter-domain routing; all routing domains would need
knowledge of all other routing domains that they route to. This
work well in small and medium sized internets. However, this
not scale to very large internets. For example, we expect growth
the future to an Internet which has tens or hundreds of thousands
routing domains in North America alone. This requires a
degree of the reachability information abstraction beyond that
can be achieved at the "routing domain" level
In the Internet, however, it should be possible to
constrain the volume and the complexity of routing information
taking advantage of the existing hierarchical interconnectivity,
discussed in Section 5. Thus, there is the opportunity for a group
Rekhter & Li [Page 4]
RFC 1518 CIDR Address Allocation Architecture September 1993
routing domains each to be assigned an address prefix from a
prefix assigned to another routing domain whose function is
interconnect the group of routing domains. Each member of the
of routing domains now has its (somewhat longer) prefix, from
it assigns its addresses
The most straightforward case of this occurs when there is a set
routing domains which are all attached to a single service
domain (e.g., regional network), and which use that provider for
external (inter-domain) traffic. A small prefix may be given to
provider, which then gives slightly longer prefixes (based on
provider's prefix) to each of the routing domains that
interconnects. This allows the provider, when informing other
domains of the addresses that it can reach, to abbreviate
reachability information for a large number of routing domains as
single prefix. This approach therefore can allow a great deal
hierarchical abbreviation of routing information, and thereby
greatly improve the scalability of inter-domain routing
Clearly, this approach is recursive and can be carried
several iterations. Routing domains at any "level" in the
may use their prefix as the basis for subsequent suballocations
assuming that the IP addresses remain within the overall length
structure constraints
At this point, we observe that the number of nodes at each
level of a hierarchy tends to grow exponentially. Thus the
gains in the reachability information abstraction (for the benefit
all higher levels of the hierarchy) occur when the
information aggregation occurs near the leaves of the hierarchy;
gains drop significantly at each higher level. Therefore, the law
diminishing returns suggests that at some point data
ceases to produce significant benefits. Determination of the point
which data abstraction ceases to be of benefit requires a
consideration of the number of routing domains that are expected
occur at each level of the hierarchy (over a given period of time),
compared to the number of routing domains and address prefixes
can conveniently and efficiently be handled via dynamic inter-
routing protocols
4.1 Efficiency versus Decentralized
If the Internet plans to support a decentralized
administration [4], then there is a balance that must be
between the requirements on IP addresses for efficient routing
the need for decentralized address administration. A
described in [3] offers an example of how these two needs might
met
Rekhter & Li [Page 5]
RFC 1518 CIDR Address Allocation Architecture September 1993
The IP address prefix <198.0.0.0 254.0.0.0> provides
administrative decentralization. This prefix identifies part of
IP address space allocated for North America. The lower order part
that prefix allows allocation of IP addresses along
boundaries in support of increased data abstraction. Clients
North America use parts of the IP address space that is
the IP address space of their service providers. Within a
domain addresses for subnetworks and hosts are allocated from
unique IP prefix assigned to the domain
5. IP Address Administration and Routing in the
The basic Internet routing components are service providers (e.g.,
backbones, regional networks), and service subscribers (e.g.,
or campuses). These components are arranged hierarchically for
most part. A natural mapping from these components to IP
components is that providers and subscribers act as routing domains
Alternatively, a subscriber (e.g., a site) may choose to operate as
part of a domain formed by a service provider. We assume that some
if not most, sites will prefer to operate as part of their provider'
routing domain. Such sites can exchange routing information
their provider via interior routing protocol route leaking or via
exterior routing protocol. For the purposes of this discussion,
choice is not significant. The site is still allocated a prefix
the provider's address space, and the provider will advertise its
prefix into inter-domain routing
Given such a mapping, where should address administration
allocation be performed to satisfy both
decentralization and data abstraction? The following
are considered
- at some part within a routing domain
- at the leaf routing domain
- at the transit routing domain (TRD),
- at the continental boundaries
A point within a routing domain corresponds to a subnetwork. If
domain is composed of multiple subnetworks, they
interconnected via routers. Leaf routing domains correspond
sites, where the primary purpose is to provide intra-
routing services. Transit routing domains are deployed to
transit (i.e., inter-domain) traffic; backbones and providers
TRDs
Rekhter & Li [Page 6]
RFC 1518 CIDR Address Allocation Architecture September 1993
The greatest burden in transmitting and operating on
information is at the top of the routing hierarchy, where
information tends to accumulate. In the Internet, for example
providers must manage the set of network numbers for all
reachable through the provider. Traffic destined for
providers is generally routed to the backbones (which act
providers as well). The backbones, however, must be cognizant
the network numbers for all attached providers and
associated networks
In general, the advantage of abstracting routing information at
given level of the routing hierarchy is greater at the
levels of the hierarchy. There is relatively little direct
to the administration that performs the abstraction, since it
maintain routing information individually on each
topological routing structure
For example, suppose that a given site is trying to decide
to obtain an IP address prefix directly from the IP address
allocated for North America, or from the IP address
allocated to its service provider. If considering only their
self-interest, the site itself and the attached provider
little reason to choose one approach or the other. The site
use one prefix or another; the source of the prefix has
effect on routing efficiency within the site. The provider
maintain information about each attached site in order to route
regardless of any commonality in the prefixes of the sites
However, there is a difference when the provider
routing information to other providers (e.g., backbones or TRDs).
In the first case, the provider cannot aggregate the site'
address into its own prefix; the address must be explicitly
in routing exchanges, resulting in an additional burden to
providers which must exchange and maintain this information
In the second case, each other provider (e.g., backbone or TRD
sees a single address prefix for the provider, which
the new site. This avoids the exchange of additional
information to identify the new site's address prefix. Thus,
advantages primarily accrue to other providers which
routing information about this site and provider
One might apply a supplier/consumer model to this problem:
higher level (e.g., a backbone) is a supplier of routing services
while the lower level (e.g., a TRD) is the consumer of
services. The price charged for services is based upon the cost
providing them. The overhead of managing a large table
addresses for routing to an attached topological
Rekhter & Li [Page 7]
RFC 1518 CIDR Address Allocation Architecture September 1993
contributes to this cost
The Internet, however, is not a market economy. Rather,
operation is based on cooperation. The recommendations
below describe simple and tractable ways of managing the
address space that benefit the entire community
5.1 Administration of IP addresses within a
If individual subnetworks take their IP addresses from a myriad
unrelated IP address spaces, there will be effectively no
abstraction beyond what is built into existing intra-
routing protocols. For example, assume that within a
domain uses three independent prefixes assigned from
different IP address spaces associated with three
attached providers
This has a negative effect on inter-domain routing,
on those other domains which need to maintain routes to
domain. There is no common prefix that can be used to
these IP addresses and therefore no summarization can take
at the routing domain boundary. When addresses are advertised
this routing domain to other routing domains, an enumerated
of the three individual prefixes must be used
This situation is roughly analogous to the present
of routing information in the Internet, where each domain may
non-contiguous network numbers assigned to it. The result
allowing subnetworks within a routing domain to take their
addresses from unrelated IP address spaces is flat routing at
A/B/C class network level. The number of IP prefixes that
routing domains would advertise is on the order of the number
attached network numbers; the number of prefixes a provider'
routing domain would advertise is approximately the number
network numbers attached to the client leaf routing domains;
for a backbone this would be summed across all attached providers
This situation is just barely acceptable in the current Internet
and as the Internet grows this will quickly become intractable.
greater degree of hierarchical information reduction is
to allow continued growth in the Internet
5.2 Administration at the Leaf Routing
As mentioned previously, the greatest degree of data
comes at the lowest levels of the hierarchy. Providing each
routing domain (that is, site) with a prefix from its provider'
prefix results in the biggest single increase in abstraction.
outside the leaf routing domain, the set of all
Rekhter & Li [Page 8]
RFC 1518 CIDR Address Allocation Architecture September 1993
reachable in the domain can then be represented by a
prefix. Further, all destinations reachable within the provider'
prefix can be represented by a single prefix
For example, consider a single campus which is a leaf
domain which would currently require 4 different IP networks
Under the new allocation scheme, they might instead be given
single prefix which provides the same number of
addresses. Further, since the prefix is a subset of
provider's prefix, they impose no additional burden on the
levels of the routing hierarchy
There is a close relationship between subnetworks and
domains implicit in the fact that they operate a common
protocol and are under the control of a single administration.
routing domain administration subdivides the domain
subnetworks. The routing domain represents the only path
a subnetwork and the rest of the internetwork. It is
that this relationship also extend to include a common
addressing space. Thus, the subnetworks within the leaf
domain should take their IP addresses from the prefix assigned
the leaf routing domain
5.3 Administration at the Transit Routing
Two kinds of transit routing domains are considered,
providers and indirect providers. Most of the subscribers of
direct provider are domains that act solely as service
(they carry no transit traffic). Most of the subscribers of
indirect provider are domains that, themselves, act as
providers. In present terminology a backbone is an
provider, while a TRD is a direct provider. Each case is
separately below
5.3.1 Direct Service
It is interesting to consider whether direct service providers
routing domains should use their IP address space for assigning
addresses from a unique prefix to the leaf routing domains
they serve. The benefits derived from data abstraction are
than in the case of leaf routing domains, and the
degree of data abstraction provided by this may be necessary
the short term
As an illustration consider an example of a direct provider
serves 100 clients. If each client takes its addresses from 4
independent address spaces then the total number of entries
are needed to handle routing to these clients is 400 (100
Rekhter & Li [Page 9]
RFC 1518 CIDR Address Allocation Architecture September 1993
times 4 providers). If each client takes its addresses from
single address space then the total number of entries would
only 100. Finally, if all the clients take their addresses
the same address space then the total number of entries would
only 1.
We expect that in the near term the number of routing domains
the Internet will grow to the point that it will be infeasible
route on the basis of a flat field of routing domains. It
therefore be essential to provide a greater degree of
abstraction
Direct providers may give part of their address space (prefixes
to leaf domains, based on an address prefix given to the provider
This results in direct providers advertising to backbones a
fraction of the number of address prefixes that would be
if they enumerated the individual prefixes of the leaf
domains. This represents a significant savings given the
scale of global internetworking
Are leaf routing domains willing to accept prefixes derived
the direct providers? In the supplier/consumer model, the
provider is offering connectivity as the service, priced
to its costs of operation. This includes the "price" of
service from one or more indirect providers (e.g., backbones).
general, indirect providers will want to handle as few
prefixes as possible to keep costs low. In the
environment, which does not operate as a typical marketplace,
routing domains must be sensitive to the resource constraints
the providers (both direct and indirect). The efficiencies
in inter-domain routing clearly warrant the adoption of IP
prefixes derived from the IP address space of the providers
The mechanics of this scenario are straightforward. Each
provider is given a unique small set of IP address prefixes,
which its attached leaf routing domains can allocates
longer IP address prefixes. For example assume that NIST is
leaf routing domain whose inter-domain link is via SURANet.
SURANet is assigned an unique IP address prefix <198.1.0.0
255.255.0.0>, NIST could use a unique IP prefix of <198.1.0.0
255.255.240.0>.
If a direct service provider is connected to another provider(s
(either direct or indirect) via multiple attachment points,
in certain cases it may be advantageous to the direct provider
exert a certain degree of control over the coupling between
attachment points and flow of the traffic destined to a
subscriber. Such control can be facilitated by first
Rekhter & Li [Page 10]
RFC 1518 CIDR Address Allocation Architecture September 1993
all the subscribers into groups, such that traffic destined to
the subscribers within a group should flow through a
attachment point. Once the partitioning is done, the address
of the provider is subdivided along the group boundaries. A
routing domain that is willing to accept prefixes derived from
direct provider gets a prefix from the provider's address
subdivision associated with the group the domain belongs to.
that the advertisement by the direct provider of the
information associated with each subdivision must be done
care to ensure that such an advertisement would not result in
global distribution of separate reachability
associated with each subdivision, unless such distribution
warranted for some other purposes (e.g., supporting
aspects of policy-based routing).
5.3.2 Indirect Providers (Backbones
There does not appear to be a strong case for direct providers
take their address spaces from the the IP space of an
provider (e.g., backbone). The benefit in routing data
is relatively small. The number of direct providers today is
the tens and an order of magnitude increase would not cause
undue burden on the backbones. Also, it may be expected that
time goes by there will be increased direct interconnection of
direct providers, leaf routing domains directly attached to
backbones, and international links directly attached to
providers. Under these circumstances, the distinction
direct and indirect providers may become blurred
An additional factor that discourages allocation of IP
from a backbone prefix is that the backbones and their
providers are perceived as being independent. Providers may
their long- haul service from one or more backbones, or may
backbones should a more cost-effective service be
elsewhere. Having IP addresses derived from a backbone
inconsistent with the nature of the relationship
5.4 Multi-homed Routing
The discussions in Section 5.3 suggest methods for allocating
addresses based on direct or indirect provider connectivity.
allows a great deal of information reduction to be achieved
those routing domains which are attached to a single TRD.
particular, such routing domains may select their IP
from a space delegated to them by the direct provider. This
the provider, when announcing the addresses that it can reach
other providers, to use a single address prefix to describe
large number of IP addresses corresponding to multiple
Rekhter & Li [Page 11]
RFC 1518 CIDR Address Allocation Architecture September 1993
domains
However, there are additional considerations for routing
which are attached to multiple providers. Such "multi-homed
routing domains may, for example, consist of single-site
and companies which are attached to multiple backbones,
organizations which are attached to different providers
different locations in the same country, or multi-
organizations which are attached to backbones in a variety
countries worldwide. There are a number of possible ways to
with these multi-homed routing domains
One possible solution is for each multi-homed organization
obtain its IP address space independently from the providers
which it is attached. This allows each multi-homed
to base its IP assignments on a single prefix, and to
summarize the set of all IP addresses reachable within
organization via a single prefix. The disadvantage of
approach is that since the IP address for that organization has
relationship to the addresses of any particular TRD, the TRDs
which this organization is attached will need to advertise
prefix for this organization to other providers. Other
(potentially worldwide) will need to maintain an explicit
for that organization in their routing tables
For example, suppose that a very large North American
"Mega Big International Incorporated" (MBII) has a
interconnected internal network and is assigned a single prefix
part of the North American prefix. It is likely that outside
North America, a single entry may be maintained in routing
for all North American destinations. However, within
America, every provider will need to maintain a separate
entry for MBII. If MBII is in fact an international corporation
then it may be necessary for every provider worldwide to
a separate entry for MBII (including backbones to which MBII
not attached). Clearly this may be acceptable if there are a
number of such multi-homed routing domains, but would place
unacceptable load on routers within backbones if all
were to choose such address assignments. This solution may
scale to internets where there are many hundreds of thousands
multi-homed organizations
A second possible approach would be for multi-homed
to be assigned a separate IP address space for each connection
a TRD, and to assign a single prefix to some subset of
domain(s) based on the closest interconnection point. For example
if MBII had connections to two providers in the U.S. (one
coast, and one west coast), as well as three connections
Rekhter & Li [Page 12]
RFC 1518 CIDR Address Allocation Architecture September 1993
national backbones in Europe, and one in the far east, then
may make use of six different address prefixes. Each part of
would be assigned a single address prefix based on the
connection
For purposes of external routing of traffic from outside MBII to
destination inside of MBII, this approach works similarly
treating MBII as six separate organizations. For purposes
internal routing, or for routing traffic from inside of MBII to
destination outside of MBII, this approach works the same as
first solution
If we assume that incoming traffic (coming from outside of MBII
with a destination within MBII) is always to enter via the
point to the destination, then each TRD which has a connection
MBII needs to announce to other TRDs the ability to reach
those parts of MBII whose address is taken from its own
space. This implies that no additional routing information
to be exchanged between TRDs, resulting in a smaller load on
inter-domain routing tables maintained by TRDs when compared
the first solution. This solution therefore scales better
extremely large internets containing very large numbers of multi
homed organizations
One problem with the second solution is that backup routes
multi-homed organizations are not automatically maintained.
the first solution, each TRD, in announcing the ability to
MBII, specifies that it is able to reach all of the hosts
MBII. With the second solution, each TRD announces that it
reach all of the hosts based on its own address prefix, which
includes some of the hosts within MBII. If the connection
MBII and one particular TRD were severed, then the hosts
MBII with addresses based on that TRD would become unreachable
inter-domain routing. The impact of this problem can be
somewhat by maintenance of additional information within
tables, but this reduces the scaling advantage of the
approach
The second solution also requires that when external
changes, internal addresses also change
Also note that this and the previous approach will tend to
packets to take different routes. With the first approach,
from outside of MBII destined for within MBII will tend to
via the point which is closest to the source (which will
tend to maximize the load on the networks internal to MBII).
the second solution, packets from outside destined for within
will tend to enter via the point which is closest to
Rekhter & Li [Page 13]
RFC 1518 CIDR Address Allocation Architecture September 1993
destination (which will tend to minimize the load on the
within MBII, and maximize the load on the TRDs).
These solutions also have different effects on policies.
example, suppose that country "X" has a law that traffic from
source within country X to a destination within country X must
all times stay entirely within the country. With the
solution, it is not possible to determine from the
address whether or not the destination is within the country.
the second solution, a separate address may be assigned to
hosts which are within country X, thereby allowing
policies to be followed. Similarly, suppose that "Little
Company" (LSC) has a policy that its packets may never be sent
a destination that is within MBII. With either solution,
routers within LSC may be configured to discard any traffic
has a destination within MBII's address space. However, with
first solution this requires one entry; with the second
requires many entries and may be impossible as a practical matter
There are other possible solutions as well. A third approach is
assign each multi-homed organization a single address prefix
based on one of its connections to a TRD. Other TRDs to which
multi-homed organization are attached maintain a routing
entry for the organization, but are extremely selective in
of which other TRDs are told of this route. This approach
produce a single "default" routing entry which all TRDs will
how to reach (since presumably all TRDs will maintain routes
each other), while providing more direct routing in some cases
There is at least one situation in which this third approach
particularly appropriate. Suppose that a special interest group
organizations have deployed their own backbone. For example,
suppose that the U.S. National Widget Manufacturers
Researchers have set up a U.S.-wide backbone, which is used
corporations who manufacture widgets, and certain
which are known for their widget research efforts. We can
that the various organizations which are in the widget group
run their internal networks as separate routing domains, and
of them will also be attached to other TRDs (since most of
organizations involved in widget manufacture and research
also be involved in other activities). We can therefore
that many or most of the organizations in the widget group
dual-homed, with one attachment for widget-
communications and the other attachment for other types
communications. Let's also assume that the total number
organizations involved in the widget group is small enough that
is reasonable to maintain a routing table containing one entry
organization, but that they are distributed throughout a
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
widget group would make use of an address assignment based on
other attachment(s) to TRDs (the attachments not associated
the widget group). The widget backbone would need to
routes to the routing domains associated with the various
organizations. Similarly, all members of the widget group
need to maintain a table of routes to the other members via
widget backbone. However, since the widget backbone does
inform other general worldwide TRDs of what addresses it can
(since the backbone is not intended for use by other
organizations), the relatively large set of routing prefixes
to be maintained only in a limited number of places. The
assigned to the various organizations which are members of
widget group would provide a "default route" via each
other attachments to TRDs, while allowing communications
the widget group to use the preferred path
A fourth solution involves assignment of a particular
prefix for routing domains which are attached to precisely two (
more) specific routing domains. For example, suppose that
are two providers "SouthNorthNet" and "NorthSouthNet" which have
very large number of customers in common (i.e., there are a
number of routing domains which are attached to both). Rather
getting two address prefixes these organizations could
three prefixes. Those routing domains which are attached
NorthSouthNet but not attached to SouthNorthNet obtain an
assignment based on one of the prefixes. Those routing
which are attached to SouthNorthNet but not to NorthSouthNet
obtain an address based on the second prefix. Finally,
routing domains which are multi-homed to both of these
would obtain an address based on the third prefix. Each of
two TRDs would then advertise two prefixes to other TRDs,
prefix for leaf routing domains attached to it only, and
prefix for leaf routing domains attached to both
This fourth solution is likely to be important when use of
data networks becomes more common. In particular, it is
that at some point in the future a substantial percentage of
routing domains will be attached to public data networks. In
case, nearly all government-sponsored networks (such as
current regionals) may have a set of customers which
substantially with the public networks
There are therefore a number of possible solutions to the
of assigning IP addresses to multi-homed routing domains. Each
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
the multi-homed organizations, and on the TRDs (including those
which the multi-homed organizations are not attached).
In addition, most of the solutions described also highlight
need for each TRD to develop policy on whether and under
conditions to accept addresses that are not based on its
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
routing domain, but not advertised to other TRDs. In a
conservative policy, a TRD might accept such non-local
and agree to exchange them with a defined set of other TRDs (
set could be an a priori group of TRDs that have something
common such as geographical location, or the result of
agreement specific to the requesting leaf routing domain).
policies involve real costs to TRDs, which may be reflected
those policies
5.5 Private
The discussion up to this point concentrates on the
between IP addresses and routing between various routing
over transit routing domains, where each transit routing
interconnects a large number of routing domains and offers
more-or-less public service
However, there may also exist a number of links which
two routing domains in such a way, that usage of these links
be limited to carrying traffic only between the two
domains. We'll refer to such links as "private".
For example, let's suppose that the XYZ corporation does a lot
business with MBII. In this case, XYZ and MBII may contract with
carrier to provide a private link between the two corporations
where this link may only be used for packets whose source
within one of the two corporations, and whose destination
within the other of the two corporations. Finally, suppose
the point-to-point link is connected between a single
(router X) within XYZ corporation and a single router (router M
within MBII. It is therefore necessary to configure router X
know which addresses can be reached over this link (specifically
all addresses reachable in MBII). Similarly, it is necessary
configure router M to know which addresses can be reached
this link (specifically, all addresses reachable in
Corporation).
Rekhter & Li [Page 16]
RFC 1518 CIDR Address Allocation Architecture September 1993
The important observation to be made here is that the
connectivity due to such private links may be ignored for
purpose of IP address allocation, and do not pose a problem
routing. This is because the routing information associated
such connectivity is not propagated throughout the Internet,
therefore does not need to be collapsed into a TRD's prefix
In our example, let's suppose that the XYZ corporation has
single connection to a regional, and has therefore uses the
address space from the space given to that regional. Similarly
let's suppose that MBII, as an international corporation
connections to six different providers, has chosen the
solution from Section 5.4, and therefore has obtained
different address allocations. In this case, all
reachable in the XYZ Corporation can be described by a
address prefix (implying that router M only needs to be
with a single address prefix to represent the addresses
over this link). All addresses reachable in MBII can be
by six address prefixes (implying that router X needs to
configured with six address prefixes to represent the
reachable over the link).
In some cases, such private links may be permitted to
traffic for a small number of other routing domains, such
closely affiliated organizations. This will increase
configuration requirements slightly. However, provided that
number of organizations using the link is relatively small,
this still does not represent a significant problem
Note that the relationship between routing and IP
described in other sections of this paper is concerned
problems in scaling caused by large, essentially public
routing domains which interconnect a large number of
domains. However, for the purpose of IP address allocation
private links which interconnect only a small number of
routing domains do not pose a problem, and may be ignored.
example, this implies that a single leaf routing domain which
a single connection to a "public" backbone, plus a number
private links to other leaf routing domains, can be treated as
it were single-homed to the backbone for the purpose of IP
allocation. We expect that this is also another way of
with multi-homed domains
5.6 Zero-Homed Routing
Currently, a very large number of organizations have
communications networks which are not connected to any
providers. Such organizations may, however, have a number
Rekhter & Li [Page 17]
RFC 1518 CIDR Address Allocation Architecture September 1993
private links that they use for communications with
organizations. Such organizations do not participate in
routing, but are satisfied with reachability to
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
case of routing domains with private links, as discussed in
previous section, and do not pose a problem for inter-
routing. As above, the routing information exchanged across
private links sees very limited distribution, usually only to
routing domain at the other end of the link. Thus, there are
address abstraction requirements beyond those inherent in
address prefixes exchanged across the private link
However, it is important that zero-homed routing domains use
globally unique IP addresses. Suppose that the zero-homed
domain is connected through a private link to a routing domain
Further, this routing domain participates in an internet
subscribes to the global IP addressing plan. This domain must
able to distinguish between the zero-homed routing domain's
addresses and any other IP addresses that it may need to route to
The only way this can be guaranteed is if the zero-homed
domain uses globally unique IP addresses
5.7 Continental
Another level of hierarchy may also be used in this
scheme to further reduce the amount of routing
necessary for inter-continental routing. Continental
is useful because continental boundaries provide natural
to topological connection and administrative boundaries. Thus,
presents a natural boundary for another level of aggregation
inter-domain routing information. To make use of this, it
necessary that each continent be assigned an appropriate subset
the address space. Providers (both direct and indirect)
that continent would allocate their addresses from this space
Note that there are numerous exceptions to this, in which
service provider (either direct or indirect) spans a
division. These exceptions can be handled similarly to multi
homed routing domains, as discussed above
Note that, in contrast to the case of providers, the
of continental routing information may not be done on
continent to which the prefix is allocated. The cost of inter
continental links (and especially trans-oceanic links) is
high. If aggregation is performed on the "near" side of the link
then routing information about unreachable destinations
Rekhter & Li [Page 18]
RFC 1518 CIDR Address Allocation Architecture September 1993
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
inject it into continental routing. This means that
which are part of the continental aggregation, but for which
is not a corresponding more specific prefix can be rejected
leaving the continent on which they originated
For example, suppose that Europe is assigned a prefix
<194.0.0.0 254.0.0.0>, such that European routing also
the longer prefixes <194.1.0.0 255.255.0.0> and <194.2.0.0
255.255.0.0>. All of the longer European prefixes may
advertised across a trans-Atlantic link to North America.
router in North America would then aggregate these routes,
only advertise the prefix <194.0.0.0 255.0.0.0> into
American routing. Packets which are destined for 194.1.1.1
traverse North American routing, but would encounter the
American router which performed the European aggregation. If
prefix <194.1.0.0 255.255.0.0> is unreachable, the router
drop the packet and send an ICMP Unreachable without using
trans-Atlantic link
5.8 Transition
Allocation of IP addresses based on connectivity to TRDs
important to allow scaling of inter-domain routing to an
containing millions of routing domains. However, such
allocation based on topology implies that in order to maximize
efficiency in routing gained by such allocation, certain
in topology may suggest a change of address
Note that an address change need not happen immediately. A
which has changed service providers may still advertise its
through its new service provider. Since upper levels in
routing hierarchy will perform routing based on the
prefix, reachability is preserved, although the aggregation
scalability of the routing information has greatly diminished
Thus, a domain which does change its topology should
addresses as soon as convenient. The timing and mechanics of
changes must be the result of agreements between the old
provider, the new provider, and the domain
This need to allow for change in addresses is a natural
inevitable consequence of routing data abstraction. The
notion of routing data abstraction is that there is
correspondence between the address and where a system (i.e.,
routing domain, subnetwork, or end system) is located. Thus if
system moves, in some cases the address will have to change. If
Rekhter & Li [Page 19]
RFC 1518 CIDR Address Allocation Architecture September 1993
were possible to change the connectivity between routing
without changing the addresses, then it would clearly be
to keep track of the location of that routing domain on
individual basis
In the short term, due to the rapid growth and
commercialization of the Internet, it is possible that
topology may be relatively volatile. This implies that
for address transition is very important. Fortunately, there are
number of steps which can be taken to help ease the
required for address transition. A complete description of
transition issues is outside of the scope of this paper. However
a very brief outline of some transition issues is contained
this section
Also note that the possible requirement to transition
based on changes in topology imply that it is valuable
anticipate the future topology changes before finalizing a
for address allocation. For example, in the case of a
domain which is initially single-homed, but which is expecting
become multi-homed in the future, it may be advantageous to
IP addresses based on the anticipated future topology
In general, it will not be practical to transition the
addresses assigned to a routing domain in an instantaneous "
the address at midnight" manner. Instead, a gradual transition
required in which both the old and the new addresses will
valid for a limited period of time. During the transition period
both the old and new addresses are accepted by the end systems
the routing domain, and both old and new addresses must result
correct routing of packets to the destination
During the transition period, it is important that packets
the old address be forwarded correctly, even when the topology
changed. This is facilitated by the use of "longest match
inter-domain routing
For example, suppose that the XYZ Corporation was
connected only to the NorthSouthNet regional. The XYZ
therefore went off to the NorthSouthNet administration and got
IP address prefix assignment based on the IP address prefix
assigned to the NorthSouthNet regional. However, for a variety
reasons, the XYZ Corporation decided to terminate its
with the NorthSouthNet, and instead connect directly to
NewCommercialNet public data network. Thus the XYZ Corporation
has a new address assignment under the IP address prefix
to the NewCommercialNet. The old address for the XYZ
would seem to imply that traffic for the XYZ Corporation should
Rekhter & Li [Page 20]
RFC 1518 CIDR Address Allocation Architecture September 1993
routed to the NorthSouthNet, which no longer has any
connection with XYZ Corporation
If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet
are adjacent and cooperative, then this transition is easy
accomplish. In this case, packets routed to the XYZ
using the old address assignment could be routed to
NorthSouthNet, which would directly forward them to
NewCommercialNet, which would in turn forward them to
Corporation. In this case only NorthSouthNet and
need be aware of the fact that the old address refers to
destination which is no longer directly attached to NorthSouthNet
If the old TRD and the new TRD are not adjacent, then
situation is a bit more complex, but there are still
possible ways to forward traffic correctly
If the old TRD and the new TRD are themselves connected by
cooperative transit routing domains, then these
domains may agree to forward traffic for XYZ correctly.
example, suppose that NorthSouthNet and NewCommercialNet are
directly connected, but that they are both directly connected
the BBNet backbone. In this case, all three of NorthSouthNet
NewCommercialNet, and the BBNet backbone would need to maintain
special entry for XYZ corporation so that traffic to XYZ using
old address allocation would be forwarded via NewCommercialNet
However, other routing domains would not need to be aware of
new location for XYZ Corporation
Suppose that the old TRD and the new TRD are separated by a non
cooperative routing domain, or by a long path of routing domains
In this case, the old TRD could encapsulate traffic to
Corporation in order to deliver such packets to the
backbone
Also, those locations which do a significant amount of
with XYZ Corporation could have a specific entry in their
tables added to ensure optimal routing of packets to XYZ.
example, suppose that another commercial
"OldCommercialNet" has a large number of customers which
traffic with XYZ Corporation, and that this third TRD is
connected to both NorthSouthNet and NewCommercialNet. In this
OldCommercialNet will continue to have a single entry in
routing tables for other traffic destined for NorthSouthNet,
may choose to add one additional (more specific) entry to
that packets sent to XYZ Corporation's old address are
correctly
Rekhter & Li [Page 21]
RFC 1518 CIDR Address Allocation Architecture September 1993
Whichever method is used to ease address transition, the goal
that knowledge relating XYZ to its old address that is
throughout the global internet would eventually be replaced
the new information. It is reasonable to expect this to
weeks or months and will be accomplished through the
directory system. Discussion of the directory, along with
address transition techniques such as automatically informing
source of a changed address, are outside the scope of this paper
Another significant transition difficulty is the establishment
appropriate addressing authorities. In order not to delay
deployment of this addressing scheme, if no authority has
created at an appropriate level, a higher level authority
allocated addresses instead of the lower level authority.
example, suppose that the continental authority has been
a portion of the address space and that the service
present on that continent are clear, but have not yet
their addressing authority. The continental authority may
(possibly with information from the provider) that the
will eventually create an authority. The continental
may then act on behalf of that provider until the provider
prepared to assume its addressing authority duties
Finally, it is important to emphasize, that a change of
due to changes in topology is not mandated by this document.
continental level addressing hierarchy, as discussed in
5.7, is intended to handle the aggregation of
information in the cases where addresses do not directly
the connectivity between providers and subscribers
5.9 Interaction with Policy
We assume that any inter-domain routing protocol will
difficulty trying to aggregate multiple destinations
dissimilar policies. At the same time, the ability to
routing information while not violating routing policies
essential. Therefore, we suggest that address
authorities attempt to allocate addresses so that aggregates
destinations with similar policies can be easily formed
6.
We anticipate that the current exponential growth of the
will continue or accelerate for the foreseeable future.
addition, we anticipate a rapid internationalization of
Internet. The ability of routing to scale is dependent upon
use of data abstraction based on hierarchical IP addresses.
CIDR [1] is introduced in the Internet, it is therefore
Rekhter & Li [Page 22]
RFC 1518 CIDR Address Allocation Architecture September 1993
to choose a hierarchical structure for IP addresses with
care
It is in the best interests of the internetworking community
the cost of operations be kept to a minimum where possible. In
case of IP address allocation, this again means that routing
abstraction must be encouraged
In order for data abstraction to be possible, the assignment of
addresses must be accomplished in a manner which is
with the actual physical topology of the Internet. For example,
those cases where organizational and administrative boundaries
not related to actual network topology, address assignment
on such organization boundaries is not recommended
The intra-domain routing protocols allow for
abstraction to be maintained within a domain. For zero-homed
single-homed routing domains (which are expected to remain zero
homed or single-homed), we recommend that the IP
assigned within a single routing domain use a single
prefix assigned to that domain. Specifically, this allows the
of all IP addresses reachable within a single domain to be
described via a single prefix
We anticipate that the total number of routing domains existing
a worldwide Internet to be great enough that additional levels
hierarchical data abstraction beyond the routing domain level
be necessary
In most cases, network topology will have a close
with national boundaries. For example, the degree of
connectivity will often be greater within a single country
between countries. It is therefore appropriate to make
recommendations based on national boundaries, with
understanding that there may be specific situations where
general recommendations need to be modified
6.1 Recommendations for an address allocation
We anticipate that public interconnectivity between
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
manner (for example, there is expected to be direct
between regionals, and all of these types of networks may have
international connections). However,