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

Versions: 00 01 02 03 04 05

MEXT Working Group                                          N. Montavont
Internet-Draft                                       IT/Telecom Bretagne
Intended status: Informational                               R. Wakikawa
Expires: November 4, 2008                          Toyota ITC/Keio Univ.
                                                                T. Ernst
                                                                   INRIA
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                          K. Kuladinithi
                                                    University of Bremen
                                                             May 3, 2008


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

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 November 4, 2008.

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,



Montavont, et al.       Expires November 4, 2008                [Page 1]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Goals and Node Capabilities  . . . . . . . . . . . . . . . . .  6
   4.  Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Analysis of Multihoming Configurations . . . . . . . . . . . .  9
     5.1.  (1,1): 1 HoA, 1 CoA  . . . . . . . . . . . . . . . . . . .  9
     5.2.  (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 11
     5.3.  (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 13
     5.4.  (n,n): n HoAs, n CoAs  . . . . . . . . . . . . . . . . . . 14
     5.5.  (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 16
   6.  Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  General IPv6-related Issues  . . . . . . . . . . . . . . . 16
       6.1.1.  Failure Detection  . . . . . . . . . . . . . . . . . . 16
       6.1.2.  Path Exploration . . . . . . . . . . . . . . . . . . . 17
       6.1.3.  Path Selection . . . . . . . . . . . . . . . . . . . . 18
       6.1.4.  Rehoming . . . . . . . . . . . . . . . . . . . . . . . 19
       6.1.5.  Ingress Filtering  . . . . . . . . . . . . . . . . . . 20
     6.2.  MIPv6-specific Issues  . . . . . . . . . . . . . . . . . . 21
       6.2.1.  Binding Multiple CoAs to a given HoA . . . . . . . . . 21
       6.2.2.  Simultaneous Location in Home and Foreign Networks . . 21
       6.2.3.  HA Synchronization . . . . . . . . . . . . . . . . . . 22
     6.3.  Considerations for MIPv6 Implementation  . . . . . . . . . 22
       6.3.1.  Using one HoA as a CoA . . . . . . . . . . . . . . . . 22
       6.3.2.  Binding a new CoA to the Right HoA . . . . . . . . . . 23
       6.3.3.  Binding HoA to interface . . . . . . . . . . . . . . . 23
     6.4.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 24
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     12.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Why a MN may want to redirect flows . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 31





Montavont, et al.       Expires November 4, 2008                [Page 2]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


1.  Introduction

   With the emergence of performant wireless technologies, nodes are
   highly mobile and can change their point of attachment to the
   Internet at any time, even during active network connections.  To
   support such mobility in IPv6, Mobile IPv6 (RFC 3775 [1] and RFC 3776
   [2]) allows mobile nodes to maintain ongoing sessions while changing
   their points of attachment to the Internet.

   Additionally, 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 may 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 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, readers should
   familiarize themselves with 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 should also has basic
   understanding of the operation of the Mobile IPv6 protocol specified
   in 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 November 4, 2008                [Page 3]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   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.


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  Mobile Node (MN)

      a Mobile Node operating Mobile IPv6

   o  HA

      a Mobile IPv6 Home Agent

   o  HoA

      a Mobile IPv6 Home Address

   o  CoA

      a Mobile IPv6 Care-of Address

   o  Multihomed Mobile Node

      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 Mobile IPv6, this may
      translate into the following definition:

      A mobile node is said multihomed when it has either i) multiple



Montavont, et al.       Expires November 4, 2008                [Page 4]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


      addresses which are used as source addresses or ii) multiple
      tunnels to transmit packets, or both.

      A mobile node may have multiple tunnels in the following cases:

      *  When it has multiple home addresses, 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 care-of addresses, that is if multiple
         prefixes are available on the foreign link or if it has
         multiple interfaces attached to (presumably) distinct foreign
         links.

      *  When the home agent 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 mobile node is using multiple addresses simultaneously when an
      incoming packet with the destination address set to any of these
      addresses reaches the mobile node, or when any of these addresses
      can be used by the mobile node as the source address of outcoming
      packets.

   o  Simultaneously using multiple interfaces

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

   o  Bidirectional Tunnel (BT) Mode

      Mobile IPv6 Bidirectional tunnel between the mobile node and its
      home agent.

   o  Route Optimization (RO) Mode

      Mobile IPv6 Route optimization between the mobile node and its
      correspondent node.







Montavont, et al.       Expires November 4, 2008                [Page 5]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


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,
   interface switching, preference settings, and aggregate bandwidth.
   These do somewhat 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 mobile node as
   long as at least one path is maintained between the mobile node and
   the fixed Internet.  This path can be divided into two portions: the
   path between the mobile node and its home agent(s) and the path
   between the home agent(s) and the correspondent node.  If route
   optimization is in place between the mobile node and the
   correspondent node, an additional path between the mobile node and
   the correspondent node must be guaranteed.  In essence, the benefit
   of multihoming is to allow all or parts of these paths to have
   multiple alternatives, so as to achieve reliability, load sharing
   and/or flow distribution.  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 mobile node and its correspondent node.

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



Montavont, et al.       Expires November 4, 2008                [Page 6]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


       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.

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

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

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

   6.  If multiple home agents are available to manage bindings for a
       given home address, the mobile node 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/addresses does not cause the disruption
   of ongoing sessions.  To achieve 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 November 4, 2008                [Page 7]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


4.  Taxonomy

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

   o  x = number of Home Addresses (HoAs)

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

   A value of '1' implies there is a single instance of the parameter,
   whereas a value of 'n' indicates that there are multiple instances of
   the parameter.  A value 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
   home addresses is independent from it having multiple interfaces.
   Having multiple interfaces does not imply that it has multiple home
   addresses and vice-versa.  Similarly, the number of care-of addresses
   is independent from the number of home addresses and the number of
   interfaces.  While a node would probably have at least one care-of
   address per interface, multiple prefixes available on a link may lead
   the node to configure several care-of addresses on that link.




Montavont, et al.       Expires November 4, 2008                [Page 8]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   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 home and
   care-of addresses, different policies will be needed, such as "which
   care-of address has to be mapped to which home address", "all the
   care-of addresses must be mapped with all the home addresses", etc.

   The readers should note that for Mobile IPv6, home address is used to
   identify a binding.  Thus when a mobile node has multiple home
   addresses, it would imply the mobile node is using multiple Mobile
   IPv6 sessions, regardless of whether all the home addresses are
   handled by a single home agent.


5.  Analysis of Multihoming Configurations

   In this section, we detail all the possible multihoming
   configurations.  We briefly discuss the current situation with Mobile
   IPv6 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 mobile node 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 mobile node in this configuration with only a single network
   interface is not multihomed.  This configuration is the common case
   of a mobile node is away from its home link: the node has one home
   address and one care-of address which is configured on the foreign
   link.  None of the multihoming goals are achievable.

   A mobile node in the same configuration but with several interfaces
   is multihomed and lead to a special situation where the mobile node
   is connected to both its home link and a foreign link.  In order to
   use both interfaces simultaneously, the home address would be



Montavont, et al.       Expires November 4, 2008                [Page 9]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   directly used on the interface connected to the home link, and a
   care-of address 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 mobile node would either have (A) multiple
   interfaces on the home link, or (B) multiple interfaces on foreign
   links.  For (A), there would be multiple home addresses.  For (B)
   there would be multiple care-of addresses.  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.

   We next analyze if Mobile IPv6 can be used to achieve the following
   multihoming benefits:

   o  Reliability

      What Mobile IPv6 can achieve

         Reliability is achievable, but in a limited manner.  Although
         the mobile node cannot register its care-of address at its home
         agent and use its home link at the same time, it could register
         the care-of address with selected correspondent nodes (i.e.
         route optimization).  In this case, the mobile node can enjoy a
         better reliability for communications sessions opened with
         these corrrespondent nodes.  When the care-of address fails,
         the mobile node can either bind a new care-of address with its
         home address at the correspondent nodes, or remove the binding
         and directly get the packets via the home link.

      What is missing for Mobile IPv6

         The mobile node cannot register the care-of address configured
         on the foreign network with its home address and receive
         packets from the home agent via a tunnel to the care-of address
         at the same time it receives packet on the home address from
         the home link.  In addition, if the mobile node looses its
         connection on the foreign link, flows that are started by using
         the care-of address as a source address must be re-initiated
         with another address (either the home address, or a new care-of
         address obtained on another foreign link).  Fault recovery is
         thus only possible without transparency, and Mobile IPv6
         features can only recover the failure of the home address.
         This issue is detailed in Section 6.2.2.

         Reliability could also be achieved through bi-casting since the
         mobile node has two addresses and should be able to request any
         correspondent node to duplicate traffic to both of them.
         However, Mobile IPv6 does not allow the mobile node to request
         bi-casting on the correspondent node (see Section 6.2.2).



Montavont, et al.       Expires November 4, 2008               [Page 10]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   o  Load Sharing, Flow Distribution

      What Mobile IPv6 can achieve

         The mobile node 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 mobile node.  When a correspondent node
         initiates a session with the mobile node, it would choose the
         destination address depending on the available information
         about the mobile node (e.g., DNS request).  Presently there is
         no mechanism allowing the mobile node to indicate on which
         interface (i.e., address) a correspondent node 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.

      What is missing for Mobile IPv6

         Although the mobile node is able to use both interfaces at the
         same time, there is no mechanism that allows the mobile node to
         indicate to which interface (i.e., address) a correspondent
         node send packets for a particular flow.  Section 6.1.3
         discusses such path selection issues.

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

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

   In either cases, the node would configure a single care-of address on
   the visited IPv6 subnet, and bind that single care-of address to all
   its home addresses.  If the mobile node has multiple interfaces, only
   one interface is connected to a foreign network.  The other
   interfaces are connected to their home links, or are inactive.

   We next analyze if Mobile IPv6 can be used to achieve the following
   multihoming benefits:





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

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   o  Reliability

      What Mobile IPv6 can achieve

         The care-of address may change when the mobile node has
         multiple interfaces and is disconnected from its home link
         (e.g. failure of the interface, or movement).  In such a
         situation, Mobile IPv6 allows transparent redirection of flows
         using the old care-of address (i.e. the session was initiated
         using the home address) to another care-of address.  For
         sessions directly opened via the care-of address, the loss of
         the address implies a re-initiation of the session.

      What is missing for Mobile IPv6

         If the home agent fails, the session using the failed home
         agent must be restarted since Mobile IPv6 does not provide any
         mechanism to hand-over transparently from a home agent to
         another one.  Fault tolerance cannot be achieved in this case,
         since established communications cannot be preserved (unless
         mechanism such as [6] is used).  See the corresponding
         discussion in Section 6.1.4 and Section 6.2.3.

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

         Reliability through bi-casting could also be achieved by
         registering two addresses with a single home address.  However
         Mobile IPv6 does not provide any mechanism to associate more
         than one care-of address with one home address.  Moreover, in
         this particular case, one home address should be used as a
         care-of address bound to the other home address. (see in
         Section 6.2.1 and Section 6.3.1).

   o  Load Sharing

      What Mobile IPv6 can achieve

         In bidirectional tunnel mode, load sharing only affects the
         path between the correspondent node and the home agent(s), and
         not the path between the mobile node and the home agent(s), as
         long as the care-of address does not change.  In route
         optimization mode, the path between the mobile node and the
         correspondent node does not change if the care-of address does



Montavont, et al.       Expires November 4, 2008               [Page 12]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


         not change.  As an entry in the binding cache is identified by
         a home address, the mobile node can register the same care-of
         address with all home address, on any distant node.

      What is missing for Mobile IPv6

         A mechanism would be needed for the mobile node to select which
         home address should be used when a new communication flow is
         initiated.  A similar mechanism is needed on the correspondent
         node side if it knows that multiple home addresses are assigned
         to the same mobile node.  With such mechanisms, it would be
         possible to use multiple home addresses at the same time, and
         load sharing could be performed.  However, it can be noted that
         load sharing on the path between the correspondent node and the
         home agent might not be the most bandwidth contraint part of
         the overall path from the correspondent node to the mobile
         node.  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 mobile node register
         one home address as a care-of address for another home address
         (see in Section 6.3.1).

   o  Flow Distribution

      What Mobile IPv6 can achieve

         Flow distribution is achievable when the mobile node 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
         mobile node can spread flows over its interfaces.  Note that if
         a correspondent node initiates a communication, the interface
         that it will use on the mobile node would depend on which
         mobile node's address is advertised to the correspondent node.

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

   A mobile node in this configuration is multihomed since it has
   several care-of addresses.  This may occur when the mobile node 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 mobile node may be connected to its home
   link.

   We next analyze if Mobile IPv6 can be used to achieve the following
   multihoming benefits:





Montavont, et al.       Expires November 4, 2008               [Page 13]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   o  Reliability

      What Mobile IPv6 can achieve

         Reliability support is limited to recover from a failed care-of
         address.  Fault recovery is achieved in Mobile IPv6 by
         associating an alternate care-of address to replace the failed
         one.

      What is missing for Mobile IPv6

         Efficient mechanisms are needed to determine that a care-of
         address has failed (see Section 6.1.1), to check reachability
         (Section 6.1.2), to determine which care-of address should be
         used instead (Section 6.1.3) and to redirect flows to the new
         care-of address (Section 6.1.4).

   o  Load Sharing and Flow Distribution

      What Mobile IPv6 can achieve

         This configuration allows sharing of the load and setting of
         preferences among different paths between the home agent and
         the mobile node when bidirectional tunnel mode is used, and
         between the correspondent node and the mobile node when route
         optimized mode is used.

      What is missing for Mobile IPv6

         In order to achieve load sharing and flow distribution under
         this scenario, the mobile node would need to register several
         care-of addresses with its unique home addresses.  However, the
         present specification of Mobile IPv6 only allows the mobile
         node to register a single care-of address per home address.
         This is discussed in Section 6.2.1.  When a single home address
         is bounded to several care-of addresses at the same time, the
         mobile node, home agent, or correspondent node must be able to
         select the appropriate care-of address.  This selection could
         be done based on user/application preferences (see
         Section 6.1.3).

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

   A mobile node 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 mobile node has several home
   addresses, e.g. given by different operators (similar to case (n,1)
   in Section 5.2) and several care-of addresses, e.g. because the node



Montavont, et al.       Expires November 4, 2008               [Page 14]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   is receiving multiple IPv6 prefixes (similar to case (1,n) in
   Section 5.3).

   We next analyze if Mobile IPv6 can be used to achieve the following
   multihoming benefits:

   o  Reliability

      What Mobile IPv6 can achieve

         If one care-of address becomes unreachable (similar to (1,n)),
         the mobile node can redirect flows to another care-of address
         by binding any of the other available care-of address to the
         corresponding home address.  If the mobile node can not use one
         of its home addresses anymore (similar to (n,1)), the mobile
         node will have to re-initiate all flows which were using the
         corresponding home address.  Redirection between the addresses
         available for the mobile node will be different depending on
         the binding policies.

      What is missing for Mobile IPv6

         None specific to (n,n) configuration.

   o  Load Sharing and Flow Distribution

      What Mobile IPv6 can achieve

         Although Mobile IPv6 allows the mobile node to register only
         one care-of address per home address (see Section 6.2.1), it
         can register the same or different care-of addresses with
         multiple home addresses.  If the mobile node chooses to bind
         the same care-of address to all its home addresses, 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 home address may be used per correspondent node.
         If the mobile node chooses to bind a different care-of address
         for each home address, load sharing will be done along the
         whole path across the mobile node and its correspondent nodes.
         Preference settings may define which care-of address should be
         bound to which home address (see Section 6.1.3).

         In a very specific situation, one of the routable address of
         the mobile node (i.e., which can be directly used without
         tunneling to reach the mobile node) can be one of its home
         addresses.  This home address would then be viewed as a care-of
         address bound to another home address (similar to (n,1)).
         Mobile IPv6 does not prevent this behavior, which allows to set



Montavont, et al.       Expires November 4, 2008               [Page 15]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


         a certain preference on addresses usage.  See Section 6.3.1 for
         the corresponding issue.

      What is missing for Mobile IPv6

         None specific to (n,n) configuration.

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 home addresses to serve
   as the care-of address of another home address (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.  Analysis of which are already done in those section
   and is thus omitted.


6.  Multihoming Issues

   Existing protocols may not allow reaching 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 Mobile IPv6 solely, whereas other
   issues are not at all related to Mobile IPv6.  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 Mobile IPv6 (Section 6.2).  Other concerns related to
   implementations of Mobile IPv6 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



Montavont, et al.       Expires November 4, 2008               [Page 16]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   is broken (i.e., loss of connectivity), the path between the mobile
   node and the home agent 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, Mobile IPv6 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).

   [7] is addressing such concerns through the use of layer 2 triggers
   [8].  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
   mobile node and its correspondent node(s), as well as between the
   mobile node and its home agent(s), and between the home agent and
   correspondent node(s).

6.1.2.  Path Exploration

   When the mobile node 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
   mobile node and its home agent, and optionally between the mobile
   node and its correspondent node.  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 addresses
   to check reachability.  An additional protocol may be needed to
   perform this task.

   In (1,*), the path exploration consists in checking reachability
   between each care-of address and each home agent address.  If RO mode
   is used, the mobile node may also insure reachability between its
   correspondent nodes' address(es) and each care-of address.

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




Montavont, et al.       Expires November 4, 2008               [Page 17]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   In all these cases the path between the home agent and the
   correspondent node is not checked.  A specific mechanism may be
   defined to check reachability between a home agent and a
   correspondent node.

6.1.3.  Path Selection

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

   o  Interface selection

      When the mobile 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 mobile node is out of scope of Mobile IPv6 and might be
      implementation specific.  On the other hand, if the mobile node
      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 [9] could be used.

   o  Home Address Selection

      When multiple home addresses are available, the mobile node and
      its communicating peers (home agent and correspondent nodes) must
      be able to select the appropriate home address 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)
      [10] or DNS SRV Protocol (RFC2782) [11] 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 home address selection.






