RFC 2008

Part 1 of 3 🎀

RFC 2008: Implications of Various Address Allocation Policies for Internet Routing 💖

Okay bestie, here's the title block tea ☕. This is RFC 2008, Network Working Group, and it's a Best Current Practice (that's the BCP 7 category 💅). Written by Y. Rekhter and T. Li from Cisco Systems, dated October 1996. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Status of this Memo 📜

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

IESG Note 🧠

Ngl this note is kind of the main character of the whole doc 👑. The addressing constraints described here are mostly the result of how existing router technology, address assignment, and architectural history all interact. After a ton of review and discussion, the authors, the working group, and the IESG concluded that there are no other technologies you could deploy right now to get around these limitations. If routing or router technology ever gets to the point where adequate aggregation can be achieved some other way, or routers can handle bigger and more dynamic routing tables, it might be time to look at these constraints again 🔥.

1 Abstract 🦋

IP unicast address allocation and management are essential operational functions for the Public Internet, no cap 🌈. The exact policies for doing this keep getting debated, and those debates can't happen in a vacuum 🙈. People have to actually understand the technical issues and what each allocation and management policy implies.

So the point of this document is to lay out the fundamental technical issues you have to think about when you're writing unicast address allocation and management policies for the Public Internet, and to give recommendations about those policies 🫶.

The main focus is on two possible policies, "address ownership" and "address lending," and what they mean technically for the Public Internet 💜. For organizations that can provide reachability to a big enough chunk of all the destinations on the Internet, and can express that reachability through one single IP address prefix, the document suggests using the "address ownership" policy. BUT applying "address ownership" to every single site or organization that connects to the Internet ends up being non-scalable routing, and that's not it 😭.

That's why this document also recommends that the "address lending" policy should be formally added to the set of address allocation policies for the Public Internet ✨. It also recommends that organizations that don't provide a sufficient degree of routing information aggregation, but still want access to Internet routing services, should be strongly encouraged to use this policy to get that access 🎀.

2 On the intrinsic value of IP addresses 💎

Syntactically, the set of IPv4 unicast addresses is the (finite) set of integers in the range 0x00000000 - 0xDFFFFFFF. IP addresses are used for Network Layer (IP) routing, and an IP address is the sole piece of information about the node that gets injected into the routing system 🧚.

The notable thing about an IP unicast address is that it can interact with the Public Internet routing service, and that's how you exchange data with the rest of the Internet. Basically, for the Public Internet, it's the reachability of an IP address that gives it its intrinsic value 💅. Still, IP addresses get used outside the Public Internet too, and this document doesn't cover what they're worth in those other contexts 🙈.

So in the Public Internet, it's the service environment (the Internet) and its continued operation, routing system included, that gives an IP address its intrinsic value, and not the other way around 🌸. That means if the Public Internet routing system stops working, the service disappears, and the addresses stop having any functional value on the Internet. At that point, for the Public Internet, every address allocation and management policy, existing ones included, is rendered meaningless 💀.

3 Hierarchical routing and its implication on address allocation 🌳

Hierarchical routing [Kleinrock 77] is a mechanism that improves the scaling properties of a routing system. It's literally the only proven mechanism for scaling routing to the current size of the Internet 👑.

Hierarchical routing requires that addresses be assigned to reflect the actual network topology. It works by taking the set of addresses covered by a portion of the topology and generating a single routing advertisement (route) for that whole set. And it's recursive, so multiple advertisements (routes) can get combined into one advertisement (route) ✨. Doing this recursion can cut down the amount of information needed to provide routing by a lot 🔥.

A super common example is the phone network 📞, where country codes, area codes, exchanges, and finally subscriber lines are the different levels in the hierarchy. A phone switch doesn't need detailed routing info about every possible subscriber in a faraway area code. Usually it just knows one routing entry for the whole area code 🦋.

The effect on scaling is honestly dramatic 😭. If you compare the space complexity of the different schemes, a switch that knows about every subscriber in the world needs O(n) space for n worldwide subscribers. With hierarchical routing, you can break n down into the number of subscribers in the local area (l), the other exchanges in the area code (e), the other area codes in the local country code (a), and the other country codes (c). Using that notation, hierarchical routing has space complexity O(l + e + a + c). Each of those factors is much, much less than n, and grows very slowly, if at all. So a phone switch can be built today that has some hope of not running out of space when it's deployed 🍓.

The fundamental property that makes this scalability possible is the ability to form abstractions. Here, that means grouping subscribers into exchanges, area codes, and country codes. And those abstractions have to be useful for routing. Some abstractions, like the group of users with green phones, aren't useful at all when it's time to route a call 🙈.

Since what the routing system really needs is the location of an address within the topology, the useful abstraction for hierarchical routing has to capture the topological location of an address within the network 🧭. In principle there are two ways to get that. Either (a) constrain the topology (and allowed topology changes) to match address assignment, or (b) avoid constraints on the topology (and topology changes), but require that as the topology changes, an entity's address changes as well. That process of changing an entity's address is known as "renumbering" 🔄.

4 Scaling the Internet routing system 📈

The enormous growth of the Public Internet puts a heavy load on the Internet routing system 🏋️‍♀️. Before CIDR was introduced, the growth rate had doubled the size of the routing table roughly every nine months. Computer technology capacity doubles roughly every 24 months. Even if we could double router capacities every 24 months, the size of the routing tables is inevitably going to exceed the limit of the routers 💀. So to keep the Public Internet growing without interruption, deploying mechanisms that contain the growth rate of routing information is essential 🫶.

Without mechanisms to contain the growth rate of routing information, the growth of the Internet would have to be limited or frozen, or the Internet routing system would get overloaded 😭. When routing gets overloaded, the routing subsystem fails. Either equipment (routers) can't keep enough routes to ensure global connectivity, or providers just exclude certain routes to make sure other routes still provide connectivity to particular sites. This document assumes that neither of those outcomes is acceptable 🙅‍♀️.

Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519] has been deployed in the Public Internet since late 1992 as the primary mechanism for containing the growth rate of routing information. Honestly, without CIDR the Internet routing system would've already collapsed 💥. For example, in October 1995, AlterNet (one of the major Internet Service Providers) had 3194 routes. Thanks to aggregation, AlterNet only advertised 799 routes to the rest of the Internet, a saving of 2395 routes (75%) [Partan 95] 🎉. Also in October 1995, the Internet Routing Registry (IRR) contained 61,430 unique prefixes listed, not counting prefixes marked as withdrawn (or 65,191 prefixes with prefixes marked as withdrawn). That's roughly a lower bound, since many prefixes aren't registered in the IRR 🤏. CIDR aggregation resulted in less than 30,000 routes in the default-free part of the Internet routing system [Villamizar 95] 🌈.

CIDR is an example of hierarchical routing in the Public Internet, where subnets, subscribers, and finally providers are some of the possible levels in the hierarchy 🪜. For example, a router within a site doesn't need detailed routing info about every possible host in that site. Instead, it keeps routing info on a per subnet basis. Likewise, a router within a provider doesn't need detailed routing info about individual subnets within its subscribers. It could instead keep routing info on a per subscriber basis. And a router within a provider doesn't need detailed routing info about stub (single home) subscribers of other providers either, because it can keep routing info on a per provider basis 💖.

Because of pre-CIDR address allocation, many routes in the Internet aren't suitable for hierarchical aggregation 🙃. Plus, there are unconnected sites with pre-CIDR address allocations out there. If those sites connect to the Internet at some point in the future, their routes are unlikely to be suitable for hierarchical aggregation either. And when a site uses addresses obtained from its provider, but then later switches to a different provider (while still using the same addresses), the route to that site may no longer be suitable for hierarchical aggregation 🧩.

Hierarchical routing requires that aggregation boundaries for the addressing information be formed along some hierarchy. So many exceptions are going to get injected into the routing system in the future, on top of the ones that already exist 😬. Every exception added to the routing system makes the routing system less scalable. How many exceptions can be tolerated depends on the technology used to support routing. Unbridled growth in the number of these exceptions will cause the routing system to collapse 🚨.

5. Address allocation and management policies 🎀

okay so this section is the big drama, bestie 💅 address allocation and management policy is seriously complicated and multifaceted. it covers who writes the policies, who actually carries them out, what the registries do, what the different orgs do (ISOC, IAB, IESG, IETF, IEPG, various government bodies, etc.), whether end users get to take part in requesting addresses, and so much more 🙈 the wild part is that allocation and routing scalability are literally interrelated. only certain allocation policies give you scalable routing 😭 and the Internet routing system has both technological and fundamental constraints, so those constraints cut down which allocation policies are even practical 💀

