WDIFF

draft-ietf-shim6-failure-detection-01.txt --> draft-ietf-shim6-failure-detection-02.txt

Network Working Group J. Arkko
Internet-Draft Ericsson
Expires: April 11, 27, 2006 I. Beijnum
Muada
October 8, 24, 2005

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

Status of this Memo

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

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

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

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

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

This Internet-Draft will expire on April 11, 27, 2006.

Abstract

This draft discusses document defines a mechanism for the issues detection of detecting communication
failures in a currently
used address pair between two communicating hosts at IP layer, and picking an
exploration protocol for switching to another pair of interfaces
and/or addresses between the same hosts if a new address working pair to can be used when a failure occurs.
found. The draft also discusses the roles of a multihoming protocol
versus network attachment functions at IP and link layers.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 1]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 7
4.1. Available Addresses . . . . . . . . . . . . . . . . . 8 . 7
4.2. Locally Operational Addresses . . . . . . . . . . . . 9 . 8
4.3. Operational Address Pairs . . . . . . . . . . . . . . 9 . 8
4.4. Primary Current Address Pair . . . . . . . . . . . . . . . . . 11 . 10
4.5. Miscellaneous . . . . . . . . . . . . . . . . . . . . 11 . 10
5. Architectural Considerations Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11
5.2. Alternative Address Pair Exploration . . . . . . . . . . 11
5.3. Exploration Order . . . . . . . . . . . . . . . . . . . 12
6. Solution
5.4. Protocol Design . . . . . . . . . . . . . . . . . . . . 13
5.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 14
6.1. State Machines
5.6. Limitations . . . . . . . . . . . . . . . . . . . . 14 . . 17
6. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 18
6.1. SHIM6 Probe Message . . . . . . . . . . . . . . . . . . 18
6.2. Failure Detection SHIM6 Event Option . . . . . . . . . . . . . . . . . . . 19
6.3. Alternative Locator Pair Exploration REAP Event Message . . . . . . . . . 19
6.3.1. Exploration Order . . . . . . . . . . 19
6.4. REAP Options . . . . . . . . . 19
6.3.2. Exploration Protocol . . . . . . . . . . . . . 21
7. Security Considerations
6.4.1. Payload Reception Report . . . . . . . . . . . . 21
6.4.2. Event Reception Report . . . . . . . 23
8. References . . . . . . 22
6.5. State Machine . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . 23
6.6. Protocol Constants . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . 23
7. Security Considerations . . . . . . . . . . . . . 24
Appendix A. Contributors . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . 27
Appendix B. Acknowledgements . . . . . . . 27
9. References . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 28
9.2. Informative References . . 30

Arkko Expires April 11, . . . . . . . . . . . . . . . 28
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34

Arkko & Beijnum Expires April 27, 2006 [Page 2]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

1. Introduction

The SHIM6 working group is extending protocol extends IPv6 to support multihoming.
The focus of the group This
protocol is to look at an IP layer (or layer 3.5) mechanism that hides multihoming from
applications [23]. This
mechanism needs to detect [18]. A part of the SHIM6 solution involves detecting
when a switch to another address or currently used pair of addresses becomes necessary. (or interfaces) between two
communication hosts has failed, and picking another pair when this
occurs. We call this the former failure detection. detection, and the latter locator
pair exploration.

This draft discusses what requirements such a component of defines the SHIM6 mechanism and protocol has, to achieve both failure
detection and how these requirements can locator pair exploration. This protocol is called
REAchability Protocol (REAP). It designed to be achieved. carried within the
SHIM6 protocol, but may also be used in other contexts.

The draft is structured as follows: Section 3 discusses what kind of solutions
have been used prior work in other similar protocols.
this space, Section 4 defines a set of useful terms and discusses them, and terms, Section 5 discusses the
architectural implications gives
an overview of failure detection designs. Finally, REAP, and Section 6 describes one possible solution involving a mechanism to
detect failures specifies the message formats and an exploration protocol for working address
pairs.
behaviour in detail. Section 7 discusses the security considerations
of REAP.

For the purposes of this draft, we consider an address to be
synonymous with a locator. There may be We assume that there are other, higher
level identifiers such as security associations, FQDNs, CGA public keys,
HBA bindings, keys or HITs HBA bindings that tie
the different locators used by a node
together. together [17].

Arkko & Beijnum Expires April 11, 27, 2006 [Page 3]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

2. Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1]. [2].

Arkko & Beijnum Expires April 11, 27, 2006 [Page 4]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

3. Related Work

Another SHIM6 document [10] discusses what kind of mechanisms can be
used to detect whether the peer is still reachable at the currently
used address. Two proposed mechanisms, Correspondent Unreachability
Detection (CUD) and Forced Bidirectional Communication (FBD) are
presented. CUD is based on getting upper layer positive feedback,
and IPv6 NUD-like probing if there is no feedback. FBD is based on
forcing bidirectional communication by adding keepalive messages when
there is no other, payload traffic.

In SCTP [11], [10], the addresses of the endpoints are learned in the
connection setup phase either through listing them explicitly or via
giving a DNS name that points to them. In order to provide a
failover mechanism between multihomed hosts, SCTP has the following
functions:

o One selects one of the
peer's addresses is selected as the primary address by the application running on
top of SCTP. All data packets are sent to this address until there
is a reason to choose another address, such as the failure of the
primary address.

o Testing

SCTP also tests the reachability of the peer endpoint's addresses.
This is done both via observing the data packets sent to the peer or
via a periodic heartbeat when there is no data packets to send. Each
time data packet retransmission is initiated (or when a heartbeat is
not answered within the estimated round-trip time) an error counter
is incremented. When a configured error limit is reached, the
particular destination address is marked as inactive. The reception
of an acknowledgement or heartbeat response clears the counter.

o
Retransmission: When retransmitting the endpoint attempts pick the
most "divergent" source-destination pair from the original source-
destination pair to which the packet was transmitted. Rules for such
selection are, however, left as implementation decisions in SCTP.

