idnits 2.17.1 draft-ietf-shim6-failure-detection-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1579. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 21, 2005) is 6694 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1750 (ref. '1') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (ref. '6') (Obsoleted by RFC 6724) == Outdated reference: A later version (-04) exists of draft-ietf-dna-goals-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dna-goals (ref. '7') == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-01 == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-unique-local-addr-05 -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '10') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '11') (Obsoleted by RFC 5389) == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-08 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-00 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-03 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-02 == Outdated reference: A later version (-05) exists of draft-ietf-shim6-hba-00 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-00 == Outdated reference: A later version (-01) exists of draft-ietf-shim6-reach-detect-00 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-10 == Outdated reference: A later version (-05) exists of draft-gont-tcpm-icmp-attacks-00 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-05 Summary: 9 errors (**), 0 flaws (~~), 16 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Expires: June 24, 2006 I. Beijnum 5 Muada 6 December 21, 2005 8 Failure Detection and Locator Pair Exploration Protocol for IPv6 9 Multihoming 10 draft-ietf-shim6-failure-detection-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 24, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document defines a mechanism for the detection of communication 44 failures between two communicating hosts at IP layer, and an 45 exploration protocol for switching to another pair of interfaces 46 and/or addresses between the same hosts if a working pair can be 47 found. The draft also discusses the roles of a multihoming protocol 48 versus network attachment functions at IP and link layers. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 54 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.1. Available Addresses . . . . . . . . . . . . . . . . . . 7 57 4.2. Locally Operational Addresses . . . . . . . . . . . . . 7 58 4.3. Operational Address Pairs . . . . . . . . . . . . . . . 8 59 4.4. Current Address Pair . . . . . . . . . . . . . . . . . . 9 60 4.5. Miscellaneous . . . . . . . . . . . . . . . . . . . . . 10 61 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 62 5.1. Failure Detection . . . . . . . . . . . . . . . . . . . 11 63 5.2. Alternative Address Pair Exploration . . . . . . . . . . 13 64 5.3. Exploration Order . . . . . . . . . . . . . . . . . . . 14 65 5.4. Protocol Design . . . . . . . . . . . . . . . . . . . . 14 66 5.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 15 67 5.6. Limitations . . . . . . . . . . . . . . . . . . . . . . 21 68 6. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 22 69 6.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 22 70 6.1.1. Keepalive Option . . . . . . . . . . . . . . . . 23 71 6.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 24 72 6.2.1. Probe Option . . . . . . . . . . . . . . . . . . 25 73 6.3. Reachability Option . . . . . . . . . . . . . . . . . . 26 74 6.3.1. Payload Reception Report . . . . . . . . . . . . 27 75 6.3.2. Probe Reception Report . . . . . . . . . . . . . 28 76 6.4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . 29 77 6.5. Protocol Constants . . . . . . . . . . . . . . . . . . . 33 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 82 9.2. Informative References . . . . . . . . . . . . . . . . . 37 83 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 39 84 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 86 Intellectual Property and Copyright Statements . . . . . . . . . . 42 88 1. Introduction 90 The SHIM6 protocol extends IPv6 to support multihoming. This 91 protocol is an IP layer mechanism that hides multihoming from 92 applications [18]. A part of the SHIM6 solution involves detecting 93 when a currently used pair of addresses (or interfaces) between two 94 communication hosts has failed, and picking another pair when this 95 occurs. We call the former failure detection, and the latter locator 96 pair exploration. 98 This draft defines the mechanism and protocol to achieve both failure 99 detection and locator pair exploration. This protocol is called 100 REAchability Protocol (REAP). It designed to be carried within the 101 SHIM6 protocol, but may also be used in other contexts. 103 The draft is structured as follows: Section 3 discusses prior work in 104 this space, Section 4 defines a set of useful terms, Section 5 gives 105 an overview of REAP, and Section 6 specifies the message formats and 106 behaviour in detail. Section 7 discusses the security considerations 107 of REAP. 109 For the purposes of this draft, we consider an address to be 110 synonymous with a locator. We assume that there are other, higher 111 level identifiers such as CGA public keys or HBA bindings that tie 112 the different locators used by a node together [17]. 114 2. Requirements language 116 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 117 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 118 described in [2]. 120 3. Related Work 122 In SCTP [10], the addresses of the endpoints are learned in the 123 connection setup phase either through listing them explicitly or via 124 giving a DNS name that points to them. In order to provide a 125 failover mechanism between multihomed hosts, SCTP selects one of the 126 peer's addresses as the primary address by the application running on 127 top of SCTP. All data packets are sent to this address until there 128 is a reason to choose another address, such as the failure of the 129 primary address. 131 SCTP also tests the reachability of the peer endpoint's addresses. 132 This is done both via observing the data packets sent to the peer or 133 via a periodic heartbeat when there is no data packets to send. Each 134 time data packet retransmission is initiated (or when a heartbeat is 135 not answered within the estimated round-trip time) an error counter 136 is incremented. When a configured error limit is reached, the 137 particular destination address is marked as inactive. The reception 138 of an acknowledgement or heartbeat response clears the counter. 139 Retransmission: When retransmitting the endpoint attempts pick the 140 most "divergent" source-destination pair from the original source- 141 destination pair to which the packet was transmitted. Rules for such 142 selection are, however, left as implementation decisions in SCTP. 144 SCTP does not define how local knowledge (such as information learned 145 from the link layer) should be used. SCTP also has no mechanism to 146 deal with dynamic changes to the set of available addresses, although 147 mechanisms for that are being developed [20]. 149 The MOBIKE protocol [15] provides multihoming and mobility for VPN 150 connections. Its failure detection and locator pair exploration is 151 designed to work across mixed IPv4/IPv6 environments and NATs, as 152 long as a path that allows bidirectional communication can be found. 154 Existing mechanisms at lower layers or in IKEv2 are used to detect 155 failures, and upon failure MOBIKE attempts to explore all 156 combinations of addresses to find a working pair. Such exploration 157 is necessary when a problem affects both nodes. For instance, two 158 nodes connected by two separate point-to-point links will be unable 159 to switch to the other link if a failure occurs on the first one. 160 While both communicating hosts are aware of each others' addresses, 161 only one end of the communication is in charge of deciding what 162 address pair to use, however. 164 The mobility and multihoming specification for the HIP protocol [14] 165 leaves the determination of when address updates are sent to a local 166 policy, but suggests the use of local information and ICMP error 167 messages. 169 Network attachment procedures are also relevant for multihoming. The 170 IPv6 and MIP6 working groups have standardized mechanisms to learn 171 about networks that a node has attached to. Basic IPv6 Neighbor 172 Discovery was, however, designed primarily for static situations. 173 The fully dynamic detection procedure has turned out to be a 174 relatively complex procedure for mobile hosts, and it was not fully 175 anticipated at the time IPv6 Neighbor Discovery or DHCP were being 176 designed. As a result, enhanced or optimized mechanisms are being 177 designed in the DHC and DNA working groups [13] [7]. 179 ICE [16], STUN [11], and TURN [24] are also related mechanisms. They 180 are primarily used for NAT detection and communication through NATs 181 in IPv4 environment, for application such as as voice over IP. STUN 182 uses a server in the Internet to discover the presence and type of 183 NATs and the client's public IP addresses and ports. TURN makes it 184 possible to receive incoming connections in hosts behind NATs. ICE 185 makes use of these protocols in peer-to-peer cooperative fashion, 186 allowing participants to discover, create and verify mutual 187 connectivity, and then use this connectivity for multimedia streams. 188 While these mechanisms are not designed for dynamic and failure 189 situations, they have many of the same requirements for the 190 exploration of connectivity, as well as the requirement to deal with 191 middleboxes. 193 Related work in the IPv6 area includes RFC 3484 [6] which defines 194 source and destination address selection rules for IPv6 in situations 195 where multiple candidate address pairs exist. RFC 3484 considers 196 only a static situation, however, and does not take into account the 197 effect of failures. Reference [23] considers how applications can 198 re-initiate connections after failures in the best way. This work 199 differs from the shim-layer approach selected for further development 200 in the working group with respect to the timing of the address 201 selection. In the shim-layer approach failure detection and the 202 selection of new addresses happens at any time, while [23] considers 203 only the case when an application re-establishes connections. 205 An earlier SHIM6 document [19] discussed what kind of mechanisms can 206 be used to detect whether the peer is still reachable at the 207 currently used address. Two proposed mechanisms, Correspondent 208 Unreachability Detection (CUD) and Forced Bidirectional Communication 209 (FBD) were presented. CUD is based on getting upper layer positive 210 feedback, and IPv6 NUD-like probing if there is no feedback. FBD is 211 based on forcing bidirectional communication by adding keepalive 212 messages when there is no other, payload traffic. FBD is the chosen 213 mechanism in this document. 215 4. Definitions 217 This section defines terms useful in discussing the problem space. 219 4.1. Available Addresses 221 Multihoming nodes need to be aware of what addresses they themselves 222 have. If a node loses the address it is currently using for 223 communications, another address must replace this address. And if a 224 node loses an address that the node's peer knows about, the peer must 225 be informed. Similarly, when a node acquires a new address it may 226 generally wish the peer to know about it. 228 Definition. Available address. An address is said to be available 229 if the following conditions are fulfilled: 231 o The address has been assigned to an interface of the node. 233 o If the address is an IPv6 address, we additionally require that 234 (a) the address is valid in the sense of RFC 2461 [3], and that 235 (b) the address is not tentative in the sense of RFC 2462 [4]. In 236 other words, the address assignment is complete so that 237 communications can be started. 239 Note that this explicitly allows an address to be optimistic in 240 the sense of [8] even though implementations are probably better 241 off using other addresses as long as there is an alternative. 243 o The address is a global unicast, unique local address [9], or an 244 unambiguous IPv6 link-local address. That is, it is not an IPv6 245 site-local address. Where IPv6 link-local addresses are used, 246 their use needs to be unambiguous as follows. At most one link- 247 local address may be used per node within the same connection 248 between two peers. 250 o The address and interface is acceptable for use according to a 251 local policy. 253 Available addresses are discovered and monitored through mechanisms 254 outside the scope of the protocol described here. These mechanisms 255 include IPv6 Neighbor Discovery and Address Autoconfiguration [3] 256 [4], DHCP [5], and DNA mechanisms [7]. 258 4.2. Locally Operational Addresses 260 Two different granularity levels are needed for failure detection. 261 The coarser granularity is for individual addresses: 263 Definition. Locally Operational Address. An available address is 264 said to be locally operational when its use is known to be possible 265 locally: the interface is up, at least one default router (if 266 applicable) that could be used to send a packet with this address as 267 a source address is known to be reachable, and no other local 268 information points to the address being unusable. 270 Locally operational addresses are discovered and monitored through 271 mechanisms outside the protocol described here. These mechanisms 272 include IPv6 Neighbor Discovery [3] and link layer specific 273 mechanisms. 275 It is also possible for hosts to learn about routing failures for a 276 particular selected source prefix, if suitable protocols for this 277 purpose exist. Some proposals in this space have been made, see, for 278 instance [21] and [23]. Potential approaches include overloading 279 information in current IPv6 Router Advertisement or adding some new 280 information in them. Similarly, hosts could learn information from 281 servers that query the BGP routing tables. 283 4.3. Operational Address Pairs 285 The existence of locally operational addresses are not, however, a 286 guarantee that communications can be established with the peer. A 287 failure in the routing infrastructure can prevent the sent packets 288 from reaching their destination. For this reason we need the 289 definition of a second level of granularity, for pairs of addresses: 291 Definition. Bidirectionally operational address pair. A pair of 292 locally operational addresses are said to be an operational address 293 pair, iff bidirectional connectivity can be shown between the 294 addresses. That is, a packet sent with one of the addresses in the 295 source field and the other in the destination field reaches the 296 destination, and vice versa. 298 Unfortunately, there are scenarios where bidirectionally operational 299 address pairs do not exist. For instance, ingress filtering or 300 network failures may result in one address pair being operational in 301 one direction while another one is operational from the other 302 direction. The following definition captures this general situation: 304 Definition. Undirectionally operational address pair. A pair of 305 locally operational addresses are said to be an unidirectionally 306 operational address pair, iff packets sent with the first address as 307 the source and the second address as the destination can be shown to 308 reach the destination. 310 Both types of operational pairs could be discovered and monitored 311 through the following mechanisms: 313 o Positive feedback from upper layer protocols. For instance, TCP 314 can indicate to the IP layer that it is making progress. This is 315 similar to how IPv6 Neighbor Unreachability Detection can in some 316 cases be avoided when upper layers provide information about 317 bidirectional connectivity [3]. In the case of unidirectional 318 connectivity, the upper layer protocol responses come back using 319 another address pair, but show that the messages sent using the 320 first address pair have been received. 322 o Negative feedback from upper layer protocols. It is conceivable 323 that upper layer protocols give an indication of a problem to the 324 multihoming layer. For instance, TCP could indicate that there's 325 either congestion or lack of connectivity in the path because it 326 is not getting ACKs. 328 o Explicit reachability tests, such as keepalives or probes added 329 when there's only unidirectional payload traffic. 331 o ICMP error messages. Given the ease of spoofing ICMP messages, 332 one should be careful to not trust these blindly, however. Our 333 suggestion is to use ICMP error messages only as a hint to perform 334 an explicit reachability test, but not as a reason to disrupt 335 ongoing communications without other indications of problems. The 336 situation may be different when certain verifications of the ICMP 337 messages are being performed [22]. These verifications can ensure 338 that (practically) only on-path attackers can spoof the messages. 340 Note a multihoming protocol needs to perform a return routability 341 test of an address before it is taken into use. The purpose of this 342 test is to ensure that fraudulent peers do not trick others into 343 redirecting traffic streams onto innocent victims [25]. This test 344 can at the same time work as a means to ensure that an address pair 345 is operational, as discussed in Section 5.2. 347 4.4. Current Address Pair 349 IP-layer solutions need to avoid sending packets concurrently over 350 multiple paths; TCP behaves rather poorly in such circumstances. For 351 this reason it is necessary to choose a particular pair of addresses 352 as the current address pair which is used until problems occur, at 353 least for the same session. 355 A current address pair need not be operational at all times. If 356 there is no traffic to send, we may not know if the primary address 357 pair is operational. Nevertheless, it makes sense to assume that the 358 address pair that worked in some time ago continues to work for new 359 communications as well. 361 4.5. Miscellaneous 363 Addresses can become deprecated [3]. When other operational 364 addresses exist, nodes generally wish to move their communications 365 away from the deprecated addresses. 367 Similarly, IPv6 source address selection [6] may guide the selection 368 of a particular source address - destination address pair. 370 5. Protocol Overview 372 This section discusses the design of the reachability detection and 373 address pair exploration mechanisms, and gives on overview of the 374 REAP protocol. 376 A naive implementation of an (un)reachability detection mechanism 377 could just probe all possible paths between two hosts periodically. 378 A "path" is defined as a combination of a source address for host A 379 and a destination address for host B. In hop-by-hop forwarding the 380 source address has no effect on reachability, but in the presence of 381 filters or source address based routing, it may. And although links 382 almost always work in two directions, routing protocols and filters 383 only work in one direction so unidirectional reachability is 384 possible. Without additional mechanisms, the practice of ingress 385 filtering by ISPs makes unidirectional connectivity likely. Being 386 able to use the working leg in a unidirectional path is useful, it's 387 not an essential requirement. It is essential, however, to avoid 388 assuming bidirectional connectivity when there is in fact a 389 unidirectional failure. 391 Exploring the full set of communication options between two hosts 392 that both have two or more addresses is an expensive operation as the 393 number of combinations to be explored increases very quickly with the 394 number of addresses. For instance, with two addresses on both sides, 395 there are four possible address pairs. Since we can't assume that 396 reachability in one direction automatically means reachability for 397 the complement pair in the other direction, the total number of two- 398 way combinations is eight. (Combinations = nA * nB * 2.) 400 An important observation in multihoming is that failures are 401 relatively infrequent, so that a path that worked a few seconds ago 402 is very likely to work now as well. So it makes sense to have a 403 light-weight protocol that confirms existing reachability, and only 404 invoke heavier exploration when a there is a suspected failure. 406 5.1. Failure Detection 408 This process consists of three tasks. First, it is necessary to 409 track local information from lower and upper layers. For instance, 410 when link layer informs that we have no connection then we know there 411 is a failure. Nodes SHOULD employ techniques listed in Section 4.1 412 and Section 4.2 to be aware of the local situation. 414 Similarly, it is necessary to track remote address information from 415 the peer. For instance, the peer may inform that its currently used 416 address is no longer in use. Techniques outside the scope of this 417 document are used for this, for further information see [18]. 419 The third task is to ensure verify reachability with the peer when 420 the local and remote information indicates that communication should 421 be possible. This needs to be performed only if there's upper layer 422 packets to be sent, however. 424 This document defines the protocol mechanisms only for the third 425 task. We employ a technique called Forced Bidirectional Detection 426 (FBD). Reachability for the currently used address pair in a shim 427 context is determined by making sure that whenever there is data 428 traffic in one direction, there is also traffic in the other 429 direction. This can be data traffic as well, but also transport 430 layer acknowledgments or a REAP reachability keepalive if there is no 431 other traffic. This way, it is no longer possible to have traffic in 432 only one direction, so whenever there is data traffic going out, but 433 there are no return packets, there must be a failure, so the full 434 path exploration mechanism is started. 436 A more detailed description of the current pair reachability 437 evaluation mechanism: 439 1. The base timing unit for this mechanism is named Keepalive 440 Timeout. Until a negotiation mechanism to negotiate different 441 values for this timer becomes available, the value (3 seconds) 442 specified in Section 6.5 SHOULD be used. 444 2. Whenever outgoing data packets are generated that are part of a 445 shim context, a timer is started to reflect the requirement that 446 the peer should generate return traffic from data packets. 448 3. Whenever incoming data packets are received that are part of a 449 shim context, the timer associated with the return traffic from 450 the peer is stopped, and another timer is started to reflect the 451 requirement for this node to generate return traffic. 453 4. The reception of a REAP keepalive packet leads to stopping the 454 timer associated with the return traffic from the peer. 456 5. Keepalive Timeout seconds after the last data packet has been 457 received for a context, and if no other packet has been sent 458 within this context since the data packet has been received, a 459 REAP keepalive packet is generated for the context in question 460 and transmitted to the correspondent. A host may send the 461 keepalive sooner than Keepalive Timeout seconds if implementation 462 considerations warrant this. The average time after which 463 keepalives are sent MUST be at least Keepalive Timeout / 2 464 seconds. After sending a single keepalive message, no additional 465 keepalive messages are sent until a data packet is received 466 within this shim context. Keepalives are not sent at all when a 467 data packet was sent since the last received data packet. 469 6. Send Timeout seconds (10 s; see Section 6.5) after the 470 transmission of a data packet with no return traffic on this 471 context, a full reachability exploration is started. This 472 timeout period is larger than the Keepalive Timeout to 473 accommodate for lost keepalives and regular variations in round 474 trip times. 476 5.2. Alternative Address Pair Exploration 478 As explained in previous section, the currently used address pair may 479 become invalid either through one of the addresses being becoming 480 unavailable or inoperational, or the pair itself being declared 481 inoperational. An exploration process attempts to find another 482 operational pair so that communications can resume. 484 What makes this process hard is the requirement to support 485 unidirectionally operational address pairs. It is insufficient to 486 probe address pairs by a simple request - response protocol. 487 Instead, the party that first detects the problem starts a process 488 where it tries each of the different address pairs in turn by sending 489 a message to its peer. These messages carry information about the 490 state of connectivity between the peers, such as whether the sender 491 has seen any traffic from the peer recently. When the peer receives 492 a message that indicates a problem, it assists the process by 493 starting its own parallel exploration to the other direction, again 494 sending information about the recently received payload traffic or 495 signaling messages. 497 Specifically, when A decides that it needs to explore for an 498 alternative address pair to B, it will initiate a set of Probe 499 messages, in sequence, until it gets an Probe message from B 500 indicating that (a) B has received one of A's messages and, 501 obviously, (b) that B's Probe message gets back to A. B uses the same 502 algorithm, but starts the process from the reception of the first 503 Probe message from A. 505 Upon changing to a new address pair, transport layer protocol needs 506 to be informed so that it can perform a slow start, or some other 507 form of adaptation to the possibly changed conditions. However, this 508 functionality is outside the scope of REAP and is rather seen as a 509 general multihoming issue. 511 Similarly, one can also envision that applications would be able to 512 tell the IP or transport layer that the current connection in 513 unsatisfactory and an exploration for a better one would be 514 desirable. This would require an API to be developed, however. In 515 any case, this is another issue that we treat as being outside the 516 scope of pure address exploration. 518 5.3. Exploration Order 520 The exploration process assumes an ability to pick current and 521 alternative address pairs. This process may result in a 522 combinatorial explosion when there are many addresses on both sides, 523 but a back-off procedure is employed to avoid a "signaling storm". 525 Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine 526 what combinations of addresses are allowed from a local point of 527 view, as this reduces the search space. RFC 3484 also provides a 528 priority ordering among different address pairs, making the search 529 possibly faster. Nodes MAY also use local information, such as known 530 quality of service parameters or interface types to determine what 531 addresses are preferred over others, and try pairs containing such 532 addresses first. The multihoming protocol also carries preference 533 information in its messages [18]. 535 Discussion note: The preferences may either be learned dynamically 536 or be configured. It is believed, however, that dynamic learning 537 based purely on the multihoming protocol is too hard and not the 538 task this layer should do. Solutions where multiple protocols 539 share their information in a common pool of locators could provide 540 this information from transport protocols, however. 542 One suggested good implementation strategy is to record the 543 reachability test result (an on/off value) and multiply this by the 544 age of the information. This allows recently tested address pairs to 545 be chosen before old ones. 547 Out of the set of possible candidate address pairs, nodes SHOULD 548 attempt a test through all of them until a working pair is found, and 549 retrying the process as is necessary. However, all nodes MUST 550 perform this process sequentially and with exponential back-off. 551 This sequential process is necessary in order to avoid a "signaling 552 storm" when an outage occurs (particularly for a complete site). 553 However, it also limits the number of addresses that can in practice 554 be used for multihoming, considering that transport and application 555 layer protocols will fail if the switch to a new address pair takes 556 too long. 558 5.4. Protocol Design 560 REAP is designed as a modular part of SHIM6 in the hopes that it may 561 also be useful in other contexts. This document defines how it is 562 carried within SHIM6, but the actual protocol messages are self- 563 contained so that it could be carried by other protocols as well. 565 The REAP design allows performing both failure detection and address 566 pair exploration in the same sequence of messages, without a need to 567 designate a specific point when the current address pair is declared 568 inoperational and the search for a new pair begins. This is useful, 569 as the loss of a small number of packets is not a proof that a 570 problem exists. Integrated failure detection and exploration allows 571 us to test multiple address pairs simultaneously, including the 572 current pair in case it starts working again. For instance, the 573 exploration process can refer to keepalive message that succeeded in 574 getting to the peer during the reachability testing phase. 576 REAP also integrates a return routability function, making it 577 unnecessary to perform another roundtrip before a newly discovered 578 address can be taken into use. 580 This document defines a minimal set of parameters that are carried by 581 the messages of the protocol. Specifically, we have limited the 582 parameters to those that are necessary to find a working path. We 583 note there may be extensions that are needed in the future for 584 various reasons, such as the desire to support load balancing or 585 finding best paths. An option format has been specified to allow 586 this. 588 5.5. Example Protocol Runs 590 This section has examples of REAP protocol runs in typical scenarios. 591 We start with the simplest scenario of two hosts, A and B, that have 592 a SHIM6 connection with each other but are not currently sending any 593 data. As neither side sends anything, they also do not expect 594 anything back, so there are no messages at all: 596 Peer A Peer B 597 | | 598 | | 599 | | 600 | | 601 | | 602 | | 603 | | 604 | | 606 Our second example involves an active connection with bidirectional 607 payload packet flows. Here the reception of data from the peer is 608 taken as an indication of reachability, so again there are no extra 609 packes: 611 Peer A Peer B 612 | | 613 | payload packet | 614 |-------------------------------------------->| 615 | | 616 | payload packet | 617 |<--------------------------------------------| 618 | | 619 | payload packet | 620 |-------------------------------------------->| 621 | | 622 | | 624 The third example is the first one that involves an actual REAP 625 message. Here the hosts communicate in just one direction, so REAP 626 messages are needed to indicate to the peer that sends payload 627 packets that its packets are getting through: 629 Peer A Peer B 630 | | 631 | payload packet | 632 |-------------------------------------------->| 633 | | 634 | payload packet | 635 |-------------------------------------------->| 636 | | 637 | payload packet | 638 |-------------------------------------------->| 639 | | 640 | Keepalive id=p | 641 |<--------------------------------------------| 642 | | 643 | payload packet | 644 |-------------------------------------------->| 645 | | 646 | | 648 Finally, our last example involves a failure scenario. Here A has 649 addresses A1 and A2 and B has addresses B1 and B2. The currently 650 used address pairs are (A1, B1) and (B1, A1). The first of these 651 becomes broken, which leads to an exploration process: 653 Peer A Peer B 654 | | 655 | (A1,B1) payload packet | 656 |-------------------------------------------->| 657 | | 658 | (B1,A1) payload packet | 659 |<--------------------------------------------| Time T1 660 | | Path A1->B1 661 | (A1,B1) payload packet | is now 662 |----------------------------------------/ | broken 663 | | 664 | (B1,A1) payload packet | 665 |<--------------------------------------------| 666 | | 667 | (A1,B1) payload packet | 668 |----------------------------------------/ | 669 | | 670 | (B1,A1) payload packet | 671 |<--------------------------------------------| 672 | | 673 | (A1,B1) payload packet | 674 |----------------------------------------/ | 675 | | 676 | | 10 seconds after 677 | | T1, sends a com- 678 | (B1,A1) Probe id=p, | plaint that 679 | iseeyou=no | it is not rec- 680 |<--------------------------------------------| eiving anything 681 | | 682 A realizes | 683 that it needs | 684 to start the | 685 exploration | 686 | | 687 | (A1, B1) Probe id=q, | 688 | iseeyou=yes | 689 | payload reception rep | 690 | probe reception rep(p) | But it gets lost 691 |-------------------------------------/ | due to broken path 692 | | 693 Retransmission | 694 to a different | 695 address | 696 | | 697 | (A1, B2) Probe id=r, | 698 | iseeyou=yes | 699 | payload reception rep | 700 | probe reception rep(p) | This one gets 701 |-------------------------------------------->| through 702 | | 703 | | 704 | | B now knows 705 | | that A has no 706 | (B1,A1) Probe id=p, | problem to receive 707 | iseeyou=yes, | its packets and 708 | probe reception rep(r) | This one gets 709 |<--------------------------------------------| that A has found 710 | | a new path to B 711 | | 712 | (A1,B2) payload packet | 713 |-------------------------------------------->| Payload packets 714 | | flow again 715 | (B1,A1) payload packet | 716 |<--------------------------------------------| 718 The next example shows when the failure for the current locator pair 719 is in the other direction: 721 Peer A Peer B 722 | | 723 | (A1,B1) payload packet | 724 |-------------------------------------------->| 725 | | 726 | (B1,A1) payload packet | 727 | /-----------------------------------------| Time T1 728 | | Path B1->A1 729 | | is now 730 | | broken 731 | (B1,A1) payload packet | 732 | /-----------------------------------------| 733 | | 734 | (B1,A1) payload packet | 735 | /-----------------------------------------| 736 | | 737 | | 10 seconds after 738 | | T1, sends a com- 739 | (B1,A1) Probe id=p, | plaint that 740 | iseeyou=no | it is not rec- 741 | /-----------------------------------------| eiving anything 742 | | 743 | (B2,A2) Probe id=q, | 744 | iseeyou=no | Next try different 745 |<--------------------------------------------| locator pair 746 | | 747 | (A2, B2) Probe id=r, | 748 | iseeyou=yes | 749 | payload reception rep | 750 | probe reception rep(q) | This one gets 751 |-------------------------------------------->| through 752 | | 753 | | 754 | | B now knows 755 | | that A has no 756 | (B2,A2) Probe id=s, | problem to receive 757 | iseeyou=yes, | its packets and 758 | probe reception rep(r) | This one gets 759 |<--------------------------------------------| that A has found 760 | | a new path to B 761 | | 762 | (A2,B2) payload packet | 763 |-------------------------------------------->| Payload packets 764 | | flow again 765 | (B2,A2) payload packet | 766 |<--------------------------------------------| 768 In the next case we have even less luck. The response to the REAP 769 probe doesn't make it in the reverse direction, so both ends end up 770 exploring indepedently: 772 Peer A Peer B 773 | | 774 | (A1,B1) payload packet | 775 |-------------------------------------------->| 776 | | 777 | (B1,A1) payload packet | 778 | /-----------------------------------------| Time T1 779 | | Path B1->A1 780 | | is now 781 | | broken 782 | (B1,A1) payload packet | 783 | /-----------------------------------------| 784 | | 785 | (B1,A1) payload packet | 786 | /-----------------------------------------| 787 | | 788 | | 10 seconds after 789 | | T1, sends a com- 790 | (B1,A1) Probe id=p, | plaint that 791 | iseeyou=no | it is not rec- 792 | /-----------------------------------------| eiving anything 793 | | 794 | (B2,A2) Probe id=q, | 795 | iseeyou=no | Next try different 796 |<--------------------------------------------| locator pair 797 | | 798 A now knows that it needs | 799 to start exploring | 800 | | 801 | (A2, B2) Probe id=r, | 802 | iseeyou=yes | 803 | payload reception rep | 804 | probe reception rep(q) | 805 |--------------------------------------/ | Doesn't make it 806 | | 807 | (A1, B1) Probe id=s, | 808 | iseeyou=yes | 809 | payload reception rep | 810 | probe reception rep(q) | This one gets 811 |-------------------------------------------->| through 812 | | 813 | | 814 | | B now knows 815 | | that A has no 816 | (B2,A2) Probe id=t, | problem to receive 817 | iseeyou=yes, | its packets and 818 | probe reception rep(r) | This one gets 819 |<--------------------------------------------| that A has found 820 | | a new path to B 821 | | 822 | (A1,B1) payload packet | 823 |-------------------------------------------->| Payload packets 824 | | flow again 825 | (B2,A2) payload packet | 826 |<--------------------------------------------| 828 5.6. Limitations 830 REAP is designed to support failure recovery even in the case of 831 having only unidirectionally operational address pairs. However, due 832 to security concerns discussed in Section 7, the exploration process 833 can typically be run only for a session that has already been 834 established. Specifically, while REAP would in theory be capable of 835 exploration even during connection establishment, its use within the 836 SHIM6 protocol does not allow this. 838 6. Protocol Definition 840 6.1. Keepalive Message 842 The format of the keepalive message is as follows: 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Next Header | Hdr Ext Len |0| Type = 66 | Reserved |0| 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Checksum |R| | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 851 | Receiver Context Tag | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | | 854 + Options + 855 | | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Next Header 860 This value MUST be set to NO_NXT_HDR (59). 862 Type 864 This field identifies the Probe message and MUST be set to 66 865 (Keepalive). 867 Reserved 869 This is a 7-bit field reserved for future use. It is set to zero 870 on transmit, and MUST be ignored on receipt. 872 R 874 This is a 1-bit field reserved for future use. It is set to zero 875 on transmit, and MUST be ignored on receipt. 877 Receiver Context Tag 879 This is a 47-bit field for the Context Tag the receiver has 880 allocated for the context. 882 Options 884 This MUST contain at least the Keepalive option and MAY contain 885 one or more Reachability options.The inclusion of the latter 886 options is not necessary, however, as there are currenly no 887 defined options that are useful in a Keepalive message. These 888 options are provided only for future extensibility reasons. 890 A valid message conforms to the format above, has a Receiver Context 891 Tag that matches to context known by the receiver, is valid shim 892 control message as defined in Section 12.2 of [18], and its shim 893 context state is ESTABLISHED. The receiver processes a valid message 894 by inspecting its options, and executing any actions specified for 895 such options. 897 The processing rules for this message are the given in more detail in 898 Section 6.4. 900 6.1.1. Keepalive Option 902 0 1 2 3 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Type = 10 |0| Length | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Res | Identifier | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Type 912 This value MUST be set to 10 (Keepalive Option). 914 0 916 This value MUST be set to 0, as in other SHIM6 options. 918 Length 920 This is the length of the option and MUST be calculated as 921 specified in Section 5.14 of [18]. 923 Res 925 This 4-bit reserved field MUST be set to zero when sending, and 926 ignored on receipt. 928 Identifier 930 This 28-bit field identifies this particular instance of an 931 Keepalive message. This value SHOULD be generated using a random 932 number generator that is known to have good randomness properties 933 [1]. Upon reception, Identifier values from both Keepalive and 934 Probe messages may be copied onto Probe Reception Report options. 935 This allows them to be used for both identifying which packets 936 were received as well as for performing a return routability test. 938 The processing rules for this option are the given in more detail in 939 Section 6.4. 941 6.2. Probe Message 943 This message performs REAP exploration. Its format is as follows: 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0| 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Checksum |R| | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 952 | Receiver Context Tag | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | | 955 + Options + 956 | | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Next Header 961 This value MUST be set to NO_NXT_HDR (59). 963 Type 965 This field identifies the Probe message and MUST be set to 67 966 (Probe). 968 Reserved 970 This is a 7-bit field reserved for future use. It is set to zero 971 on transmit, and MUST be ignored on receipt. 973 R 975 This is a 1-bit field reserved for future use. It is set to zero 976 on transmit, and MUST be ignored on receipt. 978 Receiver Context Tag 980 This is a 47-bit field for the Context Tag the receiver has 981 allocated for the context. 983 Options 985 This MUST contain at least the Probe option and MAY contain one or 986 more Reachability options. 988 A valid message conforms to the format above, has a Receiver Context 989 Tag that matches to a context known by the receiver, is valid shim 990 control message as defined in Section 12.2 of [18], and its shim 991 context state is ESTABLISHED. The receiver processes a valid message 992 by inspecting its options, and executing any actions specified such 993 options. This includes the SHIM6 Probe option found within the 994 options. 996 The processing rules for this message are the given in more detail in 997 Section 6.4. 999 6.2.1. Probe Option 1001 0 1 2 3 1002 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 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | Type = 11 |0| Length | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 |Y| Res | Identifier | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Type 1011 This value MUST be set to 11 (Probe Option). 1013 0 1015 This value MUST be set to 0, as in other SHIM6 options. 1017 Length 1019 This is the length of the option and MUST be calculated as 1020 specified in Section 5.14 of [18]. 1022 Y (The "I See You" flag) 1024 This flag is set to 1 if the sender receives either payload 1025 packets or REAP messages from the peer, and 0 otherwise. The 1026 determination of when the sender receives something is made during 1027 the last Send Timeout seconds (see Section 6.5) when traffic was 1028 expected, i.e., when there was either payload traffic or REAP 1029 messages. 1031 Upon reception, a value of 1 indicates that the receiver does not 1032 need to change its behaviour as the sender is already seeing its 1033 packets. A value of 0 indicates that the receiver MUST explore 1034 different outgoing address pairs. 1036 Res 1038 This 3-bit reserved field MUST be set to zero when sending, and 1039 ignored on receipt. 1041 Identifier 1043 This 28-bit field identifies this particular instance of an Probe 1044 message. This value SHOULD be generated using a random number 1045 generator that is known to have good randomness properties [1]. 1046 Upon reception, Identifier values are copied onto Probe Reception 1047 Report options. This allows them to be used for both identifying 1048 which Probes were received as well as for performing a return 1049 routability test. 1051 The processing rules for this option are the given in more detail in 1052 Section 6.4. 1054 6.3. Reachability Option 1056 Additional information can be included in Keepalive and Probe 1057 messages by the inclusion of the Reachability Options. Their format 1058 is as follows: 1060 0 1 2 3 1061 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Type = 12 |0| Length | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Option Type | | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1067 ~ Option Data ~ 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 Type 1072 This value MUST be set to 12 (Reachability option). 1074 0 1076 This value MUST be set to 0, as in other SHIM6 options. 1078 Length 1080 This is the length of the option and MUST be calculated as 1081 specified in Section 5.14 of [18]. 1083 Option Type 1085 This value identifies the option. 1087 Option Data 1089 Option-specific content. 1091 Unrecognized options MUST be ignored upon receipt. All 1092 implementations MUST support the options defined in this 1093 specification, however. 1095 6.3.1. Payload Reception Report 1097 This option SHOULD be included in all Probe messages when the sender 1098 has recently (within the last Send Timeout seconds) received payload 1099 packets from the peer. Its format is as follows: 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Type = 11 |0| Length | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Option Type = 1 | Reserved | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 ~ Suboptions ~ 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 Type, 0, and Length 1113 These are as specified above. 1115 Reserved 1117 This is a 16-bit field reserved for future use. It is set to zero 1118 on transmit, and MUST be ignored on receipt. 1120 Suboptions 1122 This field is reserved for possible future Reachability options 1123 that are carried (recursively) within this option. Unrecognized 1124 options MUST be ignored upon receipt. Currently there are no 1125 defined options that can be carried here. 1127 6.3.2. Probe Reception Report 1129 This option MUST be included in any Probe message when the sender has 1130 recently (within the last Send Timeout seconds) received Probe or 1131 Keepalieve messages from the peer. Depending on MTU and timing 1132 considerations, the sender MAY, however, include options for only 1133 some of the received Probe messages. All implementations MUST 1134 support sending of at least five such options, however. 1136 The format of this option is as follows: 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Type = 11 |0| Length | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Option Type = 2 | Reserved | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Res | Identifier | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 ~ Suboptions ~ 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 Type, 0, and Length 1152 These are as specified above. 1154 Option Type 1156 This value identifies the option and MUST be set to 2 (Probe 1157 Reception Report). 1159 Reserved 1161 This is a 16-bit field reserved for future use. It is set to zero 1162 on transmit, and MUST be ignored on receipt. 1164 Res 1166 This is a 3-bit field reserved for future use. It is set to zero 1167 on transmit, and MUST be ignored on receipt. 1169 Identifier 1171 This 32 bit field carries the identifier of the Probe message that 1172 was recently received. 1174 Suboptions 1176 This field is reserved for possible future Reachability options 1177 that are carried (recursively) within this option. Unrecognized 1178 options MUST be ignored upon receipt. Currently there are no 1179 defined options that can be carried here. 1181 6.4. Behaviour 1183 The required behaviour of REAP nodes is specified below in the form 1184 of a state machine. The externally observable behaviour of an 1185 implementation MUST conform to this state machine, but there is no 1186 requirement that the implementation actually employs a state machine. 1188 On a given context with a given peer, the node can be in one of three 1189 states: Operational, Exploring, or ExploringOK. In the Operational 1190 state the underlying address pairs are assumed to be operational. In 1191 the Exploring state this node has observed a problem and has 1192 currently not seen any traffic from the peer. Finally, in the 1193 ExploringOK state this node sees traffic from the peer, but peer may 1194 not yet see any traffic from this node so that the exploration 1195 process needs to continue. 1197 The node maintains also the Send and Keepalive timers. The Send 1198 timer reflects the requirement that when this node sends a payload 1199 packet there should be some return traffic (either payload packets or 1200 Keepalive messages) within Keepalive Timeout seconds. The Keepalive 1201 timer reflects the requirement that when this node receives a payload 1202 packet there should a similar response towards the peer. The 1203 Keepalive timer is only used within the Operational state, and the 1204 Send timer in the Operational and ExploringOK states. No timer is 1205 running in the Exploring state. 1207 Upon the reception of a payload packet in the Operational state, the 1208 node starts the Keepalive timer if it is not yet running, and stops 1209 the Send timer if it was running. If the node is in the Exploring 1210 state it transitions to the ExploringOK state, sends a Probe message 1211 with the I See You flag set to 1 (Yes), and starts the Send timer. 1212 In the ExploringOK state the node stops the Send timer if it was 1213 running, but does not do anything else. The reception of SHIM6 1214 control messages other than the Keepalive and Probe messages are 1215 treated similarly with payload packets. 1217 Upon sending a payload packet in the Operational state, the node 1218 stops the Keepalive timer if it was running and starts the Send timer 1219 if it was not running. In the Exploring state there is no effect, 1220 and in the ExploringOK state the node simply starts the Send timer if 1221 it was not yet running. (The sending of SHIM6 control messages is 1222 again treated similarly here.) 1224 Upon a timeout on the Keepalive timer the node sends a Keepalive 1225 message. This can only happen in the Operational state. 1227 Upon a timeout on the Send timer, the node enters the Exploring state 1228 and sends a Probe with I See You set to 0 (No) and stops the 1229 Keepalive timer if it was running. 1231 While in the Exploring state the node keeps retransmitting its Probe 1232 messages to different (or same) addresses as defined in Section 5.3. 1233 A similar process is employed in the ExploringOk state, except that 1234 upon such retransmission the Send timer is started if it was not 1235 running already. 1237 Upon the reception of a Keepalive message in the Operational state, 1238 the node stops the Send timer, if it was running. If the node is in 1239 the Exploring state it transitions to the ExploringOK state, sends a 1240 Probe message with the I See You flag set to 1 (Yes), and starts the 1241 Send timer. In the ExploringOK state the Send timer is stopped, if 1242 it was running. 1244 Upon receiving a Probe with I See You set to 0 (No) the node enters 1245 the ExploringOK state, sends a Probe with I See You set to 1 (Yes), 1246 stops the Keepalive timer if it was running, and restarts the Send 1247 timer. 1249 The behavior upon the reception of a Probe message with I see You set 1250 to 1 (Yes) depends on whether it contains a Probe Reception Report 1251 that refers to a Probe that this node has sent to the peer such that 1252 the I See You was set to 1 in that message. If not, the node sends a 1253 Probe message with I See You set to 1 (Yes), restarts the Send timer, 1254 stops the Keepalive timer if it was running, and transitions to the 1255 Operational state. 1257 If there was no such Probe Reception Report, the stops the Send timer 1258 if it was running, starts the Keepalive timer if it was not yet 1259 running, and transitions to the Operational state. 1261 Note: This check is necessary in order to terminate the 1262 exploration process when both parties are happy and know that 1263 their peers are happy as well. 1265 The reachability detection and exploration process has no effect on 1266 payload communications until a new working address pairs have 1267 actually been confirmed. Prior to that the payload packets continue 1268 to be sent to the previously used addresses. 1270 Garbage collection of SHIM6 contexts terminates contexts that are 1271 either unused or have failed due to the inability of the exploration 1272 process to find a working pair. 1274 In the PDF version of this specification, an informational drawing 1275 illustrates the state machine. Where the text and the drawing 1276 differ, the text takes precedence. 1278 A tabular representation of the state machine is shown below. Like 1279 the drawing, this representation is only informational. 1281 1. EVENT: Incoming payload packet 1282 ================================= 1284 Operational Exploring ExploringOk 1285 --------------------------------------------------------------- 1286 STOP Send; SEND Probe Y=Yes; STOP Send 1287 START Keepalive START Send; 1288 GOTO ExploringOk 1290 2. EVENT: Outgoing payload packet 1291 ================================= 1293 Operational Exploring ExploringOk 1294 --------------------------------------------------------------- 1295 START Send; - START Send 1296 STOP Keepalive 1298 3. EVENT: Keepalive timeout 1300 Operational Exploring ExploringOk 1301 --------------------------------------------------------------- 1302 SEND Keepalive - - 1304 4. EVENT: Send timeout 1305 ====================== 1307 Operational Exploring ExploringOk 1308 --------------------------------------------------------------- 1309 SEND Probe Y=No; - SEND Probe Y=No 1310 STOP Keepalive; GOTO EXPLORING 1311 GOTO EXPLORING 1312 5. EVENT: Reception of the Keepalive message 1313 ============================================ 1315 Operational Exploring ExploringOk 1316 --------------------------------------------------------------- 1317 STOP Send SEND Probe Y=Yes; STOP Send 1318 START Send; 1319 GOTO ExploringOk 1321 6. EVENT: Reception of the Probe message with Y=No 1322 ================================================== 1324 Operational Exploring ExploringOk 1325 --------------------------------------------------------------- 1326 SEND Probe Y=Yes SEND Probe Y=Yes; SEND Probe Y=Yes; 1327 STOP Keepalive; START Send; RESTART Send 1328 RESTART Send; GOTO EXPLORINGOK 1329 GOTO EXPLORINGOK 1331 7. EVENT: Reception of the Probe message with Y=Yes 1332 (peer reports not seeing yet a Probe with Y=Yes) 1333 ========================================================== 1335 Operational Exploring ExploringOk 1336 --------------------------------------------------------------- 1337 SEND Probe Y=Yes; SEND Probe Y=Yes; SEND Probe Y=Yes; 1338 RESTART Send; RESTART Send; RESTART Send; 1339 STOP Keepalive GOTO OPERATIONAL GOTO OPERATIONAL 1341 8. EVENT: Reception of the Probe message with Y=Yes 1342 (peer reports seeing a Probe with Y=Yes) 1343 =================================================== 1345 Operational Exploring ExploringOk 1346 --------------------------------------------------------------- 1347 STOP Send STOP Send; STOP Send; 1348 START Keepalive START Keepalive START Keepalive 1349 GOTO OPERATIONAL GOTO OPERATIONAL 1351 9. EVENT: Retransmission 1352 ======================== 1354 Operational Exploring ExploringOk 1355 --------------------------------------------------------------- 1356 - SEND Probe Y=No SEND Probe Y=Yes 1357 START Send 1359 6.5. Protocol Constants 1361 The following protocol constants are defined: 1363 Send Timeout 10 seconds 1364 Keepalive Timeout 3 seconds 1366 7. Security Considerations 1368 Attackers may spoof various indications from lower layers and the 1369 network in an effort to confuse the peers about which addresses are 1370 or are not working. For example, attackers may spoof ICMP error 1371 messages in an effort to cause the parties to move their traffic 1372 elsewhere or even to disconnect. Attackers may also spoof 1373 information related to network attachments, router discovery, and 1374 address assignments in an effort to make the parties believe they 1375 have Internet connectivity when in reality they do not. 1377 This may cause use of non-preferred addresses or even denial-of- 1378 service. 1380 This protocol does not provide any protection of its own for 1381 indications from other parts of the protocol stack. However, this 1382 protocol has weak resistance against incorrect information from these 1383 sources in the sense that it performs its own tests prior to picking 1384 a new address pair. Denial-of- service vulnerabilities remain, 1385 however, as do vulnerabilities against on path attackers. 1387 Some aspects of these vulnerabilities can be mitigated through the 1388 use of techniques specific to the other parts of the stack, such as 1389 properly dealing with ICMP errors [22], link layer security, or the 1390 use of [12] to protect IPv6 Router and Neighbor Discovery. 1392 This protocol is designed to be used in situations where other parts 1393 of the stack have ensured that a set of addresses belong together, 1394 such as via SHIM6 HBAs [17]. That is, REAP itself provides no 1395 assurance that a set of addresses belongs to the same host. 1396 Similarly, REAP provides only minimal protection against third party 1397 flooding attacks; when REAP is run its Probe identifiers can be used 1398 as a return routability check that the claimed address is indeed 1399 willing to receive traffic. However, this needs to be complemented 1400 with another mechanism to ensure that the claimed address is also the 1401 correct host. In SHIM6 this is performed by binding all operations 1402 to context tags. 1404 Finally, the exploration itself can cause a number of packets to be 1405 sent. As a result it may be used as a tool for packet amplification 1406 in flooding attacks. In order to prevent this it is required that 1407 the protocol employing REAP has built-in mechanisms to prevent this. 1408 For instance, in SHIM6 contexts are created only after a relatively 1409 large number of packets has been exchanged, a cost which reduces the 1410 attractiveness of using SHIM6 and REAP for amplification attacks. 1411 However, such protections are typically not present at connection 1412 establishment time. When exploration would be needed for connection 1413 establishment to succeed, its usage would result in an amplification 1414 vulnerability. As a result, SHIM6 does not support the use of REAP 1415 in connection establishment stage. 1417 8. IANA Considerations 1419 This document creates one new name spaces under the new SHIM6 1420 Reachability Protocol repository. The name space is for Reachability 1421 Option Type (Section 6.3) and it has one reserved value (0) and two 1422 defined values, 1 (Payload Reception Report defined in Section 6.3.1) 1423 and 2 (Probe Reception Report defined in Section 6.3.2). Further 1424 allocations within this 16-bit field can be made through 1425 Specification Required. The range from 65000 to 65535 is reserved 1426 for experimental use. 1428 9. References 1430 9.1. Normative References 1432 [1] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1433 Recommendations for Security", RFC 1750, December 1994. 1435 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1436 Levels", BCP 14, RFC 2119, March 1997. 1438 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1439 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1441 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 1442 Autoconfiguration", RFC 2462, December 1998. 1444 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1445 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1446 RFC 3315, July 2003. 1448 [6] Draves, R., "Default Address Selection for Internet Protocol 1449 version 6 (IPv6)", RFC 3484, February 2003. 1451 [7] Choi, J., "Detecting Network Attachment in IPv6 Goals", 1452 draft-ietf-dna-goals-00 (work in progress), June 2004. 1454 [8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 1455 draft-ietf-ipv6-optimistic-dad-01 (work in progress), June 2004. 1457 [9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1458 Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in 1459 progress), June 2004. 1461 9.2. Informative References 1463 [10] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1464 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 1465 Paxson, "Stream Control Transmission Protocol", RFC 2960, 1466 October 2000. 1468 [11] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 1469 - Simple Traversal of User Datagram Protocol (UDP) Through 1470 Network Address Translators (NATs)", RFC 3489, March 2003. 1472 [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1473 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1475 [13] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 1476 draft-ietf-dhc-dna-ipv4-08 (work in progress), July 2004. 1478 [14] Nikander, P., "End-Host Mobility and Multi-Homing with Host 1479 Identity Protocol", draft-ietf-hip-mm-00 (work in progress), 1480 October 2004. 1482 [15] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 1483 draft-ietf-mobike-protocol-03 (work in progress), 1484 September 2005. 1486 [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1487 Methodology for Network Address Translator (NAT) Traversal for 1488 Multimedia Session Establishment Protocols", 1489 draft-ietf-mmusic-ice-02 (work in progress), July 2004. 1491 [17] Bagnulo, M., "Hash Based Addresses (HBA)", 1492 draft-ietf-shim6-hba-00 (work in progress), July 2005. 1494 [18] Nordmark, E., "Level 3 multihoming shim protocol", 1495 draft-ietf-shim6-proto-00 (work in progress), October 2005. 1497 [19] Beijnum, I., "Shim6 Reachability Detection", 1498 draft-ietf-shim6-reach-detect-00 (work in progress), July 2005. 1500 [20] Stewart, R., "Stream Control Transmission Protocol (SCTP) 1501 Dynamic Address Reconfiguration", 1502 draft-ietf-tsvwg-addip-sctp-10 (work in progress), 1503 January 2005. 1505 [21] Bagnulo, M., "Address selection in multihomed environments", 1506 draft-bagnulo-shim6-addr-selection-00 (work in progress), 1507 October 2005. 1509 [22] Gont, F., "ICMP attacks against TCP", 1510 draft-gont-tcpm-icmp-attacks-00 (work in progress), 1511 August 2004. 1513 [23] Huitema, C., "Address selection in multihomed environments", 1514 draft-huitema-multi6-addr-selection-00 (work in progress), 1515 October 2004. 1517 [24] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 1518 draft-rosenberg-midcom-turn-05 (work in progress), July 2004. 1520 [25] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location 1521 Management", In Proceedings of the 18th Annual Computer 1522 Security Applications Conference, Las Vegas, Nevada, USA., 1523 December 2002. 1525 Appendix A. Contributors 1527 This draft attempts to summarize the thoughts and unpublished 1528 contributions of many people, including the MULTI6 WG design team 1529 members Marcelo Bagnulo Braun, Iljitsch van Beijnum, Erik Nordmark, 1530 Geoff Huston, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG 1531 contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer 1532 Dawkins, and James Kempf, and my colleague Pekka Nikander at 1533 Ericsson. This draft is also in debt to work done in the context of 1534 SCTP [10] and HIP [14]. 1536 Appendix B. Acknowledgements 1538 The author would also like to thank Christian Huitema, Pekka Savola, 1539 and Hannes Tschofenig for interesting discussions in this problem 1540 space, and for their comments on earlier versions of this draft. 1542 Authors' Addresses 1544 Jari Arkko 1545 Ericsson 1546 Jorvas 02420 1547 Finland 1549 Email: jari.arkko@ericsson.com 1551 Iljitsch van Beijnum 1552 Muada 1553 The Netherlands 1555 Email: iljitsch@muada.com 1557 Intellectual Property Statement 1559 The IETF takes no position regarding the validity or scope of any 1560 Intellectual Property Rights or other rights that might be claimed to 1561 pertain to the implementation or use of the technology described in 1562 this document or the extent to which any license under such rights 1563 might or might not be available; nor does it represent that it has 1564 made any independent effort to identify any such rights. Information 1565 on the procedures with respect to rights in RFC documents can be 1566 found in BCP 78 and BCP 79. 1568 Copies of IPR disclosures made to the IETF Secretariat and any 1569 assurances of licenses to be made available, or the result of an 1570 attempt made to obtain a general license or permission for the use of 1571 such proprietary rights by implementers or users of this 1572 specification can be obtained from the IETF on-line IPR repository at 1573 http://www.ietf.org/ipr. 1575 The IETF invites any interested party to bring to its attention any 1576 copyrights, patents or patent applications, or other proprietary 1577 rights that may cover technology that may be required to implement 1578 this standard. Please address the information to the IETF at 1579 ietf-ipr@ietf.org. 1581 Disclaimer of Validity 1583 This document and the information contained herein are provided on an 1584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1591 Copyright Statement 1593 Copyright (C) The Internet Society (2005). This document is subject 1594 to the rights, licenses and restrictions contained in BCP 78, and 1595 except as set forth therein, the authors retain all their rights. 1597 Acknowledgment 1599 Funding for the RFC Editor function is currently provided by the 1600 Internet Society.