wdiff rfc5534.original rfc5534.txt

Network Working Group J. Arkko
Internet-Draft
Request for Comments: 5534 Ericsson
Intended status:
Category: Standards Track I. van Van Beijnum
Expires: December 26, 2008
IMDEA Networks
June 24, 2008
May 2009

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

Status of this This Memo

By submitting

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 Internet-Draft, each author represents that any
applicable patent or other IPR claims protocol. Distribution of which he or she this memo is aware
have been or will be disclosed, unlimited.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of which he
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 she becomes
aware will be disclosed, IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in accordance with Section 6 some of BCP 79.

Internet-Drafts are working documents this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months not be modified
outside the IETF Standards Process, and derivative works of it may
not be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate created outside the IETF Standards Process, except to use Internet-Drafts format
it for publication as reference
material an RFC or to cite them translate it into languages other
than as "work in progress."

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

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

This Internet-Draft will expire on December 26, 2008. English.

Abstract

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

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
2. Requirements language Language . . . . . . . . . . . . . . . . . . . . 6 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4
3.1. Available Addresses . . . . . . . . . . . . . . . . . . 7 . 4
3.2. Locally Operational Addresses . . . . . . . . . . . . . 8 . 5
3.3. Operational Address Pairs . . . . . . . . . . . . . . . 8 . 5
3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 10 . 7
3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 10 . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 7
4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11 . 8
4.2. Full Reachability Exploration . . . . . . . . . . . . . 13 . 10
4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 14 . 11
5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 17 13
5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 17 . 13
5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 18 . 14
5.3. Keepalive Timeout Option Format . . . . . . . . . . . . 22 . 18
6. Behaviour Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 24 . 19
6.1. Incoming payload packet Payload Packet . . . . . . . . . . . . . . . . 24 . 20
6.2. Outgoing payload packet Payload Packet . . . . . . . . . . . . . . . . . 25 21
6.3. Keepalive timeout Timeout . . . . . . . . . . . . . . . . . . . 25 . 21
6.4. Send timeout Timeout . . . . . . . . . . . . . . . . . . . . . . 26 . 21
6.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 26 . 21
6.6. Reception of the Keepalive message Message . . . . . . . . . . . 26 . 22
6.7. Reception of the Probe message Message State=Exploring . . . . . 27 . 22
6.8. Reception of the Probe message Message State=InboundOk . . . . . 27 . 22
6.9. Reception of the Probe message Message State=Operational . . . . 27 . 23
6.10. Graphical Representation of the State Machine . . . . . 28 . 23
7. Protocol Constants and Variables . . . . . . . . . . . . . . . . . . . . . . 29 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 24
9. Operational Considerations . . . . . . . . . . . . . . . . . . 32 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 35
11.2. . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 35 . 28
Appendix A. Example Protocol Runs . . . . . . . . . . . . . . . . 38 29
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 43 34
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 46 34

1. Introduction

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

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

Failure detection is made as light weight lightweight as possible. Data traffic
in both direction 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 data traffic is flowing
in both directions, there is no need to send failure detection
packets, either. Only when there is traffic in one direction, direction does
the failure detection mechanism generates 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.

The

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 the message formats behavior, and behaviour in detail.
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 shim6 protocol ensure that the different
locators used by a node actually belong together. That is, REAP is
not responsible for ensuring that it said node ends up with a legitimate
locator.

REAP has been designed to be used with SHIM6, shim6 and is therefore
tailored to an environment where it runs on hosts, nodes, uses widely
varying types of paths 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.
Future versions of this specification may consider extensions with
such capabilities, for instance instance, through inheriting some mechanisms
from the Bidirectional Forwarding Detection (BFD) protocol
[I-D.ietf-bfd-base]. [BFD].

