[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05

IETF MONAMI6 Working Group                                  N. Montavont
Internet-Draft                                                GET/ENST-B
Expires: August 24, 2006                                     R. Wakikawa
                                                         Keio University
                                                                T. Ernst
                                                  Keio University / WIDE
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                          K. Kuladinithi
                                                    University of Bremen
                                                       February 20, 2006


                 Analysis of Multihoming in Mobile IPv6
                draft-ietf-monami6-mipv6-analysis-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The use of multiple interfaces is foreseen to provide ubiquitous,



Montavont, et al.        Expires August 24, 2006                [Page 1]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   permanent and fault-tolerant access to the Internet, particularly on
   mobile nodes which are more prone to failure or sudden lack of
   connectivity.  However, Mobile IPv6 currently lacks support for such
   multihomed nodes.  The purpose of this document is to detail all the
   issues arising through the operation of Mobile IPv6 on multihomed
   mobile nodes.  A taxonmy is used to describe the different situations
   where a mobile node is multihomed.  Issues are explained for each
   multihomed configuration (number of interfaces, number of Home
   Addresses or number of Care-of Addresses), and classified into
   general IPv6 issues, issues pertaining to the specification of Mobile
   IPv6, and issues related to the implementation of Mobile IPv6.  It is
   not the intention of this document to imply that all issues must be
   solved in the short term.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8

   4.  Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  (1,1): 1 HoA, 1 CoA  . . . . . . . . . . . . . . . . . . . 12
     5.2.  (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 13
     5.3.  (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 15
     5.4.  (n,n): n HoAs, n CoAs  . . . . . . . . . . . . . . . . . . 16
     5.5.  (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 17

   6.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.1.  General IPv6-related Issues  . . . . . . . . . . . . . . . 18
       6.1.1.  Path Selection . . . . . . . . . . . . . . . . . . . . 18
       6.1.2.  Ingress Filtering  . . . . . . . . . . . . . . . . . . 19
       6.1.3.  Failure detection  . . . . . . . . . . . . . . . . . . 20
     6.2.  MIPv6-specific Issues  . . . . . . . . . . . . . . . . . . 20
       6.2.1.  Binding Multiple CoAs to a given HoA . . . . . . . . . 20
       6.2.2.  Simultaneous Location in Home and Foreign Networks . . 21
     6.3.  Considerations for MIPv6 Implementation  . . . . . . . . . 21
       6.3.1.  Using one HoA as a CoA . . . . . . . . . . . . . . . . 21
       6.3.2.  Binding a new CoA to the Right HoA . . . . . . . . . . 22
       6.3.3.  Binding HoA to interface . . . . . . . . . . . . . . . 22
       6.3.4.  Flow redirection . . . . . . . . . . . . . . . . . . . 23
     6.4.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 23

   7.  TODO List  . . . . . . . . . . . . . . . . . . . . . . . . . . 25



Montavont, et al.        Expires August 24, 2006                [Page 2]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26

   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27

   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28

   Appendix A.  Why a MN may want to redirect flows . . . . . . . . . 30

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 33







































Montavont, et al.        Expires August 24, 2006                [Page 3]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


1.  Introduction

   The use of multiple addresses (allocated to either a single interface
   or multiple interfaces) is foreseen to provide ubiquitous, permanent
   and fault-tolerant access to the Internet, particularly on mobile
   nodes which are prone to failure or sudden lack of connectivity.
   Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain
   its IPv6 communications while moving between IPv6 subnets.  However,
   the current specification of Mobile IPv6 lacks support for mobile
   nodes with multiple addresses used simultaneously, i.e. multihomed
   mobile nodes.  These addresses would be assigned to a single
   interface or to multiple interfaces, which poses a number of issues.

   Individual solutions have been proposed to extend Mobile IPv6 for
   multihomed mobile nodes, but all issues have not been addressed in a
   single document.  The purpose of the present document is thus to fill
   up this gap by listing such issues, raising the discussion at the
   IETF, and placing some requirements in order to propose comprehensive
   solutions in forthcoming standards.

   This document has two goals.  The first goal of this document is to
   define the requirements from the point of view of multihomed mobile
   nodes operating Mobile IPv6.  The second goal of this document is to
   define the issues arising when we attempt to fulfill these
   requirements.  The definition of the potentially needed solutions is
   out of scope of the analysis document.  These should be defined in a
   separate document once the IETF community agrees on which issues
   should be solved.

   In order to reach the goals of this document, we define a taxonomy
   which is used to describe the different situations where a mobile
   node is multihomed.  For each case, we show the configuration a
   multihomed node may have (number of interfaces, number of Home
   Addresses or number of Care-of Addresses).  We also illustrate each
   scenario.

   To understand the foundation of this document, the reader must read
   our companion document [3] which outlines the motivations, the goals
   and the benefits of multihoming for both fixed and mobile nodes (i.e.
   generic IPv6 nodes).  Real-life scenarios as illustrated in that
   document are the base motivations of the present study.  The reader
   must also understand the operation of the Mobile IPv6 protocol ([1]).

   The document is organized as follows: in Section 2, we introduce the
   terminology related to multihoming and used in this document.  In
   Section 3, we discuss what is required on the mobile nodes to fully
   benefit from a multihomed configuration.  Then we propose in
   Section 4 a taxonomy to classify the different cases where mobile



Montavont, et al.        Expires August 24, 2006                [Page 4]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   nodes are multihomed.  Thereafter the taxonomy is used in Section 5
   to describe a number of multihomed configuration specific to Mobile
   IPv6.  Finally we discuss in Section 6 and Section 6.3 all issues
   related to a multihomed mobile node and we identify what is missing
   to reach the goals outlined in [3].  These issues are classified into
   IPv6 issues, Mobile IPv6-specific issues, and advices to
   implementers.












































Montavont, et al.        Expires August 24, 2006                [Page 5]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


2.  Terminology

   The terms used in the present document are defined in [4], [1] and
   [3].

   In this draft we are using the following terms and abbreviations:

   o  MIPv6

      The Mobile IPv6 protocol specified in [1]

   o  MN

      a Mobile Node operating MIPv6

   o  HA

      a Home Agent

   o  HoA

      Home Address

   o  CoA

      Care-of Address

   o  Multihomed MN

      In [3], a node is said to be multihomed when it has multiple IPv6
      addresses, either because multiple prefixes are advertised on the
      link(s) the node is attached to, or because the node has multiple
      interfaces (see the entire definition).  For a mobile node
      operating MIPv6, this may translate into the following definition:

      A MN (as defined above) is said multihomed when it simultaneously
      has (i) multiple HoAs; (ii) multiple CoAs; and/or (iii) or a
      combination of at least 2 of these.  A MN may have multiple HoAs/
      CoAs in the following cases:

      *  A MN would have multiple HoAs if multiple prefixes are
         available on the home link or if it has multiple interfaces
         named on (presumably) distinct home links.

      *  A MN would have multiple CoAs if multiple prefixes are
         available on the foreign link or if it has multiple interfaces
         attached to (presumably) distinct foreign links.




Montavont, et al.        Expires August 24, 2006                [Page 6]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   o  A valid address

      An address that is topologically correct (it is configured from
      the prefix available on the link the interface is attached to) and
      routable.

   o  Simultaneously using multiple addresses

      This indicates a scenario where the MN has the ability to use any
      of the said multiple addresses at the same time.  This implies
      that a packet with the destination field set to one of the said
      multiple addresses will reach the MN, either directly from a CN to
      the MN or through a tunnel with one of the MN's HAs.  This also
      implies that any of the said multiple addresses can be used as
      source address above the MIPv6 layer.

   o  Simultaneously using multiple interfaces

      This indicates a scenario when there is at least one valid address
      named for each of the said multiple interfaces, and that the MN is
      able to simultaneously use these addresses.






























Montavont, et al.        Expires August 24, 2006                [Page 7]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


3.  Requirements

   The following generic goals and benefits of multihoming are discussed
   in the companion document [3]:

   1.  Permanent and Ubiquitous Access

   2.  Reliability

   3.  Load Sharing

   4.  Load Balancing/Flow Distribution

   5.  Preference Settings

   6.  Aggregated Bandwidth

   In this section, we are determining what is required for a mobile
   node to achieve these design goals.  We will determine later in the
   document (in Section 5) which requirements are already fulfilled by
   MIPv6 and what issues remain in order to meet the requirements not
   currently fulfilled by MIPv6.

   Basically, Internet connectivity is guaranteed for a MN as long as at
   least one path is maintained between the MN and the fixed Internet.
   This path can be divided into two portions: the path between the MN
   to its HA(s) and the path between the HA(s) and the CN.  If RO is in
   place between the MN and a CN, an additional path between the MN and
   the CN must be guaranteed.  In some cases, it may be necessary to
   divert packets from a (perhaps failed) path to an alternative
   (perhaps newly established) path (e.g. for matters of reliability,
   preferences), or to split traffic between multiple paths (e.g. for
   load sharing, load balancing).  The use of an alternative path must
   be transparent at layers above layer 3 if broken sessions and the
   establishment of new transport sessions has to be avoided.

   In order to meet some of the goals (particularly load balancing and
   load sharing), multiple paths must be maintained simultaneously
   between the mobile node and its CN.

   This can translate into the following enumeration of requirements:

   1.  A MN must have either multiple interfaces with at least a single
       valid global IP address on each interface, or a single interface
       with more than one valid global address, or a single interface
       with one valid global address and multiple HoAs.





Montavont, et al.        Expires August 24, 2006                [Page 8]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   2.  A MN equipped with multiple interfaces must be able to use them
       simultaneously

   3.  A MN equipped with multiple interfaces must be able to attach
       distinct interfaces to distinct access networks (distinct foreign
       links or distinct home links, or a combination of both).

   4.  A MN should be able to share its traffic load among its
       interfaces, when several interfaces are activated and configured
       with valid addresses.

   5.  A mechanism should be available to quickly activate a backup
       interface and redirect traffic when an interface fails (e.g.,
       loss of connection).

   6.  A mechanism should be available to quickly redirect flow from one
       address to another when it is needed.  Some of the triggers of
       flow redirection are given in Appendix A.

   7.  If multiple HAs are available, the MN should be able to use
       multiple HAs simultaneously for a given Home Address.

   8.  When multiple HoAs are available to the MN, it should be able to
       use simultaneously distinct HAs for each HoA.

   One has to consider whether these goals can be achieved with
   transparency or without transparency.  Transparency is achieved when
   switching between interfaces does not cause the disruption of on-
   going sessions.  To be achieved with transparency, a necessary (may
   or may not be sufficient) condition is for the end-point addresses to
   remain unchanged.  This is in view of the large amount of Internet
   traffic currently carried by TCP, which unlike SCTP, cannot handle
   multiple end-point address pairs.

   In the future, when a Shim6 protocol [5] is designed and deployed,
   upper layer transparency may be maintained even if end-point
   addresses are changed.  However, as Shim6 is in its early design
   phase as of the writing of this memo, we will continue to assume that
   an end-point address change would cause a transport layer disruption
   throughout this document.











Montavont, et al.        Expires August 24, 2006                [Page 9]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


4.  Taxonomy

   In order to examine the issues preventing a MIPv6 mobile node to meet
   the requirements listed in Section 3 we use in the present document
   the following taxonomy (x,y) where:

   o  x = number of Home Addresses (HoAs)

   o  y = number of Care-of Addresses (CoAs)

   A value of '1' implies there is a single instance of the parameter,
   whereas a value of 'n' indicates that there are multiple instances of
   the parameter.  A value '*' indicates that the number can be '1' or
   'n'.

   An illustration of this taxonomy is given in Figure 1.

              Mobile Node

           HoA1         HoA2   ... HoAn   --> Permanent Address (x)
            |            |          |
      +-----+--------+   |          |
      |     |        |   |          |
     CoA1   +--CoA2  +---CoA3  ... CoAn   --> Temporary Address (y)
      |          |        |         |
     Link1      Link2    Link3 ... Linkn  -->     IPv6 Link (n/a *)
      |          |        |         |
      +-----+----+        |         |
            |             |         |
           IF1            IF2  ... IFn    -->   Physical layer

   HoA1 ::= {CoA1, 2, 3} [IF1 and IF2]
   HoA2 ::= {CoA3}       [IF2]
   Mobile Node(x = 2, y = 3)

   * because number of IPv6 links is equal to the number of CoAs, y

   Figure 1: Illustration of the Taxonomy

   As the taxonomy suggests, the fact that a mobile node has several
   HoAs is independent from the fact that this mobile node has multiple
   interfaces.  The fact that a mobile node has multiple interfaces does
   not imply that it has multiple HoAs and vice-versa.  Similarly, the
   number of CoAs is independent from the number of HoAs and the number
   of interfaces.  While a node would probably have at least one CoA per
   interface, multiple prefixes available on a link may lead the node to
   configure several CoAs on that link.




Montavont, et al.        Expires August 24, 2006               [Page 10]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   The proposed taxonomy has two parameters because each of them has an
   influence on either the mobile node behavior / management, or the
   potential benefits the mobile node may obtain from such a
   configuration.

   The configurations denoted by these parameters will have an impact on
   the way multihoming is supported.  According to the number of HoAs
   and CoAs, different policies will be needed, such as "which CoA has
   to be mapped with which HoA", "must all the CoAs be mapped with all
   the HoAs", etc.









































Montavont, et al.        Expires August 24, 2006               [Page 11]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


5.  Scenarios

   In this section, we detail the reachable multihoming goals under each
   type of configuration.  For each configuration, we give a basic
   explanation and we list which of the goals outlined in Section 3 are
   achievable provided that supporting mechanisms are either already
   existing or could be added.  Other goals are not achievable due to
   the inherent configuration of the node.  Then, we briefly discuss the
   current situation with MIPv6 and we point to issues discussed later
   in this document in Section 6.1, Section 6.2 and Section 6.3.

5.1.  (1,1): 1 HoA, 1 CoA

   A mobile node in this configuration with a single network interface
   is not multihomed.  This scenario is the common case of a MN running
   Mobile IPv6 and away from its home link: the node has one HoA and one
   CoA which is configured on the foreign link.  None of the multihoming
   goals are achievable.

   When the node in the same configuration has several interfaces, it
   may lead to a special situation where a node is connected to both its
   home link and a foreign link.  The MN is multihomed since it would be
   able to use both interfaces.  The Home Address might be directly used
   on the interface which is connected to the home link, and a Care-of
   Address is configured on the other interface which is connected to a
   foreign link.  There cannot be more than two interfaces, otherwise
   the mobile node would either have (A) multiple interfaces on the home
   link, or (B) multiple interfaces on foreign links.  For (A), there
   would be multiple HoAs.  For (B) there would be multiple CoAs.  These
   two cases would fall in another scenario, either (n,*) (see
   Section 5.2, Section 5.4 and Section 5.5) or (*,n) (see Section 5.3
   and Section 5.4).

   Achievable goals (when the node has multiple interfaces): Ubiquitous
   Access, Reliability, Load Sharing, Load Balancing, Aggregated
   Bandwidth, Preference Settings.

   Current situation with MIPv6 (when the node has multiple interfaces):

   o  Ubiquitous Access and Reliability

      These goals are achievable, but in a limited manner.  The MN can
      build a CoA on the interface connected to the foreign network, but
      it cannot register the CoA with its HA and receive packets from
      the HA via tunnel to the CoA at the same time it receives packet
      on the HoA from the Home Link.  As a result, without binding
      separately to CNs (i.e. route optimization), the MN is not able to
      use both addresses simultaneously.  In addition, in case of



Montavont, et al.        Expires August 24, 2006               [Page 12]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


      failure, the MN cannot redirect flows from one valid address to
      another.  If the MN looses its connection established using the
      address on the foreign link, all flows must be re-initiated with
      another address (either the HoA, or a new address obtained on
      another foreign link).  Fault recovery is thus only possible
      without transparency, and the MIPv6 features can only recover the
      failure of the Home Address.  This issue is detailed in
      Section 6.2.2.

      It might be possible for MN to register the CoA with selected CNs
      (i.e. route optimization).  In this case, the MN can enjoy
      benefits of increased reliability for communications sessions
      opened with these CNs.  When the CoA fails, the MN can either bind
      a new CoA, or remove the binding.

      Reliability can be achieved through bicasting since the MN has two
      addresses and should be able to request any CN to duplicate
      traffic to both of them.  However, MIPv6 does not allow the MN to
      request bicasting on the CN (see Section 6.2.2).

   o  Preference Settings, Load Sharing, Load Balancing and Aggregated
      Bandwidth

      The MN is able to use both interfaces at the same time, according
      to some preference settings on its side to decide which one to use
      for which application.  Therefore load sharing, load balancing and
      aggregated bandwidth can be achieved when sessions are initiated
      by the MN.  When a CN initiates a session with the MN, it would
      choose the destination address depending on the available
      information about the MN (e.g., DNS request).  Presently there is
      no mechanism allowing the MN to indicate on which interface (i.e.,
      address) a CN may reach it.  If only one address is known by the
      distant node, load sharing, load balancing and aggregated
      bandwidth cannot be achieved.  See in Section 6.1.1 where such
      path selection issues are discussed.

5.2.  (n,1): n HoAs, 1 CoA

   The MN is multihomed, since it has several HoAs.  This case may
   happen when a node is getting access to the Internet through
   different HAs (possibly distinct operators) and each offers a Mobile
   IPv6 service to the node.  That way, the node will have a HoA per HA.
   Alternatively, a single home network may be multihomed to the
   Internet, leading to having multiple prefixes on the home link.  Thus
   the MN would have multiple HoAs for a single home link.  Either case,
   the node would need to configure a single CoA on the visited IPv6
   subnet, and bind that single CoA to all the HoAs it owns.  If the MN
   has multiple interfaces, only one interface is connected to a foreign



Montavont, et al.        Expires August 24, 2006               [Page 13]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   network.  The other interfaces are connected to their home links.

   Achievable goals: Ubiquitous Access, Reliability, Load Sharing, Load
   Balancing and Aggregated Bandwidth (if the MN has more than one
   interface) and Preference Settings.

   Current situation with MIPv6:

   o  Ubiquitous Access and Reliability

      In case a HoA fails, (a failure could happen in the home network
      of the MN, e.g. when one HA of the MN is disconnected from the
      network), the session using the HoA must be restarted since MIPv6
      does not provide any mechanism to hand-over transparently from a
      fail HoA to another one.  Currently, fault tolerance cannot be
      achieved in this case, since established communications cannot be
      preserved.  See the corresponding discussion in Section 6.3.4.

      The CoA may change when the MN has multiple interfaces and is
      disconnected from its home link (e.g. failure of the interface, or
      movement).  In such a situation, MIPv6 allows to transparently
      redirect flows using the old CoA as a temporarily address (i.e.
      the HoA was used as the main address) to another CoA.  For
      sessions directly opened via the CoA, the loss of the address
      implies a re-initiation of the session.

      In conclusion, fault recovery can only be done in some cases, when
      flows were initiated via a HoA.

      Achieving reliability through bi-casting could be achieved in this
      scenario by registering two addresses with a single HoA.  However
      MIPv6 does not provide any mechanism to associate more than one
      CoA with one HoA.  Moreover, in this particular case, one HoA
      should be taken as a CoA regarding the other HoA. (see discussions
      in Section 6.2.1 and Section 6.3.1).

   o  Preference Settings and Load Sharing

      In Bidirectional Tunnel (BT) mode, preference settings and load
      sharing only affect the path between the CN and the HA(s), and not
      the path between the MN and the HA(s), as long as the CoA does not
      change.  In RO mode, the path between the MN and the CN does not
      change if the CoA does not change.  As an entry in the binding
      cache is identified by a HoA, the MN can register the same CoA
      with all HoAs, on any distant node.  A mechanism would then be
      needed for the MN to select which HoA should be used when a new
      communication flow is initiated.  A similar mechanism is needed on
      the CN side if it knows that multiple HoAs are assigned to the



Montavont, et al.        Expires August 24, 2006               [Page 14]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


      same MN.  With such mechanisms, it would be possible to use
      multiple HoAs at the same time, and load sharing could be
      performed.  See in Section 6.1.1 where such path selection issues
      are discussed.  It is also possible that the MN register one HoA
      as a CoA for another HoA (see discussions in Section 6.3.1).

   o  Load Balancing and Aggregated Bandwidth
      Load balancing and aggregated bandwidth are achievable when the MN
      has several interfaces.  In this case, the MN is attached to one
      foreign link via one of its interfaces, and it is attached to home
      link(s) with its other interface(s).  In this case, the MN can
      spread flows over its interfaces.  Note that if a CN initiates a
      communication, the interface that it will use on the MN would
      depend on the information it has about this MN.

5.3.  (1,n): 1 HoA, n CoAs

   The MN is multihomed since it has several CoAs.  This case may for
   instance occur when the interface of the node is connected to a link
   where multiple IPv6 prefixes are available.  One possible reason for
   this is that the visited network is multihomed and because of that,
   multiple prefixes are available in it, one per provider.  Note that
   one of the interfaces of the MN may be connected to its home link.

   Achievable goals: Reliability, Load Sharing, Preference Settings,
   Load Balancing and Aggregated Bandwidth (if the MN is equipped with
   several interfaces)

   Current situation with MIPv6:

   o  Ubiquitous Access, Reliabiility

      Fault recovery will be limited to the case where one of the CoAs
      become unreachable for a particular peer.  For instance, a CoA may
      become unreachable because the ISP which provides the IPv6 prefix
      fails.  Fault recovery in MIPv6 is achieved by associating an
      alternate CoA to replace the failed one.  However, efficient
      mechanisms are needed to determine that a CoA has failed (see
      Section 6.1.3) and to determine which CoA should be used instead
      (see below).

   o  Preference Setting, Load Sharing, Load balancing and Aggregated
      Bandwidth

      This configuration allows to share the load and set preferences
      among different paths between the HA and the MN when BT mode is
      used, and between the CN and the MN when RO mode is used.  In
      order to achieve load sharing, load balancing and aggregated



Montavont, et al.        Expires August 24, 2006               [Page 15]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


      bandwidth under this scenario, the MN would need to register
      several CoAs with its unique HoA.  However, the present
      specification of MIPv6 only allows the MN to register a single CoA
      per HoA.  This is discussed in Section 6.2.1.  When a single HoA
      is bounded to several CoAs at the same time, the MN or HA/CN must
      be able to select the appropriate CoA.  This selection could be
      done based on user/application preferences (see Section 6.1.1).

5.4.  (n,n): n HoAs, n CoAs

   The MN is multihomed since it has multiple addresses.  This case can
   be viewed as a combination of the two cases described above: the MN
   has several HoAs (e.g. given by different operators) and several CoAs
   (e.g. because the node is receiving multiple IPv6 prefixes).  As an
   example, we can consider a node with three interfaces, two of them
   connected to their home link (two different HoAs) and the last one
   connected to a visited link where two IPv6 prefixes are available.

   Achievable goals: ubiquitous access, reliability, load sharing, load
   balancing and preferences settings.

   Current situation with MIPv6:

   o  Ubiquitous Access, Reliability

      If one CoA becomes unreachable (similar to scenario (1,n) in
      Section 5.3), the MN can redirect flows to another CoA by
      associating any other available CoAs to the corresponding HoA.  If
      the MN can not use one of its HoA anymore (similar to scenario
      (n,1) in Section 5.2), the MN will have to re-initiate all flows
      which were using the corresponding HoA.  Redirection between the
      addresses available for the MN will be different depending on this
      HoA / CoA binding policies.

   o  Preference Settings, Load Sharing, Load Balancing and Aggregated
      Bandwidth.

      Currently, the MN can register only one CoA per HoA (see
      Section 6.2.1), but it can register the same or different CoAs
      with multiple HoAs.  If the MN chooses to bind the same CoA to all
      its HoAs, we fall in the (n,1) case.  In this case, load sharing
      can only be performed if route optimization is not used, on the
      CN-HA path, as a different HoA may be used per CN.  If the MN
      chooses to bind a different CoA for each HoA, load sharing will be
      done along the whole path across the MN and its CNs.  Preference
      settings may define which CoA (eventually several if bicasting is
      used) should be bound to which HoA (see Section 6.1.1).




Montavont, et al.        Expires August 24, 2006               [Page 16]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


      In a very specific situation, one of the routable address of the
      MN (i.e., which can be directly used without tunneling to reach
      the MN) can be one of its HoA.  In this case, this HoA can be
      viewed as a CoA to bind with another HoA.  Thus the MN may be able
      to register one HoA as CoA regarding another HoA (see
      Section 6.3.1).  MIPv6 does not prevent this behavior, which allow
      to set a certain preference on addresses usage.

5.5.  (n,0): n HoAs, no CoAs

   This case happens when all the interfaces are connected to their
   respective home links.  This node can be considered as a fixed node
   from a multihoming point of view.  The node would no longer be in the
   (n,0) configuration when one or more of the interfaces are attached
   to foreign links.

   The mobile node may wish to use one or more HoAs to serve as the CoA
   of another HoA (see Section 6.3.1).  In such situations, this
   scenario is reduced to a (1,1) or (1,n) configuration as described in
   Section 5.1 or Section 5.3.

   Achievable goals: Ubiquitous Access, Reliability, Load Sharing, Load
   Balancing, Aggregated Bandwidth, Preference Settings.

   Current situation with MIPv6

   o  Ubiquitous Access and Reliability

      If the MN is disconnected from one of its interfaces, the MN
      should be able to register another valid HoA to its failed HoA
      (see issue Section 6.3.1).

   o  Preference Settings, Load Sharing, Load Balancing and Aggregated
      Bandwidth

      This can be achieved when the MN is initiating the communication
      flow, as it can choose which HoA should be used.  Depending on how
      CN can discover HoAs of the MN, these goals might also be achieved
      when the CN is initiating the communication flow.  See previous
      scenario and discussions in Section 6.1.1 about the path
      selection.  If the flows binding on interfaces preferences change
      over time, the MN should be able to redirect one flow from one
      interface to another.  However, MIPv6 only allows to redirect all
      flows from one interface to another, assuming one HoA is
      registered as CoA (see issue Section 6.3.1).  If the MN policies
      indicate to redirect only one flow, a supplementary mechanism
      would be needed.




Montavont, et al.        Expires August 24, 2006               [Page 17]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


6.  Issues

   Existing protocols may not be able to handle the requirements
   expressed in Section 3.  For doing so, the issues discussed in this
   section must be addressed, and solved preferably by dynamic
   mechanisms.  Note that some issues are pertaining to MIPv6 solely,
   whereas other issues are not at all related to MIPv6.  However, such
   non MIPv6 issues must be solved in order to meet the requirements
   outlined in Section 3.

   In this section, we describe some of these issues in two main
   headings: general IPv6-related issues, and issues that are specific
   to MIPv6.  Other concerns related to implementations of MIPv6 are
   described in Section 6.3.  Issues and their area of application are
   summarized in Section 6.4

6.1.  General IPv6-related Issues

6.1.1.  Path Selection

   When there exists multiple paths from and to the MN, the MN ends up
   choosing a source and destination address, and possibly the interface
   that should be used.

   o  Interface selection

      When the node has multiple available interfaces, the simultaneous
      or selective use of several interfaces would allow a mobile node
      to spread flows between its different interfaces.

      Each interface could be used differently according to some user
      and applications policies and preferences that would define which
      flow would be mapped to which interface and/or which flow should
      not be used over a given interface.  How such preferences would be
      set on the MN is out of scope of MIPv6 and might be implementation
      specific.  On the other hand, if the MN wishes to influence how
      preferences are set on distant nodes (Correspondent Node or Home
      Agent), mechanisms such as those proposed in [6], [7] and [8]
      could be used.

   o  HoA Selection

      When multiple HoAs are available, the MN and its communicating
      peers (HA and CNs) must be able to select the appropriate HoA to
      be used for a particular packet or flow.

      This choice would be made at the time of a new communication flow
      set up.  Usual IPv6 mechanisms for source and destination address



Montavont, et al.        Expires August 24, 2006               [Page 18]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


      selection, such as "Default Address Selection for IPv6" [9] could
      be used.

      However, in RFC3484 it is said that "If the eight rules fail to
      choose a single address, some unspecified tie-breaker should be
      used".  Therefore more specific rules in addition to those
      described on RFC3484 may be defined for HoA selection.

   o  CoA Selection

      When multiple CoAs are available, the MN and its communicating
      peers (HA and CNs) must be able to select the appropriate CoA to
      be used for a particular packet or flow. the MN must use its
      internal policies to distribute its flow, but also to distribute
      policies on distant nodes to allow them to select the right CoA.
      Solutions like nomadv6 [8] or HA filtering [7] may be used.

   Another related aspect of path selection is the concern of ingress
   filtering.  This is detailed in Section 6.1.2.

6.1.2.  Ingress Filtering

   In the (*,n) case, a MN may be connected to multiple access networks
   or multiple home networks each practicing ingress filtering [10],
   [11].  Thus, to avoid ingress filtering, the selection of path would
   be limited by the choice of address used.  This is related to
   Section 6.1.1.  The problem of ingress filtering however, is two-
   fold.  It can occur at the access network, as well as the home
   network.

   For instance, consider Figure 2 below.  In the access network, when
   mobile node MN sends a packet through AR-A, it must use CoA=PA.MN;
   and when MN sends a packet through AR-B, it must use CoA=PB.MN.  In
   the home network, when MN tunnels the packet to home agent HA-1, it
   must use HoA=P1.MN; and when MN tunnels the packet to home agent
   HA-2, it must use HoA=P2.MN.  This greatly limits the way MN can
   benefit from its multihoming configuration.

   As an illustration, suppose MN is choosing the interface (which would
   determine the CoA used) and the home network to use (which would
   determine the HoA used), it might be possible that the chosen CoA is
   not registered with the chosen HoA.









Montavont, et al.        Expires August 24, 2006               [Page 19]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


                 Prefix: PA +------+    +----------+    +------+
          HoA: P1.MN  /-----| AR-A |----|          |----| HA-1 |
          CoA: PA.MN /      +------+    |          |    +------+
                +----+                  |          |   Prefix: P1
                | MN |                  | Internet |
                +----+                  |          |   Prefix: P2
          HoA: P2.MN \      +------+    |          |    +------+
          CoA: PB.MN  \-----| AR-B |----|          |----| HA-2 |
                 Prefix: PB +------+    +----------+    +------+

   Figure 2: MN connected to Multiple Access/Home Networks

   It must be noted that should the mobile node MN have a way of binding
   both CoAs PA.MN and PB.MN simultaneously to each of HoAs P1.MN and
   P2.MN (see Section 6.2.1), then it can choose the CoA to use based on
   the access network it wishes to use for outgoing packets.  This
   solves the first part of the problem: ingress filtering at the access
   network.  It is, nonetheless, still limited to using only a specific
   home agent for the home-address used (i.e. the second problem of
   ingress filtering at the home network remains unsolved).

6.1.3.  Failure detection

   Currently, IPv6 has no clearly defined mechanism for failure
   detection.  A failure in the path between two nodes can be located at
   many different places: the media of one of the node is broken (i.e.,
   loss of connectivity), the path between the MN and the HoA is broken,
   the home link is disconnected from the Internet, etc.  By now, MIPv6
   only relies on the ability or the inability to receive Router
   Advertisements within a stipulated period to detect the availibility
   or loss of media.  Current effort [12] in the DNA Working Group aims
   to address this, such as through the use of layer 2 triggers [13].
   Movement detection might be extended to include other triggers such
   as the loss of connectivity on one interface.  Further mechanisms
   would be needed to detect a failure in the path between a MN and its
   CN(s), as well as between the MN and its HoA(s), between the MN and
   CN(s), or between the MN and CN(s).

6.2.  MIPv6-specific Issues

6.2.1.  Binding Multiple CoAs to a given HoA

   In the (1,n) cases, multiple CoAs would be available to the MN.  In
   order to use them simultaneously, the MN must be able to bind and
   register multiple CoAs for a single HoA with both the HA and the CNs.
   The MIPv6 specification is currently lacking such ability.

   Although in the (n,n) cases, MIPv6 allows MN to have multiple HoA and



Montavont, et al.        Expires August 24, 2006               [Page 20]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   CoA pairs, the upper layer's choice of using a particular HoA would
   mean that the MN is forced to use the corresponding CoA.  This
   constrains the MN from choosing the best (in terms of cost, bandwidth
   etc) access link for a particular flow, since CoA is normally bound
   to a particular interface.  If the MN can register all available CoAs
   with each HoA, this would completely decouple the HoA from the
   interface, and allow the MN to fully exploit its multihoming
   capabilities.

   To counter this issue, solutions like [14] may be used.

6.2.2.  Simultaneous Location in Home and Foreign Networks

   Rule 4 of RFC3484 specifies that a HoA will always be preferred to a
   CoA.  While this rule allows to choose which address to use, it does
   not allow MN to benefit from being multihomed.  When a MN is
   multihomed, it may have one of its interfaces directly connected to a
   home link.  This may have an impact on the way multihoming is
   managed, since addresses from other interfaces cannot be registered
   as CoAs for the HoA associated to the home link the mobile node is
   connected on.

   In the special case of (1,*) where one of the interface is connected
   to the home link, none of the other addresses can be used to achieve
   multihoming goals with the HA.

6.3.  Considerations for MIPv6 Implementation

   In addition to the issues described in Section 6.1 and Section 6.2,
   there are other concerns implementers should take into consideration
   so that their MIPv6 implementations are more "friendly" to the use of
   multiple interfaces.  These implementation-related considerations are
   described in the sub-sections below.

6.3.1.  Using one HoA as a CoA

   In (n,*) cases, the MN has multiple HoAs.  A HoA may be seen as a CoA
   from the perspective of another home link of the same MN.

   As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home
   links.  MN is connected to these two home links via two interfaces.
   If the MN looses its connectivity on its first interface, HoA1 is not
   reachable.  It may then want to register HoA2 as a CoA for HoA1 in
   order to keep receiving packets intended to HoA1, via the second
   interface.

   According to the definition of a CoA, the current MIPv6 specification
   does not prohibit a HoA to be a CoA from the perspective of another



Montavont, et al.        Expires August 24, 2006               [Page 21]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   HoA.

   In RFC3775 section 6.1.7 it is written: " Similarly, the Binding
   Update MUST be silently discarded if the care-of address appears as a
   home address in an existing Binding Cache entry, with its current
   location creating a circular reference back to the home address
   specified in the Binding Update (possibly through additional
   entries)."

   In order to benefit from any multihoming configuration, a MN must be
   able to register whatever address it owns with any of its HoA, as
   long as the above statement is verified.

6.3.2.  Binding a new CoA to the Right HoA

   In the (n,*) cases, the MN has multiple HoAs.  When the MN moves and
   configures a new CoA, the newly obtained CoA must be bound to a
   specific HoA.  The current MIPv6 specification doesn't provide a
   decision mechanism to determine to which HoA this newly acquired CoA
   should be bound to.

   With no such mechanism, the MN may be confused and may bind this CoA
   to a possibly wrong HoA.  The result might be to bind the CoA to the
   same HoA the previous CoA was bound to or to another one, depending
   on the implementation.  It would indeed be better to specify the
   behavior so that all implementations are compliant.

6.3.3.  Binding HoA to interface

   In (n,*) cases, MIPv6 does not provide any information on how HoAs
   should be bound on a device, and particularly there is no mechanism
   to bind HoAs to interfaces.

   This may be troublesome, for example, when we consider a MN
   configured with two HoAs and equipped with three interfaces.  When
   the MN is connected to a home link via one interface, it will need to
   bind the corresponding HoA to this interface, even if the HoA was
   initially assigned to another one.

                  HoA1          HoA2

             CoA1        CoA2         CoA3
            Iface1      Iface2       Iface3

   Figure 3: Illustration of the case (2,3)

   HoA must always be assigned to an activated interface and if the MN
   is connected to its home link, the corresponding HoA must be used on



Montavont, et al.        Expires August 24, 2006               [Page 22]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   this interface.  In some cases, the HoA then would have to be re-
   assigned to another interface in case of connection loss or
   attachment to the home link.

6.3.4.  Flow redirection

   Internet connectivity is guaranteed for a MN as long as at least one
   path is maintained between the MN and its CN.  When an alternative
   path must be found to substitute for another one, the loss of one
   path to the Internet may result in broken sessions.  In this case,
   new transport sessions would have to be established over the
   alternate path if no mechanism is provided to redirect flow
   transparently at layers above layer 3.  The need for flow redirection
   is given in Appendix A.

   The different mechanisms that can be used to provide flow redirection
   can be split into two categories, depending on the part of the path
   that needs to be changed.  The first category is when the CoA
   changes: if one of the MN's CoA needs to be changed, it influences
   the path between the MN and its HA, and the path between the MN and
   its CN in RO mode.  If the MN has multiple interfaces and one fails,
   established sessions on the failed interface would break if no
   support mechanism is used to redirect flows from the failed interface
   to another.

   The second category is when the HoA changes: if one of the MN's HoA
   needs to be changed, it influences the path between the CN and the
   HoA.  In (n,*) cases, the MN has multiple HoAs.  If one fails,
   established sessions on the failed HoA would break if no support
   mechanism is used to redirect flows from a failed HoA to another,
   unless the transport session has multihoming capabilities, such as
   SCTP, to allow dynamic changing of addresses used.

6.4.  Summary

   THIS TABLE IS A WORK IN PROGRESS (so all boxes may not have been
   filled appropriately).  For now, please comment on the need for the
   table rather than the content)













Montavont, et al.        Expires August 24, 2006               [Page 23]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


    +=====================================================+
    |                      # of HoAs: | 1 | 1 | n | n | n |
    |                      # of CoAs: | 1 | n | 0 | 1 | n |
    +=====================================================+
    |             General IPv6 Issues                     |
    +---------------------------------+---+---+---+---+---+
    | Path Selection                  |   | o | ? | o | o |
    +---------------------------------+---+---+---+---+---+
    | Ingress Filtering               |   |   | ? | o | o |
    +---------------------------------+---+---+---+---+---+
    | Failure detection               |o  | o | ? | o | o |
    +---------------------------------+---+---+---+---+---+
    |            MIPv6-Specific Issues                    |
    +---------------------------------+---+---+---+---+---+
    | Binding Multiple CoAs to a      |   | o | ? | o | o |
    |   given HoA                     |   |   |   |   |   |
    +---------------------------------+---+---+---+---+---+
    | Using one HoA as a CoA          |   |   | ? | o | o |
    +---------------------------------+---+---+---+---+---+
    | Simultaneous location in home   |   | o | ? | o | o |
    |   and foreign networks          |   |   | ? |   |   |
    +---------------------------------+---+---+---+---+---+
    |        Implementation-Related Concerns              |
    +---------------------------------+---+---+---+---+---+
    | Binding a new CoA to the        |   |   | ? | o | o |
    |   right HoA                     |   |   |   |   |   |
    +---------------------------------+---+---+---+---+---+
    | Binding HoA to interface(s)     | o | o | ? | o | o |
    +---------------------------------+---+---+---+---+---+
    | Flow redirection                | o | o | ? | o | o |
    +=====================================================+

   Figure 4: Summary of Issues and Categorization


















Montavont, et al.        Expires August 24, 2006               [Page 24]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


7.  TODO List

   Study security concerns

   Possibly discuss the possibility to use HoA on both home link and
   foreign link as in case (1,1):

   Mention about relation with Shim6.

   Reword all the text about the "returning home case" throughout the
   entire draft








































Montavont, et al.        Expires August 24, 2006               [Page 25]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


8.  Conclusion

   In this document, we have raised issues related to multihoming.  We
   have seen that mechanisms are needed to redirect flow from a failed
   path to a new path, and mechanisms to decide which path should better
   be taken when multiple paths are available.  This raises a number of
   issues.

   Even if MIPv6 can be used as a mechanism to manage multihomed MN,
   triggers of flows redirection between interfaces/addresses are not
   adapted to the multihoming status of the node.  Also, we have shown
   that in some scenarios MIPv6 is ambiguous in the definitions of CoA/
   HoA and in the mappings between HoAs, CoAs and network interfaces.
   Finally, we have also raised issues not directly related to MIPv6,
   but solutions for these issues are needed for mobile nodes to fully
   enjoy the benefits of being multihomed.



































Montavont, et al.        Expires August 24, 2006               [Page 26]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


9.  Contributors

   The following people have contributed ideas, text and comments to
   earlier versions of this document: Eun Kyoung Paik from Seoul
   National University, South Korea and Thomas Noel from Universite
   Louis Pasteur, Strasbourg, France.













































Montavont, et al.        Expires August 24, 2006               [Page 27]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


10.  Acknowledgments

   The authors would like to thank all the people who have sent comments
   so far, particularly Tobias Kufner, Marcelo Bagnulo, and Romain Kuntz
   for their in-depth comments and raising new issues.


11.  References

   [1]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [2]   Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
         Agents", RFC 3776, June 2004.

   [3]   Ernst, T., "Motivations and Scenarios for Using Multiple
         Interfaces and Global Addresses",
         draft-ietf-monami6-multihoming-motivations-scenarios-00 (work
         in progress), February 2006.

   [4]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [5]   Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
         protocol", draft-ietf-shim6-proto-03 (work in progress),
         December 2005.

   [6]   Soliman, H., Malki, K., and C. Castelluccia, "Per-flow movement
         in MIPv6", draft-soliman-mobileip-flow-move-02 (work in
         progress), July 2002.

   [7]   Montavont, N. and T. Noel, "Home Agent Filtering for Mobile
         IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in
         progress), January 2004.

   [8]   Kuladinithi, K., "Filters for Mobile IPv6 Bindings (NOMADv6)",
         draft-nomadv6-mobileip-filters-03 (work in progress),
         October 2005.

   [9]   Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [10]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
         Networks", BCP 84, RFC 3704, March 2004.

   [11]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source



Montavont, et al.        Expires August 24, 2006               [Page 28]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [12]  Choi, J., "Goals of Detecting Network Attachment in IPv6",
         draft-ietf-dna-goals-04 (work in progress), December 2004.

   [13]  Yegin, A., "Link-layer Event Notifications for Detecting
         Network Attachments", draft-ietf-dna-link-information-03 (work
         in progress), October 2005.

   [14]  Wakikawa, R., "Multiple Care-of Addresses Registration",
         draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
         June 2005.

   [15]  Yegin, A., "Link-layer Hints for Detecting Network
         Attachments", draft-yegin-dna-l2-hints-01 (work in progress),
         February 2004.

   [16]  Montavont, N., "Mobile IPv6 for multiple interfaces (MMI)",
         draft-montavont-mip6-mmi-02 (work in progress), July 2005.
































