doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc5534.txt b/doc/rfc/rfc5534.txt
new file mode 100644
index 0000000..4a85228
--- /dev/null
+++ b/doc/rfc/rfc5534.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                           J. Arkko
+Request for Comments: 5534                                      Ericsson
+Category: Standards Track                                 I. van Beijnum
+                                                          IMDEA Networks
+                                                               June 2009
+
+
+                   Failure Detection and Locator Pair
+               Exploration Protocol for IPv6 Multihoming
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Abstract
+
+   This document specifies how the level 3 multihoming Shim6 protocol
+   (Shim6) detects failures between two communicating nodes.  It also
+   specifies an exploration protocol for switching to another pair of
+   interfaces and/or addresses between the same nodes if a failure
+   occurs and an operational pair can be found.
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 1]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements Language ...........................................4
+   3. Definitions .....................................................4
+      3.1. Available Addresses ........................................4
+      3.2. Locally Operational Addresses ..............................5
+      3.3. Operational Address Pairs ..................................5
+      3.4. Primary Address Pair .......................................7
+      3.5. Current Address Pair .......................................7
+   4. Protocol Overview ...............................................8
+      4.1. Failure Detection ..........................................8
+      4.2. Full Reachability Exploration .............................10
+      4.3. Exploration Order .........................................11
+   5. Protocol Definition ............................................13
+      5.1. Keepalive Message .........................................13
+      5.2. Probe Message .............................................14
+      5.3. Keepalive Timeout Option Format ...........................18
+   6. Behavior .......................................................19
+      6.1. Incoming Payload Packet ...................................20
+      6.2. Outgoing Payload Packet ...................................21
+      6.3. Keepalive Timeout .........................................21
+      6.4. Send Timeout ..............................................22
+      6.5. Retransmission ............................................22
+      6.6. Reception of the Keepalive Message ........................22
+      6.7. Reception of the Probe Message State=Exploring ............23
+      6.8. Reception of the Probe Message State=InboundOk ............23
+      6.9. Reception of the Probe Message State=Operational ..........23
+      6.10. Graphical Representation of the State Machine ............24
+   7. Protocol Constants and Variables ...............................24
+   8. Security Considerations ........................................25
+   9. Operational Considerations .....................................27
+   10. References ....................................................28
+      10.1. Normative References .....................................28
+      10.2. Informative References ...................................29
+   Appendix A. Example Protocol Runs..................................30
+   Appendix B. Contributors...........................................35
+   Appendix C. Acknowledgements.......................................35
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 2]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+1.  Introduction
+
+   The Shim6 protocol [RFC5533] 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 nodes 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).
+
+   Failure detection is made as lightweight as possible.  Payload data
+   traffic in both directions is observed, and in the case where there
+   is no traffic because the communication is idle, failure detection is
+   also idle and doesn't generate any packets.  When payload traffic is
+   flowing in both directions, there is no need to send failure
+   detection packets, either.  Only when there is traffic in one
+   direction does the failure detection mechanism generate keepalives in
+   the other direction.  As a result, whenever there is outgoing traffic
+   and no incoming return traffic or keepalives, there must be failure,
+   at which point the locator pair exploration is performed to find a
+   working address pair for each direction.
+
+   This document is structured as follows: Section 3 defines a set of
+   useful terms, Section 4 gives an overview of REAP, and Section 5
+   provides a detailed definition.  Section 6 specifies behavior, and
+   Section 7 discusses protocol constants.  Section 8 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 said node ends up with a legitimate
+   locator.
+
+   REAP has been designed to be used with Shim6 and is therefore
+   tailored to an environment where it typically runs on hosts, uses
+   widely varying types of paths, and is unaware of application context.
+   As a result, REAP attempts to be as self-configuring and unobtrusive
+   as possible.  In particular, it avoids sending any packets except
+   where absolutely required and employs exponential back-off to avoid
+   congestion.  The downside is that it cannot offer the same
+   granularity of detecting problems as mechanisms that have more
+   application context and ability to negotiate or configure parameters.
+
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 3]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   Future versions of this specification may consider extensions with
+   such capabilities, for instance, through inheriting some mechanisms
+   from the Bidirectional Forwarding Detection (BFD) protocol [BFD].
+
+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].
+
+3.  Definitions
+
+   This section defines terms useful for discussing failure detection
+   and locator pair exploration.
+
+3.1.  Available Addresses
+
+   Shim6 nodes need to be aware of what addresses they themselves have.
+   If a node loses the address it is currently using for communications,
+   another address must replace it.  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 the peer to
+   know about it.
+
+   Definition.  Available address - an address is said to be available
+   if all the following conditions are fulfilled:
+
+   o  The address has been assigned to an interface of the node.
+
+   o  The valid lifetime of the prefix (Section 4.6.2 of RFC 4861
+      [RFC4861]) associated with the address has not expired.
+
+   o  The address is not tentative in the sense of RFC 4862 [RFC4862].
+      In other words, the address assignment is complete so that
+      communications can be started.
+
+      Note that this explicitly allows an address to be optimistic in
+      the sense of Optimistic Duplicate Address Detection (DAD)
+      [RFC4429] even though implementations may prefer using other
+      addresses as long as there is an alternative.
+
+   o  The address is a global unicast or unique local address [RFC4193].
+      That is, it is not an IPv6 site-local or link-local address.
+
+      With link-local addresses, the nodes would be unable to determine
+      on which link the given address is usable.
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 4]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   o  The address and interface are acceptable for use according to a
+      local policy.
+
+   Available addresses are discovered and monitored through mechanisms
+   outside the scope of Shim6.  Shim6 implementations MUST be able to
+   employ information provided by IPv6 Neighbor Discovery [RFC4861],
+   Address Autoconfiguration [RFC4862], and DHCP [RFC3315] (when DHCP is
+   implemented).  This information includes the availability of a new
+   address and status changes of existing addresses (such as when an
+   address becomes invalid).
+
+3.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 is known to be possible
+   locally.  In other words, when the interface is up, a default router
+   (if needed) suitable for this address is known to be reachable, and
+   no other local information points to the address being unusable.
+
+   Locally operational addresses are discovered and monitored through
+   mechanisms outside the Shim6 protocol.  Shim6 implementations MUST be
+   able to employ information provided from Neighbor Unreachability
+   Detection [RFC4861].  Implementations MAY also employ additional,
+   link-layer-specific mechanisms.
+
+      Note 1: A part of the 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 subnet.
+      Mechanisms such as [DNA-SIM] can be used to ensure this.
+
+      Note 2: In theory, it would also be possible for nodes to learn
+      about routing failures for a particular selected source prefix, if
+      only suitable protocols for this purpose existed.  Some proposals
+      in this space have been made (see, for instance [ADD-SEL] and
+      [MULTI6]), but none have 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 peer.  A
+   failure in the routing infrastructure can prevent packets from
+   reaching their destination.  For this reason, we need the definition
+   of a second level of granularity, which is used for pairs of
+   addresses.
+
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 5]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   Definition.  Bidirectionally operational address pair - a pair of
+   locally operational addresses are said to be an operational address
+   pair when 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, there are scenarios where bidirectionally operational
+   address pairs do not exist.  For instance, ingress filtering or
+   network failures may result in one address pair being operational in
+   one direction while another one is operational from the other
+   direction.  The following definition captures this general situation.
+
+   Definition.  Unidirectionally operational address pair - a pair of
+   locally operational addresses are said to be a unidirectionally
+   operational address pair when packets sent with the first address as
+   the source and the second address as the destination reach the
+   destination.
+
+   Shim6 implementations MUST support the discovery of operational
+   address pairs through the use of explicit reachability tests and
+   Forced Bidirectional Communication (FBD), described later in this
+   specification.  Future extensions of Shim6 may specify additional
+   mechanisms.  Some ideas of such mechanisms are listed below but are
+   not fully specified in this document:
+
+   o  Positive feedback from upper-layer protocols.  For instance, TCP
+      can indicate to the IP layer that it is making progress.  This is
+      similar to how IPv6 Neighbor Unreachability Detection can, in some
+      cases, be avoided when upper layers provide information about
+      bidirectional connectivity [RFC4861].
+
+      In the case of unidirectional connectivity, the upper-layer
+      protocol responses come back using 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 problem to the
+      multihoming layer.  For instance, TCP could indicate that there's
+      either congestion or lack of connectivity in the path because it
+      is not getting ACKs.
+
+   o  ICMP error messages.  Given the ease of spoofing ICMP messages,
+      one should be careful not to trust these blindly, however.  One
+      approach would be to use ICMP error messages only as a hint to
+      perform an explicit reachability test or to move an address pair
+      to a lower place in the list of address pairs to be probed, but
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 6]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+      not to use these messages as a reason to disrupt ongoing
+      communications without other indications of problems.  The
+      situation may be different when certain verifications of the ICMP
+      messages are being performed, as explained by Gont in [GONT].
+      These verifications can ensure that (practically) only on-path
+      attackers can spoof the messages.
+
+3.4.  Primary Address Pair
+
+   The primary address pair consists of the addresses that upper-layer
+   protocols use in their interaction with the Shim6 layer.  Use of the
+   primary address pair means that the communication is compatible with
+   regular non-Shim6 communication and that no context tag needs to be
+   present.
+
+3.5.  Current Address Pair
+
+   Shim6 needs to avoid sending packets that belong to the same
+   transport connection concurrently over multiple paths.  This is
+   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.  Effective congestion
+   control over multiple paths is considered a research topic at the
+   time of publication of this document.  Shim6 does not attempt to
+   employ multiple paths simultaneously.
+
+      Note: The Stream Control Transmission Protocol (SCTP) and future
+      multipath transport protocols are likely to require interaction
+      with Shim6, at least to ensure that they do not employ Shim6
+      unexpectedly.
+
+   For these reasons, it is necessary to choose a particular pair of
+   addresses as the current address pair that will be used until
+   problems occur, at least for the same session.
+
+      It is theoretically possible to support multiple current address
+      pairs for different transport sessions or Shim6 contexts.
+      However, this is not supported in this version of the Shim6
+      protocol.
+
+   A current address pair need not be operational at all times.  If
+   there is no traffic to send, we may not know if the current address
+   pair is operational.  Nevertheless, it makes sense to assume that the
+   address pair that worked previously continues to be operational for
+   new communications as well.
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 7]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+4.  Protocol Overview
+
+   This section discusses the design of the reachability detection and
+   full reachability exploration mechanisms, and gives an overview of
+   the REAP protocol.
+
+   Exploring the full set of communication options between two nodes
+   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
+   the complement pair in the other direction, the total number of two-
+   way combinations is eight.  (Combinations = nA * nB * 2.)
+
+   An important observation in multihoming is that failures are
+   relatively infrequent, so an operational pair that worked a few
+   seconds ago is very likely to still be operational.  Thus, it makes
+   sense to have a lightweight protocol that confirms existing
+   reachability, and to only invoke heavier exploration mechanism when
+   there is a suspected failure.
+
+4.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 Sections 3.1 and 3.2
+   to track the local situation.  It is also necessary to track remote
+   address information from the peer.  For instance, if the peer's
+   address in the current address pair is no longer locally operational,
+   a mechanism to relay that information is needed.  The Update Request
+   message in the Shim6 protocol is used for this purpose [RFC5533].
+   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 address pair.
+
+   A technique called Forced Bidirectional Detection (FBD) is employed
+   for the reachability verification.  Reachability for the currently
+   used address pair in a Shim6 context is determined by making sure
+   that whenever there is payload traffic in one direction, there is
+   also traffic in the other direction.  This can be data traffic as
+   well, or it may be 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 only one direction; so whenever
+
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 8]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   there is payload traffic going out, but there are no return packets,
+   there must be a failure, and the full exploration mechanism is
+   started.
+
+   A more detailed description of the current pair-reachability
+   evaluation mechanism:
+
+   1.  To prevent the other side from concluding that there is a
+       reachability failure, it's necessary for a node implementing the
+       failure-detection mechanism to generate periodic keepalives when
+       there is no other traffic.
+
+       FBD works by generating REAP keepalives if the node is receiving
+       packets from its peer but not sending any of its own.  The
+       keepalives are sent at certain intervals so that the other side
+       knows there is a reachability problem when it doesn't receive any
+       incoming packets for the duration of a Send Timeout period.  The
+       node communicates its Send Timeout value to the peer as a
+       Keepalive Timeout Option (Section 5.3) in the I2, I2bis, R2, or
+       UPDATE messages.  The peer then maps this value to its Keepalive
+       Timeout value.
+
+       The interval after which keepalives are sent is named the
+       Keepalive Interval.  The RECOMMENDED approach for the Keepalive
+       Interval is to send keepalives at one-half to one-third of the
+       Keepalive Timeout interval, so that multiple keepalives are
+       generated and have time to reach the peer before it times out.
+
+   2.  Whenever outgoing payload packets are generated, a timer is
+       started to reflect the requirement that the peer should generate
+       return traffic from payload packets.  The timeout value is set to
+       the value of Send Timeout.
+
+       For the purposes of this specification, "payload packet" refers
+       to any packet that is part of a Shim6 context, including both
+       upper-layer protocol packets and Shim6 protocol messages, except
+       those defined in this specification.  For the latter messages,
+       Section 6 specifies what happens to the timers when a message is
+       transmitted or received.
+
+   3.  Whenever incoming payload packets are received, the timer
+       associated with the return traffic from the peer is stopped, and
+       another timer is started to reflect the requirement for this node
+       to generate return traffic.  This timeout value is set to the
+       value of Keepalive Timeout.
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                     [Page 9]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+       These two timers are mutually exclusive.  In other words, either
+       the node is expecting to see traffic from the peer based on the
+       traffic that the node sent earlier or the node is expecting to
+       respond to the peer based on the traffic that the peer sent
+       earlier (otherwise, the node is in an idle state).
+
+   4.  The reception of a REAP Keepalive message leads to stopping the
+       timer associated with the return traffic from the peer.
+
+   5.  Keepalive Interval seconds after the last payload packet has been
+       received for a context, if no other packet has been sent within
+       this context since the payload packet has been received, a REAP
+       Keepalive message is generated for the context in question and
+       transmitted to the peer.  A node may send the keepalive sooner
+       than Keepalive Interval seconds if implementation considerations
+       warrant this, but should take care to avoid sending keepalives at
+       an excessive rate.  REAP Keepalive messages SHOULD continue to be
+       sent at the Keepalive Interval until either a payload packet in
+       the Shim6 context has been received from the peer or the
+       Keepalive Timeout expires.  Keepalives are not sent at all if one
+       or more payload packets were sent within the Keepalive Interval.
+
+   6.  Send Timeout seconds after the transmission of a payload packet
+       with no return traffic on this context, a full reachability
+       exploration is started.
+
+   Section 7 provides some suggested defaults for these timeout values.
+   The actual value SHOULD be randomized in order to prevent
+   synchronization.  Experience from the deployment of the Shim6
+   protocol is needed in order to determine what values are most
+   suitable.
+
+4.2.  Full Reachability Exploration
+
+   As explained in previous sections, the currently used address pair
+   may become invalid, either through one of the addresses becoming
+   unavailable or nonoperational or through the pair itself being
+   declared nonoperational.  An exploration process attempts to find
+   another operational pair so that communications can resume.
+
+   What makes this process hard is the requirement to support
+   unidirectionally operational address pairs.  It is insufficient to
+   probe address pairs by a simple request-response protocol.  Instead,
+   the party that first detects the problem starts a process where it
+   tries each of the different address pairs in turn by sending a
+   message to its peer.  These messages carry information 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
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 10]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   a message that indicates a problem, it assists the process by
+   starting its own parallel exploration to the other direction, again
+   sending information about the recently received payload traffic or
+   signaling messages.
+
+   Specifically, when A decides that it needs to explore for an
+   alternative address pair to B, it will initiate a set of Probe
+   messages, in sequence, until it gets a 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
+   same algorithm, but starts the process from the reception of the
+   first Probe message from A.
+
+   Upon changing to a new address pair, the network path traversed most
+   likely has changed, so the upper-layer protocol (ULP), SHOULD be
+   informed.  This can be a signal for the ULP to adapt, due to the
+   change in path, so that for example, if the ULP is TCP, it could
+   initiate a slow start procedure.  However, it's likely that the
+   circumstances that led to the selection of a new path already caused
+   enough packet loss to trigger slow start.
+
+   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 8, 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.
+
+4.3.  Exploration Order
+
+   The exploration process assumes an ability to choose address pairs
+   for testing.  An overview of the choosing process used by REAP is as
+   follows:
+
+   o  As an input to start the process, the node has knowledge of its
+      own addresses and has been told via Shim6 protocol messages what
+      the addresses of the peer are.  A list of possible pairs of
+      addresses can be constructed by combining the two pieces of
+      information.
+
+   o  By employing standard IPv6 address selection rules, the list is
+      pruned by removing combinations that are inappropriate, such as
+      attempting to use a link-local address when contacting a peer that
+      uses a global unicast address.
+
+   o  Similarly, standard IPv6 address selection rules provide a basic
+      priority order for the pairs.
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 11]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   o  Local preferences may be applied for some additional tuning of the
+      order in the list.  The mechanisms for local preference settings
+      are not specified but can involve, for instance, configuration
+      that sets the preference for using one interface over another.
+
+   o  As a result, the node has a prioritized list of address pairs to
+      try.  However, the list may still be long, as there may be a
+      combinatorial explosion when there are many addresses on both
+      sides.  REAP employs these pairs sequentially, however, and uses a
+      back-off procedure to avoid a "signaling storm".  This ensures
+      that the exploration process is relatively conservative or "safe".
+      The tradeoff is that finding a working path may take time if there
+      are many addresses on both sides.
+
+   In more detail, the process is as follows.  Nodes first consult the
+   RFC 3484 default address selection rules [RFC3484] to determine what
+   combinations of addresses are allowed from a local point of view, as
+   this reduces the search space.  RFC 3484 also provides a priority
+   ordering among different address pairs, possibly making the search
+   faster.  (Additional mechanisms may be defined in the future for
+   arriving at an initial ordering of address pairs before testing
+   starts [PAIR].)  Nodes may also use local information, such as known
+   quality of service parameters or interface types, to determine what
+   addresses are preferred over others, and try pairs containing such
+   addresses first.  The Shim6 protocol also carries preference
+   information in its messages.
+
+   Out of the set of possible candidate address pairs, nodes SHOULD
+   attempt to test through all of them until an operational pair is
+   found, and retry the process as 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 7 suggests default values for the timers associated with the
+   exploration process.  The value Initial Probe Timeout (0.5 seconds)
+   specifies the interval between initial attempts to send probes; the
+   Number of Initial Probes (4) specifies how many initial probes can be
+   sent before the exponential back-off procedure needs to be employed.
+   This process increases the time between every probe if there is no
+   response.  Typically, each increase doubles the time, but this
+   specification does not mandate a particular increase.
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 12]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+      Note: The rationale for sending four packets at a fixed rate
+      before the exponential back-off is employed is to avoid having to
+      send these packets excessively fast.  Without this, having 0.5
+      seconds between the third and fourth probe means that the time
+      between the first and second probe would have to be 0.125 seconds,
+      which gives very little time for a reply to the first packet to
+      arrive.  Also, this means that the first four packets are sent
+      within 0.875 seconds rather than 2 seconds, increasing the
+      potential for congestion if a large number of Shim6 contexts need
+      to send probes at the same time after a failure.
+
+   Finally, Max Probe Timeout (60 seconds) 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, because upper-layer protocols using the Shim6 context in
+   question are no longer attempting to send packets.  Reaching the Max
+   Probe Timeout may also serve as a hint to the garbage collection
+   process that the context is no longer usable.
+
+5.  Protocol Definition
+
+5.1.  Keepalive Message
+
+   The format of 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Next Header  |  Hdr Ext Len  |0|  Type = 66  |  Reserved1  |0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Checksum           |R|                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             |
+   |                    Receiver Context Tag                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Reserved2                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                            Options                            +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Next Header, Hdr Ext Len, 0, 0, Checksum
+      These are as specified in Section 5.3 of the Shim6 protocol
+      description [RFC5533].
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 13]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   Type
+      This field identifies the Keepalive message and MUST be set to 66
+      (Keepalive).
+
+   Reserved1
+      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.
+
+   Receiver Context Tag
+      This is a 47-bit field for the context tag that the receiver has
+      allocated for the context.
+
+   Reserved2
+      This is a 32-bit field reserved for future use.  It is set to zero
+      on transmit and MUST be ignored on receipt.
+
+   Options
+      This field MAY contain one or more Shim6 options.  However, there
+      are currently no defined options that are useful in a Keepalive
+      message.  The Options field is provided only for future
+      extensibility reasons.
+
+   A valid message conforms to the format above, has a Receiver Context
+   Tag that matches the context known by the receiver, is a valid Shim6
+   control message as defined in Section 12.3 of the Shim6 protocol
+   description [RFC5533], and has a Shim6 context that is in state
+   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 given in more detail in
+   Section 6.
+
+5.2.  Probe Message
+
+   This message performs REAP exploration.  Its format is as follows:
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 14]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+    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  |   Reserved  |0|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Checksum           |R|                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             |
+   |                    Receiver Context Tag                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Precvd| Psent |Sta|                 Reserved2                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                      First probe sent                         +
+   |                                                               |
+   +                      Source address                           +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                      First probe sent                         +
+   |                                                               |
+   +                      Destination address                      +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      First Probe Nonce                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      First Probe Data                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                      Nth probe sent                           /
+   |                                                               |
+   +                      Source address                           +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                      Nth probe sent                           +
+   |                                                               |
+   +                      Destination address                      +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Nth Probe Nonce                          |
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 15]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Nth Probe Data                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                      First probe received                     +
+   |                                                               |
+   +                      Source address                           +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                      First probe received                     +
+   |                                                               |
+   +                      Destination address                      +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      First Probe Nonce                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      First Probe Data                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                      Nth probe received                       +
+   |                                                               |
+   +                      Source address                           +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +                      Nth probe received                       +
+   |                                                               |
+   +                      Destination address                      +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Nth Probe Nonce                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Nth Probe Data                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   //                         Options                             //
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 16]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   Next Header, Hdr Ext Len, 0, 0, Checksum
+      These are as specified in Section 5.3 of the Shim6 protocol
+      description [RFC5533].
+
+   Type
+      This field identifies the Probe message and MUST be set to 67
+      (Probe).
+
+   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.
+
+   Receiver Context Tag
+      This is a 47-bit field for the context tag that the receiver has
+      allocated for the context.
+
+   Psent
+      This is a 4-bit field that indicates the number of sent probes
+      included in this Probe message.  The first set of Probe fields
+      pertains to the current message and MUST be present, so the
+      minimum value for this field is 1.  Additional sent Probe fields
+      are copies of the same fields sent in (recent) earlier probes and
+      may be included or omitted as per any logic employed by the
+      implementation.
+
+   Precvd
+      This is a 4-bit field that indicates the number of received probes
+      included in this Probe message.  Received Probe fields are copies
+      of the same fields in earlier received probes that arrived since
+      the last transition to state Exploring.  When a sender is in state
+      InboundOk it MUST include copies of the fields of at least one of
+      the inbound probes.  A sender MAY include additional sets of these
+      received Probe fields in any state as per any logic employed by
+      the implementation.
+
+      The fields Probe Source, Probe Destination, Probe Nonce, and Probe
+      Data may be repeated, depending on the value of Psent and
+      Preceived.
+
+   Sta (State)
+      This 2-bit State field is used to inform the peer about the state
+      of the sender.  It has three legal values:
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 17]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+      0 (Operational) implies that the sender both (a) believes it has
+      no problem communicating and (b) believes that the recipient also
+      has no problem communicating.
+
+      1 (Exploring) implies that the sender has a problem communicating
+      with the recipient, e.g., it has not seen any traffic from the
+      recipient even when it expected some.
+
+      2 (InboundOk) implies that the sender believes it has no problem
+      communicating, i.e., it at least sees packets from the recipient
+      but that the recipient either has a problem or has not yet
+      confirmed to the sender that the problem has been resolved.
+
+   Reserved2
+      MUST be set to zero upon transmission and MUST be ignored upon
+      reception.
+
+   Probe Source
+      This 128-bit field contains the source IPv6 address used to send
+      the probe.
+
+   Probe Destination
+      This 128-bit field contains the destination IPv6 address used to
+      send the probe.
+
+   Probe Nonce
+      This is a 32-bit field that is initialized by the sender with a
+      value that allows it to determine with which sent probes a
+      received probe correlates.  It is highly RECOMMENDED that the
+      Nonce field be at least moderately hard to guess so that even on-
+      path attackers can't deduce the next nonce value that will be
+      used.  This value SHOULD be generated using a random number
+      generator that is known to have good randomness properties as
+      outlined in RFC 4086 [RFC4086].
+
+   Probe Data
+      This is a 32-bit field with no fixed meaning.  The Probe Data
+      field is copied back with no changes.  Future flags may define a
+      use for this field.
+
+   Options
+      For future extensions.
+
+5.3.  Keepalive Timeout Option Format
+
+   Either side of a Shim6 context can notify the peer of the value that
+   it would prefer the peer to use as its Keepalive Timeout value.  If
+   the node is using a non-default Send Timeout value, it MUST
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 18]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   communicate this value as a Keepalive Timeout value to the peer in
+   the below option.  This option MAY be sent in the I2, I2bis, R2, or
+   UPDATE messages.  The option SHOULD only need to be sent once in a
+   given Shim6 association.  If a node receives this option, it SHOULD
+   update its Keepalive Timeout value for the peer.
+
+    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  = 4            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   +           Reserved            |      Keepalive Timeout        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Fields:
+
+   Type
+      This field identifies the option and MUST be set to 10 (Keepalive
+      Timeout).
+
+   Length
+      This field MUST be set as specified in Section 5.1 of the Shim6
+      protocol description [RFC5533] -- that is, set to 4.
+
+   Reserved
+      A 16-bit field reserved for future use.  It is set to zero upon
+      transmit and MUST be ignored upon receipt.
+
+   Keepalive Timeout
+      The value in seconds corresponding to the suggested Keepalive
+      Timeout value for the peer.
+
+6.  Behavior
+
+   The required behavior of REAP nodes is specified below in the form of
+   a state machine.  The externally observable behavior of an
+   implementation MUST conform to this state machine, but there is no
+   requirement that the implementation actually employ a state machine.
+   Intermixed with the following description, we also provide a state
+   machine description in tabular form.  However, that form is only
+   informational.
+
+   On a given context with a given peer, the node can be in one of three
+   states: Operational, Exploring, or InboundOK.  In the Operational
+   state, the underlying address pairs are assumed to be operational.
+   In the Exploring state, this node hasn't seen any traffic from the
+   peer for more than a Send Timer period.  Finally, in the InboundOK
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 19]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   state, this node sees traffic from the peer, but the peer may not yet
+   see any traffic from this node, so the exploration process needs to
+   continue.
+
+   The node also maintains the Send Timer (Send Timeout seconds) and
+   Keepalive Timer (Keepalive Timeout seconds).  The Send Timer reflects
+   the requirement that when this node sends a 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 is
+   only used within the Operational state, and the Send Timer within the
+   Operational and InboundOK states.  No timer is running in the
+   Exploring state.  As explained in Section 4.1, the two timers are
+   mutually exclusive.  That is, either the Keepalive Timer or the Send
+   Timer is running, or neither of them is running.
+
+   Note that Appendix A gives some examples of typical protocol runs in
+   order to illustrate the behavior.
+
+6.1.  Incoming Payload Packet
+
+   Upon the reception of a payload packet in the Operational state, the
+   node starts the Keepalive Timer if it was not yet running, and stops
+   the Send Timer if it was running.
+
+   If the node is in the Exploring state, it transitions to the
+   InboundOK state, sends a Probe message, and starts the Send Timer.
+   It fills the Psent and corresponding Probe Source Address, Probe
+   Destination Address, Probe Nonce, and Probe Data fields with
+   information about recent Probe messages that have not yet been
+   reported as seen by the peer.  It also fills the Precvd and
+   corresponding Probe Source Address, Probe Destination Address, Probe
+   Nonce, and Probe Data fields with information about recent Probe
+   messages it has seen from the peer.  When sending a Probe message,
+   the State field MUST be set to a value that matches the conceptual
+   state of the sender after sending the Probe.  In this case, the node
+   therefore sets the State field to 2 (InboundOk).  The IP source and
+   destination addresses for sending the Probe message are selected as
+   discussed in Section 4.3.
+
+   In the InboundOK state, the node stops the Send Timer if it was
+   running, but does not do anything else.
+
+   The reception of Shim6 control messages other than the Keepalive and
+   Probe messages are treated the same as the reception of payload
+   packets.
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 20]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   While the Keepalive Timer is running, the node SHOULD send Keepalive
+   messages to the peer with an interval of Keepalive Interval seconds.
+   Conceptually, a separate timer is used to distinguish between the
+   interval between Keepalive messages and the overall Keepalive Timeout
+   interval.  However, this separate timer is not modelled in the
+   tabular or graphical state machines.  When sent, the Keepalive
+   message is constructed as described in Section 5.1.  It is sent using
+   the current address pair.
+
+   In the below tables, "START", "RESTART", and "STOP" refer to
+   starting, restarting, and stopping the Keepalive Timer or the Send
+   Timer, respectively.  "GOTO" refers to transitioning to another
+   state.  "SEND" refers to sending a message, and "-" refers to taking
+   no action.
+
+    Operational           Exploring               InboundOk
+    --------------------------------------------------------------------
+    STOP Send             SEND Probe InboundOk    STOP Send
+    START Keepalive       START Send
+                          GOTO InboundOk
+
+6.2.  Outgoing Payload Packet
+
+   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 InboundOK state the node simply starts the Send Timer if
+   it was not yet running.  (The sending of Shim6 control messages is
+   again treated the same.)
+
+     Operational             Exploring             InboundOk
+     ------------------------------------------------------------------
+     START Send              -                     START Send
+     STOP Keepalive
+
+6.3.  Keepalive Timeout
+
+   Upon a timeout on the Keepalive Timer, the node sends one last
+   Keepalive message.  This can only happen in the Operational state.
+
+   The Keepalive message is constructed as described in Section 5.1.  It
+   is sent using the current address pair.
+
+     Operational             Exploring             InboundOk
+     ------------------------------------------------------------------
+     SEND Keepalive          -                     -
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 21]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+6.4.  Send Timeout
+
+   Upon a timeout on the Send Timer, the node enters the Exploring state
+   and sends a Probe message.  The Probe message is constructed as
+   explained in Section 6.1, except that the State field is set to 1
+   (Exploring).
+
+     Operational             Exploring             InboundOk
+     ------------------------------------------------------------------
+     SEND Probe Exploring    -                     SEND Probe Exploring
+     GOTO Exploring                                GOTO Exploring
+
+6.5.  Retransmission
+
+   While in the Exploring state, the node keeps retransmitting its Probe
+   messages to different (or the same) addresses as defined in
+   Section 4.3.  A similar process is employed in the InboundOk state,
+   except that upon such retransmission, the Send Timer is started if it
+   was not running already.
+
+   The Probe messages are constructed as explained in Section 6.1,
+   except that the State field is set to 1 (Exploring) or 2 (InboundOk),
+   depending on which state the sender is in.
+
+     Operational            Exploring             InboundOk
+     -----------------------------------------------------------------
+     -                      SEND Probe Exploring  SEND Probe InboundOk
+                                                  START Send
+
+6.6.  Reception of the Keepalive Message
+
+   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
+   the Exploring state, it transitions to the InboundOK state, sends a
+   Probe message, and starts the Send Timer.  The Probe message is
+   constructed as explained in Section 6.1.
+
+   In the InboundOK state, the Send Timer is stopped if it was running.
+
+     Operational           Exploring               InboundOk
+     ------------------------------------------------------------------
+     STOP Send             SEND Probe InboundOk    STOP Send
+                           START Send
+                           GOTO InboundOk
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 22]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+6.7.  Reception of the Probe Message State=Exploring
+
+   Upon receiving a Probe message with State set to Exploring, the node
+   enters the InboundOK state, sends a Probe message as described in
+   Section 6.1, stops the Keepalive Timer if it was running, and
+   restarts the Send Timer.
+
+     Operational            Exploring              InboundOk
+     ------------------------------------------------------------------
+     SEND Probe InboundOk   SEND Probe InboundOk   SEND Probe InboundOk
+     STOP Keepalive         START Send             RESTART Send
+     RESTART Send           GOTO InboundOk
+     GOTO InboundOk
+
+6.8.  Reception of the Probe Message State=InboundOk
+
+   Upon the reception of a Probe message with State set to InboundOk,
+   the node sends a Probe message, restarts the Send Timer, stops the
+   Keepalive Timer if it was running, and transitions to the Operational
+   state.  A new current address pair is chosen for the connection,
+   based on the reports of received probes in the message that we just
+   received.  If no received probes have been reported, the current
+   address pair is unchanged.
+
+   The Probe message is constructed as explained in Section 6.1, except
+   that the State field is set to zero (Operational).
+
+    Operational            Exploring              InboundOk
+    --------------------------------------------------------------------
+    SEND Probe Operational SEND Probe Operational SEND Probe Operational
+    RESTART Send           RESTART Send           RESTART Send
+    STOP Keepalive         GOTO Operational       GOTO Operational
+
+6.9.  Reception of the Probe Message State=Operational
+
+   Upon the reception of a Probe message with State set to Operational,
+   the node stops the Send Timer if it was running, starts the Keepalive
+   Timer if it was not yet running, and transitions to the Operational
+   state.  The Probe message is constructed as explained in Section 6.1,
+   except that the State field is set to zero (Operational).
+
+      Note: This terminates the exploration process when both parties
+      are happy and know that their peer is happy as well.
+
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 23]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+     Operational             Exploring             InboundOk
+     ------------------------------------------------------------------
+     STOP Send               STOP Send             STOP Send
+     START Keepalive         START Keepalive       START Keepalive
+                             GOTO Operational      GOTO Operational
+
+   The reachability detection and exploration process has no effect on
+   payload communications until a new operational address pair has
+   actually been confirmed.  Prior to that, the payload packets continue
+   to be sent to the previously used addresses.
+
+6.10.  Graphical Representation of the State Machine
+
+   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.
+
+7.  Protocol Constants and Variables
+
+   The following protocol constants are defined:
+
+     Initial Probe Timeout      0.5 seconds
+     Number of Initial Probes     4 probes
+
+   And these variables have the following default values:
+
+     Send Timeout                15 seconds
+     Keepalive Timeout            X seconds, where X is the peer's
+                                    Send Timeout as communicated in
+                                    the Keepalive Timeout Option
+                                 15 seconds if the peer didn't send
+                                    a Keepalive Timeout option
+     Keepalive Interval           Y seconds, where Y is one-third to
+                                    one-half of the Keepalive Timeout
+                                    value (see Section 4.1)
+
+   Alternate values of the Send Timeout may be selected by a node and
+   communicated to the peer in the Keepalive Timeout Option.  A very
+   small value of the Send Timeout may affect the ability to exchange
+   keepalives over a path that has a long roundtrip delay.  Similarly,
+   it may cause Shim6 to react to temporary failures more often than
+   necessary.  As a result, it is RECOMMENDED that an alternate Send
+   Timeout value not be under 10 seconds.  Choosing a higher value than
+   the one recommended above is also possible, but there is a
+   relationship between Send Timeout and the ability of REAP to discover
+   and correct errors in the communication path.  In any case, in order
+   for Shim6 to be useful, it should detect and repair communication
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 24]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   problems long before upper layers give up.  For this reason, it is
+   RECOMMENDED that Send Timeout be at most 100 seconds (default TCP R2
+   timeout [RFC1122]).
+
+      Note: It is not expected that the Send Timeout or other values
+      will be estimated based on experienced roundtrip times.  Signaling
+      exchanges are performed based on exponential back-off.  The
+      keepalive processes send packets only in the relatively rare
+      condition that all traffic is unidirectional.
+
+8.  Security Considerations
+
+   Attackers may spoof various indications from lower layers and from
+   the network in an effort to confuse the peers about which addresses
+   are or are not 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 [GONT], 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 some protection against
+   third-party flooding attacks [AURA02]; when REAP is run, its Probe
+   Nonces can be used as a 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 node.  Shim6 does this by performing
+   binding of all operations to context tags.
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 25]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   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 in
+   order 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 attack is that the nodes enter the
+   exploration phase needlessly, but they should be able to confirm
+   connectivity unless, of course, the attacker is able to prevent the
+   exploration phase from completing.  Off-path attackers may not be
+   able to generate spoofed results, given that the context tags are 47-
+   bit random numbers.
+
+   To protect against spoofed Keepalive messages, a node implementing
+   both Shim6 and IPsec MAY ignore incoming REAP keepalives if it has
+   good reason to assume that the other side will be sending IPsec-
+   protected return traffic.  In other words, if a node is sending TCP
+   payload data, it can reasonably expect to receive TCP ACKs in return.
+   If no IPsec-protected ACKs come back but unprotected keepalives do,
+   this could be the result of an attacker trying to hide broken
+   connectivity.
+
+   The exploration phase is vulnerable to attackers that are on the
+   path.  Off-path attackers would find it hard to guess either the
+   context tag or the correct probe identifiers.  Given that IPsec
+   operates above the Shim6 layer, it is not possible to protect the
+   exploration phase against on-path attackers with IPsec.  This is
+   similar to the issues with protecting other Shim6 control exchanges.
+   There are mechanisms in place to prevent the redirection of
+   communications to 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.  It is required that the protocol employing REAP
+   has built-in mechanisms to prevent this.  For instance, Shim6
+   contexts are created only after a relatively large number of packets
+   have been exchanged, a cost that 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 establishment to succeed,
+   its usage would result in an amplification vulnerability.  As a
+   result, Shim6 does not support the use of REAP in the connection-
+   establishment stage.
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 26]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+9.  Operational Considerations
+
+   When there are no failures, the failure-detection mechanism (and
+   Shim6 in general) are lightweight: keepalives are not sent when a
+   Shim6 context is idle or when there is traffic in both directions.
+   So in normal TCP or TCP-like operations, there would only be one or
+   two keepalives when a session transitions from active to idle.
+
+   Only when there are failures is there significant failure-detection
+   traffic, especially in the case where a link goes down that is shared
+   by many active sessions and by multiple nodes.  When this happens,
+   one keepalive is sent and then a series of probes.  This happens per
+   active (traffic-generating) context, all of which will time out
+   within 15 seconds after the failure.  This makes the peak traffic
+   that Shim6 generates after a failure around one packet per second per
+   context.  Presumably, the sessions that run over those contexts were
+   sending at least that much traffic and most likely more, but if the
+   backup path is significantly lower bandwidth than the failed path,
+   this could lead to temporary congestion.
+
+      However, note that in the case of multihoming using BGP, if the
+      failover is fast enough that TCP doesn't go into slow start, the
+      full payload data traffic that flows over the failed path is
+      switched over to the backup path, and if this backup path is of a
+      lower capacity, there will be even more congestion.
+
+   Although the failure detection probing does not perform congestion
+   control as such, the exponential back-off makes sure that the number
+   of packets sent quickly goes down and eventually reaches one per
+   context per minute, which should be sufficiently conservative even on
+   the lowest bandwidth links.
+
+   Section 7 specifies a number of protocol parameters.  Possible tuning
+   of these parameters and others that are not mandated in this
+   specification may affect these properties.  It is expected that
+   further revisions of this specification provide additional
+   information after sufficient deployment experience has been obtained
+   from different environments.
+
+   Implementations may provide means to monitor their performance and
+   send alarms about problems.  Their standardization is, however, the
+   subject of future specifications.  In general, Shim6 is most
+   applicable for small sites and nodes, and it is expected that
+   monitoring requirements on such deployments are relatively modest.
+   In any case, where the node is associated with a management system,
+   it is RECOMMENDED that detected failures and failover events are
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 27]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   reported via asynchronous notifications to the management system.
+   Similarly, where logging mechanisms are available on the node, these
+   events should be recorded in event logs.
+
+   Shim6 uses the same header for both signaling and the encapsulation
+   of payload packets after a rehoming event.  This way, fate is shared
+   between the two types of packets, so the situation where reachability
+   probes or keepalives can be transmitted successfully but payload
+   packets cannot, is largely avoided: either all Shim6 packets make it
+   through, so Shim6 functions as intended, or none do, and no Shim6
+   state is negotiated.  Even in the situation where some packets make
+   it through and others do not, Shim6 will generally either work as
+   intended or provide a service that is no worse than in the absence of
+   Shim6, apart from the possible generation of a small amount of
+   signaling traffic.
+
+   Sometimes payload packets (and possibly payload packets encapsulated
+   in the Shim6 header) do not make it through, but signaling and
+   keepalives do.  This situation can occur when there is a path MTU
+   discovery black hole on one of the paths.  If only large packets are
+   sent at some point, then reachability exploration will be turned on
+   and REAP will likely select another path, which may or may not be
+   affected by the PMTUD black hole.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [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.
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 28]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862, September 2007.
+
+   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
+              Shim Protocol for IPv6", RFC 5533, June 2009.
+
+10.2.  Informative References
+
+   [ADD-SEL]  Bagnulo, M., "Address selection in multihomed
+              environments", Work in Progress, October 2005.
+
+   [AURA02]   Aura, T., Roe, M., and J. Arkko, "Security of Internet
+              Location Management", Proceedings of the 18th Annual
+              Computer Security Applications Conference, Las Vegas,
+              Nevada, USA, December 2002.
+
+   [BFD]      Katz, D. and D. Ward, "Bidirectional Forwarding
+              Detection", Work in Progress, February 2009.
+
+   [DNA-SIM]  Krishnan, S. and G. Daley, "Simple procedures for
+              Detecting Network Attachment in IPv6", Work in Progress,
+              February 2009.
+
+   [GONT]     Gont, F., "ICMP attacks against TCP", Work in Progress,
+              October 2008.
+
+   [MULTI6]   Huitema, C., "Address selection in multihomed
+              environments", Work in Progress, October 2004.
+
+   [PAIR]     Bagnulo, M., "Default Locator-pair selection algorithm for
+              the Shim6 protocol", Work in Progress, October 2008.
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+              Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
+              RFC 4960, September 2007.
+
+   [RFC5206]  Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
+              Host Mobility and Multihoming with the Host Identity
+              Protocol", RFC 5206, April 2008.
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 29]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+Appendix A.  Example Protocol Runs
+
+   This appendix has examples of REAP protocol runs in typical
+   scenarios.  We start with the simplest scenario of two nodes, A and
+   B, that have a Shim6 connection with each other but are not currently
+   sending any payload data.  As neither side sends anything, they also
+   do not expect anything back, so there are 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 reception of payload data from the
+   peer is taken as an indication of reachability, so again there are no
+   extra packets:
+
+          EXAMPLE 2: Bidirectional Communications
+
+    Peer A                                        Peer B
+      |                                             |
+      |              payload packet                 |
+      |-------------------------------------------->|
+      |                                             |
+      |              payload packet                 |
+      |<--------------------------------------------|
+      |                                             |
+      |              payload packet                 |
+      |-------------------------------------------->|
+      |                                             |
+      |                                             |
+
+   The third example is the first one that involves an actual REAP
+   message.  Here, the nodes 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:
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 30]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+         EXAMPLE 3: Unidirectional Communications
+
+    Peer A                                        Peer B
+      |                                             |
+      |              payload packet                 |
+      |-------------------------------------------->|
+      |                                             |
+      |              payload packet                 |
+      |-------------------------------------------->|
+      |                                             |
+      |              payload packet                 |
+      |-------------------------------------------->|
+      |                                             |
+      |              Keepalive Nonce=p              |
+      |<--------------------------------------------|
+      |                                             |
+      |              payload packet                 |
+      |-------------------------------------------->|
+      |                                             |
+      |                                             |
+
+   The next example involves a failure scenario.  Here, A has address A,
+   and B has addresses B1 and B2.  The currently used address pairs are
+   (A, B1) and (B1, A).  All connections via B1 become broken, which
+   leads to an exploration process:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 31]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+              EXAMPLE 4: Failure Scenario
+
+    Peer A                                        Peer B
+      |                                             |
+   State:                                           | State:
+   Operational                                      | Operational
+      |            (A,B1) payload packet            |
+      |-------------------------------------------->|
+      |                                             |
+      |            (B1,A) payload packet            |
+      |<--------------------------------------------| At time T1
+      |                                             | path A<->B1
+      |            (A,B1) payload packet            | becomes
+      |----------------------------------------/    | broken.
+      |                                             |
+      |           ( B1,A) payload packet            |
+      |   /-----------------------------------------|
+      |                                             |
+      |            (A,B1) payload packet            |
+      |----------------------------------------/    |
+      |                                             |
+      |            (B1,A) payload packet            |
+      |   /-----------------------------------------|
+      |                                             |
+      |            (A,B1) payload packet            |
+      |----------------------------------------/    |
+      |                                             |
+      |                                             | Send Timeout
+      |                                             | seconds after
+      |                                             | T1, B happens to
+      |                                             | see the problem
+      |             (B1,A) Probe Nonce=p,           | first and sends a
+      |                          state=exploring    | complaint that
+      |   /-----------------------------------------| it is not
+      |                                             | receiving
+      |                                             | anything.
+      |                                             | State:
+      |                                             | Exploring
+      |                                             |
+      |             (B2,A) Probe Nonce=q,           |
+      |                          state=exploring    | But it's lost,
+      |<--------------------------------------------| retransmission
+      |                                             | uses another pair
+   A realizes                                       |
+   that it needs                                    |
+   to start the                                     |
+   exploration.                                     |
+   It picks B2 as the                               |
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 32]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   most likely candidate,                           |
+   as it appeared in the                            |
+   Probe.                                           |
+   State: InboundOk                                 |
+      |                                             |
+      |       (A, B2) Probe Nonce=r,                |
+      |                     state=inboundok,        |
+      |                     received probe q        | This one gets
+      |-------------------------------------------->| through.
+      |                                             | State:
+      |                                             | Operational
+      |       (B2,A) Probe Nonce=s,                 |
+      |                    state=operational,       | B now knows
+      |                    received probe r         | that A has no
+      |<--------------------------------------------| problem receiving
+      |                                             | its packets.
+   State: Operational                               |
+      |                                             |
+      |            (A,B2) payload packet            |
+      |-------------------------------------------->| Payload packets
+      |                                             | flow again.
+      |            (B2,A) payload packet            |
+      |<--------------------------------------------|
+
+   The next example shows when the failure for the current locator pair
+   is in the other direction only.  A has addresses A1 and A2, and B has
+   addresses B1 and B2.  The current communication is between A1 and B1,
+   but A's packets no longer reach B using this pair.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 33]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+           EXAMPLE 5: One-Way Failure
+
+ Peer A                                        Peer B
+   |                                             |
+State:                                           | State:
+Operational                                      | Operational
+   |                                             |
+   |           (A1,B1) payload packet            |
+   |-------------------------------------------->|
+   |                                             |
+   |           (B1,A1) payload packet            |
+   |<--------------------------------------------|
+   |                                             |
+   |           (A1,B1) payload packet            | At time T1
+   |----------------------------------------/    | path A1->B1
+   |                                             | becomes
+   |                                             | broken.
+   |           (B1,A1) payload packet            |
+   |<--------------------------------------------|
+   |                                             |
+   |           (A1,B1) payload packet            |
+   |----------------------------------------/    |
+   |                                             |
+   |           (B1,A1) payload packet            |
+   |<--------------------------------------------|
+   |                                             |
+   |           (A1,B1) payload packet            |
+   |----------------------------------------/    |
+   |                                             |
+   |                                             | Send Timeout
+   |                                             | seconds after
+   |                                             | T1, B notices
+   |                                             | the problem and
+   |          (B1,A1) Probe Nonce=p,             | sends a
+   |                        state=exploring      | complaint that
+   |<--------------------------------------------| it is not
+   |                                             | receiving
+   |                                             | anything.
+A responds.                                      | State: Exploring
+State: InboundOk                                 |
+   |                                             |
+   |      (A1, B1) Probe Nonce=q,                |
+   |                     state=inboundok,        |
+   |                     received probe p        |
+   |----------------------------------------/    | A's response
+   |                                             | is lost.
+   |         (B2,A2) Probe Nonce=r,              |
+   |                       state=exploring       | Next, try a different
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 34]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+   |<--------------------------------------------| locator pair.
+   |                                             |
+   |     (A2, B2) Probe Nonce=s,                 |
+   |                    state=inboundok,         |
+   |                    received probes p, r     | This one gets
+   |-------------------------------------------->| through.
+   |                                             | State: Operational
+   |                                             |
+   |                                             | B now knows
+   |                                             | that A has no
+   |      (B2,A2) Probe Nonce=t,                 | problem receiving
+   |                    state=operational,       | its packets and
+   |                    received probe s         | that A's probe
+   |<--------------------------------------------| gets to B.  It
+   |                                             | sends a
+State: Operational                               | confirmation to A.
+   |                                             |
+   |           (A2,B2) payload packet            |
+   |-------------------------------------------->| Payload packets
+   |                                             | flow again.
+   |           (B1,A1) payload packet            |
+   |<--------------------------------------------|
+
+Appendix B.  Contributors
+
+   This document attempts to summarize the thoughts and unpublished
+   contributions of many people, including MULTI6 WG design team members
+   Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis Lindqvist,
+   Margaret Wasserman, and Jukka Ylitalo; MOBIKE WG contributors Pasi
+   Eronen, Tero Kivinen, Francis Dupont, Spencer Dawkins, and James
+   Kempf; and HIP WG contributors such as Pekka Nikander.  This document
+   is also in debt to work done in the context of SCTP [RFC4960] and the
+   Host Identity Protocol (HIP) multihoming and mobility extension
+   [RFC5206].
+
+Appendix C.  Acknowledgements
+
+   The authors would also like to thank Christian Huitema, Pekka Savola,
+   John Loughney, Sam Xia, Hannes Tschofenig, Sebastien Barre, Thomas
+   Henderson, Matthijs Mekking, Deguang Le, Eric Gray, Dan Romascanu,
+   Stephen Kent, Alberto Garcia, Bernard Aboba, Lars Eggert, Dave Ward,
+   and Tim Polk for interesting discussions in this problem space, and
+   for review of this specification.
+
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 35]
+
+RFC 5534         Failure Detection/Exploration Protocol        June 2009
+
+
+Authors' Addresses
+
+   Jari Arkko
+   Ericsson
+   Jorvas  02420
+   Finland
+
+   EMail: jari.arkko@ericsson.com
+
+
+   Iljitsch van Beijnum
+   IMDEA Networks
+   Avda. del Mar Mediterraneo, 22
+   Leganes, Madrid  28918
+   Spain
+
+   EMail: iljitsch@muada.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arkko & Van Beijnum         Standards Track                    [Page 36]
+