MIP6 Working Group R. Wakikawa (Editor) Internet-Draft Keio University Expires: December 21, 2006 June 19, 2006 Home Agent Reliability Protocol draft-ietf-mip6-hareliability-00.txt 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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The home agent can be a single point of failure when Mobile IPv6 is used in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism for achieving home agent reliability. Note that this document is not completed yet. DT is still discussing some items. Wakikawa (Editor) Expires December 21, 2006 [Page 1] Internet-Draft Home Agent Reliability June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4. Goals for the Solution . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 10 5.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 11 5.3. Failure Detection and Home Agent Management . . . . . . . 13 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 16 6.1.1. Home Agent Hello Request Message . . . . . . . . . . . 16 6.1.2. Home Agent Hello Message . . . . . . . . . . . . . . . 17 6.1.3. State Synchronization Request Message . . . . . . . . 20 6.1.4. State Synchronization Message . . . . . . . . . . . . 21 6.1.5. Home Agent SwitchOver Request Message . . . . . . . . 22 6.1.6. Home Agent SwitchOver Reply Message . . . . . . . . . 23 6.1.7. Home Agent SwitchBack Request Message . . . . . . . . 23 6.1.8. Home Agent SwitchBack Reply Message . . . . . . . . . 24 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 25 6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 25 6.2.2. Binding Cache Information Option . . . . . . . . . . . 25 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 27 6.2.4. Vendor Specific Information Option . . . . . . . . . . 27 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 29 7.1. Home Agent Configuration . . . . . . . . . . . . . . . . . 29 7.2. Hello messages Manipulation . . . . . . . . . . . . . . . 30 7.2.1. Sending Hello Request . . . . . . . . . . . . . . . . 31 7.2.2. Receiving Hello Request . . . . . . . . . . . . . . . 31 7.2.3. Sending Hello . . . . . . . . . . . . . . . . . . . . 31 7.2.4. Receiving Hello . . . . . . . . . . . . . . . . . . . 32 7.3. Failure Detection . . . . . . . . . . . . . . . . . . . . 32 7.4. Active Home Agent Change . . . . . . . . . . . . . . . . . 33 7.5. Processing State Synchronization Messages . . . . . . . . 34 7.5.1. Sending State Synchronization Request . . . . . . . . 34 7.5.2. Receiving State Synchronization Request . . . . . . . 34 7.5.3. Sending State Synchronization . . . . . . . . . . . . 34 7.5.4. Receiving State Synchronization . . . . . . . . . . . 35 7.6. Processing Home Agent SwitchOver Messages . . . . . . . . 35 7.6.1. Sending Home Agent SwitchOver Request . . . . . . . . 35 7.6.2. Sending Home Agent SwitchOver Reply . . . . . . . . . 36 Wakikawa (Editor) Expires December 21, 2006 [Page 2] Internet-Draft Home Agent Reliability June 2006 7.6.3. Receiving Home Agent SwitchOver Reply . . . . . . . . 36 7.7. Processing Home Agent SwitchBack Messages . . . . . . . . 36 7.7.1. Sending Home Agent SwitchBack Request . . . . . . . . 36 7.7.2. Sending Home Agent SwitchBack Reply . . . . . . . . . 37 7.7.3. Receiving Home Agent SwitchBack Reply . . . . . . . . 37 7.8. Sending Home Agent Switch Message . . . . . . . . . . . . 37 8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 38 8.1. Standby Home Agent Addresses Discovery . . . . . . . . . . 38 8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 38 8.3. Receiving Home Agent Switch message . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 47 Wakikawa (Editor) Expires December 21, 2006 [Page 3] Internet-Draft Home Agent Reliability June 2006 1. Introduction In Mobile IPv6 [1] and NEMO Basic Support[2], mobile nodes may use a bi-directional tunnel with their Home Agents for all traffic with the correspondent nodes. A home agent on the home link maintains a binding cache entry for each mobile node and uses the binding cache entry to route any traffic meant for the mobile node or the mobile network. If the mobile node is not on the home link and does not have a binding cache entry at the home agent, it is neither reachable at its home address nor able to setup new sessions with its home address. If a home agent loses the binding cache state, due to failure or some other reason, it results in loss of service for the mobile nodes. It would be very beneficial to provide high availability and redundancy for a home agent so that the mobile nodes can avail of uninterrupted service even when one home agent crashes or loses state. Wakikawa (Editor) Expires December 21, 2006 [Page 4] Internet-Draft Home Agent Reliability June 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. In this document, the term mobile node refers to both a mobile node [1] and a mobile router [2]. Some of the mobility related terms used in this document are defined in [1] and [7]. In addition or in replacement of these, the following terms are defined or redefined: Active Home Agent A home agent that is currently serving the mobile nodes Standby Home Agent A home agent which will serve the mobile nodes when the active home agent fails. Failed Home Agent A home agent that is not available due to hardware or software failure, system maintenance, etc. Redundant Home Agent Set A pair of an Active Home Agent and Standby Home Agent(s). The Group Identifier is introduced to identify a Redundant Home Agent set. The Group ID is exchanged by Hello messages. Binding Synchronization Synchronization of binding cache entries within the redundant home agent set Home Agent Preference This preference value is defined for DHAAD in RFC3775. This protocol uses this preference value for home agent selection when an active home agent is failed. However, an operator can also define an independent value only for home agent reliability protocol if the operator wants to have different preference value for DHAAD and home agent reliability protocol. A Home Agent SHOULD NOT use the same preference value of other Home Agents for this protocol. Wakikawa (Editor) Expires December 21, 2006 [Page 5] Internet-Draft Home Agent Reliability June 2006 Home Agent Hard Switch The Home Agent Hard Switch is used when IPsec states cannot be synchronized between an active and a Standby Home Agent. In this case each home agent negotiates independent IPsec SAs with a mobile node. The mobile node will be notified to change its home agent to one of Standby Home Agent. Home Agent Virtual Switch In this case IPsec states are synchronized within the redundant home agent set. A given mobile node has only one IPsec SA and one mobility binding. Upon failure of the Active Home Agent, the Standby Home Agent begins to serve the mobile nodes without having to notify the mobile nodes about the failure event in the network. Wakikawa (Editor) Expires December 21, 2006 [Page 6] Internet-Draft Home Agent Reliability June 2006 3. Problem Statement In Mobile IPv6 base specification, a mobile node registers and establishes a connection with only one Home Agent. Thus the Home Agent represents the possibility of a single point of failure for Mobile IPv6. A Home Agent may be responsible for multiple mobile nodes on the home link. The failure of the Home Agent may then result in the loss of connectivity for numerous mobile nodes located throughout the Internet. To overcome this problem, Mobile IPv6 allows deployment of multiple Home Agents on the home link so that upon the failure of serving Home Agent, mobile node can re-establish its connection through the new Home Agent. However, base Mobile IPv6 specification does not address the Home Agent failover and dynamic transfer of service from one Home agent to another. This transfer of service from the Failed Home Agent to a new working Home Agent requires co-ordination or pre-configuration among the Home agents regarding security association, transfer of mobile-node related binding and other service information for the reliable Mobile IPv6 service in a deployment scenario. Wakikawa (Editor) Expires December 21, 2006 [Page 7] Internet-Draft Home Agent Reliability June 2006 4. Goals for the Solution For the home agent reliability solution, we define the following requirements. Reliable Home agent service Multiple home agents are available for a home prefix and one of them is actively serves the mobile nodes. A standby home agent takes over when the Active Home Agent becomes unavailable. The transfer of the MN-HA association should be transparent to the application and should not take longer than care-of-addresses update procedure described in the Mobile IPv6 [1]. Availability of a redundant home agent set Availability of an Active Home Agent address and a standby Home Agent address at the bootstrapping period to Mobile Node is assumed. State Synchronization The information for mobile nodes must be synchronized between an Active Home Agent and Standby Home Agents. The information is Binding Cache, IPsec/IKE states, AAA information, vendor specific information. Consideration of IPsec/IKE transfer An Active Home Agent maintains several IPsec and IKE states for mobile nodes. These states are synchronized within the redundant Home Agent set. The details are described in Section 9. Secured Message Exchanges The messages used between the home agents to transfer binding cache information MAY be authenticated and encrypted. Failure Detection Redundant home agents must actively check for possible failure of an Active Home Agent. Periodic hello messages should be used to detect Active Home Agent's service availability Failure Notification Wakikawa (Editor) Expires December 21, 2006 [Page 8] Internet-Draft Home Agent Reliability June 2006 If necessary a mobile node is notified about the active home agent failure by the Standby Home Agent in Home Agent Hard Switch mode of operation Wakikawa (Editor) Expires December 21, 2006 [Page 9] Internet-Draft Home Agent Reliability June 2006 5. Protocol Overview This specification provides two modes for home agent local reliability. o Home Agent Virtual Switch: In this mode the active and the redundant home agents are all accessible through the same IP address. IPsec/IKE states must be synchronized between the active and a redundant home agent(s). The mechanism used to synchronize IPsec state is currently considered out of scope for this document and not described here. In this mode, a mobile node always establishes IPsec SAs only with the Active Home Agent. The IPsec state will be shared within the redundant home agent set in background. In case there is a failure the Standby Home Agent takes over without the mobile node being aware of the change in the home agent. o Home Agent Hard Switch: In this mode the home agents are addressed by different IP addresses and the mobile node is aware of the change in the home agent. This mode is also useful when the IPsec state cannot be synchronized. In this mode, a standby home agent must solicit mobile nodes to re-establish IPsec/IKE for Mobile IPv6 signaling. This IPsec re-establishment is triggered when a mobile node changes its home agent after receiving a home agent switch message from a standby home agent. In order to exchange this message securely between a Standby Home Agent and a mobile node, a mobile node need to establish IPsec SA with both an Active Home Agent and redundant home agents beforehand. With this multiple IPsec SAs, a mobile node will receive a notification from the Standby Home Agent and start to use the Standby Home Agent when the Active Home Agent failed. All new messages defined in this document are defined as Mobility Header messages so that the HA reliability protocol can be extended later, if needed, to provide home link redundancy. (i.e. Protocol is not tight with the link boundary) 5.1. Home Agent Virtual Switch In the case of the virtual home agent switch, a mobile node remains agnostic about the change in the serving home agent. The home agents have replicated all session state including the IPsec/IKE/ESP sates. The ESP sequence numbers, which is used to prevent replay attack, may not be synchronized momentarily. However, this should not pose any problem as both ends of the IPsec ESP tunnel should use sequence numbers that are greater than the last known sequence numbers to either ends. The Standby Home Agent should add a random number (+n) over and above the anti-replay window to ensure that the packet Wakikawa (Editor) Expires December 21, 2006 [Page 10] Internet-Draft Home Agent Reliability June 2006 received by the mobile node passes ESP replay check. The operations of the Home Agent Virtual Switch are shown in Figure 1. After binding registration is done (2, 3), the Active Home Agent pushes all the states of mobile nodes by a state synchronization message in a periodic interval (4). The Active Home Agent synchronizes the IPsec state information with the Standby Home Agent(s), too. This state synchronization should be done periodically in order to match the ESP sequence number and anti- replay window among home agents. The Standby Home Agent(s) is not active unless it takes over from a Failed Home Agent. When the Active Home Agent's failure is detected (5), the Standby Home Agent activates the IP address of the failed home agent on it and takes over from the Failed Home Agent. All the home agents in the redundant home agent set share a virtual address and the routing will ensure only the Active Home Agent will be reachable using that virtual address. The Standby Home Agent can serve all the mobile nodes for which the states are synchronized, without any further message exchange because it has all the necessary information which it obtained from the failed home agent. MN HA1(active) HA2(Standby) | | . |<--------->| . 1. IPsec/IKE | | . |---------->| . 2. Binding Update |<----------| . 3. Binding Acknowledgement | | . | |<--------->. 4. State exchanges (Binding cache/IPsec) | | . | X . HA1 FAILURE | X . | X<----------. 5. Failure Detection | X | | X | 6. HA2 takes over the HA1 | X | | X | RECOVERY COMPLETE Figure 1: Overview of Home Agent Virtual Switch 5.2. Home Agent Hard Switch The Home Agent Hard Switch is shown in Figure 2. This mode is not transparent to mobile node when there is a home agent failure and another home agent takes over. Wakikawa (Editor) Expires December 21, 2006 [Page 11] Internet-Draft Home Agent Reliability June 2006 MN HA1(active) HA2(Standby) | | | |<--------->| | 1. IKE exchange (w/HoA assignment) | | | |---------->| | 2. Binding Update |<----------| | 3. Binding Acknowledgement | | | |<--------------------->| 4. IKE exchange (wo/HoA assignment) | | | | |<--------->| 5. State Exchanges | | | | X | HA1 FAILURE | X | | X<----------| 6. Failure Detection | X | |<----------------------| 7. Sending home agent | X | Switch message | X | |<--------------------->| 8. Binding Registration (optional) | X | | X | RECOVERY COMPLETE Figure 2: Overview of Home Agent Hard Switch In this mode, a mobile node establish IPsec SA with multiple home agents beforehand. When an Active Home Agent fails, the other Standby Home Agent could use pre-existing IPsec SA to notify the Mobile Node about the failure. After the notification, the mobile node will use the Standby Home Agent as its home agent. In order to discover the home agent address, two different mechanisms are defined in the bootstrapping solution in split scenario. One is DNS lookup by home agent Name, the other is DNS lookup by Service Name. The mobile node sends a DNS SRV request and acquires IP addresses and preferences of a redundant home agent set. In integrated scenario, DHCPv6 is used to provide home agent provision to Mobile Node. The mobile node establishes IPsec/IKE state with the other acquired home agents beforehand (1 and 4), however it registers only with the Active Home Agent (2 and 3). The Active Home Agent synchronizes required states of mobile nodes such as Binding Cache information and AAA information, etc. with other standby home agents periodically (5). When the Standby Home Agent detects the failure of the active home agent (6), it sends a home agent switch message to all the mobile Wakikawa (Editor) Expires December 21, 2006 [Page 12] Internet-Draft Home Agent Reliability June 2006 nodes that were registered to the Failed Home Agent (7). The home agent switch message must be encrypted by pre-established IPsec SA. After the switch message, the mobile node MAY send a binding update and registers it with the new Active Home Agent in order to update MIP6 tunnel's end points (8). However, this binding registration can be skipped since the Standby Home Agent synchronizes the binding cache information with the Active Home Agent periodically. The mobile node only changes its home agent address to the new Active Home Agent. 5.3. Failure Detection and Home Agent Management HA1(active) HA2 HA3 .. HAn | | | | |<------>| | | 1. Hello exchange |<------------->| | |<-------------------->| | | | | (Failed) | | | A FAILURE OCCURS X | | | X | | | 3. Standby HAs detects X | | | failure. X | | | X (active) | | 4. HA2 becomes Active HA X | | | | | | | HA1 RECOVER NOW (standby) | | | |------->| | | 5. HA1 sends SwitchOver Request |<-------| | | 6. HA2 sends SwitchOver Reply | | | | (active) (standby) | | 7. HA1 returns to active HA | | | | | | | | HA1 BECOMES ACTIVE AGAIN Figure 3: Home Agent Management Figure 3 illustrates the mechanism by which a Standby Home Agent takes over from a failed home agent. This operation is common for both the hard and the virtual switch modes. The home agent whose preference is the highest among the Standby Home Agents takes over immediately after it detects failure of the Active Home Agent. The preference value can be same as the home agent preference value of RFC3775, while the operator can define an independent value only for home agent reliability protocol. The Home Agents in the redundant Home Agent set exchange periodic Wakikawa (Editor) Expires December 21, 2006 [Page 13] Internet-Draft Home Agent Reliability June 2006 Hello messages to convey their information to the peers (1). The Hello messages can either be unicast or multicast. In order to explicitly query the state information of its peer(s), any Home Agent can send a Hello request to its peer(s) in the redundant Home Agent set. The Hello message exchange is the basis of failure detection and automatic switchover in this scheme (3 and 4). When HA1 recovers in Figure 3, it needs to remain in the standby state. This prevents it to automatically take over from the currently active Home Agent. HA1 sends a SwitchOver Request to the currently active Home Agent (i.e. HA2) only if the system administrator issues a manual command, if the monitored server fails, if the routing peer/link fails. The currently Active Home Agent can be known through the exchange of Hello messages. HA1 may need to send Hello Request message to all the Standby Home Agents, when it recovered from the failure. When HA2 receives the Home Agent SwitchOver Request from HA1 it changes its state to standby and sends back the SwitchOver Reply message to HA1. HA1 returns to active home agent status immediately after receiving the SwitchOver reply. HA1(active) HA2 HA3 .. HAn | | | | |------->| | | 1. HA1 sends SwitchBack Request |<-------| | | 2. HA2 sends SwitchBack Reply | | | | (standby) (active) | | HA2 BECOMES ACTIVE HA | | | | SYSTEM MAINTENANCE, ETC. | | | | |------->| | | 3. HA1 sends SwitchOver Request |<-------| | | 4. HA2 sends SwitchOver Reply | | | | (active) (standby) | | 5. HA1 returns to active HA | | | | HA1 BECOMES ACTIVE AGAIN Figure 4: Manual Home Agent Change In some scenarios the Active Home Agent may need to stop serving the mobile nodes for system maintenance. This specification provides manual home agent change by using Home Agent SwitchBack Request and Reply messages. As shown in Figure 4, the Active Home Agent (HA1) sends Home Agent SwitchBack Request to an Standby Home Agent. As soon as HA2 receives the message, it becomes the Active Home Agent. HA2 also acknowledges with the Home Agent SwitchBack reply to HA1. HA1 becomes standby when it receives the SwitchBack reply. After the downtime, HA1 sends a Home Agent SwitchOver Request to HA2 in order Wakikawa (Editor) Expires December 21, 2006 [Page 14] Internet-Draft Home Agent Reliability June 2006 to return to become an Active Home Agent again. This operation is same as Figure 3 Wakikawa (Editor) Expires December 21, 2006 [Page 15] Internet-Draft Home Agent Reliability June 2006 6. Messages This document defines following new messages: o New Mobility Header Messages * Home Agent Hello Request Message * Home Agent Hello Message * State Synchronization Request Message * State Synchronization Message * Home Agent SwitchOver Request Message * Home Agent SwitchOver Reply Message * Home Agent SwitchBack Request Message * Home Agent SwitchBack Reply Message o New Mobility Options * Binding Cache Information Option * AAA Information Option * Vendor Specific Information Option We may add more mobility options in the future document. The DT is currently discussing the needs and the formats of IPsec/IKE state information Option and BGP/OSPF modifier option for state synchronization message. Home Agent Switch message is defined in [8]. This message is also used in operation of Home Agent Hard Switch. 6.1. New Mobility Header Messages 6.1.1. Home Agent Hello Request Message The message is unicasted to a home agent to solicit a Hello message from a home agent. The receiver of this Hello Request message MUST return a Hello message to the originator of this request message. A Home Agent Hello message SHOULD be authenticated and encrypted by IPsec ESP. Wakikawa (Editor) Expires December 21, 2006 [Page 16] Internet-Draft Home Agent Reliability June 2006 The Hello Request message has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Home Agent Hello Request Message Sequence # 16-bit unsigned integer. The Sequence number of the Hello message can be used to verify whether this Hello message is the latest one or not. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [1]. The receiver MUST ignore and skip any options which it does not understand. There MAY be additional information, associated with this HELLO Request message that need not be present in all HELLO Request messages sent. Mobility options allow future extensions to the format of the HELLO Request message to be defined. If no options are present in this message, no padding is necessary and the Header Len field will be set to 1. 6.1.2. Home Agent Hello Message The message is either unicasted or multicasted to carry Home Agent information among the Redundant home agent set. This Hello message is used by any home agents to detect the failure of a redundant peer in the redundant Home Agent set. This message can be sent either periodically or in reply to Hello Request message. A home agent Wakikawa (Editor) Expires December 21, 2006 [Page 17] Internet-Draft Home Agent Reliability June 2006 Hello message SHOULD be authenticated and encrypted by IPsec ESP when it is unicasted. If a Hello message is multicasted, IPsec ESP cannot be applied. Hence if multicast is used, the redundant Home Agent set should be in a secure network. The Standby Home Agents and the Active Home Agent must exchange the home agent information. Although Mobile IPv6 uses a router advertisement to exchange home agent information periodically, the Hello message can be replaced with the router advertisement. If the Standby Home Agent misses this Hello message from it's peer Active Home Agent for a configured number of times, it SHOULD assume that the Active Home Agent has failed. If the active home agent does not periodically send the Hello message, each standby home agent needs to solicit it by sending a Hello Request message. The Hello message has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Preference | Home Agent Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hello Interval | Group ID |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Home Agent Hello Message Sequence # 16-bit unsigned integer. The Sequence number of the Hello message can be used to verify whether this Hello message is the latest one or not. Wakikawa (Editor) Expires December 21, 2006 [Page 18] Internet-Draft Home Agent Reliability June 2006 Home Agent Preference 16-bit unsigned integer. The preference for the home agent sending this hello. This preference is same as the home agent preference value of home agent information option defined in Mobile IPv6. However, if operators want to use the different preference value for this operation, it can use different value from the preference defined in RFC3775 Home Agent Lifetime 16-bit unsigned integer. The lifetime for the home agent sending this Hello. This lifetime is same as the home agent Lifetime value of home agent information option defined in Mobile IPv6. Hello Interval 16-bit unsigned integer. The interval for the home agent sending this Hello. Group Identifier 8-bit unsigned integer. This value is used to identify a particular redundant home agent set. A flag If this flag is set, the sender of this Hello message is an Active Home Agent. Otherwise, the sender is Standby Home Agent Reserved 7-bit unsigned integer. It must be initialized to zero by the sender and must be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in [1]. The receiver MUST ignore and skip any options which it does not understand. The following options are valid in a Hello: * IP Address Option (Sub-type: Home Agent Address): A Home Agent Address and its Prefix Length are stored in an IP address option. If there are multiple home network prefixes serving by Wakikawa (Editor) Expires December 21, 2006 [Page 19] Internet-Draft Home Agent Reliability June 2006 a home agent, multiple IP address options should be used in a Hello message. If no options are present in this message, 0 octets of padding are necessary and the Header Len field will be set to 2. 6.1.3. State Synchronization Request Message This message is used to request state corresponding to a particular mobile node. It is a unicast message and MUST be authenticated. The State Synchronization Request message is used to solicit the active state corresponding to a particular Mobile Node. The format of the message is as follows: The State Synchronization Request has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: State Synchronization Request Message Identifier The 16-bit identifier to aid in matching state synchronization message. The identifier should never be set to 0. It should always be more than 1. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in [1]. The receiver MUST ignore and skip any options which it does not understand. Wakikawa (Editor) Expires December 21, 2006 [Page 20] Internet-Draft Home Agent Reliability June 2006 The following options are valid in a State Synchronization Request message. One of the following options is mandatory in State Synchronization Request message. : * IP Address Option (Sub-type: Home Address)[9]. If a Home Agents wants the Binding Cache information for a particular Mobile Node, it includes an IPv6 Address Option (Sub-type: Home Address). * Mobile Network Prefix Option: If a home agent wants to know the forwarding state setting up for a particular Mobile Network Prefix, it includes a Mobile Network Prefix Option defined in [2]. If no options are present in this message, no padding is necessary and the Header Len field will be set to 1. 6.1.4. State Synchronization Message The State Synchronization message is used between the home agents in the Home Agent redundant set to exchange binding cache information, IPsec state and any other information related to providing mobility service to the mobile nodes. It is an unicast message. The state synchronization can be sent by an active home agent either periodically or in response to a state synchronization Request message. The State Synchronization message has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: State Synchronization Message Wakikawa (Editor) Expires December 21, 2006 [Page 21] Internet-Draft Home Agent Reliability June 2006 Identifier The 16-bit identifier to aid in matching state synchronization reply message. The identifier should never be set to 0. It should always be more than 1. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in [1]. The receiver MUST ignore and skip any options which it does not understand. The following options are valid in a State Synchronization message. One of the following options is mandate in State Synchronization message. : * Binding Cache Information Option. * AAA Information Option. * Vendor Specific Information Option. This message requires at least one of mobility options. Therefore, there is no default length for this message. 6.1.5. Home Agent SwitchOver Request Message This message is unicasted by a Standby Home Agent that desires to become the Active Home Agent for all the Mobile IPv6 sessions. The receiver of the message MUST transit to inactive state as soon as the message is received and validated. The Home Agent SwitchOver Request message has the MH Type value TBD. The message MUST be authenticated and encrypted by IPsec ESP.When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Home Agent SwitchOver Request Message Wakikawa (Editor) Expires December 21, 2006 [Page 22] Internet-Draft Home Agent Reliability June 2006 No padding is necessary and the Header Len field will be set to 1. 6.1.6. Home Agent SwitchOver Reply Message This message is used to acknowledge the receipt of the corresponding Home Agent SwitchOver Request message. The reply message should contain status_code field to convey the result of processing the received Home Agent SwitchOver Request message. The Home Agent SwitchOver message has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Home Agent SwitchOver Reply Message Status 16-bit Status value. Values of Status field greater than or equal to 128 indicate that the Home Agent SwitchOver Request was rejected by the receiving node. The following Status values are currently defined: 0: success 128: The receiver of the Home Agent SwitchOver Request message is not the Active Home Agent 129: failed, Admin Prohibited. No padding is necessary and the Header Len field will be set to 1. 6.1.7. Home Agent SwitchBack Request Message This message is unicasted by an Active Home Agent that desires to become the inactive Home Agent for all the Mobile IPv6 sessions. The receiver of this message SHOULD transit to active state as soon as the message is received and validated. The Home Agent SwitchBack Request message has the MH Type value TBD. The message MUST be authenticated and encrypted by IPsec ESP. When Wakikawa (Editor) Expires December 21, 2006 [Page 23] Internet-Draft Home Agent Reliability June 2006 this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Home Agent SwitchBack Request Message No padding is necessary and the Header Len field will be set to 1. 6.1.8. Home Agent SwitchBack Reply Message This message is used to acknowledge the receipt of the corresponding Home Agent SwitchBack Request message. The message should contain status_code field to convey the result of processing Home Agent SwitchBack Request message. The Home Agent SwitchBack Reply message has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Home Agent SwitchBack Reply Message Status 16-bit Status value. Values of Status field greater than or equal to 128 indicate that the Home Agent SwitchBack Request was rejected by the receiving node. The following Status values are currently defined: 0: success Wakikawa (Editor) Expires December 21, 2006 [Page 24] Internet-Draft Home Agent Reliability June 2006 128: The receiver of Home Agent SwitchBack Request is already the Active Home Agent 129: failed, Admin Prohibited. No padding is necessary and the Header Len field will be set to 1. 6.2. New Mobility Options 6.2.1. IP address Option This option is already defined at FMIP specification[9]. This document introduces new Sub-Type value for home agent address and Home Address. Option-Code * 4: Home Agent Address * 5: Home Address 6.2.2. Binding Cache Information Option The binding cache information option has an alignment requirement of 8n+2. Its format is as follows: Wakikawa (Editor) Expires December 21, 2006 [Page 25] Internet-Draft Home Agent Reliability June 2006 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 = TBD | Length = 40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Home Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . Mobile Network Prefix Option . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Binding Cache Information Option The binding cache information option is valid in a state synchronization message. The fields of Home Address, Care-of Address, Flags, Sequence Number, and Lifetime are copied from the registered binding of a particular Mobile Node or Mobile Router. 8-bit Reserved field MUST be set to zero. If the R-flag is set to indicate this binding cache entry is for a Mobile Router, then this option will be immediately followed by one or more Mobile Network Prefix options. Wakikawa (Editor) Expires December 21, 2006 [Page 26] Internet-Draft Home Agent Reliability June 2006 6.2.3. AAA Information Option The AAA option is used to carry the AAA state of the Mobile Node's MIP6 sessions. The AAA state information can be conveyed in RADIUS or Diameter AVP formats including the user and session info. This information option is valid in a state synchronization message. 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . AAA AVPs . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Vendor Specific Inforamtion Option Type 8-bit Type value. The value is TBD. Length 8-bit length value. AAA AVPs Series of TLV encoded AAA AVPs (including vendor specific AVPs) carrying AAA related information for each MIP6 and IPsec/IKE sessions. Reserved 16-bit field reserved for future use. The value SHOULD be initialized to zero by the sender, and MUST be ignored by the receiver. 6.2.4. Vendor Specific Information Option The Vendor Specific information option is used to carry the vendor specific information of a home agent. The Vendor Specific information option is valid in a state synchronization message. Wakikawa (Editor) Expires December 21, 2006 [Page 27] Internet-Draft Home Agent Reliability June 2006 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . Vendor Specific Information . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Vendor Specific Inforamtion Option Type 8-bit Type value. The value is TBD. Length 8-bit length value. Vendor Code 16-bit vendor code can be defined by each vendor. Reserved 16-bit field reserved for future use. The value SHOULD be initialized to zero by the sender, and MUST be ignored by the receiver. Wakikawa (Editor) Expires December 21, 2006 [Page 28] Internet-Draft Home Agent Reliability June 2006 7. Home Agent Operation 7.1. Home Agent Configuration There are two approaches to place Standby Home Agents. The first configuration is that a Standby Home Agent is located at the same link (i.e. home link) of home agents. Another one is that the Standby Home Agent is located at the different link from the home link. The differences are whether home agent and Standby Home Agents share the link or not. HA1 HA2 HA3 HA4 .... HAn | | | | | --------+------+------+------+--------+--------- Home Link Figure 16: Local Recovery Configuration Figure 16 depicts the configuration where home agents serving the same home network are located on the same link. For example, HA3 and HA4 are Standby Home Agents of HA1 and HA2. This is what Mobile IPv6 defines for home agent configuration. HA1 HA2 HA3 HA4 | | | | --------+------+-----+ R +-----+------+------- Home Link Router Recovery Link Figure 17: Global Recovery Configuration Figure 17 illustrates when standby home agents are located on different link (named recovery link in the figure). For example, HA3 and HA4 are standby home agents of HA1 and HA2. In this case, HA3 and HA4 cannot receive the packets meant for the home network till the route on the Router is changed. The advantage of this configuration is that Standby Home Agents can recover the failure of the home link. If the home link becomes unreachable, the local recovery is useless. However, this configuration can achieve the home agent recovery even if the entire home link fails. In this configuration, the routing must be also updated to direct the packets meant for the home link to the recovery link. Each Standby Home Agent obtains its individual IP address from the link. This IP address is used for home agent reliability protocol to Wakikawa (Editor) Expires December 21, 2006 [Page 29] Internet-Draft Home Agent Reliability June 2006 exchange information with the associated home agent. The link between home agents should be secured. When Home Agent Virtual Switch is used, the home agent's IP address which is known by the mobile node can be shared with Standby Home Agents. When a home agent fails, the standby home agent takes the IP address out of the failed home agent. Then the Standby Home Agent can uses the IP address for further home agent operations as being an Active Home Agent. The Standby Home Agent should not activate the IP address until the Active Home Agent is dead and the reachability to the IP address is lost. Otherwise, address duplication will occurs. This operation is normally done using route selector such as BGP and OSPF modifier. As an example we can use the AS_Path prepend operation for BGP and Metric field in the OSPF for route selection. The Ha reliability DT may define a new mobility option to carry respective BGP/OSPF modifier information. Alternatively, in Home Agent Hard Switch case, The home agent address may be different, but the home addresses and the home link prefix are the same. In this case, all the reachability of mobile nodes will be lost during the recovery procedure, since the IP address of Failed Home Agent is no longer active and all the packets meant for the IP address will be discarded. The Standby Home Agent must notify mobile nodes to change the associating home agent. Thus, the mobile node will detect the home agent changes by knowing the new IP address of the standby home agent. The home agent has to use the same technique as in virtual switch mode to advertise the routes into the routing infrastructure. 7.2. Hello messages Manipulation Mobile IPv6 [1] defines a mechanism for maintaining a home agent list when there are multiple home agents present on a link. It is based on each home agent sending a router advertisement periodically on the home link with a Home Address Information option [1]. However, this mechanism is governed by how a router sends a router advertisement as defined in [4]. There are restrictions on how often a router advertisement can be sent and on how they are processed by routers that receive them. Moreover, the router advertisements are not sent frequently enough to rely on the absence of the router advertisement to detect a home agent failure. Moreover, when home agents are placed at different links, Router Solicitation and Advertisement messages [4] can not be used due to link-local limitation. In this document, new Mobility Header messages are defined in Section 6.1.1 and Section 6.1.2 to notify similar information of Router Advertisement among home agents over the home link. Wakikawa (Editor) Expires December 21, 2006 [Page 30] Internet-Draft Home Agent Reliability June 2006 7.2.1. Sending Hello Request A home agent can solicit a Hello message by sending a Hello Request message. The Hello Request message is unicasted to an Active Home Agent or a Standby Home Agent. This message should be encrypted and authenticated by IPsec ESP mode. An originator of the Hello Request message must specify the random sequence value. The sequence value is used to match the Hello message which is sent from the receiver of the Hello Request message. 7.2.2. Receiving Hello Request When a home agent receives a hello Request message, it SHOULD verify correct IPsec protection. If the message is not protected, it SHOULD be silently discarded. However, if the Hello messages can be sent on a dedicated link between the home agents and in such a case, IPsec protection is not required. If the sender home agent is not in the same redundant home agent set, the message MUST be silently ignored, too. The sequence field should be copied to the Hello message which will be sent in reply to the hello Request message. This sequence number is used as a transaction ID for the Hello message exchange. 7.2.3. Sending Hello A home agent Hello message MUST be constructed with same information of a Router Advertisement message described in section 7 of [1]. The Hello messages can be unicasted or multicasted. A new multicast address will be assigned by the IANA. All the home agents on the home link should join this multicast address. When the Hello messages are used for maintaining the home agents list, the home agent SHOULD NOT use the home agent Information option in the router advertisements to manage the home agents list. The Hello message MUST be sent when a home agent is requested by a hello Request message. The Hello message can be also periodically sent. In addition, the home agent SHOULD send a home agent Hello message to home agents of the redundant home agent set when it boots up and its local information such as preference, lifetime, and registration status, etc. change. The interval between two Hello messages is configurable on the home agents. When a new home agent boots up, it SHOULD wait a particular time to listen home agent Hello messages of all configured Home Agents. Alternatively, it can solicit Hello message by sending a Hello Request message. If a home agent is the Active Home Agent, it MUST set A flag in Hello Wakikawa (Editor) Expires December 21, 2006 [Page 31] Internet-Draft Home Agent Reliability June 2006 Messages. 7.2.4. Receiving Hello The receiver of a Home Agent Hello message MUST verify the source address field of the IPv6 header. If a Home Agent Hello message is received from unknown home agent, the message MUST be silently dropped. If the source address is not in the list of known home agents, the message MUST be silently dropped. In addition to this source address check, Group ID is introduced in this document. This Group ID is used to identify a particular redundant home agent set. If the Group ID field is specified in a Hello message, the receiver MUST process only the Hello which group ID is matched. This Group ID is verified when the Hello message is multicasted. The Hello message MUST NOT be sent to a home agent whose Group ID is different from the sender. If the Group ID is set to zero, the receiver MUST ignore this field. Any Home Agent Hello message satisfying all of these tests MUST be processed to update its home agent list. The Home Agents list can be ordered based on the home agent preference value. If the home agent lifetime field in the Hello message is set to 0, the receiver removes the sender home agent that from the home agents list. 7.3. Failure Detection When a home agent meets an error and cannot fulfill home agent functionality, the Standby Home Agent must detect the failure and should act as the Active Home Agent. The failure detection is important feature of Home Agent local reliability. The most common way to detect failure is using periodic message exchange such as Hello of routing protocols. This mechanism is often used to detect failure on many protocols. In the real scenario, when a home agent crashed, it can happened that only home agent functionality is down and network reachability to home agent is alive. In this case, ICMP type of message such as ping can not be used to detect the home agent failure. Therefore, we define a new Hello message to detect the home agent failure. The Active and the Standby Home Agents exchange periodic Hello messages to monitor one another's status. Hello request message may be used by any Home Agent to explicitly request state information from any other Home Agent in the redundant Home Agent set. If a Home Agent Hello message is not received from a Home Agent peer within a configurable amount of time, then that home agent peer is considered to have failed. Wakikawa (Editor) Expires December 21, 2006 [Page 32] Internet-Draft Home Agent Reliability June 2006 Example Failure Events: Loss of Communication with the Active Peer Home Agent The redundant Home Agent set should have knowledge of each others state. In order to achieve that, we define Hello message exchanges. In the event that the Home Agent that is currently inactive does not receive any Hello message from its peer which is currently active for a configurable duration, the Home Agent may decide to become active. Monitored Server Failure by the Active Home Agent There may be number of critical servers in the network that are essential for the ongoing Mobile IPv6 session at the Home Agent. One such server may be the AAA server which is receiving the accounting information for the session. The operator may have a policy in place that requires the Home Agent to initiate SwitchOver procedure upon detecting that the link to such a server has failed. Routing Peer/Link Failure In some cases, the operator may like the Home Agent to detect a next hop routing peer failure. If the next hop routing peer fails, the operator may want the Home Agent to initiate SwitchOver if the failure is fatal in nature or due to some other routing policies. 7.4. Active Home Agent Change There are two cases when a Standby Home Agent takes over an Active Home Agent. The first case is when a Standby Home Agent detects failure of the Active Home Agent described in Section 7.3. The Standby Home Agent immediately becomes an Active Home Agent. The second case is when a home agent receives a Home Agent SwitchOver Request message described in Section 7.6. Upon detecting failure of an Active Home Agent, the Standby Home Agent becomes Active. If there are more than one Standby Home Agent or when there are two Home Agents in the redundant Home Agent set, but both of them boots up at the same time, two values are used to break any tie. The Home Agent with lowest BGP/OSPF modifier value becomes Active. If the BGP/OSPF modifiers are the same, then the home agent preference values (configured by the system administrator) is used to break the tie. When the Standby Home Agent becomes active, it MUST start to Wakikawa (Editor) Expires December 21, 2006 [Page 33] Internet-Draft Home Agent Reliability June 2006 advertise the home agent address and the home prefix of the home addresses serviced by the redundant home agent set into the routing infrastructure. This is operated by using route selector such as BGP and OSPF modifier. In addition, if necessary, the new active home agent must overwrite the neighbor entries of the mobile nodes in order to intercept packets of the mobile nodes. 7.5. Processing State Synchronization Messages It is necessary for Standby Home Agent to synchronize the state information of each mobile node stored in the active home agent. In Home Agent Virtual Switch mode, the synchronized state information is used by a Standby Home Agent when it takes over the Failed Home Agent. In Home Agent Hard Switch mode, the Standby Home Agent starts the trigger to all the mobile nodes registering to the Failed Home Agent when the home agent failure is detected. This state synchronization must be securely operated. 7.5.1. Sending State Synchronization Request When a Standby Home Agent wants state for a particular Mobile Node such as Binding Cache, AAA, etc, it can solicit State Synchronization message by sending State Synchronization Request. This is optional operation of a standby home agent. The Standby Home Agent MUST set a random value to the Identifier field in the state synchronization Request message and MUST include either a Home Address mobility option or a Mobile Network Prefix mobility option. The Standby Home Agent can store multiple home address mobility options or mobile network prefix mobility options to request state information for multiple mobile nodes by a single state synchronization Request message. 7.5.2. Receiving State Synchronization Request If the received state synchronization Request message is not protected by IPsec ESP, the message must be silently discarded. If the sender home agent is not belong to the same redundant home agent set, the message must be silently ignored. Moreover, if a receiver is not the Active Home Agent for the requested home address or mobile network prefix, it MUST silently discard the message. Otherwise, the receiver MUST reply with a State Synchronization message including state information for the requested mobile node(s). 7.5.3. Sending State Synchronization A state synchronization message can be sent either: Wakikawa (Editor) Expires December 21, 2006 [Page 34] Internet-Draft Home Agent Reliability June 2006 o when an Active Home Agent receives a state synchronization Request message o when an Active Home Agent creates/updates binding cache for a particular Mobile Node. o in a periodic interval to update the state info for all sessions that changed since last update. If an Active Home Agent sends the state synchronization message whenever the local state information such as binding cache changed, the size of the state synchronization message are large. The Active Home Agent should update the state information with an interval which is configured by system administrator. The binding cache of the requested Mobile Node are stored in the state synchronization message. The Active Home Agent MUST copy the binding cache of the requested Mobile Node to each fields of a binding cache information option. If the state synchronization message is sent in response to the state synchronization Request message, the Active Home Agent MUST copy the Identifier field of the state synchronization Request message to the same filed in the state synchronization message. Otherwise, it MUST set zero to the Identifier field. The Active Home Agent can store state of multiple mobile nodes in a state synchronization message 7.5.4. Receiving State Synchronization A state synchronization message MUST be authenticated and encrypted by IPsec ESP mode. If not, the message MUST be ignored. When a Home Agent receives a state synchronization message, it MUST verify the Source address field of the IPv6 header. If the source address do not belong to any home agents of the redundant home agent set, the message MUST be silently discarded. The receiver home agent SHOULD record the state and the Active Home Agent address into its Binding Cache. 7.6. Processing Home Agent SwitchOver Messages 7.6.1. Sending Home Agent SwitchOver Request When a Standby Home Agent decides to become an active home agent, it MAY send a home agent SwitchOver Request message to an Active Home Agent. The reason for the Standby Home Agent to send this message is administrative intervention. The Standby Home Agent sends with a mobility header which type is set to the home agent SwitchOver Wakikawa (Editor) Expires December 21, 2006 [Page 35] Internet-Draft Home Agent Reliability June 2006 Request type. This message must be encrypted and authenticated by IPsec ESP. The Active Home Agent MUST NOT generate this message. 7.6.2. Sending Home Agent SwitchOver Reply A home agent SwitchOver reply is sent in reply to a home agent SwitchOver Request message. When a home agent receives a home agent SwitchOver Request message, it first verifies the message. If the request message is not protected by IPsec, it MUST be silently discarded. In addition, if the sender home agent is not belong to the same redundant home agent set, the message MUST be silently discarded. If a receiver home agent is not an Active Home Agent, it replies a home agent SwitchOver reply which status field set to 128. Otherwise, the receiver home agent MUST become a Standby Home Agent and replies a home agent SwitchOver reply which status field set to zero. 7.6.3. Receiving Home Agent SwitchOver Reply If a home agent receives a home agent SwitchOver reply, the message MUST be protected by IPsec. Otherwise, the message MUST be silently discarded. If a receiver home agent did not send a home agent SwitchOver Request beforehand, the message MUST be silently discarded. If the status field of the SwitchOver reply message indicates zero, the receiver Standby Home Agent immediately becomes an Active Home Agent. If the status value is greater than 128, an error is occurred. Thus, the receiver cannot be an active home agent. 7.7. Processing Home Agent SwitchBack Messages 7.7.1. Sending Home Agent SwitchBack Request When an Active Home Agent decides to become an in-active home agent (i.e. Standby Home Agent), it MAY send a home agent SwitchBack Request message to a Standby Home Agent. The reason for the Active Home Agent to send this message is administrative intervention, and events like Monitored Server Failure by the Active Home Agent or Routing Peer/Link Failure. The Active Home Agent sends it with a mobility header which type is set to the home agent SwitchBack Request type. This message must be encrypted and authenticated by IPsec ESP. A Standby Home Agent MUST NOT generate this message. Wakikawa (Editor) Expires December 21, 2006 [Page 36] Internet-Draft Home Agent Reliability June 2006 7.7.2. Sending Home Agent SwitchBack Reply A home agent SwitchBack reply is sent in reply to a home agent SwitchBack Request message. When a home agent receives a home agent SwitchBack Request message, it first verifies the message. If the request message is not protected by IPsec, it MUST be silently discarded. In addition, if the sender home agent is not belong to the same redundant home agent set, the message MUST be silently discarded. If the sender home agent of SwitchBack Request message is not an Active Home Agent, the message MUST be silently discarded. If a receiver home agent of SwitchBack Request message is already an Active Home Agent, it replies home agent SwitchBack reply which status field set to 128. Otherwise, the receiver home agent MUST become an Active Home Agent and replies a home agent SwitchBack reply which status field set to zero. 7.7.3. Receiving Home Agent SwitchBack Reply If a home agent receives a home agent SwitchBack reply, the message MUST be protected by IPsec. Otherwise, the message MUST be silently discarded. If a receiver home agent did not send a home agent SwitchBack Request message beforehand, the message MUST be silently discarded, too. If the status field of the SwitchBack reply message indicates zero, the receiver home agent immediately becomes an in-Active Home Agent. If the status value is greater than 128, some error is occurred. Thus, the receiver cannot be an in-active home agent and MUST continue to be an Active Home Agent. 7.8. Sending Home Agent Switch Message If an Active Home Agent fails, another Standby Home Agent on the home link can take over the Failed Home Agent in the Home Agent Hard Switch mode. This operation is valid only for the Home Agent Hard Switch mode. The Standby Home Agent MUST send a home agent Switch message defined in [8] to all the mobile nodes that were being served by the Failed Home Agent. The message must be encrypted with pre- established SA. The standby home agent should include its own IP address in the home agent switch message. Note that a Home Agent Switch message is sent to each mobile node served by the home agent. If there are a large number of mobile nodes, sending Home Agent Switch messages will cause a lot of signaling overhead on the network. Wakikawa (Editor) Expires December 21, 2006 [Page 37] Internet-Draft Home Agent Reliability June 2006 8. Mobile Node Operation Operations described in this section are valid only for the home agent hard switch mode. When the Home Agent Virtual Switch is used, all the operations can be skipped. 8.1. Standby Home Agent Addresses Discovery To provide home agent reliability, one possible solution is that the Mobile Node authenticate itself to two home agents and creates IPsec SA with two home agents in bootstrapping. When one home agent fails the other home agent could use pre-existing SA to notify the Mobile Node about the failure. In the Home Agent Hard Switch mode, multiple home agent addresses are valid in the home network. In order to discover the home agent address, two different mechanisms are defined in the bootstrapping solution in split scenario [10]. One is DNS lookup by home agent Name, the other is DNS lookup by Service Name. Also in integrated scenario [11], DHCPv6 is used to provide home agent provision to Mobile Node. In the split scenario, Mobile Node can use DNS lookup by Service Name to discover the home agents, as defined in [10]. For example, If home agent reliability is required by the Mobile Node, DNS lookup by Service Name method is recommended for Mobile to discovery multiple home agents addresses. Therefore Mobile Node will query the DNS SRV records with service name of mip6 and protocol name of ipv6. the DNS SRV records includes multiple home agents addresses and different preference value and weight. The mobile node SHOULD choose two home agents from the Home Agents list according to there preference value. Then the Mobile Node should authenticate itself to both home agents via IKEv2 exchange. In the integrated scenario, Mobile Node can use DHCPv6 to get home agents provision from MSP or ASP, as already defined in [11]. The only requirement is that the DHCPv6 response must include multiple home agent information in order to support home agent reliability. 8.2. IKE/IPsec pre-establishment to Home Agents After Mobile Node get multiple Home Agent addresses, it need to trigger multiple IKE exchange with multiple home agents selected from the Home Agent list. Since both IKEv1 and IKEv2 can be used to bootstrap Mobile IPv6, this solution does not introduce any new operations to co-operate with IKEv1 or IKEv2. It should initiate IKE for home agents as soon as home registration is completed. Wakikawa (Editor) Expires December 21, 2006 [Page 38] Internet-Draft Home Agent Reliability June 2006 The Mobile Node MUST follow standard IKEv2 exchange in bootstrapping solution of split scenario [10], or IKEv1 bootstrap solution [12]. if needed by Mobile Node, Home Address configuration maybe included for the first IKE exchange. After its Home Address is assigned or approved by the first home agent, Mobile Node SHOULD register itself to the second home agent by IKE using the same Home Address. Therefore, no HoA configuration should be used in the second IKEv2 procedure. Note that the Mobile Node sends Binding Update Message to the first home agent. 8.3. Receiving Home Agent Switch message A mobile node must follow the operation specified in [8] when it receives home agent switch message. When the mobile node receives a Home Agent Switch message, and if the message contains the IP address of standby home agent, it picks the Standby Home Agent in the request message as the Active Home Agent and sends a Binding Update message to it. The mobile node have already pre-established SA with the home agent and use the SA to send Binding Update. However, in this specification, the binding cache information is already synchronized among the redundant home agent set, the mobile node can skip this binding re-registration to the new active home agent. In this case, the mobile node only updates the Home Agent address of all the binding update list, MIP6 tunnel end points, etc. Wakikawa (Editor) Expires December 21, 2006 [Page 39] Internet-Draft Home Agent Reliability June 2006 9. Security Considerations Mobile IPv6 depends on IPsec and IKE for binding home registration described in [5]. A mobile node must encrypt a binding update sent to a home agent. In addition, the mobile node exchanges HoTI and HoT messages through a home agent by using IPsec tunnel mode. Therefore, before a home agent failure, these IPsec states (below is example) should be synchronized among home agents of a redundant home agent set. mobile node may encrypt particular data traffic sent to the Internet. o Security Policy Database (SPD) and Selector Information o Security Association (SA) for Binding Registration (SA1 and SA2) o SA for HoTI/HoT Exchange (SA3 and SA4) o SA for Mobile Prefix Discovery (SA5 and SA6) o SA for data packets if any (SA7 and SA8) The Home Agent reliability scheme for Mobile IPv6 involves IPsec tunnel SwitchOver upon Home Agent failure. There are various ways this can be achieved e.g. setting up of multiple IPsec security associations between the Mobile Node and the Home Agent sets. Another way could be, the Home Agents periodically check pointing IPsec session state including the per packet sequence numbers for the Mobile Node. We can call these two possible Home Agent redundancy modes as follows: 1. Home Agent Hard Switch. In this mode, the Mobile Node and the redundant Home Agent set negotiates independent IPsec SAs. 2. Home Agent Virtual Switch. In this mode, the Mobile Node negotiates just one SA for both the redundant Home Agent set. In both the cases, the mobile node maintains only one binding cache at any given time. In the Home Agent Hard Switch case, the mobile node needs to switch binding from active to Standby Home Agent upon failover. IPsec redundancy need synchronize both SPD, Selector and SAD information from one home agent to another home agent. Since Mobile IPv6 operation requires ESP in transport mode between the Mobile Node and the Home Agent, we will talk about the ESP field synchronization issues between the Mobile Node and the redundant set of Home Agents. Most of fields should be synchronized based on RFC4301[6]. The ESP header has the following fields: Wakikawa (Editor) Expires December 21, 2006 [Page 40] Internet-Draft Home Agent Reliability June 2006 SPI This field identifies the SAD at the receiver. Home Agent Hard Switch Mode the Mobile Node and the redundant Home Agent set negotiates separate/independent IPsec SAs. Therefore, the SPI value will vary depending on which Home Agent the Mobile Node selects to send/receive data packets. Home Agent Virtual Switch Mode The Mobile Node negotiates only one IPsec SA. Hence, the SPI value will remain unchanged upon Home Agent SwitchOver. Sequence Number This field is used for "anti-replay" feature of ESP. The transmitter must include this monotonically increasing number. The receiver may process the sequence number based on local policy. Home Agent Hard Switch Mode The Mobile Node and the redundant Home Agent set will have independent set of sequence numbers. Therefore, the Mobile Node and the Home Agent needs to choose the most appropriate sequence number to be used. Synchronization of the sequence number field between the Home Agents is not mandatory in this mode of operation. Home Agent Virtual Swtich Mode The Mobile Node and the redundant Home Agent set will have the same set of sequence numbers for transmit and receive. Hence, synchronization of the sequence number field is mandatory in this mode of operation. For MIP6 signaling i.e. BU/BA, HoTi/HoT etc. the SA1, SA2, SA3, SA4 could be synchronized between the Home Agents as these messages are not sent continuously. Moreover for the BU Case, if the Mobile Node is in the middle of sending a BU to the Home Agent (Active Home Agent) for binding refresh, and the Home Agent is crashing at that moment. The Mobile Node will not get any response from the Home Agent. The Mobile Node will retry. After the Standby Home Agent becomes active, it will receive BU from the Mobile Node with a sequence number that is +n from its last known Wakikawa (Editor) Expires December 21, 2006 [Page 41] Internet-Draft Home Agent Reliability June 2006 sequence number for SA1. For the BA case (SA2), the Standby Home Agent SHOULD add a random number to the last known sequence number over and above the replay window to ensure that the packet passes replay check at the Mobile Node. The same applies to HoTi and HoT messages with SA3 and SA4. Note that this windowing of the sequence numbers for MIP6 signaling is only needed to cover the corner cases when BU/HoTi is in air and the Active Home Agent fails. The technique explained above should work fine for user data packets if ESP is used to encrypt user data traffic as well. The actual switchover time and the routing infrastructure convergence time is the only latency that the user may perceive. Initialization Vector Since each time, IV will be delivered between Mobile Node and Home Agent, so this field is not necessarily synchronized between home agents. Others Other fields should be synchronized based on RFC4301[6] In Home Agent Hard Switch mode, the Standby Home Agent needs to send a home agent switch message in secure way ( i.e. required IPsec encryption to the trigger). The mobile node pre-establishes IPsec SA with the Standby Home Agent, as well as an active home agent. The Standby Home Agent can send a trigger to the mobile node with the pre-established IPsec SA. Wakikawa (Editor) Expires December 21, 2006 [Page 42] Internet-Draft Home Agent Reliability June 2006 10. Contributors This document is a result of discussions in the Mobile IPv6 Home Agent Reliability Design Team. The members of the design team are listed below: Samita Chakrabarti samita.chakrabarti@sun.com Kuntal Chowdhury kchowdhury@starentnetworks.com Hui Deng hdeng@hitachi.cn Vijay Devarapalli vijay.devarapalli@azairenet.com Sri Gundavelli gundave@cisco.com Brian Haley brian.haley@hp.com Behcet Sarikaya bsarikaya@huawei.com Ryuji Wakikawa ryuji@sfc.wide.ad.jp 11. Acknowledgements This document includes a lot of text from [13] and [14]. Therefore the authors of these two documents are acknowledged. We would also like to thank the authors of the home agent reliability problem statement [15] for describing the problem succinctly and Alice Qin for her work on the hello protocol. Wakikawa (Editor) Expires December 21, 2006 [Page 43] Internet-Draft Home Agent Reliability June 2006 12. References 12.1. Normative References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [6] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 12.2. Informative References [7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [8] Haley, B., "Mobility Header Home Agent Switch Message", draft-ietf-mip6-ha-switch-01 (work in progress), June 2006. [9] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [10] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-02 (work in progress), March 2006. [11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in progress), October 2005. [12] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6 Bootstrapping with IKEv1", draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress), March 2006. Wakikawa (Editor) Expires December 21, 2006 [Page 44] Internet-Draft Home Agent Reliability June 2006 [13] Wakikawa, R., "Inter Home Agents Protocol Specification", draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), March 2006. [14] Devarapalli, V., "Local HA to HA protocol", draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), March 2006. [15] Faizan, J., "Problem Statement: Home Agent Reliability", draft-jfaizan-mipv6-ha-reliability-01 (work in progress), February 2004. Wakikawa (Editor) Expires December 21, 2006 [Page 45] Internet-Draft Home Agent Reliability June 2006 Author's Address Ryuji Wakikawa Keio University Department of Environmental Information, Keio University 5322 Endo, Fujisawa, Kanagawa 252-8520 Japan Email: ryuji@sfc.wide.ad.jp Wakikawa (Editor) Expires December 21, 2006 [Page 46] Internet-Draft Home Agent Reliability June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wakikawa (Editor) Expires December 21, 2006 [Page 47]