Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
RFC 1520
Document | Type |
RFC - Historic
(September 1993; No errata)
Was draft-rekhter-cidr-environment (individual)
|
|
---|---|---|---|
Authors | Yakov Rekhter , Claudio Topolcic | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1520 (Historic) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group Y. Rekhter Request for Comments: 1520 T.J. Watson Research Center, IBM Corp. Category: Informational C. Topolcic CNRI September 1993 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. 1. Introduction Classless Inter-Domain Routing (CIDR) has been adopted as a solution to the scaling problem in the Internet. The overall CIDR architecture is described in [1]. The architecture for IP address assignment with CIDR is covered in [2] and [3]. The inter-domain routing protocols that are capable of supporting CIDR are covered in [4], [5], and [6]. The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR-capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra-domain routing. This document is not intended to cover all the cases (either real or imaginable). Rather, it focuses on what are viewed to be the most common cases. We expect that individual service providers will use this document as guidelines in establishing their specific operational plans for the transition to CIDR. The concepts of "network service provider" and "network service subscriber" were introduced in [3]. For the sake of brevity, we will use the term "provider" or "service provider" here to mean either "network service provider" or "network service subscriber", since for the most part, the distinction is not important to this discussion. Furthermore, we use the same terms to refer to the network and to the organization that operates the network. We feel that the context makes it amply clear whether we are talking about hardware or people, and defining different terms would only make this paper harder to read. Rekhter & Topolcic [Page 1] RFC 1520 CIDR Provider Information Exchange September 1993 This document defines a CIDR-capable provider as the provider that can perform correct IP packet forwarding (both internally and to other adjacent providers) when the inter-domain routing information acquired by the provider is expressed solely in terms of IP address prefixes (with no distinction between A/B/C class of addresses). This document defines CIDR-capable forwarding as the ability of a router to maintain its forwarding table and to perform correct forwarding of IP packets without making any assumptions about the class of IP addresses. This document defines CIDR reachability information as reachability information that may violate any assumptions about the class of IP addresses. For instance, a contiguous block of class C networks expressed as a single IP address prefix constitutes CIDR reachability information. 2. Taxonomy of Service Providers For the purpose of this document we partition all service providers into the following categories, based on the type and volume of inter-domain routing information a provider needs to acquire in order to meet its service requirements: - Requirements imposed on a service provider preclude it from using Default inter-domain route(s) -- we'll refer to such a pqrovider as a Type 1 provider. - Requirements imposed on a service provider allow it to rely on using one or more Default routes for inter-domain routing, but this information must be supplemented by requiring the provider to acquire a large percentage of total Internet routing information -- we'll refer to such a provider as a Type 2 provider. - Requirements imposed on a service provider allow it to rely on using one or more Default routes for inter-domain routing; however, to meet its service requirements the provider must supplement Default route(s) by acquiring a small percentage of total Internet routing information -- we'll refer to such a provider as a Type 3 provider. - Requirements imposed on a service provider allow it to rely solely on using one or more Default routes for inter-domain routing; no other inter-domain routing information need to be acquired -- we'll refer to such a provider as a Type 4 provider. Rekhter & Topolcic [Page 2] RFC 1520 CIDR Provider Information Exchange September 1993Show full document text