From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1518.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc1518.txt (limited to 'doc/rfc/rfc1518.txt') 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 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 -- cgit v1.2.3