RFC 1520

RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment 💅🎀

Okay bestie, let's start with the title block because it's giving paperwork, but it matters 📋✨. This is RFC 1520 from the Network Working Group, and it's an Informational doc, so it's guidance, not a standard 🌸. Y. Rekhter wrote it from the T.J. Watson Research Center at IBM Corp., and C. Topolcic wrote it from CNRI, and it's dated September 1993 🦋. The title block doesn't list any Obsoletes or Updates, so this one isn't replacing or changing any other RFC 🙈.

Status of This Memo ✨

Okay so this memo is here to share info with the Internet community 💖. It is not a standard. And distribution of it is unlimited, so share away 🌈.

1. Introduction 🦋

So CIDR (Classless Inter-Domain Routing) got adopted as the fix for the scaling problem in the Internet, and it is iconic 👑. The big-picture CIDR architecture is in [1]. How IP addresses get assigned under CIDR is in [2] and [3]. The inter-domain routing protocols that can actually support CIDR are in [4], [5], and [6] 📚.

This doc has two goals ✨. First, it describes different ways to swap inter-domain routing info across domain boundaries when one peering domain is CIDR-capable and the other one isn't. Second, it looks at what happens when CIDR-capable inter-domain routing protocols (like BGP-4 and IDRP) run and affect intra-domain routing 🔥.

It's not trying to cover every case, real or imaginable 🙃. It focuses on the most common ones. Service providers are expected to use it as a guideline for their own operational plans for the move to CIDR 🗺️.

The terms "network service provider" and "network service subscriber" came from [3]. To keep things short, "provider" or "service provider" here means either one, because the difference doesn't matter much for this discussion 💅. We also use the same words for the network and for the organization that runs it. The context makes it clear whether we mean hardware or people, and making up new terms would just make this harder to read 🫶.

Here are the key definitions, bestie, so pay attention 👀:

A CIDR-capable provider is one that can do correct IP packet forwarding, both inside its own network and toward its adjacent providers, when the inter-domain routing info it gets is expressed only as IP address prefixes, with no distinction between A, B, and C class addresses 💎.

CIDR-capable forwarding is a router's ability to keep its forwarding table and forward IP packets correctly without making any assumptions about the class of IP addresses 🧠.

CIDR reachability information is reachability info that might break any assumptions about address class. For example, a contiguous block of class C networks written as one IP address prefix counts as CIDR reachability info 🧩.

2. Taxonomy of Service Providers 🍓

For this doc, we sort all service providers into four categories. The sorting depends on the type and volume of inter-domain routing info a provider needs to acquire to meet its service requirements 📊.

• Type 1 provider 🚫: The requirements on this provider rule out using Default inter-domain route(s).
• Type 2 provider 📈: This provider can rely on one or more Default routes for inter-domain routing, but it still has to acquire a large percentage of total Internet routing info 🌊.
• Type 3 provider 🧩: This provider can also rely on one or more Default routes, but to meet its requirements it has to supplement them by acquiring a small percentage of total Internet routing info ✨.
• Type 4 provider 🧘: This provider can rely solely on one or more Default routes. It doesn't need to acquire any other inter-domain routing info at all 💅.

3. Assumptions on Deployment of CIDR in the Internet 🌈

So this doc assumes the CIDR rollout in the Internet happens in three phases 🚀.

