GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5534

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5534.txt · Last modified: 2009/06/17 23:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki