view Side-By-Side changes

Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                                I. Beijnum
Expires: December 25, 28, 2006                                         Muada
                                                           June 23, 26, 2006


    Failure Detection and Locator Pair Exploration Protocol for IPv6
                              Multihoming
                 draft-ietf-shim6-failure-detection-04
                 draft-ietf-shim6-failure-detection-05

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on December 25, 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).












Arkko & Beijnum         Expires December 25, 28, 2006               [Page 1]

Internet-Draft         Failure Detection Protocol              June 2006


Abstract

   This document specifies how the level 3 multihoming shim protocol
   (SHIM6) detects failures between two communicating hosts.  It also
   specifies an exploration protocol for switching to another pair of
   interfaces and/or addresses between the same hosts if a failure
   occurs and a working an operational pair can be found.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  7
       4.1.  5
       3.1.  Available Addresses  . . . . . . . . . . . . . . . . . .  7
       4.2.  5
       3.2.  Locally Operational Addresses  . . . . . . . . . . . . .  8
       4.3.  6
       3.3.  Operational Address Pairs  . . . . . . . . . . . . . . .  8
       4.4.  6
       3.4.  Current Address Pair . . . . . . . . . . . . . . . . . . 10
   5.  8
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.  9
       4.1.  Failure Detection  . . . . . . . . . . . . . . . . . . . 11
       5.2.  9
       4.2.  Alternative Address Pair Exploration . . . . . . . . . . 12
       5.3. 11
       4.3.  Exploration Order  . . . . . . . . . . . . . . . . . . . 13
       5.4. 11
       4.4.  Protocol Design  . . . . . . . . . . . . . . . . . . . . 14
       5.5. 12
       4.5.  Example Protocol Runs  . . . . . . . . . . . . . . . . . 15
       5.6. 13
       4.6.  Limitations  . . . . . . . . . . . . . . . . . . . . . . 21
   6. 19
   5.  Protocol Definition  . . . . . . . . . . . . . . . . . . . . . 22
       6.1. 20
       5.1.  Keepalive Message  . . . . . . . . . . . . . . . . . . . 22
             6.1.1. 20
             5.1.1.  Keepalive Option . . . . . . . . . . . . . . . . 23
       6.2. 21
       5.2.  Probe Message  . . . . . . . . . . . . . . . . . . . . . 24
             6.2.1. 22
             5.2.1.  Probe Option . . . . . . . . . . . . . . . . . . 26
       6.3. 24
       5.3.  Reachability Option  . . . . . . . . . . . . . . . . . . 27
             6.3.1. 25
             5.3.1.  Payload Reception Report . . . . . . . . . . . . 28
             6.3.2. 26
             5.3.2.  Probe Reception Report . . . . . . . . . . . . . 28
       6.4. 26
       5.4.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . 29
       6.5. 27
       5.5.  Protocol Constants . . . . . . . . . . . . . . . . . . . 33
   7. 31
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   8. 32
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
   9. 34
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
       9.1. 35
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 37
       9.2. 35
       8.2.  Informative References . . . . . . . . . . . . . . . . . 37 35
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 40 37
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 41 38
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 39
   Intellectual Property and Copyright Statements . . . . . . . . . . 43 40







Arkko & Beijnum         Expires December 25, 28, 2006               [Page 2]

Internet-Draft         Failure Detection Protocol              June 2006


1.  Introduction

   The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support
   multihoming.  It is an IP layer mechanism that hides multihoming from
   applications.  A part of the SHIM6 solution involves detecting when a
   currently used pair of addresses (or interfaces) between two
   communication hosts has failed, and picking another pair when this
   occurs.  We call the former failure detection, and the latter locator
   pair exploration.

   This document specifies the mechanisms and protocol messages to
   achieve both failure detection and locator pair exploration.  This
   part of the SHIM6 protocol is called the REAchability Protocol
   (REAP).

   The document is structured as follows: Section 3 discusses related
   work in this space, Section 4 defines a set of
   useful terms, Section 5 4 gives an overview of REAP, and Section 6 5
   specifies the message formats and behaviour in detail.  Section 7 6
   discusses the security considerations of REAP.

   In this specification, we consider an address to be synonymous with a
   locator.  Other parts of the SHIM6 protocol ensure that the different
   locators used by a node actually belong together.  That is, REAP is
   not responsible for ensuring that it ends up with a legitimate
   locator.


























Arkko & Beijnum         Expires December 25, 28, 2006               [Page 3]

Internet-Draft         Failure Detection Protocol              June 2006


2.  Requirements language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Arkko & Beijnum         Expires December 25, 28, 2006               [Page 4]

Internet-Draft         Failure Detection Protocol              June 2006


3.  Related Work

   In SCTP [RFC2960], transport addresses (IP address  Definitions

   This section defines terms useful for discussing failure detection
   and port pairs)
   are exchanged during SCTP Association (i.e. connection) setup phase.
   In order locator pair exploration.

3.1.  Available Addresses

   SHIM6 nodes need to provide a failover mechanism between multihomed hosts,
   one be aware of the peer's what addresses is selected as the primary address by they themselves have.
   If a node loses the
   application running on top of SCTP.  All data packets are sent to
   this address until there it is a reason to choose currently using for communications,
   another address, such
   as the failure of the primary address must replace this address.

   SCTP also tests the reachability of  And if a node loses an
   address that the node's peer endpoint's addresses.
   This is done both via observing the data packets sent to knows about, the peer or
   via a periodic heartbeat when there is no data packets to send.  Each
   time data packet retransmission is initiated (or must be informed.
   Similarly, when a heartbeat is
   not answered within the estimated round-trip time) an error counter
   is incremented.  When node acquires a configured error limit is reached, new address it may generally wish
   the
   particular destination peer to know about it.

   Definition.  Available address.  An address is marked as inactive. said to be available
   if the following conditions are fulfilled:

   o  The reception
   of address has been assigned to an acknowledgement or heartbeat response clears interface of the counter.  When
   retransmitting node.

   o  The address is valid in the endpoint attempts pick sense of RFC 2461 [RFC2461].

   o  The address is not tentative in the most "divergent"
   source-destination pair from sense of RFC 2462 [RFC2462].
      In other words, the original source-destination pair address assignment is complete so that
      communications can be started.

      Note that this explicitly allows an address to
   which be optimistic in
      the packet was transmitted.  Rules for such selection are,
   however, left sense of Optimistic DAD [RFC4429] even though implementations
      may prefer using other addresses as implementation decisions in SCTP.

   SCTP does not define how local knowledge (such long as information learned
   from the link layer) should be used.  A mechanism, dynamic there is an
      alternative.

   o  The address
   reconfiguration mechanism [I-D.ietf-tsvwg-addip-sctp], is being
   developed to deal with dynamic changes a global unicast, unique local address [RFC4193],
      or an unambiguous IPv6 link-local address.  That is, it is not an
      IPv6 site-local address.

      Where IPv6 link-local addresses are used, their use needs to be
      unambiguous as follows.  At most one link-local address may be
      used per node within the set of available
   addresses. same connection between two peers.

   o  The MOBIKE protocol [RFC4555] provides multihoming and mobility for
   VPN connections.  Its failure detection address and locator pair exploration interface is designed acceptable for use according to work across mixed IPv4/IPv6 environments and NATs, as
   long as a path that allows bidirectional communication can be found.

   Existing mechanisms at lower layers or in IKEv2
      local policy.

   Available addresses are used to detect
   failures, discovered and upon failure MOBIKE attempts to explore all
   combinations monitored through mechanisms
   outside the scope of addresses to find a working pair.  Such exploration
   is necessary when a problem affects both nodes.  For instance, two
   nodes connected by two separate point-to-point links will SHIM6.  SHIM6 implementations MUST be unable
   to switch able to
   employ information provided by IPv6 Neighbor Discovery [RFC2461],
   Address Autoconfiguration [RFC2462], and DHCP [RFC3315].  This
   information includes the other link if a failure occurs on the first one.
   While both communicating hosts are aware of each others' addresses,
   only one end of the communication is in charge availability of deciding what a new address pair to use, however.

   The mobility and multihoming specification for the HIP protocol
   [I-D.ietf-hip-mm] leaves the determination status
   changes of existing addresses (such as when an address updates
   are sent to a local policy, but suggests the use of local information
   and ICMP error messages. becomes
   invalid).



Arkko & Beijnum         Expires December 25, 28, 2006               [Page 5]

Internet-Draft         Failure Detection Protocol              June 2006


   Network attachment procedures


3.2.  Locally Operational Addresses

   Two different granularity levels are also relevant needed for multihoming. failure detection.
   The
   IPv6 and MIP6 working groups have standardized mechanisms to learn
   about networks that a node has attached to.  Basic IPv6 Neighbor
   Discovery was, however, designed primarily coarser granularity is for static situations.
   The fully dynamic detection procedure has turned out individual addresses:

   Definition.  Locally Operational Address.  An available address is
   said to be locally operational when its use is known to be possible
   locally: the interface is up, a
   relatively complex procedure default router (if needed) suitable
   for mobile hosts.  Enhanced or optimized
   mechanisms are being designed in the DHC and DNA working groups DNAv4
   [RFC4436], CPL [I-D.ietf-dna-cpl], and DNAv6 [I-D.ietf-dna-protocol].

   ICE [I-D.ietf-mmusic-ice], STUN [RFC3489], this address is known to be reachable, and TURN
   [I-D.rosenberg-midcom-turn] are also related mechanisms.  They no other local
   information points to the address being unusable.

   Locally operational addresses are
   primarily used for NAT detection discovered and communication monitored through NATs in
   IPv4 environment, for application such as as voice over IP.  STUN
   uses a server in the Internet to discover
   mechanisms outside the presence and type SHIM6 protocol.  SHIM6 implementations MUST be
   able to employ information provided from Neighbor Unreachability
   Detection [RFC2461].  Implementations MAY also employ additional,
   link layer specific mechanisms.

      Note 1: A part of
   NATs and the client's public problem in ensuring that an address is
      operational is making sure that after a change in link layer
      connectivity we are still connected to the same IP addresses and ports.  TURN makes subnet.
      Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6
      [I-D.ietf-dna-protocol] can be used to ensure this.

      Note 2: In theory, it would also be possible to receive incoming connections in for hosts behind NATs.  ICE
   makes use of these to learn
      about routing failures for a particular selected source prefix, if
      only suitable protocols for this purpose existed.  Some proposals
      in peer-to-peer cooperative fashion,
   allowing participants to discover, create and verify mutual
   connectivity, and then use this connectivity for multimedia streams.
   While these mechanisms are not designed space have been made, see, for dynamic instance
      [I-D.bagnulo-shim6-addr-selection] and failure
   situations, they
      [I-D.huitema-multi6-addr-selection], but none have many been
      standardized to date.

3.3.  Operational Address Pairs

   The existence of locally operational addresses are not, however, a
   guarantee that communications can be established with the same requirements for peer.  A
   failure in the
   exploration of connectivity, as well as routing infrastructure can prevent packets from
   reaching their destination.  For this reason we need the requirement definition
   of a second level of granularity, for pairs of addresses:

   Definition.  Bidirectionally operational address pair.  A pair of
   locally operational addresses are said to deal be an operational address
   pair, iff bidirectional connectivity can be shown between the
   addresses.  That is, a packet sent with
   middleboxes.

   Related work one of the addresses in the IPv6 area includes RFC 3484 [RFC3484] which
   defines
   source field and destination address selection rules for IPv6 the other in
   situations where multiple candidate address pairs exist.  RFC 3484
   considers only a static situation, however, and does not take into
   account the effect of failures.

   An earlier SHIM6 document [I-D.ietf-shim6-reach-detect] analyzed what
   kind of mechanisms can be used to detect whether the peer is still
   reachable at destination field reaches the currently used address.  Two proposed mechanisms,
   Correspondent Unreachability Detection (CUD) and Forced Bidirectional
   Communication (FBD) were presented.  CUD is based on getting upper
   layer positive feedback,
   destination, and IPv6 NUD-like probing if there is no
   feedback.  FBD is based on forcing bidirectional communication by
   adding keepalive messages when vice versa.

   Unfortunately, there is no other, payload traffic.
   FBD is the chosen mechanism in this document.

   Many other protocols, both standardized in the IETF and outside of
   the IETF make use of keepalives to track the liveness of a connection are scenarios where bidirectionally operational
   address pairs do not exist.  For instance, ingress filtering or session.



Arkko & Beijnum         Expires December 25, 28, 2006               [Page 6]

Internet-Draft         Failure Detection Protocol              June 2006


4.  Definitions

   This section defines terms useful for discussing failure detection
   and locator pair exploration.

4.1.  Available Addresses

   SHIM6 nodes need to be aware of what addresses they themselves have.
   If a node loses the


   network failures may result in one address it is currently using for communications, pair being operational in
   one direction while another address must replace this address.  And if a node loses an
   address that the node's peer knows about, the peer must be informed.
   Similarly, when a node acquires a new address it may generally wish one is operational from the peer to know about it. other
   direction.  The following definition captures this general situation:

   Definition.  Available address.  An  Unidirectionally operational address is pair.  A pair of
   locally operational addresses are said to be available
   if an unidirectionally
   operational address pair, iff packets sent with the following conditions are fulfilled:

   o  The first address has been assigned to an interface of as
   the node.

   o  The source and the second address is valid in as the sense destination can be shown to
   reach the destination.

   SHIM6 implementations MUST support the discovery of RFC 2461 [RFC2461].

   o  The operational
   address is not tentative in pairs through the sense use of RFC 2462 [RFC2462]. explicit rechability tests and
   Forced Bidirectional Communication (FBD), described later in this
   specification.  In other words, addition, implementations MAY employ the address assignment is complete so that
      communications following
   additional mechanisms:

   o  Positive feedback from upper layer protocols.  For instance, TCP
      can be started.

      Note indicate to the IP layer that this explicitly allows an address it is making progress.  This is
      similar to be optimistic how IPv6 Neighbor Unreachability Detection can in some
      cases be avoided when upper layers provide information about
      bidirectional connectivity [RFC2461].

      In the sense case of Optimistic DAD [RFC4429] even though implementations
      may prefer unidirectional connectivity, the upper layer
      protocol responses come back using other addresses as long as there is an
      alternative.

   o  The another address pair, but show
      that the messages sent using the first address pair have been
      received.

   o  Negative feedback from upper layer protocols.  It is conceivable
      that upper layer protocols give an indication of a global unicast, unique local address [RFC4193], problem to the
      multihoming layer.  For instance, TCP could indicate that there's
      either congestion or an unambiguous IPv6 link-local address.  That is, lack of connectivity in the path because it
      is not an
      IPv6 site-local address.

      Where IPv6 link-local addresses are used, their use needs to be
      unambiguous as follows.  At most getting ACKs.

   o  ICMP error messages.  Given the ease of spoofing ICMP messages,
      one link-local address may should be
      used per node within the same connection between two peers.

   o  The address and interface careful to not trust these blindly, however.  Our
      suggestion is acceptable for to use according ICMP error messages only as a hint to perform
      an explicit reachability test, but not as a
      local policy.

   Available addresses reason to disrupt
      ongoing communications without other indications of problems.  The
      situation may be different when certain verifications of the ICMP
      messages are discovered and monitored through mechanisms
   outside being performed, as explained by Gont in
      [I-D.ietf-tcpm-icmp-attacks].  These verifications can ensure that
      (practically) only on-path attackers can spoof the scope messages.

   Note SHIM6 needs to perform a return routability test of SHIM6.  These mechanisms include IPv6 Neighbor
   Discovery [RFC2461] and Address Autoconfiguration [RFC2462], and DHCP
   [RFC3315]. an address
   before it is taken into use.  The purpose of this test is to ensure
   that fraudulent peers do not trick others into redirecting traffic
   streams onto innocent victims.  For a discussion of such attacks, see
   Aura et al [AURA02].  The test can at the same time work as a means



Arkko & Beijnum         Expires December 25, 28, 2006               [Page 7]

Internet-Draft         Failure Detection Protocol              June 2006


4.2.  Locally Operational Addresses

   Two different granularity levels are needed for failure detection.
   The coarser granularity is for individual addresses:

   Definition.  Locally Operational Address.  An available address is
   said


   to be locally operational when its use ensure that an address pair is known operational, as discussed in
   Section 4.2.

3.4.  Current Address Pair

   SHIM6 needs to be possible
   locally: the interface avoid sending packets concurrently over multiple
   paths, because congestion control in commonly used transport
   protocols is up, based upon a default router (if needed) suitable
   for this address is known to be reachable, notion of a single path.  While routing can
   introduce path changes as well and no other local
   information points transport protocols have means to the address being unusable.

   Locally operational addresses are discovered and monitored through
   mechanisms outside the SHIM6 protocol.  These mechanisms include
   Neighbor Unreachability Detection [RFC2461], and link layer specific
   mechanisms.

      Note 1: A part of the problem in ensuring that an address is
      operational
   deal with this, frequent changes will cause problems.  Efficient
   congestion control over multible paths is making sure that after a change in link layer
      connectivity we are still connected to considered research at
   the same IP subnet.
      Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6
      [I-D.ietf-dna-protocol] can be used to ensure this.

      Note 2: It time this specification is also possible for hosts written.

   For these reasons it is necessary to learn about routing
      failures for choose a particular selected source prefix, if suitable
      protocols for this purpose exist.  Some proposals in this space
      have been made, see, for instance
      [I-D.bagnulo-shim6-addr-selection] and
      [I-D.huitema-multi6-addr-selection], but none have been
      standardized to date.

4.3.  Operational Address Pairs

   The existence pair of locally operational
   addresses are not, however, a
   guarantee that communications can be established with the peer.  A
   failure in the routing infrastructure can prevent packets from
   reaching their destination.  For this reason we need as the definition
   of a second level of granularity, for pairs of addresses:

   Definition.  Bidirectionally operational current address pair. pair which is used until problems
   occur, at least for the same session.

   A current address pair of
   locally operational addresses are said to need not be an operational address
   pair, iff bidirectional connectivity can be shown between the
   addresses.  That is, a packet sent with one of the addresses in the
   source field and the other in the destination field reaches the
   destination, and vice versa.

   Unfortunately, at all times.  If
   there are scenarios where bidirectionally operational
   address pairs do not exist.  For instance, ingress filtering or
   network failures is no traffic to send, we may result in one not know if the primary address
   pair being operational is operational.  Nevertheless, it makes sense to assume that the
   address pair that worked in some time ago continues to be operational
   for new communications as well.





























Arkko & Beijnum         Expires December 25, 28, 2006               [Page 8]

Internet-Draft         Failure Detection Protocol              June 2006


   one direction while another one is operational from


4.  Protocol Overview

   This section discusses the other
   direction.  The following definition captures this general situation:

   Definition.  Unidirectionally operational address pair.  A pair design of
   locally operational addresses are said to be an unidirectionally
   operational address pair, iff packets sent with the first address as the source reachability detection and the second address as the destination can be shown to
   reach the destination.

   Operational
   address pairs are discovered through pair exploration mechanisms, and gives on overview of the following means:

   o  Positive feedback from upper layer protocols.  For instance, TCP
      can indicate to
   REAP protocol.

   Exploring the IP layer full set of communication options between two hosts
   that it is making progress.  This both have two or more addresses is
      similar an expensive operation as the
   number of combinations to how IPv6 Neighbor Unreachability Detection can in some
      cases be avoided when upper layers provide information about
      bidirectional connectivity [RFC2461].

      In explored increases very quickly with the case
   number of unidirectional connectivity, the upper layer
      protocol responses come back using another addresses.  For instance, with two addresses on both sides,
   there are four possible address pair, but show pairs.  Since we can't assume that
   reachability in one direction automatically means reachability for
   the messages sent using the first address complement pair have been
      received.

   o  Negative feedback from upper layer protocols.  It in the other direction, the total number of two-
   way combinations is eight.  (Combinations = nA * nB * 2.)

   An important observation in multihoming is conceivable that upper layer protocols give failures are
   relatively infrequent, so that an indication of a problem to the
      multihoming layer.  For instance, TCP could indicate operational pair that there's
      either congestion or lack of connectivity in the path because it worked a few
   seconds ago is not getting ACKs.

   o  Explicit reachability tests, described later in this
      specification.

   o  ICMP error messages.  Given the ease of spoofing ICMP messages,
      one should be careful very likely to not trust these blindly, however.  Our
      suggestion is be still operational.  So it makes
   sense to use ICMP error messages have a light-weight protocol that confirms existing
   reachability, and only as invoke heavier exploration when a hint to perform
      an explicit reachability test, but not as there is a reason to disrupt
      ongoing communications without other indications
   suspected failure.

4.1.  Failure Detection

   Failure detection consists of problems.  The
      situation may be different when certain verifications three parts: tracking local
   information, tracking remote peer status, and finally verifying
   reachability.  Tracking local information consists of using, for
   instance, reachability information about the ICMP
      messages are being performed, local router as explained by Gont an
   input.  Nodes SHOULD employ techniques listed in
      [I-D.ietf-tcpm-icmp-attacks].  These verifications can ensure that
      (practically) only on-path attackers can spoof Section 3.1 and
   Section 3.2 to be track the messages.

   Note SHIM6 needs local situation.  It is also necessary to perform a return routability test of an
   track remote address information from the peer.  For instance, if the
   peer's currently used address
   before it is taken into use.  The purpose of this test is no longer in use, mechanism to ensure relay
   that fraudulent peers do not trick others into redirecting traffic
   streams onto innocent victims.  For a discussion of such attacks, see
   Aura et al [AURA02]. information is needed.  The test can at Update message in the same time work as a means SHIM6 protocol
   is used for this purpose [I-D.ietf-shim6-proto].  Finally, when the
   local and remote information indicates that communication should be
   possible and there are upper layer packets to be sent, reachability
   verification is necessary to ensure that the peers actually have an
   operational pair.

   A technique called Forced Bidirectional Detection (FBD, originally
   defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect])
   is employed for the reachability verification.  Reachability for the
   currently used address pair in a shim context is operational, determined by making
   sure that whenever there is data traffic in one direction, there is
   also traffic in the other direction.  This can be data traffic as discussed
   well, but also transport layer acknowledgments or a REAP reachability
   keepalive if there is no other traffic.  This way, it is no longer
   possible to have traffic in
   Section 5.2. only one direction, so whenever there is