SCTP does not define how local knowledge (such as information learned
from the link layer) should be used. SCTP also has no mechanism to
deal with dynamic changes to the set of available addresses, although
mechanisms for that are being developed [18]. [20].

The MOBIKE protocol is currently being specified [16] [15]. This

Arkko Expires April 11, 2006 [Page 5]

Internet-Draft SHIM6 Failure Detection October 2005

protocol operates in a mixed IPv4/IPv6 environment, [15] provides multihoming and typically has
to work through NATs. The current design mobility for VPN
connections. Its failure detection and locator pair exploration is assumed to need
designed to work
only in symmetric connectivity scenarios.

Some of the issues across mixed IPv4/IPv6 environments and NATs, as
long as a path that have been discussed allows bidirectional communication can be found.

Existing mechanisms at lower layers or in the IKEv2 are used to detect
failures, and upon failure MOBIKE design
phase include the following:

o Single address vs. multiple peer addresses. A simple approach is attempts to have the peers be aware of just the current address of the
other side instead of explore all possible ones. Assuming that one
combinations of the
peers will request the other to start sending addresses to find a new address
this works well. However, this approach working pair. Such exploration
is unable to deal with
problems that affect necessary when a problem affects both nodes. For instance, two
nodes connected by two separate point-to-point links will be unable
to switch to the other link if a failure occurs on the first one.

o Addresses vs. address pairs. Are tests and current paths
individual peer
While both communicating hosts are aware of each others' addresses, or pairs
only one end of peer and own addresses
(paths)? It seems that some failure scenarios require the use communication is in charge of
a path rather than a single address. A network failure may make
it impossible to communicate between a particular deciding what
address pair of
addresses, even if those addresses have some other connectivity.

o Where the connectivity information comes from. Does it come from
local stack (such as interface up/down, router advertisement),
from reception of ESP packets, from IKEv2 keepalives, or through
some MOBIKE-defined mechanism? to use, however.

The mobility and multihoming specification for the HIP protocol [14]
leaves the determination of when address updates are sent to a local
policy, but suggests the use of local information and ICMP error
messages.

Arkko & Beijnum Expires April 27, 2006 [Page 5]

Internet-Draft Failure Detection Protocol October 2005

Network attachment procedures are also relevant for multihoming. The
IPv6 and MIP6 working groups have standardized mechanisms to learn
about networks that a node has attached to. Basic IPv6 Neighbor
Discovery was, however, designed primarily for static situations.
The fully dynamic detection procedure has turned out to be a
relatively complex procedure for mobile hosts, and it was not fully
anticipated at the time IPv6 Neighbor Discovery or DHCP were being
designed. As a result, enhanced or optimized mechanisms are being
designed in the DHC and DNA working groups [6] [13] [7].

ICE [17], [16], STUN [12], [11], and TURN [24] [25] are also related mechanisms. They
are primarily used for NAT detection and communication through NATs

Arkko Expires April 11, 2006 [Page 6]

Internet-Draft SHIM6 Failure Detection October 2005
in IPv4 environment, for application such as as voice over IP. STUN
uses a server in the Internet to discover the presence and type of
NATs and the client's public IP addresses and ports. TURN makes it
possible to receive incoming connections in hosts behind NATs. ICE
makes use of these protocols in peer-to-peer cooperative fashion,
allowing participants to discover, create and verify mutual
connectivity, and then use this connectivity for multimedia streams.
While these mechanisms are not designed for dynamic and failure
situations, they have many of the same requirements for the
exploration of connectivity, as well as the requirement to deal with
middleboxes.

Related work in the IPv6 area includes RFC 3484 [5] [6] which defines
source and destination address selection rules for IPv6 in situations
where multiple candidate address pairs exist. RFC 3484 considers
only a static situation, however, and does not take into account the
effect of failures. In the MULTI6 working group [22] [24] considers how
applications can re-initiate connections after failures in the best
way. This work differs from the shim-layer approach selected for
further development in the working group with respect to the timing
of the address selection. In the shim-layer approach failure
detection and the selection of new addresses happens at any time,
while [22] [24] considers only the case when an application re-establishes
connections.

An earlier SHIM6 document [19] discussed what kind of mechanisms can
be used to detect whether the peer is still reachable at the
currently used address. Two proposed mechanisms, Correspondent
Unreachability Detection (CUD) and Forced Bidirectional Communication
(FBD) were presented. CUD is based on getting upper layer positive
feedback, and IPv6 NUD-like probing if there is no feedback. FBD is
based on forcing bidirectional communication by adding keepalive
messages when there is no other, payload traffic. FBD is the chosen
mechanism in this document.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 7] 6]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

4. Definitions

This section defines terms useful in discussing the failure detection problem space.

4.1. Available Addresses

SHIM6

Multihoming 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. 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 the following conditions are fulfilled:

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

o If the address is an IPv6 address, we additionally require that
(a) the address is valid in the sense of RFC 2461 [2], [3], and that
(b) the address is not tentative in the sense of RFC 2462 [3]. [4]. 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 [8] even though implementations are probably better
off using other addresses as long as there is an alternative.

o The address is a global unicast, unique local address [9], or an
unambiguous IPv6 link-local or IPv4 RFC 1918 address. That is, it is not an IPv6
site-local address. Where IPv6 link-local or RFC
1918 addresses are used,
their use needs to be unambiguous. The
precise meaning of ambiguous has not been defined yet, but one
approach is requiring that at unambiguous as follows. At most one link-local link-
local address may be used per node within the same connection
between two peers.

Note: Given

IPv4 compatibility note: If this protocol were defined to
handle IPv4, then RFC 3484 [5] rules for preferring smallest scope,
it is likely that many IPv6 flows at least start with even
link-local addresses. 1918 addresses would also need to be
allowed.

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

Arkko Expires April 11, 2006 [Page 8]

Internet-Draft SHIM6 Failure Detection October 2005