Montavont, et al.        Expires August 24, 2006               [Page 29]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


Appendix A.  Why a MN may want to redirect flows

   When a MN is multihomed, an addresses selection mechanism is needed
   to distribute flows over interfaces.  As policies may change over
   time, as well as the available addresses/interfaces, flow redirection
   mechanisms are needed.  While the selection policy is out of scope of
   this document, the following reasons may trigger the MN to redirect
   flow from one address to another:

   o  Failure detection: the path between the MN and its CN(s) is
      broken.  The failure can occur at different places onto this path;
      The failure can be local on the MN, where the interface used on
      the MN is disconnected from the network (e.g., a wireless
      interface which comes out of range from its point of attachment).
      Alternatively, the failure can be on the path between the MN and
      one of its HA.  Yet another alternative is that the failure can be
      on the path between the HA and the CN.  If route optimization is
      used, it can also be a failure between the MN and its CN(s).

   o  New address: a new address on the MN comes available.  This can be
      the case when the MN connects to the network with a new interface.
      The MN may decide that this new interface is most suitable for its
      current flows that are using another interface.

   o  Uninterrupted horizontal handover in mobility: If the MN is
      mobile, it may have to change its point of attachment.  When a MN
      performs a horizontal handover, the handover latency (the time
      during which the MN can not send nor receive packets) can be long
      and the flows exchanged on the interface can be interrupted.  If
      the MN wants to minimize such perturbation, it can redirect some
      or all the flows on another available interface.  This redirection
      can be done prior to the handover if L2 triggering is considered
      [13] [15]

   o  Change in the network capabilities: the MN can observe a
      degradation of service on one of its interface, or conversely an
      improvement of capacity on an interface.  The MN may then decide
      to redirect some or all flows on another interface that it
      considers most suitable for the target flows.

   o  Initiation of a new flow: a new flow is initiated between the MN
      and a CN.  According to internal policies, the MN may want to
      redirect this flow on a most suitable interface.








