RFC 1518

An Architecture for IP Address Allocation with CIDR

📅 published September 1993, from ietf

An Architecture for IP Address Allocation with CIDR 💖

Okay bestie, let's start with the vibe check ✨. This is RFC 1518, from the Network Working Group, and it's titled "An Architecture for IP Address Allocation with CIDR." It was written by Y. Rekhter of the T.J. Watson Research Center, IBM Corp., and T. Li of cisco Systems, who are both listed as the editors. It's a Standards Track doc dated September 1993, and its header doesn't list any RFCs it obsoletes or updates 🎀.

Status of this Memo

Okay so this RFC is an Internet standards track protocol 🧚 for the whole Internet community, and it's literally asking for discussion and suggestions to make it better 🙏. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" 📚. And the best part? Distribution of this memo is unlimited 💅.

1. Introduction ✨

So this paper gives us an architecture and a plan for allocating IP addresses across the Internet 🌸. It's meant to play a big role in steering the Internet toward the Address Assignment and Aggregating Strategy outlined in [1]. Main character energy 👑.

The IP address space is a scarce shared resource that must be managed for the good of the community 🫶. The people managing it are basically its custodians, and they have a responsibility to the community to manage it for the common good. Not me being responsible for literally everyone 😭.

2. Scope 🦋

Picture the global Internet as a collection of hosts connected through transmission and switching facilities 🌐. Control over all of that isn't homogeneous at all. It's split up among multiple administrative authorities. Resources under one administration form a domain. For the rest of this paper, "domain" and "routing domain" are used interchangeably, so don't get confused, bestie 💕. Domains that share their resources with other domains are called network service providers (or just providers), and domains that use other domains' resources are called network service subscribers (or just subscribers). A given domain can be a provider and a subscriber at the same time, iconic 👑.

There are two aspects of IP address allocation that matter. The first is the set of administrative requirements for getting and allocating IP addresses. The second is the technical side, which is mostly about routing, both inside a routing domain (intra-domain routing) and between routing domains (inter-domain routing). This paper focuses on the technical issues 🧠.

In today's Internet, lots of routing domains (like corporate and campus networks) connect to transit networks (like regionals) through 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 here are intended for immediate deployment 🚀. This paper specifically does not address long-term research issues, like complex policy-based routing requirements 🙅. Addressing solutions that require substantial changes or constraints on the current topology aren't considered either.

The architecture and recommendations 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's noted that there are other aspects of IP address allocation, both technical and administrative, that this paper doesn't cover. Topics not covered, or only mentioned superficially, include:

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 info is provided in this section, and it's super helpful for understanding the issues involved in IP address allocation. There's also a brief discussion of IP routing 🧩.

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 plus some indication of the leftmost contiguous significant bits within that address 🎀. Throughout the paper, IP address prefixes are expressed as <IP-address IP-mask> tuples. 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 you're determining an administrative policy for IP address assignment, it's important to understand the technical consequences 🤔. The whole objective behind hierarchical routing is to achieve some level of routing data abstraction, or summarization, so less cpu, memory, and transmission bandwidth gets consumed in support of routing 💀.

Routing data abstraction can be applied to various types of routing information, but this paper focuses on one particular type: 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, so the requirements of the two may collide. It's 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 that 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's 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 reachability information abstraction beyond what 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's an opportunity for a group of routing domains to each 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 now has its (somewhat longer) prefix, from which it assigns its addresses 🧚.

The most straightforward case of this occurs when there's a set of routing domains that are all attached to a single service provider domain (e.g., regional network), and that 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 💖

okay so, if the Internet wants to support decentralized address administration [4], then we need a balance ⚖️ between what IP addresses have to do for efficient routing and the need for decentralized address administration. A proposal described in [3] gives an example of how these two needs might both get met ✨

