idnits 2.17.1 draft-ietf-shim6-failure-detection-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1427. ** 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 (September 23, 2006) is 6424 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-01 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-04 == Outdated reference: A later version (-04) exists of draft-ietf-shim6-locator-pair-selection-00 == 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 (~~), 6 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. van Beijnum 5 Expires: March 27, 2007 September 23, 2006 7 Failure Detection and Locator Pair Exploration Protocol for IPv6 8 Multihoming 9 draft-ietf-shim6-failure-detection-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 27, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies how the level 3 multihoming shim protocol 43 (SHIM6) detects failures between two communicating hosts. It also 44 specifies an exploration protocol for switching to another pair of 45 interfaces and/or addresses between the same hosts if a failure 46 occurs and an operational pair can be found. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 52 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.1. Available Addresses . . . . . . . . . . . . . . . . . . 5 54 3.2. Locally Operational Addresses . . . . . . . . . . . . . 6 55 3.3. Operational Address Pairs . . . . . . . . . . . . . . . 6 56 3.4. Primary Address Pair . . . . . . . . . . . . . . . . . . 8 57 3.5. 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 . . . . . . . . . . . . . . . . . . . 12 62 5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 14 63 5.1. Keepalive Message . . . . . . . . . . . . . . . . . . . 14 64 5.2. Probe Message . . . . . . . . . . . . . . . . . . . . . 15 65 6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 20 66 7. Example Protocol Runs . . . . . . . . . . . . . . . . . . . . 24 67 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 29 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 72 11.2. Informative References . . . . . . . . . . . . . . . . . 33 73 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 74 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 36 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 76 Intellectual Property and Copyright Statements . . . . . . . . . . 38 78 1. Introduction 80 The SHIM6 protocol [I-D.ietf-shim6-proto] extends IPv6 to support 81 multihoming. It is an IP layer mechanism that hides multihoming from 82 applications. A part of the SHIM6 solution involves detecting when a 83 currently used pair of addresses (or interfaces) between two 84 communication hosts has failed, and picking another pair when this 85 occurs. We call the former failure detection, and the latter locator 86 pair exploration. 88 This document specifies the mechanisms and protocol messages to 89 achieve both failure detection and locator pair exploration. This 90 part of the SHIM6 protocol is called the REAchability Protocol 91 (REAP). 93 The document is structured as follows: Section 3 defines a set of 94 useful terms, Section 4 gives an overview of REAP, and Section 5 95 specifies the message formats and behaviour in detail. Section 9 96 discusses the security considerations of REAP. 98 In this specification, we consider an address to be synonymous with a 99 locator. Other parts of the SHIM6 protocol ensure that the different 100 locators used by a node actually belong together. That is, REAP is 101 not responsible for ensuring that it ends up with a legitimate 102 locator. 104 2. Requirements language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Definitions 112 This section defines terms useful for discussing failure detection 113 and locator pair exploration. 115 3.1. Available Addresses 117 SHIM6 nodes need to be aware of what addresses they themselves have. 118 If a node loses the address it is currently using for communications, 119 another address must replace this address. And if a node loses an 120 address that the node's peer knows about, the peer must be informed. 121 Similarly, when a node acquires a new address it may generally wish 122 the peer to know about it. 124 Definition. Available address. An address is said to be available 125 if the following conditions are fulfilled: 127 o The address has been assigned to an interface of the node. 129 o The address is valid in the sense of RFC 2461 [RFC2461]. 131 o The address is not tentative in the sense of RFC 2462 [RFC2462]. 132 In other words, the address assignment is complete so that 133 communications can be started. 135 Note that this explicitly allows an address to be optimistic in 136 the sense of Optimistic DAD [RFC4429] even though implementations 137 may prefer using other addresses as long as there is an 138 alternative. 140 o The address is a global unicast, unique local address [RFC4193], 141 or an unambiguous IPv6 link-local address. That is, it is not an 142 IPv6 site-local address. 144 Where IPv6 link-local addresses are used, their use needs to be 145 unambiguous as follows. At most one link-local address may be 146 used per node within the same connection between two peers. 148 o The address and interface is acceptable for use according to a 149 local policy. 151 Available addresses are discovered and monitored through mechanisms 152 outside the scope of SHIM6. SHIM6 implementations MUST be able to 153 employ information provided by IPv6 Neighbor Discovery [RFC2461], 154 Address Autoconfiguration [RFC2462], and DHCP [RFC3315] (when DHCP is 155 implemented). This information includes the availability of a new 156 address and status changes of existing addresses (such as when an 157 address becomes invalid). 159 3.2. Locally Operational Addresses 161 Two different granularity levels are needed for failure detection. 162 The coarser granularity is for individual addresses: 164 Definition. Locally Operational Address. An available address is 165 said to be locally operational when its use is known to be possible 166 locally: the interface is up, a default router (if needed) suitable 167 for this address is known to be reachable, and no other local 168 information points to the address being unusable. 170 Locally operational addresses are discovered and monitored through 171 mechanisms outside the SHIM6 protocol. SHIM6 implementations MUST be 172 able to employ information provided from Neighbor Unreachability 173 Detection [RFC2461]. Implementations MAY also employ additional, 174 link layer specific mechanisms. 176 Note 1: A part of the problem in ensuring that an address is 177 operational is making sure that after a change in link layer 178 connectivity we are still connected to the same IP subnet. 179 Mechanisms such as DNA CPL [I-D.ietf-dna-cpl] or DNAv6 180 [I-D.ietf-dna-protocol] can be used to ensure this. 182 Note 2: In theory, it would also be possible for hosts to learn 183 about routing failures for a particular selected source prefix, if 184 only suitable protocols for this purpose existed. Some proposals 185 in this space have been made, see, for instance 186 [I-D.bagnulo-shim6-addr-selection] and 187 [I-D.huitema-multi6-addr-selection], but none have been 188 standardized to date. 190 3.3. Operational Address Pairs 192 The existence of locally operational addresses are not, however, a 193 guarantee that communications can be established with the peer. A 194 failure in the routing infrastructure can prevent packets from 195 reaching their destination. For this reason we need the definition 196 of a second level of granularity, for pairs of addresses: 198 Definition. Bidirectionally operational address pair. A pair of 199 locally operational addresses are said to be an operational address 200 pair when bidirectional connectivity can be shown between the 201 addresses. That is, a packet sent with one of the addresses in the 202 source field and the other in the destination field reaches the 203 destination, and vice versa. 205 Unfortunately, there are scenarios where bidirectionally operational 206 address pairs do not exist. For instance, ingress filtering or 207 network failures may result in one address pair being operational in 208 one direction while another one is operational from the other 209 direction. The following definition captures this general situation: 211 Definition. Unidirectionally operational address pair. A pair of 212 locally operational addresses are said to be an unidirectionally 213 operational address pair when packets sent with the first address as 214 the source and the second address as the destination can be shown to 215 reach the destination. 217 SHIM6 implementations MUST support the discovery of operational 218 address pairs through the use of explicit rechability tests and 219 Forced Bidirectional Communication (FBD), described later in this 220 specification. In addition, implementations MAY employ the following 221 additional mechanisms: 223 o Positive feedback from upper layer protocols. For instance, TCP 224 can indicate to the IP layer that it is making progress. This is 225 similar to how IPv6 Neighbor Unreachability Detection can in some 226 cases be avoided when upper layers provide information about 227 bidirectional connectivity [RFC2461]. 229 In the case of unidirectional connectivity, the upper layer 230 protocol responses come back using another address pair, but show 231 that the messages sent using the first address pair have been 232 received. 234 o Negative feedback from upper layer protocols. It is conceivable 235 that upper layer protocols give an indication of a problem to the 236 multihoming layer. For instance, TCP could indicate that there's 237 either congestion or lack of connectivity in the path because it 238 is not getting ACKs. 240 o ICMP error messages. Given the ease of spoofing ICMP messages, 241 one should be careful to not trust these blindly, however. Our 242 suggestion is to use ICMP error messages only as a hint to perform 243 an explicit reachability test or move an address pair to a lower 244 place in the list of address pairs to be probed, but not as a 245 reason to disrupt ongoing communications without other indications 246 of problems. The situation may be different when certain 247 verifications of the ICMP messages are being performed, as 248 explained by Gont in [I-D.ietf-tcpm-icmp-attacks]. These 249 verifications can ensure that (practically) only on-path attackers 250 can spoof the messages. 252 Note SHIM6 needs to perform a return routability test of an address 253 before it is taken into use. The purpose of this test is to ensure 254 that fraudulent peers do not trick others into redirecting traffic 255 streams onto innocent victims. For a discussion of such attacks, see 256 Aura et al [AURA02]. The test can at the same time work as a means 257 to ensure that an address pair is operational, as discussed in 258 Section 4.2. 260 3.4. Primary Address Pair 262 The primary address pair consists of the ULID addresses that upper 263 layer protocols use in their interaction with the SHIM6 layer. Use 264 of the primary address pair means that the communication is 265 compatible with regular non-SHIM6 communication and no context ID 266 needs to be present. 268 3.5. Current Address Pair 270 SHIM6 needs to avoid sending packets concurrently over multiple 271 paths, because congestion control in commonly used transport 272 protocols is based upon a notion of a single path. While routing can 273 introduce path changes as well and transport protocols have means to 274 deal with this, frequent changes will cause problems. Efficient 275 congestion control over multible paths is a considered research at 276 the time this specification is written. 278 For these reasons it is necessary to choose a particular pair of 279 addresses as the current address pair which is used until problems 280 occur, at least for the same session. 282 A current address pair need not be operational at all times. If 283 there is no traffic to send, we may not know if the primary address 284 pair is operational. Nevertheless, it makes sense to assume that the 285 address pair that worked in some time ago continues to be operational 286 for new communications as well. 288 4. Protocol Overview 290 This section discusses the design of the reachability detection and 291 address pair exploration mechanisms, and gives on overview of the 292 REAP protocol. 294 Exploring the full set of communication options between two hosts 295 that both have two or more addresses is an expensive operation as the 296 number of combinations to be explored increases very quickly with the 297 number of addresses. For instance, with two addresses on both sides, 298 there are four possible address pairs. Since we can't assume that 299 reachability in one direction automatically means reachability for 300 the complement pair in the other direction, the total number of two- 301 way combinations is eight. (Combinations = nA * nB * 2.) 303 An important observation in multihoming is that failures are 304 relatively infrequent, so that an operational pair that worked a few 305 seconds ago is very likely to be still operational. So it makes 306 sense to have a light-weight protocol that confirms existing 307 reachability, and only invoke heavier exploration when a there is a 308 suspected failure. 310 4.1. Failure Detection 312 Failure detection consists of three parts: tracking local 313 information, tracking remote peer status, and finally verifying 314 reachability. Tracking local information consists of using, for 315 instance, reachability information about the local router as an 316 input. Nodes SHOULD employ techniques listed in Section 3.1 and 317 Section 3.2 to be track the local situation. It is also necessary to 318 track remote address information from the peer. For instance, if the 319 peer's currently used address is no longer in use, mechanism to relay 320 that information is needed. The Update message in the SHIM6 protocol 321 is used for this purpose [I-D.ietf-shim6-proto]. Finally, when the 322 local and remote information indicates that communication should be 323 possible and there are upper layer packets to be sent, reachability 324 verification is necessary to ensure that the peers actually have an 325 operational pair. 327 A technique called Forced Bidirectional Detection (FBD, originally 328 defined in an earlier SHIM6 document [I-D.ietf-shim6-reach-detect]) 329 is employed for the reachability verification. Reachability for the 330 currently used address pair in a shim context is determined by making 331 sure that whenever there is data traffic in one direction, there is 332 also traffic in the other direction. This can be data traffic as 333 well, but also transport layer acknowledgments or a REAP reachability 334 keepalive if there is no other traffic. This way, it is no longer 335 possible to have traffic in only one direction, so whenever there is 336 data traffic going out, but there are no return packets, there must 337 be a failure, so the full exploration mechanism is started. 339 A more detailed description of the current pair reachability 340 evaluation mechanism: 342 1. To avoid the other side from concluding there is a reachability 343 failure, it's necessary for a host implementing the failure 344 detection mechanism to generate periodic keepalives when there is 345 no other traffic. 347 FBD works by generating REAP keepalives if the node is receiving 348 packets from its peer but not sending any of its own. The 349 keepalives are sent at certain intervals so that the other side 350 knows there is a reachability problem when it doesn't receive any 351 incoming packets for 10 seconds, the Keepalive Timeout. 352 (Mechanisms to negotiate an alternative Keepalive Timeout may be 353 provided in the future.) 355 The interval after which keepalives are sent is named Keepalive 356 Interval. This document doesn't specify a value for Keepalive 357 Interval, but recognizes that an often used approach is sending 358 keepalives at three times the timeout interval, which would be 3 359 seconds here, and suggest a possible alternative of 4 seconds so 360 that two keepalives are generated and have time to reach the 361 correspondent. An upper bound would be 8 seconds, so that one 362 keepalive has time to reach the other side, assuming a maximum 363 one-way delay of 2 seconds. 365 2. Whenever outgoing data packets are generated, a timer is started 366 to reflect the requirement that the peer should generate return 367 traffic from data packets. 369 For the purposes of this specification, "data packet" refers to 370 any packet that is part of a shim context, including both upper 371 layer protocol packets and SHIM6 protocol messages except those 372 defined in this specification. 374 3. Whenever incoming data packets are received, the timer associated 375 with the return traffic from the peer is stopped, and another 376 timer is started to reflect the requirement for this node to 377 generate return traffic. 379 4. The reception of a REAP keepalive packet leads to stopping the 380 timer associated with the return traffic from the peer. 382 5. Keepalive Interval seconds after the last data packet has been 383 received for a context, and if no other packet has been sent 384 within this context since the data packet has been received, a 385 REAP keepalive packet is generated for the context in question 386 and transmitted to the correspondent. A host may send the 387 keepalive sooner than Keepalive Interval seconds if 388 implementation considerations warrant this, but should take care 389 to avoid sending keepalives at an excessive rate. After sending 390 a single keepalive message, no additional keepalive messages are 391 sent until a data packet is received within this shim context. 392 Keepalives are not sent at all when a data packet was sent since 393 the last received data packet. 395 6. Send Timeout seconds (10 seconds; see Section 8) after the 396 transmission of a data packet with no return traffic on this 397 context, a full reachability exploration is started. 399 Note that the above timeout values are suggestions to be used as 400 defaults. Experience from the deployment of the SHIM6 protocol is 401 needed in order to determine what values are most suitable. The 402 setting of these values is also related to various parameters in 403 transport protocols, such as TCP keepalive interval. 405 4.2. Alternative Address Pair Exploration 407 As explained in previous section, the currently used address pair may 408 become invalid either through one of the addresses being becoming 409 unavailable or inoperational, or the pair itself being declared 410 inoperational. An exploration process attempts to find another 411 operational pair so that communications can resume. 413 What makes this process hard is the requirement to support 414 unidirectionally operational address pairs. It is insufficient to 415 probe address pairs by a simple request - response protocol. 416 Instead, the party that first detects the problem starts a process 417 where it tries each of the different address pairs in turn by sending 418 a message to its peer. These messages carry information about the 419 state of connectivity between the peers, such as whether the sender 420 has seen any traffic from the peer recently. When the peer receives 421 a message that indicates a problem, it assists the process by 422 starting its own parallel exploration to the other direction, again 423 sending information about the recently received payload traffic or 424 signaling messages. 426 Specifically, when A decides that it needs to explore for an 427 alternative address pair to B, it will initiate a set of Probe 428 messages, in sequence, until it gets an Probe message from B 429 indicating that (a) B has received one of A's messages and, 430 obviously, (b) that B's Probe message gets back to A. B uses the same 431 algorithm, but starts the process from the reception of the first 432 Probe message from A. 434 Upon changing to a new address pair, the network path traversed most 435 likely has changed, so that the ULP SHOULD be informed. This can be 436 a signal for the ULP to adapt due to the change in path so that, for 437 example, TCP could initiate a slow start procedure, although it's 438 likely that the circumstances that led to the selection of a new path 439 already caused enough packet loss to trigger slow start. 441 Similarly, one can also envision that applications would be able to 442 tell the IP or transport layer that the current connection in 443 unsatisfactory and an exploration for a better one would be 444 desirable. This would require an inter-layer communication mechanism 445 to be developed, however. In any case, this is another issue that we 446 treat as being outside the scope of pure address exploration. 448 REAP is designed to support failure recovery even in the case of 449 having only unidirectionally operational address pairs. However, due 450 to security concerns discussed in Section 9, the exploration process 451 can typically be run only for a session that has already been 452 established. Specifically, while REAP would in theory be capable of 453 exploration even during connection establishment, its use within the 454 SHIM6 protocol does not allow this. 456 4.3. Exploration Order 458 The exploration process assumes an ability to choose address pairs 459 for testing, in some sequence. This process may result in a 460 combinatorial explosion when there are many addresses on both sides, 461 but a back-off procedure is employed to avoid a "signaling storm". 463 Nodes first consult the RFC 3484 default address selection rules 464 [RFC3484] Section 4 rules to determine what combinations of addresses 465 are allowed from a local point of view, as this reduces the search 466 space. RFC 3484 also provides a priority ordering among different 467 address pairs, making the search possibly faster. (Additional 468 mechanisms may be defined in the future for arriving at an initial 469 ordering of address pairs before testing starts 470 [I-D.ietf-shim6-locator-pair-selection].) Nodes may also use local 471 information, such as known quality of service parameters or interface 472 types to determine what addresses are preferred over others, and try 473 pairs containing such addresses first. The SHIM6 protocol also 474 carries preference information in its messages. 476 Discussion note: The preferences may either be learned dynamically 477 or be configured. It is believed, however, that dynamic learning 478 based purely on the multihoming protocol is too hard and not the 479 task this layer should do. Solutions where multiple protocols 480 share their information in a common pool of locators could provide 481 this information from transport protocols, however. 483 Out of the set of possible candidate address pairs, nodes SHOULD 484 attempt to test through all of them until an operational pair is 485 found, and retrying the process as is necessary. However, all nodes 486 MUST perform this process sequentially and with exponential back-off. 487 This sequential process is necessary in order to avoid a "signaling 488 storm" when an outage occurs (particularly for a complete site). 489 However, it also limits the number of addresses that can in practice 490 be used for multihoming, considering that transport and application 491 layer protocols will fail if the switch to a new address pair takes 492 too long. 494 Section 8 suggests default values for the timers associated with the 495 exploration process. The value Initial Probe Timeout (0.5 seconds) 496 specifies the interval between initial attempts to send probes; 497 Number of Initial Probes (4) specifies how many initial probes can be 498 sent before the exponential backoff procedure needs to be employed. 499 This process increases the time between every probe if there is no 500 response. Typically, each increase doubles the time but this 501 specification does not mandate a particular increase. 503 Finally, Max Probe Timeout (60 seconds) specifies a limit beyond 504 which the probe interval may not grow. If the exploration process 505 reaches this interval, it will continue sending at this rate until a 506 suitable response is triggered or the SHIM6 context is garbage 507 collected, because upper layer protocols using the SHIM6 context in 508 question are no longer attempting to send packets. Reaching the Max 509 Probe Timeout may also serve as a hint to the garbage collection 510 process that the context is no longer usable. 512 5. Protocol Definition 514 5.1. Keepalive Message 516 The format of the keepalive message is as follows: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Next Header | Hdr Ext Len |0| Type = 66 | Reserved |0| 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Checksum |R| | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 525 | Receiver Context Tag | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 + Options + 529 | | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Next Header, Hdr Ext Len, 0, 0, Checksum 534 These are as specified in Section 5.3 of the SHIM6 protocol 535 description [I-D.ietf-shim6-proto]. 537 Type 539 This field identifies the Probe message and MUST be set to 66 540 (Keepalive). 542 Reserved 544 This is a 7-bit field reserved for future use. It is set to zero 545 on transmit, and MUST be ignored on receipt. 547 R 549 This is a 1-bit field reserved for future use. It is set to zero 550 on transmit, and MUST be ignored on receipt. 552 Receiver Context Tag 554 This is a 47-bit field for the Context Tag the receiver has 555 allocated for the context. 557 Options 559 This MAY contain one or more SHIM6 options.The inclusion of the 560 latter options is not necessary, however, as there are currently 561 no defined options that are useful in a Keepalive message. These 562 options are provided only for future extensibility reasons. 564 A valid message conforms to the format above, has a Receiver Context 565 Tag that matches to context known by the receiver, is valid shim 566 control message as defined in Section 12.2 of the SHIM6 protocol 567 description [I-D.ietf-shim6-proto], and its shim context state is 568 ESTABLISHED. The receiver processes a valid message by inspecting 569 its options, and executing any actions specified for such options. 571 Discussion: It may appear prudent to include additional fields 572 that would provide at least a basic level of security, but since 573 data packets also indicate ongoing reachability, just as 574 keepalives, and those packets don't have such fields, there is 575 little or no reason to include them in a keepalive. 577 The processing rules for this message are the given in more detail in 578 Section 6. 580 5.2. Probe Message 582 This message performs REAP exploration. Its format is as follows: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0| 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Checksum |R| | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 591 | Receiver Context Tag | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Precvd| Psent |Sta| Reserved2 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | | 596 + First probe sent + 597 | | 598 + Source address + 599 | | 600 + + 601 | | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | 604 + First probe sent + 605 | | 606 + Destination address + 607 | | 608 + + 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | First probe nonce | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | First probe option | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 / / 616 / Nth probe sent / 617 | | 618 + Source address + 619 | | 620 + + 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | 624 + Nth probe sent + 625 | | 626 + Destination address + 627 | | 628 + + 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Nth probe nonce | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Nth probe option | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | | 636 + First probe received + 637 | | 638 + Source address + 639 | | 640 + + 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 + First probe received + 645 | | 646 + Destination address + 647 | | 648 + + 649 | | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | First probe nonce | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | First probe option | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | | 656 + Nth probe received + 657 | | 658 + Source address + 659 | | 660 + + 661 | | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | | 664 + Nth probe received + 665 | | 666 + Destination address + 667 | | 668 + + 669 | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Nth probe nonce | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Nth probe option | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | | 676 + Options + 677 | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | | 680 + Options + 681 | | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Next Header, Hdr Ext Len, 0, 0, Checksum 686 These are as specified in Section 5.3 of the SHIM6 protocol 687 description [I-D.ietf-shim6-proto]. 689 Type 691 This field identifies the Probe message and MUST be set to 67 692 (Probe). 694 Reserved 696 This is a 7-bit field reserved for future use. It is set to zero 697 on transmit, and MUST be ignored on receipt. 699 R 701 This is a 1-bit field reserved for future use. It is set to zero 702 on transmit, and MUST be ignored on receipt. 704 Receiver Context Tag 706 This is a 47-bit field for the Context Tag the receiver has 707 allocated for the context. 709 Psent 711 This is a 4-bit field that indicates the number of sent probes 712 included in this probe message. The first set of probe fields 713 pertains to the current message and MUST be present, so the 714 minimum value for this field is 1. Additional sent probe fields 715 are copies of the same fields sent in (recent) earlier probes and 716 may be included or omitted as per any logic employed by the 717 implementation. 719 Precvd 721 This is a 4-bit field that indicates the number of received probes 722 included in this probe messsage. Received probe fields are copies 723 of the same fields received in (recent) earlier probes and may be 724 included or omitted as per any logic employed by the 725 implementation. 727 The fields probe source, probe destination, probe nonce and probe 728 option may be repeated, depending on the value of Psent and 729 Preceived. 731 Sta (State) 733 This 2-bit State field is used to inform the peer about the state 734 of the sender. It has three legal values: 736 0 (Operational) implies that the sender both (a) believes it has 737 no problem communicating and (b) believes that the recipient also 738 has no problem communicating. 740 1 (Exploring) implies that the sender has a problem communicating 741 with the recipient, e.g., it has not seen any traffic from the 742 recipient even when it expected some. 744 2 (ExploringOk) implies that the sender believes it has no problem 745 communicating, but that the recipient either has a problem or has 746 not yet confirmed the sender that the problem has been solved. 748 Reserved2 750 MUST be set to 0 upon transmission and MUST be ignored upon 751 reception. 753 Probe source 755 This 128-bit field contains the source IPv6 address used to send 756 the probe. 758 Probe destination 760 This 128-bit field contains the destination IPv6 address used to 761 send the probe. 763 Probe nonce 765 This is a 32-bit field that is initialized by the sender with a 766 value that allows it to determine which sent probes a received 767 probe correlates with. It is highly recommeded that the nonce 768 field is at least moderately hard to guess so that even on-path 769 attackers can't deduce the next nonce value that will be used. 770 This value SHOULD be generated using a random number generator 771 that is known to have good randomness properties as outlined in 772 RFC 1750 [RFC1750]. 774 Probe option 776 This is a 32-bit field with no fixed meaning. The probe option 777 field is copied back with no changes. Future flags may define a 778 use for this field. 780 Discussion: One potential use of this field relates to 781 communicating delays between reception of a probe and 782 transmission of a reply to it. 784 Options 786 For future extensions. 788 6. Behaviour 790 The required behaviour of REAP nodes is specified below in the form 791 of a state machine. The externally observable behaviour of an 792 implementation MUST conform to this state machine, but there is no 793 requirement that the implementation actually employs a state machine. 794 Intermixed with the following description we also provide a state 795 machine description in a tabular form. That form is only 796 informational, however. 798 On a given context with a given peer, the node can be in one of three 799 states: Operational, Exploring, or ExploringOK. In the Operational 800 state the underlying address pairs are assumed to be operational. In 801 the Exploring state this node has observed a problem and has 802 currently not seen any traffic from the peer. Finally, in the 803 ExploringOK state this node sees traffic from the peer, but peer may 804 not yet see any traffic from this node so that the exploration 805 process needs to continue. 807 The node maintains also the Send timer (Send Timeout seconds) and 808 Keepalive timer (Keepalive Timeout seconds). The Send timer reflects 809 the requirement that when this node sends a payload packet there 810 should be some return traffic (either payload packets or Keepalive 811 messages) within Send Timeout seconds. The Keepalive timer reflects 812 the requirement that when this node receives a payload packet there 813 should a similar response towards the peer. The Keepalive timer is 814 only used within the Operational state, and the Send timer in the 815 Operational and ExploringOK states. No timer is running in the 816 Exploring state. 818 Upon the reception of a payload packet in the Operational state, the 819 node starts the Keepalive timer if it is not yet running, and stops 820 the Send timer if it was running. If the node is in the Exploring 821 state it transitions to the ExploringOK state, sends a Probe message, 822 and starts the Send timer. In the ExploringOK state the node stops 823 the Send timer if it was running, but does not do anything else. The 824 reception of SHIM6 control messages other than the Keepalive and 825 Probe messages are treated similarly with payload packets. 827 When sending a Probe message, the State field MUST be set to a value 828 that matches the conceptual state of the sender after sending the 829 Probe. 831 1. EVENT: Incoming payload packet 832 ================================= 834 Operational Exploring ExploringOk 835 ------------------------------------------------------------- 836 STOP Send; SEND Probe ExploringOk; STOP Send 837 START Keepalive START Send; 838 GOTO ExploringOk 840 Upon sending a payload packet in the Operational state, the node 841 stops the Keepalive timer if it was running and starts the Send timer 842 if it was not running. In the Exploring state there is no effect, 843 and in the ExploringOK state the node simply starts the Send timer if 844 it was not yet running. (The sending of SHIM6 control messages is 845 again treated similarly here.) 847 2. EVENT: Outgoing payload packet 848 ================================= 850 Operational Exploring ExploringOk 851 ----------------------------------------------------------- 852 START Send; - START Send 853 STOP Keepalive 855 Upon a timeout on the Keepalive timer the node sends a Keepalive 856 message. This can only happen in the Operational state. 858 3. EVENT: Keepalive timeout 860 Operational Exploring ExploringOk 861 ----------------------------------------------------------- 862 SEND Keepalive - - 864 Upon a timeout on the Send timer, the node enters the Exploring 865 state, sends a Probe, and stops the Keepalive timer if it was 866 running. 868 4. EVENT: Send timeout 869 ====================== 871 Operational Exploring ExploringOk 872 ----------------------------------------------------------- 873 SEND Probe Exploring; - SEND Probe Exploring; 874 STOP Keepalive; GOTO Exploring 875 GOTO Exploring 877 While in the Exploring state the node keeps retransmitting its Probe 878 messages to different (or same) addresses as defined in Section 4.3. 880 A similar process is employed in the ExploringOk state, except that 881 upon such retransmission the Send timer is started if it was not 882 running already. 884 5. EVENT: Retransmission 885 ======================== 887 Operational Exploring ExploringOk 888 ---------------------------------------------------------- 889 - SEND Probe Exploring SEND Probe ExploringOk 890 START Send 892 Upon the reception of a Keepalive message in the Operational state, 893 the node stops the Send timer, if it was running. If the node is in 894 the Exploring state it transitions to the ExploringOK state, sends a 895 Probe message, and starts the Send timer. In the ExploringOK state 896 the Send timer is stopped, if it was running. 898 6. EVENT: Reception of the Keepalive message 899 ============================================ 901 Operational Exploring ExploringOk 902 ----------------------------------------------------------- 903 STOP Send SEND Probe ExploringOk; STOP Send 904 START Send; 905 GOTO ExploringOk 907 Upon receiving a Probe with State set to Exploring, the node enters 908 the ExploringOK state, sends a Probe, stops the Keepalive timer if it 909 was running, and restarts the Send timer. 911 7. EVENT: Reception of the Probe message State=Exploring 912 ======================================================== 914 Operational Exploring ExploringOk 915 ----------------------------------------------------------- 916 SEND Probe ExploringOk; SEND Probe ExploringOk; SEND Probe 917 STOP Keepalive; START Send; ExploringOk; 918 RESTART Send; GOTO ExploringOk RESTART Send 919 GOTO ExploringOk 921 Upon the reception of a Probe message with State set to ExploringOk, 922 the node sends a Probe message, restarts the Send timer, stops the 923 Keepalive timer if it was running, and transitions to the Operational 924 state. 926 8. EVENT: Reception of the Probe message State=ExploringOk 927 ========================================================== 929 Operational Exploring ExploringOk 930 ------------------------------------------------------------- 931 SEND Probe Operational; SEND Probe Operational; SEND Probe 932 RESTART Send; RESTART Send; Operational; 933 STOP Keepalive GOTO Operational RESTART Send; 934 GOTO Operational 936 Upon the reception of a Probe message with State set to Operational, 937 the node stops the Send timer if it was running, starts the Keepalive 938 timer if it was not yet running, and transitions to the Operational 939 state. 941 Note: This terminates the exploration process when both parties 942 are happy and know that their peer is happy as well. 944 9. EVENT: Reception of the Probe message State=Operational 945 ========================================================== 947 Operational Exploring ExploringOk 948 ----------------------------------------------------------- 949 STOP Send STOP Send; STOP Send; 950 START Keepalive START Keepalive START Keepalive 951 GOTO Operational GOTO Operational 953 The reachability detection and exploration process has no effect on 954 payload communications until a new operational address pairs have 955 actually been confirmed. Prior to that the payload packets continue 956 to be sent to the previously used addresses. 958 In the PDF version of this specification, an informational drawing 959 illustrates the state machine. Where the text and the drawing 960 differ, the text takes precedence. 962 7. Example Protocol Runs 964 This section has examples of REAP protocol runs in typical scenarios. 965 We start with the simplest scenario of two hosts, A and B, that have 966 a SHIM6 connection with each other but are not currently sending any 967 data. As neither side sends anything, they also do not expect 968 anything back, so there are no messages at all: 970 EXAMPLE 1: No communications 972 Peer A Peer B 973 | | 974 | | 975 | | 976 | | 977 | | 978 | | 979 | | 980 | | 982 Our second example involves an active connection with bidirectional 983 payload packet flows. Here the reception of data from the peer is 984 taken as an indication of reachability, so again there are no extra 985 packes: 987 EXAMPLE 2: Bidirectional communications 989 Peer A Peer B 990 | | 991 | payload packet | 992 |-------------------------------------------->| 993 | | 994 | payload packet | 995 |<--------------------------------------------| 996 | | 997 | payload packet | 998 |-------------------------------------------->| 999 | | 1000 | | 1002 The third example is the first one that involves an actual REAP 1003 message. Here the hosts communicate in just one direction, so REAP 1004 messages are needed to indicate to the peer that sends payload 1005 packets that its packets are getting through: 1007 EXAMPLE 3: Unidirectional communications 1009 Peer A Peer B 1010 | | 1011 | payload packet | 1012 |-------------------------------------------->| 1013 | | 1014 | payload packet | 1015 |-------------------------------------------->| 1016 | | 1017 | payload packet | 1018 |-------------------------------------------->| 1019 | | 1020 | Keepalive id=p | 1021 |<--------------------------------------------| 1022 | | 1023 | payload packet | 1024 |-------------------------------------------->| 1025 | | 1026 | | 1028 The next example involves a failure scenario. Here A has addresses A 1029 and B has addresses B1 and B2. The currently used address pairs are 1030 (A, B1) and (B1, A). All connections via B1 become broken, which 1031 leads to an exploration process: 1033 EXAMPLE 4: Failure scenario 1035 Peer A Peer B 1036 | | 1037 State: | State: 1038 Operational | Operational 1039 | (A,B1) payload packet | 1040 |-------------------------------------------->| 1041 | | 1042 | (B1,A) payload packet | 1043 |<--------------------------------------------| At time T1 1044 | | path A<->B1 1045 | (A,B1) payload packet | becomes 1046 |----------------------------------------/ | broken 1047 | | 1048 | ( B1,A) payload packet | 1049 | /-----------------------------------------| 1050 | | 1051 | (A,B1) payload packet | 1052 |----------------------------------------/ | 1053 | | 1054 | (B1,A) payload packet | 1055 | /-----------------------------------------| 1056 | | 1057 | (A,B1) payload packet | 1058 |----------------------------------------/ | 1059 | | 1060 | | 1061 | | 10 seconds after 1062 | (B1,A) Probe id=p, | T1, sends a com- 1063 | state=exploring | plaint that 1064 | /-----------------------------------------| it is not rec- 1065 | | eiving anything 1066 | | State: 1067 | | Exploring 1068 | | 1069 | (B2,A) Probe id=q, | 1070 | state=exploring | But its lost, 1071 |<--------------------------------------------| retransmission 1072 | | uses another pair 1073 A realizes | 1074 that it needs | 1075 to start the | 1076 exploration. It | 1077 picks B2 as the | 1078 most likely candidate, | 1079 as it appeared in the | 1080 Probe | 1081 State: ExploringOk | 1082 | | 1083 | (A, B2) Probe id=r, | 1084 | state=exploringok, | 1085 | received probe q | This one gets 1086 |-------------------------------------------->| through. 1087 | | State: 1088 | | Operational 1089 | | 1090 | | 1091 | (B2,A) Probe id=s, | 1092 | state=operational, | B now knows 1093 | received probe r | that A has no 1094 |<--------------------------------------------| problem to receive 1095 | | its packets 1096 State: Operational | 1097 | | 1098 | (A,B2) payload packet | 1099 |-------------------------------------------->| Payload packets 1100 | | flow again 1101 | (B2,A) payload packet | 1102 |<--------------------------------------------| 1104 The next example shows when the failure for the current locator pair 1105 is in the other direction only. A has addresses A1 and A2, and B has 1106 addresses B1 and B2. The current communication is between A1 and B1, 1107 but A's packets no longer reach B using this pair. 1109 EXAMPLE 5: One-way failure 1111 Peer A Peer B 1112 | | 1113 State: | State: 1114 Operational | Operational 1115 | | 1116 | (A1,B1) payload packet | 1117 |-------------------------------------------->| 1118 | | 1119 | (B1,A1) payload packet | 1120 |<--------------------------------------------| 1121 | | 1122 | (A1,B1) payload packet | At time T1 1123 |----------------------------------------/ | path A1->B1 1124 | | becomes 1125 | | broken 1126 | (B1,A1) payload packet | 1127 |<--------------------------------------------| 1128 | | 1129 | (A1,B1) payload packet | 1130 |----------------------------------------/ | 1131 | | 1132 | (B1,A1) payload packet | 1133 |<--------------------------------------------| 1134 | | 1135 | (A1,B1) payload packet | 1136 |----------------------------------------/ | 1137 | | 1138 | | 10 seconds after 1139 | (B1,A1) Probe id=p, | T1, B sends a com- 1140 | state=exploring | plaint that 1141 |<--------------------------------------------| it is not rec- 1142 | | eiving anything 1143 A responds | State: Exploring 1144 State: ExploringOk | 1145 | | 1146 | (A1, B1) Probe id=q, | 1147 | state=exploringok, | 1148 | received payload, | 1149 | received probe q | 1150 |----------------------------------------/ | But A's response 1151 | | is lost 1152 | (B2,A2) Probe id=r, | 1153 | state=exploring | Next try different 1154 |<--------------------------------------------| locator pair 1155 | | 1156 | (A2, B2) Probe id=s, | 1157 | state=exploringok, | 1158 | received payload, | 1159 | received probes p, r | This one gets 1160 |-------------------------------------------->| through 1161 | | State: Operational 1162 | | 1163 | | B now knows 1164 | | that A has no 1165 | (B2,A2) Probe id=t, | problem to receive 1166 | state=operational, | its packets, and 1167 | received probe s | that A's probe 1168 |<--------------------------------------------| gets to B. It 1169 | | sends a 1170 State: Operational | confirmation to A 1171 | | 1172 | (A2,B2) payload packet | 1173 |-------------------------------------------->| Payload packets 1174 | | flow again 1175 | (B1,A1) payload packet | 1176 |<--------------------------------------------| 1178 8. Protocol Constants 1180 The following protocol constants are defined: 1182 Send Timeout 10 seconds 1183 Keepalive Interval Not specified here 1184 Initial Probe Timeout 0.5 seconds 1185 Number of Initial Probes 4 probes 1186 Max Probe Timeout 60 seconds 1188 9. Security Considerations 1190 Attackers may spoof various indications from lower layers and the 1191 network in an effort to confuse the peers about which addresses are 1192 or are not operational. For example, attackers may spoof ICMP error 1193 messages in an effort to cause the parties to move their traffic 1194 elsewhere or even to disconnect. Attackers may also spoof 1195 information related to network attachments, router discovery, and 1196 address assignments in an effort to make the parties believe they 1197 have Internet connectivity when in reality they do not. 1199 This may cause use of non-preferred addresses or even denial-of- 1200 service. 1202 This protocol does not provide any protection of its own for 1203 indications from other parts of the protocol stack. Unprotected 1204 indications SHOULD NOT be taken as a proof of connectivity problems. 1205 However, REAP has weak resistance against incorrect information even 1206 from unprotected indications in the sense that it performs its own 1207 tests prior to picking a new address pair. Denial-of- service 1208 vulnerabilities remain, however, as do vulnerabilities against on 1209 path attackers. 1211 Some aspects of these vulnerabilities can be mitigated through the 1212 use of techniques specific to the other parts of the stack, such as 1213 properly dealing with ICMP errors [I-D.ietf-tcpm-icmp-attacks], link 1214 layer security, or the use of SEND [RFC3971] to protect IPv6 Router 1215 and Neighbor Discovery. 1217 Other parts of the SHIM6 protocol ensure that the set of addresses we 1218 are switching between actually belong together. REAP itself provides 1219 no such assurances. Similarly, REAP provides only minimal protection 1220 against third party flooding attacks; when REAP is run its Probe 1221 identifiers can be used as a return routability check that the 1222 claimed address is indeed willing to receive traffic. However, this 1223 needs to be complemented with another mechanism to ensure that the 1224 claimed address is also the correct host. SHIM6 does this by 1225 performing binding of all operations to context tags. 1227 The keepalive mechanism in this specification is vulnerable to 1228 spoofing. On path-attackers that can see a SHIM6 context tag can 1229 send spoofed Keepalive messages once per Send Timeout interval, to 1230 prevent two SHIM6 nodes from sending Keepalives themselves. This 1231 vulnerability is only relevant to nodes involved in a one-way 1232 communication. The result of the attack is that the nodes enter the 1233 exploration phase needlessly, but they should be able to confirm 1234 connectivity unless, of course, the attacker is able to prevent the 1235 exploration phase from completing. Off-path attackers may not be 1236 able to generate spoofed results, given that the context tags are 47- 1237 bit random numbers. 1239 The exploration phase is vulnerable to attackers that are on the 1240 path. Off-path attackers would find it hard to guess either the 1241 context tag or the correct probe identifiers. Given that IPsec 1242 operates above the shim layer, it is not possible to protect the 1243 exploration phase against on-path attackers. This is similar to the 1244 ability to protect other Shim6 control exchanges. There are 1245 mechanisms in place to prevent the redirection of communications to 1246 wrong addresses, but on-path attackers can cause denial-of-service, 1247 move communications to less-preferred address pairs, and so on. 1249 Finally, the exploration itself can cause a number of packets to be 1250 sent. As a result it may be used as a tool for packet amplification 1251 in flooding attacks. In order to prevent this it is required that 1252 the protocol employing REAP has built-in mechanisms to prevent this. 1253 For instance, in SHIM6 contexts are created only after a relatively 1254 large number of packets has been exchanged, a cost which reduces the 1255 attractiveness of using SHIM6 and REAP for amplification attacks. 1256 However, such protections are typically not present at connection 1257 establishment time. When exploration would be needed for connection 1258 establishment to succeed, its usage would result in an amplification 1259 vulnerability. As a result, SHIM6 does not support the use of REAP 1260 in connection establishment stage. 1262 10. IANA Considerations 1264 No IANA actions are required. 1266 11. References 1268 11.1. Normative References 1270 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1271 Recommendations for Security", RFC 1750, December 1994. 1273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1274 Requirement Levels", BCP 14, RFC 2119, March 1997. 1276 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1277 Discovery for IP Version 6 (IPv6)", RFC 2461, 1278 December 1998. 1280 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1281 Autoconfiguration", RFC 2462, December 1998. 1283 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1284 and M. Carney, "Dynamic Host Configuration Protocol for 1285 IPv6 (DHCPv6)", RFC 3315, July 2003. 1287 [RFC3484] Draves, R., "Default Address Selection for Internet 1288 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1290 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1291 Addresses", RFC 4193, October 2005. 1293 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1294 for IPv6", RFC 4429, April 2006. 1296 11.2. Informative References 1298 [AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1299 Location Management", In Proceedings of the 18th Annual 1300 Computer Security Applications Conference, Las Vegas, 1301 Nevada, USA., December 2002. 1303 [I-D.bagnulo-shim6-addr-selection] 1304 Bagnulo, M., "Address selection in multihomed 1305 environments", draft-bagnulo-shim6-addr-selection-00 (work 1306 in progress), October 2005. 1308 [I-D.huitema-multi6-addr-selection] 1309 Huitema, C., "Address selection in multihomed 1310 environments", draft-huitema-multi6-addr-selection-00 1311 (work in progress), October 2004. 1313 [I-D.ietf-dna-cpl] 1314 Nordmark, E. and J. Choi, "DNA with unmodified routers: 1315 Prefix list based approach", draft-ietf-dna-cpl-02 (work 1316 in progress), January 2006. 1318 [I-D.ietf-dna-protocol] 1319 Kempf, J., "Detecting Network Attachment in IPv6 Networks 1320 (DNAv6)", draft-ietf-dna-protocol-01 (work in progress), 1321 June 2006. 1323 [I-D.ietf-hip-mm] 1324 Nikander, P., "End-Host Mobility and Multihoming with the 1325 Host Identity Protocol", draft-ietf-hip-mm-04 (work in 1326 progress), June 2006. 1328 [I-D.ietf-shim6-locator-pair-selection] 1329 Bagnulo, M., "Default Locator-pair selection algorithm for 1330 the SHIM6 protocol", 1331 draft-ietf-shim6-locator-pair-selection-00 (work in 1332 progress), May 2006. 1334 [I-D.ietf-shim6-proto] 1335 Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1336 protocol", draft-ietf-shim6-proto-05 (work in progress), 1337 May 2006. 1339 [I-D.ietf-shim6-reach-detect] 1340 Beijnum, I., "Shim6 Reachability Detection", 1341 draft-ietf-shim6-reach-detect-01 (work in progress), 1342 October 2005. 1344 [I-D.ietf-tcpm-icmp-attacks] 1345 Gont, F., "ICMP attacks against TCP", 1346 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 1347 February 2006. 1349 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1350 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1351 Zhang, L., and V. Paxson, "Stream Control Transmission 1352 Protocol", RFC 2960, October 2000. 1354 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1355 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1357 Appendix A. Contributors 1359 This draft attempts to summarize the thoughts and unpublished 1360 contributions of many people, including the MULTI6 WG design team 1361 members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis 1362 Lindqvist, Margaret Wasserman, and Jukka Ylitalo, the MOBIKE WG 1363 contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer 1364 Dawkins, and James Kempf, and HIP WG contributors such as Pekka 1365 Nikander. This draft is also in debt to work done in the context of 1366 SCTP [RFC2960] and HIP multihoming and mobility extension 1367 [I-D.ietf-hip-mm]. 1369 Appendix B. Acknowledgements 1371 The authors would also like to thank Christian Huitema, Pekka Savola, 1372 John Loughney, Sam Xia, and Hannes Tschofenig for interesting 1373 discussions in this problem space, and for review of this 1374 specification. 1376 Authors' Addresses 1378 Jari Arkko 1379 Ericsson 1380 Jorvas 02420 1381 Finland 1383 Email: jari.arkko@ericsson.com 1385 Iljitsch van Beijnum 1387 Email: iljitsch@muada.com 1389 Full Copyright Statement 1391 Copyright (C) The Internet Society (2006). 1393 This document is subject to the rights, licenses and restrictions 1394 contained in BCP 78, and except as set forth therein, the authors 1395 retain all their rights. 1397 This document and the information contained herein are provided on an 1398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1400 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1401 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1402 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1405 Intellectual Property 1407 The IETF takes no position regarding the validity or scope of any 1408 Intellectual Property Rights or other rights that might be claimed to 1409 pertain to the implementation or use of the technology described in 1410 this document or the extent to which any license under such rights 1411 might or might not be available; nor does it represent that it has 1412 made any independent effort to identify any such rights. Information 1413 on the procedures with respect to rights in RFC documents can be 1414 found in BCP 78 and BCP 79. 1416 Copies of IPR disclosures made to the IETF Secretariat and any 1417 assurances of licenses to be made available, or the result of an 1418 attempt made to obtain a general license or permission for the use of 1419 such proprietary rights by implementers or users of this 1420 specification can be obtained from the IETF on-line IPR repository at 1421 http://www.ietf.org/ipr. 1423 The IETF invites any interested party to bring to its attention any 1424 copyrights, patents or patent applications, or other proprietary 1425 rights that may cover technology that may be required to implement 1426 this standard. Please address the information to the IETF at 1427 ietf-ipr@ietf.org. 1429 Acknowledgment 1431 Funding for the RFC Editor function is provided by the IETF 1432 Administrative Support Activity (IASA).