Arkko & Beijnum         Expires December 25, 28, 2006               [Page 9]

Internet-Draft         Failure Detection Protocol              June 2006


4.4.  Current Address Pair

   SHIM6 needs to avoid sending packets concurrently over multiple
   paths, because congestion control in commonly used transport
   protocols is based upon a notion of a single path.  While routing can
   introduce path changes as well and transport protocols have means to
   deal with this, frequent changes will cause problems.  Efficient
   congestion control over multible paths is


   data traffic going out, but there are no return packets, there must
   be a considered research at failure, so the time this specification is written.

   For these reasons it full exploration mechanism is necessary to choose a particular pair started.

   A more detailed description of
   addresses as the current address pair which reachability
   evaluation mechanism:

   1.  The base timing unit for this mechanism is used until problems
   occur, at least named Keepalive
       Timeout.  Until a negotiation mechanism to negotiate different
       values for this timer becomes available, the same session.

   A current address pair need not value (3 seconds)
       specified in Section 5.5 SHOULD be operational at all times.  If
   there used.

   2.  Whenever outgoing data packets are generated, a timer is no traffic started
       to send, we may not know if reflect the primary address
   pair is operational.  Nevertheless, it makes sense to assume requirement that the
   address pair peer should generate return
       traffic from data packets.

       For the purposes of this specification, "data packet" refers to
       any packet that worked is part of a shim context, including both upper
       layer protocol packets and SHIM6 protocol messages except those
       defined in some time ago continues this specification.

   3.  Whenever incoming data packets are received, the timer associated
       with the return traffic from the peer is stopped, and another
       timer is started to work reflect the requirement for new
   communications as well.
































Arkko & this node to
       generate return traffic.

   4.  The reception of a REAP keepalive packet leads to stopping the
       timer associated with the return traffic from the peer.

   5.  Keepalive Timeout seconds after the last data packet has been
       received for a context, and if no other packet has been sent
       within this context since the data packet has been received, a
       REAP keepalive packet is generated for the context in question
       and transmitted to the correspondent.  A host may send the
       keepalive sooner than Keepalive Timeout seconds if implementation
       considerations warrant this.  The average time after which
       keepalives are sent MUST be at least Keepalive Timeout / 2
       seconds.  After sending a single keepalive message, no additional
       keepalive messages are sent until a data packet is received
       within this shim context.  Keepalives are not sent at all when a
       data packet was sent since the last received data packet.

   6.  Send Timeout seconds (10 s; see Section 5.5) after the
       transmission of a data packet with no return traffic on this
       context, a full reachability exploration is started.  This
       timeout period is larger than the Keepalive Timeout to
       accommodate for lost keepalives and regular variations in round
       trip times.




Arkko & Beijnum         Expires December 25, 28, 2006              [Page 10]

Internet-Draft         Failure Detection Protocol              June 2006


5.  Protocol Overview

   This section discusses the design of


4.2.  Alternative Address Pair Exploration

   As explained in previous section, the reachability detection and currently used address pair exploration mechanisms, and gives on overview may
   become invalid either through one of the
   REAP protocol.

   Exploring the full set of communication options between two hosts
   that both have two or more addresses is an expensive operation as the
   number of combinations to be explored increases very quickly with the
   number of addresses.  For instance, with two addresses on both sides,
   there are four possible address pairs.  Since we can't assume that
   reachability in one direction automatically means reachability for being becoming
   unavailable or inoperational, or the complement pair in the other direction, the total number of two-
   way combinations is eight.  (Combinations = nA * nB * 2.) itself being declared
   inoperational.  An important observation in multihoming is that failures are
   relatively infrequent, exploration process attempts to find another
   operational pair so that a path that worked a few seconds ago
   is very likely to work now as well.  So it communications can resume.

   What makes sense to have a
   light-weight protocol that confirms existing reachability, and only
   invoke heavier exploration when a there this process hard is a suspected failure.

5.1.  Failure Detection

   Failure detection consists of three parts: tracking local
   information, tracking remote peer status, and finally verifying
   reachability.  Tracking local information consists of using, for
   instance, reachability information about the local router as an
   input.  Nodes SHOULD employ techniques listed in Section 4.1 and
   Section 4.2 requirement to be track the local situation. support
   unidirectionally operational address pairs.  It is also necessary insufficient to
   track remote
   probe address information from pairs by a simple request - response protocol.
   Instead, the peer.  For instance, if party that first detects the
   peer's currently used problem starts a process
   where it tries each of the different address is no longer pairs in use, mechanism turn by sending
   a message to relay
   that its peer.  These messages carry information is needed.  The Update about the
   state of connectivity between the peers, such as whether the sender
   has seen any traffic from the peer recently.  When the peer receives
   a message in that indicates a problem, it assists the SHIM6 protocol
   is used for this purpose [I-D.ietf-shim6-proto].  Finally, when process by
   starting its own parallel exploration to the
   local and remote other direction, again
   sending information indicates about the recently received payload traffic or
   signaling messages.

   Specifically, when A decides that communication should be
   possible and there are upper layer packets it needs to be sent, reachability
   verification is necessary explore for an
   alternative address pair to ensure that there actually is B, it will initiate a working
   path between set of Probe
   messages, in sequence, until it gets an Probe message from B
   indicating that (a) B has received one of A's messages and,
   obviously, (b) that B's Probe message gets back to A. B uses the peers.

   A technique called Forced Bidirectional Detection (FBD) is employed
   for same
   algorithm, but starts the reachability verification.  Reachability for process from the currently
   used address pair in reception of the first
   Probe message from A.

   Upon changing to a shim context is determined by making sure new address pair, the network path traversed most
   likely has changed, so that
   whenever there is data traffic in one direction, there is also
   traffic in the other direction. ULP SHOULD be informed.  This can be data traffic as well,
   but also transport layer acknowledgments or
   a REAP reachability
   keepalive if there is no other traffic.  This way, it is no longer
   possible signal for the ULP to have traffic in only one direction, adapt due to the change in path so whenever there is
   data traffic going out, but there are no return packets, there must that, for
   example, TCP could initiate a slow start procedure.

   Similarly, one can also envision that applications would be able to
   tell the IP or transport layer that the current connection in
   unsatisfactory and an exploration for a failure, so better one would be
   desirable.  This would require an API to be developed, however.  In
   any case, this is another issue that we treat as being outside the full
   scope of pure address exploration.

4.3.  Exploration Order

   The exploration mechanism process assumes an ability to choose address pairs
   for testing, in some sequence.  This process may result in a
   combinatorial explosion when there are many addresses on both sides,
   but a back-off procedure is started. employed to avoid a "signaling storm".




Arkko & Beijnum         Expires December 25, 28, 2006              [Page 11]

Internet-Draft         Failure Detection Protocol              June 2006


   A more detailed description of


   Nodes first consult the current pair reachability
   evaluation mechanism:

   1.  The base timing unit for RFC 3484 default address selection rules
   [RFC3484] Section 4 rules to determine what combinations of addresses
   are allowed from a local point of view, as this mechanism is named Keepalive
       Timeout.  Until reduces the search
   space.  RFC 3484 also provides a negotiation mechanism to negotiate priority ordering among different
       values for this timer becomes available,
   address pairs, making the value (3 seconds)
       specified in Section 6.5 SHOULD be used.

   2.  Whenever outgoing data packets are generated that are part search possibly faster.  Nodes may also use
   local information, such as known quality of a
       shim context, a timer is started service parameters or
   interface types to reflect the requirement determine what addresses are preferred over
   others, and try pairs containing such addresses first.  The SHIM6
   protocol also carries preference information in its messages.


      Discussion note: The preferences may either be learned dynamically
      or be configured.  It is believed, however, that dynamic learning
      based purely on the peer multihoming protocol is too hard and not the
      task this layer should generate return traffic do.  Solutions where multiple protocols
      share their information in a common pool of locators could provide
      this information from data packets.

   3.  Whenever incoming data packets are received that are part transport protocols, however.

   Out of a
       shim context, the timer associated with the return traffic from set of possible candidate address pairs, nodes SHOULD
   attempt to test through all of them until an operational pair is
   found, and retrying the peer process as is stopped, necessary.  However, all nodes
   MUST perform this process sequentially and another timer with exponential back-off.
   This sequential process is started necessary in order to reflect avoid a "signaling
   storm" when an outage occurs (particularly for a complete site).
   However, it also limits the
       requirement number of addresses that can in practice
   be used for this node multihoming, considering that transport and application
   layer protocols will fail if the switch to generate return traffic.

   4.  The reception of a REAP keepalive packet leads to stopping new address pair takes
   too long.

   Section 5.5 suggests default values for the
       timer timers associated with
   the return traffic from the peer.

   5.  Keepalive exploration process.  The value Initial Probe Timeout seconds after (0.5 s)
   specifies the last data packet has been
       received for a context, and if no other packet has been interval between initial attempts to send probes;
   Number of Initial Probes (4) specifies how many initial probes can be
   sent
       within this context since the data packet has been received, a
       REAP keepalive packet is generated for before the context in question
       and transmitted exponential backoff procedure needs to be employed.
   This process duplicates the correspondent.  A host may send the
       keepalive sooner than Keepalive Timeout seconds if implementation
       considerations warrant this.  The average time after which
       keepalives are sent MUST be at least Keepalive Timeout / 2
       seconds.  After sending a single keepalive message, no additional
       keepalive messages are sent until a data packet between every probe if there is received
       within this shim context.  Keepalives are not sent at all when no
   response.  Finally, Max probe Timeout (60 s) specifies a
       data packet was sent since limit beyond
   which the last received data packet.

   6.  Send Timeout seconds (10 s; see Section 6.5) after probe interval may not grow.  If the
       transmission of a data packet with no return traffic on exploration process
   reaches this
       context, interval, it will continue sending at this rate until a full reachability exploration is started.  This
       timeout period
   suitable response is larger than triggered or the Keepalive Timeout to
       accommodate for lost keepalives and regular variations in round
       trip times.

5.2.  Alternative Address Pair Exploration

   As explained SHIM6 context is garbage
   collected.

4.4.  Protocol Design

   REAP is designed as a modular part of SHIM6 in previous section, the currently used address pair hopes that it may
   become invalid either through one of the addresses being becoming
   unavailable or inoperational, or the pair itself being declared
   inoperational.  An exploration process attempts to find another
   operational pair
   also be useful in other contexts.  This document defines how it is
   carried within SHIM6, but the actual protocol messages are self-
   contained so that communications can resume. it could be carried by other protocols as well.




Arkko & Beijnum         Expires December 25, 28, 2006              [Page 12]

Internet-Draft         Failure Detection Protocol              June 2006


   What makes this process hard is the requirement to support
   unidirectionally operational address pairs.  It is insufficient to
   probe


   The REAP design allows performing both failure detection and address pairs by a simple request - response protocol.
   Instead, the party that first detects
   pair exploration in the problem starts a process
   where it tries each same sequence of the different address pairs in turn by sending messages, without a message need to its peer.  These messages carry information about
   designate a specific point when the
   state of connectivity between current address pair is declared
   inoperational and the peers, such search for a new pair begins.  This is useful,
   as whether the sender
   has seen any traffic from the peer recently.  When the peer receives loss of a message small number of packets is not a proof that indicates a problem,
   problem exists.  Integrated failure detection and exploration allows
   us to test multiple address pairs simultaneously, including the
   current pair in case it assists becomes operational again.  For instance, the process by
   starting its own parallel
   exploration process can refer to keepalive message that succeeded in
   getting to the other direction, again
   sending information about peer during the recently received payload traffic or
   signaling messages.

   Specifically, when A decides that reachability testing phase.

   REAP also integrates a return routability function, making it needs
   unnecessary to explore for an
   alternative address pair to B, it will initiate perform another roundtrip before a newly discovered
   address can be taken into use.

   This document defines a minimal set of Probe
   messages, in sequence, until it gets an Probe message from B
   indicating that (a) B has received one of A's messages and,
   obviously, (b) parameters that B's Probe message gets back to A. B uses the same
   algorithm, but starts the process from are carried by
   the reception messages of the first
   Probe message from A.

   Upon changing protocol.  Specifically, we have limited the
   parameters to a new those that are necessary to find an operational address pair, the network path traversed most
   likely has changed, so
   pair.  We note there may be extensions that are needed in the ULP SHOULD be informed.  This can be
   a signal future
   for various reasons, such as the ULP desire to adapt due support load balancing or
   finding best pairs.  An option format has been specified to the change allow
   this.

4.5.  Example Protocol Runs

   This section has examples of REAP protocol runs in path so that, for
   example, TCP could initiate a slow typical scenarios.
   We start procedure.

   Similarly, one can also envision that applications would be able to
   tell the IP or transport layer that with the current connection in
   unsatisfactory simplest scenario of two hosts, A and an exploration for B, that have
   a better one would be
   desirable.  This would require an API to be developed, however.  In SHIM6 connection with each other but are not currently sending any case, this is another issue that we treat as being outside the
   scope of pure address exploration.

5.3.  Exploration Order

   The exploration process assumes an ability to choose address pairs
   for testing, in some sequence.  This process may result in a
   combinatorial explosion when
   data.  As neither side sends anything, they also do not expect
   anything back, so there are many addresses on both sides,
   but a back-off procedure is employed to avoid a "signaling storm".

   Nodes first consult no messages at all:

               EXAMPLE 1: No communications

    Peer A                                        Peer B
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |

   Our second example involves an active connection with bidirectional
   payload packet flows.  Here the RFC 3484 default address selection rules
   [RFC3484] Section 4 rules to determine what combinations reception of addresses
   are allowed data from a local point of view, as this reduces the search
   space.  RFC 3484 also provides a priority ordering among different
   address pairs, making the search possibly faster.  Nodes may also use
   local information, such peer is
   taken as known quality an indication of service parameters or
   interface types to determine what addresses reachability, so again there are preferred over
   others, and try pairs containing such addresses first.  The SHIM6 no extra
   packes:




Arkko & Beijnum         Expires December 25, 28, 2006              [Page 13]

Internet-Draft         Failure Detection Protocol              June 2006


   protocol also carries preference information in its messages.


      Discussion note:


          EXAMPLE 2: Bidirectional communications

    Peer A                                        Peer B
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |              payload packet                 |
      |<--------------------------------------------|
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |                                             |

   The preferences may either be learned dynamically
      or be configured.  It third example is believed, however, the first one that dynamic learning
      based purely on the multihoming protocol is too hard and not the
      task this layer should do.  Solutions where multiple protocols
      share their information in a common pool of locators could provide
      this information from transport protocols, however.

   Out of the set of possible candidate address pairs, nodes SHOULD
   attempt to test through all of them until a working pair is found,
   and retrying the process as is necessary.  However, all nodes MUST
   perform this process sequentially and with exponential back-off.
   This sequential process is necessary in order to avoid a "signaling
   storm" when an outage occurs (particularly for a complete site).
   However, it also limits the number of addresses that can in practice
   be used for multihoming, considering that transport and application
   layer protocols will fail if the switch to a new address pair takes
   too long.

   Section 6.5 suggests default values for the timers associated with
   the exploration process.  The value Initial Probe Timeout (0.5 s)
   specifies the interval between initial attempts to send probes;
   Number of Initial Probes (4) specifies how many initial probes can be
   sent before the exponential backoff procedure needs to be employed.
   This process duplicates the time between every probe if there is no
   response.  Finally, Max probe Timeout (60 s) specifies a limit beyond
   which the probe interval may not grow.  If the exploration process
   reaches this interval, it will continue sending at this rate until a
   suitable response is triggered or the SHIM6 context is garbage
   collected.

5.4.  Protocol Design

   REAP is designed as a modular part of SHIM6 in the hopes that it may
   also be useful in other contexts.  This document defines how it is
   carried within SHIM6, but the actual protocol messages are self-
   contained so that it could be carried by other protocols as well.

   The REAP design allows performing both failure detection and address
   pair exploration in the same sequence of messages, without a need to
   designate a specific point when the current address pair is declared
   inoperational and the search for a new pair begins.  This is useful,
   as the loss of a small number of packets is not a proof that a
   problem exists.  Integrated failure detection and exploration allows
   us to test multiple address pairs simultaneously, including the
   current pair in case it starts working again.  For instance, the



Arkko & Beijnum         Expires December 25, 2006              [Page 14]

Internet-Draft         Failure Detection Protocol              June 2006


   exploration process can refer to keepalive message that succeeded in
   getting to the peer during the reachability testing phase.

   REAP also integrates a return routability function, making it
   unnecessary to perform another roundtrip before a newly discovered
   address can be taken into use.

   This document defines a minimal set of parameters that are carried by
   the messages of the protocol.  Specifically, we have limited the
   parameters to those that are necessary to find a working address
   pair.  We note there may be extensions that are needed in the future
   for various reasons, such as the desire to support load balancing or
   finding best pairs.  An option format has been specified to allow
   this.

5.5.  Example Protocol Runs

   This section has examples of REAP protocol runs in typical scenarios.
   We start with the simplest scenario of two hosts, A and B, that have
   a SHIM6 connection with each other but are not currently sending any
   data.  As neither side sends anything, they also do not expect
   anything back, so there are no messages at all:

    Peer A                                        Peer B
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |
      |                                             |

   Our second example involves an active connection with bidirectional
   payload packet flows.  Here the reception of data from the peer is
   taken as an indication of reachability, so again there are no extra
   packes:














Arkko & Beijnum         Expires December 25, 2006              [Page 15]

Internet-Draft         Failure Detection Protocol              June 2006


    Peer A                                        Peer B
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |              payload packet                 |
      |<--------------------------------------------|
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |                                             |

   The third example is the first one that involves an actual REAP
   message.  Here involves an actual REAP
   message.  Here the hosts communicate in just one direction, so REAP
   messages are needed to indicate to the peer that sends payload
   packets that its packets are getting through:

         EXAMPLE 3: Unidirectional communications

    Peer A                                        Peer B
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |       Keepalive id=p                        |
      |<--------------------------------------------|
      |                                             |
      |              payload packet                 |
      |-------------------------------------------->|
      |                                             |
      |                                             |

   Finally, our last

   The next example involves a failure scenario.  Here A has addresses
   A1 and A2 and B has addresses B1 and B2.  The currently used address
   pairs are (A1, B1) and (B1, A1).  The first of these becomes broken,
   which leads to an exploration process:

              EXAMPLE 4: Failure scenario




Arkko & Beijnum         Expires December 28, 2006              [Page 14]

Internet-Draft         Failure Detection Protocol              June 2006


    Peer A                                        Peer B
      |                                             |
      |           (A1,B1) payload packet            |
      |-------------------------------------------->|
      |                                             |
      |           (B1,A1) payload packet            |



Arkko & Beijnum         Expires December 25, 2006              [Page 16]

Internet-Draft         Failure Detection Protocol              June 2006
      |<--------------------------------------------| Time T1
      |                                             | Path A1->B1
      |           (A1,B1) payload packet            | is now
      |----------------------------------------/    | broken
      |                                             |
      |           (B1,A1) payload packet            |
      |<--------------------------------------------|
      |                                             |
      |           (A1,B1) payload packet            |
      |----------------------------------------/    |
      |                                             |
      |           (B1,A1) payload packet            |
      |<--------------------------------------------|
      |                                             |
      |           (A1,B1) payload packet            |
      |----------------------------------------/    |
      |                                             |
      |                                             | 10 seconds after
      |                                             | T1, sends a com-
      |         (B1,A1) Probe id=p,                 | plaint that
      |                          iseeyou=no         | it is not rec-
      |<--------------------------------------------| eiving anything
      |                                             |
   A realizes                                       |
   that it needs                                    |
   to start the                                     |
   exploration                                      |
      |                                             |
      |     (A1, B1) Probe id=q,                    |
      |                    iseeyou=yes              |
      |                    payload reception rep    |
      |                    probe reception rep(p)   | But it gets lost
      |-------------------------------------/       | due to broken path
      |                                             |
   Retransmission                                   |
   to a different                                   |
   address                                          |
      |                                             |
      |      (A1, B2) Probe id=r,                   |
      |                     iseeyou=yes             |
      |                     payload reception rep   |
      |                     probe reception rep(p)  | This one gets
      |-------------------------------------------->| through
      |                                             |
      |                                             |
      |                                             | B now knows
      |                                             | that A has no
      |      (B1,A1) Probe id=p,                    | problem to receive



Arkko & Beijnum         Expires December 25, 28, 2006              [Page 17] 15]

Internet-Draft         Failure Detection Protocol              June 2006


      |-------------------------------------------->| through. Note
      |                    iseeyou=yes,             | its packets and
      |                    probe reception rep(r)                                             | This one gets
      |<--------------------------------------------| that A has found
      |                                             | a new path to B would also
      |                                             |
      |           (A1,B2) payload packet            |
      |-------------------------------------------->| Payload packets have retransmitted
      |                                             | flow again soon, but in this
      |           (B1,A1) payload packet                                             |
      |<--------------------------------------------|

   The next example shows when the failure for the current locator pair
   is in the other direction:






































Arkko & Beijnum         Expires December 25, 2006              [Page 18]