The IP address prefix <198.0.0.0 254.0.0.0> is giving administrative decentralization 🌸. This prefix identifies part of the IP address space allocated for North America. The lower order part of that prefix lets you allocate IP addresses along topological boundaries, which supports increased data abstraction 🧚. Clients within North America use parts of the IP address space that sit underneath the IP address space of their service providers. Within a routing domain, addresses for subnetworks and hosts get allocated from the unique IP prefix assigned to that 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.

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 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 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 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 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 🔥.

Okay so direct providers can hand out chunks of their own address space (prefixes 🎀) to leaf domains, as long as those chunks come from the one prefix the provider was given. Bestie, this is giving major efficiency ✨. Instead of announcing every single prefix in every leaf routing domain to the backbones, the provider only has to announce a tiny handful, and that's a huge savings once the global internet gets as big as everyone expects 🌈.

Are leaf routing domains actually willing to take prefixes from their direct provider? 🤔 In the supplier/consumer model, the direct provider sells connectivity as its service, priced based on what it costs to run. That price includes what the provider pays for service from one or more indirect providers (like backbones). Indirect providers want to handle as few address prefixes as possible so their costs stay low 💅. The Internet doesn't work like a normal marketplace, though, so leaf routing domains have to be considerate of the resource limits of their providers, both direct and indirect 🫶. The routing efficiencies are so good that using prefixes derived from the providers' address space is totally worth it 🔥.

The mechanics are super simple. Each direct provider gets a unique small set of IP address prefixes, and its attached leaf routing domains can then allocate slightly longer prefixes out of that set. For example, say NIST is a leaf routing domain whose inter-domain link goes through SURANet. If SURANet is assigned the unique IP address prefix <198.1.0.0 255.255.0.0>, NIST could use the unique IP prefix <198.1.0.0 255.255.240.0> 💖.

Now, if a direct service provider is connected to other providers (direct or indirect) through multiple attachment points, it may sometimes be useful for the direct provider to have some control over how those attachment points connect to the traffic going to a particular subscriber 🎯. That control gets a lot easier if the provider first sorts all of its subscribers into groups, so that traffic for every subscriber in a group flows through one particular attachment point. Once the groups are set, the provider's address space gets split along those group boundaries. A leaf routing domain that is willing to take prefixes from its direct provider gets a prefix from the piece of the address space that belongs to its group 🧚. Be careful here, though: when the direct provider advertises the routing information for each piece, it should not cause that information to spread globally as separate reachability entries for each piece, unless there's some other reason for it to go global, like supporting certain parts of policy-based routing 🦋.

5.3.2. Indirect Providers (Backbones) 🌸

There doesn't seem to be a strong case for direct providers to take their address space from an indirect provider's space, like a backbone's 🙈. The benefit in routing data abstraction is pretty small. There are only tens of direct providers today, and doing an order of magnitude more wouldn't put an undue burden on the backbones. Also, as time goes on, the direct providers are likely to interconnect more directly with each other, leaf routing domains may attach straight to the backbones, and international links may attach directly to the providers. When all that happens, the line between direct and indirect providers could get blurry 🌀.

Another reason to avoid handing out addresses from a backbone prefix is that backbones and their attached providers are seen as independent of each other. Providers can take their long-haul service from one or more backbones, or switch backbones if somewhere else offers a better deal 💅. Having IP addresses that come from a backbone just doesn't match that kind of relationship 😭.

5.4. Multi-homed Routing Domains 🍓

The discussions in Section 5.3 lay out ways to allocate IP addresses based on direct or indirect provider connectivity ✨. This gives a ton of information reduction for routing domains attached to a single TRD 🎀. Those routing domains can pick their IP addresses from a space that the direct provider delegated to them. That means the provider, when it announces the addresses it can reach to other providers, can use a single address prefix to describe a big pile of IP addresses across multiple routing domains 👑.