5.1. The "address ownership" allocation policy and its implications on the Public Internet

"address ownership" is one possible allocation and management policy 🦋 it means that once a chunk of address space is given to an org, it stays allocated to that org for as long as the org wants it, and no other org gets that chunk. these are often called "portable" addresses. the assumption was that an org with addresses from this policy could use them to get Internet routing services no matter where it connects to the Internet 🌸

nobody ever officially said that the Internet Registries use the "address ownership" policy, but it's always been assumed (and practiced) 👀

so to figure out what "address ownership" ("portable" addresses) does to routing scalability, you gotta look at two things:

• (a) by definition, address ownership means addresses fall under the assignee's control once assigned. the assignee is the one who decides when to give up ownership (though stuff can influence that decision). specifically, the assignee is not required (but may be influenced) to give up ownership as its connectivity to the Internet changes.
• (b) by definition, hierarchical routing assumes that addresses reflect the network topology as much as possible.

so the only practical way we currently know to get both scalable hierarchical routing and address ownership for everyone is to assume the topology (or at least certain pieces of it) will be permanently fixed 😬 but the Internet is distributed, decentralized, largely unregulated, and global (international), so locking down the topology (or even parts of it) could have broad technical, social, economical, and political implications. nobody really knows what those implications are yet, and even less is known about whether they'd be acceptable (feasible) in practice. so for now, we have to support an Internet with an unconstrained topology (and unconstrained topological changes) 🫶

since the Internet doesn't constrain its topology (or allowed topology changes), we can either have address ownership for everyone or a routable Internet, but not both 💀 or we need to develop and deploy new mechanisms (e.g., decoupling the address owned by end users from the ones used by Internet routing, and providing mechanisms to translate between the two) ✨ without new mechanisms, if we have address ownership ("portable" addresses) for everyone, the routing overhead will lead to a breakdown of the routing system, resulting in a fragmented (partitioned) Internet. alternately, we can have a routable Internet, but without address ownership ("portable" addresses) for everyone 🌈

5.2. The "address lending" allocation policy and its implications for the Public Internet

recently, especially since the arrival of CIDR, some subscribers and providers have followed a model where address space isn't owned (not portable), but is bound to the topology 🧚 this model suggests an allocation and management policy that's different from "address ownership." the following describes a policy called "address lending," which gives a better match to the model.

an "address lending" policy means an org gets its addresses on a "loan" basis 🎀 for the length of the loan, the lender can't lend those addresses to any other borrower. assignments and allocations based on "address lending" should explicitly include the loan conditions. those conditions must specify that allocations are returned if the borrower is no longer contractually bound to the lender, and the lender can no longer provide aggregation for the allocation. if a loan ends, the org can no longer use the borrowed addresses, so it has to get new addresses and renumber 😭 the "address lending" policy doesn't constrain how the new addresses could be acquired.

this document expects that "address lending" would be used primarily by Internet Registries associated with providers, but it doesn't preclude use by an Internet Registry that isn't associated with a provider 💅

this document expects that when a provider-associated Internet Registry uses "address lending," the provider is responsible for arranging aggregation of these addresses to a degree that's sufficient to achieve Internet-wide IP connectivity 🫶

this document also expects that when a provider-associated Internet Registry uses "address lending," the loan terms would be coupled to the service agreement between the provider and the subscribers. that means if the subscriber moves to another provider, the loan gets canceled 🙈

to reduce disruptions when a subscriber changes providers, this document strongly recommends that the loan terms include a grace period 💖 this would let a subscriber that disconnects from its provider keep using its loan addresses for a certain grace period after the disconnection. during this grace period, the borrower (the subscriber) may continue to use the addresses obtained under the loan. this document recommends a grace period of at least 30 days. but to contain the routing information overhead, it suggests that a grace period be no longer than six months ⏳

to see the scalability implications of "address lending," notice that if a subscriber borrows its addresses from its provider's block, the provider can advertise a single address prefix ✨ that cuts down the routing information the Internet routing system has to carry (for more info, check Section 5.3.1 of RFC1518). as the subscriber changes providers, the loan from the old provider gets returned and a loan from the new provider gets established, so the subscriber renumbers to the new addresses. once the subscriber renumbers into the new provider's existing blocks, no new routes need to be introduced into the routing system 🦋

