IETF MIP6 Working Group                                     N. Montavont
Internet-Draft                                               LSIIT - ULP
Expires: July 11, 2005                                       R. Wakikawa
                                                         Keio University
                                                                T. Ernst
                                                 WIDE at Keio University
                                                                 T. Noel
                                                             LSIIT - ULP
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                        January 10, 2005


                 Analysis of Multihoming in Mobile IPv6
        draft-montavont-mobileip-multihoming-pb-statement-03.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 July 11, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract




Montavont, et al.        Expires July 11, 2005                  [Page 1]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


   The use of multiple interfaces is foreseen to provide ubiquitous,
   permanent and fault-tolerant access to the Internet, particularly on
   mobile nodes which are more subject to failure or sudden lacks of
   connectivity.  However, Mobile IPv6 currently lacks support for such
   multihomed nodes.  Individual solutions have been proposed to extend
   Mobile IPv6 but all issues have not been addressed in a single
   document.  The purpose of the present document is thus to fill up
   this gap and to raise the discussion in order to make sure that
   forthcoming solutions will address all the issues.  In this document,
   we propose a taxonomy to classify the situations where a mobile node
   could be multihomed.  This taxonomy is then used to highlight the
   issues preventing mobile nodes operating Mobile IPv6 to be
   multihomed.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  9
     6.1   Deciding which HoA a new CoA should be bound to  . . . . .  9
     6.2   Binding Multiple CoAs to a HoA . . . . . . . . . . . . . . 10
     6.3   Using one HoA as a CoA . . . . . . . . . . . . . . . . . . 10
     6.4   Using multiple interfaces simultanouely  . . . . . . . . . 10
     6.5   Relationship between interfaces and HoAs . . . . . . . . . 10
     6.6   Flow redirection . . . . . . . . . . . . . . . . . . . . . 11
     6.7   Flows filtering  . . . . . . . . . . . . . . . . . . . . . 11
     6.8   Multiple HoAs  . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 16















Montavont, et al.        Expires July 11, 2005                  [Page 2]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


1.  Introduction

   The use of multiple addresses (allocated to either a single interface
   or multiple interfaces) is foreseen to provide ubiquitous, permanent
   and fault-tolerant access to the Internet, particularly on mobile
   nodes which are prone to failure or sudden lacks of connectivity.
   Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain
   its IPv6 communications while moving between IPv6 subnets.  However,
   the current specification of Mobile IPv6 lacks support for mobile
   nodes with multiple addresses used simultaneously, i.e.  multihomed
   mobile nodes.  These addresses would be assigned to a single
   interface or to multiple interfaces, which poses a number of issues.
    Individual solutions have been proposed to extend Mobile IPv6 for
   multihomed mobile nodes, but all issues have not been addressed in a
   single document.  The purpose of the present document is thus to fill
   up this gap by listing such issues, raising the discussion at the
   IETF, and placing some requirements in order to propose comprehensive
   solutions in forthcoming standards.

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

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

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

   The document is organized as follows: in the first section, we
   introduce terminology related to multihoming.  Then we propose a
   taxonomy to classify the different cases where mobile nodes are
   multihomed.  We then present requirements for multihomed MN.
   Thereafter the taxonomy is used to describe the multihoming scenarios
   specific to Mobile IPv6.  Finaly we list all open issues related to a



Montavont, et al.        Expires July 11, 2005                  [Page 3]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


   multihomed MN and identify what is missing to reach goals fixed in
   [3].

2.  Terminology

   The terms used in the present document are defined in [4], [1] and
   [3].  From now on we will use the abbreviations MIP6 for Mobile IPv6
   and MN for a "Mobile Node operating MIP6".

   In [3], a node is said to be multihomed when it has multiple IPv6
   addresses, either because multiple prefixes are advertised on the
   link(s) the node is attached to, or because the node has multiple
   interfaces (see the entire definition).

   For a mobile node operating MIP6, this may translate into the MN
   having multiple HoAs and/or multiple CoAs:

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

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

   A valid address is an address topologically correct (it is named
   after the prefix advertised on the link the interface is attached to)
   and routable.

   A MN is said to be "simultaneously using multiple addresses" if the
   MN has the ability to use any of the said multiple addresses at the
   same time.  This implies that the MN is able to receive packets with
   destination address field equals to any of the said multiple
   addresses, and the MN is able to choose any of the said multiple
   addresses as the source address of the packets it is sending.

   A MN is said to be "simultaneously using multiple interfaces" if
   there is at least one valid address named for each of the said
   multiple interfaces, and that the MN is able to simultaneously use
   these addresses.

3.  Taxonomy

   In order to aid the discussion of the benefits of multihoming as
   listed in [3] from the perspective of a mobile node, we will use the
   following taxonomy in this document:





Montavont, et al.        Expires July 11, 2005                  [Page 4]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


   o  x = number of active interfaces

   o  y = number of Home Addresses (HoAs)

   o  z = 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.  An illustration of this taxonomy is given in Figure
   1.

              Mobile Node

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


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

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

                 Figure 1: Illustration of the Taxonomy

   The variable y indicates the number of HoAs allocated to a node.  A
   node may have multiple HoAs (y=n) when either:

   o  The node has only one home link, and all its HoAs are based on the
      same IPv6 prefix (e.g.  the node may have multiple interfaces).

   o  The node has only one home link, and multiple HoAs with distinct
      prefixes because there are several IPv6 prefixes advertised on the
      home link.

   o  The node has several home links, and thus has at least two HoAs
      with different IPv6 prefixes.

   As the taxonomy suggests, the fact that the mobile node has several



Montavont, et al.        Expires July 11, 2005                  [Page 5]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


   HoAs is independent from the fact that the mobile node has multiple
   interfaces.  The fact that the mobile node has multiple interfaces
   does not imply that it has multiple HoAs and vice-versa.

   We propose a taxonomy with three 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
   configuration.  According to the number of interfaces, a mobile node
   can indeed expect different benefits.  If several interfaces are
   available, they can for instance be used simultaneouly to save
   bandwidth.  If only one interface is available at a time but the node
   is still multihomed, multiple source / destination addresses or
   multiple HAs may be used according to the type of traffic.  This
   feature could also allow load balancing.

   The number of HoAs and CoAs help to consider all scenarios of
   multihomed nodes.  These parameters will have an impact on the way
   multihoming is supported.  According to the number of HoAs and CoAs,
   different policies will be needed, such as which CoA have to be
   mapped with which HoA, do all the CoAs need to be mapped with all the
   HoAs, etc.

4.  Requirements

   To achieve the benefits of multihoming as described in [3], some
   requirements on the MN might have to be fulfilled.  These include:

   o  The MN must have a valid address on each link an interface is
      attached to.

   o  The MN must have either multiple interfaces with at least a single
      valid IP address on each interface, or a single interface with
      more than one valid address.

   o  A MN equipped with multiple interface must be able to use multiple
      interfaces simultaneously.

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

   o  If several interfaces are activated and configured with valid
      addresses, the MN should be able to share its traffic load among
      these interfaces.

   o  If an interface is used as backup and the primary interface failed
      (loss of connection), a mechanism should be available to quickly
      activate the backup interface and redirect traffic.



Montavont, et al.        Expires July 11, 2005                  [Page 6]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


   o  The MN must be able to use multiple Home Agents simultaneously if
      they are available

   o  When considering the goals/benefits defined in [3], 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.  In order to achieve transparency, a necessary (may or
      may not be sufficient) condition is for the end-point addresses to
      remain unchanged.  This is in-view of the large amount of Internet
      traffic today are carried by TCP, which unlike SCTP, cannot handle
      multiple end-point address pairs.

   We will next analyse issues arising from current Mobile IPv6
   Specifications when trying to fulfill these requirements.

5.  Scenarios

   This section is split into two parts according to the number of
   interfaces on the mobile node.  This distinction is made to help the
   reader to better understand the different cases, but also because the
   benefits for the mobile node will be different according to this
   parameter.

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

       The node is not multihomed.  The node has only one interface,
       with one HoA and is currently away from its home link (one CoA on
       the foreign link).

       Achievable benefits: none.

   2.  (1,n,1): 1 iface, several HoAs, 1 CoA

       The node is multihomed, since it has several HoAs.  This case may
       happen when a node is getting access to Internet through
       different ISPs and each offers a Mobile IPv6 service to the node.
       That way, the node will have a HoA per ISP.  Once the node is
       connected to a visited IPv6 subnet, it gets one CoA.  This CoA
       may be registered with all the Home Agents provided by the ISPs,
       in order to remain simulteneously reachable through all its HoAs.

       Achievable benefits: fault recovery, load sharing, preference
       settings.

   3.  (1,1,n): 1 iface, 1 HoA, several CoAs

       The node is multihomed since it has several CoAs.  This case may