Internet-Draft         Failure Detection Protocol              June 2006


    Peer A                                        Peer B
      |                                             |
      |           (A1,B1) payload packet            |
      |-------------------------------------------->|
      |                                             |
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------| Time T1
      |                                             | Path B1->A1
      |                                             | is now
      |                                             | broken
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------|
      |                                             |
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------|
      |                                             |
      |                                             | 10 seconds after
      |                                             | T1, sends a com-
      |          (B1,A1) Probe id=p,                | plaint that
      |                        iseeyou=no           | it is not rec-
      |   /-----------------------------------------| eiving anything
      |                                             |
      |         (B2,A2) Probe id=q,                 |
      |                       iseeyou=no            | Next try different
      |<--------------------------------------------| locator pair
      |                                             |
      |      (A2, B2) Probe id=r,                   |
      |                     iseeyou=yes             |
      |                     payload reception rep   |
      |                     probe reception rep(q)  | This one gets
      |-------------------------------------------->| got
      |                                             | through first
      |                                             |
      |                                             |
      |                                             | B now knows
      |                                             | that A has no
      |      (B2,A2)      (B1,A1) Probe id=s, id=p,                    | problem to receive
      |                    iseeyou=yes,             | its packets and
      |                    probe reception rep(r)   | This one gets
      |<--------------------------------------------| that A has found
      |                                             | a new path to B
      |                                             |
      |           (A2,B2)           (A1,B2) payload packet            |
      |-------------------------------------------->| Payload packets
      |                                             | flow again
      |           (B2,A2)           (B1,A1) payload packet            |
      |<--------------------------------------------|

   In the next case we have even less luck.

   The response to next example shows when the REAP failure for the current locator pair
   is in the other direction:



























Arkko & Beijnum         Expires December 25, 28, 2006              [Page 19] 16]

Internet-Draft         Failure Detection Protocol              June 2006


   probe doesn't make it in the reverse direction, so both ends end up
   exploring independently:


              EXAMPLE 5: One-way failure

    Peer A                                        Peer B
      |                                             |
      |           (A1,B1) payload packet            |
      |-------------------------------------------->|
      |                                             |
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------| Time T1
      |                                             | Path B1->A1
      |                                             | is now
      |                                             | broken
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------|
      |                                             |
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------|
      |                                             |
      |                                             | 10 seconds after
      |                                             | T1, sends a com-
      |          (B1,A1) Probe id=p,                | plaint that
      |                        iseeyou=no           | it is not rec-
      |   /-----------------------------------------| eiving anything
      |                                             |
      |         (B2,A2) Probe id=q,                 |
      |                       iseeyou=no            | Next try different
      |<--------------------------------------------| locator pair
      |                                             |
   A now knows that it needs                        |
   to start exploring                               |
      |                                             |
      |      (A2, B2) Probe id=r,                   |
      |                     iseeyou=yes             |
      |                     payload reception rep   |
      |                     probe reception rep(q)  |
      |--------------------------------------/      | Doesn't make it
      |                                             |
      |      (A1, B1) Probe id=s,                   |
      |                     iseeyou=yes             |
      |                     payload reception rep   |
      |                     probe reception rep(q)  | This one gets
      |-------------------------------------------->| through
      |                                             |
      |                                             |
      |                                             | B now knows
      |                                             | that A has no
      |      (B2,A2) Probe id=t, id=s,                    | problem to receive



Arkko & Beijnum         Expires December 25, 2006              [Page 20]

Internet-Draft         Failure Detection Protocol              June 2006
      |                    iseeyou=yes,             | its packets and
      |                    probe reception rep(r)   | This one gets
      |<--------------------------------------------| that A has found
      |                                             | a new path to B
      |                                             |
      |           (A1,B1)           (A2,B2) payload packet            |
      |-------------------------------------------->| Payload packets
      |                                             | flow again
      |           (B2,A2) payload packet            |
      |<--------------------------------------------|

5.6.  Limitations

   REAP is designed to support failure recovery even in the case of
   having only unidirectionally operational address pairs.  However, due
   to security concerns discussed in Section 7, the exploration process
   can typically be run only for a session that has already been
   established.  Specifically, while REAP would in theory be capable of
   exploration even during connection establishment, its use within the
   SHIM6 protocol does not allow this.



Arkko & Beijnum         Expires December 25, 28, 2006              [Page 21] 17]

Internet-Draft         Failure Detection Protocol              June 2006


6.  Protocol Definition

6.1.  Keepalive Message


   In the next case we have even less luck.  The format of response to the keepalive message 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REAP
   probe doesn't make it in the reverse direction, so both ends end up
   exploring independently:

            EXAMPLE 6: Independent exploration

    Peer A                                        Peer B
      |  Next Header                                             |  Hdr Ext Len  |0|  Type = 66
      |   Reserved  |0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           (A1,B1) payload packet            |            Checksum           |R|
      |-------------------------------------------->|
      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                             |
      |                    Receiver Context Tag           (B1,A1) payload packet            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   /-----------------------------------------| Time T1
      |
   +                          Options                              +                                             | Path B1->A1
      |                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header

      This value MUST be set to NO_NXT_HDR (59).

   Hdr Ext Len

      This is an 8-bit unsigned integer field, calculated as specified
      in Section 5.3 of the SHIM6 protocol description
      [I-D.ietf-shim6-proto].

   Type

      This field identifies the Probe message and MUST be set to 66
      (Keepalive).

   Reserved

      This is now
      |                                             | broken
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------|
      |                                             |
      |           (B1,A1) payload packet            |
      |   /-----------------------------------------|
      |                                             |
      |                                             | 10 seconds after
      |                                             | T1, sends a 7-bit field reserved for future use.  It com-
      |         (B1,A1) Probe id=p,                 | plaint that
      |                       iseeyou=no            | it is set not rec-
      |   /-----------------------------------------| eiving anything
      |                                             |
      |         (B2,A2) Probe id=q,                 |
      |                       iseeyou=no            | Next try different
      |<--------------------------------------------| locator pair
      |                                             |
   A now knows that it needs                        |
   to zero
      on transmit, and MUST be ignored on receipt.

   R start exploring                               |
      |                                             |
      |      (A2, B2) Probe id=r,                   |
      |                     iseeyou=yes             |
      |                     payload reception rep   |
      |                     probe reception rep(q)  |
      |--------------------------------------/      | Doesn't make it
      |                                             |
      |      (A1, B1) Probe id=s,                   |
      |                     iseeyou=yes             |
      |                     payload reception rep   |
      |                     probe reception rep(q)  | This is a 1-bit field reserved for future use.  It is set to zero
      on transmit, and MUST be ignored on receipt. one gets
      |-------------------------------------------->| through
      |                                             |
      |                                             |



Arkko & Beijnum         Expires December 25, 28, 2006              [Page 22] 18]

Internet-Draft         Failure Detection Protocol              June 2006


   Checksum

      This is a 16-bit field, calculated as specified in Section 5.3 of
      the SHIM6 protocol description [I-D.ietf-shim6-proto].

   Receiver Context Tag

      This is a 47-bit field for the Context Tag the receiver


      |                                             | B now knows
      |                                             | that A has
      allocated for the context.

   Options

      This MUST contain at least the Keepalive option no
      |      (B2,A2) Probe id=t,                    | problem to receive
      |                    iseeyou=yes,             | its packets and MAY contain
      |                    probe reception rep(r)   | This one or more Reachability options.The inclusion of the latter
      options is not necessary, however, as there are currently no
      defined options gets
      |<--------------------------------------------| that are useful in a Keepalive message.  These
      options are provided only for future extensibility reasons. A valid message conforms to the format above, has found
      |                                             | a Receiver Context
   Tag that matches new path to context known by the receiver, is valid shim
   control message as defined in Section 12.2 of the SHIM6 protocol
   description [I-D.ietf-shim6-proto], and its shim context state is
   ESTABLISHED.  The receiver processes a valid message by inspecting
   its options, and executing any actions specified for such options.

   The processing rules for this message are the given in more detail in
   Section 6.4.

6.1.1.  Keepalive Option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B
      |         Type = 10           |0|            Length                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Res           (A1,B1) payload packet            |
      |-------------------------------------------->| Payload packets
      |                                             | flow again
      |                   Identifier           (B2,A2) payload packet            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This value MUST be set
      |<--------------------------------------------|

4.6.  Limitations

   REAP is designed to 10 (Keepalive Option).

   0

      This value MUST be set support failure recovery even in the case of
   having only unidirectionally operational address pairs.  However, due
   to 0, as security concerns discussed in other Section 6, the exploration process
   can typically be run only for a session that has already been
   established.  Specifically, while REAP would in theory be capable of
   exploration even during connection establishment, its use within the
   SHIM6 options. protocol does not allow this.




























Arkko & Beijnum         Expires December 25, 28, 2006              [Page 23] 19]

Internet-Draft         Failure Detection Protocol              June 2006


   Length

      This is the length of the option and MUST be calculated as
      specified in Section 5.14 of the SHIM6 protocol description
      [I-D.ietf-shim6-proto].

   Res

      This 4-bit reserved field MUST be set to zero when sending, and
      ignored on receipt.

   Identifier

      This 28-bit field identifies this particular instance of an
      Keepalive message.  This value SHOULD be generated using a random
      number generator that is known to have good randomness properties
      as outlined in RFC 1750 [RFC1750].  Upon reception, Identifier
      values from both


5.  Protocol Definition

5.1.  Keepalive and Probe messages may be copied onto
      Probe Reception Report options.  This allows them to be used for
      both identifying which packets were received as well as for
      performing a return routability test. Message

   The processing rules for this option are format of the given in more detail in
   Section 6.4.

6.2.  Probe Message

   This keepalive 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  |  Hdr Ext Len  |0|  Type = 67 66  |   Reserved  |0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |R|                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             |
   |                    Receiver Context Tag                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                          Options                              +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header

      This value MUST be set to NO_NXT_HDR (59).





Arkko & Beijnum         Expires December 25, 2006              [Page 24]

Internet-Draft         Failure Detection Protocol              June 2006

      This value MUST be set to NO_NXT_HDR (59).

   Hdr Ext Len

      This is an 8-bit unsigned integer field, calculated as specified
      in Section 5.3 of the SHIM6 protocol description
      [I-D.ietf-shim6-proto].

   Type

      This field identifies the Probe message and MUST be set to 67
      (Probe). 66
      (Keepalive).

   Reserved

      This is a 7-bit field reserved for future use.  It is set to zero
      on transmit, and MUST be ignored on receipt.

   R

      This is a 1-bit field reserved for future use.  It is set to zero
      on transmit, and MUST be ignored on receipt.







Arkko & Beijnum         Expires December 28, 2006              [Page 20]