Available addresses are discovered and monitored through mechanisms
outside the scope of SHIM6 (and HIP or MOBIKE). the protocol described here. These mechanisms
include IPv6 Neighbor Discovery and Address Autoconfiguration [2]
[3], DHCP [3]
[4], enhanced network detection mechanisms detected by the
DNA working group, DHCP [5], and corresponding DNA mechanisms [7].

Arkko & Beijnum Expires April 27, 2006 [Page 7]

Internet-Draft Failure Detection Protocol October 2005

IPv4 mechanisms, such as [6]. compatibility note: If IPv4 was supported in this protocol,
then also mechanisms defined in [13] would need to be supported.

4.2. Locally Operational Addresses

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

Definition. Locally Operational Address. An available address is
said to be locally operational when its use is known to be possible
locally: the interface is up, a relevant at least one default router (if
applicable) that could be used to send a packet with this address as
a source 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 SHIM6 (and HIP or MOBIKE). the protocol described here. These mechanisms
include IPv6 Neighbor Discovery [2], corresponding IPv4 mechanisms, [3] and link layer specific
mechanisms.

IPv4 compatibility note: In IPv4, mechanisms such as those defined
in [13] could be used.

It is also possible for hosts to learn about routing failures for a
particular selected source prefix. Protocols prefix, if suitable protocols for distributing this
information are being designed [19] [22]. The development of such
protocols would be possible, however.
purpose exist. Some proposals in this space have been made, see, for
instance [21] and [24]. Potential approaches include overloading
information in current IPv6 Router Advertisement or adding some new
information in them. Similarly, hosts could learn information from
servers that query the BGP routing tables.

4.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 the sent packets
from reaching their destination. For this reason we need the
definition of a second level of granularity, for pairs of addresses:

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

Unfortunately, there are scenarios where bidirectionally operational
address pairs do not exist. For instance, ingress filtering or

Arkko & Beijnum Expires April 27, 2006 [Page 8]

Internet-Draft Failure Detection Protocol October 2005

network failures may result in one address pair being operational in

Arkko Expires April 11, 2006 [Page 9]

Internet-Draft SHIM6 Failure Detection October 2005
one direction while another one is operational from the other
direction. The following definition captures this general situation:

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

Both types of operational pairs are could be discovered and monitored
through the following mechanisms:

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 [2]. [3]. 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
SHIM6
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 Explicit reachability tests, such as keepalives or probes added
when there's only unidirectional payload traffic [10]. traffic.

o ICMP error messages. Given the ease of spoofing ICMP messages,
one should be careful to not trust these blindly, however. Our
suggestion is to use ICMP error messages only as a hint to perform
an explicit reachability test, but not 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 [21]. [23]. These verifications can ensure
that (practically) only on-path attackers can spoof the messages.
Such verifications are not possible for all transport protocols,
however.

Note that some protocols, such as HIP [14] and MOBIKE [16], a multihoming protocol needs to perform a return routability
test of an address before it is taken into use. The purpose of this
test is to ensure that fraudulent peers do not

Arkko Expires April 11, 2006 [Page 10]

Internet-Draft SHIM6 Failure Detection October 2005 trick others into
redirecting traffic streams onto innocent victims [26]. Such tests This test
can at the same time work as a means to ensure that an address pair
is operational. Note, however, that some advanced
optimizations attempt to postpone the reachability tests so that they
do not increase movement-related latency [25].

4.4. Primary Address Pair

Contrary to SCTP which has a specific congestion avoidance design
suitable for multi-homing, IP-layer operational, as discussed in Section 5.2.

Arkko & Beijnum Expires April 27, 2006 [Page 9]

Internet-Draft Failure Detection Protocol October 2005

4.4. Current Address Pair

IP-layer solutions need to avoid sending packets concurrently over
multiple paths; TCP behaves rather poorly in such circumstances. For
this reason it is necessary to choose a particular pair of addresses
as the primary current address pair which is used until problems occur, at
least for the same session.

A primary current address pair need not be operational at all times. If
there is no traffic to send, we may not know if the primary address
pair is operational. Nevertheless, it makes sense to assume that the
address pair that worked in some time ago continues to work for new
communications as well.

4.5. Miscellaneous

Addresses can become deprecated [2]. [3]. When other operational
addresses exist, nodes generally wish to move their communications
away from the deprecated addresses.

Similarly, IPv6 source address selection [5] [6] may guide the selection
of a particular source address - destination address pair.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 11] 10]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

5. Architectural Considerations

Architecturally, a number Protocol Overview

This section discusses the design of questions arises. One simple question
is whether there needs to be communications between a multihoming
solution residing at the IP layer failure detection and upper layer protocols? Upon
changing to a new
address pair, transport layer protocol SHOULD be
notified so that it can perform a slow start, or some other form pair exploration mechanisms, and gives on overview of
adaptation to the possibly changed conditions.
REAP protocol.

5.1. Failure Detection

This process consists of three tasks. First, it is necessary,
for necessary to
track local information from lower and upper layers. For instance,
when switching from a high-bandwidth LAN interface to a
low bandwidth cellular interface. (Note link layer informs that this notification can
not be done in protocol designs where the end points are not the
final hosts, such as where a gateway is used.)

A more fundamental question we have no connection then we know there
is which protocols should a failure. Nodes SHOULD employ techniques listed in Section 4.1
and Section 4.2 to be responsible
for which parts aware of the problem. It seems clear that no multihoming
solution should take on the task of lower layers and other IP
functions for discovering its own addresses or testing local
connectivity. Protocols such as DHCP or Neighbor and Router
Discovery do this already.

But situation.

Similarly, it is less clear which protocol(s) should discover end-to-end
connectivity problems or recover necessary to track remote address information from them. One answer is
the peer. For instance, the peer may inform that this its currently used
address is clearly within no longer in use. Techniques outside the domain of multihoming protocol. By performing
testing and failure detection scope of the this
document are used path and switching for this, for further information see [18].

The third task is to a new
path if necessary, ensure verify reachability with the transport and application protocols can work
unchanged.

