Scalable Support for Multi-homed Multi-provider Connectivity
RFC 2260

Document Type RFC - Informational (January 1998; Errata)
Authors Tony Bates  , Yakov Rekhter 
Last updated 2013-03-02
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2260 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           T. Bates
Request for Comments: 2260                                 Cisco Systems
Category: Informational                                       Y. Rekhter
                                                           Cisco Systems
                                                            January 1998

      Scalable Support for Multi-homed Multi-provider Connectivity

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

2. Abstract

   This document describes addressing and routing strategies for multi-
   homed enterprises attached to multiple Internet Service Providers
   (ISPs) that are intended to reduce the routing overhead due to these
   enterprises in the global Internet routing system.

3. Motivations

   An enterprise may acquire its Internet connectivity from more than
   one Internet Service Provider (ISP) for some of the following
   reasons.  Maintaining connectivity via more than one ISP could be
   viewed as a way to make connectivity to the Internet more reliable.
   This way when connectivity through one of the ISPs fails,
   connectivity via the other ISP(s) would enable the enterprise to
   preserve its connectivity to the Internet. In addition to providing
   more reliable connectivity, maintaining connectivity via more than
   one ISP could also allow the enterprise to distribute load among
   multiple connections. For enterprises that span wide geographical
   area this could also enable better (more optimal) routing.

   The above considerations, combined with the decreasing prices for the
   Internet connectivity, motivate more and more enterprises to become
   multi-homed to multiple ISPs. At the same time, the routing overhead
   that such enterprises impose on the Internet routing system becomes
   more and more significant. Scaling the Internet, and being able to
   support a growing number of such enterprises demands mechanism(s) to
   contain this overhead. This document assumes that an approach where
   routers in the "default-free" zone of the Internet would be required

Bates & Rekhter              Informational                      [Page 1]
RFC 2260                      Multihoming                   January 1998

   to maintain a route for every multi-homed enterprise that is
   connected to multiple ISPs does not provide an adequate scaling.
   Moreover, given the nature of the Internet, this document assumes
   that any approach to handle routing for such enterprises should
   minimize the amount of coordination among ISPs, and especially the
   ISPs that are not directly connected to these enterprises.

   There is a difference of opinions on whether the driving factors
   behind multi-homing to multiple ISPs could be adequately addressed by
   multi-homing just to a single ISP, which would in turn eliminate the
   negative impact of multi-homing on the Internet routing system.
   Discussion of this topic is beyond the scope of this document.

   The focus of this document is on the routing and addressing
   strategies that could reduce the routing overhead due to multi-homed
   enterprises connected to multiple ISPs in the Internet routing

   The strategies described in this document are equally applicable to
   both IPv4 and IPv6.

4. Address allocation and assignment

   A multi-homed enterprise connected to a set of ISPs would be
   allocated a block of addresses (address prefix) by each of these ISPs
   (an enterprise connected to N ISPs would get N different blocks).
   The address allocation from the ISPs to the enterprise would be based
   on the "address-lending" policy [RFC2008]. The allocated addresses
   then would be used for address assignment within the enterprise.

   One possible address assignment plan that the enterprise could employ
   is to use the topological proximity of a node (host) to a particular
   ISP (to the interconnect between the enterprise and the ISP) as a
   criteria for selecting which of the address prefixes to use for
   address assignment to the node. A particular node (host) may be
   assigned address(es) out of a single prefix, or may have addresses
   from different prefixes.

5. Routing information exchange

   The issue of routing information exchange between an enterprise and
   its ISPs is decomposed into the following components:

      a) reachability information that an enterprise border router
      advertises to a border router within an ISP

      b) reachability information that a border router within an ISP
      advertises to an enterprise border router

Bates & Rekhter              Informational                      [Page 2]
RFC 2260                      Multihoming                   January 1998

   The primary focus of this document is on (a); (b) is covered only as
Show full document text