Routing domains attached to multiple providers come with extra considerations, though 🫣. These "multi-homed" routing domains could be things like single-site campuses and companies attached to multiple backbones, big organizations attached to different providers at different locations in the same country, or multinational organizations attached to backbones in a bunch of different countries around the world 🌍. There are a few possible ways to handle these multi-homed routing domains.

One option is for each multi-homed organization to get its IP address space independently from the providers it's attached to 💜. That lets the organization base all of its IP assignments on one prefix, so every IP address reachable inside it can be summarized under a single prefix. The downside is that since the organization's addresses have no relationship to any particular TRD, the TRDs it's attached to will need to advertise that organization's prefix to other providers. Other providers, potentially all over the world, will need to keep an explicit entry for that organization in their routing tables 😬.

Here's an example. Suppose a super big North American company, "Mega Big International Incorporated" (MBII), has a fully interconnected internal network and gets assigned a single prefix as part of the North American prefix 💼. Outside of North America, a single routing table entry could probably cover all North American destinations. Inside North America, though, every provider would need its own separate address entry for MBII 🥺. If MBII is actually an international corporation, then every provider worldwide might need a separate entry for MBII, including backbones that MBII isn't even attached to. That's probably fine if there are only a few multi-homed routing domains like this, but it would put an unacceptable load on the routers inside the backbones if every organization picked this kind of address assignment. This approach may not scale to internets with many hundreds of thousands of multi-homed organizations 📉.

A second option is for each multi-homed organization to get a separate IP address space for each of its connections to a TRD, and then assign a single prefix to some subset of its domains based on the closest interconnection point 🗺️. For example, if MBII had connections to two providers in the U.S. (one on the east coast and one on the west coast), three connections to national backbones in Europe, and one in the far east, then MBII could use six different address prefixes 🔥. Each part of MBII would get one address prefix based on its nearest connection.

For routing traffic from outside MBII to a destination inside MBII, this approach works kind of like treating MBII as six separate organizations 🧩. For routing inside MBII, or for routing traffic from inside MBII to a destination outside it, this approach works the same as the first solution 🔁.

If we assume that incoming traffic (coming from outside MBII with a destination inside MBII) always enters at the point nearest to the destination, then each TRD that has a connection to MBII only needs to announce to other TRDs that it can reach the parts of MBII whose addresses come from its own address space 📡. That means no extra routing information has to be swapped between TRDs, so the inter-domain routing tables that TRDs maintain stay smaller than they would be under the first solution. That's why this solution scales better to extremely large internets with very large numbers of multi-homed organizations 💪.

One problem with the second solution is that backup routes to multi-homed organizations aren't automatically maintained 😩. With the first solution, each TRD announcing its ability to reach MBII says it can reach all of the hosts inside MBII. With the second solution, each TRD announces that it can reach all of the hosts based on its own address prefix, and that prefix only covers some of the hosts inside MBII. If the connection between MBII and one particular TRD were cut, then the hosts inside MBII whose addresses come from that TRD would become unreachable through inter-domain routing 💀. You can reduce the impact of this somewhat by keeping extra information in the routing tables, but that cuts into the scaling advantage of the second approach 🥀.

The second solution also requires that internal addresses change whenever external connectivity changes 🙃.

Also, note that this approach and the previous one will tend to make packets take different routes 🛣️. With the first approach, packets from outside MBII headed to MBII will tend to enter at the point closest to the source, which tends to maximize the load on the networks inside MBII. With the second solution, packets from outside headed to MBII will tend to enter at the point closest to the destination, which tends to minimize the load on the networks inside MBII and maximize the load on the TRDs 🫶.

These solutions also hit policies differently, bestie 💅 Say country "X" has a law that traffic from a source inside country X to a destination inside country X has to stay entirely within the country at all times 🌍. With the first solution, you literally can't tell from the destination address whether it's inside the country 🙈. With the second solution, hosts inside country X get their own separate address, so routing policies can actually be followed 🧭. Same energy with "Little Small Company" (LSC), which has a policy that its packets may never be sent to a destination inside MBII 🚫. With either solution, the routers inside LSC may be configured to discard anything headed for MBII's address space. But with the first solution that's one entry, and with the second it's many entries and might be impossible in practice 😭.