On peer when
the other hand, one could argue that transport local and application
protocols would have more knowledge about remote information indicates that communication should
be possible. This needs to be performed only if there's upper layer
packets to be sent, however.

This document defines the situation, and have protocol mechanisms only for the third
task. We employ a
better ability technique called Forced Bidirectional Detection
(FBD) to decide ensure reachability. This technique tests reachability only
when a move there's payload traffic. When there is required. For instance, they
know what the required throughput and congestion status is. Also, it
would no payload traffic, no
tests will be unfortunate if both the IP layer performed, and transport/application
layer took action for the same problem, no failure are assumed to exist.

Similarly, when there is bidirectional payload traffic, there is no
need for instance by switching FBD to
a new address at do anything, as packets are already flowing as
expected. However, if one of the IP layer and throttling back due peers is only receiving but not
sending any other traffic, then FBD sends occasional keepalives to "congestion"
at
the transport layer.

One can also envision that applications would be able other peer in order to tell let the IP
or transport layer peer know that the current connection in unsatisfactory and
an exploration for its payload traffic
is getting through. As a better one would be desirable. This would
require an API result, a node that is sending something to be developed, however.

Generally speaking, we
the peer but receives nothing in return can divide information assume that there's a host has into
three categories: local information from "lower layers" such as IPv6
Neighbor Discovery, transit and congestion condition information from
either from the multihoming protocol itself or from transport layer
protocols and (where available) ECN, and application layer policies
failure.

5.2. Alternative Address Pair Exploration

As explained in previous section, the currently used address pair may
become invalid either through one of the addresses being becoming
unavailable or inoperational, or the pair itself being declared
inoperational. An exploration process attempts to find another
operational pair so that dictate what communications can resume.

What makes this process hard is the requirements are for acceptable connections. requirement to support

Arkko & Beijnum Expires April 11, 27, 2006 [Page 12] 11]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

The division of work is largely left as an open issue as far as this
document

unidirectionally operational address pairs. It is concerned, but our description works from a point of view
of insufficient to
probe address pairs by a multihoming protocol at simple request - response protocol.
Instead, the IP layer. We also note party that in first detects the
CELP proposal [20], both IP, transport, and application layer
entities could share their connectivity status problem starts a process
where it tries each of the different address pairs in turn by sending
a common message to its peer. These messages carry information pool. This may also be a useful approach.

Finally, the last architectural question is about the difference
state of connectivity between mobility and multihoming. Given our definitions above,
there's no fundamental difference with respect to how the
multihoming/mobility protocol learns peers, such as whether the addresses it sender
has available.
However, seen any traffic from the peer recently. When the peer receives
a practical difference is message that in a multihoming scenario
there are alternative addresses, whereas in mobility changes to indicates a new
address are forced due problem, it assists the process by
starting its own exploration to the old address no longer being available.
Interestingly, with other direction, again sending
information about the exception 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 MOBIKE, existing mobility
protocols do not employ any failure detection mechanisms Event
messages, in sequence, until it gets an Event message from B
indicating that (a) B has received one of their
own, and rely solely on link layer and neighbor discovery mechanisms.

Arkko Expires April 11, 2006 [Page 13]

Internet-Draft SHIM6 Failure Detection October 2005

6. Solution

We need A's messages and,
obviously, (b) that B's Event message gets back to keep track of A. B uses the host's own available addresses,
operational addresses, and operational address pairs, and to explore
for other operational pairs when a failure occurs. We will first
describe two general state machines that illustrate same
algorithm, but starts the overall
process, and then discuss process from the details reception of the reachability tests
needed for ensuring operational status, and the exploration protocol.

6.1. State Machines

Addresses can be in the AVAILABLE and OPERATIONAL states. The state
transitions relating first
Event message from A.

Upon changing to this are shown in Figure 1.

+--------------+
Address becomes | |
available | |
----------------->| |
| AVAILABLE |
<-----------------| |
Address is no | |
longer available | |
+--------------+
| / \
Address | | Address
becomes | | is no longer
operational | | operational
| |
\ / |
+--------------+
| |
Address is no | |
longer available | |
<-----------------| OPERATIONAL |
| |
| |
| |
+--------------+

Figure 1. Address state machine.

When an address becomes operational, it SHOULD be reported as a new address pair, transport layer protocol needs
to be informed so that it can perform a slow start, or some other
form of adaptation to the peer. Similarly, when an address possibly changed conditions. However, this
functionality is no longer
operational or available, outside the peer SHOULD be informed.

In addition, scope of REAP and is rather seen as a particular address
general multihoming issue.

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

5.3. Exploration Order

The exploration process assumes an ability to pick current and
alternative address pairs. This process results in a combinatorial
explosion when there are many addresses on both sides. However, not
all combinations are legal. In order to avoid congestion, we also
can not explore all pairs without performing some kind of a back-off
procedure.

Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine
what combinations of addresses are legal from a local point of view,
as this reduces the state machine. search space. RFC 3484 also provides a priority
ordering among different address pairs, making the search possibly
faster. Nodes MAY also use local information, such as known quality
of service parameters or interface types to determine what addresses

Arkko & Beijnum Expires April 11, 27, 2006 [Page 14] 12]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Another state machine describes address pair selection. A node runs
the address pair selection state machine to choose the currently used
primary address pair, the one which is used for sending outgoing
packets. A node runs one of these state machines towards each
different peer, tracking the known address pairs

are preferred over others, and their status.
Each peer try pairs containing such addresses
first. The multihoming protocol also has carries preference information
in its own state machine for talking back to the
node; there messages [18].

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

One suggested good implementation strategy is to record the
reachability test result (an on/off value) and multiply this by the
age of the information. This allows recently tested address pairs (in reverse
order) have to
be chosen before old ones.

IPv4 compatibility note: As has been noted in the same state; lack context of bidirectionally
MOBIKE, the existence of NATs can require that peers continuously
monitor the operational pair
would result in a different status of address pairs, as otherwise NAT
state related to a particular communication is lost, and the peer
on both sides, for instance.