Internet-Draft         Failure Detection Protocol              June 2006


   Checksum

      This is a 16-bit field, calculated as specified in Section 5.3 of
      the SHIM6 protocol description [I-D.ietf-shim6-proto].

   Receiver Context Tag

      This is a 47-bit field for the Context Tag the receiver has
      allocated for the context.

   Options

      This MUST contain at least the Probe Keepalive option and MAY contain
      one or more Reachability options. options.The inclusion of the latter
      options is not necessary, however, as there are currently no
      defined options that are useful in a Keepalive message.  These
      options are provided only for future extensibility reasons.

   A valid message conforms to the format above, has a Receiver Context
   Tag that matches to a context known by the receiver, is valid shim
   control message as defined in Section 12.2 of the SHIM6 protocol
   description [I-D.ietf-shim6-proto], and its shim context state is
   ESTABLISHED.  The receiver processes a valid message by inspecting
   its options, and executing any actions specified for such options.

   The processing rules for this message are the given in more detail in
   Section 5.4.

5.1.1.  Keepalive Option

    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           |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |                   Identifier                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This value MUST be set to 10 (Keepalive Option).

   0

      This value MUST be set to 0, as in other SHIM6 options.






Arkko & Beijnum         Expires December 28, 2006              [Page 21]

Internet-Draft         Failure Detection Protocol              June 2006


   Length

      This
   includes is the length of the option and MUST be calculated as
      specified in Section 5.14 of the SHIM6 protocol description
      [I-D.ietf-shim6-proto].

   Res

      This 4-bit reserved field MUST be set to zero when sending, and
      ignored on receipt.

   Identifier

      This 28-bit field identifies this particular instance of an
      Keepalive message.  This value SHOULD be generated using a random
      number generator that is known to have good randomness properties
      as outlined in RFC 1750 [RFC1750].  Upon reception, Identifier
      values from both Keepalive and Probe messages may be copied onto
      Probe option found within the Reception Report options.  This allows them to be used for
      both identifying which packets were received as well as for
      performing a return routability test.

   The processing rules for this message option are the given in more detail in
   Section 6.4.





Arkko & Beijnum         Expires December 25, 2006              [Page 25]

Internet-Draft         Failure Detection Protocol              June 2006


6.2.1. 5.4.

5.2.  Probe Option 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  |  Hdr Ext Len  |0|  Type = 11 67  |   Reserved  |0|            Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Checksum           |R|                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             |
   |                    Receiver Context Tag                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Y| Res
   |                   Identifier                                                               |
   +                          Options                              +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This value MUST be set to 11 (Probe Option).

   0

   Next Header

      This value MUST be set to 0, as in other SHIM6 options.

   Length NO_NXT_HDR (59).





Arkko & Beijnum         Expires December 28, 2006              [Page 22]

Internet-Draft         Failure Detection Protocol              June 2006


   Hdr Ext Len

      This is the length of the option and MUST be an 8-bit unsigned integer field, calculated as specified
      in Section 5.14 5.3 of the SHIM6 protocol description
      [I-D.ietf-shim6-proto].

   Y (The "I See You" flag)

   Type

      This flag is set to 1 if the sender receives either payload
      packets or REAP messages from field identifies the peer, Probe message and 0 otherwise.  The
      determination of when the sender receives something MUST be set to 67
      (Probe).

   Reserved

      This is made during
      the last Send Timeout seconds (see Section 6.5) when traffic was
      expected, i.e., when there was either payload traffic or REAP
      messages.

      Upon reception, a value of 1 indicates that the receiver does not
      need to change its behaviour as the sender 7-bit field reserved for future use.  It is already seeing its
      packets.  A value of 0 indicates that the receiver set to zero
      on transmit, and MUST explore
      different outgoing address pairs.

   Res be ignored on receipt.

   R

      This 3-bit reserved is a 1-bit field MUST be reserved for future use.  It is set to zero when sending,
      on transmit, and MUST be ignored on receipt.

   Identifier

   Checksum

      This 28-bit field identifies this particular instance is a 16-bit field, calculated as specified in Section 5.3 of an Probe
      message.
      the SHIM6 protocol description [I-D.ietf-shim6-proto].

   Receiver Context Tag

      This value SHOULD be generated using a random number
      generator that is known to have good randomness properties.  Upon



Arkko & Beijnum         Expires December 25, 2006              [Page 26]

Internet-Draft         Failure Detection Protocol              June 2006


      reception, Identifier values are copied onto a 47-bit field for the Context Tag the receiver has
      allocated for the context.

   Options

      This MUST contain at least the Probe Reception
      Report option and MAY contain one or
      more Reachability options.  This allows them

   A valid message conforms to be used for both identifying
      which Probes were received as well the format above, has a Receiver Context
   Tag that matches to a context known by the receiver, is valid shim
   control message as for performing defined in Section 12.2 of the SHIM6 protocol
   description [I-D.ietf-shim6-proto], and its shim context state is
   ESTABLISHED.  The receiver processes a return
      routability test. valid message by inspecting
   its options, and executing any actions specified such options.  This
   includes the SHIM6 Probe option found within the options.

   The processing rules for this option message are the given in more detail in
   Section 6.4.

6.3.  Reachability Option

   Additional information can be included in Keepalive and 5.4.





Arkko & Beijnum         Expires December 28, 2006              [Page 23]

Internet-Draft         Failure Detection Protocol              June 2006


5.2.1.  Probe
   messages by the inclusion of the Reachability Options.  Their format
   is as follows: Option

    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 = 12 11           |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Y| Res |          Option Type          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                   Identifier                          |
   ~                         Option Data                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      This value MUST be set to 12 (Reachability option). 11 (Probe Option).

   0

      This value MUST be set to 0, as in other SHIM6 options.

   Length

      This is the length of the option and MUST be calculated as
      specified in Section 5.14 of the SHIM6 protocol description
      [I-D.ietf-shim6-proto].

   Option Type

   Y (The "I See You" flag)

      This value identifies the option.

   Option Data

      Option-specific content.

   Unrecognized options MUST be ignored upon receipt.  All
   implementations MUST support flag is set to 1 if the options defined in this



Arkko & Beijnum         Expires December 25, 2006              [Page 27]

Internet-Draft         Failure Detection Protocol              June 2006


   specification, however.

6.3.1.  Payload Reception Report

   This option SHOULD be included in all Probe sender receives either payload
      packets or REAP messages from the peer, and 0 otherwise.  The
      determination of when the sender
   has recently (within receives something is made during
      the last Send Timeout seconds) received seconds (see Section 5.5) when traffic was
      expected, i.e., when there was either payload
   packets from traffic or REAP
      messages.

      Upon reception, a value of 1 indicates that the peer.  Its format is receiver does not
      need to change its behaviour 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 the sender is already seeing its
      packets.  A value of 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type = 11           |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Option Type = 1         |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Suboptions                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type, 0, and Length

      These are as specified above.

   Reserved indicates that the receiver MUST explore
      different outgoing address pairs.

   Res

      This is a 16-bit field 3-bit reserved for future use.  It is field MUST be set to zero
      on transmit, when sending, and MUST be
      ignored on receipt.

   Suboptions

   Identifier

      This 28-bit field is reserved for possible future Reachability options
      that are carried (recursively) within identifies this option.  Unrecognized
      options MUST particular instance of an Probe
      message.  This value SHOULD be ignored upon receipt.  Currently there are no
      defined options generated using a random number
      generator that can be carried here.

6.3.2. is known to have good randomness properties.  Upon



Arkko & Beijnum         Expires December 28, 2006              [Page 24]

Internet-Draft         Failure Detection Protocol              June 2006


      reception, Identifier values are copied onto Probe Reception
      Report options.  This allows them to be used for both identifying
      which Probes were received as well as for performing a return
      routability test.

   The processing rules for this option MUST are the given in more detail in
   Section 5.4.

5.3.  Reachability Option

   Additional information can be included in any Probe message when the sender has
   recently (within the last Send Timeout seconds) received Probe or Keepalive messages from the peer.  Depending on MTU and timing
   considerations, Probe
   messages by the sender MAY, however, include options for only
   some inclusion of the received Probe messages.  All implementations MUST
   support sending of at least five such options, however.

   The Reachability Options.  Their format of this option
   is as follows:







Arkko & Beijnum         Expires December 25, 2006              [Page 28]

Internet-Draft         Failure Detection Protocol              June 2006

    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 = 11 12           |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Option Type = 2         |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          | Res                               |                     Identifier
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Suboptions                         Option Data                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type, 0, and Length

      These are as specified above.

   Option

   Type

      This value identifies the option and MUST be set to 2 (Probe
      Reception Report).

   Reserved

      This is a 16-bit field reserved for future use.  It is set to zero
      on transmit, and MUST be ignored on receipt.

   Res

      This is a 3-bit field reserved for future use.  It is value MUST be set to zero
      on transmit, and 12 (Reachability option).

   0

      This value MUST be ignored on receipt.

   Identifier set to 0, as in other SHIM6 options.

   Length

      This 32 bit field carries is the identifier length of the Probe message that
      was recently received.

   Suboptions

      This field is reserved for possible future Reachability options
      that are carried (recursively) within this option.  Unrecognized
      options option and MUST be ignored upon receipt.  Currently there are no
      defined options that can be carried here.

6.4.  Behaviour

   The required behaviour of REAP nodes is calculated as
      specified below in the form
   of a state machine.  The externally observable behaviour of an
   implementation MUST conform to this state machine, but there is no



Arkko & Beijnum         Expires December 25, 2006              [Page 29]

Internet-Draft         Failure Detection Protocol              June 2006


   requirement that the implementation actually employs a state machine.

   On a given context with a given peer, the node can be in one Section 5.14 of three
   states: Operational, Exploring, or ExploringOK.  In the Operational
   state SHIM6 protocol description
      [I-D.ietf-shim6-proto].

   Option Type

      This value identifies the underlying address pairs are assumed to option.

   Option Data

      Option-specific content.

   Unrecognized options MUST be operational.  In
   the Exploring state this node has observed a problem and has
   currently not seen any traffic from the peer.  Finally, in the
   ExploringOK state this node sees traffic from the peer, but peer may
   not yet see any traffic from this node so that the exploration
   process needs to continue.

   The node maintains also the Send and Keepalive timers.  The Send
   timer reflects ignored upon receipt.  All
   implementations MUST support the requirement that when options defined in this node sends a payload
   packet there should



Arkko & Beijnum         Expires December 28, 2006              [Page 25]

Internet-Draft         Failure Detection Protocol              June 2006


   specification, however.

5.3.1.  Payload Reception Report

   This option SHOULD be some return traffic (either payload packets or
   Keepalive messages) within included in all Probe messages when the sender
   has recently (within the last Send Timeout seconds.  The Keepalive timer
   reflects the requirement that when this node receives a seconds) received payload
   packet there should a similar response towards
   packets from the peer.  The
   Keepalive timer  Its format is only used within the Operational state, and the
   Send timer in the Operational 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type = 12           |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Option Type = 1         |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Suboptions                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type, 0, and ExploringOK states.  No timer Length

      These are as specified above.

   Reserved

      This is
   running in the Exploring state.

   Upon the reception of a payload packet in the Operational state, the
   node starts the Keepalive timer if it 16-bit field reserved for future use.  It is not yet running, set to zero
      on transmit, and stops
   the Send timer if it was running.  If the node MUST be ignored on receipt.

   Suboptions

      This field is reserved for possible future Reachability options
      that are carried (recursively) within this option.  Unrecognized
      options MUST be ignored upon receipt.  Currently there are no
      defined options that can be carried here.

