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

Versions: 00 01 02 03 04 05

MONAMI6 Working Group                                       N. Montavont
Internet-Draft                                                GET/ENST-B
Intended status: Informational                               R. Wakikawa
Expires: January 11, 2008                                Keio University
                                                                T. Ernst
                                                                   INRIA
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                          K. Kuladinithi
                                                    University of Bremen
                                                           July 10, 2007


                 Analysis of Multihoming in Mobile IPv6
                  draft-ietf-monami6-mipv6-analysis-03

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 January 11, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).







Montavont, et al.       Expires January 11, 2008                [Page 1]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


Abstract

   Mobile IPv6 as specified in RFC 3775 allows a mobile node to maintain
   its IPv6 communications while moving between subnets.  This document
   investigates configurations where a mobile node running Mobile IPv6
   is multihomed.  The use of multiple addresses is foreseen to provide
   ubiquitous, 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.







































Montavont, et al.       Expires January 11, 2008                [Page 2]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7

   3.  Goals and Node Capabilities  . . . . . . . . . . . . . . . . .  9

   4.  Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

   5.  Multihoming Configurations . . . . . . . . . . . . . . . . . . 13
     5.1.  (1,1): 1 HoA, 1 CoA  . . . . . . . . . . . . . . . . . . . 13
     5.2.  (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 14
     5.3.  (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 16
     5.4.  (n,n): n HoAs, n CoAs  . . . . . . . . . . . . . . . . . . 17
     5.5.  (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 18

   6.  Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  General IPv6-related Issues  . . . . . . . . . . . . . . . 19
       6.1.1.  Failure Detection  . . . . . . . . . . . . . . . . . . 19
       6.1.2.  Path Exploration . . . . . . . . . . . . . . . . . . . 19
       6.1.3.  Path Selection . . . . . . . . . . . . . . . . . . . . 20
       6.1.4.  Rehoming . . . . . . . . . . . . . . . . . . . . . . . 21
       6.1.5.  Ingress Filtering  . . . . . . . . . . . . . . . . . . 22
     6.2.  MIPv6-specific Issues  . . . . . . . . . . . . . . . . . . 23
       6.2.1.  Binding Multiple CoAs to a given HoA . . . . . . . . . 23
       6.2.2.  Simultaneous Location in Home and Foreign Networks . . 23
       6.2.3.  HA Synchronization . . . . . . . . . . . . . . . . . . 24
     6.3.  Considerations for MIPv6 Implementation  . . . . . . . . . 24
       6.3.1.  Using one HoA as a CoA . . . . . . . . . . . . . . . . 24
       6.3.2.  Binding a new CoA to the Right HoA . . . . . . . . . . 25
       6.3.3.  Binding HoA to interface . . . . . . . . . . . . . . . 25
     6.4.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 26

   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29

   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30

   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31

   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     12.2. Informative References . . . . . . . . . . . . . . . . . . 32




Montavont, et al.       Expires January 11, 2008                [Page 3]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


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

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 37















































Montavont, et al.       Expires January 11, 2008                [Page 4]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


1.  Introduction

   The emergence of performant wireless technologies has favored node
   mobility within the Internet.  Nowadays, and even more tomorrow,
   nodes are highly mobile and can change their point of attachment to
   the Internet at any time, even during active network connections.  As
   such, Mobile IPv6 (RFC 3775 [1] and RFC 3776 [2]) allows mobile nodes
   to maintain sessions open while changing their point of attachment to
   the Internet.

   Besides - as explained in [3] - ubiquitous, permanent, fault-tolerant
   and heterogeneous access to the Internet is required .  For doing so,
   mobile nodes which are prone to failure or sudden lack of
   connectivity shall be equipped with multiple interfaces.  They may
   also be connected to multihomed networks.  In such a situation,
   mobile nodes would be allocated multiple addresses and are said to be
   multihomed.  These addresses would be assigned to a single interface
   or to multiple interfaces.  However, the current specification of
   Mobile IPv6 lacks support for using multiple addresses
   simultaneously.

   Individual solutions have been proposed to extend Mobile IPv6 in such
   a way but all issues have not been addressed and not even discussed
   in some document.

   This study aims at fulfilling this gap and has two thus goals.  The
   first goal is to determine the capabilities required for providing
   ubiquitous, permanent, fault-tolerant and heterogeneous access to the
   Internet to multihomed mobile nodes operating Mobile IPv6.  The
   second goal is to define the issues arising when we attempt to
   fulfill these requirements.  The definition of solutions addressing
   these issues is out of scope of this document.

   To understand the foundation of this study, the reader shall read the
   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 for the present study.  The reader
   shall also understand the operation of the Mobile IPv6 protocol
   (RFC3775 [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 recall and refine the design goals behind multihoming
   and we discuss what are the required capabilities on the mobile nodes
   to fully meet these design goals.  Then we propose in Section 4 a
   taxonomy to classify the different cases where mobile nodes are
   multihomed.  Thereafter the taxonomy is used in Section 5 to describe



Montavont, et al.       Expires January 11, 2008                [Page 5]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   a number of multihomed configurations specific to Mobile IPv6.  For
   each case, we show the resulting addressing configuration (number of
   Home Addresses, and the number of Care-of Addresses).  Each
   configuration is illustrated with example diagrams and the means to
   meet the requirements are outlined.  Finally we discuss in Section 6
   all issues related to a multihomed mobile node and we identify what
   is missing in order 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 January 11, 2008                [Page 6]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


2.  Terminology

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

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

   o  MIPv6

      The Mobile IPv6 protocol specified in RFC3775 [1]

   o  MN

      a Mobile Node operating MIPv6

   o  HA

      a Mobile IPv6 Home Agent

   o  HoA

      a Mobile IPv6 Home Address

   o  CoA

      a Mobile IPv6 Care-of Address

   o  Multihomed MN

      In the companion document [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 is said multihomed when it has either i) multiple addresses
      which are used as source addresses or ii) multiple tunnels to
      transmit packets, or both.

      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



Montavont, et al.       Expires January 11, 2008                [Page 7]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


         attached to (presumably) distinct foreign links.

   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

      A MN is using multiple addresses simultaneously when an incoming
      packet with the destination address set to any of these addresses
      reaches the MN, or when any of these addresses can be used by the
      MN as the source address of outcoming packets.

   o  Simultaneously using multiple interfaces

      A MN is using multiple interfaces simultaneously when it can
      transmit IP packets over any of these interfaces.

   o  BT Mode

      MIPv6 Bidirectional tunnel between MN and HA.

   o  RO Mode

      MIPv6 Route optimization between MN and CN.
























Montavont, et al.       Expires January 11, 2008                [Page 8]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


3.  Goals and Node Capabilities

   In this section, we determine what are the capabilities required on
   the mobile nodes in order to benefit from multihoming configurations,
   as indicated in [3] where a number of goals/benefits are listed:
   ubiquitous access, flow redirection, reliability, load sharing,
   inteface switching, preference settings, and aggregate bandwidth.
   These do somwhat overlap, i.e., they are not totally independent.
   Reaching one of them may imply reaching another one as well.  For
   this reason, the following non-overlapping goals could be extracted:

   1.  Reliability

   2.  Load Sharing

   3.  Flow Distribution

   From now on, this document will focus on these three non-overlapping
   goals, as in this section to determine capabilities.  We will
   determine later in Section 5 which capabilities are already fulfilled
   by Mobile IPv6 and what issues still remain.

   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
   and 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, flow distribution).  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 flow distribution
   and load sharing), multiple paths must be maintained simultaneously
   between the MN and its CN.

   This translates into the following capabilities:

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

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



Montavont, et al.       Expires January 11, 2008                [Page 9]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   3.  A MN allocated with multiple valid addresses must be able to use
       them simultaneously.

   4.  A MN equipped with multiple interfaces (attached to distinct
       foreign links or distinct home links, or a combination of both)
       must be able to use them simultaneoulsy.

   5.  A MN should be able to distribute its traffic load among its
       valid global addresses.

   6.  If multiple HAs are available to manage bindings for a given HoA,
       the MN should be able to use them simultaneously.

   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 at
   the transport/application layer 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.

   Each of the aforementioned goals can be achieved independently.  We
   define here which of the above capabilities are needed for each goal:

   1.  Reliability: 1, 2, 3, 6

   2.  Load Sharing: 3, 6

   3.  Flow Distribution: 2, 3, 4, 5, 6





















Montavont, et al.       Expires January 11, 2008               [Page 10]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


4.  Taxonomy

   In order to examine the issues preventing a MN 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 of '0' implies that there is no instance of
   this parameter.  A value '*' indicates that the number can be '0',
   '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

   CoA1, CoA2, CoA3 are bound to HoA1 on IF1 and IF2
   CoA3 is bound to HoA2 on IF2

   * n/a because the number of IPv6 links is equal to 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 it having multiple interfaces.  Having
   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 January 11, 2008               [Page 11]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   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
   how multihoming is supported.  Depending on the number of HoAs and
   CoAs, different policies will be needed, such as "which CoA has to be
   mapped to which HoA", "must all the CoAs be mapped with all the
   HoAs", etc.









































Montavont, et al.       Expires January 11, 2008               [Page 12]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


5.  Multihoming Configurations

   In this section, we detail all the possible multihoming
   configurations.  For each one, we briefly explain how it may happen.
   We also 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 that will be further
   detailed in Section 6.1, Section 6.2 and Section 6.3.

   As it is demonstrated below, we notice that:

   o  When the mobile nodes is equipped with multiple interfaces,
      reliability, load sharing and flow distribution can be achieved in
      all (*,*) cases.

   o  When a single interface is available, none of the goals can be
      achieved in the (1,1) case (the MN is not multihomed).  In all the
      other cases, only reliability and load sharing can be achieved.

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

   A MN in this configuration with only a single network interface is
   not multihomed.  This configuration is the common case of a MN 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.

   A MN in the same configuration but with several interfaces is
   multihomed and lead to a special situation where the MN is connected
   to both its home link and a foreign link.  In order to use both
   interfaces simultaneously, the HoA would be directly used on the
   interface connected to the home link, and a CoA configured on the
   other interface connected to a foreign link.  There cannot be more
   than two active interfaces in the (1,1) case, otherwise the MN 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 are indeed cases (n,*)
   (see Section 5.2 , Section 5.4 and Section 5.5) and (*,n) (see
   Section 5.3 and Section 5.4), respectively.

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

   o  Reliability

      Reliability is achievable, but in a limited manner.  The MN has
      two valid addresses, but is unable to use both addresses



Montavont, et al.       Expires January 11, 2008               [Page 13]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


      simultaneously: it cannot register the CoA configured on the
      foreign network with its HA and receive packets from the HA via a
      tunnel to the CoA at the same time it receives packet on the HoA
      from the home link.  In addition, if the MN looses its connection
      established using the CoA on the foreign link, flows must be re-
      initiated with another address (either the HoA, or a new CoA
      obtained on another foreign link).  Fault recovery is thus only
      possible without transparency, and MIPv6 features can only recover
      the failure of the HoA.  This issue is detailed in Section 6.2.2.

      However, it might be possible for the MN to register the CoA with
      selected CNs (i.e. route optimization).  In this case, the MN can
      enjoy a better reliability for communications sessions opened with
      these CNs.  When the CoA fails, the MN can either bind a new CoA,
      or remove the binding and directly get the packets to its HoA.

      Reliability could also be achieved through bi-casting 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 bi-casting on the CN (see Section 6.2.2).

   o  Load Sharing, Flow Distribution

      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 and flow
      distribution 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 and flow distribution cannot be achieved.  See
      in Section 6.1.3 where such path selection issues are discussed.

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

   A MN in this configuration is multihomed since it has several HoAs.
   This case may happen when a node gets access to the Internet through
   different HAs (possibly distinct operators), each offering a Mobile
   IPv6 service to the node.  That way, the node would have a HoA per
   HA.  Alternatively, a single home network may be multihomed to the
   Internet, leading to the advertisement of multiple prefixes on the
   home link.  The MN would thus have multiple HoAs on a single home
   link.

   In either cases, the node would configure a single CoA on the visited
   IPv6 subnet, and bind that single CoA to all its HoAs.  If the MN has



Montavont, et al.       Expires January 11, 2008               [Page 14]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   multiple interfaces, only one interface is connected to a foreign
   network.  The other interfaces are connected to their home links, or
   are inactive.

   Current situation with MIPv6:

   o  Reliability

      In case a HoA fails, the session using the HoA must be restarted
      since MIPv6 does not provide any mechanism to hand-over
      transparently from a failed HoA to another one.  Fault tolerance
      cannot be achieved in this case, since established communications
      cannot be preserved.  See the corresponding discussion in
      Section 6.1.4 and Section 6.2.3.

      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.

      Reliability through bi-casting could also be achieved 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 used as
      a CoA bound to the other HoA. (see in Section 6.2.1 and
      Section 6.3.1).  In conclusion, reliability can only be achieved
      in some cases, when flows are initiated via a HoA.

   o  Load Sharing

      In Bidirectional Tunnel (BT) mode, load sharing only affects 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 same MN.  With such
      mechanisms, it would be possible to use multiple HoAs at the same
      time, and load sharing could be performed.  However, it can be
      noted that load sharing on the path between the CN and the HA
      might not be the most bandwidth contraint part of the overall path
      from the CN to the MN.  Thus load sharing might not bring



Montavont, et al.       Expires January 11, 2008               [Page 15]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


      important benefits.  See in Section 6.1.3 where such path
      selection issues are discussed.  It is also possible that the MN
      register one HoA as a CoA for another HoA (see in Section 6.3.1).

   o  Flow Distribution

      This is achievable when the MN is attached to one foreign link via
      one of its interfaces and to the home link(s) via 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

   A MN in this configuration is multihomed since it has several CoAs.
   It may occur when the MN has multiple interfaces connected to
   different links, or when the only interface is connected to a link
   where multiple IPv6 prefixes are advertised (i.e. the visited network
   is multihomed).  Note that one of the interfaces of the MN may be
   connected to its home link.

   Current situation with MIPv6:

   o  Reliability

      Reliability support is limited to recover from a failed CoA.
      Fault recovery is achieved in MIPv6 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.1), to
      check reachability (Section 6.1.2), to determine which CoA should
      be used instead (Section 6.1.3) and to redirect flows to the new
      CoA (Section 6.1.4).

   o  Load Sharing and Flow Distribution

      This configuration allows to share the load and to 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 and flow distribution 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.3).