Montavont, et al.        Expires July 11, 2005                  [Page 7]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


       occur when the interface of the node is connected to a link where
       multiple IPv6 prefixes are advertised.

       Achievable benefits: fault recovery, load sharing, bicasting,
       preference settings.

   4.  (1,n,n): 1 iface, several HoAs, several CoAs

       The node is multihomed, since it has multiple addresses.  This
       case can be viewed as a combination of the two cases described
       above: the node has several HoAs (e.g.  given by different ISPs)
       and several CoAs (e.g.  because the node is receiving multiple
       IPv6 prefixes).

       Achievable benefits: fault recovery, load sharing, bicasting,
       preferences settings.

   5.  (n,1,1): n ifaces, 1 HoA, 1 CoA

       The node is multihomed: this is a special case of a node with two
       interfaces connected to different IPv6 subnets; one of the subnet
       is the home network of the node and allows the node to directly
       use its HoA (without the MIPv6 mechanisms).  The node can build a
       temporarily IPv6 address on its other interface but it cannot
       register the temporary address with its Home Agent because the
       node is using its HoA.  If the node decides to update its
       location, it will not be able to use its HoA on the interface
       connected to its home link.

       Achievable benefits: ubiquitous access, fault recovery, load
       sharing, load balancing, preference settings

   6.  (n,1,n): n ifaces, 1 HoA, several CoAs

       The node is multihomed: the node has several addresses to choose
       from.  For example, consider a node with several interfaces, each
       connected to an IPv6 network (the same or not).  In this example,
       at least one global IPv6 address is configured on each interface.
       The node has only one home link, and only one Home Agent.

       Achievable benefits: ubiquitous access, fault recovery, load
       sharing, load balancing, bicasting, preference settings

   7.  (n,n,1): n ifaces, several HoA, one CoA

       The node is multihomed.  This case extends the case (n,1,1) when
       the node has several HoAs, for example from multiple ISPs.  The
       CoA can be associated with each HoA.



Montavont, et al.        Expires July 11, 2005                  [Page 8]


       Achievable benefits: ubiquitous access, fault recovery, load
       sharing, load balancing, bicasting, preference settings

   8.  (n,n,n): n ifaces, several HoAs, several CoAs

       The node is multihomed.  Many scenarios may lead to this case.
       For example, 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
       advertised.

       Achievable benefits: ubiquitous access, fault recovery, load
       sharing, load balancing, bicasting, preference settings


6.  Problem Statement

   Internet connectivity is guaranteed for a MN as long as at least one
   path is maintained between the MN and the fixed Internet.  When an
   alternative path must be found to substitute a failed one, the loss
   of the previous path may result in broken sessions.  New transport
   sessions would have to be established over the alternate path if no
   mechanism is provided to make this change transparent at layers above
   layer 3.

   In order to meet other expected benefits of multihoming, multiple
   paths may be maintained simulateneously (e.g.  for load balancing,
   load sharing) or not (e.g.  for redundancy) between the mobile node
   and the home network(s).  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 fault
   recovery, preferences) or to split traffic between multiple paths
   (e.g.  for load sharing, load balacing)

   Existing protocols may not be able to handle such cases.  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 MIP6 solely, whereas other issues are not at all
   related to MIP6.  However, such non MIP6 issues must be solved in
   order to reach all the goals of multihoming.

6.1  Deciding which HoA a new CoA should be bound to

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

   With no such mechanism, the MN may be confused and may bind this CoA



Montavont, et al.        Expires July 11, 2005                  [Page 9]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


   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.2  Binding Multiple CoAs to a HoA

   In the (*,1,n) cases, multiple CoAs would be available on the MN.
   However, the current MIP6 specification doesn't allow to register
   multiple CoAs for a single HoA.

6.3  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 disctinct
   home links.  MN is connected to these two home links via two
   interfaces.  If the MN looses its connectivity on its first
   interface, HoA1 is not reachable.  It may then want to register HoA2
   as a CoA for HoA1 in order to keep receiving packets intended to
   HoA1, via the second interface.

   According to the definition of a CoA, the current MIP6 specification
   prohibits to register another HoA as a CoA.  In order to counter
   this, a MN must be able to register whatever address it owns with any
   of its HoA.  A mechanism is needed to determine how to decide which
   HoA will be chosen and the definition of a HoA and CoA might be
   extended.

6.4  Using multiple interfaces simultanouely

   In (n,*,*) cases, the MN has multiple interfaces.  The simultaneous
   use of several interfaces would allow a mobile node to spread its
   different flows between its interfaces.  MIP6 does not presently
   allow the MN to register and use several interfaces simultaneously,
   regardless the number of HoAs and CoAs the mobile node may have and
   regardless the network topology the mobile node is connected to.

6.5  Relationship between interfaces and HoAs

   In (*,n,*) cases, MIPv6 does not define any relation between HoAs and
   interfaces, and particularly there is no mechanism to bind HoAs to
   interfaces.  For example, consider a MN equipped with two HoAs and
   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.