5.3.2.  Probe Reception Report

   This option MUST be included in the Exploring
   state it transitions to the ExploringOK state, sends a any Probe message
   with the I See You flag set to 1 (Yes), and starts the Send timer.
   In the ExploringOK state when the node stops sender has
   recently (within the last Send timer if it was
   running, but does not do anything else.  The reception of SHIM6
   control messages other than the Keepalive and Timeout seconds) received Probe messages are
   treated similarly with payload packets.

   Upon sending a payload packet in the Operational state, the node
   stops the or
   Keepalive timer if it was running and starts the Send timer
   if it was not running.  In messages from the Exploring state there is no effect, peer.  Depending on MTU and in the ExploringOK state timing
   considerations, the node simply starts sender MAY, however, include options for only
   some of the Send timer if
   it was not yet running.  (The received Probe messages.  All implementations MUST
   support sending of SHIM6 control messages at least five such options, however.

   The format of this option is
   again treated similarly here.)

   Upon a timeout on the Keepalive timer the node sends a Keepalive
   message. as follows:







Arkko & Beijnum         Expires December 28, 2006              [Page 26]

Internet-Draft         Failure Detection Protocol              June 2006


    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 = 12           |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Option Type = 2         |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Res |                     Identifier                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Suboptions                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type, 0, and Length

      These are as specified above.

   Option Type

      This can only happen in value identifies the Operational state.

   Upon option and MUST be set to 2 (Probe
      Reception Report).

   Reserved

      This is a timeout 16-bit field reserved for future use.  It is set to zero
      on the Send timer, the node enters the Exploring state transmit, and sends MUST be ignored on receipt.

   Res

      This is a Probe with I See You 3-bit field reserved for future use.  It is set to 0 (No) zero
      on transmit, and stops the
   Keepalive timer if it was running.

   While in MUST be ignored on receipt.

   Identifier

      This 32 bit field carries the Exploring state identifier of the node keeps retransmitting its Probe
   messages to different (or same) addresses as message that
      was recently received.

   Suboptions

      This field is reserved for possible future Reachability options
      that are carried (recursively) within this option.  Unrecognized
      options MUST be ignored upon receipt.  Currently there are no
      defined in Section 5.3.
   A similar process options that can be carried here.

5.4.  Behaviour

   The required behaviour of REAP nodes is employed specified below in the ExploringOk state, except that form
   of a state machine.  The externally observable behaviour of an
   implementation MUST conform to this state machine, but there is no



Arkko & Beijnum         Expires December 25, 28, 2006              [Page 30] 27]

Internet-Draft         Failure Detection Protocol              June 2006


   upon such retransmission


   requirement that the Send timer is started if it was not
   running already.

   Upon implementation actually employs a state machine.
   Intermixed with the reception of following description we also provide a Keepalive message state
   machine description in the Operational state,
   the node stops the Send timer, if it was running.  If a tabular form.  That form is only
   informational, however.

   On a given context with a given peer, the node is can be in one of three
   states: Operational, Exploring, or ExploringOK.  In the Exploring Operational
   state it transitions the underlying address pairs are assumed to be operational.  In
   the ExploringOK state, sends Exploring state this node has observed a
   Probe message with the I See You flag set to 1 (Yes), problem and starts has
   currently not seen any traffic from the
   Send timer.  In peer.  Finally, in the
   ExploringOK state this node sees traffic from the peer, but peer may
   not yet see any traffic from this node so that the exploration
   process needs to continue.

   The node maintains also the Send and Keepalive timers.  The Send
   timer is stopped, if
   it was running.

   Upon receiving a Probe with I See You set to 0 (No) reflects the requirement that when this node enters
   the ExploringOK state, sends a Probe with I See You set to 1 (Yes),
   stops payload
   packet there should be some return traffic (either payload packets or
   Keepalive messages) within Send Timeout seconds.  The Keepalive timer
   reflects the requirement that when this node receives a payload
   packet there should a similar response towards the peer.  The
   Keepalive timer if it was running, is only used within the Operational state, and restarts the
   Send
   timer.

   The behavior upon timer in the reception of a Probe message with I see You set
   to 1 (Yes) depends on whether it contains a Probe Reception Report
   that refers to Operational and ExploringOK states.  No timer is
   running in the Exploring state.

   Upon the reception of a Probe that this payload packet in the Operational state, the
   node has sent to starts the peer such that Keepalive timer if it is not yet running, and stops
   the I See You Send timer if it was set to 1 in that message. running.  If not, the node is in the Exploring
   state it transitions to the ExploringOK state, sends a Probe message
   with the I See You flag set to 1 (Yes), restarts and starts the Send timer,
   stops the Keepalive timer if it was running, and transitions to timer.
   In the
   Operational state.

   If there was no such Probe Reception Report, ExploringOK state the node stops the Send timer if it was
   running, starts the Keepalive timer if it was but does not yet
   running, and transitions to the Operational state.

      Note: This check is necessary in order to terminate the
      exploration process when both parties are happy and know that
      their peers are happy as well. do anything else.  The reachability detection and exploration process has no effect on
   payload communications until a new working address pairs have
   actually been confirmed.  Prior to that the payload packets continue
   to be sent to the previously used addresses.

   Garbage collection reception of SHIM6 contexts terminates contexts that are
   either unused or have failed due to the inability of the exploration
   process to find a working pair.

   In the PDF version of this specification, an informational drawing
   illustrates the state machine.  Where
   control messages other than the text Keepalive and the drawing
   differ, the text takes precedence.


   A tabular representation of the state machine is shown below.  Like
   the drawing, this representation is only informational.




Arkko & Beijnum         Expires December 25, 2006              [Page 31]

Internet-Draft         Failure Detection Protocol              June 2006 Probe messages are
   treated similarly with payload packets.

     1. EVENT: Incoming payload packet
     =================================

     Operational              Exploring                ExploringOk
   ---------------------------------------------------------------
     -------------------------------------------------------------
     STOP Send;               SEND Probe Y=Yes;        STOP Send
     START Keepalive          START Send;
                              GOTO ExploringOk

   Upon sending a payload packet in the Operational state, the node
   stops the Keepalive timer if it was running and starts the Send timer
   if it was not running.  In the Exploring state there is no effect,
   and in the ExploringOK state the node simply starts the Send timer if
   it was not yet running.  (The sending of SHIM6 control messages is



Arkko & Beijnum         Expires December 28, 2006              [Page 28]

Internet-Draft         Failure Detection Protocol              June 2006


   again treated similarly here.)

     2. EVENT: Outgoing payload packet
     =================================

     Operational              Exploring                ExploringOk
   ---------------------------------------------------------------
     -------------------------------------------------------------
     START Send;              -                        START Send
     STOP Keepalive

   Upon a timeout on the Keepalive timer the node sends a Keepalive
   message.  This can only happen in the Operational state.

     3. EVENT: Keepalive timeout

     Operational              Exploring                ExploringOk
   ---------------------------------------------------------------
     -------------------------------------------------------------
     SEND Keepalive           -                        -

   Upon a timeout on the Send timer, the node enters the Exploring state
   and sends a Probe with I See You set to 0 (No) and stops the
   Keepalive timer if it was running.

     4. EVENT: Send timeout
     ======================

     Operational              Exploring                ExploringOk
   ---------------------------------------------------------------
     -------------------------------------------------------------
     SEND Probe Y=No;         -                        SEND Probe Y=No
   STOP Keepalive;                                     GOTO EXPLORING
   GOTO EXPLORING


   5. Y=No
     STOP Keepalive;                                   GOTO Exploring
     GOTO Exploring

   While in the Exploring state the node keeps retransmitting its Probe
   messages to different (or same) addresses as defined in Section 4.3.
   A similar process is employed in the ExploringOk state, except that
   upon such retransmission the Send timer is started if it was not
   running already.

     5. EVENT: Retransmission
     ========================

     Operational              Exploring                ExploringOk
     -------------------------------------------------------------
     -                        SEND Probe Y=No          SEND Probe Y=Yes
                                                       START Send

   Upon the reception of a Keepalive message in the Operational state,
   the node stops the Send timer, if it was running.  If the node is in



Arkko & Beijnum         Expires December 28, 2006              [Page 29]

Internet-Draft         Failure Detection Protocol              June 2006


   the Exploring state it transitions to the ExploringOK state, sends a
   Probe message with the I See You flag set to 1 (Yes), and starts the
   Send timer.  In the ExploringOK state the Send timer is stopped, if
   it was running.

     6. EVENT: Reception of the Keepalive message
     ============================================

     Operational              Exploring                ExploringOk
   ---------------------------------------------------------------
     -------------------------------------------------------------
     STOP Send                SEND Probe Y=Yes;        STOP Send
                              START Send;
                              GOTO ExploringOk


   6.

   Upon receiving a Probe with I See You set to 0 (No) the node enters
   the ExploringOK state, sends a Probe with I See You set to 1 (Yes),
   stops the Keepalive timer if it was running, and restarts the Send
   timer.

     7. EVENT: Reception of the Probe message with Y=No
     ==================================================



Arkko & Beijnum         Expires December 25, 2006              [Page 32]

Internet-Draft         Failure Detection Protocol              June 2006

     Operational              Exploring                ExploringOk
   ---------------------------------------------------------------
     -------------------------------------------------------------
     SEND Probe Y=Yes         SEND Probe Y=Yes;        SEND Probe Y=Yes;
     STOP Keepalive;          START Send;              RESTART Send
     RESTART Send;            GOTO EXPLORINGOK ExploringOk
     GOTO EXPLORINGOK


   7. ExploringOk

   The behavior upon the reception of a Probe message with I see You set
   to 1 (Yes) depends on whether it contains a Probe Reception Report
   that refers to a Probe that this node has sent to the peer such that
   the I See You was set to 1 in that message.  If it does, the node
   sends a Probe message with I See You set to 1 (Yes), restarts the
   Send timer, stops the Keepalive timer if it was running, and
   transitions to the Operational state.

     8. EVENT: Reception of the Probe message with Y=Yes
               (peer reports not seeing seeing yet a Probe with Y=Yes)
     ==========================================================

     Operational              Exploring                ExploringOk
     -------------------------------------------------------------
     SEND Probe Y=Yes;        SEND Probe Y=Yes;        SEND Probe Y=Yes;
     RESTART Send;            RESTART Send;            RESTART Send;
     STOP Keepalive           GOTO Operational         GOTO Operational

   If there was no such Probe Reception Report, the stops the Send timer



Arkko & Beijnum         Expires December 28, 2006              [Page 30]

