IETF MIP6 Working Group                                     N. Montavont
Internet-Draft                                                      NIST
Expires: December 10, 2005                                   R. Wakikawa
                                                         Keio University
                                                                T. Ernst
                                                 WIDE at Keio University
                                                                   C. Ng
                                                Panasonic Singapore Labs
                                                          K. Kuladinithi
                                                    University of Bremen
                                                            June 8, 2005


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on December 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The use of multiple interfaces is foreseen to provide ubiquitous,



Montavont, et al.       Expires December 10, 2005               [Page 1]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   permanent and fault-tolerant access to the Internet, particularly on
   mobile nodes which are more prone to failure or sudden lack of
   connectivity.  However, Mobile IPv6 currently lacks support for such
   multihomed nodes.  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.







































Montavont, et al.       Expires December 10, 2005               [Page 2]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1   (1,1,1): 1 iface, 1 HoA, 1 CoA . . . . . . . . . . . . . . 12
     5.2   (1,n,1): 1 iface, n HoAs, 1 CoA  . . . . . . . . . . . . . 12
     5.3   (1,1,n): 1 iface, 1 HoA, n CoAs  . . . . . . . . . . . . . 13
     5.4   (1,n,n): 1 iface, n HoAs, n CoAs . . . . . . . . . . . . . 14
     5.5   (n,1,1): n ifaces, 1 HoA, 1 CoA  . . . . . . . . . . . . . 14
     5.6   (n,1,n): n ifaces, 1 HoA, n CoAs . . . . . . . . . . . . . 16
     5.7   (n,n,1): n ifaces, n HoAs, 1 CoA . . . . . . . . . . . . . 17
     5.8   (n,n,n): n ifaces, n HoAs, n CoAs  . . . . . . . . . . . . 18
     5.9   (n,n,0): n ifaces, n HoAs, no CoAs . . . . . . . . . . . . 18
   6.  Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.1   General IPv6-related Issues  . . . . . . . . . . . . . . . 20
       6.1.1   Path Selection . . . . . . . . . . . . . . . . . . . . 20
       6.1.2   Ingress Filtering  . . . . . . . . . . . . . . . . . . 21
       6.1.3   Media Detection  . . . . . . . . . . . . . . . . . . . 22
     6.2   MIPv6-specific Issues  . . . . . . . . . . . . . . . . . . 22
       6.2.1   Binding Multiple CoAs to a given HoA . . . . . . . . . 22
       6.2.2   Using one HoA as a CoA . . . . . . . . . . . . . . . . 22
       6.2.3   Simultaneous location in home and foreign networks . . 23
   7.  Considerations for MIPv6 Implementation  . . . . . . . . . . . 25
     7.1   Binding a new CoA to the right HoA . . . . . . . . . . . . 25
     7.2   Binding HoA to interface . . . . . . . . . . . . . . . . . 25
     7.3   Flow redirection . . . . . . . . . . . . . . . . . . . . . 26
   8.  TODO List  . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   9.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   10.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 30
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 30
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
       Intellectual Property and Copyright Statements . . . . . . . . 33















Montavont, et al.       Expires December 10, 2005               [Page 3]


Internet-Draft      Analysis of Multihoming in MIPv6           June 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 lack of connectivity.
   Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain
   its IPv6 communications while moving between IPv6 subnets.  However,
   the current specification of Mobile IPv6 lacks support for mobile
   nodes with multiple addresses used simultaneously, i.e. multihomed
   mobile nodes.  These addresses would be assigned to a single
   interface or to multiple interfaces, which poses a number of issues.

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

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

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

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

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



Montavont, et al.       Expires December 10, 2005               [Page 4]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


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













































Montavont, et al.       Expires December 10, 2005               [Page 5]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


2.  Terminology

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

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

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

   o  MIPv6

      The Mobile IPv6 protocol specified in [1]

   o  MN

      a Mobile Node operating MIPv6

   o  HA

      a Home Agent

   o  HoA

      Home Address

   o  CoA

      Care-of Address

   o  A valid address

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