Montavont, et al.       Expires November 4, 2008               [Page 18]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   o  CoA Selection

      When multiple care-of addresses are available, the mobile node and
      its communicating peers must be able to select the appropriate
      care-of address to be used for a particular packet or flow.  The
      mobile node may use its internal policies to (i) distribute its
      flow, and (ii) distribute policies on distant nodes to allow them
      to select the preferred care-of address.  Solutions like [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 care-of address changes : it influences the
   path between the mobile node and its home agent, and the path between
   the mobile node and its correspondent node in RO mode.  This may hold
   in case (n, n).

   The second category is when the home address changes (: it influences
   the entire path.  As the home address is the address shown to the
   higher layer (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 home agent address changes.  In this
   case, the bidirectional tunnel between the mobile node and its home
   agent as to be switched to the new address of the home agent.  This
   can be managed transparently by Mobile IPv6 if the home address
   doesn't change at the same time.  Otherwise, sessions continuity is
   not ensured, as explained in the above paragraph.







Montavont, et al.       Expires November 4, 2008               [Page 19]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


6.1.5.  Ingress Filtering

   Ingress filtering mechanisms [15][16] may drop the outgoing packets
   when multiple bi-directional tunnels end up at different home agents.
   This could particularly occur if different prefixes are handled by
   different home agents.  If a packet with a source address configured
   from a specific prefix is tunneled to a home agent that does not
   handle that specific prefix, the packet may be discarded either by
   the home agent 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 the mobile node selects the interface (which would determine
   the care-of address) and the home network (which would determine the
   home address): the chosen care-of address may not be registered with
   the chosen home address.  For instance, consider Figure 2 below.  In
   the access network, the mobile node 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 and greatly limits the way
   mobile node can benefit from its multihoming configuration
   (particularly in case of the home agent failure since flows cannot be
   diverted to the other home agent).

                 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

   Should the mobile node be able to bind both care-of addresses PA.MN
   and PB.MN simultaneously to home addresses 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 home agent 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



Montavont, et al.       Expires November 4, 2008               [Page 20]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   since the choice of the home and care-of addresses is limited to a
   single (HoA, CoA) pair in other cases.  In (n,n), the mobile node 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 care-of addresses would be available to
   the mobile node.  In order to use them simultaneously, the mobile
   node must be able to bind and register multiple care-of addresses for
   a single home address with both the home agent and the correspondent
   nodes.  The Mobile IPv6 specification is currently lacking such
   ability.

   Although in the (n,n) cases, Mobile IPv6 allows the mobile node to
   have multiple (HoA,CoA) pairs, the upper layer's choice of using a
   particular home address would mean that the mobile node is forced to
   use the corresponding care-of address.  This constrains the mobile
   node from choosing the best (in terms of cost, bandwidth etc) access
   link for a particular flow, since care-of address is normally bound
   to a particular interface.  If the mobile node can register all
   available care-of addresses with each home address, this would
   completely decouple the home address from the interface, and allow
   the mobile node 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 mobile node can successfully bind a number of victims'
   addresses as valid care-of addresses for the mobile node with its
   home agent.  This is further elaborated in [19].  In view of such
   risk, it might be avisable for home agent implementations to employ
   some form of care-of addresses verification before using the care-of
   addresses as a valid routing path to mobile node when accepting
   multiple care-of address registrations.

6.2.2.  Simultaneous Location in Home and Foreign Networks

   Rule 4 of RFC3484 (section 5) specifies that a home address should be
   preferred to a care-of address.  While this rule allows the host to
   choose which address to use, it does not allow the mobile node 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 care-of addresses for
   the home address associated to the home link the mobile node is
   connected to.  As a result, flows cannot be redirected transparently



Montavont, et al.       Expires November 4, 2008               [Page 21]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   from one care-of address to another and Mobile IPv6 features can only
   recover the failure of the home address.

   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 home agent.

   This issue is currently being resolved by [18].

6.2.3.  HA Synchronization

   For a single home address obtained from a single home network, when a
   failure is affecting ongoing sessions on a given home agent (i.e.
   home agent has failed or is overloaded), solutions like [6] may be
   used to allowing existing sessions to be shifted from one home agent
   to another.  However, in the (n,*) cases where home addresses may be
   obtained from different home agents on different home networks, such
   coordination is not currently available.  To achieve a global home
   agent synchronization, it might be necessary to extend mechanisms
   such as proposed in [6], [20] and [21].

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 Mobile IPv6 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 mobile node has multiple home addresses.  A home
   address may be seen as a care-of address from the perspective of
   another home link of the same mobile node.

   As an example, a mobile node has two home addresses (HoA1 and HoA2)
   on two distinct home links.  The mobile node is connected to these
   two home links via two interfaces.  When the mobile node looses its
   connectivity on its first interface and HoA1 is not reachable, it may
   want to register HoA2 as a care-of address for HoA1 in order to keep
   receiving packets intended to HoA1, via the second interface.

   According to the definition of a care-of address, the current Mobile
   IPv6 specification does not prohibit to register a home address as
   the care-of address from the perspective of another home address.

   In RFC3775 section 6.1.7 it is written: "Similarly, the Binding



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

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   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 mobile node
   must be able to register whatever address it owns with any of its
   home address, as long as the above statement is observed.

6.3.2.  Binding a new CoA to the Right HoA

   In the (n,*) cases, the mobile node has multiple home addresses.
   When the mobile node moves and configures a new care-of address, the
   newly obtained care-of address must be bound to a specific home
   address.  The current Mobile IPv6 specification doesn't provide a
   decision mechanism to determine to which home address this newly
   acquired care-of address should be bound to.

   With no such mechanism, the mobile node may be confused and may bind
   this care-of address to a possibly wrong home address.  The result
   might be to bind the care-of address to the same home address the
   previous care-of address 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, Mobile IPv6 does not provide any information on how
   home addresses should be bound to a device, and particularly there is
   no mechanism to bind home addresses to interfaces.

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

                  HoA1          HoA2

             CoA1        CoA2         CoA3
            Iface1      Iface2       Iface3

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

   Home address must always be assigned to an activated interface and if
   the mobile node is connected to its home link, the corresponding home



Montavont, et al.       Expires November 4, 2008               [Page 23]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   address must be used on this interface.  In some cases, the home
   address 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.


      +==========================================================+
      |                           # 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 given HoA |   | o | ? | o | o |
      +--------------------------------------+---+---+---+---+---+
      | Simultaneous Location in Home and    |   | o | ? | o | o |
      |    Foreign Networks                  |   |   |   |   |   |
      +--------------------------------------+---+---+---+---+---+
      | HA Synchronization                   |   |   |   |   |   |
      +--------------------------------------+---+---+---+---+---+
      |            Implementation-Related Concerns               |
      +--------------------------------------+---+---+---+---+---+
      | Using one HoA as a CoA               |   |   | ? | o | o |
      +--------------------------------------+---+---+---+---+---+
      | Binding a new CoA to the Right HoA   |   |   | ? | o | o |
      +--------------------------------------+---+---+---+---+---+
      | Binding HoA to Interface(s)          | o | o | ? | o | o |
      +==========================================================+

              Figure 4: Summary of Issues and Categorization







Montavont, et al.       Expires November 4, 2008               [Page 24]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


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 node 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
   home addresses, care-of addresses 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.


8.  IANA Considerations

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


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 care-of addresses
   registration.


10.  Contributors

   The following people have contributed ideas, text and comments to
   earlier versions of this document: Eun Kyoung Paik from Seoul



Montavont, et al.       Expires November 4, 2008               [Page 25]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


   National University, South Korea and Thomas Noel from Universite
   Louis Pasteur, Strasbourg, France.


11.  Acknowledgments

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


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-03 (work in
         progress), May 2008.

   [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]   Wakikawa, R., "Home Agent Reliability Protocol",
         draft-ietf-mip6-hareliability-03 (work in progress),
         November 2007.

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

   [8]   Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and
         A. Yegin, "Link-Layer Event Notifications for Detecting Network



Montavont, et al.       Expires November 4, 2008               [Page 26]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


         Attachments", RFC 4957, August 2007.

   [9]   Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
         "Flow Bindings in Mobile IPv6 and Nemo Basic Support",
         draft-soliman-monami6-flow-binding-05 (work in progress),
         November 2007.

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

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

   [12]  Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R.
         Kuntz, "Flow Distribution Rule Language for Multi-Access
         Nodes", draft-larsson-mext-flow-distribution-rules-00 (work in
         progress), November 2007.

   [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, "Shim6: Level 3 Multihoming Shim
         Protocol for IPv6", draft-ietf-shim6-proto-10 (work in
         progress), February 2008.

   [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-07 (work in progress),
         April 2008.

   [19]  Lim, B., Ng, C., and K. Aso, "Verification of Care-of Addresses
         in Multiple Bindings Registration",
         draft-lim-mext-multiple-coa-verify-01 (work in progress),
         February 2008.

   [20]  Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home



Montavont, et al.       Expires November 4, 2008               [Page 27]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


         Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
         in progress), February 2004.

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


Appendix A.  Why a MN may want to redirect flows

   When a mobile node 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
   mobile node to redirect flow from one address to another:

   o  Failure detection: the path between the mobile node and its
      correspondent node(s) is broken.  The failure can occur at
      different places onto this path; The failure can be local on the
      mobile node, where the interface used on the mobile node 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 mobile node and one of
      its home agent.  Yet another alternative is that the failure can
      be on the path between the home agent and the correspondent node.
      If route optimization is used, it can also be a failure between
      the mobile node and its correspondent node(s).

   o  New address: a new address on the mobile node may become
      available, e.g. when the mobile node connects to the network with
      a new interface.  The mobile node may decide that this new
      interface is most suitable for its current flows that are using
      another interface.

   o  Uninterrupted horizontal handover in mobility: if the mobile node
      is mobile, it may have to change its point of attachment.  When a
      mobile node performs a horizontal handover, the handover latency
      (the time during which the mobile node can not send nor receive
      packets) can be long and the flows exchanged on the interface can
      be interrupted.  If the mobile node 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 [8].

   o  Change in the network capabilities: the mobile node can observe a
      degradation of service on one of its interface, or conversely an
      improvement of capacity on an interface.  The mobile node may then



Montavont, et al.       Expires November 4, 2008               [Page 28]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


      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
      mobile node and a correspondent node.  According to internal
      policies, the mobile node may want to redirect this flow on a most
      suitable interface.


Authors' Addresses

   Nicolas Montavont
   Institut Telecom - Telecom Bretagne
   2, rue de la chataigneraie
   Cesson Sevigne  35576
   France

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


   Ryuji Wakikawa
   Toyota ITC / Keio University
   6-6-20 Akasaka, Minato-ku
   Tokyo  107-0052
   Japan

   Phone: +81-3-5561-8276
   Fax:   +81-3-5561-8292
   Email: ryuji@jp.toyota-itc.com


   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 November 4, 2008               [Page 29]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


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

   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 November 4, 2008               [Page 30]

Internet-Draft      Analysis of Multihoming in MIPv6            May 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Montavont, et al.       Expires November 4, 2008               [Page 31]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/