The state machine the outer side of the NAT can be in no longer reach the NO PRIMARY, TESTING PRIMARY, and
PRIMARY OPERATIONAL states. The chosen peer inside
the NAT.

Out of the set of possible candidate address pairs, nodes SHOULD
attempt a test through all of them until a working pair is known to be
operational found.
However, all nodes MUST do this sequentially and using an exponential
back-off procedure. 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 PRIMARY OPERATIONAL state, 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.

5.4. Protocol Design

REAP is either
unverified or non-operational designed as a modular part of SHIM6 in the hopes that it may
also be useful in other states.

Figure 2 shows the state machine:

Arkko contexts. This document defines how it is
carried within SHIM6, but the actual protocol messages are self-
contained so that it could be carried by other protocols as well.

Similarly, while this document defines a SHIM6 message that carries
REAP, this message is only used when no other SHIM6 message is about
to be sent that could be used to carry the REAP information. For
instance, a Locator List Update message can be used to carry a REAP
message that conveys reachability information.

The REAP design allows performing both failure detection and address

Arkko & Beijnum Expires April 11, 27, 2006 [Page 15] 13]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

+----------------+

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

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

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

5.5. Example Protocol Runs

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

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

Arkko & Beijnum Expires April 27, 2006 [Page 14]

Internet-Draft Failure Detection Protocol October 2005

Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
+-----| |<---------------+
| payload packet |
|<--------------------------------------------|
| |
| +----------------+ payload packet |
|-------------------------------------------->|
| / \ / \ |
Add
| |

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

Peer A Peer B
| |
pair:
| Delete payload packet |
|-------------------------------------------->|
| Test Delete |
Send
| pair & payload packet |
|-------------------------------------------->|
| fail & pair & |
test
| Last payload packet |
|-------------------------------------------->|
| Last Last |
| REAP Event id=p, |
| iseeyou=yes, |
| +----------------+ payload reception report |
|<--------------------------------------------|
| |
| payload packet |
+---->| |<----+
|-------------------------------------------->|
| |
| | Test

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

Internet-Draft Failure Detection Protocol October 2005

| |
| (B1,A1) payload packet | |<----+
|<--------------------------------------------|
| | +---->| Path A1->B1
| (A1,B1) payload packet | is now
|----------------------------------------/ | broken
| | +----------------+
| |
Policy Eventually, B
| ICMP | sends a com-
| (B1,A1) REAP Event id=p, | plaint that
| iseeyou=no | it is not rec-
|<--------------------------------------------| eiving anything
|
change | Timer:
A realizes | ULP
that it needs |
to start the | Test
exploration | Delete
| | Send
| feedback:| (A1, B1) REAP Event id=q, | OK:
| pair & iseeyou=yes |
| test payload reception rep | Reset
| event reception rep(p)| But it gets lost
|-------------------------------------/ | Reset due to broken path
| !Last |
Retransmission |
to a different | timer
address |
| timer |
| (A1, B2) REAP Event id=r, |
| \ / \ / iseeyou=yes |
| payload reception rep |
| +----------------+ event reception rep(p)| This one gets
|-------------------------------------------->| through
| |
| +-----| |
| | B now knows
| | |-----+ that A has no
|
+--------------| (B1,A1) REAP Event id=p, | problem to receive
| iseeyou=yes, | its packets and
| event reception rep(r)| This one gets
|<--------------------------------------------| that A has found
|
+-----| OPERATIONAL | a new path to B
|
ULP feedback: |
| PRIMARY (A1,B2) payload packet |
|-------------------------------------------->| Payload packets
|
Reset timer | flow again
| |----------------+
+---->| (B1,A1) payload packet |
|<--------------------------------------------|

Arkko & Beijnum Expires April 27, 2006 [Page 16]

Internet-Draft Failure Detection Protocol October 2005

| |
+----------------+

Figure 2. Pair selection state machine.

5.6. Limitations

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

REAP does not support IPv4, but could be extended to do so. We have
noted IPv4 compatibility issues where they exist.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 16] 17]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

6. Protocol Definition

6.1. SHIM6 Probe Message

The notation used in Figure 2 SHIM6 Probe message carries REAP messages when no other SHIM6
message needs to be sent. Its format is explained below:

Connect

An event representing the desire of the application 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = TBD | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header

This value MUST be set to send a
packet NO_NXT_HDR (59).

Type

This field identifies the Probe message and MUST be set to < TBD
by IANA > (Probe).

Reserved1

This is a new peer, or an indication from a peer wishing to
connect 7-bit field reserved for future use. It is set to us.

Test OK

An event representing zero
on transmit, and MUST be ignored on receipt.

Reserved2

This is a successful completion of the reachability
test.

Test fail

An event representing failure to complete the reachability test.

ULP feedback

An event representing positive indication from an upper layer
protocol that the packets we have sent 16-bit field reserved for future use. It is set to the peer are getting
through.

ICMP

An event representing the reception of an ICMP error message.

Timer

An event representing timer elapsing.

Add pair

An event representing the addition of a new possible address pair,
either through learning a new local address or being told of a new
remote address. Note that this does not usually result in any
immediate action, unless we are currently lacking an operational
primary pair. zero
on transmit, and MUST be ignored on receipt.

Receiver Context Tag

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

Arkko & Beijnum Expires April 11, 27, 2006 [Page 17] 18]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Delete pair

An event representing

Options

This MUST contain at least the deletion of SHIM6 Event option and MAY contain
other options.

A valid SHIM6 Probe message conforms to the currently chosen primary
address pair, or learning format above and has a
Receiver Context Tag that one of the addresses is in matches to context known by the pair
is no longer operational.

Policy change

An event representing receiver.
The receiver processes a valid message by inspecting its options, and
executing any actions specified for the desire of SHIM6 Event option found
within the local or remote end to
change options.

6.2. SHIM6 Event Option

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ REAP Event ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

This value MUST be set to a different address pair, despite the current one being
operational. < TBD by IANA > (Event Option).

