idnits 2.17.1 draft-ietf-shim6-failure-detection-05.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 1541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1565. ** 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 issues found here. 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 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 (June 26, 2006) is 6513 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-00 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-03 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-05 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 Intended status: Informational I. Beijnum 5 Expires: December 28, 2006 Muada 6 June 26, 2006 8 Failure Detection and Locator Pair Exploration Protocol for IPv6 9 Multihoming 10 draft-ietf-shim6-failure-detection-05 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 December 28, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document specifies how the level 3 multihoming shim protocol 44 (SHIM6) detects failures between two communicating hosts. It also 45 specifies an exploration protocol for switching to another pair of 46 interfaces and/or addresses between the same hosts if a failure 47 occurs and an operational pair can be found. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 53 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Available Addresses . . . . . . . . . . . . . . . . . . 5 55 3.2. Locally Operational Addresses . . . . . . . . . . . . . 6 56 3.3. Operational Address Pairs . . . . . . . . . . . . . . . 6 57 3.4. Current Address Pair . . . . . . . . . . . . . . . . . . 8 58 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 59 4.1. Failure Detection . . . . . . . . . . . . . . . . . . . 9 60 4.2. Alternative Address Pair Exploration . . . . . . . . . . 11 61 4.3. Exploration Order . . . . . . . . . . . . . . . . . . . 11 62 4.4. Protocol Design . . . . . . . . . . . . . . . . . . . . 12 63 4.5. Example Protocol Runs . . . . . . . . . . . . . . . . . 13 64 4.6. Limitations . . . . . . . . . . . . . . . . . . . . . . 19 65 5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 20 66 5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 20 67 5.1.1. Keepalive Option . . . . . . . . . . . . . . . . 21 68 5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 22 69 5.2.1. Probe Option . . . . . . . . . . . . . . . . . . 24 70 5.3. Reachability Option . . . . . . . . . . . . . . . . . . 25 71 5.3.1. Payload Reception Report . . . . . . . . . . . . 26 72 5.3.2. Probe Reception Report . . . . . . . . . . . . . 26 73 5.4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . 27 74 5.5. Protocol Constants . . . . . . . . . . . . . . . . . . . 31 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 35 79 8.2. Informative References . . . . . . . . . . . . . . . . . 35 80 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37 81 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 83 Intellectual Property and Copyright Statements . . . . . . . . . . 40 85 1. Introduction 87 The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support 88 multihoming. It is an IP layer mechanism that hides multihoming from 89 applications. A part of the SHIM6 solution involves detecting when a 90 currently used pair of addresses (or interfaces) between two 91 communication hosts has failed, and picking another pair when this 92 occurs. We call the former failure detection, and the latter locator 93 pair exploration. 95 This document specifies the mechanisms and protocol messages to 96 achieve both failure detection and locator pair exploration. This 97 part of the SHIM6 protocol is called the REAchability Protocol 98 (REAP). 100 The document is structured as follows: Section 3 defines a set of 101 useful terms, Section 4 gives an overview of REAP, and Section 5 102 specifies the message formats and behaviour in detail. Section 6 103 discusses the security considerations of REAP. 105 In this specification, we consider an address to be synonymous with a 106 locator. Other parts of the SHIM6 protocol ensure that the different 107 locators used by a node actually belong together. That is, REAP is 108 not responsible for ensuring that it ends up with a legitimate 109 locator. 111 2. Requirements language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Definitions 119 This section defines terms useful for discussing failure detection 120 and locator pair exploration. 122 3.1. Available Addresses 124 SHIM6 nodes need to be aware of what addresses they themselves have. 125 If a node loses the address it is currently using for communications, 126 another address must replace this address. And if a node loses an 127 address that the node's peer knows about, the peer must be informed. 128 Similarly, when a node acquires a new address it may generally wish 129 the peer to know about it. 131 Definition. Available address. An address is said to be available 132 if the following conditions are fulfilled: 134 o The address has been assigned to an interface of the node. 136 o The address is valid in the sense of RFC 2461 [RFC2461]. 138 o The address is not tentative in the sense of RFC 2462 [RFC2462]. 139 In other words, the address assignment is complete so that 140 communications can be started. 142 Note that this explicitly allows an address to be optimistic in 143 the sense of Optimistic DAD [RFC4429] even though implementations 144 may prefer using other addresses as long as there is an 145 alternative. 147 o The address is a global unicast, unique local address [RFC4193], 148 or an unambiguous IPv6 link-local address. That is, it is not an 149 IPv6 site-local address. 151 Where IPv6 link-local addresses are used, their use needs to be 152 unambiguous as follows. At most one link-local address may be 153 used per node within the same connection between two peers. 155 o The address and interface is acceptable for use according to a 156 local policy. 158 Available addresses are discovered and monitored through mechanisms 159 outside the scope of SHIM6. SHIM6 implementations MUST be able to 160 employ information provided by IPv6 Neighbor Discovery [RFC2461], 161 Address Autoconfiguration [RFC2462], and DHCP [RFC3315]. This 162 information includes the availability of a new address and status 163 changes of existing addresses (such as when an address becomes 164 invalid). 166 3.2. Locally Operational Addresses 168 Two different granularity levels are needed for failure detection. 169 The coarser granularity is for individual addresses: 171 Definition. Locally Operational Address. An available address is 172 said to be locally operational when its use is known to be possible 173 locally: the interface is up, a default router (if needed) suitable 174 for this address is known to be reachable, and no other local 175 information points to the address being unusable. 177 Locally operational addresses are discovered and monitored through 178 mechanisms outside the SHIM6 protocol. SHIM6 implementations MUST be 179 able to employ information provided from Neighbor Unreachability 180 Detection [RFC2461]. Implementations MAY also employ additional, 181 link layer specific mechanisms. 183 Note 1: A part of the problem in ensuring that an address is 184 operational is making sure that after a change in link layer 185 connectivity we are still connected to the same IP subnet. 186 Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6 187 [I-D.ietf-dna-protocol] can be used to ensure this. 189 Note 2: In theory, it would also be possible for hosts to learn 190 about routing failures for a particular selected source prefix, if 191 only suitable protocols for this purpose existed. Some proposals 192 in this space have been made, see, for instance 193 [I-D.bagnulo-shim6-addr-selection] and 194 [I-D.huitema-multi6-addr-selection], but none have been 195 standardized to date. 197 3.3. Operational Address Pairs 199 The existence of locally operational addresses are not, however, a 200 guarantee that communications can be established with the peer. A 201 failure in the routing infrastructure can prevent packets from 202 reaching their destination. For this reason we need the definition 203 of a second level of granularity, for pairs of addresses: 205 Definition. Bidirectionally operational address pair. A pair of 206 locally operational addresses are said to be an operational address 207 pair, iff bidirectional connectivity can be shown between the 208 addresses. That is, a packet sent with one of the addresses in the 209 source field and the other in the destination field reaches the 210 destination, and vice versa. 212 Unfortunately, there are scenarios where bidirectionally operational 213 address pairs do not exist. For instance, ingress filtering or 214 network failures may result in one address pair being operational in 215 one direction while another one is operational from the other 216 direction. The following definition captures this general situation: 218 Definition. Unidirectionally operational address pair. A pair of 219 locally operational addresses are said to be an unidirectionally 220 operational address pair, iff packets sent with the first address as 221 the source and the second address as the destination can be shown to 222 reach the destination. 224 SHIM6 implementations MUST support the discovery of operational 225 address pairs through the use of explicit rechability tests and 226 Forced Bidirectional Communication (FBD), described later in this 227 specification. In addition, implementations MAY employ the following 228 additional mechanisms: 230 o Positive feedback from upper layer protocols. For instance, TCP 231 can indicate to the IP layer that it is making progress. This is 232 similar to how IPv6 Neighbor Unreachability Detection can in some 233 cases be avoided when upper layers provide information about 234 bidirectional connectivity [RFC2461]. 236 In the case of unidirectional connectivity, the upper layer 237 protocol responses come back using another address pair, but show 238 that the messages sent using the first address pair have been 239 received. 241 o Negative feedback from upper layer protocols. It is conceivable 242 that upper layer protocols give an indication of a problem to the 243 multihoming layer. For instance, TCP could indicate that there's 244 either congestion or lack of connectivity in the path because it 245 is not getting ACKs. 247 o ICMP error messages. Given the ease of spoofing ICMP messages, 248 one should be careful to not trust these blindly, however. Our 249 suggestion is to use ICMP error messages only as a hint to perform 250 an explicit reachability test, but not as a reason to disrupt 251 ongoing communications without other indications of problems. The 252 situation may be different when certain verifications of the ICMP 253 messages are being performed, as explained by Gont in 254 [I-D.ietf-tcpm-icmp-attacks]. These verifications can ensure that 255 (practically) only on-path attackers can spoof the messages. 257 Note SHIM6 needs to perform a return routability test of an address 258 before it is taken into use. The purpose of this test is to ensure 259 that fraudulent peers do not trick others into redirecting traffic 260 streams onto innocent victims. For a discussion of such attacks, see 261 Aura et al [AURA02]. The test can at the same time work as a means 262 to ensure that an address pair is operational, as discussed in 263 Section 4.2. 265 3.4. Current Address Pair 267 SHIM6 needs to avoid sending packets concurrently over multiple 268 paths, because congestion control in commonly used transport 269 protocols is based upon a notion of a single path. While routing can 270 introduce path changes as well and transport protocols have means to 271 deal with this, frequent changes will cause problems. Efficient 272 congestion control over multible paths is a considered research at 273 the time this specification is written. 275 For these reasons it is necessary to choose a particular pair of 276 addresses as the current address pair which is used until problems 277 occur, at least for the same session. 279 A current address pair need not be operational at all times. If 280 there is no traffic to send, we may not know if the primary address 281 pair is operational. Nevertheless, it makes sense to assume that the 282 address pair that worked in some time ago continues to be operational 283 for new communications as well. 285 4. Protocol Overview 287 This section discusses the design of the reachability detection and 288 address pair exploration mechanisms, and gives on overview of the 289 REAP protocol. 291 Exploring the full set of communication options between two hosts 292 that both have two or more addresses is an expensive operation as the 293 number of combinations to be explored increases very quickly with the 294 number of addresses. For instance, with two addresses on both sides, 295 there are four possible address pairs. Since we can't assume that 296 reachability in one direction automatically means reachability for 297 the complement pair in the other direction, the total number of two- 298 way combinations is eight. (Combinations = nA * nB * 2.) 300 An important observation in multihoming is that failures are 301 relatively infrequent, so that an operational pair that worked a few 302 seconds ago is very likely to be still operational. So it makes 303 sense to have a light-weight protocol that confirms existing 304 reachability, and only invoke heavier exploration when a there is a 305 suspected failure. 307 4.1. Failure Detection 309 Failure detection consists of three parts: tracking local 310 information, tracking remote peer status, and finally verifying 311 reachability. Tracking local information consists of using, for 312 instance, reachability information about the local router as an 313 input. Nodes SHOULD employ techniques listed in Section 3.1 and 314 Section 3.2 to be track the local situation. It is also necessary to 315 track remote address information from the peer. For instance, if the 316 peer's currently used address is no longer in use, mechanism to relay 317 that information is needed. The Update message in the SHIM6 protocol 318 is used for this purpose [I-D.ietf-shim6-proto]. Finally, when the 319 local and remote information indicates that communication should be 320 possible and there are upper layer packets to be sent, reachability 321 verification is necessary to ensure that the peers actually have an 322 operational pair. 324 A technique called Forced Bidirectional Detection (FBD, originally 325 defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect]) 326 is employed for the reachability verification. Reachability for the 327 currently used address pair in a shim context is determined by making 328 sure that whenever there is data traffic in one direction, there is 329 also traffic in the other direction. This can be data traffic as 330 well, but also transport layer acknowledgments or a REAP reachability 331 keepalive if there is no other traffic. This way, it is no longer 332 possible to have traffic in only one direction, so whenever there is 333 data traffic going out, but there are no return packets, there must 334 be a failure, so the full exploration mechanism is started. 336 A more detailed description of the current pair reachability 337 evaluation mechanism: 339 1. The base timing unit for this mechanism is named Keepalive 340 Timeout. Until a negotiation mechanism to negotiate different 341 values for this timer becomes available, the value (3 seconds) 342 specified in Section 5.5 SHOULD be used. 344 2. Whenever outgoing data packets are generated, a timer is started 345 to reflect the requirement that the peer should generate return 346 traffic from data packets. 348 For the purposes of this specification, "data packet" refers to 349 any packet that is part of a shim context, including both upper 350 layer protocol packets and SHIM6 protocol messages except those 351 defined in this specification. 353 3. Whenever incoming data packets are received, the timer associated 354 with the return traffic from the peer is stopped, and another 355 timer is started to reflect the requirement for this node to 356 generate return traffic. 358 4. The reception of a REAP keepalive packet leads to stopping the 359 timer associated with the return traffic from the peer. 361 5. Keepalive Timeout seconds after the last data packet has been 362 received for a context, and if no other packet has been sent 363 within this context since the data packet has been received, a 364 REAP keepalive packet is generated for the context in question 365 and transmitted to the correspondent. A host may send the 366 keepalive sooner than Keepalive Timeout seconds if implementation 367 considerations warrant this. The average time after which 368 keepalives are sent MUST be at least Keepalive Timeout / 2 369 seconds. After sending a single keepalive message, no additional 370 keepalive messages are sent until a data packet is received 371 within this shim context. Keepalives are not sent at all when a 372 data packet was sent since the last received data packet. 374 6. Send Timeout seconds (10 s; see Section 5.5) after the 375 transmission of a data packet with no return traffic on this 376 context, a full reachability exploration is started. This 377 timeout period is larger than the Keepalive Timeout to 378 accommodate for lost keepalives and regular variations in round 379 trip times. 381 4.2. Alternative Address Pair Exploration 383 As explained in previous section, the currently used address pair may 384 become invalid either through one of the addresses being becoming 385 unavailable or inoperational, or the pair itself being declared 386 inoperational. An exploration process attempts to find another 387 operational pair so that communications can resume. 389 What makes this process hard is the requirement to support 390 unidirectionally operational address pairs. It is insufficient to 391 probe address pairs by a simple request - response protocol. 392 Instead, the party that first detects the problem starts a process 393 where it tries each of the different address pairs in turn by sending 394 a message to its peer. These messages carry information about the 395 state of connectivity between the peers, such as whether the sender 396 has seen any traffic from the peer recently. When the peer receives 397 a message that indicates a problem, it assists the process by 398 starting its own parallel exploration to the other direction, again 399 sending information about the recently received payload traffic or 400 signaling messages. 402 Specifically, when A decides that it needs to explore for an 403 alternative address pair to B, it will initiate a set of Probe 404 messages, in sequence, until it gets an Probe message from B 405 indicating that (a) B has received one of A's messages and, 406 obviously, (b) that B's Probe message gets back to A. B uses the same 407 algorithm, but starts the process from the reception of the first 408 Probe message from A. 410 Upon changing to a new address pair, the network path traversed most 411 likely has changed, so that the ULP SHOULD be informed. This can be 412 a signal for the ULP to adapt due to the change in path so that, for 413 example, TCP could initiate a slow start procedure. 415 Similarly, one can also envision that applications would be able to 416 tell the IP or transport layer that the current connection in 417 unsatisfactory and an exploration for a better one would be 418 desirable. This would require an API to be developed, however. In 419 any case, this is another issue that we treat as being outside the 420 scope of pure address exploration. 422 4.3. Exploration Order 424 The exploration process assumes an ability to choose address pairs 425 for testing, in some sequence. This process may result in a 426 combinatorial explosion when there are many addresses on both sides, 427 but a back-off procedure is employed to avoid a "signaling storm". 429 Nodes first consult the RFC 3484 default address selection rules 430 [RFC3484] Section 4 rules to determine what combinations of addresses 431 are allowed from a local point of view, as this reduces the search 432 space. RFC 3484 also provides a priority ordering among different 433 address pairs, making the search possibly faster. Nodes may also use 434 local information, such as known quality of service parameters or 435 interface types to determine what addresses are preferred over 436 others, and try pairs containing such addresses first. The SHIM6 437 protocol also carries preference information in its messages. 439 Discussion note: The preferences may either be learned dynamically 440 or be configured. It is believed, however, that dynamic learning 441 based purely on the multihoming protocol is too hard and not the 442 task this layer should do. Solutions where multiple protocols 443 share their information in a common pool of locators could provide 444 this information from transport protocols, however. 446 Out of the set of possible candidate address pairs, nodes SHOULD 447 attempt to test through all of them until an operational pair is 448 found, and retrying the process as is necessary. However, all nodes 449 MUST perform this process sequentially and with exponential back-off. 450 This sequential process is necessary in order to avoid a "signaling 451 storm" when an outage occurs (particularly for a complete site). 452 However, it also limits the number of addresses that can in practice 453 be used for multihoming, considering that transport and application 454 layer protocols will fail if the switch to a new address pair takes 455 too long. 457 Section 5.5 suggests default values for the timers associated with 458 the exploration process. The value Initial Probe Timeout (0.5 s) 459 specifies the interval between initial attempts to send probes; 460 Number of Initial Probes (4) specifies how many initial probes can be 461 sent before the exponential backoff procedure needs to be employed. 462 This process duplicates the time between every probe if there is no 463 response. Finally, Max probe Timeout (60 s) specifies a limit beyond 464 which the probe interval may not grow. If the exploration process 465 reaches this interval, it will continue sending at this rate until a 466 suitable response is triggered or the SHIM6 context is garbage 467 collected. 469 4.4. Protocol Design 471 REAP is designed as a modular part of SHIM6 in the hopes that it may 472 also be useful in other contexts. This document defines how it is 473 carried within SHIM6, but the actual protocol messages are self- 474 contained so that it could be carried by other protocols as well. 476 The REAP design allows performing both failure detection and address 477 pair exploration in the same sequence of messages, without a need to 478 designate a specific point when the current address pair is declared 479 inoperational and the search for a new pair begins. This is useful, 480 as the loss of a small number of packets is not a proof that a 481 problem exists. Integrated failure detection and exploration allows 482 us to test multiple address pairs simultaneously, including the 483 current pair in case it becomes operational again. For instance, the 484 exploration process can refer to keepalive message that succeeded in 485 getting to the peer during the reachability testing phase. 487 REAP also integrates a return routability function, making it 488 unnecessary to perform another roundtrip before a newly discovered 489 address can be taken into use. 491 This document defines a minimal set of parameters that are carried by 492 the messages of the protocol. Specifically, we have limited the 493 parameters to those that are necessary to find an operational address 494 pair. We note there may be extensions that are needed in the future 495 for various reasons, such as the desire to support load balancing or 496 finding best pairs. An option format has been specified to allow 497 this. 499 4.5. Example Protocol Runs 501 This section has examples of REAP protocol runs in typical scenarios. 502 We start with the simplest scenario of two hosts, A and B, that have 503 a SHIM6 connection with each other but are not currently sending any 504 data. As neither side sends anything, they also do not expect 505 anything back, so there are no messages at all: 507 EXAMPLE 1: No communications 509 Peer A Peer B 510 | | 511 | | 512 | | 513 | | 514 | | 515 | | 516 | | 517 | | 519 Our second example involves an active connection with bidirectional 520 payload packet flows. Here the reception of data from the peer is 521 taken as an indication of reachability, so again there are no extra 522 packes: 524 EXAMPLE 2: Bidirectional communications 526 Peer A Peer B 527 | | 528 | payload packet | 529 |-------------------------------------------->| 530 | | 531 | payload packet | 532 |<--------------------------------------------| 533 | | 534 | payload packet | 535 |-------------------------------------------->| 536 | | 537 | | 539 The third example is the first one that involves an actual REAP 540 message. Here the hosts communicate in just one direction, so REAP 541 messages are needed to indicate to the peer that sends payload 542 packets that its packets are getting through: 544 EXAMPLE 3: Unidirectional communications 546 Peer A Peer B 547 | | 548 | payload packet | 549 |-------------------------------------------->| 550 | | 551 | payload packet | 552 |-------------------------------------------->| 553 | | 554 | payload packet | 555 |-------------------------------------------->| 556 | | 557 | Keepalive id=p | 558 |<--------------------------------------------| 559 | | 560 | payload packet | 561 |-------------------------------------------->| 562 | | 563 | | 565 The next example involves a failure scenario. Here A has addresses 566 A1 and A2 and B has addresses B1 and B2. The currently used address 567 pairs are (A1, B1) and (B1, A1). The first of these becomes broken, 568 which leads to an exploration process: 570 EXAMPLE 4: Failure scenario 572 Peer A Peer B 573 | | 574 | (A1,B1) payload packet | 575 |-------------------------------------------->| 576 | | 577 | (B1,A1) payload packet | 578 |<--------------------------------------------| Time T1 579 | | Path A1->B1 580 | (A1,B1) payload packet | is now 581 |----------------------------------------/ | broken 582 | | 583 | (B1,A1) payload packet | 584 |<--------------------------------------------| 585 | | 586 | (A1,B1) payload packet | 587 |----------------------------------------/ | 588 | | 589 | (B1,A1) payload packet | 590 |<--------------------------------------------| 591 | | 592 | (A1,B1) payload packet | 593 |----------------------------------------/ | 594 | | 595 | | 10 seconds after 596 | | T1, sends a com- 597 | (B1,A1) Probe id=p, | plaint that 598 | iseeyou=no | it is not rec- 599 |<--------------------------------------------| eiving anything 600 | | 601 A realizes | 602 that it needs | 603 to start the | 604 exploration | 605 | | 606 | (A1, B1) Probe id=q, | 607 | iseeyou=yes | 608 | payload reception rep | 609 | probe reception rep(p) | But it gets lost 610 |-------------------------------------/ | due to broken path 611 | | 612 Retransmission | 613 to a different | 614 address | 615 | | 616 | (A1, B2) Probe id=r, | 617 | iseeyou=yes | 618 | payload reception rep | 619 | probe reception rep(p) | This one gets 620 |-------------------------------------------->| through. Note 621 | | that B would also 622 | | have retransmitted 623 | | soon, but in this 624 | | example A got 625 | | through first 626 | | 627 | | 628 | | B now knows 629 | | that A has no 630 | (B1,A1) Probe id=p, | problem to receive 631 | iseeyou=yes, | its packets and 632 | probe reception rep(r) | This one gets 633 |<--------------------------------------------| that A has found 634 | | a new path to B 635 | | 636 | (A1,B2) payload packet | 637 |-------------------------------------------->| Payload packets 638 | | flow again 639 | (B1,A1) payload packet | 640 |<--------------------------------------------| 642 The next example shows when the failure for the current locator pair 643 is in the other direction: 645 EXAMPLE 5: One-way failure 647 Peer A Peer B 648 | | 649 | (A1,B1) payload packet | 650 |-------------------------------------------->| 651 | | 652 | (B1,A1) payload packet | 653 | /-----------------------------------------| Time T1 654 | | Path B1->A1 655 | | is now 656 | | broken 657 | (B1,A1) payload packet | 658 | /-----------------------------------------| 659 | | 660 | (B1,A1) payload packet | 661 | /-----------------------------------------| 662 | | 663 | | 10 seconds after 664 | | T1, sends a com- 665 | (B1,A1) Probe id=p, | plaint that 666 | iseeyou=no | it is not rec- 667 | /-----------------------------------------| eiving anything 668 | | 669 | (B2,A2) Probe id=q, | 670 | iseeyou=no | Next try different 671 |<--------------------------------------------| locator pair 672 | | 673 | (A2, B2) Probe id=r, | 674 | iseeyou=yes | 675 | payload reception rep | 676 | probe reception rep(q) | This one gets 677 |-------------------------------------------->| through 678 | | 679 | | 680 | | B now knows 681 | | that A has no 682 | (B2,A2) Probe id=s, | problem to receive 683 | iseeyou=yes, | its packets and 684 | probe reception rep(r) | This one gets 685 |<--------------------------------------------| that A has found 686 | | a new path to B 687 | | 688 | (A2,B2) payload packet | 689 |-------------------------------------------->| Payload packets 690 | | flow again 691 | (B2,A2) payload packet | 692 |<--------------------------------------------| 694 In the next case we have even less luck. The response to the REAP 695 probe doesn't make it in the reverse direction, so both ends end up 696 exploring independently: 698 EXAMPLE 6: Independent exploration 700 Peer A Peer B 701 | | 702 | (A1,B1) payload packet | 703 |-------------------------------------------->| 704 | | 705 | (B1,A1) payload packet | 706 | /-----------------------------------------| Time T1 707 | | Path B1->A1 708 | | is now 709 | | broken 710 | (B1,A1) payload packet | 711 | /-----------------------------------------| 712 | | 713 | (B1,A1) payload packet | 714 | /-----------------------------------------| 715 | | 716 | | 10 seconds after 717 | | T1, sends a com- 718 | (B1,A1) Probe id=p, | plaint that 719 | iseeyou=no | it is not rec- 720 | /-----------------------------------------| eiving anything 721 | | 722 | (B2,A2) Probe id=q, | 723 | iseeyou=no | Next try different 724 |<--------------------------------------------| locator pair 725 | | 726 A now knows that it needs | 727 to start exploring | 728 | | 729 | (A2, B2) Probe id=r, | 730 | iseeyou=yes | 731 | payload reception rep | 732 | probe reception rep(q) | 733 |--------------------------------------/ | Doesn't make it 734 | | 735 | (A1, B1) Probe id=s, | 736 | iseeyou=yes | 737 | payload reception rep | 738 | probe reception rep(q) | This one gets 739 |-------------------------------------------->| through 740 | | 741 | | 742 | | B now knows 743 | | that A has no 744 | (B2,A2) Probe id=t, | problem to receive 745 | iseeyou=yes, | its packets and 746 | probe reception rep(r) | This one gets 747 |<--------------------------------------------| that A has found 748 | | a new path to B 749 | | 750 | (A1,B1) payload packet | 751 |-------------------------------------------->| Payload packets 752 | | flow again 753 | (B2,A2) payload packet | 754 |<--------------------------------------------| 756 4.6. Limitations 758 REAP is designed to support failure recovery even in the case of 759 having only unidirectionally operational address pairs. However, due 760 to security concerns discussed in Section 6, the exploration process 761 can typically be run only for a session that has already been 762 established. Specifically, while REAP would in theory be capable of 763 exploration even during connection establishment, its use within the 764 SHIM6 protocol does not allow this. 766 5. Protocol Definition 768 5.1. Keepalive Message 770 The format of the keepalive message is as follows: 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Next Header | Hdr Ext Len |0| Type = 66 | Reserved |0| 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Checksum |R| | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 779 | Receiver Context Tag | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | | 782 + Options + 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Next Header 788 This value MUST be set to NO_NXT_HDR (59). 790 Hdr Ext Len 792 This is an 8-bit unsigned integer field, calculated as specified 793 in Section 5.3 of the SHIM6 protocol description 794 [I-D.ietf-shim6-proto]. 796 Type 798 This field identifies the Probe message and MUST be set to 66 799 (Keepalive). 801 Reserved 803 This is a 7-bit field reserved for future use. It is set to zero 804 on transmit, and MUST be ignored on receipt. 806 R 808 This is a 1-bit field reserved for future use. It is set to zero 809 on transmit, and MUST be ignored on receipt. 811 Checksum 813 This is a 16-bit field, calculated as specified in Section 5.3 of 814 the SHIM6 protocol description [I-D.ietf-shim6-proto]. 816 Receiver Context Tag 818 This is a 47-bit field for the Context Tag the receiver has 819 allocated for the context. 821 Options 823 This MUST contain at least the Keepalive option and MAY contain 824 one or more Reachability options.The inclusion of the latter 825 options is not necessary, however, as there are currently no 826 defined options that are useful in a Keepalive message. These 827 options are provided only for future extensibility reasons. 829 A valid message conforms to the format above, has a Receiver Context 830 Tag that matches to context known by the receiver, is valid shim 831 control message as defined in Section 12.2 of the SHIM6 protocol 832 description [I-D.ietf-shim6-proto], and its shim context state is 833 ESTABLISHED. The receiver processes a valid message by inspecting 834 its options, and executing any actions specified for such options. 836 The processing rules for this message are the given in more detail in 837 Section 5.4. 839 5.1.1. Keepalive Option 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type = 10 |0| Length | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Res | Identifier | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Type 851 This value MUST be set to 10 (Keepalive Option). 853 0 855 This value MUST be set to 0, as in other SHIM6 options. 857 Length 859 This is the length of the option and MUST be calculated as 860 specified in Section 5.14 of the SHIM6 protocol description 861 [I-D.ietf-shim6-proto]. 863 Res 865 This 4-bit reserved field MUST be set to zero when sending, and 866 ignored on receipt. 868 Identifier 870 This 28-bit field identifies this particular instance of an 871 Keepalive message. This value SHOULD be generated using a random 872 number generator that is known to have good randomness properties 873 as outlined in RFC 1750 [RFC1750]. Upon reception, Identifier 874 values from both Keepalive and Probe messages may be copied onto 875 Probe Reception Report options. This allows them to be used for 876 both identifying which packets were received as well as for 877 performing a return routability test. 879 The processing rules for this option are the given in more detail in 880 Section 5.4. 882 5.2. Probe Message 884 This message performs REAP exploration. Its format is as follows: 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0| 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Checksum |R| | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 893 | Receiver Context Tag | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | | 896 + Options + 897 | | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Next Header 902 This value MUST be set to NO_NXT_HDR (59). 904 Hdr Ext Len 906 This is an 8-bit unsigned integer field, calculated as specified 907 in Section 5.3 of the SHIM6 protocol description 908 [I-D.ietf-shim6-proto]. 910 Type 912 This field identifies the Probe message and MUST be set to 67 913 (Probe). 915 Reserved 917 This is a 7-bit field reserved for future use. It is set to zero 918 on transmit, and MUST be ignored on receipt. 920 R 922 This is a 1-bit field reserved for future use. It is set to zero 923 on transmit, and MUST be ignored on receipt. 925 Checksum 927 This is a 16-bit field, calculated as specified in Section 5.3 of 928 the SHIM6 protocol description [I-D.ietf-shim6-proto]. 930 Receiver Context Tag 932 This is a 47-bit field for the Context Tag the receiver has 933 allocated for the context. 935 Options 937 This MUST contain at least the Probe option and MAY contain one or 938 more Reachability options. 940 A valid message conforms to the format above, has a Receiver Context 941 Tag that matches to a context known by the receiver, is valid shim 942 control message as defined in Section 12.2 of the SHIM6 protocol 943 description [I-D.ietf-shim6-proto], and its shim context state is 944 ESTABLISHED. The receiver processes a valid message by inspecting 945 its options, and executing any actions specified such options. This 946 includes the SHIM6 Probe option found within the options. 948 The processing rules for this message are the given in more detail in 949 Section 5.4. 951 5.2.1. Probe Option 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Type = 11 |0| Length | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 |Y| Res | Identifier | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 Type 963 This value MUST be set to 11 (Probe Option). 965 0 967 This value MUST be set to 0, as in other SHIM6 options. 969 Length 971 This is the length of the option and MUST be calculated as 972 specified in Section 5.14 of the SHIM6 protocol description 973 [I-D.ietf-shim6-proto]. 975 Y (The "I See You" flag) 977 This flag is set to 1 if the sender receives either payload 978 packets or REAP messages from the peer, and 0 otherwise. The 979 determination of when the sender receives something is made during 980 the last Send Timeout seconds (see Section 5.5) when traffic was 981 expected, i.e., when there was either payload traffic or REAP 982 messages. 984 Upon reception, a value of 1 indicates that the receiver does not 985 need to change its behaviour as the sender is already seeing its 986 packets. A value of 0 indicates that the receiver MUST explore 987 different outgoing address pairs. 989 Res 991 This 3-bit reserved field MUST be set to zero when sending, and 992 ignored on receipt. 994 Identifier 996 This 28-bit field identifies this particular instance of an Probe 997 message. This value SHOULD be generated using a random number 998 generator that is known to have good randomness properties. Upon 999 reception, Identifier values are copied onto Probe Reception 1000 Report options. This allows them to be used for both identifying 1001 which Probes were received as well as for performing a return 1002 routability test. 1004 The processing rules for this option are the given in more detail in 1005 Section 5.4. 1007 5.3. Reachability Option 1009 Additional information can be included in Keepalive and Probe 1010 messages by the inclusion of the Reachability Options. Their format 1011 is as follows: 1013 0 1 2 3 1014 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 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Type = 12 |0| Length | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Option Type | | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1020 ~ Option Data ~ 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Type 1025 This value MUST be set to 12 (Reachability option). 1027 0 1029 This value MUST be set to 0, as in other SHIM6 options. 1031 Length 1033 This is the length of the option and MUST be calculated as 1034 specified in Section 5.14 of the SHIM6 protocol description 1035 [I-D.ietf-shim6-proto]. 1037 Option Type 1039 This value identifies the option. 1041 Option Data 1043 Option-specific content. 1045 Unrecognized options MUST be ignored upon receipt. All 1046 implementations MUST support the options defined in this 1047 specification, however. 1049 5.3.1. Payload Reception Report 1051 This option SHOULD be included in all Probe messages when the sender 1052 has recently (within the last Send Timeout seconds) received payload 1053 packets from the peer. Its format is as follows: 1055 0 1 2 3 1056 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 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Type = 12 |0| Length | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Option Type = 1 | Reserved | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 ~ Suboptions ~ 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Type, 0, and Length 1067 These are as specified above. 1069 Reserved 1071 This is a 16-bit field reserved for future use. It is set to zero 1072 on transmit, and MUST be ignored on receipt. 1074 Suboptions 1076 This field is reserved for possible future Reachability options 1077 that are carried (recursively) within this option. Unrecognized 1078 options MUST be ignored upon receipt. Currently there are no 1079 defined options that can be carried here. 1081 5.3.2. Probe Reception Report 1083 This option MUST be included in any Probe message when the sender has 1084 recently (within the last Send Timeout seconds) received Probe or 1085 Keepalive messages from the peer. Depending on MTU and timing 1086 considerations, the sender MAY, however, include options for only 1087 some of the received Probe messages. All implementations MUST 1088 support sending of at least five such options, however. 1090 The format of this option is as follows: 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type = 12 |0| Length | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Option Type = 2 | Reserved | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Res | Identifier | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 ~ Suboptions ~ 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Type, 0, and Length 1106 These are as specified above. 1108 Option Type 1110 This value identifies the option and MUST be set to 2 (Probe 1111 Reception Report). 1113 Reserved 1115 This is a 16-bit field reserved for future use. It is set to zero 1116 on transmit, and MUST be ignored on receipt. 1118 Res 1120 This is a 3-bit field reserved for future use. It is set to zero 1121 on transmit, and MUST be ignored on receipt. 1123 Identifier 1125 This 32 bit field carries the identifier of the Probe message that 1126 was recently received. 1128 Suboptions 1130 This field is reserved for possible future Reachability options 1131 that are carried (recursively) within this option. Unrecognized 1132 options MUST be ignored upon receipt. Currently there are no 1133 defined options that can be carried here. 1135 5.4. Behaviour 1137 The required behaviour of REAP nodes is specified below in the form 1138 of a state machine. The externally observable behaviour of an 1139 implementation MUST conform to this state machine, but there is no 1140 requirement that the implementation actually employs a state machine. 1141 Intermixed with the following description we also provide a state 1142 machine description in a tabular form. That form is only 1143 informational, however. 1145 On a given context with a given peer, the node can be in one of three 1146 states: Operational, Exploring, or ExploringOK. In the Operational 1147 state the underlying address pairs are assumed to be operational. In 1148 the Exploring state this node has observed a problem and has 1149 currently not seen any traffic from the peer. Finally, in the 1150 ExploringOK state this node sees traffic from the peer, but peer may 1151 not yet see any traffic from this node so that the exploration 1152 process needs to continue. 1154 The node maintains also the Send and Keepalive timers. The Send 1155 timer reflects the requirement that when this node sends a payload 1156 packet there should be some return traffic (either payload packets or 1157 Keepalive messages) within Send Timeout seconds. The Keepalive timer 1158 reflects the requirement that when this node receives a payload 1159 packet there should a similar response towards the peer. The 1160 Keepalive timer is only used within the Operational state, and the 1161 Send timer in the Operational and ExploringOK states. No timer is 1162 running in the Exploring state. 1164 Upon the reception of a payload packet in the Operational state, the 1165 node starts the Keepalive timer if it is not yet running, and stops 1166 the Send timer if it was running. If the node is in the Exploring 1167 state it transitions to the ExploringOK state, sends a Probe message 1168 with the I See You flag set to 1 (Yes), and starts the Send timer. 1169 In the ExploringOK state the node stops the Send timer if it was 1170 running, but does not do anything else. The reception of SHIM6 1171 control messages other than the Keepalive and Probe messages are 1172 treated similarly with payload packets. 1174 1. EVENT: Incoming payload packet 1175 ================================= 1177 Operational Exploring ExploringOk 1178 ------------------------------------------------------------- 1179 STOP Send; SEND Probe Y=Yes; STOP Send 1180 START Keepalive START Send; 1181 GOTO ExploringOk 1183 Upon sending a payload packet in the Operational state, the node 1184 stops the Keepalive timer if it was running and starts the Send timer 1185 if it was not running. In the Exploring state there is no effect, 1186 and in the ExploringOK state the node simply starts the Send timer if 1187 it was not yet running. (The sending of SHIM6 control messages is 1188 again treated similarly here.) 1190 2. EVENT: Outgoing payload packet 1191 ================================= 1193 Operational Exploring ExploringOk 1194 ------------------------------------------------------------- 1195 START Send; - START Send 1196 STOP Keepalive 1198 Upon a timeout on the Keepalive timer the node sends a Keepalive 1199 message. This can only happen in the Operational state. 1201 3. EVENT: Keepalive timeout 1203 Operational Exploring ExploringOk 1204 ------------------------------------------------------------- 1205 SEND Keepalive - - 1207 Upon a timeout on the Send timer, the node enters the Exploring state 1208 and sends a Probe with I See You set to 0 (No) and stops the 1209 Keepalive timer if it was running. 1211 4. EVENT: Send timeout 1212 ====================== 1214 Operational Exploring ExploringOk 1215 ------------------------------------------------------------- 1216 SEND Probe Y=No; - SEND Probe Y=No 1217 STOP Keepalive; GOTO Exploring 1218 GOTO Exploring 1220 While in the Exploring state the node keeps retransmitting its Probe 1221 messages to different (or same) addresses as defined in Section 4.3. 1222 A similar process is employed in the ExploringOk state, except that 1223 upon such retransmission the Send timer is started if it was not 1224 running already. 1226 5. EVENT: Retransmission 1227 ======================== 1229 Operational Exploring ExploringOk 1230 ------------------------------------------------------------- 1231 - SEND Probe Y=No SEND Probe Y=Yes 1232 START Send 1234 Upon the reception of a Keepalive message in the Operational state, 1235 the node stops the Send timer, if it was running. If the node is in 1236 the Exploring state it transitions to the ExploringOK state, sends a 1237 Probe message with the I See You flag set to 1 (Yes), and starts the 1238 Send timer. In the ExploringOK state the Send timer is stopped, if 1239 it was running. 1241 6. EVENT: Reception of the Keepalive message 1242 ============================================ 1244 Operational Exploring ExploringOk 1245 ------------------------------------------------------------- 1246 STOP Send SEND Probe Y=Yes; STOP Send 1247 START Send; 1248 GOTO ExploringOk 1250 Upon receiving a Probe with I See You set to 0 (No) the node enters 1251 the ExploringOK state, sends a Probe with I See You set to 1 (Yes), 1252 stops the Keepalive timer if it was running, and restarts the Send 1253 timer. 1255 7. EVENT: Reception of the Probe message with Y=No 1256 ================================================== 1258 Operational Exploring ExploringOk 1259 ------------------------------------------------------------- 1260 SEND Probe Y=Yes SEND Probe Y=Yes; SEND Probe Y=Yes; 1261 STOP Keepalive; START Send; RESTART Send 1262 RESTART Send; GOTO ExploringOk 1263 GOTO ExploringOk 1265 The behavior upon the reception of a Probe message with I see You set 1266 to 1 (Yes) depends on whether it contains a Probe Reception Report 1267 that refers to a Probe that this node has sent to the peer such that 1268 the I See You was set to 1 in that message. If it does, the node 1269 sends a Probe message with I See You set to 1 (Yes), restarts the 1270 Send timer, stops the Keepalive timer if it was running, and 1271 transitions to the Operational state. 1273 8. EVENT: Reception of the Probe message with Y=Yes 1274 (peer reports not seeing yet a Probe with Y=Yes) 1275 ========================================================== 1277 Operational Exploring ExploringOk 1278 ------------------------------------------------------------- 1279 SEND Probe Y=Yes; SEND Probe Y=Yes; SEND Probe Y=Yes; 1280 RESTART Send; RESTART Send; RESTART Send; 1281 STOP Keepalive GOTO Operational GOTO Operational 1283 If there was no such Probe Reception Report, the stops the Send timer 1284 if it was running, starts the Keepalive timer if it was not yet 1285 running, and transitions to the Operational state. 1287 Note: This check is necessary in order to terminate the 1288 exploration process when both parties are happy and know that 1289 their peers are happy as well. 1291 9. EVENT: Reception of the Probe message with Y=Yes 1292 (peer reports seeing a Probe with Y=Yes) 1293 =================================================== 1295 Operational Exploring ExploringOk 1296 ------------------------------------------------------------- 1297 STOP Send STOP Send; STOP Send; 1298 START Keepalive START Keepalive START Keepalive 1299 GOTO Operational GOTO Operational 1301 The reachability detection and exploration process has no effect on 1302 payload communications until a new operational address pairs have 1303 actually been confirmed. Prior to that the payload packets continue 1304 to be sent to the previously used addresses. 1306 Garbage collection of SHIM6 contexts terminates contexts that are 1307 either unused or have failed due to the inability of the exploration 1308 process to find an operational pair. 1310 In the PDF version of this specification, an informational drawing 1311 illustrates the state machine. Where the text and the drawing 1312 differ, the text takes precedence. 1314 5.5. Protocol Constants 1316 The following protocol constants are defined: 1318 Send Timeout 10 seconds 1319 Keepalive Timeout 3 seconds 1320 Initial Probe Timeout 0.5 seconds 1321 Number of Initial Probes 4 probes 1322 Max Probe Timeout 60 seconds 1324 6. Security Considerations 1326 Attackers may spoof various indications from lower layers and the 1327 network in an effort to confuse the peers about which addresses are 1328 or are not operational. For example, attackers may spoof ICMP error 1329 messages in an effort to cause the parties to move their traffic 1330 elsewhere or even to disconnect. Attackers may also spoof 1331 information related to network attachments, router discovery, and 1332 address assignments in an effort to make the parties believe they 1333 have Internet connectivity when in reality they do not. 1335 This may cause use of non-preferred addresses or even denial-of- 1336 service. 1338 This protocol does not provide any protection of its own for 1339 indications from other parts of the protocol stack. Unprotected 1340 indications SHOULD NOT be taken as a proof of connectivity problems. 1341 However, REAP has weak resistance against incorrect information even 1342 from unprotected indications in the sense that it performs its own 1343 tests prior to picking a new address pair. Denial-of- service 1344 vulnerabilities remain, however, as do vulnerabilities against on 1345 path attackers. 1347 Some aspects of these vulnerabilities can be mitigated through the 1348 use of techniques specific to the other parts of the stack, such as 1349 properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link 1350 layer security, or the use of SEND [RFC3971] to protect IPv6 Router 1351 and Neighbor Discovery. 1353 Other parts of the SHIM6 protocol ensure that the set of addresses we 1354 are switching between actually belong together. REAP itself provides 1355 no such assurances. Similarly, REAP provides only minimal protection 1356 against third party flooding attacks; when REAP is run its Probe 1357 identifiers can be used as a return routability check that the 1358 claimed address is indeed willing to receive traffic. However, this 1359 needs to be complemented with another mechanism to ensure that the 1360 claimed address is also the correct host. SHIM6 does this by 1361 performing binding of all operations to context tags. 1363 The keepalive mechanism in this specification is vulnerable to 1364 spoofing. On path-attackers that can see a SHIM6 context tag can 1365 send spoofed Keepalive messages once per Send Timeout interval, to 1366 prevent two SHIM6 nodes from sending Keepalives themselves. This 1367 vulnerability is only relevant to nodes involved in a one-way 1368 communication. The result of the attack is that the nodes enter the 1369 exploration phase needlessly, but they should be able to confirm 1370 connectivity unless, of course, the attacker is able to prevent the 1371 exploration phase from completing. Off-path attackers may not be 1372 able to generate spoofed results, given that the context tags are 47- 1373 bit random numbers. 1375 The exploration phase is vulnerable to attackers that are on the 1376 path. Off-path attackers would find it hard to guess either the 1377 context tag or the correct probe identifiers. Given that IPsec 1378 operates above the shim layer, it is not possible to protect the 1379 exploration phase against on-path attackers. This is similar to the 1380 ability to protect other Shim6 control exchanges. There are 1381 mechanisms in place to prevent the redirection of communications to 1382 wrong addresses, but on-path attackers can cause denial-of-service, 1383 move communications to less-preferred address pairs, and so on. 1385 Finally, the exploration itself can cause a number of packets to be 1386 sent. As a result it may be used as a tool for packet amplification 1387 in flooding attacks. In order to prevent this it is required that 1388 the protocol employing REAP has built-in mechanisms to prevent this. 1389 For instance, in SHIM6 contexts are created only after a relatively 1390 large number of packets has been exchanged, a cost which reduces the 1391 attractiveness of using SHIM6 and REAP for amplification attacks. 1392 However, such protections are typically not present at connection 1393 establishment time. When exploration would be needed for connection 1394 establishment to succeed, its usage would result in an amplification 1395 vulnerability. As a result, SHIM6 does not support the use of REAP 1396 in connection establishment stage. 1398 7. IANA Considerations 1400 This document creates one new name spaces under the new SHIM6 1401 Reachability Protocol repository. The name space is for Reachability 1402 Option Type (Section 5.3) and it has one reserved value (0) and two 1403 defined values, 1 (Payload Reception Report defined in Section 5.3.1) 1404 and 2 (Probe Reception Report defined in Section 5.3.2). Further 1405 allocations within this 16-bit field can be made through 1406 Specification Required. The range from 65000 to 65535 is reserved 1407 for experimental use. 1409 8. References 1411 8.1. Normative References 1413 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1414 Recommendations for Security", RFC 1750, December 1994. 1416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1417 Requirement Levels", BCP 14, RFC 2119, March 1997. 1419 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1420 Discovery for IP Version 6 (IPv6)", RFC 2461, 1421 December 1998. 1423 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1424 Autoconfiguration", RFC 2462, December 1998. 1426 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1427 and M. Carney, "Dynamic Host Configuration Protocol for 1428 IPv6 (DHCPv6)", RFC 3315, July 2003. 1430 [RFC3484] Draves, R., "Default Address Selection for Internet 1431 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1433 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1434 Addresses", RFC 4193, October 2005. 1436 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1437 for IPv6", RFC 4429, April 2006. 1439 8.2. Informative References 1441 [AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1442 Location Management", In Proceedings of the 18th Annual 1443 Computer Security Applications Conference, Las Vegas, 1444 Nevada, USA., December 2002. 1446 [I-D.bagnulo-shim6-addr-selection] 1447 Bagnulo, M., "Address selection in multihomed 1448 environments", draft-bagnulo-shim6-addr-selection-00 (work 1449 in progress), October 2005. 1451 [I-D.huitema-multi6-addr-selection] 1452 Huitema, C., "Address selection in multihomed 1453 environments", draft-huitema-multi6-addr-selection-00 1454 (work in progress), October 2004. 1456 [I-D.ietf-dna-cpl] 1457 Nordmark, E. and J. Choi, "DNA with unmodified routers: 1458 Prefix list based approach", draft-ietf-dna-cpl-02 (work 1459 in progress), January 2006. 1461 [I-D.ietf-dna-protocol] 1462 Kempf, J., "Detecting Network Attachment in IPv6 Networks 1463 (DNAv6)", draft-ietf-dna-protocol-00 (work in progress), 1464 February 2006. 1466 [I-D.ietf-hip-mm] 1467 Nikander, P., "End-Host Mobility and Multihoming with the 1468 Host Identity Protocol", draft-ietf-hip-mm-03 (work in 1469 progress), March 2006. 1471 [I-D.ietf-shim6-proto] 1472 Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1473 protocol", draft-ietf-shim6-proto-05 (work in progress), 1474 May 2006. 1476 [I-D.ietf-shim6-reach-detect] 1477 Beijnum, I., "Shim6 Reachability Detection", 1478 draft-ietf-shim6-reach-detect-01 (work in progress), 1479 October 2005. 1481 [I-D.ietf-tcpm-icmp-attacks] 1482 Gont, F., "ICMP attacks against TCP", 1483 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 1484 February 2006. 1486 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1487 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1488 Zhang, L., and V. Paxson, "Stream Control Transmission 1489 Protocol", RFC 2960, October 2000. 1491 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1492 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1494 Appendix A. Contributors 1496 This draft attempts to summarize the thoughts and unpublished 1497 contributions of many people, including the MULTI6 WG design team 1498 members Marcelo Bagnulo Braun, Iljitsch van Beijnum, Erik Nordmark, 1499 Geoff Huston, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG 1500 contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer 1501 Dawkins, and James Kempf, and my colleague Pekka Nikander at 1502 Ericsson. This draft is also in debt to work done in the context of 1503 SCTP [RFC2960] and HIP [I-D.ietf-hip-mm]. 1505 Appendix B. Acknowledgements 1507 The authors would also like to thank Christian Huitema, Pekka Savola, 1508 John Loughney, Sam Xia, and Hannes Tschofenig for interesting 1509 discussions in this problem space, and for review of this 1510 specification. 1512 Authors' Addresses 1514 Jari Arkko 1515 Ericsson 1516 Jorvas 02420 1517 Finland 1519 Email: jari.arkko@ericsson.com 1521 Iljitsch van Beijnum 1522 Muada 1523 The Netherlands 1525 Email: iljitsch@muada.com 1527 Full Copyright Statement 1529 Copyright (C) The Internet Society (2006). 1531 This document is subject to the rights, licenses and restrictions 1532 contained in BCP 78, and except as set forth therein, the authors 1533 retain all their rights. 1535 This document and the information contained herein are provided on an 1536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1538 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1539 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1540 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1543 Intellectual Property 1545 The IETF takes no position regarding the validity or scope of any 1546 Intellectual Property Rights or other rights that might be claimed to 1547 pertain to the implementation or use of the technology described in 1548 this document or the extent to which any license under such rights 1549 might or might not be available; nor does it represent that it has 1550 made any independent effort to identify any such rights. Information 1551 on the procedures with respect to rights in RFC documents can be 1552 found in BCP 78 and BCP 79. 1554 Copies of IPR disclosures made to the IETF Secretariat and any 1555 assurances of licenses to be made available, or the result of an 1556 attempt made to obtain a general license or permission for the use of 1557 such proprietary rights by implementers or users of this 1558 specification can be obtained from the IETF on-line IPR repository at 1559 http://www.ietf.org/ipr. 1561 The IETF invites any interested party to bring to its attention any 1562 copyrights, patents or patent applications, or other proprietary 1563 rights that may cover technology that may be required to implement 1564 this standard. Please address the information to the IETF at 1565 ietf-ipr@ietf.org. 1567 Acknowledgment 1569 Funding for the RFC Editor function is provided by the IETF 1570 Administrative Support Activity (IASA).