2.4.9 Site Multihoming in IPv6 (multi6)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MULTI6 Web Page

Last Modified: 2005-01-18


Brian Carpenter <brc@zurich.ibm.com>
Kurt Lindqvist <kurtis@kurtis.pp.se>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Mailing Lists:

General Discussion: multi6@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe multi6
Archive: http://ops.ietf.org/lists/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 tolerance, perform load balancing, etc.

Multihoming today is done largely by having a site obtain a dedicated
block of address space and then advertising a route for its 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 seek alternative approaches with better scaling
properties. Specifically, the WG will prefer multihoming 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). Just as sites have multiple reasons to choose
multihoming, they may have multiple reasons to want to provide these
benefits more directly to hosts within their sites, for instance,
because some of those hosts may have network stacks capable of
detecting and surviving a provider/prefix change. Phasing in hosts
capabilities of multihoming might be part of the Multi6 solution
In the course of this work, the WG may also study the deeper
questions of identity and location of services, hosts and sites as
directly affect multihoming.However, the working group is not
to make significant changes to the nature of IP addresses or to
inter-domain routing.

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). Also, IPv6 deployment is at an early
stage, so modest enhancements to IPv6 could still be proposed.

The WG has already produced a document, RFC 3582, on goals for 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 there.

The WG will take on the following tasks:

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

Produce a document outlining practical questions to be considered
when evaluating proposals meeting the RFC 3582 goals, including
questions concerning upper layer protocols.

Produce a document describing the security threats to be addressed
by multihoming solutions.

Solicit and evaluate specific proposals to multihoming in IPv6
(both existing and new), extract and analyse common architectural
features, and select one or a small number of proposals for further
development. The architectural analysis will include applications
considerations and transport layer considerations, as well as lower
layer issues.

Development of specific solutions will require chartering of work
in the appropriate Area or Areas.

Goals and Milestones:

Done  Goals for a multihoming solution as RFC
Done  Final solicitation of proposals
Done  Begin architectural evaluation of proposals
Done  First draft of architectural evaluation
Done  Submit informational I-D to IESG on security threats
Done  Submit informational I-D to IESG on how multihoming is done today
Done  Submit informational I-D to IESG on architectural evaluation
Dec 04  Identify proposal(s) for further development, recharter
Done  Submit informational I-D to IESG on practical questions


  • draft-ietf-multi6-v4-multihoming-03.txt
  • draft-ietf-multi6-things-to-think-about-01.txt
  • draft-ietf-multi6-multihoming-threats-03.txt
  • draft-ietf-multi6-architecture-04.txt
  • draft-ietf-multi6-hba-00.txt
  • draft-ietf-multi6-functional-dec-00.txt
  • draft-ietf-multi6-app-refer-00.txt
  • draft-ietf-multi6-l3shim-00.txt
  • draft-ietf-multi6-failure-detection-00.txt

    Request For Comments:

    RFC3582 I Goals for IPv6 Site-Multihoming Architectures

    Current Meeting Report


    Agenda :

    o Administrivia, 5 mins - Chairs [agenda-62.ppt]
    - Agenda bashing
    - Scribe / Jabber Scribe

    o Presentation on changes to updated documents
    - Erik, 10 mins [multi6-shim.pdf]
    - Marcelo, 10 mins [multi6_bagnulo_ietf62.pdf]
    - Jarko, 10 mins [ietf62_multi6_faildet.pdf]

    o Outstanding issues, 25 mins
    - Any topic that should be addressed elsewhere (outside shim6)
    - Decide on open ends (not addressed by updated documents)

    o AOB, wrap-up and closing of WG.


    Time to start.

    Hopefully last multi6 meeting.

    audio streaming info here: http://www.ietf.org/audio//

    Adminstrative stuff:
    Friday there is a shim6 bof. This is in the interenet area. Output of multi6 wg is moving into this bof. 2? drafts in RFC editor's queue. Couple of drafts in IESG review.

    David (AD) mention that the DISCUSSes should have been just cleared, so a few minor issues should be fixed shortly.

    The plan is to talk to the current documents, then discuss any issues still outstanding.

    Brian - just to be clear, we've set a direction that will be filled by shim6 in Internet area. We are not going to revisit old points.

    Jari Arkko presents an Update on Failure detection draft in MULTI6
    Summary of content is existing work in the space.
    It provides a model where lower layers provide info to multi6 protocol and defines a few basic concepts:
    - available addresses
    - locally operational address pairs
    - operation address pairs

    Gives guidelines on selection of address pairs & suggests a protocol for testing reachability.

    Major changes are:
    - relaxed rules on the use of non-global address

    Marcell is up - 2 drafts
    Draft-ietf-multi6-hba-00 update
    HBAs are new type of address with cryptographic properties and provide protection when rehoming.
    Changes to the draft include
    -- added examples of reaming scenario
    -- added privacy concerns
    -- added flooding attacks discussion
    -- added the multi-prefix extension in step 6.1 of the hba-set generation process
    -- added Ext type value recommended for trials

    Brian asked for DNS consideration discussion to be added. Also mentioned that DNS could be used as a cource of trust for available addresses. Brian didn't ask for an update of DNS inside this document, but to carry to shim6

    draft-ietf-mult6-functional-dec-00 update
    This draft analyzes the trade-offs on different parts of a mult6 archetecture, presents different options, etc. Addressed some comments on locator set management. Removal of multi6 session state and fixed some editorial comments. Added comment on rehoming may be run for other reasons than just failure

    Geoff Houston - doesn't know what will happen with this document, but the title doesn't match the body. It isn't a functional decomposition and doesn't provide steps. It is more a high level discusison with some discussion points. Either need to change the title or rework the document.

    Marcello - we took Geoff's architecture document as a basis and tried to provide mechanisms to fit that document.

    Geoff - that document was a set of questions; this document fleshes out the questions, but doesn't provide solutions.

    Marcello - that was the intention and wanted to have a discussion about this at the last meeting. Was told to leave the document as-is for now, and it would be sent to shim6. We'll fix the title and need more discussion on the trade-offs.

    Kurtis - The state document is more like what Geoff wants. Leave that discussion for shim6. Geoff's point is probably valid, need to revisit it in a document revision.

    Eric is up. This is about the l3-shim document.
    Changes in the update & some comments recieved since then. Change log shown
    - clarified ingress filtering
    - clarified use of ULAs
    - added text about IP multicast
    - added text about ICMP handing in this scenario
    - clarified text on recieved site multiplexing
    - added text on renumbering issues
    - clarified flow-lable text.

    To Do things
    - using address, locator & ULID more carefully
    - Does the interaction between source locator selection and ingress filtering implies a stronger assumption - it might be too soon to assume that.
    - make it clear that the probablitlity of prefix reuse causing address reuse is very small
    - point out that MTU change can occur from locator pair switch
    - more clarifications on what is ULA specific vs. using reverse DNA

    Other questions?
    Issue 01 with To Do things added.

    Brian - confusion when handing drafts to another working group. Maybe its best to resubmit current draft with new wg (to be) label. Any other comments?

    Kurtis - my name is Geoff ... you can make same comments with respect to this document as to the previous document

    Geoff - These documents don't really tie into each other. Trying to look at this as a whole is important. The current linking between the drafts are weak.

    Eric - agrees that this is missing.

    Geoff - it is hard to read all 3 and draw the big picture from all of them. They need a little bit of work. Geoff sends a list of to the mailing list

    Someone who said that they were Brian (joke) What to do if the shim6 doesn't become a WG.

    Brian - He's not worried about that. Margaret is possitive about the bof, so he's not worried that this a dead-end. Does David Kessens want to comment?

    David - From the beginning the idea was to move the WG to a new area; there is not much reason to worry about any problems though.

    Outstanding issues or other business

    No comments

    Pekka Savola - I want to say 2 (or 3 or 4) words - Traffic Engineering and Provider Independence.

    Kurtis - provider independence is maybe not a problem to tackle here. Traffic engineering may move to shim6. Do you have another point or were you thinking about something.

    Pekka - I'm trying to remind that we've focused on connection survivability, but this is not sufficent.

    Kurtis - Yeah, there is nothing cooler than having your own address block.

    Tony Hain - are you suggestion we hold PI in another WG.

    Pekka - just reminding everyone about this topic.

    Geoff - There is a large list of things that are nice to do, but some things are easier to do. Traffic engineering is harder when you are doing host-centric services as hosts don't know topological info. TE falls down to the bottom of the list when you do host multihoming. There's not enough information at the host to do all of this.

    Pekka - I agree, but we should try to find out ways to mitigate this when using multi6.

    Eric - my take is that there is a lot of things people can do with TE. If there is a subset that is interesting, we can look into this, but it is a balancing act.

    Brian - this may be an area that isn't covered, Mr. AD?

    David - wants to say he is Margaret Wasserman, but says this is the engineering task force, if you can't solve everything, then you do what you can.

    Kurtis - should we keep this for Friday?

    David - Yes.

    Brian - it can be covered by an individual submission by someone who really cares ...

    Kurtis - last 10 minutes and mic is free ...

    Brian thanks Kurtis & David.



    Presentations attached.


    Multihoming L3 Shim Approach
    Update on the Failure Detection Draft in MULTI6