HIPRG A. de la Oliva Internet-Draft UC3M Intended status: Experimental M. Bagnulo Expires: January 3, 2008 Huawei Labs at UC3M July 2, 2007 Fault tolerance configurations for HIP multihoming draft-oliva-hiprg-reap4hip-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document considers scenarios for the provision of fault tolerance capabilities in multihomed HIP nodes. In order to support such configurations, this document updates the behaviour for HIP multihoming nodes currently defined and defines the integration of the REAP protocol in HIP. de la Oliva & Bagnulo Expires January 3, 2008 [Page 1] Internet-Draft Fault Tolerant HIP Multihoming July 2007 Table of Contents 1. Introducion . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Locator management . . . . . . . . . . . . . . . . . . . . . . 3 3. Failure detection and alternative path exploration for HIP . . 5 3.1. Multihoming scenario . . . . . . . . . . . . . . . . . . . 5 3.2. Failure detection and recovery . . . . . . . . . . . . . . 7 3.3. Processing of the REAP messages . . . . . . . . . . . . . 8 4. HIP comformant REAP messages . . . . . . . . . . . . . . . . . 9 4.1. KeepAlive Message . . . . . . . . . . . . . . . . . . . . 9 4.2. Probe Message . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Keepalive Timeout Option Format . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Acknoledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 de la Oliva & Bagnulo Expires January 3, 2008 [Page 2] Internet-Draft Fault Tolerant HIP Multihoming July 2007 1. Introducion Multihoming support for HIP is defined in draft-ietf-hip-mm [2]. It relies on the usage of UPDATE messages to convey information about the alternative locators available for the HIP nodes. The aforementioned specification defines the basic support for multihoming and covers some basic scenarios but it postpones the analysis of more advanced multihoming scenarios for future study. This document considers additional multihoming scenarios, especially focussing on the provision of fault tolerance capabilities in multihomed HIP nodes. In order to support such fault tolerant configurations, this document updates the behaviour for HIP multihoming nodes defined in [2] and defines the integration of the REAP protocol as defined in draft-ietf-shim6-failure-detection [4] in HIP. 2. Locator management A multihomed HIP node has multiple locators that can have different reachability status. Some of them can be operational/reachable while other may be not. Fault tolerance is a preferred capability of such configuration. In order to provide basic fault tolerance support, a HIP node should be able to perform the following functions: First, the multihomed HIP nodes must be able to convey the locally available locator set to the peer. Second, the nodes should be able to monitor the communication and detect failures. In case that a failure is detected, they must be able to discover alternative working locator pairs and divert the communication through the alternative locator pair. In this section, we focus in the locator management part, and in the next section we will focus on the failure detection and alternative path exploration part. It should be noted that for the provision of basic fault tolerance capabilities, the locators are managed following the following guidelines: o All the locators available for each peers that are to be used to provide fault tolerance must be exchanged early in the communication, so they can be used as alternative locators in case of a failure. This is different from the mobility case described in [2] since the peers only know a single locator of the peer at the time. o However, the locators are only used sequentially and not in parallel. This is so, because as long a locator pair is working, the peers stick to that pair for exchanging data packets and they only change the locator pair used when there is a failure. This is different from the general multihoming scenario considered in [2] since locator pairs are not used in parallel. This particular constraint reduces considerably the possibility of packet reordering and hence the possibility of having problems with the de la Oliva & Bagnulo Expires January 3, 2008 [Page 3] Internet-Draft Fault Tolerant HIP Multihoming July 2007 reply protection window due to reordering of packets that travel through different paths. In the general multihoming scenario defined in [2], a multihomed node is recommended to create different SAs and use different SPIs for each locator pair available for the communication between two multihomed nodes to avoid problems with the anti-replay protection window resulting from reordering packets when using multiple paths simultaneously. While this is required for the general multihoming scenario, this is an expensive approach, because it requires a high number of SAs to be created and it also requires a significant signaling overhead. Basically in a multihoming scenario where a multihomed node A that has m locators is communicating with another multihomed node B that has n locators, they need to exchange m+n UPDATE messages to convey all the locator information. This is so, because they need to convey SPI information for each of the locator pairs. Node A does so by sending an n UPDATE messages. Each one of these n UPDATE messages contains the m locally available locators with an SPI value for each locator. Each of the n UPDATE messages is addressed to a different locator of the n available at node B. In this way, the information of the m*n SPIs values for the different locator pairs is exchanged between the peers. While all the overhead and complexity is required when using multiple locator pairs in parallel, this is not the case for a fault tolerant configuration, where the locator pairs will be used sequentially. Hence, in the document we define a modified behaviour for HIP multihomed nodes for fault tolerance support. For fault tolerance, only sequential use of locator pairs is required. This is similar to the mobility case, the difference being that the locator set for each peer is known beforehand. In order to support this configuration, the following behaviour is defined for HIP nodes. Each node will convey the available locator set information to the peer in a single UPDATE message. The Old SPI and the New SPI values of the LOCATOR parameter will be equal and set to the current SPI value for every locator in the message. Each node will use a single SA and a single SPI value for all the locator pairs available for the configuration. Only a single locator pair will be active, and all the traffic will be sent using the preferred (active) locator pair. Upon the reception of one UPDATE message containing multiple locators with a single SPI value for both the OlD SPI and the New SPI for all the locators, the receiver will verify the locators contained in the UPDATE message as defined in [2]. After that, the receiver will identify that it is in the fault tolerance scenario and will create locator pairs using all the received locators and all the locally available locators, irrespectively of the locator to which the UPDATE message was sent. The result is that each of the peers will have all the locator pairs available for use de la Oliva & Bagnulo Expires January 3, 2008 [Page 4] Internet-Draft Fault Tolerant HIP Multihoming July 2007 in case that a failure occurs. After the locator sets have been exchanged, the peers use the REAP protocol as defined in the next section to detect failure, explore alternative locator pairs and divert the communication through alternative working locators. 3. Failure detection and alternative path exploration for HIP Multihoming support for the HIP protocol as defined in [2] relies in the usage of the UPDATE message to convey multiple alternative locators for a given HI/HIT that is being used as identifier for ongoing communications between two nodes. By including alternative locators associated to the multihoming configuration, the communication between the two nodes is more reliable, since it is possible to use alternative locator pairs in case the original one should fail. As currently defined, the HIP protocol is capable of exchanging the alternative locators, validate them and use them to exchange packets. However, the capabilities required for detecting failures and exploring alternative working locators are still lacking. The REAP protocol [4] provides such capabilities for the Shim6 protocol [3] and can be used to provide the lacking failure detection and path exploration capabilities in HIP. This section defines how the REAP protocol [4] can be used to detect failures and explore alternative paths between two hosts using HIP multihoming. 3.1. Multihoming scenario The considered scenario consists of two HIP hosts that are communicating. At least one of them has multiple locators which may have different reachability status. In order to benefit from the enhanced fault tolerance capabilities resulting from multihoming, the decide to exchange the alternative locators available at each end. The exchange of the locator set of each end host can be performed in two ways: o Each end point of the communication may send a LOCATOR parameter on R1 and I2 messages of the HIP connection establishment as defined on [2]. o The HIP protocol specified on [1] supports the modification of the locator set currently being used by the exchange of the UPDATE message. Herein we describe the use of the UPDATE packet to exchange the locator set but a similar scenario would result if the locator sets were exchanged using the R2 and I2 messages. de la Oliva & Bagnulo Expires January 3, 2008 [Page 5] Internet-Draft Fault Tolerant HIP Multihoming July 2007 The exchange of locators in the UPDATE packet is secured by the use of HMAC and HIP_SIGNATURE on the message. A number of combinations of parameters in an UPDATE packet are possible (see [2]). In this scenario we consider the case where one LOCATOR and one ESP_INFO parameter is used in any HIP packet. Other configurations may be possible although are out of the scope of this document. As specified on [2] the LOCATOR parameter should list all the locators that are active on the HIP association, so the UPDATE packet sent to the peer will inform of all the locators which can be used to reach the host on this HIP association. The locators stored on the LOCATOR parameter may be: o IPv6 or an IPv4-in-IPv6 format IPv4 adress (for non ESP based usage). o The concatenation of an ESP SPI (first 32 bits) followed by an IPv6 address or IPv4-in-IPv6 format IPv4 address (128 bits) for ESP use. On the LOCATOR parameter, there is a bit (P) which express the preferred locator. This bit must be set to one on the active locator for this communication and 0 in all the others to prevent a change of the active locators. The UPDATE packet may contain a ESP_INFO parameter, rules for processing this parameter are given on [2] and are assumed to be valid on this document. Once an UPDATE message is received, the locators listed on the LOCATOR parameter are processed following the guidelines of [2]. After the processing, the SA will have a list with all the available addresses of the peer. The address in use will be on ACTIVE state and the rest will be on UNVERIFIED state. Note that in [2] is stated that after receiving an UPDATE message with a LOCATOR parameter included, the only valid locator pairs created are between the new locators added and the source address of the UPDATE message. We extend this behaviour on Section 2 to allow the creation of pairs between all the locators of both endpoints. Note that with this approach a communication between two endhosts (A,B), having A n possible locators and B m, leads to an SA with n*m valid locator pairs. Once finished the locator exchange, we assume each endhost SA will have n*m valid locator pairs. At this stage, the hosts are ready to benefit from the enhanced fault tolerance capabilities resulting from multihoming, and use the REAP protocol to detect failures in the current locator pair and to explore alternative working locators pairs in case the current one should fail. We describe how this is done in the following section. de la Oliva & Bagnulo Expires January 3, 2008 [Page 6] Internet-Draft Fault Tolerant HIP Multihoming July 2007 3.2. Failure detection and recovery The REAP protocol [4] defined in the Shim6 architecture [3] provides path failure detection and alternative path exploration capabilities between two multihomed hosts. It relies in two mechanisms, namely, the failure detection mechanism and the path exploration mechanism. The failure detection mechanism is based on the Forced Bidirectional Detection (FBD) technique, which consists on making sure that whenever there is data traffic in one direction, there is also traffic in the other direction. This is accomplished by injecting additional control messages (called KeepAlives messages) when needed, which guarantee that the frequency of traffic in the reverse direction is above a predetermined threshold. The result is that when there is a ongoing data communication between two REAP peers, both peers can expect an incoming traffic frequency that is above the predetermined threshold defined by REAP. If the incoming traffic frequency is below this threshold, then this implies that a failure has occurred. In other words, after a given period of time no traffic has been received a failure on the path is assumed and the alternative path exploration mechanism is triggered. The current implementation the REAP protocol relies on two timers, the Keep Alive Timer and the Send Timer, and a control message, namely the Keepalive message. The Keep Alive Timer TKA is started each time a node receives a data packet from its peer, and stopped and reset, each time the node sends a packet to the peer. When the Keep Alive Timer expires, a Keep Alive message is sent to the peer. The Send Timer TSend, defined roughly as three times the Keep Alive Timer plus a deviation to accommodate the Round Trip Time, is started each time the node sends a packet and stopped each time the node receives a packet from the peer. If no answer (either a Keep Alive or data packet) is received in the Send Timer period a failure is assumed and a locator path exploration is started. Consequently, the Send Timer reflects the requirement that when a node sends a payload packet there should be some return traffic within Send Timeout seconds. On the other hand, the Keepalive timer reflects the requirement that when a node receives a payload packet there should a similar response towards the peer within Keepalive seconds (if no traffic is interchanged, there is no Keep Alive signaling). The path exploration mechanism starts whenever the node has not received any packet during a fixed period of time (Send Timer). A path may become invalid either bacause one of the locators used may became invalid or inoperational, or the pair itself has been declared as inoperational. A full exploration mechanism should check all possible pairs of source/destination locators until at least one working locator pair is found. Instead of using a request/response de la Oliva & Bagnulo Expires January 3, 2008 [Page 7] Internet-Draft Fault Tolerant HIP Multihoming July 2007 approach the first of both sides which detects the failure tries each of the peer's locators sending probes through each of its interfaces. Each probe carries information about the current state of the communication and the probes which have been received so far through the rest of the interfaces. The state of the connection can be one of three possible states: i) Operational, when both peers can see each other, b)Exploring, when one of the peers have detected a problem and has currently not seen any traffic from the peer or c) Inbound_OK, when the node sees traffic from the peer but the peer does not see any traffic from the node. The information related with the rest of the probes received, which is carried on every probe allows the end hosts to be able to know which are the locator pairs working in the outgoing direction, on the case there are multiple probes. The path exploration mechanism ends when both peers have received a probe confirming that the peer can see them. It should be noted that the defined exploration mechanism is capable of discovering locators pairs that are working in only one direction (i.e. unidirectional reachability) thanks to the information about all received probes contained in all the reply probes. In the current implementation once a node detects a failure, it starts the path exploration mechanism. A Probe message is sent to test the current locator pair, and if no responses are obtained during a period of time called Retransmission Timer (TRTx), the nodes start sending Probes testing the rest of the available address pairs, using all possible source/destination address pairs. Once a probe is received by the node, it sends another probe to the peer indicating that it is seeing traffic from it (Inbound_OK). After receiving this last probe the peer will answer confirming the reception of this last probe and indicating that the new locator pair is in the Operational state. These Probe messages are used to confirm reachability and can be used as an address verification mechanism to modify the state of the locator being probe to ACTIVE. Note that each end point of the communication explores unidirectional reachability and based on its observations decides the pair of locators to use in a not coordinated way. Therefore the pair of locators selected by each end host may be different. At the end of the path exploration mechanism, each host will have a pair of ACTIVE locators which can be used to continue the communication. 3.3. Processing of the REAP messages Figure 1 shows the placement of the REAP module within the HIP Multihoming stack. Once some heuristic has decided that a de la Oliva & Bagnulo Expires January 3, 2008 [Page 8] Internet-Draft Fault Tolerant HIP Multihoming July 2007 communication should be protected by the REAP protocol, an instance of it is created and associated with the SA to protect. The REAP instance is able to communicate with the ESP and HIP layers. The ESP layer should inform of every packet received or sent associated with the SPI used on the protected HIP association. By this way if rekeying is needed due to a change of locator or any other cause, the ESP layer will still be able to inform REAP of the messages received or sent associated to the protected SA. --------- | TCP | (sockets bound to HITs) --------- | --------- ----> | ESP | {HIT_s, HIT_d} <-> SPI | --------- ---- | | MH | --------- ---- ->| HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI} |REAP| --------- ---- | --------- | IP | --------- Figure 1: Architecture for HIP mobility and multihoming (MH) The REAP control messages (Probe, KeepAlive) are not protected by ESP and will be indexed by the Sender's and Receiver's HIT pair. Upon reception of a REAP control message, the HIP layer will demultiplex the control packet and forward it to the corresponding REAP instance. It must be taken into account that if several SAs are used to communicate the same HIT pairs only one instanciation of the REAP protocol is needed. On this case all data packets corresponding with the SAs between the HIT pair will be notified to the same instance of REAP. 4. HIP comformant REAP messages 4.1. KeepAlive Message The format of the keepalive message is as follows: de la Oliva & Bagnulo Expires January 3, 2008 [Page 9] Internet-Draft Fault Tolerant HIP Multihoming July 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Length |0| Packet Type | VER. | RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Controls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: KeepAlive Message Fields: Next Header, Header Length, 0, Version, Reserved, 1, Checksum and HIP Controls: These are as specified in Section 5.1 of the HIP protocol description [1]. Packet Type (as specified in [4]): This field identifies the KeepAlive message and MUST be set to 66 (KeepAlive) Sender's Host Identity Tag (HIT): As defined in [1] Receiver's Host Identity Tag (HIT): As defined in [1] HIP parameters: This space is reserved for adding HIP parameters. At least the KeepAlive Timeout Option may be added here. de la Oliva & Bagnulo Expires January 3, 2008 [Page 10] Internet-Draft Fault Tolerant HIP Multihoming July 2007 4.2. Probe Message This message performs REAP exploration. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Length |0| Packet Type | VER. | RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Controls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Precvd| Psent |Sta| Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + First probe sent + | | + Source address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + First probe sent + | | + Destination address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First probe nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First probe data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ de la Oliva & Bagnulo Expires January 3, 2008 [Page 11] Internet-Draft Fault Tolerant HIP Multihoming July 2007 / / / Nth probe sent / | | + Source address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nth probe sent + | | + Destination address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nth probe nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nth probe data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + First probe received + | | + Source address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + First probe received + | | + Destination address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First probe nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First probe data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Nth probe received + | | + Source address + de la Oliva & Bagnulo Expires January 3, 2008 [Page 12] Internet-Draft Fault Tolerant HIP Multihoming July 2007 | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nth probe received + | | + Destination address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nth probe nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nth probe data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Options + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Probe Message Fields: Next Header, Header Length, 0, Version, Reserved, 1, Checksum and HIP Controls: These are as specified in Section 5.1 of the HIP protocol description [1]. Packet Type (as specified in [4]): This field identifies the Probe message and MUST be set to 67 (Probe) Sender's Host Identity Tag (HIT): As defined in [1]. Receiver's Host Identity Tag (HIT): As defined in [1]. HIP parameters: This space is reserved for adding HIP parameters. At least the KeepAlive Timeout Option may be added here. de la Oliva & Bagnulo Expires January 3, 2008 [Page 13] Internet-Draft Fault Tolerant HIP Multihoming July 2007 The rest of the parameters on the packet are exactly the same as specified on [4]. Psent This is a 4-bit field that indicates the number of sent probes included in this probe message. The first set of probe fields pertains to the current message and MUST be present, so the minimum value for this field is 1. Additional sent probe fields are copies of the same fields sent in (recent) earlier probes and may be included or omitted as per any logic employed by the implementation. Precvd This is a 4-bit field that indicates the number of received probes included in this probe messsage. Received probe fields are copies of the same fields received in (recent) earlier probes and may be included or omitted as per any logic employed by the implementation. The fields probe source, probe destination, probe nonce and probe data may be repeated, depending on the value of Psent and Preceived. Sta (State) This 2-bit State field is used to inform the peer about the state of the sender. It has three legal values: 0 (Operational) implies that the sender both (a) believes it has no problem communicating and (b) believes that the recipient also has no problem communicating. 1 (Exploring) implies that the sender has a problem communicating with the recipient, e.g., it has not seen any traffic from the recipient even when it expected some. 2 (InboundOk) implies that the sender believes it has no problem communicating, i.e., it at least sees packets from the recipient, but that the recipient either has a problem or has not yet confirmed to the sender that the problem has been solved. Reserved2 MUST be set to 0 upon transmission and MUST be ignored upon reception. Probe source This 128-bit field contains the source IPv6 address used to send the probe. Probe destination de la Oliva & Bagnulo Expires January 3, 2008 [Page 14] Internet-Draft Fault Tolerant HIP Multihoming July 2007 This 128-bit field contains the destination IPv6 address used to send the probe. Probe nonce This is a 32-bit field that is initialized by the sender with a value that allows it to determine which sent probes a received probe correlates with. It is highly recommeded that the nonce field is at least moderately hard to guess so that even on-path attackers can't deduce the next nonce value that will be used. This value SHOULD be generated using a random number generator that is known to have good randomness properties as outlined in RFC 1750 [RFC1750]. Probe data This is a 32-bit field with no fixed meaning. The probe data field is copied back with no changes. Future flags may define a use for this field. 4.3. Keepalive Timeout Option Format Either side of a HIP association can notify the peer of the value that it would prefer the peer to use as its Keepalive Timeout value. If the host is using a non-default Send Timeout value, it SHOULD communicate this value as a Keepalive Timeout value to the peer in the below option. This option MAY be sent in the I2, R2, or UPDATE messages. The option SHOULD only need to be sent once in a given HIP association. If a host receives this option it SHOULD update its Keepalive Timeout value for the correspondent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Reserved | Keepalive Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: KeepAlive Timeout Option Format Fields: Type This field identifies the option and MUST be set to 10 (Keepalive Timeout). The rest of the fiels on this packet are exactly the same as defined on [4]. de la Oliva & Bagnulo Expires January 3, 2008 [Page 15] Internet-Draft Fault Tolerant HIP Multihoming July 2007 Length This field MUST be set as specified in Section 5.1 of the HIP protocol description [1]. Reserved 16-bit field reserved for future use. Set to zero upon transmit and MUST be ignored upon receipt. Keepalive Timeout Value in seconds corresponding to suggested Keepalive Timeout value for the peer. 5. Security Considerations TBD 6. Acknoledgements Tom Henderson provided comments and feedback on the contents of this draft. Antonio de la Oliva is partly funded by OneLab, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the OneLab project or the European Commission. 7. References [1] Moskowitz, R., Nikander, P., and T. Henderson, "Host Identity Protocol", June 2007. [2] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", March 2007. [3] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", May 2007. [4] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", June 2007. de la Oliva & Bagnulo Expires January 3, 2008 [Page 16] Internet-Draft Fault Tolerant HIP Multihoming July 2007 Authors' Addresses Antonio de la Oliva UC3M Email: aoliva@it.uc3m.es Marcelo Bagnulo Huawei Labs at UC3M Email: marcelo@it.uc3m.es de la Oliva & Bagnulo Expires January 3, 2008 [Page 17] Internet-Draft Fault Tolerant HIP Multihoming July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). de la Oliva & Bagnulo Expires January 3, 2008 [Page 18]