Montavont, et al.       Expires December 10, 2005               [Page 6]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   o  Simultaneously using multiple addresses

      This indicates a scenario where the MN has the ability to use any
      of the said multiple addresses at the same time.  This implies
      that 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.

   o  Simultaneously using multiple interfaces

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





































Montavont, et al.       Expires December 10, 2005               [Page 7]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


3.  Requirements

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

   1.  Permanent and Ubiquitous Access

   2.  Redundancy/Fault-Recovery

   3.  Load Sharing

   4.  Load Balancing

   5.  Preference Settings

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

   Basically, Internet connectivity is guaranteed for a MN as long as at
   least one path is maintained between the MN and the fixed Internet.
   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 balancing).  The
   use of an alternative path must be transparent at layers above layer
   3 if broken sessions and the establishment of new transport sessions
   has to be avoided.

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

   Basically, this can translate into the following enumeration of
   requirements:

   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 interfaces must be able to use
      multiple interfaces simultaneously.

   o  A MN equipped 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).



Montavont, et al.       Expires December 10, 2005               [Page 8]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   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.

   o  The MN must be able to use multiple HAs simultaneously for a given
      home address.

   o  The MN must be able to use a distinct HA for each home address
      simultaneously.

   One has to consider whether these goals can be achieved with
   transparency or without transparency.  Transparency is achieved when
   switching between interfaces does not cause the disruption of on-
   going sessions.  To be achieved with transparency, a necessary (may
   or may not be sufficient) condition is for the end-point addresses 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.





























Montavont, et al.       Expires December 10, 2005               [Page 9]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