Montavont, et al.       Expires January 11, 2008               [Page 16]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


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

   A MN in this configuration 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 (similar to case (n,1) in Section 5.2) and several CoAs,
   e.g. because the node is receiving multiple IPv6 prefixes (similar to
   case (1,n) in Section 5.3).  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.

   Current situation with MIPv6:

   o  Reliability

      If one CoA becomes unreachable (similar to (1,n)), the MN can
      redirect flows to another CoA by associating any of the other
      available CoAs to the corresponding HoA.  If the MN can not use
      one of its HoA anymore (similar to (n,1)), 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  Load Sharing and Flow Distribution

      MIPv6 allows the MN to 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 bi-casting is
      used) should be bound to which HoA (see Section 6.1.3).

      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.  This HoA would then be viewed as a
      CoA bound to another HoA (similar to (n,1)).  MIPv6 does not
      prevent this behavior, which allows to set a certain preference on
      addresses usage.  See Section 6.3.1 for the corresponding issue.








Montavont, et al.       Expires January 11, 2008               [Page 17]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


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

   This case happens when all the interfaces are connected to their
   respective home links.  This situation is quite similar to a
   multihomed fixed node.  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 and Section 5.3, respectively.

   Current situation with MIPv6

   o  Reliability

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

   o  Load Sharing, Flow Distribution

      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.3 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 January 11, 2008               [Page 18]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


