[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: May 22, 2008                                    Keio University
                                                                T. Ernst
                                                                   INRIA
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                          K. Kuladinithi
                                                    University of Bremen
                                                       November 19, 2007


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

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 May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).







Montavont, et al.         Expires May 22, 2008                  [Page 1]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                  [Page 2]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 . . 24
       6.2.3.  HA Synchronization . . . . . . . . . . . . . . . . . . 24
     6.3.  Considerations for MIPv6 Implementation  . . . . . . . . . 24
       6.3.1.  Using one HoA as a CoA . . . . . . . . . . . . . . . . 25
       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 . . . . . . . . . . . . . . . . . . . . . . . . . . 28

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30

   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31

   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32

   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     12.2. Informative References . . . . . . . . . . . . . . . . . . 33




Montavont, et al.         Expires May 22, 2008                  [Page 3]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


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

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 38















































Montavont, et al.         Expires May 22, 2008                  [Page 4]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                  [Page 5]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                  [Page 6]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 tunnels in the following cases:

      *  When it has multiple HoAs, that is if multiple prefixes are
         available on the home link or if it has multiple interfaces
         named on (presumably) distinct home links.

      *  When it has multiple CoAs, that is if multiple prefixes are
         available on the foreign link or if it has multiple interfaces



Montavont, et al.         Expires May 22, 2008                  [Page 7]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


         attached to (presumably) distinct foreign links.

      *  When the HA has multiple addresses.

   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 May 22, 2008                  [Page 8]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                  [Page 9]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 or to switch
       between them.

   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 May 22, 2008                 [Page 10]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 11]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 12]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


5.  Multihoming Configurations

   In this section, we detail all the possible multihoming
   configurations.  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
      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



Montavont, et al.         Expires May 22, 2008                 [Page 13]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


      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
   multiple interfaces, only one interface is connected to a foreign
   network.  The other interfaces are connected to their home links, or
   are inactive.




Montavont, et al.         Expires May 22, 2008                 [Page 14]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


   Current situation with MIPv6:

   o  Reliability

      If the HA fails, the session using the fail HA must be restarted
      since MIPv6 does not provide any mechanism to hand-over
      transparently from a HA 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.

      If one of the HoA of the mobile node fails, it means either that
      the corresponding HA has failed (which is the case discussed
      above), or the HoA is no longer routed to the HA.  In that latter
      case, sessions using that HoA would be temrinated, since the HoA
      cannot be changed transparently.

      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 transparent
      redirection of flows using the old CoA (i.e. the session was
      initiated using the HoA) 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



Montavont, et al.         Expires May 22, 2008                 [Page 15]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


      might not be the most bandwidth contraint part of the overall path
      from the CN to the MN.  Thus load sharing might not bring
      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 which MN's
      address is advertised to the CN.

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/



Montavont, et al.         Expires May 22, 2008                 [Page 16]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


      application preferences (see Section 6.1.3).

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 May 22, 2008                 [Page 17]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 18]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


6.  Multihoming Issues

   Existing protocols may not have the goals 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 goals 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).

   [6] is addressing such concerns through the use of layer 2 triggers
   [7].  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
   to provide bidirectional connectivity between the MN and its HA, and



Montavont, et al.         Expires May 22, 2008                 [Page 19]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


   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 [8] could be used.





Montavont, et al.         Expires May 22, 2008                 [Page 20]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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)
      [9] or DNS SRV Protocol (RFC2782) [10] 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 [8], [11], [12], or [13] 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 May 22, 2008                 [Page 21]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


   (above layer 3), an additional mechanism is needed to manage this
   change.  Solution with a shim layer (e.g., Shim6 [14]), or solution
   at the transport layer such as SCTP [5] 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 [15][16] 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 +------+    +----------+    +------+

          Figure 2: MN connected to Multiple Access/Home Networks



Montavont, et al.         Expires May 22, 2008                 [Page 22]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


   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 [17] and [14]) 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 [18] may be used.  However,
   with simultaneous binding support, there exists a possibility that a
   malicious MN can successfully bind a number of victims' addresses as
   valid CoAs for the MN with its HA.  This is because CoAs specified by
   the MN in BU messages are not verified by HA (since MIPv6 assumes an
   existing trust relationship between the MN and its HA).  Once these
   addresses have been bound, the malicious MN can perform a re-
   direction attack by instructing the HA to tunnel packets to the
   victims' addresses.

   Although such threats exist in MIPv6, MIPv6 only allows a MN to have
   a single CoA binding per HoA at a given time.  Once the malicious MN
   has bound a victim's address to the HoA using MIPv6, the malicious MN
   can no longer use the HoA for communications (such as to initiate a



Montavont, et al.         Expires May 22, 2008                 [Page 23]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


   large file download).  With simultaneous multiple CoA bindings, the
   malicious MN could bind a valid CoA in addition to multiple victims'
   addresses.  This valid CoA could then be used by the malicious MN to
   set up flow filtering rules at HA, thereby controlling and/or
   launching new re-direction attacks.

   In view of such risk, it is advisable for HA to employ some form of
   CoAs verification before using the CoAs as a valid routing path to
   MN.

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
   features can only recover the failure of the HoA.

   In the 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, though 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 [19] and
   [20] 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.





Montavont, et al.         Expires May 22, 2008                 [Page 24]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


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



Montavont, et al.         Expires May 22, 2008                 [Page 25]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


   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.

6.4.  Summary

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





























Montavont, et al.         Expires May 22, 2008                 [Page 26]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


    +=====================================================+
    |                      # 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 May 22, 2008                 [Page 27]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 28]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


8.  IANA Considerations

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















































Montavont, et al.         Expires May 22, 2008                 [Page 29]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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.  For instance, Section 6.2.1
   described a potential threat that should be considered when
   developing a proposed solution for multiple CoA regsitrations










































Montavont, et al.         Expires May 22, 2008                 [Page 30]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 31]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 32]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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.

   [5]   Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
         Paxson, "Stream Control Transmission Protocol", RFC 2960,
         October 2000.

12.2.  Informative References

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

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

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

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

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

   [11]  Larsson, C., "A Filter Rule Mechanism for Multi-access Mobile



Montavont, et al.         Expires May 22, 2008                 [Page 33]


Internet-Draft      Analysis of Multihoming in MIPv6       November 2007


         IPv6", draft-larsson-monami6-filter-rules-02 (work in
         progress), March 2007.

   [12]  Kauppinen, T., "Filter Interface Identifier Binding in Mobile
         IPv6", draft-kauppinen-monami6-binding-filter-rule-00 (work in
         progress), October 2006.

   [13]  Mitsuya, K., "A Policy Data Set for Flow Distribution",
         draft-mitsuya-monami6-flow-distribution-policy-04 (work in
         progress), August 2007.

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

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

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

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

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

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

   [20]  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 May 22, 2008                 [Page 34]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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
      [7] .

   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 May 22, 2008                 [Page 35]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 36]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 37]


Internet-Draft      Analysis of Multihoming in MIPv6       November 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 May 22, 2008                 [Page 38]


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