view Side-By-Side changes
Network Working Group J. Arkko Internet-Draft Ericsson Intended status: Informational I. van Beijnum Expires:December 28, 2006 Muada June 26,March 27, 2007 September 23, 2006 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihomingdraft-ietf-shim6-failure-detection-05draft-ietf-shim6-failure-detection-06 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 onDecember 28, 2006.March 27, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 1] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 Abstract This document specifies how the level 3 multihoming shim protocol (SHIM6) detects failures between two communicating hosts. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same hosts if a failure occurs and an operational pair can be found. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Available Addresses . . . . . . . . . . . . . . . . . . 5 3.2. Locally Operational Addresses . . . . . . . . . . . . . 6 3.3. Operational Address Pairs . . . . . . . . . . . . . . . 6 3.4.CurrentPrimary Address Pair . . . . . . . . . . . . . . . . . . 84. Protocol Overview .3.5. Current Address Pair . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . .9 4.1. Failure Detection. . . . . . . . . . . . . . . . . . . 94.2. Alternative Address Pair Exploration4.1. Failure Detection . . . . . . . . . .11 4.3. Exploration Order. . . . . . . . . 9 4.2. Alternative Address Pair Exploration . . . . . . . . . . 114.4. Protocol Design .4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 124.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 13 4.6. Limitations . . . . . . . . . . . . . . . . . . . . . . 195. Protocol Definition . . . . . . . . . . . . . . . . . . . . .2014 5.1. Keepalive Message . . . . . . . . . . . . . . . . . . .20 5.1.1. Keepalive Option . . . . . . . . . . . . . . . . 2114 5.2. Probe Message . . . . . . . . . . . . . . . . . . . . .22 5.2.1. Probe Option . . . . . . . . . . . . . . . . . . 24 5.3. Reachability Option . . . . . . . . . . . . . . . . .15 6. Behaviour .25 5.3.1. Payload Reception Report. . . . . . . . . . . .26 5.3.2. Probe Reception Report. . . . . . . . . . . . .26 5.4. Behaviour20 7. Example Protocol Runs . . . . . . . . . . . . . . . . . . . . 24 8. Protocol Constants . . .27 5.5. Protocol Constants. . . . . . . . . . . . . . . . . . .31 6.29 9. Security Considerations . . . . . . . . . . . . . . . . . . .32 7.30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .34 8.32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . .35 8.1.33 11.1. Normative References . . . . . . . . . . . . . . . . . .35 8.2.33 11.2. Informative References . . . . . . . . . . . . . . . . .3533 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . .3735 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . .3836 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .3937 Intellectual Property and Copyright Statements . . . . . . . . . .4038 Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 2] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 1. Introduction The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support multihoming. It is an IP layer mechanism that hides multihoming from applications. A part of the SHIM6 solution involves detecting when a currently used pair of addresses (or interfaces) between two communication hosts has failed, and picking another pair when this occurs. We call the former failure detection, and the latter locator pair exploration. This document specifies the mechanisms and protocol messages to achieve both failure detection and locator pair exploration. This part of the SHIM6 protocol is called the REAchability Protocol (REAP). The document is structured as follows: Section 3 defines a set of useful terms, Section 4 gives an overview of REAP, and Section 5 specifies the message formats and behaviour in detail. Section69 discusses the security considerations of REAP. In this specification, we consider an address to be synonymous with a locator. Other parts of the SHIM6 protocol ensure that the different locators used by a node actually belong together. That is, REAP is not responsible for ensuring that it ends up with a legitimate locator. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 3] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 2. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 4] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 3. Definitions This section defines terms useful for discussing failure detection and locator pair exploration. 3.1. Available Addresses SHIM6 nodes need to be aware of what addresses they themselves have. If a node loses the address it is currently using for communications, another address must replace 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 The address is valid in the sense of RFC 2461 [RFC2461]. o The address is not tentative in the sense of RFC 2462 [RFC2462]. 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 [RFC4429] even though implementations may prefer using other addresses as long as there is an alternative. o The address is a global unicast, unique local address [RFC4193], or an unambiguous IPv6 link-local address. That is, it is not an IPv6 site-local address. Where IPv6 link-local addresses are used, their use needs to be unambiguous as follows. At most one link-local address may be used per node within the same connection between two peers. o The address and interface is acceptable for use according to a local policy. Available addresses are discovered and monitored through mechanisms outside the scope of SHIM6. SHIM6 implementations MUST be able to employ information provided by IPv6 Neighbor Discovery [RFC2461], Address Autoconfiguration [RFC2462], and DHCP[RFC3315].[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). Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 5] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 3.2. Locally Operational Addresses Two different granularity levels are needed for failure detection. The coarser granularity is for individual addresses: Definition. Locally Operational Address. An available address is said to be locally operational when its use is known to be possible locally: the interface is up, a default router (if needed) suitable for this address is known to be reachable, and no other local information points to the address being unusable. Locally operational addresses are discovered and monitored through mechanisms outside the SHIM6 protocol. SHIM6 implementations MUST be able to employ information provided from Neighbor Unreachability Detection [RFC2461]. Implementations MAY also employ additional, link layer specific mechanisms. Note 1: A part of the problem in ensuring that an address is operational is making sure that after a change in link layer connectivity we are still connected to the same IP subnet. Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6 [I-D.ietf-dna-protocol] can be used to ensure this. Note 2: In theory, it would also be possible for hosts to learn about routing failures for a particular selected source prefix, if only suitable protocols for this purpose existed. Some proposals in this space have been made, see, for instance [I-D.bagnulo-shim6-addr-selection] and [I-D.huitema-multi6-addr-selection], but none have been standardized to date. 3.3. Operational Address Pairs The existence of locally operational addresses are not, however, a guarantee that communications can be established with the peer. A failure in the routing infrastructure can prevent packets from reaching their destination. For this reason we need the definition of a second level of granularity, for pairs of addresses: Definition. Bidirectionally operational address pair. A pair of locally operational addresses are said to be an operational addresspair, iffpair when bidirectional connectivity can be shown between the addresses. That is, a packet sent with one of the addresses in the source field and the other in the destination field reaches the destination, and vice versa. Unfortunately, there are scenarios where bidirectionally operational address pairs do not exist. For instance, ingress filtering or Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 6] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 network failures may result in one address pair being operational in one direction while another one is operational from the other direction. The following definition captures this general situation: Definition. Unidirectionally operational address pair. A pair of locally operational addresses are said to be an unidirectionally operational addresspair, iffpair when packets sent with the first address as the source and the second address as the destination can be shown to reach the destination. SHIM6 implementations MUST support the discovery of operational address pairs through the use of explicit rechability tests and Forced Bidirectional Communication (FBD), described later in this specification. In addition, implementations MAY employ the following additional 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 [RFC2461]. In the case of unidirectional connectivity, the upper layer protocol responses come back using another address pair, but show that the messages sent using the first address pair have been received. o Negative feedback from upper layer protocols. It is conceivable that upper layer protocols give an indication of a problem to the multihoming layer. For instance, TCP could indicate that there's either congestion or lack of connectivity in the path because it is not getting ACKs. o ICMP error messages. Given the ease of spoofing ICMP messages, one should be careful to not trust these blindly, however. Our suggestion is to use ICMP error messages only as a hint to perform an explicit reachabilitytest,test or move an address pair to a lower place in the list of address pairs to be probed, 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, as explained by Gont in [I-D.ietf-tcpm-icmp-attacks]. These verifications can ensure that (practically) only on-path attackers can spoof the messages. Note SHIM6 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 trick others into redirecting traffic Arkko & van Beijnum Expires March 27, 2007 [Page 7] Internet-Draft Failure Detection Protocol September 2006 streams onto innocent victims. For a discussion of such attacks, see Aura et al [AURA02]. The test can at the same time work as a meansArkko & Beijnum Expires December 28, 2006 [Page 7] Internet-Draft Failure Detection Protocol June 2006to ensure that an address pair is operational, as discussed in Section 4.2. 3.4. Primary Address Pair The primary address pair consists of the ULID addresses that upper layer protocols use in their interaction with the SHIM6 layer. Use of the primary address pair means that the communication is compatible with regular non-SHIM6 communication and no context ID needs to be present. 3.5. Current Address Pair SHIM6 needs to avoid sending packets concurrently over multiple paths, because congestion control in commonly used transport protocols is based upon a notion of a single path. While routing can introduce path changes as well and transport protocols have means to deal with this, frequent changes will cause problems. Efficient congestion control over multible paths is a considered research at the time this specification is written. For these reasons it is necessary to choose a particular pair of addresses as the current address pair which is used until problems occur, at least for the same session. 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 address pair is operational. Nevertheless, it makes sense to assume that the address pair that worked in some time ago continues to be operational for new communications as well. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 8] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 4. Protocol Overview This section discusses the design of the reachability detection and address pair exploration mechanisms, and gives on overview of the REAP protocol. Exploring the full set of communication options between two hosts that both have two or more addresses is an expensive operation as the number of combinations to be explored increases very quickly with the number of addresses. For instance, with two addresses on both sides, there are four possible address pairs. Since we can't assume that reachability in one direction automatically means reachability for 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 operational. So it makes sense to have a light-weight protocol that confirms existing reachability, and only invoke heavier exploration 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 3.1 and Section 3.2 to be 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 is no longer in use, mechanism to relay that information is needed. The Update message in the SHIM6 protocol is used for this purpose [I-D.ietf-shim6-proto]. Finally, when the local and remote information indicates that communication should be possible and there are upper layer packets to be sent, reachability verification is necessary to ensure that the peers actually have an operational pair. A technique called Forced Bidirectional Detection (FBD, originally defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect]) is employed for the reachability verification. Reachability for the currently used address pair in a shim context is 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 acknowledgments or a REAP reachability keepalive if there is no other traffic. This way, it is no longer possible to have traffic in only one direction, so whenever there is Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page 9] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 data traffic going out, but there are no return packets, there must be a failure, so the full exploration mechanism is started. A more detailed description of the current pair reachability evaluation mechanism: 1.The base timing unitTo avoid the other side from concluding there is a reachability failure, it's necessary forthisa host implementing the failure detection mechanism to generate periodic keepalives when there isnamedno 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 10 seconds, the Keepalive Timeout.Until a negotiation mechanism(Mechanisms to negotiatedifferent values for this timer becomes available,an alternative Keepalive Timeout may be provided in the future.) The interval after which keepalives are sent is named Keepalive Interval. This document doesn't specify a value(3 seconds) specified in Section 5.5 SHOULDfor Keepalive Interval, but recognizes that an often used approach is sending keepalives at three times the timeout interval, which would beused.3 seconds here, and suggest a possible alternative of 4 seconds so that two keepalives are generated and have time to reach the correspondent. An upper bound would be 8 seconds, so that one keepalive has time to reach the other side, assuming a maximum one-way delay of 2 seconds. 2. Whenever outgoing data packets are generated, a timer is started to reflect the requirement that the peer should generate return traffic from data packets. For the purposes of this specification, "data packet" refers to any packet that is part of a shim context, including both upper layer protocol packets and SHIM6 protocol messages except those defined in this specification. 3. Whenever incoming data packets are received, the timer associated with the return traffic from the peer is stopped, and another timer is started to reflect the requirement for this node to generate return traffic. 4. The reception of a REAP keepalive packet leads to stopping the timer associated with the return traffic from the peer. 5. KeepaliveTimeoutInterval seconds after the last data packet has been received for a context, and if no other packet has been sent Arkko & van Beijnum Expires March 27, 2007 [Page 10] Internet-Draft Failure Detection Protocol September 2006 within this context since the data packet has been received, a REAP keepalive packet is generated for the context in question and transmitted to the correspondent. A host may send the keepalive sooner than KeepaliveTimeoutInterval seconds if implementation considerations warrantthis. The average time after whichthis, but should take care to avoid sending keepalivesare sent MUST beatleast Keepalive Timeout / 2 seconds.an excessive rate. After sending a single keepalive message, no additional keepalive messages are sent until a data packet is received within this shim context. Keepalives are not sent at all when a data packet was sent since the last received data packet. 6. Send Timeout seconds (10s;seconds; see Section5.5)8) after the transmission of a data packet with no return traffic on this context, a full reachability exploration is started.ThisNote that the above timeoutperiod is larger thanvalues are suggestions to be used as defaults. Experience from theKeepalive Timeoutdeployment of the SHIM6 protocol is needed in order toaccommodate for lost keepalives and regular variationsdetermine what values are most suitable. The setting of these values is also related to various parameters inround trip times. Arkko & Beijnum Expires December 28, 2006 [Page 10] Internet-Draft Failure Detection Protocol June 2006transport protocols, such as TCP keepalive interval. 4.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 communications can resume. What makes this process hard is the requirement to support unidirectionally operational address pairs. It is insufficient to probe address pairs by a simple request - response protocol. Instead, the party that first detects the problem starts a process where it tries each of the different address pairs in turn by sending a message to its peer. These messages carry information about the state of connectivity between the peers, such as whether the sender has seen any traffic from the peer recently. When the peer receives a message that indicates a problem, it assists the process by starting its own parallel exploration to the other direction, again sending information about the recently received payload traffic or signaling messages. Specifically, when A decides that it needs to explore for an alternative address pair to B, it will initiate a set of Probe messages, in sequence, until it gets an Probe message from B indicating that (a) B has received one of A's messages and, obviously, (b) that B's Probe message gets back to A. B uses the same algorithm, but starts the process from the reception of the first Arkko & van Beijnum Expires March 27, 2007 [Page 11] Internet-Draft Failure Detection Protocol September 2006 Probe message from A. Upon changing to a new address pair, the network path traversed most likely has changed, so that the ULP SHOULD be informed. This can be a signal for the ULP to adapt due to the change in path so that, for example, TCP could initiate a slow startprocedure.procedure, although it's likely that the circumstances that led to the selection of a new path already caused enough packet loss to trigger slow start. Similarly, one can also envision that applications would be able to tell the IP or transport layer that the current connection in unsatisfactory and an exploration for a better one would be desirable. This would require anAPIinter-layer communication mechanism to be developed, however. In any case, this is another issue that we treat as being outside the scope of pure address exploration. 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 9, the exploration process can typically be run only for a session that has already been established. Specifically, while REAP would in theory be capable of exploration even during connection establishment, its use within the SHIM6 protocol does not allow this. 4.3. Exploration Order The exploration process assumes an ability to choose address pairs for testing, in some sequence. This process may result in a combinatorial explosion when there are many addresses on both sides, but a back-off procedure is employed to avoid a "signaling storm".Arkko & Beijnum Expires December 28, 2006 [Page 11] Internet-Draft Failure Detection Protocol June 2006Nodes first consult the RFC 3484 default address selection rules [RFC3484] Section 4 rules to determine what combinations of addresses are allowed from a local point of view, as this reduces the search space. RFC 3484 also provides a priority ordering among different address pairs, 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].) Nodes may also use local information, such as known quality of service parameters or interface types to determine what addresses are preferred over others, and try pairs containing such addresses first. The SHIM6 protocol also carries preference information in its messages. Discussion note: The preferences may either be learned dynamically or be configured. It is believed, however, that dynamic learning based purely on the multihoming protocol is too hard and not the Arkko & van Beijnum Expires March 27, 2007 [Page 12] Internet-Draft Failure Detection Protocol September 2006 task this layer should do. Solutions where multiple protocols share their information in a common pool of locators could provide this information from transport protocols, however. Out of the set of possible candidate address pairs, nodes SHOULD attempt to test through all of them until an operational pair is found, and retrying the process as is necessary. However, all nodes MUST perform this process sequentially and with exponential back-off. This sequential process is necessary in order to avoid a "signaling storm" when an outage occurs (particularly for a complete site). However, it also limits the number of addresses that can in practice be used for multihoming, considering that transport and application layer protocols will fail if the switch to a new address pair takes too long. Section5.58 suggests default values for the timers associated with the exploration process. The value Initial Probe Timeout (0.5s)seconds) specifies the interval between initial attempts to send probes; Number of Initial Probes (4) specifies how many initial probes can be sent before the exponential backoff procedure needs to be employed. This processduplicatesincreases the time between every probe if there is no response. Typically, each increase doubles the time but this specification does not mandate a particular increase. Finally, MaxprobeProbe Timeout (60s)seconds) specifies a limit beyond which the probe interval may not grow. If the exploration process reaches this interval, it will continue sending at this rate until a suitable response is triggered or the SHIM6 context is garbagecollected. 4.4. Protocol Design REAP is designed as a modular part ofcollected, because upper layer protocols using the SHIM6 context in question are no longer attempting to send packets. Reaching thehopes that it may also be useful in other contexts. This document defines how it is carried within SHIM6, butMax Probe Timeout may also serve as a hint to theactual protocol messages are self- contained sogarbage collection process thatit could be carried by other protocols as well.the context is no longer usable. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page12]13] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 5. Protocol Definition 5.1. Keepalive Message TheREAP design allows performing both failure detection and address pair exploration informat of thesame sequencekeepalive 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 | Reserved |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Receiver Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header, Hdr Ext Len, 0, 0, Checksum These are as specified in Section 5.3 ofmessages, without a needthe SHIM6 protocol description [I-D.ietf-shim6-proto]. Type This field identifies the Probe message and MUST be set todesignate66 (Keepalive). Reserved This is aspecific point when the current address pair7-bit field reserved for future use. It isdeclared inoperationalset to zero on transmit, andthe search for a new pair begins.MUST be ignored on receipt. R This isuseful, as the loss ofasmall number of packets1-bit field reserved for future use. It isnot a proof that a problem exists. Integrated failure detection and exploration allows usset totest multiple address pairs simultaneously, including the current pair in case it becomes operational again. For instance, the exploration process can refer to keepalive message that succeeded in getting to the peer during the reachability testing phase. REAP also integrates a return routability function, making it unnecessary to perform another roundtrip before a newly discovered address canzero on transmit, and MUST betaken into use.ignored on receipt. Receiver Context Tag Thisdocument definesis aminimal set of parameters that are carried by47-bit field for themessages ofContext Tag theprotocol. Specifically, we have limitedreceiver has allocated for theparameters to those that are necessary to find an operational address pair. We notecontext. Arkko & van Beijnum Expires March 27, 2007 [Page 14] Internet-Draft Failure Detection Protocol September 2006 Options This MAY contain one or more SHIM6 options.The inclusion of the latter options is not necessary, however, as theremay be extensionsare currently no defined options that areneededuseful inthe futurea Keepalive message. These options are provided only forvarious reasons, such as the desirefuture extensibility reasons. A valid message conforms tosupport load balancing or finding best pairs. An optionthe format above, hasbeen specifieda Receiver Context Tag that matches toallow this. 4.5. Example Protocol Runs This section has examples of REAP protocol runs in typical scenarios. We start withcontext known by thesimplest scenarioreceiver, is valid shim control message as defined in Section 12.2 oftwo hosts, Athe SHIM6 protocol description [I-D.ietf-shim6-proto], andB,its shim context state is ESTABLISHED. The receiver processes a valid message by inspecting its options, and executing any actions specified for such options. Discussion: It may appear prudent to include additional fields thathavewould provide at least aSHIM6 connection with each otherbasic level of security, butare not currently sending any data. As neither side sends anything, theysince data packets alsodo not expect anything back, soindicate ongoing reachability, just as keepalives, and those packets don't have such fields, thereareis little or nomessages at all: EXAMPLE 1: No communications Peer A Peer Breason to include them in a keepalive. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Precvd| Psent |Sta| Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + First probe sent + | | + Source address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |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 & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page13]15] Internet-Draft Failure Detection ProtocolJuneSeptember 2006EXAMPLE 2: Bidirectional communications Peer A Peer B+ First probe sent + | | + Destination address + |payload packet||-------------------------------------------->|+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |payload packetFirst probe nonce ||<--------------------------------------------|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First probe option | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Nth probe sent / |payload packet||-------------------------------------------->|+ Source address + | | + + | |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: EXAMPLE 3: Unidirectional communications Peer A Peer B+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nth probe sent + |payload packet||-------------------------------------------->|+ Destination address + | | + + |payload packet||-------------------------------------------->|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nth probe nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |payload packetNth probe option ||-------------------------------------------->|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + First probe received + |Keepalive id=p||<--------------------------------------------|+ Source address + | | + + |payload packet||-------------------------------------------->|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + First probe received + | |The next example involves a failure scenario. Here A has addresses A1 and A2 and B has addresses B1 and B2. The currently used+ Destination addresspairs are (A1, B1) and (B1, A1). The first of these becomes broken, which leads to an exploration process: EXAMPLE 4: Failure scenario+ | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First probe nonce | Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page14]16] Internet-Draft Failure Detection ProtocolJuneSeptember 2006Peer A Peer B | | | (A1,B1) payload packet | |-------------------------------------------->| | | | (B1,A1) payload packet | |<--------------------------------------------| Time T1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First probe option |Path A1->B1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(A1,B1) payload packet|is now |----------------------------------------/+ Nth probe received + |broken| + Source address + | |(B1,A1) payload packet+ + ||<--------------------------------------------|| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |(A1,B1) payload packet+ Nth probe received + ||----------------------------------------/| + Destination address + | | + + |(B1,A1) payload packet||<--------------------------------------------|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nth probe nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(A1,B1) payload packetNth probe option ||----------------------------------------/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |10 seconds after| + Options + |T1, sends a com-|(B1,A1)+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header, Hdr Ext Len, 0, 0, Checksum These are as specified in Section 5.3 of the SHIM6 protocol description [I-D.ietf-shim6-proto]. Type This field identifies the Probeid=p, | plaint that | iseeyou=no | it is not rec- |<--------------------------------------------| eiving anything | | A realizes | that it needs | to start the | exploration | | | | (A1, B1) Probe id=q, | | iseeyou=yes | | payload reception rep | | probe reception rep(p) | But it gets lost |-------------------------------------/ | due to broken path | | Retransmission |message and MUST be set toa different | address | | | | (A1, B2) Probe id=r, | | iseeyou=yes | | payload reception rep | | probe reception rep(p) |67 (Probe). Reserved Thisone getsis a 7-bit field reserved for future use. It is set to zero on transmit, and MUST be ignored on receipt. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page15]17] Internet-Draft Failure Detection ProtocolJuneSeptember 2006|-------------------------------------------->| through. Note | | that B would also | | have retransmitted | | soon, but in this | | example A got | | through first | | | | | | B now knows | | that A has no | (B1,A1) Probe id=p, | problemR This is a 1-bit field reserved for future use. It is set toreceive | iseeyou=yes, | its packetszero on transmit, and| probe reception rep(r) |MUST be ignored on receipt. Receiver Context Tag Thisone gets |<--------------------------------------------| that A has found | |is anew path to B | | | (A1,B2) payload packet | |-------------------------------------------->| Payload packets | | flow again | (B1,A1) payload packet | |<--------------------------------------------| The next example shows when47-bit field for thefailureContext Tag the receiver has allocated for thecurrent locator paircontext. Psent This isina 4-bit field that indicates theother direction: Arkko & Beijnum Expires December 28, 2006 [Page 16] Internet-Draft Failure Detection Protocol June 2006 EXAMPLE 5: One-way failure Peer A Peer B | | | (A1,B1) payload packet | |-------------------------------------------->| | | | (B1,A1) payload packet | | /-----------------------------------------| Time T1 | | Path B1->A1 | | is now | | broken | (B1,A1) payload packet | | /-----------------------------------------| | | | (B1,A1) payload packet | | /-----------------------------------------| | | | | 10 seconds after | | T1, sends a com- | (B1,A1) Probe id=p, | plaint that | iseeyou=no | it is not rec- | /-----------------------------------------| eiving anything | | | (B2,A2) Probe id=q, | | iseeyou=no | Next try different |<--------------------------------------------| locator pair | | | (A2, B2) Probe id=r, | | iseeyou=yes | | payload reception rep | | probe reception rep(q) | This one gets |-------------------------------------------->| through | | | | | | B now knows | | that A has no | (B2,A2) Probe id=s, | problem to receive | iseeyou=yes, | its packets and | probe reception rep(r) | This one gets |<--------------------------------------------| that A has found | | a new path to B | | | (A2,B2) payload packet | |-------------------------------------------->| Payload packets | | flow again | (B2,A2) payload packet | |<--------------------------------------------| Arkko & Beijnum Expires December 28, 2006 [Page 17] Internet-Draft Failure Detection Protocol June 2006 In the next case we have even less luck. The response to the REAP probe doesn't make it in the reverse direction, so both ends end up exploring independently: EXAMPLE 6: Independent exploration Peer A Peer B | | | (A1,B1) payload packet | |-------------------------------------------->| | | | (B1,A1) payload packet | | /-----------------------------------------| Time T1 | | Path B1->A1 | | is now | | broken | (B1,A1) payload packet | | /-----------------------------------------| | | | (B1,A1) payload packet | | /-----------------------------------------| | | | | 10 seconds after | | T1, sends a com- | (B1,A1) Probe id=p, | plaint that | iseeyou=no | it is not rec- | /-----------------------------------------| eiving anything | | | (B2,A2) Probe id=q, | | iseeyou=no | Next try different |<--------------------------------------------| locator pair | | A now knows that it needs | to start exploring | | | | (A2, B2) Probe id=r, | | iseeyou=yes | | payload reception rep | | probe reception rep(q) | |--------------------------------------/ | Doesn't make it | | | (A1, B1) Probe id=s, | | iseeyou=yes | | payload reception rep | | probe reception rep(q) | This one gets |-------------------------------------------->| through | | | | Arkko & Beijnum Expires December 28, 2006 [Page 18] Internet-Draft Failure Detection Protocol June 2006 | | B now knows | | that A has no | (B2,A2) Probe id=t, | problem to receive | iseeyou=yes, | its packets and | probe reception rep(r) | This one gets |<--------------------------------------------| that A has found | | a new path to B | | | (A1,B1) payload packet | |-------------------------------------------->| Payload packets | | flow again | (B2,A2) payload packet | |<--------------------------------------------| 4.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 6, the exploration process can typically be run only for a session that has already been established. Specifically, while REAP would in theory be capable of exploration even during connection establishment, its use within the SHIM6 protocol does not allow this. Arkko & Beijnum Expires December 28, 2006 [Page 19] Internet-Draft Failure Detection Protocol June 2006 5. Protocol Definition 5.1. Keepalive Message The format of the keepalive message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len |0| Type = 66 | Reserved |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum |R| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Receiver Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header This value MUST be set to NO_NXT_HDR (59). Hdr Ext Len This is an 8-bit unsigned integer field, calculated as specified in Section 5.3 of the SHIM6 protocol description [I-D.ietf-shim6-proto]. Type This field identifies the Probe message and MUST be set to 66 (Keepalive). Reserved This is a 7-bit field reserved for future use. It is set to zero on transmit, and MUST be ignored on receipt. R This is a 1-bit field reserved for future use. It is set to zero on transmit, and MUST be ignored on receipt. Arkko & Beijnum Expires December 28, 2006 [Page 20] Internet-Draft Failure Detection Protocol June 2006 Checksum This is a 16-bit field, calculated as specified in Section 5.3 of the SHIM6 protocol description [I-D.ietf-shim6-proto]. Receiver Context Tag This is a 47-bit field for the Context Tag the receiver has allocated for the context. Options This MUST contain at least the Keepalive option and MAY contain one or more Reachability options.The inclusion of the latter options is not necessary, however, as there are currently no defined options that are useful in a Keepalive message. These options are provided only for future extensibility reasons. A valid message conforms to the format above, has a Receiver Context Tag that matches to context known by the receiver, is valid shim control message as defined in Section 12.2 of the SHIM6 protocol description [I-D.ietf-shim6-proto], and its shim context state is ESTABLISHED. The receiver processes a valid message by inspecting its options, and executing any actions specified for such options. The processing rules for this message are the given in more detail in Section 5.4. 5.1.1. Keepalive Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This value MUST be set to 10 (Keepalive Option). 0 This value MUST be set to 0, as in other SHIM6 options. Arkko & Beijnum Expires December 28, 2006 [Page 21] Internet-Draft Failure Detection Protocol June 2006 Length This is the length of the option and MUST be calculated as specified in Section 5.14 of the SHIM6 protocol description [I-D.ietf-shim6-proto]. Res This 4-bit reserved field MUST be set to zero when sending, and ignored on receipt. Identifier This 28-bit field identifies this particular instance of an Keepalive message. This value SHOULD be generated using a random number generator that is known to have good randomness properties as outlined in RFC 1750 [RFC1750]. Upon reception, Identifier values from both Keepalive and Probe messages may be copied onto Probe Reception Report options. This allows them to be used for both identifying which packets were received as well as for performing a return routability test. The processing rules for this option are the given in more detail in Section 5.4. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header This value MUST be set to NO_NXT_HDR (59). Arkko & Beijnum Expires December 28, 2006 [Page 22] Internet-Draft Failure Detection Protocol June 2006 Hdr Ext Len This is an 8-bit unsigned integer field, calculated as specifiednumber of sent probes included inSection 5.3this probe message. The first set of probe fields pertains to theSHIM6 protocol description [I-D.ietf-shim6-proto]. Type This field identifies the Probecurrent message and MUST beset to 67 (Probe). Reserved This is a 7-bit field reservedpresent, so the minimum value forfuture use. It is set to zero on transmit, and MUST be ignored on receipt. R This is a 1-bitthis fieldreserved for future use. Itisset to zero on transmit,1. Additional sent probe fields are copies of the same fields sent in (recent) earlier probes andMUSTmay beignored on receipt. Checksum This is a 16-bit field, calculatedincluded or omitted asspecified in Section 5.3 ofper any logic employed by theSHIM6 protocol description [I-D.ietf-shim6-proto]. Receiver Context Tagimplementation. Precvd This is a47-bit4-bit fieldfor the Context Tagthat indicates thereceiver has allocated fornumber of received probes included in this probe messsage. Received probe fields are copies of thecontext. Options This MUST contain at leastsame fields received in (recent) earlier probes and may be included or omitted as per any logic employed by theProbeimplementation. The fields probe source, probe destination, probe nonce and probe option may be repeated, depending on the value of Psent andMAY contain one or more Reachability options. A valid message conformsPreceived. Sta (State) This 2-bit State field is used to inform theformat above, has a Receiver Context Tag that matches to a context known bypeer about thereceiver, is valid shim control message as defined in Section 12.2state of theSHIM6 protocol description [I-D.ietf-shim6-proto], and its shim context state is ESTABLISHED. The receiver processes a valid message by inspecting its options,sender. It has three legal values: 0 (Operational) implies that the sender both (a) believes it has no problem communicating andexecuting(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 anyactions specified such options. This includestraffic from theSHIM6 Probe option found withinrecipient even when it expected some. 2 (ExploringOk) implies that theoptions. The processing rules for this message aresender believes it has no problem communicating, but that thegiven in more detail in Section 5.4.recipient either has a problem or has not yet confirmed the sender that the problem has been solved. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page23]18] Internet-Draft Failure Detection ProtocolJuneSeptember 20065.2.1. Probe 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 = 11 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Y| Res | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This valueReserved2 MUST be set to11 (Probe Option).0This value MUST be set to 0, as in other SHIM6 options. Length This is the length of the optionupon transmission and MUST becalculated as specified in Section 5.14 of the SHIM6 protocol description [I-D.ietf-shim6-proto]. Y (The "I See You" flag)ignored upon reception. Probe source Thisflag is set128-bit field contains the source IPv6 address used to1 ifsend thesender receives either payload packets or REAP messages fromprobe. Probe destination This 128-bit field contains thepeer, and 0 otherwise. The determination of whendestination IPv6 address used to send thesender receives somethingprobe. Probe nonce This ismade duringa 32-bit field that is initialized by thelast Send Timeout seconds (see Section 5.5) when traffic was expected, i.e., when there was either payload traffic or REAP messages. Upon reception,sender with a valueof 1 indicatesthat allows it to determine which sent probes a received probe correlates with. It is highly recommeded that thereceiver does not neednonce field is at least moderately hard tochange its behaviour asguess so that even on-path attackers can't deduce thesender is already seeing its packets. Anext nonce valueof 0 indicatesthatthe receiver MUST explore different outgoing address pairs. Res This 3-bit reserved field MUSTwill beset to zero when sending, and ignored on receipt. Identifier This 28-bit field identifies this particular instance of an Probe message.used. This value SHOULD be generated using a random number generator that is known to have good randomnessproperties. Upon Arkko & Beijnum Expires December 28, 2006 [Page 24] Internet-Draft Failure Detection Protocol June 2006 reception, Identifier values are copied onto Probe Reception Report options. This allows them to be used for both identifying which Probes were received as wellproperties asfor performing a return routability test. The processing rules for this option are the given in more detail in Section 5.4. 5.3. Reachability Option Additional information can be includedoutlined inKeepalive andRFC 1750 [RFC1750]. Probemessages by the inclusion of the Reachability Options. Their 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Option Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This value MUST be set to 12 (Reachability option). 0 This value MUST be set to 0, as in other SHIM6 options. Lengthoption This isthe length of thea 32-bit field with no fixed meaning. The probe optionand MUST be calculated as specified in Section 5.14 of the SHIM6 protocol description [I-D.ietf-shim6-proto]. Option Type This value identifies the option. Option Data Option-specific content. Unrecognized options MUST be ignored upon receipt. All implementations MUST support the options defined infield is copied back with no changes. Future flags may define a use for this field. Discussion: One potential use of this field relates to communicating delays between reception of a probe and transmission of a reply to it. Options For future extensions. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page25]19] Internet-Draft Failure Detection ProtocolJuneSeptember 2006specification,6. Behaviour The required behaviour of REAP nodes is specified below in the form of a state machine. The externally observable behaviour of an implementation MUST conform to this state machine, but there is no requirement that the implementation actually employs a state machine. Intermixed with the following description we also provide a state machine description in a tabular form. That form is only informational, however.5.3.1. Payload Reception Report This option SHOULDOn a given context with a given peer, the node can beincludedinall Probe messages whenone of three states: Operational, Exploring, or ExploringOK. In thesenderOperational state the underlying address pairs are assumed to be operational. In the Exploring state this node hasrecently (withinobserved a problem and has currently not seen any traffic from the peer. Finally, in the ExploringOK state this node sees traffic from the peer, but peer may not yet see any traffic from this node so that the exploration process needs to continue. The node maintains also thelastSend timer (Send Timeout seconds)receivedand Keepalive timer (Keepalive Timeout seconds). The Send timer reflects the requirement that when this node sends a payload packet there should be some return traffic (either payload packetsfromor Keepalive messages) within Send Timeout seconds. The Keepalive timer reflects the requirement that when this node receives a payload packet there should a similar response towards the peer.Its formatThe Keepalive timer isas follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type = 1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Suboptions ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, 0,only used within the Operational state, andLength These are as specified above. Reserved Thisthe Send timer in the Operational and ExploringOK states. No timer is running in the Exploring state. Upon the reception of a16-bit field reserved for future use. Itpayload packet in the Operational state, the node starts the Keepalive timer if it isset to zero on transmit,not yet running, andMUST be ignored on receipt. Suboptions This fieldstops the Send timer if it was running. If the node isreserved for possible future Reachability options that are carried (recursively) within this option. Unrecognized options MUST be ignored upon receipt. Currently there are no defined options that can be carried here. 5.3.2. Probe Reception Report This option MUST be includedinanythe Exploring state it transitions to the ExploringOK state, sends a Probemessage whenmessage, and starts thesender has recently (withinSend timer. In the ExploringOK state the node stops thelastSendTimeout seconds) received Probe or Keepalivetimer if it was running, but does not do anything else. The reception of SHIM6 control messagesfromother than thepeer. Depending on MTUKeepalive andtiming considerations,Probe messages are treated similarly with payload packets. When sending a Probe message, thesender MAY, however, include options for only someState field MUST be set to a value that matches the conceptual state of thereceived Probe messages. All implementations MUST supportsender after sendingof at least five such options, however. The format of this option is as follows:the Probe. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page26]20] Internet-Draft Failure Detection ProtocolJuneSeptember 20060 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 |0| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type = 2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Suboptions ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type, 0,1. EVENT: Incoming payload packet ================================= Operational Exploring ExploringOk ------------------------------------------------------------- STOP Send; SEND Probe ExploringOk; STOP Send START Keepalive START Send; GOTO ExploringOk Upon sending a payload packet in the Operational state, the node stops the Keepalive timer if it was running andLength These are as specified above. Option Type This value identifiesstarts theoptionSend timer if it was not running. In the Exploring state there is no effect, andMUST be set to 2 (Probe Reception Report). Reserved Thisin the ExploringOK state the node simply starts the Send timer if it was not yet running. (The sending of SHIM6 control messages is again treated similarly here.) 2. EVENT: Outgoing payload packet ================================= Operational Exploring ExploringOk ----------------------------------------------------------- START Send; - START Send STOP Keepalive Upon a16-bit field reserved for future use. It is set to zero on transmit, and MUST be ignoredtimeout onreceipt. Resthe Keepalive timer the node sends a Keepalive message. Thisiscan only happen in the Operational state. 3. EVENT: Keepalive timeout Operational Exploring ExploringOk ----------------------------------------------------------- SEND Keepalive - - Upon a3-bit field reserved for future use. It is set to zero on transmit, and MUST be ignoredtimeout onreceipt. Identifier This 32 bit field carriestheidentifier ofSend timer, theProbe message thatnode enters the Exploring state, sends a Probe, and stops the Keepalive timer if it wasrecently received. Suboptions This field is reserved for possible future Reachability options that are carried (recursively) within this option. Unrecognized options MUST be ignored upon receipt. Currently there are no defined options that can be carried here. 5.4. Behaviour The required behaviour of REAP nodes is specified belowrunning. 4. EVENT: Send timeout ====================== Operational Exploring ExploringOk ----------------------------------------------------------- SEND Probe Exploring; - SEND Probe Exploring; STOP Keepalive; GOTO Exploring GOTO Exploring While in theform of aExploring statemachine. The externally observable behaviour of an implementation MUST conformthe node keeps retransmitting its Probe messages tothis state machine, but there is nodifferent (or same) addresses as defined in Section 4.3. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page27]21] Internet-Draft Failure Detection ProtocolJuneSeptember 2006requirement thatA similar process is employed in theimplementation actually employs a state machine. Intermixed withExploringOk state, except that upon such retransmission thefollowing description we also provide a state machine description in a tabular form. That formSend timer isonly informational, however. On a given context with a given peer,started if it was not running already. 5. EVENT: Retransmission ======================== Operational Exploring ExploringOk ---------------------------------------------------------- - SEND Probe Exploring SEND Probe ExploringOk START Send Upon thenode can be in onereception ofthree states: Operational, Exploring, or ExploringOK. Ina Keepalive message in the Operationalstatestate, theunderlying address pairs are assumed to be operational. Innode stops the Send timer, if it was running. If the node is in the Exploring statethis node has observedit transitions to the ExploringOK state, sends aproblemProbe message, andhas currently not seen any traffic fromstarts thepeer. Finally, inSend timer. In the ExploringOK statethis node sees traffic from the peer, but peer may not yet see any traffic from this node so that the exploration process needs to continue. The node maintains alsothe Sendandtimer is stopped, if it was running. 6. EVENT: Reception of the Keepalivetimers. Themessage ============================================ Operational Exploring ExploringOk ----------------------------------------------------------- STOP Sendtimer reflectsSEND Probe ExploringOk; STOP Send START Send; GOTO ExploringOk Upon receiving a Probe with State set to Exploring, therequirement that when thisnode enters the ExploringOK state, sends apayload packet there should be some return traffic (either payload packets or Keepalive messages) within Send Timeout seconds. TheProbe, stops the Keepalive timerreflectsif it was running, and restarts therequirement that when this node receivesSend timer. 7. EVENT: Reception of the Probe message State=Exploring ======================================================== Operational Exploring ExploringOk ----------------------------------------------------------- SEND Probe ExploringOk; SEND Probe ExploringOk; SEND Probe STOP Keepalive; START Send; ExploringOk; RESTART Send; GOTO ExploringOk RESTART Send GOTO ExploringOk Upon the reception of apayload packet there shouldProbe message with State set to ExploringOk, the node sends asimilar response towardsProbe message, restarts the Send timer, stops thepeer. TheKeepalive timeris only used within the Operational state,if it was running, and transitions to theSend timer inOperational state. Arkko & van Beijnum Expires March 27, 2007 [Page 22] Internet-Draft Failure Detection Protocol September 2006 8. EVENT: Reception of the Probe message State=ExploringOk ========================================================== Operational Exploring ExploringOk ------------------------------------------------------------- SEND Probe Operational; SEND Probe Operational; SEND Probe RESTART Send; RESTART Send; Operational; STOP Keepalive GOTO Operational RESTART Send; GOTO Operationaland ExploringOK states. No timer is running in the Exploring state.Upon the reception of apayload packet in the Operational state,Probe message with State set to Operational, the node stops the Send timer if it was running, starts the Keepalive timer if itiswas not yet running, andstopstransitions to theSend timer if it was running. IfOperational state. Note: This terminates thenodeexploration process when both parties are happy and know that their peer isinhappy as well. 9. EVENT: Reception of the Probe message State=Operational ========================================================== Operational Exploringstate it transitionsExploringOk ----------------------------------------------------------- STOP Send STOP Send; STOP Send; START Keepalive START Keepalive START Keepalive GOTO Operational GOTO Operational The reachability detection and exploration process has no effect on payload communications until a new operational address pairs have actually been confirmed. Prior to that theExploringOK state, sendspayload packets continue to be sent to the previously used addresses. 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. Arkko & van Beijnum Expires March 27, 2007 [Page 23] Internet-Draft Failure Detection Protocol September 2006 7. 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 aProbe messageSHIM6 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 Peer A Peer B | | | | | | | | | | | | | | | | Our second example involves an active connection with bidirectional payload packet flows. Here theI See You flag set to 1 (Yes), and starts the Send timer. In the ExploringOK state the node stops the Send timer if it was running, but does not do anything else. Thereception ofSHIM6 control messages other thandata from theKeepalive and Probe messagespeer is taken as an indication of reachability, so again there aretreated similarly withno extra packes: EXAMPLE 2: Bidirectional communications Peer A Peer B | | | payloadpackets. 1. EVENT: Incomingpacket | |-------------------------------------------->| | | | payload packet================================= Operational Exploring ExploringOk ------------------------------------------------------------- STOP Send; SEND Probe Y=Yes; STOP Send START Keepalive START Send; GOTO ExploringOk Upon sending a| |<--------------------------------------------| | | | payload packetin the Operational state, the node stops the Keepalive timer if it was running and starts the Send timer if it was not running. In the Exploring state there| |-------------------------------------------->| | | | | The third example isno effect, and intheExploringOK state the node simply startsfirst one that involves an actual REAP message. Here theSend timer if it was not yet running. (The sending of SHIM6 controlhosts communicate in just one direction, so REAP messagesisare needed to indicate to the peer that sends payload packets that its packets are getting through: Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page28]24] Internet-Draft Failure Detection ProtocolJuneSeptember 2006again treated similarly here.) 2. EVENT: OutgoingEXAMPLE 3: Unidirectional communications Peer A Peer B | | | payload packet | |-------------------------------------------->| | | | payload packet | |-------------------------------------------->| | | | payload packet================================= Operational Exploring ExploringOk ------------------------------------------------------------- START Send; - START Send STOP Keepalive Upon a timeout on the Keepalive timer the node sends a Keepalive message. This can only happen in the Operational state. 3. EVENT: Keepalive timeout Operational Exploring ExploringOk ------------------------------------------------------------- SEND| |-------------------------------------------->| | | | Keepalive- - Uponid=p | |<--------------------------------------------| | | | payload packet | |-------------------------------------------->| | | | | The next example involves atimeout on the Send timer, the node enters the Exploring statefailure scenario. Here A has addresses A andsends a Probe with I See You set to 0 (No)B has addresses B1 andstops the Keepalive timer if it was running. 4. EVENT: Send timeout ====================== Operational Exploring ExploringOk ------------------------------------------------------------- SEND Probe Y=No; - SEND Probe Y=No STOP Keepalive; GOTO Exploring GOTO Exploring While in the Exploring state the node keeps retransmitting its Probe messagesB2. The currently used address pairs are (A, B1) and (B1, A). All connections via B1 become broken, which leads todifferent (or same) addresses as defined in Section 4.3.an exploration process: EXAMPLE 4: Failure scenario Peer Asimilar process is employed in the ExploringOk state, except that upon such retransmission the Send timer is started if it was not running already. 5. EVENT: Retransmission ========================Peer B | | State: | State: OperationalExploring ExploringOk ------------------------------------------------------------- - SEND Probe Y=No SEND Probe Y=Yes START Send Upon the reception of a Keepalive message in the| Operationalstate, the node stops the Send timer, if it was running. If the node is in| (A,B1) payload packet | |-------------------------------------------->| | | | (B1,A) payload packet | |<--------------------------------------------| At time T1 | | path A<->B1 | (A,B1) payload packet | becomes |----------------------------------------/ | broken | | | ( B1,A) payload packet | | /-----------------------------------------| | | | (A,B1) payload packet | |----------------------------------------/ | | | | (B1,A) payload packet | Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page29]25] Internet-Draft Failure Detection ProtocolJuneSeptember 2006the Exploring state it transitions to the ExploringOK state,| /-----------------------------------------| | | | (A,B1) payload packet | |----------------------------------------/ | | | | | | | 10 seconds after | (B1,A) Probe id=p, | T1, sends aProbe message with the I See You flag set to 1 (Yes), and starts the Send timer. In the ExploringOK state the Send timer is stopped, ifcom- | state=exploring | plaint that | /-----------------------------------------| itwas running. 6. EVENT: Reception of the Keepalive message ============================================ Operationalis not rec- | | eiving anything | | State: | | ExploringExploringOk ------------------------------------------------------------- STOP Send SEND Probe Y=Yes; STOP Send START Send; GOTO ExploringOk Upon receiving a| | | (B2,A) Probewith I See You setid=q, | | state=exploring | But its lost, |<--------------------------------------------| retransmission | | uses another pair A realizes | that it needs | to0 (No) the node entersstart theExploringOK state, sends a Probe with I See You set to 1 (Yes), stops| exploration. It | picks B2 as theKeepalive timer if| most likely candidate, | as itwas running, and restarts the Send timer. 7. EVENT: Reception ofappeared in the | Probemessage with Y=No ================================================== Operational Exploring ExploringOk ------------------------------------------------------------- SEND Probe Y=Yes SEND Probe Y=Yes; SEND Probe Y=Yes; STOP Keepalive; START Send; RESTART Send RESTART Send; GOTO ExploringOk GOTO| State: ExploringOkThe behavior upon the reception of a Probe message with I see You set to 1 (Yes) depends on whether it contains a Probe Reception Report that refers to a| | | | (A, B2) Probe id=r, | | state=exploringok, | | received probe q | This one gets |-------------------------------------------->| through. | | State: | | Operational | | | | | (B2,A) Probe id=s, | | state=operational, | B now knows | received probe r | thatthis nodeA hassentno |<--------------------------------------------| problem to receive | | its packets State: Operational | | | | (A,B2) payload packet | |-------------------------------------------->| Payload packets | | flow again | (B2,A) payload packet | |<--------------------------------------------| Arkko & van Beijnum Expires March 27, 2007 [Page 26] Internet-Draft Failure Detection Protocol September 2006 The next example shows when thepeer such thatfailure for theI See You was set to 1current locator pair is inthat message. If it does, the node sends a Probe message with I See You set to 1 (Yes), restarts the Send timer, stopstheKeepalive timer if it was running,other direction only. A has addresses A1 andtransitions to theA2, 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 Peer A Peer B | | State: | State: Operationalstate. 8. EVENT: Reception of the Probe message with Y=Yes (peer reports not seeing yet a| Operational | | | (A1,B1) payload packet | |-------------------------------------------->| | | | (B1,A1) payload packet | |<--------------------------------------------| | | | (A1,B1) payload packet | At time T1 |----------------------------------------/ | path A1->B1 | | becomes | | broken | (B1,A1) payload packet | |<--------------------------------------------| | | | (A1,B1) payload packet | |----------------------------------------/ | | | | (B1,A1) payload packet | |<--------------------------------------------| | | | (A1,B1) payload packet | |----------------------------------------/ | | | | | 10 seconds after | (B1,A1) Probewith Y=Yes) ========================================================== Operationalid=p, | T1, B sends a com- | state=exploring | plaint that |<--------------------------------------------| it is not rec- | | eiving anything A responds | State: Exploring State: ExploringOk------------------------------------------------------------- SEND Probe Y=Yes; SEND Probe Y=Yes; SEND Probe Y=Yes; RESTART Send; RESTART Send; RESTART Send; STOP Keepalive GOTO Operational GOTO Operational If there was no such| | | | (A1, B1) ProbeReception Report, the stops the Send timerid=q, | | state=exploringok, | | received payload, | | received probe q | |----------------------------------------/ | But A's response | | is lost Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page30]27] Internet-Draft Failure Detection ProtocolJuneSeptember 2006if it was running, starts the Keepalive timer if it was not yet running, and transitions to the Operational state. Note: This check is necessary in order to terminate the exploration process when both parties are happy and know that their peers are happy as well. 9. EVENT: Reception of the| (B2,A2) Probemessage with Y=Yes (peer reports seeing aid=r, | | state=exploring | Next try different |<--------------------------------------------| locator pair | | | (A2, B2) Probewith Y=Yes) =================================================== Operational Exploring ExploringOk ------------------------------------------------------------- STOP Send STOP Send; STOP Send; START Keepalive START Keepalive START Keepalive GOTO Operational GOTOid=s, | | state=exploringok, | | received payload, | | received probes p, r | This one gets |-------------------------------------------->| through | | State: OperationalThe reachability detection and exploration process| | | | B now knows | | that A has noeffect on payload communications until a new operational address pairs have actually been confirmed. Prior to that the payload packets continue to be sent to the previously used addresses. Garbage collection of SHIM6 contexts terminates contexts| (B2,A2) Probe id=t, | problem to receive | state=operational, | its packets, and | received probe s | thatare either unused or have failed dueA's probe |<--------------------------------------------| gets tothe inability of the exploration processB. It | | sends a State: Operational | confirmation tofind an operational pair. In the PDF version of this specification, an informational drawing illustrates the state machine. Where the text and the drawing differ, the text takes precedence. 5.5.A | | | (A2,B2) payload packet | |-------------------------------------------->| Payload packets | | flow again | (B1,A1) payload packet | |<--------------------------------------------| Arkko & van Beijnum Expires March 27, 2007 [Page 28] Internet-Draft Failure Detection Protocol September 2006 8. Protocol Constants The following protocol constants are defined: Send Timeout 10 seconds KeepaliveTimeout 3 secondsInterval Not specified here Initial Probe Timeout 0.5 seconds Number of Initial Probes 4 probes Max Probe Timeout 60 seconds Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page31]29] Internet-Draft Failure Detection ProtocolJuneSeptember 20066.9. Security Considerations Attackers may spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not operational. For example, attackers may spoof ICMP error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof information related to network attachments, router discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when in reality they do not. This may cause use of non-preferred addresses or even denial-of- service. This protocol does not provide any protection of its own for indications from other parts of the protocol stack. Unprotected indications SHOULD NOT be taken as a proof of connectivity problems. However, REAP has weak resistance against incorrect information even from unprotected indications in the sense that it performs its own tests prior to picking a new address pair. Denial-of- service vulnerabilities remain, however, as do vulnerabilities against on path attackers. Some aspects of these vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link layer security, or the use of SEND [RFC3971] to protect IPv6 Router and Neighbor Discovery. Other parts of the SHIM6 protocol ensure that the set of addresses we are switching between actually belong together. REAP itself provides no such assurances. Similarly, REAP provides only minimal protection against third party flooding attacks; when REAP is run its Probe identifiers can be used as a return routability check that the claimed address is indeed willing to receive traffic. However, this needs to be complemented with another mechanism to ensure that the claimed address is also the correct host. SHIM6 does this by performing binding of all operations to context tags. The keepalive mechanism in this specification is vulnerable to spoofing. On path-attackers that can see a SHIM6 context tag can send spoofed Keepalive messages once per Send Timeout interval, to prevent two SHIM6 nodes from sending Keepalives themselves. This vulnerability is only relevant to nodes involved in a one-way communication. The result of the 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 Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page32]30] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 able to generate spoofed results, given that the context tags are 47- bit random numbers. 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 layer, it is not possible to protect the exploration phase against on-path attackers. This is similar to the ability to protect other Shim6 control exchanges. There are mechanisms in place to prevent the redirection of communications to wrong addresses, but on-path attackers can cause denial-of-service, move communications to less-preferred address pairs, and so on. Finally, the exploration itself can cause a number of packets to be sent. As a result it may be used as a tool for packet amplification in flooding attacks. In order to prevent this it is required that the protocol employing REAP has built-in mechanisms to prevent this. For instance, in SHIM6 contexts are created only after a relatively large number of packets has been exchanged, a cost which reduces the attractiveness of using SHIM6 and REAP for amplification attacks. However, such protections are typically not present at connection establishment time. When exploration would be needed for connection establishment to succeed, its usage would result in an amplification vulnerability. As a result, SHIM6 does not support the use of REAP in connection establishment stage. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page33]31] Internet-Draft Failure Detection ProtocolJuneSeptember 20067.10. IANA ConsiderationsThis document creates one new name spaces under the new SHIM6 Reachability Protocol repository. The name space is for Reachability Option Type (Section 5.3) and it has one reserved value (0) and two defined values, 1 (Payload Reception Report defined in Section 5.3.1) and 2 (Probe Reception Report defined in Section 5.3.2). Further allocations within this 16-bit field can be made through Specification Required. The range from 65000 to 65535 is reserved for experimental use.No IANA actions are required. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page34]32] Internet-Draft Failure Detection ProtocolJuneSeptember 20068.11. References8.1.11.1. Normative References [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.8.2.11.2. Informative References [AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", In Proceedings of the 18th Annual Computer Security Applications Conference, Las Vegas, Nevada, USA., December 2002. [I-D.bagnulo-shim6-addr-selection] Bagnulo, M., "Address selection in multihomed environments", draft-bagnulo-shim6-addr-selection-00 (work in progress), October 2005. [I-D.huitema-multi6-addr-selection] Huitema, C., "Address selection in multihomed environments", draft-huitema-multi6-addr-selection-00 (work in progress), October 2004. [I-D.ietf-dna-cpl] Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page35]33] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix list based approach", draft-ietf-dna-cpl-02 (work in progress), January 2006. [I-D.ietf-dna-protocol] Kempf, J., "Detecting Network Attachment in IPv6 Networks (DNAv6)",draft-ietf-dna-protocol-00draft-ietf-dna-protocol-01 (work in progress),FebruaryJune 2006. [I-D.ietf-hip-mm] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol",draft-ietf-hip-mm-03draft-ietf-hip-mm-04 (work in progress),MarchJune 2006. [I-D.ietf-shim6-locator-pair-selection] Bagnulo, M., "Default Locator-pair selection algorithm for the SHIM6 protocol", draft-ietf-shim6-locator-pair-selection-00 (work in progress), May 2006. [I-D.ietf-shim6-proto] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-05 (work in progress), May 2006. [I-D.ietf-shim6-reach-detect] Beijnum, I., "Shim6 Reachability Detection", draft-ietf-shim6-reach-detect-01 (work in progress), October 2005. [I-D.ietf-tcpm-icmp-attacks] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm-icmp-attacks-00 (work in progress), February 2006. [RFC2960] 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. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page36]34] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 Appendix A. Contributors This draft attempts to summarize the thoughts and unpublished contributions of many people, including the MULTI6 WG design team members Marcelo Bagnulo Braun,Iljitsch van Beijnum,Erik Nordmark, Geoff Huston, Kurtis Lindqvist, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer Dawkins, and James Kempf, andmy colleagueHIP WG contributors such as PekkaNikander at Ericsson.Nikander. This draft is also in debt to work done in the context of SCTP [RFC2960] and HIP multihoming and mobility extension [I-D.ietf-hip-mm]. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page37]35] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 Appendix B. Acknowledgements The authors would also like to thank Christian Huitema, Pekka Savola, John Loughney, Sam Xia, and Hannes Tschofenig for interesting discussions in this problem space, and for review of this specification. Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page38]36] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@ericsson.com Iljitsch van BeijnumMuada The NetherlandsEmail: iljitsch@muada.com Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page39]37] Internet-Draft Failure Detection ProtocolJuneSeptember 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Arkko & van Beijnum ExpiresDecember 28, 2006March 27, 2007 [Page40]38] ----