6.  Multihoming 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 (Section 6.1), and issues that
   are specific to MIPv6 (Section 6.2).  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.  Failure Detection

   It is expected for faults to occur more readily at the edge of the
   network (i.e. the mobile nodes), due to the use of wireless
   connections.  Efficient fault detection mechanisms are necessary to
   recover in timely fashion.  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 HA is broken, the home link is disconnected from the Internet,
   etc.  The failure protection domain greatly varies.  In some
   configurations, the protection domain is limited to a portion of the
   path.

   So far, MIPv6 only relies on the ability or the inability to receive
   Router Advertisements within a stipulated period to detect the
   availability or loss of media (local failure).

   [5] is addressing such concerns through the use of layer 2 triggers
   [6].  Movement detection might be extended to include other triggers
   such as the loss of connectivity on one interface.  Additional
   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 HA(s), between
   the MN and CN(s), or between the HA and CN(s).

6.1.2.  Path Exploration

   When the MN needs to re-home a communication to an alternative path,
   a path exploration may take place.  The path exploration is a step
   that occurs after the failure detection, and before the path
   selection.  It consists of identifying a set of paths that are known



Montavont, et al.       Expires January 11, 2008               [Page 19]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   to provide bidirectional connectivity between the MN and its HA, and
   optionally between the MN and its CN.  It may be noted that the step
   of path exploration may be avoided by selecting a new path, and
   trying to re-home the communications on this new path.  If the re-
   homing fails, a new path is selected until there is no alternate
   path, or the re-homing signaling succeed.

   Path exploration requires some signaling between pairs of address to
   check reachability.  An additional protocol may be needed to perform
   this task.

   In (1, *), the path exploration consists in checking reachability
   between each CoA and each HA address.  If RO mode is used, the MN may
   also insure reachability between its CNs address(es) and each CoA.

   In (n, *), the path exploration consists in checking reachability
   between the HoA that is used with the session that must be re-homed
   and each CoA (and optionnally with the CN address(es)).  In addition,
   the session may need to be re-homed to a different HoA.  In this
   case, each path between a pair (HoA, CoA) must to be validated.

   In all these cases the path between the HA and the CN is not checked.
   A specific mechanism may be defined to check reachability between a
   HA and a CN.