This can value MUST be due set to the availability of the higher-
bandwidth connection, cost, or 0, as in other issues.

Last

A condition that tells whether or not the currently chosen primary
pair is the only known address pair.

Send test

An action to initiate the reachability test for a particular pair. SHIM6 options.

Length

This test is typically embedded in the SHIM6 connection setup
exchange when run initially, and a separate exchange later.

Note that due to potentially asymmetric connectivity, both sides
have to perform their own tests, length of the option and make their own primary pair
selections.

Reset timer

An action to reset a timer so that it will send an event after a MUST be calculated as
specified time.

The state machines also assumes an underlying multihoming signaling
capability, consisting in Section 5.14 of [18].

The processing rules for this option are the following abstract message exchanges:

Open

Establishes a connection between ones defined for the peers. May also exchange
locator sets and test reachability at
REAP Event field in Section 6.3.

6.3. REAP Event Message

REAP Event messages are the same time. only messages in the REAP protocol.
Their format is as follows:

Arkko & Beijnum Expires April 11, 27, 2006 [Page 18] 19]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Test

Verifies reachability using a specific address pair.

Add

Informs the peer about new locators.

Delete

Informs

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y| Res | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ REAP Options ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message Type

This value identifies the peer about losing some locators.

Note that REAP message, and MUST be set to 1
(Event).

Length

This is the above state machine leaves open how specific address
pairs are chosen or how length of the tests are actually performed. These
issues will be discussed in message excluding the next sections. We have also, on
purpose, decided to avoid attaching functional labels such as
"backup" Message Type and
Length fields, expressed in bytes.

Y (The "I See You" flag)

This flag is set to other address pairs beyond 1 if the primary pair. It is our
belief that a general design does not need these labels.

6.2. Failure Detection

This process consists of three tasks:

o Tracking local information sender receives either payload
packets or REAP messages from lower the peer, and upper layers. For
instance, 0 otherwise. The
determination of when link layer informs that we have no connection then
we know there is a failure.

o Performing a reachability process as described in in [10] for
ensuring that there the sender receives something is reachability when made during
the local information
says last Exploration Init Timeout seconds (see Section 6.6) when
traffic was expected, i.e., when there should be.

o Following commands from was either payload traffic
or REAP messages.

Upon reception, a value of 1 indicates that the peer regarding receiver does not
need to change its behaviour as the availability sender is already seeing its
packets. A value of 0 indicates that the receiver MUST explore
different outgoing address pairs.

Res

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

Identifier

This identifies this particular instance of
addresses.

6.3. Alternative Locator Pair Exploration

6.3.1. Exploration Order

The pair selection state machine assumes an ability to pick primary
and alternative address pairs. Event message.
This process results in value SHOULD be generated using a combinatorial explosion when there random number generator
that is known to have good randomness properties [1]. Upon
reception, Identifier values are many
addresses on both sides. Do copied onto Event Reception
Report options. This allows them to be used for both sides track all possible
combinations of addresses? If identifying
which Events were received as well as for performing a failure occurs, shall all
combinations be tested before giving up? Are such tests performed in
parallel or in sequence, and what kind of backoff procedures should return
routability test.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 19] 20]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

REAP Options

This field contains zero or REAP options. Unrecognized options
MUST be applied?

Our suggestion is that nodes ignored upon receipt. All implementations MUST first consult RFC 3484 [5] support
the options defined in Section 6.4, however.

6.4. REAP Options

The general option format is as follows:

0 1 2 3
0 1 2 3 4 rules to determine what combinations of addresses are legal from a
local point 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Option Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type

This value identifies the option.

Length

This is the length of view, as this reduces the search space. RFC 3484 also
provides a priority ordering among different address pairs, making option excluding the search possibly faster. Nodes Option Type and
Length fields, expressed in bytes.

Option Data

Option-specific content.

6.4.1. Payload Reception Report

This option SHOULD also use local information,
such be included in any Event message when the sender
has recently (within the last Exploration Init Timeout seconds)
received payload packets from the peer. Its format is as known quality of service parameters or interface types to
determine what addresses are preferred over others, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Suboptions ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Arkko & Beijnum Expires April 27, 2006 [Page 21]

Internet-Draft Failure Detection Protocol October 2005

Option Type

This value identifies the option and try pairs
containing such addresses first. In some cases we can also learn MUST be set to 1 (Payload
Reception Report).

Length

This is the
peer's preferences through length of the multihoming protocol.

Discussion note 1: It may also be option excluding the Option Type and
Length fields, expressed in bytes.

Suboptions

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

IPv4 compatibility note: If IPv4 and NATs would need to simulate preferences
by choosing be
supported, then it might be necessary to not tell indicate what
addresses and port numbers were used in the peer about some (non-preferred)
addresses.

Discussion note 2: The preferences may either be learned
dynamically or received payload
packets.

6.4.2. Event Reception Report

This option MUST be configured. It is believed, however, that
dynamic learning based purely on included in any Event message when the SHIM6 protocol is too hard sender has
recently (within the last Exploration Init Timeout seconds) received
Event messages from the peer. Depending on MTU and not timing
considerations, the task this layer should do. Solutions where multiple
protocols share their information in a common pool sender MAY, however, include options for only
some of locators
could provide this information from transport protocols, however
[20]. the received Event messages. All implementations MUST
support sending of at least five such options, however.

The reception format of packets from this option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Suboptions ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type

This value identifies the peer with a given address pair option and MUST be set to 1 (Payload
Reception Report).

Arkko & Beijnum Expires April 27, 2006 [Page 22]

Internet-Draft Failure Detection Protocol October 2005

Length

This is a
good hint that the address pair works, particularly when these
packets are authenticated multihoming protocol packets. However, the
reception length of these packets alone is an insufficient reason to switch
to a new address, as in an unidirectional connectivity case the
return path may not work.

One suggested good implementation strategy option excluding the Option Type and
Length fields, expressed in bytes.

This is a 1 bit reserved field, MUST be set to record the
reachability test result (an on/off value) zero and multiply this by ignored on
receipt.