Montavont, et al.        Expires July 11, 2005                 [Page 10]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


                  HoA1          HoA2

         CoA 1        CoA2         CoA3
         Iface1       Iface2      Iface3

               Figure 2: Illustration of the case (3,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.6  Flow redirection

   In the (n,*,*) cases, the MN has multiple interfaces.  If one
   interface fails, established sessions on the failed interface would
   break if no support mechanism is used to redirect flows from the
   failed interface to another.

   MIP6 allows a MN to move transparently from one access link to
   another access link when the same interface is used, i.e.  in cases
   (1,*,*).  However, in cases (n,*,*), MIP6 doesn't provide a mechanism
   to transmit traffic established over one interface to another
   interface.

   Movement detection might be extended to include other triggers such
   as the loss of connectivity on one interface.  Moreover, the chosen
   mechanism must work whatever the previous bindings the MN has
   registered.  The redirection between interfaces can be performed
   transparently to the MNs if mechanisms such as specified in [5] are
   brought to the MN.

6.7  Flows filtering

   In the (n,*,*) case, the node has multiple interfaces.  If each
   interface may be used differently according to some 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.

   In order to optimize the global connectivity of a multihomed node, a
   specific mechanims may allow a multihomed node to set filters on
   flows on distant nodes (Correspondent Node or Home Agent), such as
   mechanisms proposed by [6], [7] and [8].






Montavont, et al.        Expires July 11, 2005                 [Page 11]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


6.8  Multiple HoAs

   In the (n,*,*) cases listed in Section 5, the node may have one of
   its interfaces directly connected to a home link.  This may have an
   impact on the multihoming management.

   For example, if we consider the case (n,n,n) with a node having three
   interfaces, three HoAs and two CoAs (connected to two visited IPv6
   subnets), the CoAs cannot be registered with the Home Agent serving
   the node on the home link it is connected to.

   Otherwise, the case (n,n,n) can translate into either case (n,n,1) or
   (n,n,0) according to the way the node is connected to the Internet.
   Case (n,n,1) only happens when the node is connected to a visited
   link with only one interface and obtain only one CoA.  Other
   interfaces are connected to the home link(s).  In the case (n,n,0),
   i.e.  several interfaces, several HoAs, and no CoA, all interfaces of
   the node are connected to their respective home links.

7.  Conclusion

   In this document, we have raised issues related to multihoming.  Even
   if MIPv6 can be used as mechanism to manage multihomed MN, triggers
   of flows redirection between interfaces/addresses are not adapted to
   the multihoming status of the node.  Also, we have shown that in some
   scenarios MIPv6 is ambigous in the CoA / HoA definition and in the
   mapping between HoAs, CoAs and CoAs.  Finaly, we have also raised
   issues not directly related to MIPv6, but which are needed to achieve
   benefits described in [3].

8.  Contributors

   The following people have contributed ideas, text and comments to
   this draft: Koojana Kuladinithi, Eun Kyoung Paik.

9.  Acknowledgments

   The authors would like to than all the people who have sent comments
   so far, particularly Tobias Kufner for raising new issues.


10  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



Montavont, et al.        Expires July 11, 2005                 [Page 12]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


         Agents", RFC 3776, June 2004.

   [3]   Ernst, T., "Goals and Benefits of Multihoming",
         draft-multihoming-generic-goals-and-benefits-00 (work in
         progress), February 2004.

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

   [5]   Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for
         Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in
         progress), July 2002.

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

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

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

   [9]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-02 (work in progress), October
         2004.

   [10]  Wakikawa, R., "Multiple Care-of Addresses Registration",
         draft-wakikawa-mobileip-multiplecoa-03 (work in progress), July
         2004.

   [11]  Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay
         Networks", Journal Mobile Networks and Applications, vol. 3,
         number 4, pages 335-350, 1998.















Montavont, et al.        Expires July 11, 2005                 [Page 13]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


Authors' Addresses

   Nicolas Montavont
   LSIIT - Univerity Louis Pasteur
   Pole API, bureau C444
   Boulevard Sebastien Brant
   Illkirch  67400
   FRANCE

   Phone: (33) 3 90 24 45 87
   EMail: montavont@dpt-info.u-strasbg.fr
   URI:   http://www-r2.u-strasbg.fr/~montavont/


   Ryuji Wakikawa
   Keio University
   Jun Murai Lab., 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.mobileip.jp/


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

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













Montavont, et al.        Expires July 11, 2005                 [Page 14]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


   Thomas Noel
   LSIIT - Univerity Louis Pasteur
   Pole API, bureau C444
   Boulevard Sebastien Brant
   Illkirch  67400
   FRANCE

   Phone: (33) 3 90 24 45 92
   EMail: noel@dpt-info.u-strasbg.fr
   URI:   http://www-r2.u-strasbg.fr/~noel/


   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: cwng@psl.com.sg






























Montavont, et al.        Expires July 11, 2005                 [Page 15]


Internet-Draft    Analysis of Multihoming in Mobile IPv6    January 2005


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Montavont, et al.        Expires July 11, 2005                 [Page 16]