IPv6 Multihoming Support at Site Exit Routers
RFC 3178

Document Type RFC - Informational (October 2001; No errata)
Authors Hal Snyder  , Jun-ichiro Itoh 
Last updated 2013-03-02
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3178 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Hagino
Request for Comments: 3178                      Research Laboratory, IIJ
Category: Informational                                        H. Snyder
                                                            Vail Systems
                                                            October 2001

             IPv6 Multihoming Support at Site Exit Routers

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


   The document describes a mechanism for basic IPv6 multihoming
   support, and its operational requirements.  Unlike currently-
   practiced IPv4 multihoming, the technique does not impact the
   worldwide routing table size, nor IGP (Interior Gateway Protocol)
   routing table size in upstream ISPs.  The mechanism can be combined
   with more sophisticated (or complex) multihoming support mechanisms,
   and can be used as a foundation for other mechanisms.  The document
   is largely based on RFC 2260 by Tony Bates.

1.  Problem

   Routing table size has been a major issue for both IPv4 and IPv6.  As
   IPv6 addresses are 4 times larger in bit width than IPv4, the routing
   table size issue would have more serious negative effects on router
   memory usage, as well as routing table lookup performance.  To cope
   with this problem, the IPv6 addressing architecture [Hinden, 1998] is
   designed to take advantage of aggregated routing announcements to
   reduce the number of routes in default-free zone.  Also, 6bone
   operation guideline [Rockell, 2000] (which is the currently-practiced
   guideline for IPv6 network operation) suggests that ASes not announce
   non-aggregatable announcements to the default-free zone, if there is
   no special agreement with the peer.

   In IPv4, a multihomed site uses either of the following techniques to
   achieve better reachability:

Hagino & Snyder              Informational                      [Page 1]
RFC 3178     IPv6 Multihoming Support at Site Exit Routers  October 2001

   o  Obtain a portable IPv4 address prefix, and announce it from
      multiple upstream providers.

   o  Obtain a single IPv4 address prefix from ISP A, and announce it
      from multiple upstream providers the site is connected to.

   Since the above two methodologies effectively inject additional
   routes to the worldwide routing table, they have negative impact on
   the worldwide routing table size issue.  They also are not compatible
   with current IPv6 operational practice.

   This document provides a way to configure site exit routers and ISP
   routers, so that the site can achieve better reachability from
   multihomed connectivity, without impacting worldwide routing table
   size issues.  The technique uses multiple distinct IPv6 address
   prefixes, assigned from multiple upstream ISPs.  The technique uses
   an already-defined routing protocol (BGP or RIPng) and tunneling of
   IPv6 packets; therefore, this document introduces no new protocol
   standard (the document describes how to operate the configuration).

   This document is largely based on RFC 2260 [Bates, 1998] by Tony

2.  Goals and non-goals

   The goal of this document is to achieve better packet delivery from a
   site to the outside, or from the outside to the site, even when some
   of the site exit links are down.

   Non goals are:

   o  Choose the "best" exit link as possible.  Note that there can be
      no common definition of the "best" exit link.

   o  Achieve load-balancing between multiple exit links.

   o  Cope with breakage of any of the upstream ISPs.

3.  Basic mechanisms

   We use the technique described in RFC 2260 section 5.2 in our
   configuration.  To summarize, for IPv4-only networks, RFC 2260 says

   o  We assume that our site is connected to 2 ISPs, ISP-A and ISP-B.

Hagino & Snyder              Informational                      [Page 2]
RFC 3178     IPv6 Multihoming Support at Site Exit Routers  October 2001

   o  We are assigned IP address prefixes, Pref-A and Pref-B, from ISP-A
      and ISP-B respectively.  Hosts near ISP-A will get an address from
      Pref-A, and vice versa.

   o  In the site, we locally exchange routes for Pref-A and Pref-B, so
      that hosts in the site can communicate with each other without
      using external link.

   o  ISP-A and our site are connected by a "primary link" between ISP
      router ISP-BR-A and our router E-BR-A.  ISP B and our site are
      connected by a primary link between ISP router ISP-BR-B and our
      router E-BR-B.

           (ISP A)                         (ISP B)

           ISP-BR-A                       ISP-BR-B
               |                             |
               |Primary link                 |
Show full document text