4.  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 in
   the present document the taxonomy (x,y,z) where:

   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.  A value '*' indicates that the number can be '1' or
   'n'.

   An illustration of this taxonomy is given in Figure 1.

              Mobile Node

           HoA1         HoA2   ... HoAn   --> Permanent Address (y)
            |            |          |
      +-----+--------+   |          |
      |     |        |   |          |
     CoA1   +--CoA2  +---CoA3  ... CoAn   --> Temporary Address (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 links is equal to the number of CoAs, z

                  Figure 1: Illustration of the Taxonomy

   As the taxonomy suggests, the fact that the mobile node has several
   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.  Similarly,
   the number of CoAs the node has is independent from the number of
   HoAs and the number of interfaces.  While a node would probably have
   at least one CoA per interface, multiple prefixes advertised on a



Montavont, et al.       Expires December 10, 2005              [Page 10]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   link may lead to the node building several CoAs on that link.

   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.

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







































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


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


5.  Scenarios

   In this section, we are detailing the possible benefits for each type
   of configuration.  For each configuration, we give a basic
   explanation and we list which of the goals outlined in Section 3 are
   achievable provided that supporting mechanisms are either already
   existing or could be defined.  Other goals are not achievable due to
   the inherent configuration of the node.  Then, we briefly discuss the
   current situation with MIPv6 and we point to issues discussed later
   in this document in Section 6 and Section 7.

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

   The MN is not multihomed.  The node has only one interface, with one
   HoA and is currently away from its home link.  A CoA is configured on
   the foreign link.  This is the usual scenario considered by Mobile
   IPv6 which would bind that CoA to the HoA.

   Achievable goals: none.

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

   The MN is multihomed, since it has several HoAs.  This case may
   happen when a node is getting access to the Internet through
   different HAs (possibly distinct operators) and each offers a Mobile
   IPv6 service to the node.  That way, the node will have a HoA per HA.
   Alternatively, though less commonly practiced, a single operator may
   have a multiple prefixed home link assigned to the mobile node, thus
   the mobile node would have multiple HoAs for a single home link.
   Either case, the node would need to configure a single CoA on the
   visited IPv6 subnet, and bind that single CoA to all the HoAs it
   owns.

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

   Current situation with MIPv6:

   o  Fault Recovery

      If there is a failure in one of the home network of the MN (e.g.,
      one HA of the MN is disconnected from the network) MIPv6 does not
      provide any mechanism to hand-over the communication to another
      HoA.  If a HoA, which is used at the transport layer by an
      application, needs to be changed, the application must be
      restarted.  MIPv6 does not allow changing of the HoA transparently
      for a given transport session.  Currently, fault recovery can
      therefore only be performed without transparency.  See the
      corresponding discussion in Section 7.3



Montavont, et al.       Expires December 10, 2005              [Page 12]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   o  Preference Settings and Load Sharing

      As an entry in the binding cache is identified by a HoA, the MN
      can register the same CoA with all HoAs, on any distant node.  A
      mechanism would then be needed for the MN to select which HoA
      should be used when a new communication flow is initiated.  A
      similar mechanism is needed on the CN side if it knows that
      multiple HoAs are assigned to the same MN.  With such mechanisms,
      it would be possible to use multiple HoAs at the same time, and
      load sharing could be performed.  See in Section 6.1.1 where such
      path selection issues are discussed.


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

   The MN is multihomed since it has several CoAs.  This case may occur
   when the interface of the node is connected to a link where multiple
   IPv6 prefixes are advertised.

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

   Current situation with MIPv6:

   o  Fault Recovery

      Fault recovery will be limited to the case where a prefix in the
      visited network is not advertised anymore, i.e. when the MN looses
      a CoA.  This is possible with MIPv6 as it can associate an
      alternate CoA to replace the failed CoA.  However, efficient
      mechanisms are needed to determine that a CoA has failed (see
      Section 6.1.3) and to determine which CoA should be used instead
      (see below).

   o  Preference Setting, Load Sharing and Bicasting

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







Montavont, et al.       Expires December 10, 2005              [Page 13]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


5.4  (1,n,n): 1 iface, n HoAs, n CoAs

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

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

   Current situation with MIPv6

   o  Fault Revovery

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

   o  Preference Settings, Load Sharing and Bicasting

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

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


5.5  (n,1,1): n ifaces, 1 HoA, 1 CoA

   This is a very special case of a node with multiple interfaces



Montavont, et al.       Expires December 10, 2005              [Page 14]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   connected to different IPv6 subnets.  The MN is multihomed if one of
   the interface is attached to a foreign link, the other one is
   attached to the home link.  Thus, the MN only configures one CoA on
   the foreign subnet, and one HoA on the home link.

   There cannot be more than two interfaces, otherwise the mobile node
   would either have (A) multiple interfaces on the home link, or (B)
   multiple interfaces on foreign links.  For (A), there would be
   multiple HoAs.  For (B) there would be multiple CoAs.

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

   Current situation with MIPv6:

   o  Fault Recovery and Ubiquitous Access

      These goals are achievable, but in a limited manner.  The MN can
      build a temporary IPv6 address on its other interface but it
      cannot register the temporary address with its HA because the node
      is using its HoA.  If the node needs to update its location
      following a movement, it will not be able to use its HoA on the
      interface connected to its home link.  This issue is detailed in
      Section 6.2.3.

      As MIPv6 cannot be used on these addresses, the MN will not be
      able to redirect any flow to another address.  For instance, if
      the MN looses its connection to its home link, all flows must be
      initiated again with the CoA address valid on the other interface
      of the MN.  Fault recovery is then only possible without
      transparency and none of the MIPv6 features can help in case of a
      failure.

   o  Preference Settings, Load Sharing and Load Balancing

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





Montavont, et al.       Expires December 10, 2005              [Page 15]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   o  Bicasting

      Bicasting should be possible since the MN has two addresses.  The
      MN should be able to request any CN to duplicate traffic to both
      addresses.  However, MIPv6 does not allow the MN to request
      bicasting on the CN (see Section 6.2.3).


5.6  (n,1,n): n ifaces, 1 HoA, n CoAs

   The MN is multihomed: the node has several addresses to choose from.
   This case regroups two different scenarios: either the MN is
   connected to its home link via one interface, or the MN is only
   connected to visited subnets via all its interfaces.  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 HA.

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

   Current situation with MIPv6:

   o  Fault Recovery

      Fault recovery is possible with MIPv6 whenever the MN looses one
      interface (and the CoA configured on this interface) as it can
      associate the CoA of an alternate interface to replace the failed
      one.  However, efficient mechanisms are needed to determine that
      an interface has failed (see Section 6.1.3) and to determine which
      interface should be used instead (see Section 6.1.1)

   o  Preference Settings, Load Sharing and Bicasting

      In order to achieve these goals under this scenario, the MN would
      need to register several CoAs with its unique HoA.  However, the
      present specification of MIPv6 only allows the MN to register a
      single CoA per HoA.  This is discussed in Section 6.2.1.  Having
      multiple interfaces and their associated CoAs available
      simultaneously, efficient mechanisms are needed to select the
      appropriate path (see Section 6.1.1).

   o  Flow redirection (Fault Recovery, Load Sharing, preference
      settings)

      If the MN has a connection to its home link and then uses its HoA
      on this interface, it will not be able to use MIPv6 mechanisms.



Montavont, et al.       Expires December 10, 2005              [Page 16]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


      The same conclusions can be drawn as in the previous case: the MN
      can choose from all its valid addresses to initiate a flow, but
      will not be able to redirect any of them (e.g., in case of
      preferences/address changing).  The interface used to receive a
      new flow from a CN will depend on the knowledge of the CN on the
      MN's addresses.

      If the MN is not connected to its home link, it can register
      (only) one CoA with its HoA.  In this case, if the registered CoA
      fails or changes, the MN will be able to redirect flows on another
      CoA.  For any flow directly started via one of the CoA, the MN
      would have to initiate it again in order to use an alternative
      address.  Thus fault recovery and preferences changes can only be
      done without transparency for other addresses than the registered
      CoA.  Load sharing and load balancing are subject to the same
      consideration as above.


5.7  (n,n,1): n ifaces, n HoAs, 1 CoA

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

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

   Current situation with MIPv6

   o  Fault Recovery and Ubiquitous Access

      If the MN is disconnected from its home link, MIPv6 allows the MN
      to redirect flows transparently to another CoA.  If the CoA
      changes (e.g., failure of the interface, or movement), MIPv6
      allows to transparently redirect flows which were using this
      address as temporarily address (i.e., communication is using a HoA
      as main address) to another address.  If sockets were directly
      opened via the CoA, loss of the address will imply to initiate
      again the communication.  In conclusion, fault recovery can only
      be done in some cases, when flows were initiated via a HoA.

   o  Preference Settings, Load Sharing, Load Balancing

      That case may be interpreted in different ways.  Either the MN is
      attached to one or several home links and one foreign link.  The
      CoA can be registered to HoAs of the MN, but the one used on the
      interface(s) connected to the home link.  The MN can distribute
      its flows among its interfaces by selecting the appropriated



Montavont, et al.       Expires December 10, 2005              [Page 17]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


      address.  CN can initiate flows intended to the MN via different
      addresses depending on the information it has on the MN.  It can
      be noted, that in some scenarios one HoA will be registered as CoA
      for another HoA (see discussions in Section 6.2.2).

   o  Bicasting

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


5.8  (n,n,n): n ifaces, n HoAs, n CoAs

   The MN 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 goals: ubiquitous access, fault recovery, load sharing,
   load balancing, bicasting, preference settings.

   Current situation with MIPv6

   o  Fault Recovery and Ubiquitous Access

      Flow redirection between interfaces is only possible if the
      corresponding socket was opened with a HoA at the application
      layer.

   o  Preference Settings, Load sharing, Load Balancing and Bicasting

      This can be achieved when the MN is initiating communication.
      Depending on the information about the MN on the CN side, multiple
      addresses may be advertised for the same MN, making possible for
      the MN to simultaneously use several interfaces.  However, only
      one CoA can presently be bound to a HoA (see discussion in
      Section 6.2.1).  This would limit the selection of addresses per
      flow to a selection of which CoA must be bound to which HoA.


5.9  (n,n,0): n ifaces, n HoAs, no CoAs

   This case happens when the interfaces are connected to their
   respective home links.  This node can be considered as a fixed node



Montavont, et al.       Expires December 10, 2005              [Page 18]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   from a multihoming point of view.  The node would no longer be in the
   (n,n,0) configuration when one or more of the interfaces are attached
   to foreign links.

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

   Current situation with MIPv6

   o  Fault Recovery and Ubiquitous Access

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

   o  Preference Settings, Load Sharing, Load Balancing

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

   o  Bicasting

      MN should be able to request bicasting from any CN, to duplicate
      traffic to several HoAs.  To do so, multiple addresses have to be
      registered with one HoA (see Section 6.2.1), and HoA(s) should be
      used as CoAs for other HoAs (see Section 6.2.2).















Montavont, et al.       Expires December 10, 2005              [Page 19]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


6.  Issues

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

   In this section, we described some of these issues in two main
   headings: general IPv6-related issues, and issues that are specific
   to MIPv6.  Other concerns related to implementation of MIPv6 are
   described in Section 7.

6.1  General IPv6-related Issues

6.1.1  Path Selection

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

   o  Interface selection

      In the (n,*,*) case, the node has multiple available interfaces.
      The simultaneous or selective use of several interfaces would
      allow a mobile node to spread flows between its different
      interfaces.

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

   o  HoA selection

      In the (*,n,*) cases, multiple HoAs would be available on the MN.
      The MN and its communicating peers (HA and CNs) must be able to
      select the appropriate HoA to be used for a particular packet or
      flow.

      This choice would be made at the time of a new communication flow



Montavont, et al.       Expires December 10, 2005              [Page 20]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


      set up.  Usual IPv6 mechanisms for source and destination address
      selection, such as [8] would be used.

   o  CoA selection

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

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

6.1.2  Ingress Filtering

   In the (n,*,n) case, a MN may be connected to multiple access
   networks or multiple home networks each practicing ingress filtering
   [9], [10].  Thus, to avoid ingress filtering, the selection of path
   would be limited by the choice of address used.  This is related to
   Section 6.1.1.  The problem of ingress filtering however, is two-
   fold.  It can occur at the access network, as well as the home
   network.  For instance, consider Figure 2 below.  In the access
   network, when mobile node MN sends a packet through AR-A, it must use
   CoA=PA.MN; and when MN sends a packet through AR-B, it must use
   CoA=PB.MN.  In the home network, when MN tunnels the packet to home
   agent HA-1, it must use HoA=P1.MN; and when MN tunnels the packet to
   home agent HA-2, it must use HoA=P2.MN.  This greatly limits the way
   MN can benefit from its multihoming configuration.

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

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

          Figure 2: MN connected to Multiple Access/Home Networks



Montavont, et al.       Expires December 10, 2005              [Page 21]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


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

6.1.3  Media Detection

   Currently, IPv6 has no clearly defined mechanism for detecting the
   availability or loss of media except through the ability or inability
   to receive router advertisements within a stipulated period.  Current
   effort [11] in the DNA Working Group aims to address this, such as
   through the use of layer 2 triggers [12].

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

6.2  MIPv6-specific Issues

6.2.1  Binding Multiple CoAs to a given HoA

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

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

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

6.2.2  Using one HoA as a CoA

   In (*,n,*) cases, the MN has multiple HoAs.  A HoA may be seen as a



Montavont, et al.       Expires December 10, 2005              [Page 22]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   CoA from the perspective of another home link of the same MN.

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

   According to the definition of a CoA, the current MIPv6 specification
   prohibits registering another HoA as a CoA.

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

   In other words, the BU must be discarded if the binding cache of the
   receiver is:

   Binding Cache:
   New BU:           HoA = addr1 w/ CoA = addr2
   existing entries: HoA = addr2 w/ CoA = addr3
                     HoA = addr3 w/ CoA = addr1

   But, in the following situation:

   Binding Cache:
   New BU:           HoA = addr1 w/ CoA = addr2
   existing entries: HoA = addr2 w/ CoA = addr3

   and no other entries in the binding cache concerning addr1/2/3.  In
   this case, the BU should be accepted.

   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.2.3  Simultaneous location in home and foreign networks

   In the (n,*,*), the mobile node may have one of its interfaces
   directly connected to a home link.  This may have an impact on the
   way multihoming is managed, since addresses from other interfaces
   cannot be registered as CoAs for the HoA associated to the home link
   the mobile node is connected on.



Montavont, et al.       Expires December 10, 2005              [Page 23]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


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
















































Montavont, et al.       Expires December 10, 2005              [Page 24]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


7.  Considerations for MIPv6 Implementation

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

7.1  Binding a new CoA to the right HoA

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

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

7.2  Binding HoA to interface

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

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

                  HoA1          HoA2

             CoA1        CoA2         CoA3
            Iface1      Iface2       Iface3

                Figure 3: Illustration of the case (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.





Montavont, et al.       Expires December 10, 2005              [Page 25]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


7.3  Flow redirection

   Internet connectivity is guaranteed for a MN as long as at least one
   path is maintained between the mobile node and its corresponding
   node.  When an alternative path must be found to substitute for a
   failed one, the loss of one path to the Internet may result in broken
   sessions.  In this case, new transport sessions would have to be
   established over the alternate path if no mechanism is provided to
   redirect flow transparently at layers above layer 3.  This could
   happen in the following situations:

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

      Although MIPv6 does not specify handovers between two interfaces,
      implementers should design a mechanism to allow a HoA to be re-
      bound to an alternative interface.  Such a implementation should
      take into consideration the use of connectivity triggers from
      multiple interfaces when performing movement detection.
      Mechanisms such as those specified in [13] can be used.

   o  In the (*,n,*) cases, the MN has multiple HoAs.  If one fails,
      established sessions on the failed HoA would break if no support
      mechanism is used to redirect flows from a failed HoA to another,
      unless the transport session has multihoming capabilities, such as
      SCTP, to allow dynamic changing of addresses used.























Montavont, et al.       Expires December 10, 2005              [Page 26]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


8.  TODO List

   Add a table to summarize issues

   Study security concerns

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

   Mention about relation with  Multi6 / Shim6.









































Montavont, et al.       Expires December 10, 2005              [Page 27]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


9.  Conclusion

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

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



































Montavont, et al.       Expires December 10, 2005              [Page 28]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


10.  Contributors

   The following people have contributed ideas, text and comments to
   this draft: Eun Kyoung Paik from Seoul National University, South
   Korea and Thomas Noel from Universite Louis Pasteur, Strasbourg,
   France, and Julien Charbon from Keio University, Japan.













































Montavont, et al.       Expires December 10, 2005              [Page 29]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


11.  Acknowledgments

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


12.  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., "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]   Soliman, H., Malki, K., and C. Castelluccia, "Per-flow movement
         in MIPv6", draft-soliman-mobileip-flow-move-02 (work in
         progress), July 2002.

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

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

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

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

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

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

   [12]  Yegin, A., "Link-layer Event Notifications for Detecting



Montavont, et al.       Expires December 10, 2005              [Page 30]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


         Network Attachments", draft-ietf-dna-link-information-01 (work
         in progress), February 2005.

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

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

   [15]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         draft-ietf-nemo-terminology-03 (work in progress),
         February 2005.

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


Authors' Addresses

   Nicolas Montavont
   National Institute of Standards and Technology
   100 Bureau Drive, Stop 1070
   Gaithersburg  20899-1070
   USA

   Phone: 301 975 2923
   Email: nicolas.montavont@nist.gov
   URI:   http://www-r2.u-strasbg.fr/~montavont/


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

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







Montavont, et al.       Expires December 10, 2005              [Page 31]


Internet-Draft      Analysis of Multihoming in MIPv6           June 2005


   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/


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

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


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

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
















Montavont, et al.       Expires December 10, 2005              [Page 32]


Internet-Draft      Analysis of Multihoming in MIPv6           June 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 December 10, 2005              [Page 33]