[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
HIPRG                                                     A. de la Oliva
Internet-Draft                                                      UC3M
Intended status: Experimental                                 M. Bagnulo
Expires: January 3, 2008                             Huawei Labs at UC3M
                                                            July 2, 2007


           Fault tolerance configurations for HIP multihoming
                     draft-oliva-hiprg-reap4hip-00

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 3, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document considers scenarios for the provision of fault
   tolerance capabilities in multihomed HIP nodes.  In order to support
   such configurations, this document updates the behaviour for HIP
   multihoming nodes currently defined and defines the integration of
   the REAP protocol in HIP.





de la Oliva & Bagnulo    Expires January 3, 2008                [Page 1]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


Table of Contents

   1.  Introducion  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Locator management . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Failure detection and alternative path exploration for HIP . .  5
     3.1.  Multihoming scenario . . . . . . . . . . . . . . . . . . .  5
     3.2.  Failure detection and recovery . . . . . . . . . . . . . .  7
     3.3.  Processing of the REAP messages  . . . . . . . . . . . . .  8
   4.  HIP comformant REAP messages . . . . . . . . . . . . . . . . .  9
     4.1.  KeepAlive Message  . . . . . . . . . . . . . . . . . . . .  9
     4.2.  Probe Message  . . . . . . . . . . . . . . . . . . . . . . 11
     4.3.  Keepalive Timeout Option Format  . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   6.  Acknoledgements  . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 18


































de la Oliva & Bagnulo    Expires January 3, 2008                [Page 2]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


1.  Introducion

   Multihoming support for HIP is defined in draft-ietf-hip-mm [2].  It
   relies on the usage of UPDATE messages to convey information about
   the alternative locators available for the HIP nodes.  The
   aforementioned specification defines the basic support for
   multihoming and covers some basic scenarios but it postpones the
   analysis of more advanced multihoming scenarios for future study.
   This document considers additional multihoming scenarios, especially
   focussing on the provision of fault tolerance capabilities in
   multihomed HIP nodes.  In order to support such fault tolerant
   configurations, this document updates the behaviour for HIP
   multihoming nodes defined in [2] and defines the integration of the
   REAP protocol as defined in draft-ietf-shim6-failure-detection [4] in
   HIP.


2.  Locator management

   A multihomed HIP node has multiple locators that can have different
   reachability status.  Some of them can be operational/reachable while
   other may be not.  Fault tolerance is a preferred capability of such
   configuration.  In order to provide basic fault tolerance support, a
   HIP node should be able to perform the following functions: First,
   the multihomed HIP nodes must be able to convey the locally available
   locator set to the peer.  Second, the nodes should be able to monitor
   the communication and detect failures.  In case that a failure is
   detected, they must be able to discover alternative working locator
   pairs and divert the communication through the alternative locator
   pair.  In this section, we focus in the locator management part, and
   in the next section we will focus on the failure detection and
   alternative path exploration part.  It should be noted that for the
   provision of basic fault tolerance capabilities, the locators are
   managed following the following guidelines:
   o  All the locators available for each peers that are to be used to
      provide fault tolerance must be exchanged early in the
      communication, so they can be used as alternative locators in case
      of a failure.  This is different from the mobility case described
      in [2] since the peers only know a single locator of the peer at
      the time.
   o  However, the locators are only used sequentially and not in
      parallel.  This is so, because as long a locator pair is working,
      the peers stick to that pair for exchanging data packets and they
      only change the locator pair used when there is a failure.  This
      is different from the general multihoming scenario considered in
      [2] since locator pairs are not used in parallel.  This particular
      constraint reduces considerably the possibility of packet
      reordering and hence the possibility of having problems with the



de la Oliva & Bagnulo    Expires January 3, 2008                [Page 3]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


      reply protection window due to reordering of packets that travel
      through different paths.

   In the general multihoming scenario defined in [2], a multihomed node
   is recommended to create different SAs and use different SPIs for
   each locator pair available for the communication between two
   multihomed nodes to avoid problems with the anti-replay protection
   window resulting from reordering packets when using multiple paths
   simultaneously.  While this is required for the general multihoming
   scenario, this is an expensive approach, because it requires a high
   number of SAs to be created and it also requires a significant
   signaling overhead.  Basically in a multihoming scenario where a
   multihomed node A that has m locators is communicating with another
   multihomed node B that has n locators, they need to exchange m+n
   UPDATE messages to convey all the locator information.  This is so,
   because they need to convey SPI information for each of the locator
   pairs.  Node A does so by sending an n UPDATE messages.  Each one of
   these n UPDATE messages contains the m locally available locators
   with an SPI value for each locator.  Each of the n UPDATE messages is
   addressed to a different locator of the n available at node B. In
   this way, the information of the m*n SPIs values for the different
   locator pairs is exchanged between the peers.  While all the overhead
   and complexity is required when using multiple locator pairs in
   parallel, this is not the case for a fault tolerant configuration,
   where the locator pairs will be used sequentially.  Hence, in the
   document we define a modified behaviour for HIP multihomed nodes for
   fault tolerance support.

   For fault tolerance, only sequential use of locator pairs is
   required.  This is similar to the mobility case, the difference being
   that the locator set for each peer is known beforehand.  In order to
   support this configuration, the following behaviour is defined for
   HIP nodes.  Each node will convey the available locator set
   information to the peer in a single UPDATE message.  The Old SPI and
   the New SPI values of the LOCATOR parameter will be equal and set to
   the current SPI value for every locator in the message.  Each node
   will use a single SA and a single SPI value for all the locator pairs
   available for the configuration.  Only a single locator pair will be
   active, and all the traffic will be sent using the preferred (active)
   locator pair.  Upon the reception of one UPDATE message containing
   multiple locators with a single SPI value for both the OlD SPI and
   the New SPI for all the locators, the receiver will verify the
   locators contained in the UPDATE message as defined in [2].  After
   that, the receiver will identify that it is in the fault tolerance
   scenario and will create locator pairs using all the received
   locators and all the locally available locators, irrespectively of
   the locator to which the UPDATE message was sent.  The result is that
   each of the peers will have all the locator pairs available for use



de la Oliva & Bagnulo    Expires January 3, 2008                [Page 4]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


   in case that a failure occurs.

   After the locator sets have been exchanged, the peers use the REAP
   protocol as defined in the next section to detect failure, explore
   alternative locator pairs and divert the communication through
   alternative working locators.


3.  Failure detection and alternative path exploration for HIP

   Multihoming support for the HIP protocol as defined in [2] relies in
   the usage of the UPDATE message to convey multiple alternative
   locators for a given HI/HIT that is being used as identifier for
   ongoing communications between two nodes.  By including alternative
   locators associated to the multihoming configuration, the
   communication between the two nodes is more reliable, since it is
   possible to use alternative locator pairs in case the original one
   should fail.  As currently defined, the HIP protocol is capable of
   exchanging the alternative locators, validate them and use them to
   exchange packets.  However, the capabilities required for detecting
   failures and exploring alternative working locators are still
   lacking.  The REAP protocol [4] provides such capabilities for the
   Shim6 protocol [3] and can be used to provide the lacking failure
   detection and path exploration capabilities in HIP.  This section
   defines how the REAP protocol [4] can be used to detect failures and
   explore alternative paths between two hosts using HIP multihoming.

3.1.  Multihoming scenario

   The considered scenario consists of two HIP hosts that are
   communicating.  At least one of them has multiple locators which may
   have different reachability status.  In order to benefit from the
   enhanced fault tolerance capabilities resulting from multihoming, the
   decide to exchange the alternative locators available at each end.

   The exchange of the locator set of each end host can be performed in
   two ways:
   o  Each end point of the communication may send a LOCATOR parameter
      on R1 and I2 messages of the HIP connection establishment as
      defined on [2].
   o  The HIP protocol specified on [1] supports the modification of the
      locator set currently being used by the exchange of the UPDATE
      message.

   Herein we describe the use of the UPDATE packet to exchange the
   locator set but a similar scenario would result if the locator sets
   were exchanged using the R2 and I2 messages.




de la Oliva & Bagnulo    Expires January 3, 2008                [Page 5]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


   The exchange of locators in the UPDATE packet is secured by the use
   of HMAC and HIP_SIGNATURE on the message.  A number of combinations
   of parameters in an UPDATE packet are possible (see [2]).  In this
   scenario we consider the case where one LOCATOR and one ESP_INFO
   parameter is used in any HIP packet.  Other configurations may be
   possible although are out of the scope of this document.  As
   specified on [2] the LOCATOR parameter should list all the locators
   that are active on the HIP association, so the UPDATE packet sent to
   the peer will inform of all the locators which can be used to reach
   the host on this HIP association.

   The locators stored on the LOCATOR parameter may be:
   o  IPv6 or an IPv4-in-IPv6 format IPv4 adress (for non ESP based
      usage).
   o  The concatenation of an ESP SPI (first 32 bits) followed by an
      IPv6 address or IPv4-in-IPv6 format IPv4 address (128 bits) for
      ESP use.

   On the LOCATOR parameter, there is a bit (P) which express the
   preferred locator.  This bit must be set to one on the active locator
   for this communication and 0 in all the others to prevent a change of
   the active locators.

   The UPDATE packet may contain a ESP_INFO parameter, rules for
   processing this parameter are given on [2] and are assumed to be
   valid on this document.  Once an UPDATE message is received, the
   locators listed on the LOCATOR parameter are processed following the
   guidelines of [2].  After the processing, the SA will have a list
   with all the available addresses of the peer.  The address in use
   will be on ACTIVE state and the rest will be on UNVERIFIED state.
   Note that in [2] is stated that after receiving an UPDATE message
   with a LOCATOR parameter included, the only valid locator pairs
   created are between the new locators added and the source address of
   the UPDATE message.  We extend this behaviour on Section 2 to allow
   the creation of pairs between all the locators of both endpoints.

   Note that with this approach a communication between two endhosts
   (A,B), having A n possible locators and B m, leads to an SA with n*m
   valid locator pairs.  Once finished the locator exchange, we assume
   each endhost SA will have n*m valid locator pairs.

   At this stage, the hosts are ready to benefit from the enhanced fault
   tolerance capabilities resulting from multihoming, and use the REAP
   protocol to detect failures in the current locator pair and to
   explore alternative working locators pairs in case the current one
   should fail.  We describe how this is done in the following section.





de la Oliva & Bagnulo    Expires January 3, 2008                [Page 6]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


3.2.  Failure detection and recovery

   The REAP protocol [4] defined in the Shim6 architecture [3] provides
   path failure detection and alternative path exploration capabilities
   between two multihomed hosts.  It relies in two mechanisms, namely,
   the failure detection mechanism and the path exploration mechanism.

   The failure detection mechanism is based on the Forced Bidirectional
   Detection (FBD) technique, which consists on making sure that
   whenever there is data traffic in one direction, there is also
   traffic in the other direction.  This is accomplished by injecting
   additional control messages (called KeepAlives messages) when needed,
   which guarantee that the frequency of traffic in the reverse
   direction is above a predetermined threshold.  The result is that
   when there is a ongoing data communication between two REAP peers,
   both peers can expect an incoming traffic frequency that is above the
   predetermined threshold defined by REAP.  If the incoming traffic
   frequency is below this threshold, then this implies that a failure
   has occurred.  In other words, after a given period of time no
   traffic has been received a failure on the path is assumed and the
   alternative path exploration mechanism is triggered.

   The current implementation the REAP protocol relies on two timers,
   the Keep Alive Timer and the Send Timer, and a control message,
   namely the Keepalive message.  The Keep Alive Timer TKA is started
   each time a node receives a data packet from its peer, and stopped
   and reset, each time the node sends a packet to the peer.  When the
   Keep Alive Timer expires, a Keep Alive message is sent to the peer.
   The Send Timer TSend, defined roughly as three times the Keep Alive
   Timer plus a deviation to accommodate the Round Trip Time, is started
   each time the node sends a packet and stopped each time the node
   receives a packet from the peer.  If no answer (either a Keep Alive
   or data packet) is received in the Send Timer period a failure is
   assumed and a locator path exploration is started.  Consequently, the
   Send Timer reflects the requirement that when a node sends a payload
   packet there should be some return traffic within Send Timeout
   seconds.  On the other hand, the Keepalive timer reflects the
   requirement that when a node receives a payload packet there should a
   similar response towards the peer within Keepalive seconds (if no
   traffic is interchanged, there is no Keep Alive signaling).

   The path exploration mechanism starts whenever the node has not
   received any packet during a fixed period of time (Send Timer).  A
   path may become invalid either bacause one of the locators used may
   became invalid or inoperational, or the pair itself has been declared
   as inoperational.  A full exploration mechanism should check all
   possible pairs of source/destination locators until at least one
   working locator pair is found.  Instead of using a request/response



de la Oliva & Bagnulo    Expires January 3, 2008                [Page 7]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


   approach the first of both sides which detects the failure tries each
   of the peer's locators sending probes through each of its interfaces.
   Each probe carries information about the current state of the
   communication and the probes which have been received so far through
   the rest of the interfaces.  The state of the connection can be one
   of three possible states: i) Operational, when both peers can see
   each other, b)Exploring, when one of the peers have detected a
   problem and has currently not seen any traffic from the peer or c)
   Inbound_OK, when the node sees traffic from the peer but the peer
   does not see any traffic from the node.  The information related with
   the rest of the probes received, which is carried on every probe
   allows the end hosts to be able to know which are the locator pairs
   working in the outgoing direction, on the case there are multiple
   probes.  The path exploration mechanism ends when both peers have
   received a probe confirming that the peer can see them.  It should be
   noted that the defined exploration mechanism is capable of
   discovering locators pairs that are working in only one direction
   (i.e. unidirectional reachability) thanks to the information about
   all received probes contained in all the reply probes.

   In the current implementation once a node detects a failure, it
   starts the path exploration mechanism.  A Probe message is sent to
   test the current locator pair, and if no responses are obtained
   during a period of time called Retransmission Timer (TRTx), the nodes
   start sending Probes testing the rest of the available address pairs,
   using all possible source/destination address pairs.  Once a probe is
   received by the node, it sends another probe to the peer indicating
   that it is seeing traffic from it (Inbound_OK).  After receiving this
   last probe the peer will answer confirming the reception of this last
   probe and indicating that the new locator pair is in the Operational
   state.

   These Probe messages are used to confirm reachability and can be used
   as an address verification mechanism to modify the state of the
   locator being probe to ACTIVE.  Note that each end point of the
   communication explores unidirectional reachability and based on its
   observations decides the pair of locators to use in a not coordinated
   way.  Therefore the pair of locators selected by each end host may be
   different.

   At the end of the path exploration mechanism, each host will have a
   pair of ACTIVE locators which can be used to continue the
   communication.

3.3.  Processing of the REAP messages

   Figure 1 shows the placement of the REAP module within the HIP
   Multihoming stack.  Once some heuristic has decided that a



de la Oliva & Bagnulo    Expires January 3, 2008                [Page 8]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


   communication should be protected by the REAP protocol, an instance
   of it is created and associated with the SA to protect.  The REAP
   instance is able to communicate with the ESP and HIP layers.  The ESP
   layer should inform of every packet received or sent associated with
   the SPI used on the protected HIP association.  By this way if
   rekeying is needed due to a change of locator or any other cause, the
   ESP layer will still be able to inform REAP of the messages received
   or sent associated to the protected SA.

               ---------
               | TCP   |  (sockets bound to HITs)
               ---------
                   |
               ---------
         ----> | ESP   |  {HIT_s, HIT_d} <-> SPI
         |     ---------
        ----       |
       | MH |  ---------
        ---- ->| HIP   |  {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
       |REAP|  ---------
        ----       |
               ---------
               |  IP   |
               ---------

       Figure 1: Architecture for  HIP mobility and multihoming (MH)

   The REAP control messages (Probe, KeepAlive) are not protected by ESP
   and will be indexed by the Sender's and Receiver's HIT pair.  Upon
   reception of a REAP control message, the HIP layer will demultiplex
   the control packet and forward it to the corresponding REAP instance.
   It must be taken into account that if several SAs are used to
   communicate the same HIT pairs only one instanciation of the REAP
   protocol is needed.  On this case all data packets corresponding with
   the SAs between the HIT pair will be notified to the same instance of
   REAP.


4.  HIP comformant REAP messages

4.1.  KeepAlive Message

   The format of the keepalive message is as follows:








de la Oliva & Bagnulo    Expires January 3, 2008                [Page 9]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Header   | Header Length |0| Packet Type |  VER. | RES.|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Checksum             |           Controls            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Sender's Host Identity Tag (HIT)               |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Receiver's Host Identity Tag (HIT)              |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /                        HIP Parameters                         /
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 2: KeepAlive Message

   Fields:

   Next Header, Header Length, 0, Version, Reserved, 1, Checksum and HIP
   Controls:
      These are as specified in Section 5.1 of the HIP protocol
      description [1].

   Packet Type (as specified in [4]):
      This field identifies the KeepAlive message and MUST be set to 66
      (KeepAlive)

   Sender's Host Identity Tag (HIT):
      As defined in [1]

   Receiver's Host Identity Tag (HIT):
      As defined in [1]

   HIP parameters:
      This space is reserved for adding HIP parameters.  At least the
      KeepAlive Timeout Option may be added here.





de la Oliva & Bagnulo    Expires January 3, 2008               [Page 10]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


4.2.  Probe Message

   This message performs REAP exploration.  Its format is as follows:

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Header   | Header Length |0| Packet Type |  VER. | RES.|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Checksum             |           Controls            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Sender's Host Identity Tag (HIT)               |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Receiver's Host Identity Tag (HIT)              |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /                        HIP Parameters                         /
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Precvd| Psent |Sta|                 Reserved2                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      First probe sent                         +
      |                                                               |
      +                      Source address                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      First probe sent                         +
      |                                                               |
      +                      Destination address                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      First probe nonce                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      First probe data                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



de la Oliva & Bagnulo    Expires January 3, 2008               [Page 11]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


      /                                                               /
      /                      Nth probe sent                           /
      |                                                               |
      +                      Source address                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Nth probe sent                           +
      |                                                               |
      +                      Destination address                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Nth probe nonce                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Nth probe data                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      First probe received                     +
      |                                                               |
      +                      Source address                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      First probe received                     +
      |                                                               |
      +                      Destination address                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      First probe nonce                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      First probe data                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /                                                               /
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +                      Nth probe received                       +
      |                                                               |
      +                      Source address                           +



de la Oliva & Bagnulo    Expires January 3, 2008               [Page 12]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Nth probe received                       +
      |                                                               |
      +                      Destination address                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Nth probe nonce                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Nth probe data                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                          Options                              +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                          Options                              +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 3: Probe Message

   Fields:

   Next Header, Header Length, 0, Version, Reserved, 1, Checksum and HIP
   Controls:
      These are as specified in Section 5.1 of the HIP protocol
      description [1].

   Packet Type (as specified in [4]):
      This field identifies the Probe message and MUST be set to 67
      (Probe)

   Sender's Host Identity Tag (HIT):
      As defined in [1].

   Receiver's Host Identity Tag (HIT):
      As defined in [1].

   HIP parameters:
      This space is reserved for adding HIP parameters.  At least the
      KeepAlive Timeout Option may be added here.




de la Oliva & Bagnulo    Expires January 3, 2008               [Page 13]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


   The rest of the parameters on the packet are exactly the same as
   specified on [4].

   Psent
      This is a 4-bit field that indicates the number of sent probes
      included in this probe message.  The first set of probe fields
      pertains to the current message and MUST be present, so the
      minimum value for this field is 1.  Additional sent probe fields
      are copies of the same fields sent in (recent) earlier probes and
      may be included or omitted as per any logic employed by the
      implementation.

   Precvd
      This is a 4-bit field that indicates the number of received probes
      included in this probe messsage.  Received probe fields are copies
      of the same fields received in (recent) earlier probes and may be
      included or omitted as per any logic employed by the
      implementation.

   The fields probe source, probe destination, probe nonce and probe
   data may be repeated, depending on the value of Psent and Preceived.

   Sta (State)
      This 2-bit State field is used to inform the peer about the state
      of the sender.  It has three legal values:
         0 (Operational) implies that the sender both (a) believes it
         has no problem communicating and (b) believes that the
         recipient also has no problem communicating.
         1 (Exploring) implies that the sender has a problem
         communicating with the recipient, e.g., it has not seen any
         traffic from the recipient even when it expected some.
         2 (InboundOk) implies that the sender believes it has no
         problem communicating, i.e., it at least sees packets from the
         recipient, but that the recipient either has a problem or has
         not yet confirmed to the sender that the problem has been
         solved.

   Reserved2
      MUST be set to 0 upon transmission and MUST be ignored upon
      reception.

   Probe source
      This 128-bit field contains the source IPv6 address used to send
      the probe.

   Probe destination





de la Oliva & Bagnulo    Expires January 3, 2008               [Page 14]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


      This 128-bit field contains the destination IPv6 address used to
      send the probe.

   Probe nonce
      This is a 32-bit field that is initialized by the sender with a
      value that allows it to determine which sent probes a received
      probe correlates with.  It is highly recommeded that the nonce
      field is at least moderately hard to guess so that even on-path
      attackers can't deduce the next nonce value that will be used.
      This value SHOULD be generated using a random number generator
      that is known to have good randomness properties as outlined in
      RFC 1750 [RFC1750].

   Probe data
      This is a 32-bit field with no fixed meaning.  The probe data
      field is copied back with no changes.  Future flags may define a
      use for this field.

4.3.  Keepalive Timeout Option Format

   Either side of a HIP association can notify the peer of the value
   that it would prefer the peer to use as its Keepalive Timeout value.
   If the host is using a non-default Send Timeout value, it SHOULD
   communicate this value as a Keepalive Timeout value to the peer in
   the below option.  This option MAY be sent in the I2, R2, or UPDATE
   messages.  The option SHOULD only need to be sent once in a given HIP
   association.  If a host receives this option it SHOULD update its
   Keepalive Timeout value for the correspondent.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type = 10           |        Length  = 4            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +           Reserved            |      Keepalive Timeout        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4: KeepAlive Timeout Option Format

   Fields:

   Type
      This field identifies the option and MUST be set to 10 (Keepalive
      Timeout).

   The rest of the fiels on this packet are exactly the same as defined
   on [4].



de la Oliva & Bagnulo    Expires January 3, 2008               [Page 15]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


   Length
      This field MUST be set as specified in Section 5.1 of the HIP
      protocol description [1].

   Reserved
      16-bit field reserved for future use.  Set to zero upon transmit
      and MUST be ignored upon receipt.

   Keepalive Timeout
      Value in seconds corresponding to suggested Keepalive Timeout
      value for the peer.


5.  Security Considerations

   TBD


6.  Acknoledgements

   Tom Henderson provided comments and feedback on the contents of this
   draft.

   Antonio de la Oliva is partly funded by OneLab, a research project
   supported by the European Commission under its Sixth Framework
   Program.  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the OneLab project or the European Commission.


7.  References

   [1]  Moskowitz, R., Nikander, P., and T. Henderson, "Host Identity
        Protocol", June 2007.

   [2]  Henderson, T., "End-Host Mobility and Multihoming with the Host
        Identity Protocol", March 2007.

   [3]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
        Protocol for IPv6", May 2007.

   [4]  Arkko, J. and I. van Beijnum, "Failure Detection and Locator
        Pair Exploration Protocol for IPv6 Multihoming", June 2007.







de la Oliva & Bagnulo    Expires January 3, 2008               [Page 16]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


Authors' Addresses

   Antonio de la Oliva
   UC3M

   Email: aoliva@it.uc3m.es


   Marcelo Bagnulo
   Huawei Labs at UC3M

   Email: marcelo@it.uc3m.es







































de la Oliva & Bagnulo    Expires January 3, 2008               [Page 17]


Internet-Draft       Fault Tolerant HIP Multihoming            July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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


Acknowledgment

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





de la Oliva & Bagnulo    Expires January 3, 2008               [Page 18]