Identifier

This 31 bit field carries the
age identifier of the information. This allows Event message that
was recently tested address pairs received.

Suboptions

IPv4 compatibility note: If IPv4 and NATs would need to be chosen before old ones.

Out of
supported, then it might be necessary to indicate what
addresses and port numbers were used in the set of possible candidate address pairs, nodes SHOULD
attempt a test through all received payload
packets.

6.5. State Machine

A suggested state machine to implement REAP is shown below.

(The text version does not have the state machine.
Please consult either the PDF version of them, but MUST do this sequentially and
using an exponential back-off procedure. draft,
or http://www.arkko.com/publications/shim6/reap-proto.jpg)

This sequential process state machine still has some known open issues. One issue is necessary
that it does not represent other events than those present in order to avoid a "signaling
storm" when an outage occurs (particularly for a complete site).
However, it also limits
static situation. For instance, the number loss of an address, or peer
telling us of its new addresses should also affect the state machine.
A more serious issue is that can in practice
be used for multihoming, considering that transport and application
layer protocols will fail if the switch machine treats all flows of under 3
seconds as something that do not need to a new address pair takes
too long. For instance, we be acknowledged. This can assume that an initial timeout value
be easily corrected, but we are struggling with the support of this
while simultaneously not having to perform extra exploration when the
traffic flow legitimately ends.

6.6. Protocol Constants

The following protocol constants are defined:

Arkko & Beijnum Expires April 11, 27, 2006 [Page 20] 23]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

is 0.1

Exploration Init Timeout 10 seconds
Incoming Timeout 3 seconds
Outgoing Timeout 3 seconds
Give Up Timeout 60 seconds
Keepalive Timeout 3 seconds

Arkko & Beijnum Expires April 27, 2006 [Page 24]

Internet-Draft Failure Detection Protocol October 2005

7. Security Considerations

Attackers may spoof various indications from lower layers and there are four addresses on both sides. Going
through all sixteen address pairs and doubling the timeout value at
every trial would take 3200 seconds!

Finally, as has been noted
network in an effort to confuse the context of MOBIKE, the existence of
NATs can require that peers continuously monitor about which addresses are
or are not working. For example, attackers may spoof ICMP error
messages in an effort to cause the operational
status of address pairs, as otherwise NAT state parties to move their traffic
elsewhere or even to disconnect. Attackers may also spoof
information related to a
particular communication is lost, network attachments, router discovery, and the peer on the outer side of
the NAT can no longer reach the peer inside the NAT.

6.3.2. Exploration Protocol

The exploration for a working
address pair is not easy, as
unidirectional reachability needs assignments in an effort to be considered. This is because make the test of a single pair 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 result in a working paths to send
both provide any protection of its own for
indications from other parts of the request and response packets. The following protocol could
be used to avoid stack. However, this problem:

Peer A Peer B
| |
| Poll 1 (src=A1, dst=B1) |
|-------------------------------------------->|
| |
| Poll 2 (src=B1, dst=A1) OK: 1 |
| X------------------------------------|
| |
| Poll 3 (src=A2, dst=B1) |
|------------------------------X |
| |
| Poll 4 (src=B2, dst=A1) OK: 1 |
|<--------------------------------------------|
| |
| Poll 5 (src=A1, dst=B1) OK: 4 |
|-------------------------------------------->|
| |

When B receives
protocol has weak resistance against incorrect information from these
sources in the first Poll message, it memorizes sense that it has
gotten it. The Poll message from B, however, is lost so A tries
again with another pair. This is lost too, but B continues performs its own
testing process by sending its second Poll message, which is received
by A. The messages carry identifiers, and tests prior to picking
a list new address pair. Denial-of- service vulnerabilities remain,
however, as do vulnerabilities against on path attackers.

Some aspects of identifiers that
were found messages these vulnerabilities can be mitigated through the sender had itself successfully received
earlier.

In
use of techniques specific to the end other parts of the example case, A and B know that they have a working
path from A stack, such as
properly dealing with ICMP errors [23], link layer security, or the
use of [12] to B using (A1, B1) protect IPv6 Router and from B to A using (B2, A1).

Arkko Expires April 11, 2006 [Page 21]

Internet-Draft SHIM6 Failure Detection October 2005

More generally, when A decides that it needs Neighbor Discovery.

This protocol is designed to test for
connectivity, it will initiate a set of Poll messages, be used in sequence,
until it gets a Poll message from B indicating that (a) B has
received one situations where other parts
of the stack have ensured that a set of A's Poll messages and, obviously, (b) addresses belong together,
such as via SHIM6 HBAs [17]. That is, REAP itself provides no
assurance that B's Poll
message is getting through. B uses the same algorithm, but starts
the process from the reception a set of addresses belongs to the first Poll message from A.

Note that this protocol same host.
Similarly, REAP provides only minimal protection against third party
flooding attacks; when REAP is run its Event identifiers can be implemented in different ways. One
approach is to rely on data packets, such used
as TCP payload packets and
acknowledgements. This method has the benefit a return routability check that it likely passes
easily through firewalls and other middleboxes. One exception the claimed address is indeed
willing to receive traffic. However, this are stateful firewalls that wish needs to know what happened "earlier"
in the connection, but it seems that such firewalls are fundamentally
incompatible be complemented
with multi-homing anyway. One drawback of this method
is, however, another mechanism to ensure that the claimed address is also the number of available payload packets may not
match
correct host. In SHIM6 this is performed by binding all operations
to context tags.

Finally, the need in a situation where exploration itself can cause a lot number of address pairs need packets to be
explored.

Another approach is to have
sent. As a completely separate protocol result it may be used as a tool for packet amplification
in flooding attacks. In order to prevent this it is required that
the
exploration. This would need protocol employing REAP has built-in mechanisms to be explicitly allowed prevent this.
For instance, in firewalls
before it could be used. On SHIM6 contexts are created only after a relatively
large number of packets has been exchanged, a cost which reduces the other hand, then it
attractiveness of using SHIM6 and REAP for amplification attacks.
However, such protections are typically not present at connection
establishment time. When exploration would be very
clear needed for the firewall administrators what they are letting through. connection
establishment to succeed, its usage would result in an amplification

