Browse Prior Art Database

IPv6 Multihoming Support at Site Exit Routers (RFC3178)

IP.com Disclosure Number: IPCOM000005859D
Original Publication Date: 2001-Oct-01
Included in the Prior Art Database: 2001-Nov-13
Document File: 13 page(s) / 25K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Hagino: AUTHOR [+2]

Abstract

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 14% of the total text.

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.

Abstract

   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

   Bates.

2.  Goals and non-goals

   The goal of this document is...