Goals for IPv6 Site-Multihoming Architectures
RFC 3582

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                           J. Abley
Request for Comments: 3582                                           ISC
Category: Informational                                         B. Black
                                                         Layer8 Networks
                                                                 V. Gill
                                                         AOL Time Warner
                                                             August 2003

             Goals for IPv6 Site-Multihoming Architectures

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 (2003).  All Rights Reserved.

Abstract

   This document outlines a set of goals for proposed new IPv6 site-
   multihoming architectures.  It is recognised that this set of goals
   is ambitious and that some goals may conflict with others.  The
   solution or solutions adopted may only be able to satisfy some of the
   goals presented here.

1.  Introduction

   Site-multihoming, i.e., connecting to more than one IP service
   provider, is an essential component of service for many sites which
   are part of the Internet.

   Current IPv4 site-multihoming practices have been added on to the
   CIDR architecture [1], which assumes that routing table entries can
   be aggregated based upon a hierarchy of customers and service
   providers.

   However, it appears that this hierarchy is being supplanted by a
   dense mesh of interconnections [6].  Additionally, there has been an
   enormous growth in the number of multihomed sites.  For purposes of
   redundancy and load-sharing, the multihomed address blocks are
   introduced into the global table even if they are covered by a
   provider aggregate.  This contributes to the rapidly-increasing size
   of both the global routing table and the turbulence exhibited within
   it, and places stress on the inter-provider routing system.

Abley, et al.                Informational                      [Page 1]
RFC 3582              IPv6 Site-Multihoming Goals            August 2003

   Continued growth of both the Internet and the practice of site-
   multihoming will seriously exacerbate this stress.  The site-
   multihoming architecture for IPv6 should allow the routing system to
   scale more pleasantly.

2.  Terminology

   A "site" is an entity autonomously operating a network using IP, and
   in particular, determining the addressing plan and routing policy for
   that network.  This definition is intended to be equivalent to
   "enterprise" as defined in [2].

   A "transit provider" operates a site that directly provides
   connectivity to the Internet to one or more external sites.  The
   connectivity provided extends beyond the transit provider's own site.
   A transit provider's site is directly connected to the sites for
   which it provides transit.

   A "multihomed" site is one with more than one transit provider.
   "Site-multihoming" is the practice of arranging a site to be
   multihomed.

   The term "re-homing" denotes a transition of a site between two
   states of connectedness due to a change in the connectivity between
   the site and its transit providers' sites.

3.  Multihoming Goals

3.1.  Capabilities of IPv4 Multihoming

   The following capabilities of current IPv4 multihoming practices
   should be supported by an IPv6 multihoming architecture.

3.1.1.  Redundancy

   By multihoming, a site should be able to insulate itself from certain
   failure modes within one or more transit providers, as well as
   failures in the network providing interconnection among one or more
   transit providers.

   Infrastructural commonalities below the IP layer may result in
   connectivity which is apparently diverse, sharing single points of
   failure.  For example, two separate DS3 circuits ordered from
   different suppliers and connecting a site to independent transit
   providers may share a single conduit from the street into a building;
   in this case, physical disruption (sometimes referred to as
   "backhoe-fade") of both circuits may be experienced due to a single
   incident in the street.  The two circuits are said to "share fate".

Abley, et al.                Informational                      [Page 2]
RFC 3582              IPv6 Site-Multihoming Goals            August 2003

   The multihoming architecture should accommodate (in the general case,
   issues of shared fate notwithstanding) continuity of connectivity
   during the following failures:

   o  Physical failure, such as a fiber cut, or router failure,

   o  Logical link failure, such as a misbehaving router interface,

   o  Routing protocol failure, such as a BGP peer reset,

   o  Transit provider failure, such as a backbone-wide IGP failure, and

   o  Exchange failure, such as a BGP reset on an inter-provider