Arkko & Beijnum Expires April 27, 2006 [Page 25]

Internet-Draft Failure Detection Protocol October 2005

vulnerability. As a result, SHIM6 does not support the use of REAP
in connection establishment stage.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 22] 26]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

7. Security

8. IANA Considerations

Attackers may spoof various indications from lower layers and the
network in an effort to confuse

This document requires the peers about which addresses are
or are not working. For example, attackers may spoof ICMP error
messages in an effort to cause allocation of a SHIM6 message Type code
for the parties to move their traffic
elsewhere or even to disconnect. Attackers may SHIM6 Probe message (Section 6.1).

This document requires 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 allocation of non-preferred addresses or even denial-of-
service. a SHIM6 does not provide any protection of its own option Type
code for indications from
other parts of the protocol stack. However, MOBIKE is resistant to
incorrect information from these sources in SHIM6 Event option (Section 6.2).

This document creates two new name spaces under the sense that it
provides its own security new SHIM6 REAP
repository. The first name space is for both the signaling of addressing
information as well as actual payload data transmission. Denial-of-
service vulnerabilities remain, however. Some aspects of these
vulnerabilities REAP Message Type
(Section 6.3) and it has one reserved value (0) and one defined
value, 1 (Event). Further allocations within this 16-bit field can
be mitigated made through the use of techniques
specific to the other parts of the stack, such as properly dealing
with ICMP errors [21], link layer security, Standards Action or the use of [13] IESG Approval. The range from
65000 to 65535 is reserved for experimental use.

The second name space is for REAP Option Type (Section 6.4) and it
has one reserved value (0) and two defined values, 1 (Payload
Reception Report defined in Section 6.4.1) and 2 (Event Reception
Report defined in Section 6.4.2). Further allocations within this
16-bit field can be made through Specification Required. The range
from 65535 to
protect IPv6 Router and Neighbor Discovery. 65535 is reserved for experimental use.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 23] 27]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

9. References

8.1.

9.1. Normative References

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

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

[2]

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

[3]

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

[4]

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

[5]

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

[6] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004.

[7] Choi, J., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-00 (work in progress), June 2004.

[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
draft-ietf-ipv6-optimistic-dad-01 (work in progress), June 2004.

[9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
progress), June 2004.

[10] Beijnum, I., "Shim6 Reachability Detection",
draft-ietf-shim6-reach-detect-00 (work in progress), July 2005.

8.2.

9.2. Informative References

[11]

[10] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.

[12]

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

Arkko Expires April 11, 2006 [Page 24]

Internet-Draft SHIM6 Failure Detection October 2005

[13]

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

[13] Aboba, B., "Detection of Network Attachment (DNA) in IPv4",

Arkko & Beijnum Expires April 27, 2006 [Page 28]

Internet-Draft Failure Detection Protocol October 2005

draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004.

[14] Nikander, P., "End-Host Mobility and Multi-Homing with Host
Identity Protocol", draft-ietf-hip-mm-00 (work in progress),
October 2004.

[15] Kivinen, T., "Design of the MOBIKE protocol",
draft-ietf-mobike-design-00 (work in progress), June 2004.

[16] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
draft-ietf-mobike-protocol-03 (work in progress),
September 2005.

[17]

[16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
draft-ietf-mmusic-ice-02 (work in progress), July 2004.

[17] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-00 (work in progress), July 2005.

[18] Nordmark, E., "Level 3 multihoming shim protocol",
draft-ietf-shim6-proto-00 (work in progress), October 2005.

[19] Beijnum, I., "Shim6 Reachability Detection",
draft-ietf-shim6-reach-detect-00 (work in progress), July 2005.

[20] Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-10 (work in progress),
January 2005.

[19]

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

[20]

[22] Crocker, D., "Framework for Common Endpoint Locator Pools",
draft-crocker-celp-00 (work in progress), February 2004.

[21]

[23] Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-00 (work in progress),
August 2004.

[22]

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

[23] Nordmark, E., "Level 3 multihoming shim protocol",
draft-ietf-shim6-proto-00 (work in progress), October 2005.

[24]

[25] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-05 (work in progress), July 2004.

[25] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner,
"Credit-Based Authorization for Mobile IPv6 Early Binding
Updates", draft-vogt-mipv6-credit-based-authorization-00 (work

Arkko Expires April 11, 2006 [Page 25]

Internet-Draft SHIM6 Failure Detection October 2005

in progress), May 2004.

[26] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location

Arkko & Beijnum Expires April 27, 2006 [Page 29]

Internet-Draft Failure Detection Protocol October 2005

Management", In Proceedings of the 18th Annual Computer
Security Applications Conference, Las Vegas, Nevada, USA.,
December 2002.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 26] 30]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Appendix A. Contributors

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

The protocol design in Section 6.3.2 is due to Erik, Marcelo, [10] and
Iljitsch. HIP [14].

Arkko & Beijnum Expires April 11, 27, 2006 [Page 27] 31]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Appendix B. Acknowledgements

The author would also like to thank Christian Huitema, Pekka Savola,
and Hannes Tschofenig for interesting discussions in this problem
space, and for their comments on earlier versions of this draft.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 28] 32]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Author's Address

Authors' Addresses

Jari Arkko
Ericsson
Jorvas 02420
Finland

Email: jari.arkko@ericsson.com

Iljitsch van Beijnum
Muada
The Netherlands

Email: iljitsch@muada.com

Arkko & Beijnum Expires April 11, 27, 2006 [Page 29] 33]

Internet-Draft SHIM6 Failure Detection Protocol October 2005

Intellectual Property Statement

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.

Disclaimer of Validity

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

Copyright (C) The Internet Society (2005). 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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Arkko & Beijnum Expires April 11, 27, 2006 [Page 30] 34]

----