2. Requirements language 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

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 this address. 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 (RFC (Section 4.6.2 of RFC 4861 [RFC4861] Section
4.6.2)
[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 DAD 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.

o The address and interface is are acceptable for use according to a
local policy.

Available addresses are discovered and monitored through mechanisms
outside the scope of SHIM6. SHIM6 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: addresses.

Definition. Locally Operational Address operational address - an available address is
said to be locally operational when its use is known to be possible
locally:
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 shim6 protocol. SHIM6 Shim6 implementations MUST be
able to employ information provided from Neighbor Unreachability
Detection [RFC4861]. Implementations MAY also employ additional,
link layer specific
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 link-layer
connectivity, we are still connected to the same IP subnet.
Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6
[I-D.ietf-dna-protocol] [DNA-SIM] can be used to ensure this.

Note 2: In theory, it would also be possible for hosts 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, made (see, for instance
[I-D.bagnulo-shim6-addr-selection] [ADD-SEL] and
[I-D.huitema-multi6-addr-selection],
[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 reason, we need the definition
of a second level of granularity, which is used for pairs of addresses:
addresses.

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
Source field and the other in the destination 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: situation.

Definition. Unidirectionally operational address pair - a pair of
locally operational addresses are said to be an a unidirectionally
operational address pair when packets sent with the first address as
the source and the second address as the destination reaches reach the
destination.

SHIM6

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 shim6 may specify additional
mechanisms. Some ideas of such mechanisms are listed below, below but are
not fully specified in this document:

o Positive feedback from upper layer 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 can, in some
cases
cases, be avoided when upper layers provide information about
bidirectional connectivity [RFC4861].

In the case of unidirectional connectivity, the upper layer 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 upper-layer protocols. It is conceivable
that upper layer 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 to 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
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 [I-D.ietf-tcpm-icmp-attacks]. [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 upper-layer
protocols use in their interaction with the SHIM6 shim6 layer. Use of the
primary address pair means that the communication is compatible with
regular non-SHIM6 non-shim6 communication and that no context ID tag needs to be
present.

3.5. Current Address Pair

SHIM6

Shim6 needs to avoid sending packets which 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 specification is written. SHIM6 document. Shim6 does not attempt to
employ multiple paths simultaneously.

Note: SCTP The Stream Control Transmission Protocol (SCTP) and future
multipath transport protocols are likely to require interaction
with SHIM6, shim6, at least to ensure that they do not employ SHIM6 shim6
unexpectedly.

For these reasons reasons, it is necessary to choose a particular pair of
addresses as the current address pair which is 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 shim6 contexts.
However, this is not supported in this version of the SHIM6 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 primary 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.

4. Protocol Overview

This section discusses the design of the reachability detection and
full reachability exploration mechanisms, and gives on an overview of
the REAP protocol.

Exploring the full set of communication options between two hosts 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 that an operational pair that worked a few
seconds ago is very likely to be still be operational. So Thus, it makes
sense to have a light-weight lightweight protocol that confirms existing
reachability, and to only invoke heavier exploration mechanism when a
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 Section Sections 3.1 and
Section 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 currently used
address in the current address pair is no longer in use, locally operational,
a mechanism to relay that information is needed. The Update Request
message in the
SHIM6 shim6 protocol is used for this purpose [I-D.ietf-shim6-proto]. [RFC5533].
Finally, when the local and remote information indicates that
communication should be possible and there are upper layer 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, originally
defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect]) (FBD) is employed
for the reachability verification. Reachability for the currently
used address pair in a SHIM6 shim6 context is determined by making sure
that whenever there is data traffic in one direction, there is also
traffic in the other direction. This can be data traffic as well, but also transport layer 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, direction; so whenever there is
data traffic going out, but there are no return packets, there must
be a failure, so and the full exploration mechanism is started.

A more detailed description of the current pair reachability pair-reachability
evaluation mechanism:

1. To avoid prevent the other side from concluding that there is a
reachability failure, it's necessary for a host node implementing the failure
detection
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 its the duration of a Send Timeout period. The host
node communicates its Send Timeout value to the peer as an a
Keepalive Timeout Option (section (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 sending to send keepalives at one-
half one-half to one-third of the
Keepalive Timeout interval, so that multiple keepalives are
generated and have time to reach the
correspondent peer before it times out.

2. Whenever outgoing data payload packets are generated, a timer is
started to reflect the requirement that the peer should generate
return traffic from data payload packets. The timeout value is set to
the value of Send Timeout.

For the purposes of this specification, "data "payload packet" refers
to any packet that is part of a SHIM6 shim6 context, including both upper
layer
upper-layer protocol packets and SHIM6 shim6 protocol messages messages, except
those defined in this specification. For those messages, section
6 specifies what happens to the timers when a message is
transmitted or received.

3. Whenever incoming data 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.

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 (or (otherwise, the node is in an idle state).

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

5. Keepalive Interval seconds after the last data payload packet has been
received for a context, and if no other packet has been sent within
this context since the data payload packet has been received, a REAP keepalive packet
Keepalive Message is generated for the context in question and
transmitted to the correspondent. peer. A host 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
packets Keepalive Messages SHOULD continue to be
sent at the Keepalive Interval until either a data payload packet in
the SHIM6 shim6 context has been received from the peer or the
Keepalive Timeout expires. Keepalives are not sent at all if data was one
or more payload packets were sent within the keep-alive interval.
A recommended value range for Keepalive Interval is specified in
Section 7. The actual value SHOULD be randomized in order to
prevent synchronization. Interval.

6. Send Timeout seconds after the transmission of a data 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 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 invalid, either through one of the addresses being becoming
unavailable or nonoperational, 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 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
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,
Messages, in sequence, until it gets an a Probe message Message from B
indicating that (a) B has received one of A's messages and,
obviously, (b) that B's Probe message Message gets back to A. B uses the
same algorithm, but starts the process from the reception of the
first Probe message Message from A.

Upon changing to a new address pair, the network path traversed most
likely has changed, so that the ULP upper-layer protocol (ULP), SHOULD be
informed. This can be a signal for the ULP to adapt adapt, due to the
change in path path, so that, that for example, TCP if the ULP is TCP, it could
initiate a slow start procedure, although 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
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 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 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.

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, 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 is to avoid a "signaling storm". This ensures
that the exploration process is relatively conservative or "safe".
The tradeoff is that fnding 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 possibly
faster. (Additional mechanisms may be defined in the future for
arriving at an initial ordering of address pairs before testing
starts [I-D.ietf-shim6-locator-pair-selection].) [PAIR].) Nodes may also use local information, such as known
quality of service parameters or interface types types, to determine what
addresses are preferred over others, and try pairs containing such
addresses first. The SHIM6 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 retrying retry the process as is necessary. However, all nodes MUST
perform this process sequentially and with exponential back-off.
This sequential process is necessary in order to avoid a "signaling
storm" when an outage occurs (particularly for a complete site).
However, it also limits the number of addresses that can can, in practice
practice, be used for multihoming, considering that transport transport- and application
layer
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 backoff 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 time, but this
specification does not mandate a particular increase.

Note: The rationale for sending four packets at a fixed rate
before the exponential backoff 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 shim 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 shim6 context is garbage
collected, because upper layer upper-layer protocols using the SHIM6 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 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 context tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header, Hdr Ext Len, 0, 0, Checksum
These are as specified in Section 5.3 of the SHIM6 shim6 protocol
description [I-D.ietf-shim6-proto]. [RFC5533].

Type
This field identifies the Keepalive message 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, 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, transmit and MUST be ignored on receipt.

Receiver Context Tag context tag
This is a 47-bit field for the Context Tag 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, transmit and MUST be ignored on receipt.

Options
This field MAY contain one or more SHIM6 options.The inclusion of the
latter options is not necessary, however, as options. However, there
are currently no defined options that are useful in a Keepalive message. These
options are
Message. The Options field is provided only for future
extensibility reasons.

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

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

5.2. Probe Message

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+
// Options +
| | //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header, Hdr Ext Len, 0, 0, Checksum
These are as specified in Section 5.3 of the SHIM6 shim6 protocol
description [I-D.ietf-shim6-proto]. [RFC5533].

Type
This field identifies the Probe message 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, 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, transmit and MUST be ignored on receipt.

Receiver Context Tag context tag
This is a 47-bit field for the Context Tag 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. Probe Message. The first set of probe Probe fields
pertains to the current message and MUST be present, so the
minimum value for this field is 1. Additional sent probe 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. Probe Message. Received probe 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 Probe fields in any state as per any logic employed by
the implementation.

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

Sta (State)
This 2-bit State field is used to inform the peer about the state
of the sender. It has three legal values:

0 (Operational) implies that the sender both (a) believes it has
no problem communicating and (b) believes that the recipient also
has no problem communicating.

1 (Exploring) implies that the sender has a problem communicating
with the recipient, e.g., it has not seen any traffic from the
recipient even when it expected some.

2 (InboundOk) implies that the sender believes it has no problem
communicating, i.e., it at least sees packets from the recipient, recipient
but that the recipient either has a problem or has not yet
confirmed to the sender that the problem has been solved. resolved.

Reserved2
MUST be set to 0 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 with. correlates. It is highly RECOMMENDED that the nonce
Nonce field is be at least moderately hard to guess so that even on-path 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 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 shim6 context can notify the peer of the value that
it would prefer the peer to use as its Keepalive Timeout value. If
the host node is using a non-default Send Timeout value, it SHOULD MUST
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 host node receives this option option, it SHOULD
update its Keepalive Timeout value for the correspondent. 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.14 5.1 of the SHIM6 shim6
protocol description [I-D.ietf-shim6-proto]. That [RFC5533] -- that is, it is set to 4.

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

Keepalive Timeout

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

6. Behaviour Behavior

The required behaviour behavior of REAP nodes is specified below in the form of
a state machine. The externally observable behaviour behavior of an
implementation MUST conform to this state machine, but there is no
requirement that the implementation actually employs employ a state machine.
Intermixed with the following description description, we also provide a state
machine description in a tabular form. That However, that form is only
informational, however.
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
state, the underlying address pairs are assumed to be operational.
In the Exploring state state, this node has observed a problem and has
currently not hasn't seen any traffic from the peer.
peer for more than a Send Timer period. Finally, in the InboundOK state
state, this node sees traffic from the peer, but the peer may not yet
see any traffic from this node node, so that the exploration process needs to
continue.

The node maintains also maintains the Send timer Timer (Send Timeout seconds) and
Keepalive timer Timer (Keepalive Timeout seconds). The Send timer Timer reflects
the requirement that when this node sends a payload packet packet, there
should be some return traffic (either payload packets or Keepalive
messages)
Messages) within Send Timeout seconds. The Keepalive timer Timer reflects
the requirement that when this node receives a payload packet packet, there
should a similar response towards the peer. The Keepalive timer Timer is
only used within the Operational state, and the Send timer in 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 is running Timer or the Send timer
Timer is running (or no timer running, or neither of them is running). running.

Note that Appendix A gives some examples of typical protocol runs in
order to illustrate the behaviour. behavior.

6.1. Incoming payload packet Payload Packet

Upon the reception of a payload packet in the Operational state, the
node starts the Keepalive timer Timer if it is was not yet running, and stops
the Send timer Timer if it was running.

If the node is in the Exploring state state, it transitions to the
InboundOK state, sends a Probe message, Message, and starts the Send timer. Timer.
It fills the Psent and corresponding Probe source address, Source Address, Probe destination
address,
Destination Address, Probe nonce, Nonce, and Probe data Data fields with
information about recent Probe messages Messages that have not yet been
reported as seen by the peer. It also fills the Precvd and
corresponding Probe source
address, Source Address, Probe destination address, Destination Address, Probe nonce,
Nonce, and Probe data Data fields with information about recent Probe messages
Messages it has seen from the peer. When sending a Probe message, 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 case, the node
therefore sets the Sta State field to 2 (InboundOk). The IP source and and
destination addresses for sending the Probe message Message are selected as
discussed in Section 4.3.

In the InboundOK state state, the node stops the Send timer Timer if it was
running, but does not do anything else.

The reception of SHIM6 shim6 control messages other than the Keepalive and
Probe messages Messages are treated similarly with the same as the reception of payload
packets.

While the Keepalive timer Timer is running, the node SHOULD send Keepalive
messages
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 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
Message is constructed as described in Section 5.1. It is sent using
the current address pair.

"Start" and "Stop" refer to starting and stopping the Keepalive Timer
or the Send Timer.

6.2. Outgoing payload packet Payload Packet

Upon sending a payload packet in the Operational state, the node
stops the Keepalive timer Timer if it was running and starts the Send timer 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 Timer if
it was not yet running. (The sending of SHIM6 shim6 control messages is
again treated similarly here.) the same.)

6.3. Keepalive timeout Timeout

Upon a timeout on the Keepalive timer, Timer, the node sends one last
Keepalive message. Message. This can only happen in the Operational state.

The Keepalive message Message is constructed as described in Section 5.1. It
is sent using the current address pair.

Operational Exploring InboundOk
-----------------------------------------------------------
------------------------------------------------------------------
SEND Keepalive - -

6.4. Send timeout Timeout

Upon a timeout on the Send timer, Timer, the node enters the Exploring state
and sends a Probe message. Message. The Probe message Message is constructed as
explained in Section 6.1, except that the Sta State field is set to 1
(Exploring).

6.5. Retransmission

While in the Exploring state state, the node keeps retransmitting its Probe
messages
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 retransmission, the Send timer Timer is started if it
was not running already.

The Probe messages Messages are constructed as explained in Section 6.1,
except that the Sta State field is set to 1 (Exploring) or 2 (InboundOk),
depending on which state the sender is in.

6.6. Reception of the Keepalive message Message

Upon the reception of a Keepalive message Message in the Operational state,
the node stops the Send timer, Timer if it was running. If the node is in
the Exploring state state, it transitions to the InboundOK state, sends a
Probe message, Message, and starts the Send timer. Timer. The Probe message Message is
constructed as explained in Section 6.1.

In the InboundOK state state, the Send timer Timer is stopped, stopped if it was running.

6.7. Reception of the Probe message Message State=Exploring

Upon receiving a Probe with State set to Exploring, the node enters
the InboundOK state, sends a Probe as described in Section 6.1, stops
the Keepalive timer Timer if it was running, and restarts the Send timer. Timer.

Operational Exploring InboundOk
-----------------------------------------------------------
------------------------------------------------------------------
SEND Probe InboundOk; InboundOk SEND Probe InboundOk; InboundOk SEND Probe InboundOk
STOP Keepalive; Keepalive START Send; InboundOk; Send Restart Send
RESTART Send; Send GOTO InboundOk RESTART Send
GOTO InboundOk

6.8. Reception of the Probe message Message State=InboundOk

Upon the reception of a Probe message Message with State set to InboundOk,
the node sends a Probe message, Message, restarts the Send timer, Timer, stops the
Keepalive timer Timer if it was running, and transitions to the Operational
state. New 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 Message is constructed as explained in Section 6.1, except
that the Sta State field is set to 0 zero (Operational).

Operational Exploring InboundOk
-------------------------------------------------------------
--------------------------------------------------------------------
SEND Probe Operational; Operational SEND Probe Operational; Operational SEND Probe Operational
RESTART Send RESTART Send; Send RESTART Send; Operational; Send
STOP Keepalive GOTO Operational RESTART Send; GOTO Operational

6.9. Reception of the Probe message Message State=Operational

Upon the reception of a Probe message Message with State set to Operational,
the node stops the Send timer Timer if it was running, starts the Keepalive
timer
Timer if it was not yet running, and transitions to the Operational
state. The Probe message Message is constructed as explained in Section 6.1,
except that the Sta State field is set to 0 zero (Operational).

Note: This terminates the exploration process when both parties
are happy and know that their peer is happy as well.

Operational Exploring InboundOk
-----------------------------------------------------------
------------------------------------------------------------------
STOP Send STOP Send; Send STOP Send; 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 pairs have pair has
actually been confirmed. Prior to that 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 Interval Timeout X seconds, where X is
one third 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
one-half of the Keepalive Timeout
value (see Section 4.1)
Initial Probe Timeout 0.5 seconds
Number of Initial Probes 4 probes
Max Probe Timeout 60 seconds

Alternate values of the Send Timeout may be selected by a host 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 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 shim6 to be useful, it should detect and repair communication
problems far 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 that it

Note: It is not expected that the Send Timeout or other values
need to
will be estimated based on experienced roundtrip times. Signaling
exchanges are performed based on exponential backoff. back-off. The
keepalive processes send packets only in the relatively rare
condition that all traffic is unidirectional. Finally, because
Send Timeout is far greater than usual roundtrip times, it merely
divides the traffic into periods that SHIM6 shim6 looks at to decide
whether to act.

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, 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- 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 Denial-of-service
vulnerabilities remain, however, as do vulnerabilities against on on-
path attackers.

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

Other parts of the SHIM6 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
third-party flooding attacks [AURA02]; when REAP is run run, its Probe 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 host. SHIM6 node. Shim6 does this by performing
binding of all operations to context tags.

The keepalive mechanism in this specification is vulnerable to
spoofing. On path-attackers On-path attackers that can see a SHIM6 shim6 context tag can
send spoofed Keepalive messages Messages once per Send Timeout interval, interval in
order to prevent two SHIM6 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 packets, a host 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. I.e., if a host is sending TCP 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 from an attacker trying to hide broken connectivity.
bit random numbers.

To protect against spoofed keepalive packets, Keepalive Messages, a host 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. I.e., In other words, if a host node is sending TCP
data, it can reasonably expect to receive TCP ACKs in return. If no IPsec-
protected
IPsec-protected ACKs come back but unprotected keepalives do, this
could be the result from 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 shim shim6 layer, it is not possible to protect the
exploration phase against on-path attackers. attackers with IPsec. This is
similar to the
ability to protect issues with protecting other Shim6 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 result, it may be used as a tool for packet amplification
in flooding attacks. In order to prevent this it It is required that the protocol employing REAP
has built-in mechanisms to prevent this. For instance, in SHIM6 shim6
contexts are created only after a relatively large number of packets has
have been exchanged, a cost which that reduces the attractiveness of using SHIM6
shim6 and REAP for amplification attacks. However, such protections
are typically not present at connection
establishment 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 shim6 does not support the use of REAP in connection the connection-
establishment stage.

9. Operational Considerations

When there are no failures, the failure detection failure-detection mechanism (and
SHIM6
shim6 in general) are light-weight: lightweight: keepalives are not sent when a
SHIM6
shim6 context is idle or when there is traffic in both directions.
So in normal TCP or TCP-like operation, operations, there would only be one or
two keepalives when a session transitions from active to idle.

Only when there are failures, there failures is there significant failure detection failure-detection
traffic, and then especially in the case where a link goes down that is shared
by many active sessions and by multiple hosts. nodes. When this happens,
one keepalive is sent and then a series of probes. This happens per
active (traffic generating) (traffic-generating) context, all of which will all
timeout time out
within 10 15 seconds after the failure. This makes the peak traffic
that SHIM6 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 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 in that case. congestion.

Although the failure detection probing does not perform congestion
control as such, the exponential backoff 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 shim6 is most
applicable for small sites and hosts, nodes, and it is expected that
monitoring requirements on such deployments are relatively modest.
In any case, where the host node is associated with a management system,
it is RECOMMENDED that detected failures and failover events are
reported via asynchronous notifications to the management system.
Similarly, where logging mechanisms are available on the host, node, these
events should be recorded in event logs.

SHIM6

Shim6 uses the same header for both signaling and the encapsulation
of data 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, successfully but data payload
packets can not, cannot, is largely avoided: either all SHIM6 shim6 packets make it
through, so SHIM6 shim6 functions as intended, or none do, and no SHIM6 shim6
state is negotiated. Even in the situation where some packets make
it through and other others do not, SHIM6 shim6 will generally either work as
intended or provide a service that is no worse than in the absense absence of
SHIM6,
shim6, apart from the possible generation a of a small amount of
signaling traffic.

Sometimes data payload packets and (and possibly data payload packets encapsulated
in the
SHIM6 header 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. IANA Considerations

No IANA actions are required. The number assignments necessary for
the messages defined in this document appear together with all the
other IANA assignments in the main SHIM6 specification
[I-D.ietf-shim6-proto].

11. References

11.1.

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.

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

11.2.

[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, May 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", In Proceedings of the 18th Annual
Computer Security Applications Conference, Las Vegas,
Nevada, USA., USA, December 2002.

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

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

[I-D.ietf-bfd-base]

[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-08 (work Work in progress),
March 2008.

[I-D.ietf-dna-cpl]
Nordmark, E. Progress, February 2009.

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

[I-D.ietf-dna-protocol]
Narayanan, S., Kempf, J., Nordmark, E., Pentland, B.,
Choi, J., G. Daley, G., and N. Montavont, "Detecting "Simple procedures for
Detecting Network Attachment in IPv6 Networks (DNAv6)",
draft-ietf-dna-protocol-07 (work IPv6", Work in progress), Progress,
February 2009.

[GONT] Gont, F., "ICMP attacks against TCP", Work in Progress,
October 2008.

[I-D.ietf-hip-mm]
Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-05 (work

[MULTI6] Huitema, C., "Address selection in
progress), March 2007.

[I-D.ietf-shim6-locator-pair-selection] multihomed
environments", Work in Progress, October 2004.

[PAIR] Bagnulo, M., "Default Locator-pair selection algorithm for
the SHIM6 protocol",
draft-ietf-shim6-locator-pair-selection-03 (work in
progress), February 2008.

[I-D.ietf-shim6-proto]
Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work
in progress), February 2008.

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

[I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-03 (work in progress),
March 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.

Appendix A. Example Protocol Runs

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

EXAMPLE 1: No communications Communications

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

EXAMPLE 2: Bidirectional communications 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 Here, the hosts 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:

EXAMPLE 3: Unidirectional communications Communications

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

The next example involves a failure scenario. Here Here, A has addresses A 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:

EXAMPLE 4: Failure scenario 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 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 id=p, nonce=p, | first and sends a
| state=exploring | complaint that
| /-----------------------------------------| it is not rec-
| | eiving anything anything.
| | State:
| | Exploring
| |
| (B2,A) Probe id=q, nonce=q, |
| state=exploring | But its it's lost,
|<--------------------------------------------| retransmission
| | uses another pair
A realizes |
that it needs |
to start the |
exploration. It |
It picks B2 as the |
most likely candidate, |
as it appeared in the |
Probe
Probe. |
State: InboundOk |
| |
| (A, B2) Probe id=r, nonce=r, |
| state=inboundok, |
| received probe q | This one gets
|-------------------------------------------->| through.
| | State:
| | Operational
| |
| |
| (B2,A) Probe id=s, nonce=s, |
| state=operational, | B now knows
| received probe r | that A has no
|<--------------------------------------------| problem to receive receiving
| | its packets packets.
State: Operational |
| |
| (A,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again 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.

EXAMPLE 5: One-way failure 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 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 id=p, nonce=p, | sends a com-
| state=exploring | plaint that
|<--------------------------------------------| it is not rec-
| | eiving anything anything.
A responds responds. | State: Exploring
State: InboundOk |
| |
| (A1, B1) Probe id=q, nonce=q, |
| state=inboundok, |
| received probe p |
|----------------------------------------/ | But A's response
| | is lost lost.
| (B2,A2) Probe id=r, nonce=r, |
| state=exploring | Next Next, try a different
|<--------------------------------------------| locator pair pair.
| |
| (A2, B2) Probe id=s, nonce=s, |
| state=inboundok, |
| received probes p, r | This one gets
|-------------------------------------------->| through through.
| | State: Operational
| |
| | B now knows
| | that A has no
| (B2,A2) Probe id=t, nonce=t, | problem to receive receiving
| state=operational, | its packets, packets and
| received probe s | that A's probe
|<--------------------------------------------| gets to B. It
| | sends a
State: Operational | confirmation to A A.
| |
| (A2,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again again.
| (B1,A1) payload packet |
|<--------------------------------------------|

Appendix B. Contributors

This draft document attempts to summarize the thoughts and unpublished
contributions of many people, including the MULTI6 WG design team members
Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis Lindqvist,
Margaret Wasserman, and Jukka Ylitalo, the Ylitalo; MOBIKE WG contributors Pasi
Eronen, Tero Kivinen, Francis Dupont, Spencer Dawkins, and James Kempf,
Kempf; and HIP WG contributors such as Pekka Nikander. This draft document
is also in debt to work done in the context of SCTP [RFC4960] and HIP the
Host Identity Protocol (HIP) multihoming and mobility extension
[I-D.ietf-hip-mm].
[RFC5206].

Appendix C. Acknowledgements

The authors would also like to thank Christian Huitema, Pekka Savola,
John Loughney, Sam Xia, Hannes Tschofenig, Sebastian 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.

Authors' Addresses

Jari Arkko
Ericsson
Jorvas 02420
Finland

Email:

EMail: jari.arkko@ericsson.com

Iljitsch van Beijnum
IMDEA Networks
Avda. del Mar Mediterraneo, 22
Leganes, Madrid 28918
Spain

Email:

EMail: iljitsch@muada.com

Full Copyright Statement

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

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

Intellectual Property

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

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

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