Current Meeting Report

2.3.21 Site Multihoming in IPv6 (multi6)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 19-Nov-01
Thomas Narten <>
Sean Doran <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
To Subscribe:
In Body: subscribe multi6
Description of Working Group:
A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc.

Multihoming today is done largely by having a site obtain a block of address space and then advertising a route for that prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will explore alternative approaches with better scaling properties. Specifically, the WG will prefer multi-homing solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ).

This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4).

The WG will take on the following initial tasks:

Produce a document defining what site multihoming is, the requirements for a multihoming solution (from both the end site and ISP perspective). This document will also include a taxonomy of different ways that multihoming might be achieved.

Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches.

The WG will also consider specific proposals to multihoming in IPv6 (both existing and new) and select a small number of them to work on as formal WG items. Development of specific solutions will require approval of the IESG (e.g., a recharter).

Goals and Milestones:
Apr 01   Submit initial I-D on requirements, terminology, etc.
Apr 01   Submit I-D on how multihoming is done today
Apr 01   Begin consideration of approaches and proposals that could be pursued.
Aug 01   Evaluate approaches and select those to be worked on.
Sep 01   Submit requirements ID to IESG for publication as Informational RFC.
Sep 01   Submit 'how multihoming is done today' ID to IESG for publication as Informational RFC.
Sep 01   Evaluate progress, recharter or shutdown
No Request For Comments

Current Meeting Report

None received.


None received.