Internet-Draft         Failure Detection Protocol              June 2006


   if it was running, starts the Keepalive timer if it was not yet a Probe with Y=Yes)
   ==========================================================
   running, and transitions to the Operational               Exploring                 ExploringOk
   ---------------------------------------------------------------
   SEND Probe Y=Yes;         SEND Probe Y=Yes;         SEND Probe Y=Yes;
   RESTART Send;             RESTART Send;             RESTART Send;
   STOP Keepalive            GOTO OPERATIONAL          GOTO OPERATIONAL


   8. state.

      Note: This check is necessary in order to terminate the
      exploration process when both parties are happy and know that
      their peers are happy as well.


     9. EVENT: Reception of the Probe message with Y=Yes
               (peer reports seeing a Probe with Y=Yes)
     ===================================================

     Operational              Exploring                ExploringOk
   ---------------------------------------------------------------
     -------------------------------------------------------------
     STOP Send                STOP Send;               STOP Send;
     START Keepalive          START Keepalive          START Keepalive
                              GOTO OPERATIONAL Operational         GOTO OPERATIONAL


   9. EVENT: Retransmission
   ======================== Operational               Exploring                 ExploringOk
   ---------------------------------------------------------------
   -                         SEND Probe Y=No           SEND Probe Y=Yes
                                                       START Send

6.5.

   The reachability detection and exploration process has no effect on
   payload communications until a new operational address pairs have
   actually been confirmed.  Prior to that the payload packets continue
   to be sent to the previously used addresses.

   Garbage collection of SHIM6 contexts terminates contexts that are
   either unused or have failed due to the inability of the exploration
   process to find an operational pair.

   In the PDF version of this specification, an informational drawing
   illustrates the state machine.  Where the text and the drawing
   differ, the text takes precedence.


5.5.  Protocol Constants

   The following protocol constants are defined:

   Send Timeout                              10 seconds
   Keepalive Timeout                          3 seconds
   Initial Probe Timeout                    0.5 seconds
   Number of Initial Probes                   4 probes
   Max Probe Timeout                         60 seconds










Arkko & Beijnum         Expires December 25, 28, 2006              [Page 33] 31]

Internet-Draft         Failure Detection Protocol              June 2006


7.


6.  Security Considerations

   Attackers may spoof various indications from lower layers and the
   network in an effort to confuse the peers about which addresses are
   or are not working. operational.  For example, attackers may spoof ICMP error
   messages in an effort to cause the parties to move their traffic
   elsewhere or even to disconnect.  Attackers may also spoof
   information related to network attachments, router discovery, and
   address assignments in an effort to make the parties believe they
   have Internet connectivity when in reality they do not.

   This may cause use of non-preferred addresses or even denial-of-
   service.

   This protocol does not provide any protection of its own for
   indications from other parts of the protocol stack.  Unprotected
   indications SHOULD NOT be taken as a proof of connectivity problems.
   However, REAP has weak resistance against incorrect information even
   from unprotected indications in the sense that it performs its own
   tests prior to picking a new address pair.  Denial-of- service
   vulnerabilities remain, however, as do vulnerabilities against on
   path attackers.

   Some aspects of these vulnerabilities can be mitigated through the
   use of techniques specific to the other parts of the stack, such as
   properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link
   layer security, or the use of SEND [RFC3971] to protect IPv6 Router
   and Neighbor Discovery.

   Other parts of the SHIM6 protocol ensure that the set of addresses we
   are switching between actually belong together.  REAP itself provides
   no such assurances.  Similarly, REAP provides only minimal protection
   against third party flooding attacks; when REAP is run its Probe
   identifiers can be used as a return routability check that return routability check that the
   claimed address is indeed willing to receive traffic.  However, this
   needs to be complemented with another mechanism to ensure that the
   claimed address is also the correct host.  SHIM6 does this by
   performing binding of all operations to context tags.

   The keepalive mechanism in this specification is vulnerable to
   spoofing.  On path-attackers that can see a SHIM6 context tag can
   send spoofed Keepalive messages once per Send Timeout interval, to
   prevent two SHIM6 nodes from sending Keepalives themselves.  This
   vulnerability is only relevant to nodes involved in a one-way
   communication.  The result of the
   claimed address attack is indeed willing that the nodes enter the
   exploration phase needlessly, but they should be able to receive traffic.  However, this
   needs confirm
   connectivity unless, of course, the attacker is able to prevent the
   exploration phase from completing.  Off-path attackers may not be complemented with another mechanism



Arkko & Beijnum         Expires December 28, 2006              [Page 32]

Internet-Draft         Failure Detection Protocol              June 2006


   able to ensure generate spoofed results, given that the
   claimed address context tags are 47-
   bit random numbers.

   The exploration phase is also vulnerable to attackers that are on the
   path.  Off-path attackers would find it hard to guess either the
   context tag or the correct host.  SHIM6 does this by
   performing binding probe identifiers.  Given that IPsec
   operates above the shim layer, it is not possible to protect the
   exploration phase against on-path attackers.  This is similar to the
   ability to protect other Shim6 control exchanges.  There are
   mechanisms in place to prevent the redirection of all operations communications to context tags.
   wrong addresses, but on-path attackers can cause denial-of-service,
   move communications to less-preferred address pairs, and so on.

   Finally, the exploration itself can cause a number of packets to be
   sent.  As a result it may be used as a tool for packet amplification
   in flooding attacks.  In order to prevent this it is required that
   the protocol employing REAP has built-in mechanisms to prevent this.
   For instance, in SHIM6 contexts are created only after a relatively
   large number of packets has been exchanged, a cost which reduces the
   attractiveness of using SHIM6 and REAP for amplification attacks.
   However, such protections are typically not present at connection
   establishment time.  When exploration would be needed for connection



Arkko & Beijnum         Expires December 25, 2006              [Page 34]

Internet-Draft         Failure Detection Protocol              June 2006
   establishment to succeed, its usage would result in an amplification
   vulnerability.  As a result, SHIM6 does not support the use of REAP
   in connection establishment stage.


























Arkko & Beijnum         Expires December 25, 28, 2006              [Page 35] 33]

Internet-Draft         Failure Detection Protocol              June 2006


8.


7.  IANA Considerations

   This document creates one new name spaces under the new SHIM6
   Reachability Protocol repository.  The name space is for Reachability
   Option Type (Section 6.3) 5.3) and it has one reserved value (0) and two
   defined values, 1 (Payload Reception Report defined in Section 6.3.1) 5.3.1)
   and 2 (Probe Reception Report defined in Section 6.3.2). 5.3.2).  Further
   allocations within this 16-bit field can be made through
   Specification Required.  The range from 65000 to 65535 is reserved
   for experimental use.









































Arkko & Beijnum         Expires December 25, 28, 2006              [Page 36] 34]

Internet-Draft         Failure Detection Protocol              June 2006


9.


8.  References

9.1.

8.1.  Normative References

   [RFC1750]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

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

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 2006.

9.2.

8.2.  Informative References

   [AURA02]   Aura, T., Roe, M., and J. Arkko, "Security of Internet
              Location Management", In Proceedings of the 18th Annual
              Computer Security Applications Conference, Las Vegas,
              Nevada, USA., December 2002.

   [I-D.bagnulo-shim6-addr-selection]
              Bagnulo, M., "Address selection in multihomed
              environments", draft-bagnulo-shim6-addr-selection-00 (work
              in progress), October 2005.

   [I-D.huitema-multi6-addr-selection]
              Huitema, C., "Address selection in multihomed
              environments", draft-huitema-multi6-addr-selection-00
              (work in progress), October 2004.

   [I-D.ietf-dna-cpl]



Arkko & Beijnum         Expires December 25, 28, 2006              [Page 37] 35]

Internet-Draft         Failure Detection Protocol              June 2006


              Nordmark, E. and J. Choi, "DNA with unmodified routers:
              Prefix list based approach", draft-ietf-dna-cpl-02 (work
              in progress), January 2006.

   [I-D.ietf-dna-protocol]
              Kempf, J., "Detecting Network Attachment in IPv6 Networks
              (DNAv6)", draft-ietf-dna-protocol-00 (work in progress),
              February 2006.

   [I-D.ietf-hip-mm]
              Nikander, P., "End-Host Mobility and Multihoming with the
              Host Identity Protocol", draft-ietf-hip-mm-03 (work in
              progress), March 2006.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Methodology for Network  Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-08 (work in progress), March 2006.

   [I-D.ietf-shim6-proto]
              Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
              protocol", draft-ietf-shim6-proto-05 (work in progress),
              May 2006.

   [I-D.ietf-shim6-reach-detect]
              Beijnum, I., "Shim6 Reachability Detection",
              draft-ietf-shim6-reach-detect-01 (work in progress),
              October 2005.

   [I-D.ietf-tcpm-icmp-attacks]
              Gont, F., "ICMP attacks against TCP",
              draft-ietf-tcpm-icmp-attacks-00 (work in progress),
              February 2006.

   [I-D.ietf-tsvwg-addip-sctp]
              Stewart, R., "Stream Control Transmission Protocol (SCTP)
              Dynamic Address  Reconfiguration",
              draft-ietf-tsvwg-addip-sctp-15 (work in progress),
              June 2006.

   [I-D.rosenberg-midcom-turn]
              Rosenberg, J., "Traversal Using Relay NAT (TURN)",
              draft-rosenberg-midcom-turn-08 (work in progress),
              September 2005.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,



Arkko & Beijnum         Expires December 25, 2006              [Page 38]

Internet-Draft         Failure Detection Protocol              June 2006
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4436]  Aboba, B., Carlson, J., and S. Cheshire, "Detecting
              Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.















Arkko & Beijnum         Expires December 25, 28, 2006              [Page 39] 36]

Internet-Draft         Failure Detection Protocol              June 2006


Appendix A.  Contributors

   This draft attempts to summarize the thoughts and unpublished
   contributions of many people, including the MULTI6 WG design team
   members Marcelo Bagnulo Braun, Iljitsch van Beijnum, Erik Nordmark,
   Geoff Huston, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG
   contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer
   Dawkins, and James Kempf, and my colleague Pekka Nikander at
   Ericsson.  This draft is also in debt to work done in the context of
   SCTP [RFC2960] and HIP [I-D.ietf-hip-mm].









































Arkko & Beijnum         Expires December 25, 28, 2006              [Page 40] 37]

Internet-Draft         Failure Detection Protocol              June 2006


Appendix B.  Acknowledgements

   The author authors would also like to thank Christian Huitema, Pekka Savola,
   John Loughney, Sam Xia, and Hannes Tschofenig for interesting
   discussions in this problem space, and for review of this
   specification.













































Arkko & Beijnum         Expires December 25, 28, 2006              [Page 41] 38]

Internet-Draft         Failure Detection Protocol              June 2006


Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@ericsson.com


   Iljitsch van Beijnum
   Muada
   The Netherlands

   Email: iljitsch@muada.com




































Arkko & Beijnum         Expires December 25, 28, 2006              [Page 42] 39]

Internet-Draft         Failure Detection Protocol              June 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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





Arkko & Beijnum         Expires December 25, 28, 2006              [Page 43] 40]

----