Phase one: all the major service providers become CIDR-capable 💪. Specifically, every Type 1 provider (the ones that can't use Default routes) is expected to deploy BGP-4 and transition to CIDR during this phase. CIDR reachability info is expected to show up in the Internet for the first time once all the Type 1 providers have transitioned 👀.

Phase two starts once phase one is done 🏁. Other providers connected to the ones that transitioned in phase one become CIDR-capable too 🔗. Mostly this means Type 2 providers, which need a large percentage of total Internet routing info, and some Type 3 providers might join as well. A number of major providers agreed to this plan [8], and NSFNET's steps to carry it out are described in [9] 🙌.

Phase three is when the rest of the Type 3 providers and most of the Type 4 providers transition to CIDR ⏳.

Timing-wise, phase one is expected to be significantly shorter than phase two, and phase two is expected to be shorter than phase three 🏃‍♀️.

This doc is all about the need for providers to exchange inter-domain routing info during phases two and three 🔁. During those phases, some providers are CIDR-capable and others aren't yet. So this doc looks at routing exchanges where one peer is CIDR-capable and the other is CIDR-incapable. That's the tea 🫖☕.

4. Implications of CIDR on Interior Routing 🏠

A CIDR-capable provider can use two techniques to spread exterior routing info to all of its routers, both interior and border 🛣️:

• Use internal BGP/IDRP between all the routers.
• Use CIDR-capable IGPs (e.g., OSPF, IS-IS, RIP2).

The first technique doesn't add any requirements to the IGP inside the provider, which is a nice little win 🎀. More details on doing the first option are in [5] (see Section A.2.4).

The second technique lets the provider use internal BGP/IDRP less, but it puts specific requirements on the intra-domain routing 🧱. It also needs the ability to inject inter-domain routing info (learned through BGP or IDRP) into the intra-domain routing. Details on the second option are in [7]. Not every feature listed in [7] is expected to be widely needed, so it would be highly desirable to prioritize the features 🎯.

Both techniques mean that all the routers inside a CIDR-capable provider need to be capable of CIDR-based forwarding 💜. Which of the two techniques should be preferred? That's outside the scope of this doc, so we're not going there 🙅‍♀️.

5. Exchanging Inter-Domain Routing Information 🤝

At every phase of the transition to CIDR, one of the essential parts of Internet operations is exchanging inter-domain routing info between CIDR-capable providers and CIDR-incapable providers 🌐.

When a CIDR-capable provider swaps routing info with a CIDR-incapable one, it is of utmost importance to think about the view each side wants the other to present 🔍. That view has two parts:

• The type of routing info exchanged: a Default route, traditional (non-CIDR) reachability info, or CIDR reachability info.
• The routing info processing each side has to do to maintain these views, like the ability to aggregate, or the ability to do controlled de-aggregation 🧮.

These exchanges are controlled by bilateral agreements between directly connected service providers 🤝💖. So the views each side wants of the other are expected to be a core part of those agreements 💅.

To make troubleshooting and problem isolation easier, those bilateral agreements should be accessible to other providers 🔎. One way to do that is to put them in a generally accessible database. How to build that is outside the scope of this doc, but one possible way is described in [9] 🗄️.

Exchanging inter-domain routing info across provider boundaries happens on a per-peer basis 👯. So a border router is expected to provide the mechanisms (e.g., configuration) that control how this info is exchanged and processed, one peer at a time 🎛️.

The next sections describe possible scenarios for exchanging inter-domain routing info 👀🔥. In all of them, it's always assumed that one side is CIDR-capable and the other side isn't. The juicy part is coming next 🫶.

5.1. Exchanging Inter-Domain Routing Information between CIDR-capable providers and CIDR-incapable Type 2 (default with large proportion of explicit routes) providers

Okay so this is the Type 2 situation 💖 where the other side wants a lot of routes. The border routers inside a CIDR-capable provider are expected to be able to aggregate the inter-domain routing information they get from a CIDR-incapable Type 2 provider ✨ That aggregation is governed by a bilateral agreement. The CIDR-capable provider (the receiver) aggregates only what the other side (the CIDR-incapable sender) asks for. Basically, the aggregation SHALL be done by the CIDR-capable provider (the receiver), and ONLY when the CIDR-incapable provider (the sender) agrees 🫶

Passing inter-domain routing info from a CIDR-capable provider to a CIDR-incapable Type 2 provider needs an agreement between the two that covers:

• under what conditions the CIDR-capable provider can pass an inter-domain Default route to the CIDR-incapable provider 💅
• exchange of specific non-CIDR reachability information 🌸
• controlled de-aggregation of CIDR reachability information 🦋

The first two are already happening across the Internet, so the only new thing CIDR brings to the table is controlled de-aggregation. A CIDR-capable provider MAY decide not to de-aggregate any CIDR reachability information, or to de-aggregate some or all of it. Main character choice 👑

If a CIDR-capable provider does NOT de-aggregate its CIDR reachability info, its non-CIDR Type 2 peer can get reachability info either as non-CIDR reachability info (explicit Class A/B/C network advertisement) or as an inter-domain Default route. Since most of the current reachability info on the Internet is non-CIDR, a Type 2 provider can keep grabbing it as explicit Class A/B/C advertisements from the CIDR-capable provider, same as it does now. It's also expected that, at least temporarily (until the second phase of the transition is done), a Type 2 provider SHOULD be able to use an inter-domain Default route (acquired from the CIDR-capable provider) to forward to destinations covered by CIDR reachability info, in most cases 🌈

So, most of the cases with a CIDR-capable Type 2 provider and a CIDR-capable provider that doesn't de-aggregate can be handled by combining specific non-CIDR reachability info with an inter-domain Default route. Any inconvenience to a CIDR-incapable provider from using an inter-domain Default route goes away once that provider transitions to CIDR ✨

On the other hand, a CIDR-capable provider MAY decide to perform controlled de-aggregation of CIDR reachability information. More info on that can be found in [5] (Section 8) 📚 Now, the spicy part: special care MUST be taken when de-aggregating CIDR reachability information carried by a route with the ATOMIC_AGGREGATE path attribute. ⚠️ Also worth pointing out: because a Type 2 provider needs to acquire a large percentage of total inter-domain routing info, controlled de-aggregation is expected to result in substantial configuration at the border router that does the de-aggregating. Lots of setup, bestie 😭

5.2. Exchanging Inter-Domain Routing Information between CIDR-capable providers and CIDR-incapable Type 3 (Default with few explicit routes) providers

Same energy as 5.1 here 🌸 A border router in a CIDR-capable provider is expected to be able to aggregate routing info it gets from a CIDR-incapable Type 3 provider. This is governed by a bilateral agreement, and the CIDR-capable provider aggregates only what the CIDR-incapable provider requests.

The big difference from 5.1 is that a CIDR-incapable provider only needs a small percentage of total inter-domain routing info. If that info is non-CIDR, a Type 3 provider can get it from a CIDR-capable provider. If it's CIDR reachability info, then in most cases, forwarding to destinations covered by it can be handled with an inter-domain Default route 🦋

Once more for the people in the back: a border router in a CIDR-capable provider is still expected to be able to aggregate routing info it receives from a CIDR-incapable Type 3 provider 💅 Governed and controlled via a bilateral agreement, with the CIDR capable provider aggregating only what the other side requests.

5.3. Exchanging Inter-Domain Routing Information between CIDR-capable providers and CIDR-incapable Type 4 (Default only) providers

Again, it's still expected that a border router in a CIDR-capable provider can aggregate routing info it receives from a CIDR-incapable Type 4 provider 🫶 That's governed by a bilateral agreement, and the CIDR-capable provider aggregates only what the CIDR-incapable provider requests.

The only difference from 5.1 is that the CIDR-incapable provider doesn't need ANY inter-domain routing info beyond the Default inter-domain route. So controlled de-aggregation of CIDR reachability info is not an issue 🎀

---

6. Conclusions ✨

The global volume of routing info is expected to start dropping immediately once the first phase of the transition to CIDR is complete 📉 The second phase makes bilateral arrangements between connected service providers simpler, by shifting responsibility for routing info aggregation toward the parties that are better suited for it, and by significantly cutting down the need for routing info de-aggregation. So most of the gain in the second phase comes from simplifying those bilateral agreements 💜 The third phase is intended to complete the goals and objectives of the second phase. Full circle, iykyk 🌈

7. Acknowledgments 🫶

This document was largely sparked by the discussion at the Merit/NSFNET Regional Tech Meeting in Boulder, January 21-22, 1993. The authors would like to specifically acknowledge contributions from:

• Peter Ford (Los Alamos National Laboratory) 🌸
• Elise Gerich (NSFNET/Merit) 💖
• Susan Hares (NSFNET/Merit) ✨
• Mark Knopper (NSFNET/Merit) 🦋
• Bill Manning (Sesquinet/Rice University) 👑
• John Scudder (NSFNET/Merit) 🧚

8. References 📚

• [1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco, Merit, and OARnet, September 1993.
• [2] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit, May 1993.
• [3] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems, September 1993.
• [4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Work in Progress, June 1993.
• [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol in the Internet", Work in Progress, September 1992.
• [6] Hares, S., "IDRP for IP", Work in Progress, March 1993.
• [7] Varadhan, K., "BGP4 OSPF Interaction", Work in Progress, March 1993.
• [8] Topolcic, C., "Notes on BGP-4/CIDR Coordination Meeting of 11 March 93", Informal Notes, March 1993.
• [9] Knopper, M., "Aggregation Support in the NSFNET Policy Routing Database", RFC 1482, Merit, June 1993.

9. Security Considerations 💀

Plot twist: security issues are not discussed in this memo. Full stop, no notes. 🙈

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


Claudio Topolcic
Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Suite 100
Reston, VA 22091

Phone: (703) 620-8990
EMail: topolcic@CNRI.Reston.VA.US

And that's a wrap on RFC 1520, bestie 🌈💖✨