6.1.3.  Path Selection

   When there exists multiple paths from and to the MN, the MN ends up
   choosing a source address, and possibly the interface that should be
   used.  A CN that wants to establish a communication with such a MN
   may end up by choosing a destination address for this MN.

   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
      draft-soliman-flow-binding [7] could be used.




Montavont, et al.       Expires January 11, 2008               [Page 20]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   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
      selection, such as "Default Address Selection for IPv6" (RFC3484)
      [8] or DNS SRV Protocol (RFC2782) [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 in 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 may use its
      internal policies to (i) distribute its flow, and (ii) distribute
      policies on distant nodes to allow them to select the preferred
      CoA.  Solutions like draft-soliman-flow-binding [7] may be used.

   Another related aspect of path selection is the concern of ingress
   filtering.  This is covered below in Section 6.1.5.

6.1.4.  Rehoming

   Re-homing takes place after an outage has been detected or an
   alternative path has been identified (see previous issues
   Section 6.1.1, Section 6.1.2 and Section 6.1.3), therefrom diverting
   existing sessions from one path to another.  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 re-homing or flow redirection is explained in Appendix A

   The different mechanisms that can be used to provide re-homing can be
   split into three categories, depending on the part of the path that
   needs to be changed.

   The first category is the CoA changes : it influences the path
   between the MN and its HA, and the path between the MN and its CN in
   RO mode.  This may hold in case (n, n).

   The second category is when the HoA changes (: it influences the
   entire path.  As the HoA is the address shown to the higher layer



Montavont, et al.       Expires January 11, 2008               [Page 21]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   (above layer 3), an additional mechanism is needed to manage this
   change.  Solution with a shim layer (e.g., Shim6 [REF shim6 TO BE
   ADDED]), or solution at the transport layer such as SCTP [REF SCTP TO
   BE ADDED] may be useful.

   The third category is when the HA address changes.  In this case, the
   bidirectional tunnel between the MN and its HA as to be switched to
   the new address of the HA.  This can be managed transparently by
   MIPv6 if the HoA doesn't change at the same time.  Otherwise,
   sessions continuity is not ensured, as explained in the above
   paragraph.

6.1.5.  Ingress Filtering

   Ingress filtering mechanisms [10][11] may drop the outgoing packets
   when multiple bi-directional tunnels end up at different HAs.  This
   could particularly occur if different prefixes are handled by
   different HAs.  If a packet with a source address configured from a
   specific prefix is tunneled to a HA that does not handle that
   specific prefix, the packet may be discarded either by the HA or by a
   border router in the home network.  The problem of ingress filtering
   however, is two-fold.  It can occur in the access network as well as
   the home network.

   Suppose MN selects the interface (which would determine the CoA) and
   the home network (which would determine the HoA): the chosen CoA may
   not be registered with the chosen HoA.  For instance, consider
   Figure 2 below.  In the access network, the MN must use CoA=PA.MN
   when it sends packets through AR-A and it must use CoA=PB.MN when it
   sends a packet through AR-B.  In the home network, it must use
   HoA=P1.MN when it tunnels the packet to home agent HA-1, and it must
   use HoA=P2.MN when it tunnels the packet to home agent HA-2.  To
   avoid ingress filtering, the choice is thus limited to a of valid
   (HoA,CoA) pairs.  This issue is related to Section 6.1.3 greatly
   limits the way MN can benefit from its multihoming configuration
   (particularly in case of the HA failure since flows cannot be
   diverted to the other HA).

                 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 +------+    +----------+    +------+




Montavont, et al.       Expires January 11, 2008               [Page 22]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


          Figure 2: MN connected to Multiple Access/Home Networks

   Should the MN be able to bind both CoAs PA.MN and PB.MN
   simultaneously to HoAs P1.MN and P2.MN respectively (see
   Section 6.2.1), it would be able to choose the (HoA,CoA) pair based
   on the access network it wishes to use for outgoing packets.  It is,
   nonetheless, still limited to transmit all packets to a specific HA
   for the selected (HoA,CoA) pair, i.e. ingress filtering at the home
   network remains unsolved).

   Ingress filtering in the home network concerns only the (n,n) case
   since the choice of the HoA and CoA is limited to a single (HoA, CoA)
   pair in other cases.  In (n,n), the MN may be connected to multiple
   access networks or multiple home networks each practicing ingress
   filtering.  To overcome this, mechanisms such as those provided by
   Shim6 (see RFC3582 [12] and [13]) may be used.

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,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, a solution like [14] may be used.

6.2.2.  Simultaneous Location in Home and Foreign Networks

   Rule 4 of RFC3484 (section 5) specifies that a HoA should be
   preferred to a CoA.  While this rule allows the host to choose which
   address to use, it does not allow the MN to benefit from being
   multihomed in a situation where it may have one of its interfaces
   directly connected to a home link.  That is, addresses from other
   interfaces cannot be registered as CoAs for the HoA associated to the
   home link the mobile node is connected to.  As a result, flows cannot
   be redirected transparently from one CoA to another and MIPv6



Montavont, et al.       Expires January 11, 2008               [Page 23]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   features can only recover the failure of the HoA.

   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.2.3.  HA Synchronization

   In the (n,*) cases, HoAs may be obtained from different HAs.  If any
   failure is affecting ongoing sessions on a given HoA (HA has failed
   or is overloaded), there is currently no failover allowing existing
   sessions to be shifted from one HA to another tough certain level of
   co-ordination between HAs on registered bindings would be useful.
   This co-ordination could further be extened to all (*,*) cases where
   distinct HAs would be co-ordinated to register CoAs for the same HoA.
   HA synchronization mechanisms such as these described in [15] and
   [16] could be used.

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
   multihoming, particularly 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.
   MN looses its connectivity on its first interface and 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 to register a HoA as the CoA from the perspective
   of another 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



Montavont, et al.       Expires January 11, 2008               [Page 24]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   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 observed.

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 to 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
   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.







Montavont, et al.       Expires January 11, 2008               [Page 25]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


6.4.  Summary

   The table below summarizes the cases where each issue applies (TO BE
   CHECKED AND COMPLETED)


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

              Figure 4: Summary of Issues and Categorization








Montavont, et al.       Expires January 11, 2008               [Page 26]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


7.  Conclusion

   In this document, we have demonstrated issues arising for multihomed
   mobile nodes operating Mobile IPv6.  We have seen that mechanisms are
   needed:

   o  to redirect flows from a failed path to a new path,

   o  to decide which path should better be taken when multiple paths
      are available,

   o  to register multiple Care-of Addresses

   o  to exchange policies between the Mobile Router and the Home Agent

   Even if Mobile IPv6 can be used as a mechanism to manage multihomed
   mobile nodes, triggers of flow redirection between interfaces/
   addresses are not adapted to the multihoming status of the node.
   Also, we have shown that in some configurations Mobile IPv6 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 Mobile IPv6, but solutions for these
   issues are needed for mobile nodes to fully take advantage of their
   multihomed configuration.



























Montavont, et al.       Expires January 11, 2008               [Page 27]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


8.  IANA Considerations

   This is an informational document and as such does not require any
   IANA action.















































Montavont, et al.       Expires January 11, 2008               [Page 28]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


9.  Security Considerations

   This is an informational document where the multihoming
   configurations under the operation of Mobile IPv6 are analyzed.
   Security considerations of these multihoming configurations, should
   they be different from those that concern Mobile IPv6, must be
   considered by forthcoming solutions.












































Montavont, et al.       Expires January 11, 2008               [Page 29]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


10.  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 January 11, 2008               [Page 30]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


11.  Acknowledgments

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














































Montavont, et al.       Expires January 11, 2008               [Page 31]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


12.  References

12.1.  Normative 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., Montavont, N., Wakikawa, R., Ng, C., and K.
         Kuladinithi, "Motivations and Scenarios for Using Multiple
         Interfaces and Global Addresses",
         draft-ietf-monami6-multihoming-motivation-scenario-01 (work in
         progress), October 2006.

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

12.2.  Informative References

   [5]   Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
         in IPv6", RFC 4135, August 2005.

   [6]   Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A.
         Yegin, "Link-layer Event Notifications for Detecting Network
         Attachments", draft-ietf-dna-link-information-06 (work in
         progress), February 2007.

   [7]   Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
         "Flow Bindings in Mobile IPv6",
         draft-soliman-monami6-flow-binding-04 (work in progress),
         February 2007.

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

   [9]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [10]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

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



Montavont, et al.       Expires January 11, 2008               [Page 32]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   [12]  Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
         Multihoming Architectures", RFC 3582, August 2003.

   [13]  Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim
         protocol", draft-ietf-shim6-proto-08 (work in progress),
         May 2007.

   [14]  Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli,
         "Multiple Care-of Addresses Registration",
         draft-ietf-monami6-multiplecoa-02 (work in progress),
         March 2007.

   [15]  Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home
         Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
         in progress), February 2004.

   [16]  Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent
         Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress),
         July 2004.
































Montavont, et al.       Expires January 11, 2008               [Page 33]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


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 may become available, e.g.
      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

   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
      [6] .

   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 January 11, 2008               [Page 34]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


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.org/


   Thierry Ernst
   INRIA
   INRIA Rocquencourt
   Domaine de Voluceau B.P. 105
   Le Chesnay,   78153
   France

   Phone: +33-1-39-63-59-30
   Fax:   +33-1-39-63-54-91
   Email: thierry.ernst@inria.fr
   URI:   http://www.nautilus6.org/~thierry














Montavont, et al.       Expires January 11, 2008               [Page 35]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


   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 January 11, 2008               [Page 36]


Internet-Draft      Analysis of Multihoming in MIPv6           July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Montavont, et al.       Expires January 11, 2008               [Page 37]


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