so "address lending," if applied appropriately, is consistent with the constraints hierarchical routing puts on allocation policies, and it promotes a scalable routing system 🌟 it could play an important role in enabling the continuous, uninterrupted growth of the Internet 🚀

to scale routing in other parts of the hierarchy, the "lending" policy may also be applied hierarchically, so addresses can be lent to other orgs in turn 🧚 the implication is that the end of a single loan may affect orgs that recursively borrowed parts of the address space from the main allocation. in that case, the exact effects are difficult to determine a priori 😵

5.3. In the absence of an explicit "address lending" policy

orgs connecting to the Internet should be aware that even if their current provider, and the provider they switch to in the future, don't require renumbering, renumbering may still be needed to achieve Internet-wide IP connectivity 👀 for example, an org might now get Internet service from a provider and allocate its addresses out of that provider's CIDR block. later, the org may switch to another provider. the previous provider may still be willing to let the org keep part of the provider's CIDR block and accept a more specific prefix for that org from the new provider 🎀 likewise, the new provider may be willing to accept that org without renumbering and advertise the more specific prefix (covering destinations within the org) to the rest of the Internet. however, if one or more other providers exist that are unwilling or unable to accept the longer prefix advertised by the new provider, then the org won't have IP connectivity to part of the Internet 😭 among the solutions open to the org: either renumber, or have others acquire connectivity to providers that are willing and able to accept the prefix.

the above shows that the absence of an explicit "address lending" policy from a current provider in no way ensures that renumbering won't be required in the future when changing providers 🙅 orgs should be aware of this fact should they encounter a provider making claims to the contrary.

6 Recommendations ✨

okay bestie, so the goal of hierarchical routing on the Internet is NOT to shrink the routing info down to the theoretical minimum 🙈. It's just to keep the volume inside what technology, price/performance, and human factors can actually handle 💅. So if an org can reach a big enough chunk of all the destinations and can express that reach with one IP address prefix, it can expect that route to stay in the default-free part of the routing system no matter where it plugs in 🦋. Using the "address ownership" policy for those orgs is a reasonable choice, and inside those orgs this doc suggests the "address lending" policy. iykyk 😌

For everyone else who expects Internet-wide IP connectivity, the reachability info they inject into the routing system should be subject to hierarchical aggregation. "Address ownership" makes that aggregation hard, if not impossible, and that is super detrimental to the routing system 💀. So to prevent the collapse of the routing system, this doc recommends "address lending" for these orgs. The catch is that when such an org first connects to the Public Internet, or changes its topological attachment to it, the org eventually needs to renumber 🔥. Renumbering lets the org withdraw any exceptional prefixes it would otherwise inject into the routing system. This applies when the org takes its addresses out of its direct provider's block and then changes its direct provider. It may also apply when the org takes its addresses out of its indirect provider's block and changes its indirect provider, or when the org's direct provider changes its provider.

Carrying routing info costs something 💸. At some point that cost may get passed back in full to the orgs injecting the info. Aggregation via CIDR could reduce the cost, because it lets one route cover more destinations. Orgs whose addresses come from "address ownership" (and so may not be suitable for aggregation) should be prepared to absorb the cost completely on their own 🫠.

Neither "address ownership" nor "address lending" on its own is enough to guarantee Internet-wide IP connectivity, so sites with addresses from either policy should talk to their providers about the reachability scope they can get with those addresses, and what it costs to use them 🧚.

If an org doesn't need Internet-wide IP connectivity, its address allocation could be done under "address ownership." It can still keep limited IP connectivity (for example, with all the subscribers of its direct provider) by limiting the distribution scope of its routing info to that direct provider. Connectivity to the rest of the Internet can be handled by mediating gateways, like application layer gateways and Network Address Translators (NATs) 🌸. Mediating gateways get rid of the need to renumber and keep non-aggregatable addressing info out of the routing system, but they have other drawbacks that can be awkward in certain situations 🙃.

Renumbering (from "address lending"), non-aggregated routing info (from "address ownership"), and mediating gateways all come with some costs 🍓. So an org needs to analyze its own connectivity requirements carefully and compare the tradeoffs of addresses from either policy against connectivity via mediating gateways (maybe with limited IP connectivity added), using addresses from "address ownership." To reduce the cost of renumbering, orgs should be strongly encouraged to deploy tools that simplify it, like the Dynamic Host Configuration Protocol [RFC 1541]. Use of the DNS should be strongly encouraged too 🌈.

---

7 Summary 💜

okay so the big takeaway ✨: any address allocation and management policy for IP addresses used for Internet connectivity has to account for its impact on the scalability of the Public Internet routing system 👑. Only the policies that give you a scalable routing system are feasible. Every other policy is self-destructive, because it leads to a collapse of the routing system and, from there, to fragmentation (partitioning) of the Public Internet 💀.

Within the current Public Internet, policies that assume unrestricted address ownership hit scalability extremely hard 😭. They are almost certain to exhaust the scalability of the routing system well before we run out of IPv4 address space, and well before we can make effective use of the IPv6 address space. Given the Internet's growth rate and current technology, the idea that everyone can own address space and get Internet-wide routing services, no matter where they connect, is currently technically infeasible 🙅‍♀️. So this doc makes two recommendations. First, the "address lending" policy should be formally added to the set of address allocation policies in the Public Internet. Second, orgs that don't provide a sufficient degree of routing info aggregation to get access to the Internet routing services should be strongly encouraged to use this policy to gain access 🎀.

Since the current IPv6 address allocation architecture is based on CIDR, the recommendations in this document apply to IPv6 address allocation and management policies as well 🦋.

---

8 Security Considerations 🔐

okay this section is serious, bestie, so pay attention 😤.

Renumbering a site has several possible implications for the security policies of both the site itself and any sites that regularly communicate with it 🚨.

Lots of sites use "firewall" systems to provide coarse-grained access control from external networks, like The Internet, to their internal systems. Those firewalls might make access control decisions based on the claimed source address of packets arriving at them. When the firewall policy relates to packets arriving on the firewall from inside the site, that firewall needs to be reconfigured at the same time the site renumbers. When the firewall policy relates to packets arriving from outside the site, those firewalls need to be reconfigured whenever an outside site that gets any access inside through the firewall is renumbered 🧱.

It is highly inadvisable to rely on unauthenticated source or destination IP addresses for security policy decisions [Bellovin89] 🙅‍♀️. IP address spoofing is not difficult with widely available systems, like personal computers. A better approach would probably involve IP Security techniques, like the IP Authentication Header [RFC-1826] or IP Encapsulating Security Payload [RFC-1827], at the firewall, so the firewall can rely on cryptographic techniques for identification when making its security policy decisions 🔑.

It is strongly desirable that authentication be present in any mechanism used to renumber IP nodes. A renumbering mechanism that lacks authentication could be used by an adversary to renumber systems that should not have been renumbered, for example 👀.

There may be other security considerations that are not covered in this document 🫣.

---

9 Acknowledgments 🫶

this doc borrows heavily from various postings on various mailing lists 📬. Special thanks to Noel Chiappa, Dennis Ferguson, Eric Fleischman, Geoff Huston, and Jon Postel, whose postings were used in this document 💖.

Most of Section 5.3 was contributed by Curtis Villamizar. The Security section was contributed by Ran Atkinson 🌟.

Many thanks to Scott Bradner, Randy Bush, Brian Carpenter, Noel Chiappa, David Conrad, John Curran, Sean Doran, Dorian Kim, Thomas Narten, Andrew Partan, Dave Piscitello, Simon Poole, Curtis Villamizar, and Nicolas Williams for their review, comments, and contributions 🙌.

Finally, we like to thank all the members of the CIDR Working Group for their review and comments 🩷.

---

9 References 📚

[Bellovin89] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989.

[Kleinrock 77] Kleinrock, L., and K. Farouk, K., "Hierarchical Routing for Large Networks," Computer Networks 1 (1977), North-Holland Publishing Company.

[Partan 95] Partan, A., private communications, October 1995.

[RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", October 1993.

[RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", September 1993.

[RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", September 1993.

[RFC 1825] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995.

[RFC 1826] Atkinson, R., "IP Authentication Header (AH), RFC 1826, August 1995.

[RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.

[Villamizar 95] Villamizar, C., private communications, October 1995.

---

10 Authors' Addresses 🧑‍💻

   Yakov Rekhter
   cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA 95134
   Phone: (914) 528-0090
   EMail: yakov@cisco.com

   Tony Li
   cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA 95134
   Phone: (408) 526-8186
   EMail: tli@cisco.com