There are other possible solutions too 🦋 A third approach is to give each multi-homed organization a single address prefix, based on one of its connections to a TRD. The other TRDs the multi-homed organization is attached to keep a routing table entry for it, but they're extremely selective about which other TRDs get told about this route 🤫. This approach produces a single "default" routing entry that all TRDs know how to reach (since presumably all TRDs maintain routes to each other), while still giving more direct routing in some cases ✨.

There's at least one situation where this third approach is especially giving 🎀 Imagine a special interest group of organizations that have deployed their own backbone. Let's say the U.S. National Widget Manufacturers and Researchers set up a U.S.-wide backbone, used by corporations that make widgets and certain universities known for their widget research 🔧. The organizations 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 widget folks are also into other stuff 💀). So we can expect many or most of the widget group orgs to be dual-homed, with one attachment for widget-related communications and the other for everything else 👑. Let's also assume the total number of organizations in the widget group is small enough that keeping a routing table with one entry per organization is reasonable, but they're scattered through a bigger internet with many millions of (mostly non-widget) routing domains 🌈.

With the third approach, each multi-homed organization in the widget group uses an address assignment based on its other attachment(s) to TRDs (the ones not tied to the widget group) 🧚. The widget backbone needs to keep routes to the routing domains of the various member organizations. Similarly, every member of the widget group needs a table of routes to the other members via the widget backbone 🫶. But since the widget backbone doesn't tell other general worldwide TRDs what addresses it can reach (because it isn't meant for use by other outside organizations), that relatively large set of routing prefixes only needs to live in a limited number of places 🤐. The addresses given to the widget group members provide a "default route" via each member's other attachments to TRDs, while letting communications within the widget group take the preferred path 🛤️. Main character energy, honestly ✨.

A fourth solution involves assigning a particular address prefix to routing domains that are attached to precisely two (or more) specific routing domains 🍓. For example, say there are two providers, "SouthNorthNet" and "NorthSouthNet", that have a very large number of customers in common (i.e., a large number of routing domains attached to both). Instead of getting two address prefixes, these organizations could obtain three prefixes 🔢. Routing domains attached to NorthSouthNet but not to SouthNorthNet get an address assignment based on the first prefix. Routing domains attached to SouthNorthNet but not to NorthSouthNet get an address based on the second prefix. And routing domains multi-homed to both networks get an address based on the third prefix 💜. Each of these two TRDs would then advertise two prefixes to other TRDs: one for leaf routing domains attached only to it, and one for leaf routing domains attached to both 📣.

This fourth solution is likely to matter a lot once use of public data networks becomes more common 📡. In particular, it's likely that at some point in the future a substantial percentage of all routing domains will be attached to public data networks. In that case, nearly all government-sponsored networks (like some current regionals) may have a set of customers that overlaps heavily with the public networks 😳.

So there are a bunch of possible solutions to the problem of assigning IP addresses to multi-homed routing domains 🌸. Each one has really different advantages and disadvantages. Each solution puts a different real (i.e., financial) cost on the multi-homed organizations, and on the TRDs (including the ones the multi-homed organizations are not attached to) 💸.

Also, most of the solutions described highlight the need for each TRD to develop a policy on whether and under what conditions to accept addresses that aren't based on its own address prefix, and how those non-local addresses will get treated 🧐. For example, a somewhat conservative policy might be that non-local IP address prefixes are 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 share something in common, like geographical location, or the result of an agreement specific to the requesting leaf routing domain) 🤝. Various policies come with real costs to TRDs, and those costs may be reflected in the policies themselves 💅.

5.5 Private Links 🔗

The discussion up to this point focuses 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 can also be a bunch of links that interconnect two routing domains in such a way that usage of those links may be limited to carrying traffic only between the two routing domains 🔐. We'll call these links "private" 🤫.

