RFC 1520 (rfc1520) - Page 1 of 9
Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
Alternative Format: Original Text Document
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