Montavont, et al.        Expires August 24, 2006               [Page 30]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


Authors' Addresses

   Nicolas Montavont
   Ecole Nationale Superieure des telecommunications de Bretagne
   2, rue de la chataigneraie
   Cesson Sevigne  35576
   France

   Phone: (+33) 2 99 12 70 23
   Email: nicolas.montavont@enst-bretagne.fr
   URI:   http://www-r2.u-strasbg.fr/~montavont/


   Ryuji Wakikawa
   Keio University
   Department of Environmental Information, Keio University.
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.net/


   Thierry Ernst
   Keio University / WIDE
   Jun Murai Lab., Keio University.
   K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
   Kawasaki, Kanagawa  212-0054
   Japan

   Phone: +81-44-580-1600
   Fax:   +81-44-580-1437
   Email: ernst@sfc.wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~ernst/














Montavont, et al.        Expires August 24, 2006               [Page 31]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


   Chan-Wah Ng
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG

   Phone: +65 65505420
   Email: chanwah.ng@sg.panasonic.com


   Koojana Kuladinithi
   University of Bremen
   ComNets-ikom,University of Bremen.
   Otto-Hahn-Allee NW 1
   Bremen, Bremen  28359
   Germany

   Phone: +49-421-218-8264
   Fax:   +49-421-218-3601
   Email: koo@comnets.uni-bremen.de
   URI:   http://www.comnets.uni-bremen.de/~koo/





























Montavont, et al.        Expires August 24, 2006               [Page 32]


Internet-Draft      Analysis of Multihoming in MIPv6       February 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Montavont, et al.        Expires August 24, 2006               [Page 33]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/