This Working Group did not meet
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 06-Mar-02
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).
| 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 |