summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1518.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1518.txt')
-rw-r--r--doc/rfc/rfc1518.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc1518.txt b/doc/rfc/rfc1518.txt
new file mode 100644
index 0000000..d440908
--- /dev/null
+++ b/doc/rfc/rfc1518.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group Y. Rekhter
+Request for Comments: 1518 T.J. Watson Research Center, IBM Corp.
+Category: Standards Track T. Li
+ cisco Systems
+ Editors
+ September 1993
+
+
+ An Architecture for IP Address Allocation with CIDR
+
+Status of this Memo
+
+ This RFC specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" for the standardization state and status
+ of this protocol. Distribution of this memo is unlimited.
+
+1. Introduction
+
+ This paper provides an architecture and a plan for allocating IP
+ addresses in the Internet. This architecture and the plan are
+ intended to play an important role in steering the Internet towards
+ the Address Assignment and Aggregating Strategy outlined in [1].
+
+ The IP address space is a scarce shared resource that must be managed
+ for the good of the community. The managers of this resource are
+ acting as its custodians. They have a responsibility to the community
+ to manage it for the common good.
+
+2. Scope
+
+ The global Internet can be modeled as a collection of hosts
+ interconnected via transmission and switching facilities. Control
+ over the collection of hosts and the transmission and switching
+ facilities that compose the networking resources of the global
+ Internet is not homogeneous, but is distributed among multiple
+ administrative authorities. Resources under control of a single
+ administration form a domain. For the rest of this paper, "domain"
+ and "routing domain" will be used interchangeably. Domains that
+ share their resources with other domains are called network service
+ providers (or just providers). Domains that utilize other domain's
+ resources are called network service subscribers (or just
+ subscribers). A given domain may act as a provider and a subscriber
+ simultaneously.
+
+
+
+
+
+
+Rekhter & Li [Page 1]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ There are two aspects of interest when discussing IP address
+ allocation within the Internet. The first is the set of
+ administrative requirements for obtaining and allocating IP
+ addresses; the second is the technical aspect of such assignments,
+ having largely to do with routing, both within a routing domain
+ (intra-domain routing) and between routing domains (inter-domain
+ routing). This paper focuses on the technical issues.
+
+ In the current Internet many routing domains (such as corporate and
+ campus networks) attach to transit networks (such as regionals) in
+ 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 are
+ intended for immediate deployment. This paper specifically does not
+ address long-term research issues, such as complex policy-based
+ routing requirements.
+
+ Addressing solutions which require substantial changes or constraints
+ on the current topology are not considered.
+
+ The architecture and recommendations in this paper are oriented
+ primarily toward the large-scale division of IP address allocation in
+ the Internet. Topics covered include:
+
+ - Benefits of encoding some topological information in IP
+ addresses to significantly reduce routing protocol overhead;
+
+ - The anticipated need for additional levels of hierarchy in
+ Internet addressing to support network growth;
+
+ - The recommended mapping between Internet topological entities
+ (i.e., service providers, and service subscribers) and IP
+ addressing and routing components;
+
+ - The recommended division of IP address assignment among service
+ providers (e.g., backbones, regionals), and service subscribers
+ (e.g., sites);
+
+ - Allocation of the IP addresses by the Internet Registry;
+
+ - Choice of the high-order portion of the IP addresses in leaf
+ routing domains that are connected to more than one service
+ 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 this
+ 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 the
+ Internet;
+
+ - Policy or mechanisms for making registered information known to
+ third parties (such as the entity to which a specific IP address
+ or a portion of the IP address space has been allocated);
+
+ - How a routing domain (especially a site) should organize its
+ 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 internal
+ addressing plan is not; and,
+
+ - Procedures for assigning host IP addresses.
+
+3. Background
+
+ Some background information is provided in this section that is
+ helpful in understanding the issues involved in IP address
+ 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 domain
+ (interior routing), and,
+
+ - routing among routing domains (exterior routing).
+
+4. IP Addresses and Routing
+
+ For the purposes of this paper, an IP prefix is an IP address and
+ some indication of the leftmost contiguous significant bits within
+ this address. Throughout this paper IP address prefixes will be
+ expressed as <IP-address IP-mask> tuples, such that a bitwise logical
+ AND operation on the IP-address and IP-mask components of a tuple
+ yields the sequence of leftmost contiguous significant bits that form
+ 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 contiguous
+ significant bits.
+
+ When determining an administrative policy for IP address assignment,
+ it is important to understand the technical consequences. The
+ objective behind the use of hierarchical routing is to achieve some
+ level of routing data abstraction, or summarization, to reduce the
+ cpu, memory, and transmission bandwidth consumed in support of
+ routing.
+
+
+
+Rekhter & Li [Page 3]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ While the notion of routing data abstraction may be applied to
+ various types of routing information, this paper focuses on one
+ particular type, namely reachability information. Reachability
+ information describes the set of reachable destinations. Abstraction
+ of reachability information dictates that IP addresses be assigned
+ according to topological routing structures. However, administrative
+ assignment falls along organizational or political boundaries. These
+ may not be congruent to topological boundaries and therefore the
+ requirements of the two may collide. It is necessary to find a
+ balance between these two needs.
+
+ Routing data abstraction occurs at the boundary between
+ hierarchically arranged topological routing structures. An element
+ lower in the hierarchy reports summary routing information to its
+ parent(s).
+
+ At routing domain boundaries, IP address information is exchanged
+ (statically or dynamically) with other routing domains. If IP
+ addresses within a routing domain are all drawn from non-contiguous
+ IP address spaces (allowing no abstraction), then the boundary
+ information consists of an enumerated list of all the IP addresses.
+
+ Alternatively, should the routing domain draw IP addresses for all
+ the hosts within the domain from a single IP address prefix, boundary
+ routing information can be summarized into the single IP address
+ prefix. This permits substantial data reduction and allows better
+ scaling (as compared to the uncoordinated addressing discussed in the
+ previous paragraph).
+
+ If routing domains are interconnected in a more-or-less random (i.e.,
+ non-hierarchical) scheme, it is quite likely that no further
+ abstraction of routing data can occur. Since routing domains would
+ have no defined hierarchical relationship, administrators would not
+ be able to assign IP addresses within the domains out of some common
+ prefix for the purpose of data abstraction. The result would be flat
+ inter-domain routing; all routing domains would need explicit
+ knowledge of all other routing domains that they route to. This can
+ work well in small and medium sized internets. However, this does
+ not scale to very large internets. For example, we expect growth in
+ the future to an Internet which has tens or hundreds of thousands of
+ routing domains in North America alone. This requires a greater
+ degree of the reachability information abstraction beyond that which
+ can be achieved at the "routing domain" level.
+
+ In the Internet, however, it should be possible to significantly
+ constrain the volume and the complexity of routing information by
+ taking advantage of the existing hierarchical interconnectivity, as
+ discussed in Section 5. Thus, there is the opportunity for a group of
+
+
+
+Rekhter & Li [Page 4]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ routing domains each to be assigned an address prefix from a shorter
+ prefix assigned to another routing domain whose function is to
+ interconnect the group of routing domains. Each member of the group
+ of routing domains now has its (somewhat longer) prefix, from which
+ it assigns its addresses.
+
+ The most straightforward case of this occurs when there is a set of
+ routing domains which are all attached to a single service provider
+ domain (e.g., regional network), and which use that provider for all
+ external (inter-domain) traffic. A small prefix may be given to the
+ provider, which then gives slightly longer prefixes (based on the
+ provider's prefix) to each of the routing domains that it
+ interconnects. This allows the provider, when informing other routing
+ domains of the addresses that it can reach, to abbreviate the
+ reachability information for a large number of routing domains as a
+ single prefix. This approach therefore can allow a great deal of
+ hierarchical abbreviation of routing information, and thereby can
+ greatly improve the scalability of inter-domain routing.
+
+ Clearly, this approach is recursive and can be carried through
+ several iterations. Routing domains at any "level" in the hierarchy
+ may use their prefix as the basis for subsequent suballocations,
+ assuming that the IP addresses remain within the overall length and
+ structure constraints.
+
+ At this point, we observe that the number of nodes at each lower
+ level of a hierarchy tends to grow exponentially. Thus the greatest
+ gains in the reachability information abstraction (for the benefit of
+ all higher levels of the hierarchy) occur when the reachability
+ information aggregation occurs near the leaves of the hierarchy; the
+ gains drop significantly at each higher level. Therefore, the law of
+ diminishing returns suggests that at some point data abstraction
+ ceases to produce significant benefits. Determination of the point at
+ which data abstraction ceases to be of benefit requires a careful
+ consideration of the number of routing domains that are expected to
+ occur at each level of the hierarchy (over a given period of time),
+ compared to the number of routing domains and address prefixes that
+ can conveniently and efficiently be handled via dynamic inter-domain
+ routing protocols.
+
+4.1 Efficiency versus Decentralized Control
+
+ If the Internet plans to support a decentralized address
+ administration [4], then there is a balance that must be sought
+ between the requirements on IP addresses for efficient routing and
+ the need for decentralized address administration. A proposal
+ described in [3] offers an example of how these two needs might be
+ 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 for
+ administrative decentralization. This prefix identifies part of the
+ IP address space allocated for North America. The lower order part of
+ that prefix allows allocation of IP addresses along topological
+ boundaries in support of increased data abstraction. Clients within
+ North America use parts of the IP address space that is underneath
+ the IP address space of their service providers. Within a routing
+ domain addresses for subnetworks and hosts are allocated from the
+ unique IP prefix assigned to the domain.
+
+5. IP Address Administration and Routing in the Internet
+
+ The basic Internet routing components are service providers (e.g.,
+ backbones, regional networks), and service subscribers (e.g., sites
+ or campuses). These components are arranged hierarchically for the
+ most part. A natural mapping from these components to IP routing
+ components is that providers and subscribers act as routing domains.
+
+ Alternatively, a subscriber (e.g., a site) may choose to operate as a
+ 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's
+ routing domain. Such sites can exchange routing information with
+ their provider via interior routing protocol route leaking or via an
+ exterior routing protocol. For the purposes of this discussion, the
+ choice is not significant. The site is still allocated a prefix from
+ the provider's address space, and the provider will advertise its own
+ prefix into inter-domain routing.
+
+ Given such a mapping, where should address administration and
+ allocation be performed to satisfy both administrative
+ decentralization and data abstraction? The following possibilities
+ are considered:
+
+ - at some part within a routing domain,
+
+ - at the leaf routing domain,
+
+ - at the transit routing domain (TRD), and
+
+ - at the continental boundaries.
+
+ A point within a routing domain corresponds to a subnetwork. If a
+ domain is composed of multiple subnetworks, they are
+ interconnected via routers. Leaf routing domains correspond to
+ sites, where the primary purpose is to provide intra-domain
+ routing services. Transit routing domains are deployed to carry
+ transit (i.e., inter-domain) traffic; backbones and providers are
+ TRDs.
+
+
+
+Rekhter & Li [Page 6]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ The greatest burden in transmitting and operating on routing
+ information is at the top of the routing hierarchy, where routing
+ information tends to accumulate. In the Internet, for example,
+ providers must manage the set of network numbers for all networks
+ reachable through the provider. Traffic destined for other
+ providers is generally routed to the backbones (which act as
+ providers as well). The backbones, however, must be cognizant of
+ the network numbers for all attached providers and their
+ associated networks.
+
+ In general, the advantage of abstracting routing information at a
+ given level of the routing hierarchy is greater at the higher
+ levels of the hierarchy. There is relatively little direct benefit
+ to the administration that performs the abstraction, since it must
+ maintain routing information individually on each attached
+ topological routing structure.
+
+ For example, suppose that a given site is trying to decide whether
+ to obtain an IP address prefix directly from the IP address space
+ allocated for North America, or from the IP address space
+ allocated to its service provider. If considering only their own
+ self-interest, the site itself and the attached provider have
+ little reason to choose one approach or the other. The site must
+ use one prefix or another; the source of the prefix has little
+ effect on routing efficiency within the site. The provider must
+ 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 distributes
+ routing information to other providers (e.g., backbones or TRDs).
+ In the first case, the provider cannot aggregate the site's
+ address into its own prefix; the address must be explicitly listed
+ in routing exchanges, resulting in an additional burden to other
+ 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 encompasses
+ the new site. This avoids the exchange of additional routing
+ information to identify the new site's address prefix. Thus, the
+ advantages primarily accrue to other providers which maintain
+ routing information about this site and provider.
+
+ One might apply a supplier/consumer model to this problem: the
+ higher level (e.g., a backbone) is a supplier of routing services,
+ while the lower level (e.g., a TRD) is the consumer of these
+ services. The price charged for services is based upon the cost of
+ providing them. The overhead of managing a large table of
+ addresses for routing to an attached topological entity
+
+
+
+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, efficient
+ operation is based on cooperation. The recommendations discussed
+ below describe simple and tractable ways of managing the IP
+ address space that benefit the entire community.
+
+5.1 Administration of IP addresses within a domain
+
+ If individual subnetworks take their IP addresses from a myriad of
+ unrelated IP address spaces, there will be effectively no data
+ abstraction beyond what is built into existing intra-domain
+ routing protocols. For example, assume that within a routing
+ domain uses three independent prefixes assigned from three
+ different IP address spaces associated with three different
+ attached providers.
+
+ This has a negative effect on inter-domain routing, particularly
+ on those other domains which need to maintain routes to this
+ domain. There is no common prefix that can be used to represent
+ these IP addresses and therefore no summarization can take place
+ at the routing domain boundary. When addresses are advertised by
+ this routing domain to other routing domains, an enumerated list
+ of the three individual prefixes must be used.
+
+ This situation is roughly analogous to the present dissemination
+ of routing information in the Internet, where each domain may have
+ non-contiguous network numbers assigned to it. The result of
+ allowing subnetworks within a routing domain to take their IP
+ addresses from unrelated IP address spaces is flat routing at the
+ A/B/C class network level. The number of IP prefixes that leaf
+ routing domains would advertise is on the order of the number of
+ attached network numbers; the number of prefixes a provider's
+ routing domain would advertise is approximately the number of
+ network numbers attached to the client leaf routing domains; and
+ 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. A
+ greater degree of hierarchical information reduction is necessary
+ to allow continued growth in the Internet.
+
+5.2 Administration at the Leaf Routing Domain
+
+ As mentioned previously, the greatest degree of data abstraction
+ comes at the lowest levels of the hierarchy. Providing each leaf
+ routing domain (that is, site) with a prefix from its provider's
+ prefix results in the biggest single increase in abstraction. From
+ outside the leaf routing domain, the set of all addresses
+
+
+
+Rekhter & Li [Page 8]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ reachable in the domain can then be represented by a single
+ prefix. Further, all destinations reachable within the provider's
+ prefix can be represented by a single prefix.
+
+ For example, consider a single campus which is a leaf routing
+ domain which would currently require 4 different IP networks.
+ Under the new allocation scheme, they might instead be given a
+ single prefix which provides the same number of destination
+ addresses. Further, since the prefix is a subset of the
+ provider's prefix, they impose no additional burden on the higher
+ levels of the routing hierarchy.
+
+ There is a close relationship between subnetworks and routing
+ domains implicit in the fact that they operate a common routing
+ protocol and are under the control of a single administration. The
+ routing domain administration subdivides the domain into
+ subnetworks. The routing domain represents the only path between
+ a subnetwork and the rest of the internetwork. It is reasonable
+ that this relationship also extend to include a common IP
+ addressing space. Thus, the subnetworks within the leaf routing
+ domain should take their IP addresses from the prefix assigned to
+ the leaf routing domain.
+
+5.3 Administration at the Transit Routing Domain
+
+ Two kinds of transit routing domains are considered, direct
+ providers and indirect providers. Most of the subscribers of a
+ direct provider are domains that act solely as service subscribers
+ (they carry no transit traffic). Most of the subscribers of an
+ indirect provider are domains that, themselves, act as service
+ providers. In present terminology a backbone is an indirect
+ provider, while a TRD is a direct provider. Each case is discussed
+ separately below.
+
+5.3.1 Direct Service Providers
+
+ It is interesting to consider whether direct service providers'
+ routing domains should use their IP address space for assigning IP
+ addresses from a unique prefix to the leaf routing domains that
+ they serve. The benefits derived from data abstraction are greater
+ than in the case of leaf routing domains, and the additional
+ degree of data abstraction provided by this may be necessary in
+ the short term.
+
+ As an illustration consider an example of a direct provider that
+ serves 100 clients. If each client takes its addresses from 4
+ independent address spaces then the total number of entries that
+ are needed to handle routing to these clients is 400 (100 clients
+
+
+
+Rekhter & Li [Page 9]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ times 4 providers). If each client takes its addresses from a
+ single address space then the total number of entries would be
+ only 100. Finally, if all the clients take their addresses from
+ the same address space then the total number of entries would be
+ only 1.
+
+ We expect that in the near term the number of routing domains in
+ the Internet will grow to the point that it will be infeasible to
+ route on the basis of a flat field of routing domains. It will
+ therefore be essential to provide a greater degree of information
+ 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 small
+ fraction of the number of address prefixes that would be necessary
+ if they enumerated the individual prefixes of the leaf routing
+ domains. This represents a significant savings given the expected
+ scale of global internetworking.
+
+ Are leaf routing domains willing to accept prefixes derived from
+ the direct providers? In the supplier/consumer model, the direct
+ provider is offering connectivity as the service, priced according
+ to its costs of operation. This includes the "price" of obtaining
+ service from one or more indirect providers (e.g., backbones). In
+ general, indirect providers will want to handle as few address
+ prefixes as possible to keep costs low. In the Internet
+ environment, which does not operate as a typical marketplace, leaf
+ routing domains must be sensitive to the resource constraints of
+ the providers (both direct and indirect). The efficiencies gained
+ in inter-domain routing clearly warrant the adoption of IP address
+ prefixes derived from the IP address space of the providers.
+
+ The mechanics of this scenario are straightforward. Each direct
+ provider is given a unique small set of IP address prefixes, from
+ which its attached leaf routing domains can allocates slightly
+ longer IP address prefixes. For example assume that NIST is a
+ leaf routing domain whose inter-domain link is via SURANet. If
+ 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, 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
+
+
+
+Rekhter & Li [Page 10]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ 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. 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 other purposes (e.g., supporting certain
+ aspects of policy-based routing).
+
+5.3.2 Indirect Providers (Backbones)
+
+ There does not appear to be a strong case for direct providers to
+ take their address spaces from the the IP 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 IP 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 IP addresses derived from a backbone is
+ inconsistent with the nature of the relationship.
+
+5.4 Multi-homed Routing Domains
+
+ The discussions in Section 5.3 suggest methods for allocating IP
+ 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 IP 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 IP addresses corresponding to multiple routing
+
+
+
+Rekhter & Li [Page 11]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ 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 IP address space independently from the providers to
+ which it is attached. This allows each multi-homed organization
+ to base its IP assignments on a single prefix, and to thereby
+ summarize the set of all IP addresses reachable within that
+ organization via a single prefix. The disadvantage of this
+ approach is that since the IP 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 IP 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
+
+
+
+Rekhter & Li [Page 12]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ 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
+
+
+
+Rekhter & Li [Page 13]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ 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 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.
+
+5.5 Private Links
+
+ The discussion up to this point concentrates on the relationship
+ between IP addresses and routing between various routing domains
+ over transit routing domains, where each transit routing domain
+ interconnects a large number of routing domains and offers a
+ more-or-less public service.
+
+ However, there may also exist a number of links which interconnect
+ two routing domains in such a way, that usage of these links may
+ be limited to carrying traffic only between the two routing
+ domains. We'll refer to such links as "private".
+
+ For example, let's suppose that the XYZ corporation does a lot of
+ business with MBII. In this case, XYZ and MBII may contract with a
+ carrier to provide a private link between the two corporations,
+ where this link may only be used for packets whose source is
+ within one of the two corporations, and whose destination is
+ within the other of the two corporations. Finally, suppose that
+ the point-to-point link is connected between a single router
+ (router X) within XYZ corporation and a single router (router M)
+ within MBII. It is therefore necessary to configure router X to
+ know which addresses can be reached over this link (specifically,
+ all addresses reachable in MBII). Similarly, it is necessary to
+ configure router M to know which addresses can be reached over
+ this link (specifically, all addresses reachable in XYZ
+ Corporation).
+
+
+
+
+Rekhter & Li [Page 16]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ The important observation to be made here is that the additional
+ connectivity due to such private links may be ignored for the
+ purpose of IP address allocation, and do not pose a problem for
+ routing. This is because the routing information associated with
+ such connectivity is not propagated throughout the Internet, and
+ therefore does not need to be collapsed into a TRD's prefix.
+
+ In our example, let's suppose that the XYZ corporation has a
+ single connection to a regional, and has therefore uses the IP
+ address space from the space given to that regional. Similarly,
+ let's suppose that MBII, as an international corporation with
+ connections to six different providers, has chosen the second
+ solution from Section 5.4, and therefore has obtained six
+ different address allocations. In this case, all addresses
+ reachable in the XYZ Corporation can be described by a single
+ address prefix (implying that router M only needs to be configured
+ with a single address prefix to represent the addresses reachable
+ over this link). All addresses reachable in MBII can be described
+ by six address prefixes (implying that router X needs to be
+ configured with six address prefixes to represent the addresses
+ reachable over the link).
+
+ In some cases, such private links may be permitted to forward
+ traffic for a small number of other routing domains, such as
+ closely affiliated organizations. This will increase the
+ configuration requirements slightly. However, provided that the
+ number of organizations using the link is relatively small, then
+ this still does not represent a significant problem.
+
+ Note that the relationship between routing and IP addressing
+ described in other sections of this paper is concerned with
+ problems in scaling caused by large, essentially public transit
+ routing domains which interconnect a large number of routing
+ domains. However, for the purpose of IP address allocation,
+ private links which interconnect only a small number of private
+ routing domains do not pose a problem, and may be ignored. For
+ example, this implies that a single leaf routing domain which has
+ a single connection to a "public" backbone, plus a number of
+ private links to other leaf routing domains, can be treated as if
+ it were single-homed to the backbone for the purpose of IP address
+ allocation. We expect that this is also another way of dealing
+ with multi-homed domains.
+
+5.6 Zero-Homed Routing Domains
+
+ Currently, a very large number of organizations have internal
+ communications networks which are not connected to any service
+ providers. Such organizations may, however, have a number of
+
+
+
+Rekhter & Li [Page 17]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ private links that they use for communications with other
+ organizations. Such organizations do not participate in global
+ routing, but are satisfied with reachability to those
+ 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 degenerate
+ case of routing domains with private links, as discussed in the
+ previous section, and do not pose a problem for inter-domain
+ routing. As above, the routing information exchanged across the
+ private links sees very limited distribution, usually only to the
+ routing domain at the other end of the link. Thus, there are no
+ address abstraction requirements beyond those inherent in the
+ address prefixes exchanged across the private link.
+
+ However, it is important that zero-homed routing domains use valid
+ globally unique IP addresses. Suppose that the zero-homed routing
+ domain is connected through a private link to a routing domain.
+ Further, this routing domain participates in an internet that
+ subscribes to the global IP addressing plan. This domain must be
+ able to distinguish between the zero-homed routing domain's IP
+ 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 routing
+ domain uses globally unique IP addresses.
+
+5.7 Continental aggregation
+
+ Another level of hierarchy may also be used in this addressing
+ scheme to further reduce the amount of routing information
+ necessary for inter-continental routing. Continental aggregation
+ is useful because continental boundaries provide natural barriers
+ to topological connection and administrative boundaries. Thus, it
+ presents a natural boundary for another level of aggregation of
+ inter-domain routing information. To make use of this, it is
+ necessary that each continent be assigned an appropriate subset of
+ the address space. Providers (both direct and indirect) within
+ that continent would allocate their addresses from this space.
+ Note that there are numerous exceptions to this, in which a
+ service provider (either direct or indirect) spans a continental
+ 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 aggregation
+ of continental routing information may not be done on the
+ continent to which the prefix is allocated. The cost of inter-
+ continental links (and especially trans-oceanic links) is very
+ high. If aggregation is performed on the "near" side of the link,
+ then routing information about unreachable destinations within
+
+
+
+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 and
+ inject it into continental routing. This means that destinations
+ which are part of the continental aggregation, but for which there
+ is not a corresponding more specific prefix can be rejected before
+ leaving the continent on which they originated.
+
+ For example, suppose that Europe is assigned a prefix of
+ <194.0.0.0 254.0.0.0>, such that European routing also contains
+ 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 be
+ advertised across a trans-Atlantic link to North America. The
+ router in North America would then aggregate these routes, and
+ only advertise the prefix <194.0.0.0 255.0.0.0> into North
+ American routing. Packets which are destined for 194.1.1.1 would
+ traverse North American routing, but would encounter the North
+ American router which performed the European aggregation. If the
+ prefix <194.1.0.0 255.255.0.0> is unreachable, the router would
+ drop the packet and send an ICMP Unreachable without using the
+ trans-Atlantic link.
+
+5.8 Transition Issues
+
+ Allocation of IP addresses based on connectivity to TRDs is
+ important to allow scaling of inter-domain routing to an internet
+ containing millions of routing domains. However, such address
+ allocation based on topology implies that in order to maximize the
+ efficiency in routing gained by such allocation, certain changes
+ in topology may suggest a change of address.
+
+ Note that an address change need not happen immediately. A domain
+ which has changed service providers may still advertise its prefix
+ through its new service provider. Since upper levels in the
+ routing hierarchy will perform routing based on the longest
+ prefix, reachability is preserved, although the aggregation and
+ scalability of the routing information has greatly diminished.
+ Thus, a domain which does change its topology should change
+ addresses as soon as convenient. The timing and mechanics of such
+ changes must be the result of agreements between the old service
+ 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 basic
+ notion of routing data abstraction is that there is some
+ correspondence between the address and where a system (i.e., a
+ routing domain, subnetwork, or end system) is located. Thus if the
+ system moves, in some cases the address will have to change. If it
+
+
+
+Rekhter & Li [Page 19]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ were possible to change the connectivity between routing domains
+ without changing the addresses, then it would clearly be necessary
+ to keep track of the location of that routing domain on an
+ individual basis.
+
+ In the short term, due to the rapid growth and increased
+ commercialization of the Internet, it is possible that the
+ topology may be relatively volatile. This implies that planning
+ for address transition is very important. Fortunately, there are a
+ number of steps which can be taken to help ease the effort
+ required for address transition. A complete description of address
+ transition issues is outside of the scope of this paper. However,
+ a very brief outline of some transition issues is contained in
+ this section.
+
+ Also note that the possible requirement to transition addresses
+ based on changes in topology imply that it is valuable to
+ anticipate the future topology changes before finalizing a plan
+ for address allocation. For example, in the case of a routing
+ domain which is initially single-homed, but which is expecting to
+ become multi-homed in the future, it may be advantageous to assign
+ IP addresses based on the anticipated future topology.
+
+ In general, it will not be practical to transition the IP
+ addresses assigned to a routing domain in an instantaneous "change
+ the address at midnight" manner. Instead, a gradual transition is
+ required in which both the old and the new addresses will remain
+ valid for a limited period of time. During the transition period,
+ both the old and new addresses are accepted by the end systems in
+ the routing domain, and both old and new addresses must result in
+ correct routing of packets to the destination.
+
+ During the transition period, it is important that packets using
+ the old address be forwarded correctly, even when the topology has
+ changed. This is facilitated by the use of "longest match"
+ inter-domain routing.
+
+ For example, suppose that the XYZ Corporation was previously
+ connected only to the NorthSouthNet regional. The XYZ Corporation
+ therefore went off to the NorthSouthNet administration and got an
+ IP address prefix assignment based on the IP address prefix value
+ assigned to the NorthSouthNet regional. However, for a variety of
+ reasons, the XYZ Corporation decided to terminate its association
+ with the NorthSouthNet, and instead connect directly to the
+ NewCommercialNet public data network. Thus the XYZ Corporation now
+ has a new address assignment under the IP address prefix assigned
+ to the NewCommercialNet. The old address for the XYZ Corporation
+ would seem to imply that traffic for the XYZ Corporation should be
+
+
+
+Rekhter & Li [Page 20]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ routed to the NorthSouthNet, which no longer has any direct
+ connection with XYZ Corporation.
+
+ If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet)
+ are adjacent and cooperative, then this transition is easy to
+ accomplish. In this case, packets routed to the XYZ Corporation
+ using the old address assignment could be routed to the
+ NorthSouthNet, which would directly forward them to the
+ NewCommercialNet, which would in turn forward them to XYZ
+ Corporation. In this case only NorthSouthNet and NewCommercialNet
+ need be aware of the fact that the old address refers to a
+ destination which is no longer directly attached to NorthSouthNet.
+
+ If the old TRD and the new TRD are not adjacent, then the
+ situation is a bit more complex, but there are still several
+ possible ways to forward traffic correctly.
+
+ If the old TRD and the new TRD are themselves connected by other
+ cooperative transit routing domains, then these intermediate
+ domains may agree to forward traffic for XYZ correctly. For
+ example, suppose that NorthSouthNet and NewCommercialNet are not
+ directly connected, but that they are both directly connected to
+ the BBNet backbone. In this case, all three of NorthSouthNet,
+ NewCommercialNet, and the BBNet backbone would need to maintain a
+ special entry for XYZ corporation so that traffic to XYZ using the
+ old address allocation would be forwarded via NewCommercialNet.
+ However, other routing domains would not need to be aware of the
+ 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 XYZ
+ Corporation in order to deliver such packets to the correct
+ backbone.
+
+ Also, those locations which do a significant amount of business
+ with XYZ Corporation could have a specific entry in their routing
+ tables added to ensure optimal routing of packets to XYZ. For
+ example, suppose that another commercial backbone
+ "OldCommercialNet" has a large number of customers which exchange
+ traffic with XYZ Corporation, and that this third TRD is directly
+ connected to both NorthSouthNet and NewCommercialNet. In this case
+ OldCommercialNet will continue to have a single entry in its
+ routing tables for other traffic destined for NorthSouthNet, but
+ may choose to add one additional (more specific) entry to ensure
+ that packets sent to XYZ Corporation's old address are routed
+ correctly.
+
+
+
+
+Rekhter & Li [Page 21]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ Whichever method is used to ease address transition, the goal is
+ that knowledge relating XYZ to its old address that is held
+ throughout the global internet would eventually be replaced with
+ the new information. It is reasonable to expect this to take
+ weeks or months and will be accomplished through the distributed
+ directory system. Discussion of the directory, along with other
+ address transition techniques such as automatically informing the
+ source of a changed address, are outside the scope of this paper.
+
+ Another significant transition difficulty is the establishment of
+ appropriate addressing authorities. In order not to delay the
+ deployment of this addressing scheme, if no authority has been
+ created at an appropriate level, a higher level authority may
+ allocated addresses instead of the lower level authority. For
+ example, suppose that the continental authority has been allocated
+ a portion of the address space and that the service providers
+ present on that continent are clear, but have not yet established
+ their addressing authority. The continental authority may foresee
+ (possibly with information from the provider) that the provider
+ will eventually create an authority. The continental authority
+ may then act on behalf of that provider until the provider is
+ prepared to assume its addressing authority duties.
+
+ Finally, it is important to emphasize, that a change of addresses
+ due to changes in topology is not mandated by this document. The
+ continental level addressing hierarchy, as discussed in Section
+ 5.7, is intended to handle the aggregation of reachability
+ information in the cases where addresses do not directly reflect
+ the connectivity between providers and subscribers.
+
+5.9 Interaction with Policy Routing
+
+ We assume that any inter-domain routing protocol will have
+ difficulty trying to aggregate multiple destinations with
+ dissimilar policies. At the same time, the ability to aggregate
+ routing information while not violating routing policies is
+ essential. Therefore, we suggest that address allocation
+ authorities attempt to allocate addresses so that aggregates of
+ destinations with similar policies can be easily formed.
+
+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.
+
+7. Acknowledgments
+
+ The authors would like to acknowledge the substantial contributions
+ made by the authors of RFC 1237 [2], Richard Colella, Ella Gardner,
+ and Ross Callon. The significant concepts (and a large portion of
+ the text) in this document are taken directly from their work.
+
+ The authors would like to acknowledge the substantial contributions
+ made by the members of the following two groups, the Federal
+ Engineering Planning Group (FEPG) and the International Engineering
+ Planning Group (IEPG). This document also reflects many concepts
+ expressed at the IETF Addressing BOF which took place in Cambridge,
+ MA in July 1992.
+
+ We would also like to thank Peter Ford (Los Alamos National
+ Laboratory), Elise Gerich (MERIT), Steve Kent (BBN), Barry Leiner
+ (ADS), Jon Postel (ISI), Bernhard Stockman (NORDUNET/SUNET), Claudio
+
+
+
+Rekhter & Li [Page 25]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+ Topolcic (CNRI), and Kannan Varadhan (OARnet) for their review and
+ constructive comments.
+
+8. References
+
+ [1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
+ Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
+ cicso, Merit, OARnet, June 1992.
+
+ [2] Colella, R., Gardner, E, and R. Callon, "Guidelines for OSI NSAP
+ Allocation in the Internet", RFC 1237, JuNIST, Mitre, DEC, July
+ 1991.
+
+ [3] Gerich, E., "Guidelines for Management of IP Address Space", RFC
+ 1466, Merit, May 1993.
+
+ [4] Cerf, V., "IAB Recommended Policy on Distributing Internet
+ Identifier Assignment and IAB Recommended Policy Change to
+ Internet "Connected" Status", RFC 1174, CNRI, August 1990.
+
+9. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 26]
+
+RFC 1518 CIDR Address Allocation Architecture September 1993
+
+
+10. Authors' Addresses
+
+ Yakov Rekhter
+ T.J. Watson Research Center, IBM Corporation
+ P.O. Box 218
+ Yorktown Heights, NY 10598
+
+ Phone: (914) 945-3896
+ EMail: yakov@watson.ibm.com
+
+
+ Tony Li
+ cisco Systems, Inc.
+ 1525 O'Brien Drive
+ Menlo Park, CA 94025
+
+ EMail: tli@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Li [Page 27]
+ \ No newline at end of file