For example, let's say 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. This link may only be used for packets whose source is inside one of the two corporations and whose destination is inside the other one 🎀. Now suppose the point-to-point link connects a single router (router X) inside the XYZ corporation with a single router (router M) inside MBII. That means router X has to be configured to know which addresses can be reached over this link (specifically, all addresses reachable in MBII). Similarly, router M has to be configured to know which addresses can be reached over this link (specifically, all addresses reachable in XYZ Corporation) 🛠️.

The important thing to notice here is that the extra connectivity from private links like this may be ignored for the purpose of IP address allocation, and doesn't pose a problem for routing 🙌. That's because the routing information tied to this connectivity isn't propagated throughout the Internet, so it doesn't need to be collapsed into a TRD's prefix 🧠.

Back to our example 🍭. Suppose the XYZ corporation has a single connection to a regional, so it uses IP address space from the space given to that regional. Likewise, suppose 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 (which means 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 (which means router X needs to be configured with six address prefixes to represent the addresses reachable over the link) 📋.

In some cases, private links may be permitted to forward traffic for a small number of other routing domains, such as closely affiliated organizations 👯. This increases the configuration requirements slightly. But as long as the number of organizations using the link is relatively small, this still isn't a significant problem 👍.

Note that the relationship between routing and IP addressing described in the other sections of this paper is concerned with scaling problems caused by large, essentially public transit routing domains that interconnect a large number of routing domains 📈. For the purpose of IP address allocation, though, private links that interconnect only a small number of private routing domains don't pose a problem, and can be ignored 🙈. For example, this means a single leaf routing domain that 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 this is also another way of dealing with multi-homed domains 💖.

5.6 Zero-Homed Routing Domains 🌙

Right now, a very large number of organizations have internal communications networks that aren't connected to any service providers 🏢. These organizations may still have a number of private links they use to communicate with other organizations 🔗. Such organizations don't take part in global routing, but they're happy with reachability to the organizations they've set up private links with 🥰. These are referred to as zero-homed routing domains 🦋.

Okay so zero-homed routing domains are basically the degenerate case of routing domains with private links 🧚, which we just covered in the previous section. They do not pose a problem for inter-domain routing 💅. The routing info exchanged across those private links only gets passed around super locally, usually just to the routing domain at the other end of the link 🌸. So there are no address abstraction requirements beyond the ones that come with the address prefixes exchanged across that private link ✨.

But ngl, it is important that zero-homed routing domains use valid globally unique IP addresses 🚨. Picture this: the zero-homed routing domain is hooked up through a private link to a routing domain, and that routing domain is part of an internet that follows the global IP addressing plan 🌈. That routing domain must be able to tell the difference between the zero-homed domain's IP addresses and any other IP addresses it may need to route to 👀. The only way to guarantee that is if the zero-homed routing domain uses globally unique IP addresses 💖.

5.7. Continental aggregation 🌍✨

Okay, another level of hierarchy may also be used in this addressing scheme 🦋 to cut down even more on the routing info needed for inter-continental routing 💅. Continental aggregation is lowkey so useful because continental boundaries are natural barriers to topological connection and administrative boundaries 🧱. That makes them a natural spot for another level of aggregation of inter-domain routing information 💜. To make this work, it is necessary that each continent gets an appropriate subset of the address space 🎀. Providers (both direct and indirect) within that continent then allocate their addresses from that space 🧚. Note that there are numerous exceptions, though, where a service provider (either direct or indirect) spans a continental division 🙈. Those exceptions can be handled similarly to multi-homed routing domains, as discussed above 🫶.

Note that, unlike providers, the aggregation of continental routing information may not be done on the continent to which the prefix is allocated 👀. Why? The cost of inter-continental links (and especially trans-oceanic links) is very high 💸. If aggregation happens on the "near" side of the link, then routing info about unreachable destinations within that continent can only live on that continent 🏝️. But if continental aggregation is done on the "far" side of an inter-continental link, the "far" end can do the aggregation and inject it into continental routing 🚀. That means destinations that are part of the continental aggregation, but that don't have a corresponding more specific prefix, can be rejected before leaving the continent they originated on 🙅‍♀️.

For example, suppose Europe is assigned a prefix of <194.0.0.0 254.0.0.0>, so 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 destined for 194.1.1.1 would traverse North American routing, but would hit the North American router that did the European aggregation 🧐. If the prefix <194.1.0.0 255.255.0.0> is unreachable, that router would drop the packet and send an ICMP Unreachable without using the trans-Atlantic link 💀.

5.8. Transition Issues 🦋🌈

Allocating IP addresses based on connectivity to TRDs is important 🔥, because it lets inter-domain routing scale to an internet containing millions of routing domains 📈. However, address allocation based on topology implies that, to get the most routing efficiency out of it, certain changes in topology may suggest a change of address 🫠.

Note that an address change need not happen immediately 🙌. A domain that has changed service providers may still advertise its prefix through its new service provider 📮. Since upper levels in the routing hierarchy perform routing based on the longest prefix, reachability is preserved 🫶. The aggregation and scalability of the routing info has greatly diminished, though 😭. So a domain that 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 is that there is some correspondence between the address and where a system (i.e., a routing domain, subnetwork, or end system) is located 🗺️. So if the system moves, the address will in some cases have to change 🚚. If it 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, the topology may be relatively volatile, thanks to the rapid growth and increased commercialization of the Internet 📶. That means planning for address transition is very important 📋. Fortunately, there are a number of steps that can help ease the effort required for address transition 🧹. A complete description of address transition issues is outside the scope of this paper 🙃. A very brief outline of some transition issues is contained in this section, though ✨.

Also note that the possible requirement to transition addresses based on changes in topology implies that it is valuable to anticipate future topology changes before finalizing a plan for address allocation 🔮. For example, a routing domain that is initially single-homed but expects to become multi-homed in the future may find it 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 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 made possible by the use of "longest match" inter-domain routing 💜.

For example, suppose 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 end its association with the NorthSouthNet and instead connect directly to the NewCommercialNet public data network 💅. Now the XYZ Corporation 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 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 📨. Only NorthSouthNet and NewCommercialNet need be aware that the old address refers to a destination no longer directly attached to NorthSouthNet 🤫.

If the old TRD and the new TRD are not adjacent, 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 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 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, locations that do a significant amount of business with XYZ Corporation could have a specific entry added to their routing tables to ensure optimal routing of packets to XYZ 💼. For example, suppose another commercial backbone "OldCommercialNet" has a large number of customers that 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 🎯.

Whichever method is used to ease address transition, the goal is that the knowledge relating XYZ to its old address, which 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 it 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 big transition headache 😭 is figuring out who the addressing authorities even are. We don't want this whole scheme stuck waiting around, so if no authority has been set up at the right level yet, a higher level authority MAY allocate addresses instead of the lower one. Say the continental authority already has a chunk of the address space, and the service providers on that continent are clear but haven't set up their own addressing authority yet. The continental authority MAY foresee (maybe with some info from the provider) that the provider will eventually make one, and it MAY act on that provider's behalf until the provider is ready to take over its addressing authority duties. Main character patience 🦋.

And finally, this is super important bestie 🫶: a change of addresses because the topology changed is not mandated by this document 🙅‍♀️. The continental level addressing hierarchy from Section 5.7 is meant to handle aggregating reachability information for when addresses don't directly reflect the connectivity between providers and subscribers. It's giving "the map doesn't match the vibes, but we still got this" 🗺️✨.

5.9. Interaction with Policy Routing 🎀

Ngl, we're assuming any inter-domain routing protocol is gonna struggle when it tries to bundle up destinations with totally different policies 😩. BUT being able to aggregate routing info without breaking routing policies is literally essential 🔥. So we suggest address allocation authorities try to hand out addresses so that aggregates of destinations with similar policies can be easily formed 💖.

6. Recommendations 👑

The Internet is growing exponentially rn, and we expect that to keep going or even speed up 📈🚀. We also expect it to get super international 🌍. Routing can only scale if it uses data abstraction based on hierarchical IP addresses (this is the whole vibe). So as CIDR [1] rolls out, choosing a hierarchical structure for IP addresses is super important and needs real care 🎀.

It's giving "keep operating costs low where we can" 💸. For IP address allocation, that means routing data abstraction MUST be encouraged 🫶.

Bestie, for data abstraction to even work, IP address assignment MUST be accomplished in a way that matches the actual physical topology of the Internet 🗺️. Like, if organizational and administrative boundaries have nothing to do with the real network topology, then assigning addresses based on those org boundaries is NOT RECOMMENDED 🙅‍♀️.

Intra-domain routing protocols let you keep information abstraction inside a domain 🏠. For zero-homed and single-homed routing domains (the ones expected to stay zero-homed or single-homed 💅), we recommend that every IP address assigned inside a single routing domain use one address prefix assigned to that domain. Specifically, this means all the IP addresses reachable within one domain can be fully described with a single prefix 🎀.

We expect the total number of routing domains on a worldwide Internet to be so huge 🤯 that we'll need extra levels of hierarchical data abstraction beyond the routing domain level.

Usually network topology is super close to national boundaries 🌏. Connectivity is often way stronger inside one country than between countries, so it's totally appropriate to make specific recs based on national boundaries 💜. Just know there MAY be situations where these general recs 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,
a number of commercial Public Data Networks.

These networks won't be wired up in a strictly hierarchical way. Regionals are expected to connect directly to each other, and all of these types of networks MAY have direct international connections 🌐. But the total number of such TRDs is expected to remain small enough (for the foreseeable future) to address this set via a flat address space ✨. These TRDs will interconnect a wide variety of routing domains, and each one of those MAY comprise a single corporation, part of a corporation, a university campus, a government agency, or another organizational unit 🎓.

Some private corporations MAY be expected to make use of dedicated private TRDs for communication within their own corporation 🏢.

Most routing domains will be attached to just one TRD, which lets us aggregate addresses hierarchically based on TRD 🪄. So we strongly recommend assigning addresses hierarchically, based on address prefixes given to individual TRDs 💅.

To support aggregating routes at the continental level, we recommend that every address for a TRD that's wholly inside a continent comes from the continental prefix 🌎.

For the proposed scheme, this means portions of IP address space SHOULD be assigned to each TRD (and yes, that explicitly includes the backbones and regionals 🙌). For those leaf routing domains connected to a single TRD, they SHOULD be assigned a prefix value from the address space assigned to that TRD.

Routing domains that are NOT attached to any publicly available TRD don't have the same urgent need for hierarchical address abbreviation 🤷‍♀️. So we don't make any additional recommendations for such "isolated" routing domains 🏝️. And if they connect to other domains by private point-to-point links that are used solely for routing between the two domains they interconnect, that link doesn't cause any new technical problems for address abbreviation either. No specific additional recommendations are necessary 💖.

And to keep IP address aggregation at national and continental boundaries down to as few prefixes as possible 🧩, we further recommend that IP addresses given to routing domains SHOULD be assigned based on each routing domain's connectivity to national and continental Internet backbones 🌈.

6.2. Recommendations for Multi-Homed Routing Domains 🦋

There are several possible ways 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. On top of that, 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 packets follow, and MAY affect 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 administration 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 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 🚨

Heads up, bestie 🚨: security issues are not discussed in this memo. Not one word. Keep that in mind as you read 😭🔒.

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

📦 where this page comes from

ietf: rfc1518 1993-09
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms