idnits 2.17.1 draft-oliva-hiprg-reap4hip-00.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, updated by RFC 4748 on line 746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 770. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 427: '...eepAlive message and MUST be set to 66...' RFC 2119 keyword, line 571: '...he Probe message and MUST be set to 67...' RFC 2119 keyword, line 590: '...rent message and MUST be present, so t...' RFC 2119 keyword, line 622: '... MUST be set to 0 upon transmissi...' RFC 2119 keyword, line 639: '... This value SHOULD be generated u...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 2, 2007) is 6136 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC1750' on line 641 Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG A. de la Oliva 3 Internet-Draft UC3M 4 Intended status: Experimental M. Bagnulo 5 Expires: January 3, 2008 Huawei Labs at UC3M 6 July 2, 2007 8 Fault tolerance configurations for HIP multihoming 9 draft-oliva-hiprg-reap4hip-00 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 January 3, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document considers scenarios for the provision of fault 43 tolerance capabilities in multihomed HIP nodes. In order to support 44 such configurations, this document updates the behaviour for HIP 45 multihoming nodes currently defined and defines the integration of 46 the REAP protocol in HIP. 48 Table of Contents 50 1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Locator management . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Failure detection and alternative path exploration for HIP . . 5 53 3.1. Multihoming scenario . . . . . . . . . . . . . . . . . . . 5 54 3.2. Failure detection and recovery . . . . . . . . . . . . . . 7 55 3.3. Processing of the REAP messages . . . . . . . . . . . . . 8 56 4. HIP comformant REAP messages . . . . . . . . . . . . . . . . . 9 57 4.1. KeepAlive Message . . . . . . . . . . . . . . . . . . . . 9 58 4.2. Probe Message . . . . . . . . . . . . . . . . . . . . . . 11 59 4.3. Keepalive Timeout Option Format . . . . . . . . . . . . . 15 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 61 6. Acknoledgements . . . . . . . . . . . . . . . . . . . . . . . 16 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 64 Intellectual Property and Copyright Statements . . . . . . . . . . 18 66 1. Introducion 68 Multihoming support for HIP is defined in draft-ietf-hip-mm [2]. It 69 relies on the usage of UPDATE messages to convey information about 70 the alternative locators available for the HIP nodes. The 71 aforementioned specification defines the basic support for 72 multihoming and covers some basic scenarios but it postpones the 73 analysis of more advanced multihoming scenarios for future study. 74 This document considers additional multihoming scenarios, especially 75 focussing on the provision of fault tolerance capabilities in 76 multihomed HIP nodes. In order to support such fault tolerant 77 configurations, this document updates the behaviour for HIP 78 multihoming nodes defined in [2] and defines the integration of the 79 REAP protocol as defined in draft-ietf-shim6-failure-detection [4] in 80 HIP. 82 2. Locator management 84 A multihomed HIP node has multiple locators that can have different 85 reachability status. Some of them can be operational/reachable while 86 other may be not. Fault tolerance is a preferred capability of such 87 configuration. In order to provide basic fault tolerance support, a 88 HIP node should be able to perform the following functions: First, 89 the multihomed HIP nodes must be able to convey the locally available 90 locator set to the peer. Second, the nodes should be able to monitor 91 the communication and detect failures. In case that a failure is 92 detected, they must be able to discover alternative working locator 93 pairs and divert the communication through the alternative locator 94 pair. In this section, we focus in the locator management part, and 95 in the next section we will focus on the failure detection and 96 alternative path exploration part. It should be noted that for the 97 provision of basic fault tolerance capabilities, the locators are 98 managed following the following guidelines: 99 o All the locators available for each peers that are to be used to 100 provide fault tolerance must be exchanged early in the 101 communication, so they can be used as alternative locators in case 102 of a failure. This is different from the mobility case described 103 in [2] since the peers only know a single locator of the peer at 104 the time. 105 o However, the locators are only used sequentially and not in 106 parallel. This is so, because as long a locator pair is working, 107 the peers stick to that pair for exchanging data packets and they 108 only change the locator pair used when there is a failure. This 109 is different from the general multihoming scenario considered in 110 [2] since locator pairs are not used in parallel. This particular 111 constraint reduces considerably the possibility of packet 112 reordering and hence the possibility of having problems with the 113 reply protection window due to reordering of packets that travel 114 through different paths. 116 In the general multihoming scenario defined in [2], a multihomed node 117 is recommended to create different SAs and use different SPIs for 118 each locator pair available for the communication between two 119 multihomed nodes to avoid problems with the anti-replay protection 120 window resulting from reordering packets when using multiple paths 121 simultaneously. While this is required for the general multihoming 122 scenario, this is an expensive approach, because it requires a high 123 number of SAs to be created and it also requires a significant 124 signaling overhead. Basically in a multihoming scenario where a 125 multihomed node A that has m locators is communicating with another 126 multihomed node B that has n locators, they need to exchange m+n 127 UPDATE messages to convey all the locator information. This is so, 128 because they need to convey SPI information for each of the locator 129 pairs. Node A does so by sending an n UPDATE messages. Each one of 130 these n UPDATE messages contains the m locally available locators 131 with an SPI value for each locator. Each of the n UPDATE messages is 132 addressed to a different locator of the n available at node B. In 133 this way, the information of the m*n SPIs values for the different 134 locator pairs is exchanged between the peers. While all the overhead 135 and complexity is required when using multiple locator pairs in 136 parallel, this is not the case for a fault tolerant configuration, 137 where the locator pairs will be used sequentially. Hence, in the 138 document we define a modified behaviour for HIP multihomed nodes for 139 fault tolerance support. 141 For fault tolerance, only sequential use of locator pairs is 142 required. This is similar to the mobility case, the difference being 143 that the locator set for each peer is known beforehand. In order to 144 support this configuration, the following behaviour is defined for 145 HIP nodes. Each node will convey the available locator set 146 information to the peer in a single UPDATE message. The Old SPI and 147 the New SPI values of the LOCATOR parameter will be equal and set to 148 the current SPI value for every locator in the message. Each node 149 will use a single SA and a single SPI value for all the locator pairs 150 available for the configuration. Only a single locator pair will be 151 active, and all the traffic will be sent using the preferred (active) 152 locator pair. Upon the reception of one UPDATE message containing 153 multiple locators with a single SPI value for both the OlD SPI and 154 the New SPI for all the locators, the receiver will verify the 155 locators contained in the UPDATE message as defined in [2]. After 156 that, the receiver will identify that it is in the fault tolerance 157 scenario and will create locator pairs using all the received 158 locators and all the locally available locators, irrespectively of 159 the locator to which the UPDATE message was sent. The result is that 160 each of the peers will have all the locator pairs available for use 161 in case that a failure occurs. 163 After the locator sets have been exchanged, the peers use the REAP 164 protocol as defined in the next section to detect failure, explore 165 alternative locator pairs and divert the communication through 166 alternative working locators. 168 3. Failure detection and alternative path exploration for HIP 170 Multihoming support for the HIP protocol as defined in [2] relies in 171 the usage of the UPDATE message to convey multiple alternative 172 locators for a given HI/HIT that is being used as identifier for 173 ongoing communications between two nodes. By including alternative 174 locators associated to the multihoming configuration, the 175 communication between the two nodes is more reliable, since it is 176 possible to use alternative locator pairs in case the original one 177 should fail. As currently defined, the HIP protocol is capable of 178 exchanging the alternative locators, validate them and use them to 179 exchange packets. However, the capabilities required for detecting 180 failures and exploring alternative working locators are still 181 lacking. The REAP protocol [4] provides such capabilities for the 182 Shim6 protocol [3] and can be used to provide the lacking failure 183 detection and path exploration capabilities in HIP. This section 184 defines how the REAP protocol [4] can be used to detect failures and 185 explore alternative paths between two hosts using HIP multihoming. 187 3.1. Multihoming scenario 189 The considered scenario consists of two HIP hosts that are 190 communicating. At least one of them has multiple locators which may 191 have different reachability status. In order to benefit from the 192 enhanced fault tolerance capabilities resulting from multihoming, the 193 decide to exchange the alternative locators available at each end. 195 The exchange of the locator set of each end host can be performed in 196 two ways: 197 o Each end point of the communication may send a LOCATOR parameter 198 on R1 and I2 messages of the HIP connection establishment as 199 defined on [2]. 200 o The HIP protocol specified on [1] supports the modification of the 201 locator set currently being used by the exchange of the UPDATE 202 message. 204 Herein we describe the use of the UPDATE packet to exchange the 205 locator set but a similar scenario would result if the locator sets 206 were exchanged using the R2 and I2 messages. 208 The exchange of locators in the UPDATE packet is secured by the use 209 of HMAC and HIP_SIGNATURE on the message. A number of combinations 210 of parameters in an UPDATE packet are possible (see [2]). In this 211 scenario we consider the case where one LOCATOR and one ESP_INFO 212 parameter is used in any HIP packet. Other configurations may be 213 possible although are out of the scope of this document. As 214 specified on [2] the LOCATOR parameter should list all the locators 215 that are active on the HIP association, so the UPDATE packet sent to 216 the peer will inform of all the locators which can be used to reach 217 the host on this HIP association. 219 The locators stored on the LOCATOR parameter may be: 220 o IPv6 or an IPv4-in-IPv6 format IPv4 adress (for non ESP based 221 usage). 222 o The concatenation of an ESP SPI (first 32 bits) followed by an 223 IPv6 address or IPv4-in-IPv6 format IPv4 address (128 bits) for 224 ESP use. 226 On the LOCATOR parameter, there is a bit (P) which express the 227 preferred locator. This bit must be set to one on the active locator 228 for this communication and 0 in all the others to prevent a change of 229 the active locators. 231 The UPDATE packet may contain a ESP_INFO parameter, rules for 232 processing this parameter are given on [2] and are assumed to be 233 valid on this document. Once an UPDATE message is received, the 234 locators listed on the LOCATOR parameter are processed following the 235 guidelines of [2]. After the processing, the SA will have a list 236 with all the available addresses of the peer. The address in use 237 will be on ACTIVE state and the rest will be on UNVERIFIED state. 238 Note that in [2] is stated that after receiving an UPDATE message 239 with a LOCATOR parameter included, the only valid locator pairs 240 created are between the new locators added and the source address of 241 the UPDATE message. We extend this behaviour on Section 2 to allow 242 the creation of pairs between all the locators of both endpoints. 244 Note that with this approach a communication between two endhosts 245 (A,B), having A n possible locators and B m, leads to an SA with n*m 246 valid locator pairs. Once finished the locator exchange, we assume 247 each endhost SA will have n*m valid locator pairs. 249 At this stage, the hosts are ready to benefit from the enhanced fault 250 tolerance capabilities resulting from multihoming, and use the REAP 251 protocol to detect failures in the current locator pair and to 252 explore alternative working locators pairs in case the current one 253 should fail. We describe how this is done in the following section. 255 3.2. Failure detection and recovery 257 The REAP protocol [4] defined in the Shim6 architecture [3] provides 258 path failure detection and alternative path exploration capabilities 259 between two multihomed hosts. It relies in two mechanisms, namely, 260 the failure detection mechanism and the path exploration mechanism. 262 The failure detection mechanism is based on the Forced Bidirectional 263 Detection (FBD) technique, which consists on making sure that 264 whenever there is data traffic in one direction, there is also 265 traffic in the other direction. This is accomplished by injecting 266 additional control messages (called KeepAlives messages) when needed, 267 which guarantee that the frequency of traffic in the reverse 268 direction is above a predetermined threshold. The result is that 269 when there is a ongoing data communication between two REAP peers, 270 both peers can expect an incoming traffic frequency that is above the 271 predetermined threshold defined by REAP. If the incoming traffic 272 frequency is below this threshold, then this implies that a failure 273 has occurred. In other words, after a given period of time no 274 traffic has been received a failure on the path is assumed and the 275 alternative path exploration mechanism is triggered. 277 The current implementation the REAP protocol relies on two timers, 278 the Keep Alive Timer and the Send Timer, and a control message, 279 namely the Keepalive message. The Keep Alive Timer TKA is started 280 each time a node receives a data packet from its peer, and stopped 281 and reset, each time the node sends a packet to the peer. When the 282 Keep Alive Timer expires, a Keep Alive message is sent to the peer. 283 The Send Timer TSend, defined roughly as three times the Keep Alive 284 Timer plus a deviation to accommodate the Round Trip Time, is started 285 each time the node sends a packet and stopped each time the node 286 receives a packet from the peer. If no answer (either a Keep Alive 287 or data packet) is received in the Send Timer period a failure is 288 assumed and a locator path exploration is started. Consequently, the 289 Send Timer reflects the requirement that when a node sends a payload 290 packet there should be some return traffic within Send Timeout 291 seconds. On the other hand, the Keepalive timer reflects the 292 requirement that when a node receives a payload packet there should a 293 similar response towards the peer within Keepalive seconds (if no 294 traffic is interchanged, there is no Keep Alive signaling). 296 The path exploration mechanism starts whenever the node has not 297 received any packet during a fixed period of time (Send Timer). A 298 path may become invalid either bacause one of the locators used may 299 became invalid or inoperational, or the pair itself has been declared 300 as inoperational. A full exploration mechanism should check all 301 possible pairs of source/destination locators until at least one 302 working locator pair is found. Instead of using a request/response 303 approach the first of both sides which detects the failure tries each 304 of the peer's locators sending probes through each of its interfaces. 305 Each probe carries information about the current state of the 306 communication and the probes which have been received so far through 307 the rest of the interfaces. The state of the connection can be one 308 of three possible states: i) Operational, when both peers can see 309 each other, b)Exploring, when one of the peers have detected a 310 problem and has currently not seen any traffic from the peer or c) 311 Inbound_OK, when the node sees traffic from the peer but the peer 312 does not see any traffic from the node. The information related with 313 the rest of the probes received, which is carried on every probe 314 allows the end hosts to be able to know which are the locator pairs 315 working in the outgoing direction, on the case there are multiple 316 probes. The path exploration mechanism ends when both peers have 317 received a probe confirming that the peer can see them. It should be 318 noted that the defined exploration mechanism is capable of 319 discovering locators pairs that are working in only one direction 320 (i.e. unidirectional reachability) thanks to the information about 321 all received probes contained in all the reply probes. 323 In the current implementation once a node detects a failure, it 324 starts the path exploration mechanism. A Probe message is sent to 325 test the current locator pair, and if no responses are obtained 326 during a period of time called Retransmission Timer (TRTx), the nodes 327 start sending Probes testing the rest of the available address pairs, 328 using all possible source/destination address pairs. Once a probe is 329 received by the node, it sends another probe to the peer indicating 330 that it is seeing traffic from it (Inbound_OK). After receiving this 331 last probe the peer will answer confirming the reception of this last 332 probe and indicating that the new locator pair is in the Operational 333 state. 335 These Probe messages are used to confirm reachability and can be used 336 as an address verification mechanism to modify the state of the 337 locator being probe to ACTIVE. Note that each end point of the 338 communication explores unidirectional reachability and based on its 339 observations decides the pair of locators to use in a not coordinated 340 way. Therefore the pair of locators selected by each end host may be 341 different. 343 At the end of the path exploration mechanism, each host will have a 344 pair of ACTIVE locators which can be used to continue the 345 communication. 347 3.3. Processing of the REAP messages 349 Figure 1 shows the placement of the REAP module within the HIP 350 Multihoming stack. Once some heuristic has decided that a 351 communication should be protected by the REAP protocol, an instance 352 of it is created and associated with the SA to protect. The REAP 353 instance is able to communicate with the ESP and HIP layers. The ESP 354 layer should inform of every packet received or sent associated with 355 the SPI used on the protected HIP association. By this way if 356 rekeying is needed due to a change of locator or any other cause, the 357 ESP layer will still be able to inform REAP of the messages received 358 or sent associated to the protected SA. 360 --------- 361 | TCP | (sockets bound to HITs) 362 --------- 363 | 364 --------- 365 ----> | ESP | {HIT_s, HIT_d} <-> SPI 366 | --------- 367 ---- | 368 | MH | --------- 369 ---- ->| HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} 370 |REAP| --------- 371 ---- | 372 --------- 373 | IP | 374 --------- 376 Figure 1: Architecture for HIP mobility and multihoming (MH) 378 The REAP control messages (Probe, KeepAlive) are not protected by ESP 379 and will be indexed by the Sender's and Receiver's HIT pair. Upon 380 reception of a REAP control message, the HIP layer will demultiplex 381 the control packet and forward it to the corresponding REAP instance. 382 It must be taken into account that if several SAs are used to 383 communicate the same HIT pairs only one instanciation of the REAP 384 protocol is needed. On this case all data packets corresponding with 385 the SAs between the HIT pair will be notified to the same instance of 386 REAP. 388 4. HIP comformant REAP messages 390 4.1. KeepAlive Message 392 The format of the keepalive message is as follows: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Checksum | Controls | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Sender's Host Identity Tag (HIT) | 402 | | 403 | | 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Receiver's Host Identity Tag (HIT) | 407 | | 408 | | 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 / HIP Parameters / 413 / / 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 2: KeepAlive Message 419 Fields: 421 Next Header, Header Length, 0, Version, Reserved, 1, Checksum and HIP 422 Controls: 423 These are as specified in Section 5.1 of the HIP protocol 424 description [1]. 426 Packet Type (as specified in [4]): 427 This field identifies the KeepAlive message and MUST be set to 66 428 (KeepAlive) 430 Sender's Host Identity Tag (HIT): 431 As defined in [1] 433 Receiver's Host Identity Tag (HIT): 434 As defined in [1] 436 HIP parameters: 437 This space is reserved for adding HIP parameters. At least the 438 KeepAlive Timeout Option may be added here. 440 4.2. Probe Message 442 This message performs REAP exploration. Its format is as follows: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Checksum | Controls | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Sender's Host Identity Tag (HIT) | 452 | | 453 | | 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Receiver's Host Identity Tag (HIT) | 457 | | 458 | | 459 | | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 / HIP Parameters / 463 / / 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Precvd| Psent |Sta| Reserved2 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 + First probe sent + 470 | | 471 + Source address + 472 | | 473 + + 474 | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 + First probe sent + 478 | | 479 + Destination address + 480 | | 481 + + 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | First probe nonce | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | First probe data | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 / / 489 / Nth probe sent / 490 | | 491 + Source address + 492 | | 493 + + 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | | 497 + Nth probe sent + 498 | | 499 + Destination address + 500 | | 501 + + 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Nth probe nonce | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Nth probe data | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 + First probe received + 510 | | 511 + Source address + 512 | | 513 + + 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | | 517 + First probe received + 518 | | 519 + Destination address + 520 | | 521 + + 522 | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | First probe nonce | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | First probe data | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | | 529 / / 530 / / 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 + Nth probe received + 534 | | 535 + Source address + 536 | | 537 + + 538 | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 + Nth probe received + 542 | | 543 + Destination address + 544 | | 545 + + 546 | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Nth probe nonce | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Nth probe data | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | 553 + Options + 554 | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 + Options + 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 3: Probe Message 563 Fields: 565 Next Header, Header Length, 0, Version, Reserved, 1, Checksum and HIP 566 Controls: 567 These are as specified in Section 5.1 of the HIP protocol 568 description [1]. 570 Packet Type (as specified in [4]): 571 This field identifies the Probe message and MUST be set to 67 572 (Probe) 574 Sender's Host Identity Tag (HIT): 575 As defined in [1]. 577 Receiver's Host Identity Tag (HIT): 578 As defined in [1]. 580 HIP parameters: 581 This space is reserved for adding HIP parameters. At least the 582 KeepAlive Timeout Option may be added here. 584 The rest of the parameters on the packet are exactly the same as 585 specified on [4]. 587 Psent 588 This is a 4-bit field that indicates the number of sent probes 589 included in this probe message. The first set of probe fields 590 pertains to the current message and MUST be present, so the 591 minimum value for this field is 1. Additional sent probe fields 592 are copies of the same fields sent in (recent) earlier probes and 593 may be included or omitted as per any logic employed by the 594 implementation. 596 Precvd 597 This is a 4-bit field that indicates the number of received probes 598 included in this probe messsage. Received probe fields are copies 599 of the same fields received in (recent) earlier probes and may be 600 included or omitted as per any logic employed by the 601 implementation. 603 The fields probe source, probe destination, probe nonce and probe 604 data may be repeated, depending on the value of Psent and Preceived. 606 Sta (State) 607 This 2-bit State field is used to inform the peer about the state 608 of the sender. It has three legal values: 609 0 (Operational) implies that the sender both (a) believes it 610 has no problem communicating and (b) believes that the 611 recipient also has no problem communicating. 612 1 (Exploring) implies that the sender has a problem 613 communicating with the recipient, e.g., it has not seen any 614 traffic from the recipient even when it expected some. 615 2 (InboundOk) implies that the sender believes it has no 616 problem communicating, i.e., it at least sees packets from the 617 recipient, but that the recipient either has a problem or has 618 not yet confirmed to the sender that the problem has been 619 solved. 621 Reserved2 622 MUST be set to 0 upon transmission and MUST be ignored upon 623 reception. 625 Probe source 626 This 128-bit field contains the source IPv6 address used to send 627 the probe. 629 Probe destination 630 This 128-bit field contains the destination IPv6 address used to 631 send the probe. 633 Probe nonce 634 This is a 32-bit field that is initialized by the sender with a 635 value that allows it to determine which sent probes a received 636 probe correlates with. It is highly recommeded that the nonce 637 field is at least moderately hard to guess so that even on-path 638 attackers can't deduce the next nonce value that will be used. 639 This value SHOULD be generated using a random number generator 640 that is known to have good randomness properties as outlined in 641 RFC 1750 [RFC1750]. 643 Probe data 644 This is a 32-bit field with no fixed meaning. The probe data 645 field is copied back with no changes. Future flags may define a 646 use for this field. 648 4.3. Keepalive Timeout Option Format 650 Either side of a HIP association can notify the peer of the value 651 that it would prefer the peer to use as its Keepalive Timeout value. 652 If the host is using a non-default Send Timeout value, it SHOULD 653 communicate this value as a Keepalive Timeout value to the peer in 654 the below option. This option MAY be sent in the I2, R2, or UPDATE 655 messages. The option SHOULD only need to be sent once in a given HIP 656 association. If a host receives this option it SHOULD update its 657 Keepalive Timeout value for the correspondent. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type = 10 | Length = 4 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 + Reserved | Keepalive Timeout | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 4: KeepAlive Timeout Option Format 669 Fields: 671 Type 672 This field identifies the option and MUST be set to 10 (Keepalive 673 Timeout). 675 The rest of the fiels on this packet are exactly the same as defined 676 on [4]. 678 Length 679 This field MUST be set as specified in Section 5.1 of the HIP 680 protocol description [1]. 682 Reserved 683 16-bit field reserved for future use. Set to zero upon transmit 684 and MUST be ignored upon receipt. 686 Keepalive Timeout 687 Value in seconds corresponding to suggested Keepalive Timeout 688 value for the peer. 690 5. Security Considerations 692 TBD 694 6. Acknoledgements 696 Tom Henderson provided comments and feedback on the contents of this 697 draft. 699 Antonio de la Oliva is partly funded by OneLab, a research project 700 supported by the European Commission under its Sixth Framework 701 Program. The views and conclusions contained herein are those of the 702 authors and should not be interpreted as necessarily representing the 703 official policies or endorsements, either expressed or implied, of 704 the OneLab project or the European Commission. 706 7. References 708 [1] Moskowitz, R., Nikander, P., and T. Henderson, "Host Identity 709 Protocol", June 2007. 711 [2] Henderson, T., "End-Host Mobility and Multihoming with the Host 712 Identity Protocol", March 2007. 714 [3] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim 715 Protocol for IPv6", May 2007. 717 [4] Arkko, J. and I. van Beijnum, "Failure Detection and Locator 718 Pair Exploration Protocol for IPv6 Multihoming", June 2007. 720 Authors' Addresses 722 Antonio de la Oliva 723 UC3M 725 Email: aoliva@it.uc3m.es 727 Marcelo Bagnulo 728 Huawei Labs at UC3M 730 Email: marcelo@it.uc3m.es 732 Full Copyright Statement 734 Copyright (C) The IETF Trust (2007). 736 This document is subject to the rights, licenses and restrictions 737 contained in BCP 78, and except as set forth therein, the authors 738 retain all their rights. 740 This document and the information contained herein are provided on an 741 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 742 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 743 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 744 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 745 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Intellectual Property 750 The IETF takes no position regarding the validity or scope of any 751 Intellectual Property Rights or other rights that might be claimed to 752 pertain to the implementation or use of the technology described in 753 this document or the extent to which any license under such rights 754 might or might not be available; nor does it represent that it has 755 made any independent effort to identify any such rights. Information 756 on the procedures with respect to rights in RFC documents can be 757 found in BCP 78 and BCP 79. 759 Copies of IPR disclosures made to the IETF Secretariat and any 760 assurances of licenses to be made available, or the result of an 761 attempt made to obtain a general license or permission for the use of 762 such proprietary rights by implementers or users of this 763 specification can be obtained from the IETF on-line IPR repository at 764 http://www.ietf.org/ipr. 766 The IETF invites any interested party to bring to its attention any 767 copyrights, patents or patent applications, or other proprietary 768 rights that may cover technology that may be required to implement 769 this standard. Please address the information to the IETF at 770 ietf-ipr@ietf.org. 772 Acknowledgment 774 Funding for the RFC Editor function is provided by the IETF 775 Administrative Support Activity (IASA).