MIP6 Working Group R. Wakikawa (Editor) Internet-Draft Keio University Intended status: Standards Track July 17, 2007 Expires: January 18, 2008 Home Agent Reliability Protocol draft-ietf-mip6-hareliability-02.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 January 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Wakikawa (Editor) Expires January 18, 2008 [Page 1] Internet-Draft HA Reliability July 2007 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 of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement and Requirements . . . . . . . . . . . . . . 6 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Home Agent Network Configuration . . . . . . . . . . . . . 10 5.2. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 11 5.3. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12 5.4. Active Home Agent Management . . . . . . . . . . . . . . . 13 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 14 6.1.1. State Synchronization Message . . . . . . . . . . . . 14 6.1.2. Home Agent Control Message . . . . . . . . . . . . . . 16 6.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 18 6.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 20 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 20 6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 20 6.2.2. Binding Cache Information Option . . . . . . . . . . . 21 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 22 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 23 7.1. Home Agent Address Configuration . . . . . . . . . . . . . 23 7.2. Consideration of Routing and Neighbor Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. Home Agent List Management . . . . . . . . . . . . . . . . 24 7.4. Detecting Home Agent Failure . . . . . . . . . . . . . . . 25 7.5. Home Agent Switch Over . . . . . . . . . . . . . . . . . . 26 7.6. Processing Hello Messages . . . . . . . . . . . . . . . . 27 7.6.1. Requesting Hello Message . . . . . . . . . . . . . . . 27 Wakikawa (Editor) Expires January 18, 2008 [Page 2] Internet-Draft HA Reliability July 2007 7.6.2. Sending Hello Message . . . . . . . . . . . . . . . . 27 7.6.3. Receiving Hello Message . . . . . . . . . . . . . . . 28 7.7. Processing State Synchronization Messages . . . . . . . . 29 7.7.1. Soliciting State of a Particular Mobile Node or Subset of Mobile Nodes . . . . . . . . . . . . . . . . 29 7.7.2. Synchronizing State of Mobile Nodes . . . . . . . . . 30 7.8. Processing Home Agent Control Messages . . . . . . . . . . 31 7.8.1. Standby Home Agent becomes an Active Home Agent . . . 31 7.8.2. Active Home Agent becomes in-active . . . . . . . . . 32 7.9. Sending Home Agent Switch Messages . . . . . . . . . . . . 32 7.10. Interworking with VRRP . . . . . . . . . . . . . . . . . . 33 7.11. Retransmissions and Rate Limiting . . . . . . . . . . . . 35 8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 36 8.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 36 8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 36 8.3. Receiving Home Agent Switch message . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . . 42 Appendix A. Change Log From Previous Versions . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 45 Wakikawa (Editor) Expires January 18, 2008 [Page 3] Internet-Draft HA Reliability July 2007 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 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 a loss of service for the mobile nodes. It is beneficial to provide high availability and redundancy for a home agent so that mobile nodes can avail of uninterrupted service even when one home agent crashes or loses state. Wakikawa (Editor) Expires January 18, 2008 [Page 4] Internet-Draft HA Reliability July 2007 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 [10]. 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 group of active and standby home agent(s). The Group Identifier is used 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 Duplicate Home Agent Address Discovery (DHAAD) in RFC3775. This protocol uses this preference value for home agent selection when an active home agent has failed. However, an operator can also define an independent value used only for the home agent reliability protocol if the operator wants to have different preference values for DHAAD and the home agent reliability protocol. A home agent SHOULD NOT use the same preference value as other home agents for this protocol. Wakikawa (Editor) Expires January 18, 2008 [Page 5] Internet-Draft HA Reliability July 2007 3. Problem Statement and Requirements In Mobile IPv6 [1], a mobile node registers and establishes a binding 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 a home agent, a mobile node can re-establish its connection through a new home agent. However, the base Mobile IPv6 specification does not address 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 coordination or pre- configuration among the home agents regarding security associations, transfer of mobile node bindings, and other service information for reliable Mobile IPv6 service in a deployment scenario. 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 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 applications and should not take longer than the care-of-addresses update procedure described in 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 for the mobile node is assumed. State Synchronization The information for mobile nodes must be able to be synchronized between an active home agent and standby home agents. This includes the Binding Cache, AAA information, other Mobile IPv6 and NEMO related information. Consideration of IPsec/IKE transfer Wakikawa (Editor) Expires January 18, 2008 [Page 6] Internet-Draft HA Reliability July 2007 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. If a home agent supports an existing failure detection mechanism such as VRRP[4] or HSRP[5], it can re- use that mechanism to detect the home agent failure. On the other hand, periodic Hello messages are introduced to detect active home agent's service availability in this document. Failure Notification If necessary, a mobile node is notified about the active home agent failure by the standby home agent. Wakikawa (Editor) Expires January 18, 2008 [Page 7] Internet-Draft HA Reliability July 2007 4. Protocol Design Mobile IPv6 depends on IPsec and IKE for home binding registration as described in [6]. A mobile node must encrypt a Binding Update sent to a home agent. In addition, the mobile node exchanges HoTI and HoT messages through the home agent by using IPsec tunnel mode. Therefore, before home agent failure, these IPsec states should be synchronized among home agents of a redundant home agent set. A mobile node may also encrypt particular data traffic sent to nodes in the Internet. IPsec information required by Mobile IPv6 is listed below. 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) There are various ways this can be achieved. One is to setup multiple IPsec security associations between the mobile node and the home agent sets. Another is to have the home agents periodically check-point IPsec session state, including the per packet sequence numbers, for the mobile node. Thus, we define two possible home agent redundancy modes as follows: Home Agent Virtual Switch Each mobile node negotiates just one SA with an active home agent in a redundant home agent set. The IPsec state will be shared within the redundant home agent set in the background. The active and the redundant home agents are addressed by the same home agent address, although only the active home agent is accessible by the home agent address all of the time. IPsec/IKE states must be synchronized between the active and standby home agents. The mechanism used to synchronize IPsec state is considered out of scope for this document. In case there is a failure of the active home agent, the standby home agent takes over without the mobile node being aware of the change in the home agent. In a redundant home agent set, a single home agent address is used by the active home agent. Thus, all the mobile nodes served by a redundant home agent set MUST associate with the same home agent (the active home agent) all the time. Wakikawa (Editor) Expires January 18, 2008 [Page 8] Internet-Draft HA Reliability July 2007 Home Agent Hard Switch The home agents are addressed by different IP addresses and the mobile node is aware of the change of home agent. A Mobile node and all home agents in a redundant home agent set negotiate independent IPsec SAs. This mode is especially useful when the IPsec/IKE states cannot be synchronized. However, the home agent change is not transparent to the mobile node. When an active home agent fails, a mobile node will receive a notification (a Home Agent Switch message [11]) from a standby home agent, and send a Binding Update to the standby home agent. In order to exchange the Home Agent Switch message securely between the standby home agent and a mobile node, the mobile node needs to establish an IPsec SA with both the active and the standby home agents in the redundant home agent set beforehand. Since each home agent has a different address, an active home agent can be defined for each mobile node. When a mobile node boots, it will discover home agents and create IPsec SAs with them. It will then decide which one of the home agents is its active home agent. For example, when two home agents serve a home network, half of the mobile nodes might register with one home agent and the rest of mobile nodes with another home agent. When one of the home agents fails, a standby home agent, whose preference value is next highest than the failed home agent, can trigger a home agent switch by sending a Home Agent Switch message to the mobile nodes that were registered with the failed home agent. In both the cases, the mobile node maintains only one home binding at any given time. In the Home Agent Hard Switch mode, the mobile node needs to switch its binding from the active to standby home agent upon failover. The bindings are synchronized among home agents in the redundant home agent set in the background when the Home Agent Virtual Switch mode is used. All new messages defined in this document are defined as Mobility Header messages so that the Home Agent Reliability protocol can be extended to provide home link redundancy. Finally, the reasons why we defined a new Hello message instead of using VRRP is described in Section 7.3 and Section 7.4. We also give instructions on how operators can run both VRRP and the Home Agent Reliability protocol at the same time in Section 7.10. Wakikawa (Editor) Expires January 18, 2008 [Page 9] Internet-Draft HA Reliability July 2007 5. Protocol Overview 5.1. Home Agent Network Configuration The Home Agent Reliability protocol supports two different configurations for standby home agents. Standby home agents can be placed on the same home link as the active home agent, or on a different link. The Global Recovery described below is not included in this document, although the Home Agent Reliability protocol can support this with slight modifications to home agent operations. HA1 HA2 HA3 HA4 .... HAn | | | | | --------+------+------+------+--------+--------- Home Link Figure 1: Local Recovery Configuration Figure 1 depicts the configuration where home agents serving the same home network are located on the same link. For example, HA2, HA3 and HA4 are standby home agents of HA1. This is the same as what Mobile IPv6 defines for home agent configuration. ---------IGP------>|<---BGP--->|<-----IGP--------- HA1 HA2 HA3 HA4 | | | | --------+------+-----+ R---R---R +-----+------+------- Home Link Routers Recovery Link Figure 2: Global Recovery Configuration Figure 2 illustrates when standby home agents are located on a different link (named the recovery link in Figure 2). HA3 and HA4 are standby home agents of HA1 and HA2. In this case, HA3 and HA4 cannot receive packets meant for the home network until the route on the Routers is changed. The advantage of this configuration is that standby home agents can recover from a failure of the home link. This configuration can achieve 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. Wakikawa (Editor) Expires January 18, 2008 [Page 10] Internet-Draft HA Reliability July 2007 This geographic redundancy is not a requirement by most SDOs (Standards Development Organization), but is required by operators. Most large operators have a very stringent requirement on network availability even in the worst type of disaster or outage. For example, critical nodes in region-1 are backed up by nodes in region-2. These two regions are geographically separated. If region-1 suffers a downtime due to any reason, all the sessions will be seamlessly taken over by the nodes in region-2. This is called geographic redundancy. This is a well-known configuration for Telecommunications operators. 5.2. Home Agent Virtual Switch A mobile node remains unaware about the change in the active home agent since the home agents have replicated all session state including the IPsec/IKE/ESP states. The IPsec/IKE/ESP state transfer is out of scope of this document. MN HA1(active) HA2(Standby) | | . |<--------->| | 1. IKE exchange (with HoA assignment) |---------->| . 2. Binding Update |<----------| . 3. Binding Acknowledgment | | . | |<--------->. 4. State exchanges (binding cache/IPsec) | | . | X . HA1 FAILURE | X . | X<----------. 5. Failure Detection | X | 6. HA2 takes over the HA1 | X | | X | RECOVERY COMPLETE Figure 3: Overview of Home Agent Virtual Switch The operations of the Home Agent Virtual Switch mode are shown in Figure 3. The mobile node first attempts the IKE exchange for Security Association (SA) setup and home address assignment (1). After binding registration is done (2, 3), the active home agent pushes all the states of its mobile nodes with a state synchronization message (4). 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 for the failed home agent. All the home agents in the Wakikawa (Editor) Expires January 18, 2008 [Page 11] Internet-Draft HA Reliability July 2007 redundant home agent set share a virtual home agent address and the routing will ensure only the active home agent will be reachable using that virtual home agent 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. 5.3. Home Agent Hard Switch The overview of the Home Agent Hard Switch is shown in Figure 4. This mode is not transparent to the mobile node when the active home agent failure occurs. MN HA1(active) HA2(Standby) | | | |<--------->| | 1. IKE exchange (with HoA assignment) |---------->| | 2. Binding Update |<----------| | 3. Binding Acknowledgment |<--------------------->| 4. IKE exchange (without HoA assignment) | | | | |<--------->. 5. State exchanges (binding cache) | | | | X | HA1 FAILURE | X | | X<----------| 6. Failure Detection |<----------------------| 7. Sending Home Agent | X | Switch message |<--------------------->| 8. Binding Registration | X | | X | RECOVERY COMPLETE Figure 4: Overview of Home Agent Hard Switch The mobile node establishes IPsec/IKE state with all the home agents in the redundant home agent set beforehand (1 and 4), however it registers its binding only with the active home agent (2 and 3). When an active home agent fails, a standby home agent uses a pre- existing IPsec SA to notify the mobile node about the failure by securely sending a Home Agent Switch message. In order to discover home agent addresses, two different mechanisms are defined, as described in Section 8.1. The active home agent synchronizes the required states of the mobile nodes, such as Binding Cache and AAA information, with other standby home agents periodically (5). The mobile node MUST NOT request a home address(es) assignment through the IKE exchange to the standby home agent when it establishes an SA with it (4). Wakikawa (Editor) Expires January 18, 2008 [Page 12] Internet-Draft HA Reliability July 2007 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 nodes that were registered with the failed home agent (7). The Home Agent Switch message must be encrypted by a pre-established IPsec SA. After the switch message, the mobile node MUST send a binding update to the new active home agent in order to update the Mobile IPv6 tunnel end points (8). 5.4. Active Home Agent Management 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 5: Manual Home Agent Change In some scenarios the active home agent may need to stop serving mobile nodes for system maintenance. This specification provides for a manual home agent switch by using SwitchBack Request and Reply messages. As shown in Figure 5, the active home agent (HA1) sends a SwitchBack Request message to a standby home agent (HA2). As soon as HA2 receives the message, it becomes the active home agent. HA2 will acknowledge the message by sending a SwitchBack Reply message to HA1. HA1 becomes a standby home agent when it receives the SwitchBack Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in order to become the active home agent again. Wakikawa (Editor) Expires January 18, 2008 [Page 13] Internet-Draft HA Reliability July 2007 6. Messages 6.1. New Mobility Header Messages 6.1.1. State Synchronization Message This message is used to exchange state corresponding to a particular mobile node. It MUST be unicasted and MUST be authenticated by IPsec ESP. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: State Synchronization Message Type 8-bit unsigned integer. It can be assigned one of the following values: 0: Request This message is called State Synchronization Request and used to request state corresponding to a particular mobile node. The State Synchronization Request is used to solicit the active state corresponding to a particular mobile node. 1: Reply The message is called State Synchronization Reply and is used between the home agents in the redundant home agent set to exchange binding cache information and any other information related to providing mobility service to the mobile nodes. The State Synchronization Reply can be sent by an active home agent Wakikawa (Editor) Expires January 18, 2008 [Page 14] Internet-Draft HA Reliability July 2007 either periodically or in response to a State Synchronization Request. Reserved 8-bit unsigned integer. It must be initialized to zero by the sender and must be ignored by the receiver. Identifier A 16-bit identifier to aid in matching state synchronization messages. 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. One of the following options is mandatory in State Synchronization Request message. : * IP Address Option (Sub-type: Home Address)[12]. If a home agent wants the Binding Cache information for a particular mobile node, it includes an IPv6 Address Option. * Mobile Network Prefix Option. If a home agent wants to know the forwarding state setup for a particular Mobile Network Prefix, it includes a Mobile Network Prefix Option as defined in [2]. * Vendor Specific Mobility Option. If a home agent wants vendor specific information, it can solicit with this option as defined in [7]. One of the following options is mandatory in State Synchronization Reply. : * Binding Cache Information Option * AAA Information Option * Vendor Specific Mobility Option This message requires at least one mobility option, therefore, there Wakikawa (Editor) Expires January 18, 2008 [Page 15] Internet-Draft HA Reliability July 2007 is no default length for this message. 6.1.2. Home Agent Control Message This message is used to control the status of a home agent to either active or standby. This message MUST be unicasted between home agents and MUST be authenticated and encrypted by IPsec ESP. The Home Agent Control 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Home Agent Control Message Type 8-bit unsigned integer. It can be assigned one of the following values: 0: SwitchOver Request This message is called SwitchOver Request. It is unicasted by a standby home agent that desires to become the active home agent. The receiver of the message MUST transition to standby state as soon as the message is received and validated successfully. 1: SwitchOver Reply This message is called SwitchOver Reply. It is used to acknowledge the receipt of the corresponding SwitchOver Request. Wakikawa (Editor) Expires January 18, 2008 [Page 16] Internet-Draft HA Reliability July 2007 2: SwitchBack Request This message is called SwitchBack Request. It is unicasted by an active home agent that desires to become the a standby home agent. The receiver of this message SHOULD transition to active state as soon as the message is received and validated successfully. 3: SwitchBack Reply This message is called SwitchBack Reply. It is used to acknowledge the receipt of the corresponding SwitchBack Request. Status 8-bit unsigned integer indicating the disposition of a Switchover Request or SwitchBack Request message. This field is only valid in SwitchOver Reply and SwitchBack Reply messages. The following Status values are defined: 0: Success 128: Reason unspecified 129: Administratively prohibited 130: Not active home agent (The receiver of the SwitchOver Request message is not the active home agent) 131: Not standby home agent (The receiver of the SwitchBack Request is already the active home agent) 132: Not in same redundant home agent set 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. No options are defined in this specification If no options are present in this message, no padding is necessary and the Header Len field will be set to 1. Wakikawa (Editor) Expires January 18, 2008 [Page 17] Internet-Draft HA Reliability July 2007 6.1.3. Home Agent Hello Message This messages can be replaced by other protocols as described in Section 7.10. If this message is used, it MUST be either unicasted or multicasted to carry home agent information among the redundant home agent set. The Hello message is defined for two purpose: 1) an alive check and 2) home agent information exchange. A home agent 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. In this case the redundant home agent set should be located in a secure network. Alternatively, all the home agents MUST have a secure channel with each other. 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|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: 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. Home Agent Preference 16-bit unsigned integer. The preference for the home agent sending this Hello message. This preference is the same as the Home Agent Preference value of the Home Agent Information option as defined in [1]. However, operators MAY use a different Wakikawa (Editor) Expires January 18, 2008 [Page 18] Internet-Draft HA Reliability July 2007 preference value for this operation. Home Agent Lifetime 16-bit unsigned integer. The lifetime for the home agent sending this Hello message. This lifetime is the same as the Home Agent Lifetime value of the Home Agent Information option as defined in [1]. Hello Interval 16-bit unsigned integer. The interval for the home agent sending this Hello message. 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 R flag If this flag is set, the receiver of this Hello message must send back a Hello message to the sender. Reserved 6-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. No valid options are defined in this specification. If no options are present in this message, 0 octets of padding are necessary and the Header Len field will be set to 2. Wakikawa (Editor) Expires January 18, 2008 [Page 19] Internet-Draft HA Reliability July 2007 6.1.4. Home Agent Switch Message This message is defined in Section 8.3. The Home Agent Reliability protocol extends this message for the Home Agent Hard Switch. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of Addresses |I| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . Home Agent Addresses . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Mobility options . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Home Agent Switch Message IPsec Re-key (I) The IPsec rekey (I) bit is set to indicate that the mobile node SHOULD start an IPsec re-key with the home agent specified in the Home Agent Addresses field. This flag is used when a failed home agent recovers and needs to re-establish IPsec SA/IKE state with a mobile node. Reserved The reserve field is reduced from 8 to 7 bits 6.2. New Mobility Options 6.2.1. IP address Option This option is already defined in the Fast Handovers for Mobile IPv6 (FMIP) specification [12]. This document introduces new Sub-Type values for home agent address and Home Address. Option-Code * 4: Home Agent Address Wakikawa (Editor) Expires January 18, 2008 [Page 20] Internet-Draft HA Reliability July 2007 * 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: 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 10: Binding Cache Information Option The Binding Cache Information option is only 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 Wakikawa (Editor) Expires January 18, 2008 [Page 21] Internet-Draft HA Reliability July 2007 mobile node or mobile router. The 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. 6.2.3. AAA Information Option The AAA option is used to carry the AAA state of the mobile node's Mobile IPv6 sessions. The AAA state information can be conveyed in RADIUS or Diameter AVP formats including the user and session info. This information option is only 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 11: 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 Mobile IPv6 and IPsec/ IKE session. Wakikawa (Editor) Expires January 18, 2008 [Page 22] Internet-Draft HA Reliability July 2007 7. Home Agent Operation 7.1. Home Agent Address Configuration Each standby home agent obtains its individual IPv6 address from its attached link. This IPv6 address is used by the home agent reliability protocol to exchange information with the associated home agents. The link between home agents should be secured. When the Home Agent Virtual Switch mode is used, the virtual home agent IPv6 address which is known by the mobile node is shared with the standby home agents. When a home agent fails, the standby home agent activates the IPv6 address of the failed home agent and becomes the active home agent. The standby home agent should not activate the IPv6 address until it knows the active home agent is no longer reachable at the address, otherwise address duplication will occur. To guarantee transparency of the home agent virtual switch to mobile nodes located on the home link, the neighbor cache of the home agent IP address MUST be carefully operated. See Section 7.2 in detail. When the Home Agent Hard Switch mode is used, each home agent configures itself with a different IPv6 address from the same home prefix. This IPv6 address can be used for the Home Agent Reliability protocol if the standby home agents are located at the same link of the active home agent (Figure 1). In case of Figure 2, the router must carefully route packets to the standby home agents as described in Section 7.2. Once a mobile node registers its binding with the active home agent, it may solicit an IPsec/IKE exchange with standby home agents. These packets must be routed to the recovery link. This can be achieved by installing host routes for the standby home agents on the recovery link of the router. 7.2. Consideration of Routing and Neighbor Discovery Protocol This section gives a brief explanation of how a home agent interacts with routing and Neighbor Discovery Protocol (NDP) when the Home Agent Virtual Switch mode is used. When a standby home agent becomes active in the Home Agent Virtual Switch mode, it MUST start to 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 operation is normally done using a route selector such as BGP or an OSPF modifier. For example, we can use the AS_Path prepend operation for BGP, and the Metric field in OSPF for route selection. For instance, home agents should run OSPF with the appropriate cost so that the active home agent whose preference is highest can receive Wakikawa (Editor) Expires January 18, 2008 [Page 23] Internet-Draft HA Reliability July 2007 the packets from the other routers on the home link. When the active home agent is down, OSPF detects the failure and can dynamically switch the route to the standby home Agent based on the OSPF cost value. If this cost conflicts with the home agent preference value due to misconfiguration, the routers on the home link may not route packets to the desired standby home agent. Therefore, the home agent MAY dynamically change the OSPF cost based on the home agent preference value. Most of router vendors have a private MIB to set the cost via SNMP, though this is a vendor-specific function. The operator can consider other existing approaches to update routes on the routers at the home link. When an active home agent activates a home agent address, it SHOULD use a virtual MAC address as introduced in [4]. When the active home agent is changed, the neighbor cache of the active home agent is not necessarily updated on mobile nodes located on the home link. Otherwise, the new home agent MUST update the neighbor cache entry for the home agent address on all the mobile nodes located on the home link. In addition, Mobile IPv6 uses proxy NDP to intercept packets meant for mobile nodes which are away from the home link. However, it is unnecessary for the new active home agent to overwrite the existing proxy neighbor entries of the mobile nodes. 7.3. Home Agent List Management In Mobile IPv6 [1], each home agent periodically sends router advertisements with a Home Address Information option [1] for exchanging home agent information when there are multiple home agents present on a link. This information is managed in a home agent list introduced in [1]. When the Home Agent Reliability Protocol is used, Hello messages are used to update the home agent list. There are several reasons to use Hello message instead of Router Advertisement on the Home Agent Reliability protocol: 1. Router Advertisements are sent among home agents and also to mobile nodes. When the Home Agent Virtual Switch is used, standby home agents MUST NOT generate unsolicited Router Advertisements. The standby home agents MUST be transparent to all mobile nodes. Hello messages are exchanged only with other home agents. 2. Router Solicitation and Advertisement messages [8] cannot be used due to link-local limitations. However, as shown in Section 5.1, standby home agents are not always configured on the same link. Router Advertisements cannot be used in this case. 3. The Home Agent Reliability protocol is required to exchange additional information such as Group ID and Active/Standby Status Wakikawa (Editor) Expires January 18, 2008 [Page 24] Internet-Draft HA Reliability July 2007 of the home agents. When Hello messages are used, the Home Agent Information Option [1] MAY NOT be used in Router Advertisements on the home link, because all necessary information will be present in the Hello messages. However, mobile nodes located on the home link require this information for home agent discovery. In addition, if operators want to use different parameters such as Preference value for home agents and mobile nodes, they can utilize both Router Advertisements and Hello messages. Router Advertisements are used to carry the home agent information for mobile nodes, and Hello message are used to carry information for Home Agent Reliability operation. If an operator decides not to use the Hello messages, Router Advertisements MUST be used to update the home agent list. Since Hello messages carry all the necessary information filled-in from the home agent list, the management of the home agent list is unchanged. If a standby home agent removes an active home agent from the list because its lifetime has become zero, it can start recovery according to this document. Section 7.4 describes failure detection in detail. 7.4. Detecting Home Agent Failure The active and standby home agents can monitor each other's status in multiple ways. One method is to reuse other failure detection mechanisms such as VRRP[4] and HSRP[5] described in Section 7.10. This document also defines its own method by using periodic exchanges of Hello messages to monitor status. The reasons to specify Hello messages are: 1. Hello messages can be sent off-link for global recovery is required by an operator. Router Advertisements cannot be used in this scenario since their scope is link-local. Thus, Hello messages are necessary to exchange home agent information among home agents in a globally redundant home agent set. 2. If Router Advertisements and VRRP are used for periodic messages, they may not detect the case where the system is running but the Mobile IPv6 stack is not operational. Mobile IPv6 may be implemented as a userland daemon, so if Hello messages are used, the failure of a home agent can be easily detected, assuming Hello message functionality is implemented in the same home agent daemon. 3. Hello messages can be frequently exchanged to detect failure, while there is a restriction on how often Router Advertisements can be sent, and on how they are processed by routers that Wakikawa (Editor) Expires January 18, 2008 [Page 25] Internet-Draft HA Reliability July 2007 receive them. Router Advertisements are also not sent frequently enough to rely on their absence to detect a home agent failure. A Hello request message (R-flag set) may be used by any home agent to request state information from any other home agent in the redundant home agent set. If a 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. The detail of the Hello message is described in Section 7.6. Failure events used in the Home Agent Reliability protocol are listed below. Loss of Communication with the Active Peer Home Agent In the event that a standby home agent does not receive any Hello message from its peer which is currently the active home agent for a configurable duration, the standby home agent may decide to become the active home agent. 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 sessions 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 a switch- over procedure upon detecting that the link to such a server has failed. Routing Peer/Link Failure In some cases, an operator may require 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 a switch- over procedure if the failure is fatal in nature, or due to some other routing policies. 7.5. Home Agent Switch Over After detecting the active home agent has failed, a standby home agent whose preference value is the highest MUST take over for the failed home agent. In the Home Agent Virtual Switch mode, the standby home agent MUST activate the virtual home agent address. If a virtual MAC address as introduced in [4] is used, the standby home agent MUST start using the virtual MAC address as well. Since all the necessary state has already been transferred to this standby home agent before the active home agent failed, it can immediately start acting as the active home Wakikawa (Editor) Expires January 18, 2008 [Page 26] Internet-Draft HA Reliability July 2007 agent. In the Home Agent Hard Switch mode, the standby home agent MUST send a Home Agent Switch message to all the mobile nodes that were registered at the failed home agent as described in Section 7.9, using the pre-established IPsec SA. The home agent switch-over is complete when it receives binding updates from all the mobile nodes. 7.6. Processing Hello Messages Hello messages can be unicasted or multicasted. A new multicast address will be assigned by the IANA. When all home agents in a redundant home agent set are configured on a same home link, they MUST join a new multicast address (TBA) and multicast Hello. On the other hand, if a home link is separated as described in Figure 2, each home agent MUST unicast Hello messages. 7.6.1. Requesting Hello Message A home agent can solicit a Hello message from a particular home agent in the same redundant home agent set by unicasting or multicasting a Hello message with the R-flag set. The sender MUST fill the fields of the Hello message with it's home agent information. When a Hello message is unicasted, only the destination of the Hello message will answer it. On the other hand, if a Hello message is multicasted, all the home agents in the multicast group will reply to the Hello message. This Hello request message SHOULD be generated when: o A new home agent needs to collect information of the other home agents in the same redundant home agent set. In this case it SHOULD multicast a Hello message in which the R-flag is set. o A home agent entry in the redundant home agent list is about to be removed due to home agent lifetime expiration. o A Hello message has not been received during the specified hello interval. 7.6.2. Sending Hello Message The Hello message MUST be sent when a home agent receives a Hello message with the R-flag set, indicating a request is required, otherwise Hello messages are periodically sent according to the pre- configured Hello interval. In addition, a home agent SHOULD send a Hello message to the home agents of the redundant home agent set when it boots up and its local information, such as home agent preference, home agent lifetime, and registration status, etc., change. When a new home agent boots up, it SHOULD solicit Hello messages by Wakikawa (Editor) Expires January 18, 2008 [Page 27] Internet-Draft HA Reliability July 2007 multicasting a Hello message with the R-flag set in parallel with sending its own Hello message. Whenever a home agent generates Hello message, it MUST increment in the Sequence Number by 1. The Sequence Number SHOULD be initialized to zero for the first Hello message. To accomplish sequence number rollover, if the sequence number has already been assigned to be the largest possible number representable as a 16-bit unsigned integer, then when it is incremented it will then have a value of zero (0). It MUST also specify its own Group ID in the Group ID field of the Hello message. If a home agent is the active home agent, it MUST set the A-flag in it's Hello Messages. In the Home Agent Hard Switch mode, the source address of Hello messages MUST be the configured home agent address. In the Home Agent Virtual Switch mode, the individual IPv6 addresses of each home agent MUST be used. 7.6.3. Receiving Hello Message When a home agent receives a Hello message, it SHOULD verify IPsec ESP protection. If the message is not protected, it SHOULD be silently discarded. However, if the Hello messages is sent on a dedicated link between the home agents, IPsec protection is not required. If a Hello message is sent from an IPv6 address whose scope is not global, the message MUST be silently discarded. If the sending home agent is not in the same redundant home agent set, the message MUST be silently ignored. This can be done by comparing the Group ID field of the received Hello message with its own Group ID value. Hello messages MUST NOT be sent to a home agent whose Group ID is different from the sender. If the Sequence Number value in the Hello message is equal to or less than the Sequence Number value stored in the home agent list entry, the Hello message MUST be discarded. Any Hello message satisfying all of these tests MUST be processed to update the redundant home agent list. The receiver copies home agent information in the Hello message to the corresponding redundant home agent list entry. The home agent address of the sender is retrieved from the Source Address field of the IPv6 header of the Hello message. If the home agent lifetime field in the Hello message is set to 0, the receiver removes the sender from the redundant home agents list. If the R-flag is set in the received Hello message, the receiver MUST reply with a Hello message to the originator as described in Section 7.6.2. Wakikawa (Editor) Expires January 18, 2008 [Page 28] Internet-Draft HA Reliability July 2007 7.7. Processing State Synchronization Messages It is necessary for standby home agents to synchronize the state information of each mobile node registered with the active home agent. In the Home Agent Virtual Switch mode, the synchronized state information is used by a standby home agent when it takes over for the failed home agent. In the Home Agent Hard Switch mode, the standby home agent starts the switch-over of all the mobile nodes registered to the failed home agent when the home agent failure is detected. Thus, the Binding Cache entry MUST be modified to keep the active home agent address of each mobile node. 7.7.1. Soliciting State of a Particular Mobile Node or Subset of Mobile Nodes When a standby home agent wants state information for a particular mobile node or a subset of mobile nodes, such as Binding Cache, AAA, etc., it MAY solicit this state by sending a State Synchronization message constructed as follows: o It MUST set the Type field to 0 (Request). o It MUST set a random value in the Identifier field that does not coincide with any other currently pending Requests. o It MUST include either a Home Address mobility option indicating the mobile node, or a Mobile Network Prefix mobility option indicating the mobile router. The standby home agent can send multiple home address and mobile network prefix mobility options to request state information for multiple mobile nodes in a single State Synchronization request message. When a home agent receives the State Synchronization message with the Type field set to 0 (Request), it MUST verify the message as follows: o The state synchronization message MUST be protected by IPsec ESP. o The sending home agent MUST belong to the same redundant home agent set o The receiver MUST be the active home agent for the requested home address or mobile network prefix. Any packet carrying a State Synchronization message which fails to satisfy all of these tests MUST be silently ignored. Otherwise, the receiver MUST reply with a State Synchronization message including state information for the requested mobile node(s) Wakikawa (Editor) Expires January 18, 2008 [Page 29] Internet-Draft HA Reliability July 2007 and/or mobile network prefix(es) as described in Section Section 7.7.2. 7.7.2. Synchronizing State of Mobile Nodes A state synchronization message can be sent either: o When an active home agent receives a state synchronization message in which the Type field is set to 0 (Request). o When an active home agent creates a binding cache entry for a particular mobile node. o When an active home agent deletes a binding cache entry for a particular mobile node. o When an active home agent updates a binding cache entry for a particular mobile node, only when operating in the Home Agent Virtual Switch mode. In the Home Agent Hard Switch mode, standby home agents only use this binding cache information to send a Home Agent Switch message, so only need a home address of all the mobile nodes registered to the active home agent of the same redundant home agent set. o In a periodic interval to update the state information for all sessions that changed since the last update. If an active home agent sends a State Synchronization message whenever the local state information changes, such as a binding cache change, the number of the State Synchronization messages sent can be quite large. The binding cache information of the requested mobile nodes is stored in the State Synchronization message. The active home agent MUST copy the binding cache information of the requested mobile nodes into Binding Cache Information options. If the State Synchronization message is sent in response to a State Synchronization request message, the active home agent MUST copy the Identifier field of the State Synchronization request message to the Identifier field in the State Synchronization reply message. Otherwise, it MUST set the Identifier field to 0. When the active home agent stores the state of multiple mobile nodes in a state synchronization message, a Binding Cache Information option is used as a separator. For each mobile node, a Binding Cache Information option is placed first, followed by any other options. When the next Binding Cache Information option is reached in the State Synchronization message, it indicates the information of a Wakikawa (Editor) Expires January 18, 2008 [Page 30] Internet-Draft HA Reliability July 2007 different mobile node. A State Synchronization message MUST be authenticated and encrypted by IPsec ESP mode, otherwise 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 does not belong to any home agent in the redundant home agent set, the message MUST be silently discarded. After successfully verifying the message, the receiving home agent MUST update its binding cache and all other necessary information such as AAA and vendor specific information in the particular database. In the Home Agent Hard Switch mode, the receiver MUST also record the IPv6 address of the sender (the active home agent). 7.8. Processing Home Agent Control Messages 7.8.1. Standby Home Agent becomes an Active Home Agent When a standby home agent decides to become an active home agent, the standby home agent sends a SwitchOver Request message (a Home Agent Control message in which the Type field is set to 0) to the active home agent. This message MUST be unicasted to the active home agent and MUST be encrypted and authenticated by IPsec ESP. The active home Agent MUST NOT generate this message. When an active home agent receives a SwitchOver Request, it first verifies the received Home Agent Control message. If the request message is not protected by IPsec, it MUST be silently discarded. If the home agent is not an active home agent, it MUST send a SwitchOver Reply message (a Home Agent Control message in which the Type field is set to 1) with the Status field set to 130 (Not active home agent). If the receiver is an active home agent and does not want this standby home agent to become the active home agent, it MUST reply a SwitchOver reply with the Status field set to 129 (Administratively prohibited). In addition, if the sending home agent does not belong to the same redundant home agent set, a SwitchOver Reply message MUST be sent to the sender with the Status field set to 132 (Not in same redundant home agent set). Otherwise, the active home agent MUST become a standby home agent and reply with a SwitchOver Reply message with the Status field set to 0 (Success). If a home agent receives a SwitchOver Reply message, it MUST be protected by IPsec ESP. Otherwise, the message MUST be silently discarded. If the receiving home agent did not send a SwitchOver Request message, the message MUST be silently ignored. If the Status field of the SwitchOver Reply message is 0 (Success), the receiving standby home agent immediately becomes an active home agent. If the value in the Status field is greater than 128 an error has occurred. Wakikawa (Editor) Expires January 18, 2008 [Page 31] Internet-Draft HA Reliability July 2007 In this case, the receiver MUST NOT become an active home agent. 7.8.2. Active Home Agent becomes in-active When an active home agent decides to become an in-active home agent, it sends a SwitchBack Request message (i.e. a Home Agent Control message with Type field set to 3) to a standby home agent. The reason for the active home agent to send this message can be administrative intervention, and events like Monitored Server Failure by the active home agent or Routing Peer/Link Failure. This message MUST be unicasted to one of the standby home agents and MUST be encrypted and authenticated by IPsec ESP. A standby home agent MUST NOT generate this message. A SwitchBack Reply is sent in reply to a SwitchBack Request message. When a home agent receives a SwitchBack Request message, it first verifies the message. If the SwitchBack Request message is not protected by IPsec ESP, it MUST be silently discarded. If the sending home agent of the SwitchBack Request message is not an active home agent, the receiver MUST reply with a SwitchBack Reply (a Home Agent Control message in which the Type field is set to 4) in which the Status field is set to 130 (Not active home agent). If the sending home agent does not belong to the same redundant home agent set, a SwitchBack Reply message MUST be sent in which the Status field set to 132 (Not in same redundant home agent set). Otherwise, the receiving home agent MUST send a SwitchBack Reply message in which the Status field is set to 0 (Success). After sending the SwitchBack reply, it MUST NOT become an active home agent immediately. This is because the active home agent is still active until it receives the SwitchBack Reply message acknowledging the SwitchBack Request. The standby home agent SHOULD change to active at least after LINK_TRAVERSAL_TIME. If a home agent receives a SwitchBack Reply message, it MUST be protected by IPsec ESP, otherwise the message MUST be silently discarded. If the receiving home agent did not send a SwitchBack Request message beforehand, the message MUST be silently discarded. If the Status field of the SwitchBack Reply message is 0 (Success), the receiving home agent immediately becomes an in-active home agent. If the value in the Status field is greater than 128, an error has occurred. In this case, the receiver cannot become an in-active home agent and MUST continue to be an active home agent. 7.9. Sending Home Agent Switch Messages This operation is valid only for the Home Agent Hard Switch mode. The standby home agent MUST send a Home Agent Switch message as defined in [11] to all the mobile nodes that were being served by the Wakikawa (Editor) Expires January 18, 2008 [Page 32] Internet-Draft HA Reliability July 2007 failed home agent. Since the active home agent address is recorded in each synchronized binding cache, the standby home agent knows which mobile nodes were served by the failed home agent. The Home Agent Switch message must be encrypted with a pre-established SA. The standby home agent should include its own IPv6 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 is a large number of mobile nodes, sending Home Agent Switch messages will cause a lot of signaling overhead on the network. When a failed home agent recovers, it MUST re-establish an IPsec SA with each mobile node served by its redundant home agent set. Otherwise, it cannot be either a standby or active home agent for the mobile nodes. Therefore, it sends a Home Agent Switch message with the I-flag set to all the mobile nodes serving by other home agents in the same redundant home agent set, and includes its own home agent address in the Home Agent Addresses field. 7.10. Interworking with VRRP VRRP and HSRP specify an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. This operation is similar to the Home Agent Virtual Switch operation. For example, the VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. Although VRRP is used to guarantee home agent address reachability, it cannot be used for state synchronization and explicit switching of Master and Backup. Thus, the Home Agent Reliability protocol cannot be replaced by VRRP. This section explains how VRRP can interwork with the Home Agent Reliability protocol. When VRRP is available, VRRP can replace the Hello message described in Section 6.1.3. However, some of information is missed by using VRRP. After receiving a VRRP message, each home agent SHOULD process the message and store the information as if it receives Home Agent Hello messages Section 7.6.3. The Home Agents SHOULD still perform binding cache synchronization as described in Section 7.7 and SHOULD support the Home Agent Switch message as described in Section 7.9. In addition to this, VRRP is useful only if all home agents are located on the same link. If the home agents are topologically separated, the Home Agent Reliability protocol MUST be used. Wakikawa (Editor) Expires January 18, 2008 [Page 33] Internet-Draft HA Reliability 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(rsvd) | Adver Int | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Address(es) | + + + + + + + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: VRRP Packet Format The message format of VRRP is described in Figure 12. Each field is mapped as follows: Virtual Rtr ID Group ID is stored in the Virtual Rtr ID field. Priority Home Agent Preference is stored in the Priority field. Note that VRRP only has 8 bits for the Priority field. Therefore, values larger than 255 MUST NOT be assigned to the preference value. Count IPv6 IPv6 Addr This field MUST be always be 1. Advert Int This field MUST be mapped to the Hello Interval field of the Home Agent Hello message, though it only has 12 bytes. Wakikawa (Editor) Expires January 18, 2008 [Page 34] Internet-Draft HA Reliability July 2007 IPv6 address A home agent address is stored in this field. Home Agent Lifetime, Sequence Number and Flags field are missing in the VRRP packet format. Therefore, operators SHOULD use the same statically configured value for Home Agent Lifetime. Each home agent does not check freshness of received VRRP message because of no sequence number. If VRRP is used, a home agent cannot determine the active home agent from the VRRP message due to lack of A flag, and cannot request a VRRP advertisement to other home agents. 7.11. Retransmissions and Rate Limiting Standby and active home agents are responsible for retransmissions and rate limiting of a State Synchronization Request, Switchover Request, SwitchBack Request messages for which they expect a response. The home agent MUST determine a value for the initial transmission timer: o If the home agent sends a State Synchronization Request message, it SHOULD use an initial retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER. o If a standby home agent sends a Switchover Request message, it SHOULD use an initial retransmission interval of INITIAL_SWICHOVER_REQ_TIMER. o If an active home agent sends a SwitchBack Request message, it SHOULD use an initial retransmission interval of INITIAL_SWICHBACK_REQ_TIMER . If the sending home agent fails to receive a valid matching response within the selected initial retransmission interval, it SHOULD retransmit the message until a response is received. All of the above constants are specified in Section 10. The retransmission MUST use an exponential backoff process as described in [1] until either the home agent receives a response, or the timeout period reaches the value MAC_HARELIABILITY_TIMEOUT (16sec). The home agent SHOULD use a separate back-off process for different message types and different destinations. The rate limiting of Mobility Header messages is the same as one in [1]. A home agent MUST NOT send Mobility Header Messages to a particular home agent more than MAX_UPDATE_RATE (3) times a second, which is specified in [1]. Wakikawa (Editor) Expires January 18, 2008 [Page 35] Internet-Draft HA Reliability July 2007 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 these operations can be skipped. 8.1. Home Agent Addresses Discovery To provide home agent reliability with the Home Agent Hard Switch mode, a mobile node authenticates itself to two or more home agents and creates IPsec SAs with them during bootstrapping. When one home agent fails, another home agent can use the pre-existing SA to notify the mobile node about the failure. Multiple home agent addresses are available in a home network. In order to discover these home agent addresses, two different mechanisms are defined in the bootstrapping solution in the split scenario [13]. One is DNS lookup by home agent Name, the other is DNS lookup by Service Name. DHCPv6 can also be used in the integrated scenario [14] to provide home agent provisioning to mobile nodes. In the split scenario, a mobile node can use DNS lookup by Service Name to discover the home agents, as defined in [13]. For example, if home agent reliability is required by a mobile node, DNS lookup by Service Name method is recommended for the mobile node to discover multiple home agents addresses. Therefore, mobile nodes will query the DNS SRV records with a service name of mip6 and protocol name of ipv6. The DNS SRV records includes multiple home agent addresses and different preference values and weights. The mobile node SHOULD choose two or more home agents from the home agents list according to their preference value. Then the mobile node should authenticate itself to these home agents via an IKEv2 exchange. In the integrated scenario, a mobile node can use DHCPv6 to get home agent provisioning from an MSP or ASP, as already defined in [14]. The only requirement is that the DHCPv6 response must include multiple home agents' information in order to support home agent reliability. 8.2. IKE/IPsec pre-establishment to Home Agents After a mobile node gets multiple home agent addresses, it needs to trigger multiple IKE exchanges with theh 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 complete. Wakikawa (Editor) Expires January 18, 2008 [Page 36] Internet-Draft HA Reliability July 2007 The mobile node MUST follow the standard IKEv2 exchange in the bootstrapping solution of the split scenario [13], or the IKEv1 bootstrapping solution [15]. Home Address configuration maybe also be included, if necessary, for the first IKE exchange. After its Home Address is assigned or approved by the first home agent, mobile node SHOULD register itself with the second home agent with IKE using the same Home Address. Therefore, no home address configuration should be used in the second IKEv2 procedure. Note that the mobile node only sends a Binding Update message to the first home agent. 8.3. Receiving Home Agent Switch message A mobile node must follow the operation specified in [11] when it receives a Home Agent Switch message. If the I-flag is set in the received Home Agent Switch message, the mobile node MUST re-key the SA with the home agent addresses stored in the Home Agent Addresses field. The mobile node MUST NOT change its active home agent when the I-flag is set. If the home agent address is not known from the bootstrapping described in Section 8.1, the mobile node MUST NOT start an IKE session with the unknown home agent. Instead, it SHOULD re-start home agent discovery again to update its home agent address information. When the mobile node receives a Home Agent Switch message without I-flag set, and if the message contains the IPv6 address of a standby home agent, it SHOULD pick the standby home agent in the switch message as the active home agent and send a Binding Update message to it. The mobile node already has a pre-established SA with the home agent and should use that SA to send the Binding Update. Wakikawa (Editor) Expires January 18, 2008 [Page 37] Internet-Draft HA Reliability July 2007 9. Security Considerations Since Mobile IPv6 operation requires ESP in transport mode between the mobile node and the home agent, we will discuss the ESP field synchronization issues between the mobile node and the redundant set of home agents. This synchronization is required only for Home Agent Virtual Switch mode. Most of fields should be synchronized based on RFC4301 [9]. The ESP header has the following fields: SPI This field identifies the SAD at the receiver. The mobile node negotiates only one IPsec SA. Hence, the SPI value will remain unchanged upon home agent failover. 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. 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. As described in Section 4, the SA1, SA2, SA3, SA4 could be synchronized between the home agents as these messages are not sent continuously. Moreover for the Binding Update case, if the mobile node is in the middle of sending a Binding Update to an active home agent for a binding refresh, and the active home agent is not available at that moment, the mobile node will not get any response from the active home agent. After a standby home agent becomes active, the mobile node will retry and it will receive the Binding Update from the mobile node with a sequence number that is +n from its last known sequence number for SA1. For the Binding Acknowledgement 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 the 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 Mobile IPv6 signaling is only needed to cover the corner cases when Binding Update or HoTi is in-flight and the active home agent fails. Wakikawa (Editor) Expires January 18, 2008 [Page 38] Internet-Draft HA Reliability July 2007 The technique explained above should work 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 the Initialization Vector will be delivered in each exchange between a mobile node and home agent, this field is not necessarily synchronized between home agents. Others Other fields should be synchronized based on RFC4301[9] In the Home Agent Hard Switch mode, the standby home agent needs to send a Home Agent Switch message using IPsec encryption. Since the mobile node has pre-established an IPsec SA with both the active and standby home agents, the standby home agent can send the message to the mobile node with the pre-established IPsec SA. Wakikawa (Editor) Expires January 18, 2008 [Page 39] Internet-Draft HA Reliability July 2007 10. Protocol Constants INITIAL_STATE_SYNC_REQ_TIMER: 3sec INITIAL_SWICHOVER_REQ_TIMER: 1sec INITIAL_SWICHBACK_REQ_TIMER 1sec LINK_TRAVERSAL_TIME 150msec Wakikawa (Editor) Expires January 18, 2008 [Page 40] Internet-Draft HA Reliability July 2007 11. Contributors This document is a result of discussions in the Mobile IPv6 Home Agent Reliability Design Team. The members of the design team that are listed below are authors that have contributed to this document: Samita Chakrabarti samita.chakrabarti@azairenet.com Kuntal Chowdhury kchowdhury@starentnetworks.com Hui Deng hdeng@hitachi.cn Vijay Devarapalli vijay.devarapalli@azairenet.com Sri Gundavelli sgundave@cisco.com Brian Haley brian.haley@hp.com Behcet Sarikaya bsarikaya@huawei.com Ryuji Wakikawa ryuji@sfc.wide.ad.jp 12. Acknowledgements This document includes a lot of text from [16] and [17]. Therefore the authors of these two documents are acknowledged. We would also like to thank the authors of the home agent reliability problem statement [18] for describing the problem succinctly and Alice Qin for her work on the hello protocol. Wakikawa (Editor) Expires January 18, 2008 [Page 41] Internet-Draft HA Reliability July 2007 13. References 13.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] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004. [5] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby Router Protocol (HSRP)", RFC 2281, March 1998. [6] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [7] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", draft-ietf-mip6-vsm-00 (work in progress), December 2006. [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [9] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 13.2. Informative References [10] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [11] Haley, B., "Mobility Header Home Agent Switch Message", draft-ietf-mip6-ha-switch-01 (work in progress), June 2006. [12] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-02 (work in progress), March 2006. Wakikawa (Editor) Expires January 18, 2008 [Page 42] Internet-Draft HA Reliability July 2007 [14] 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. [15] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6 Bootstrapping with IKEv1", draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress), March 2006. [16] Wakikawa, R., "Inter Home Agents Protocol Specification", draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), March 2006. [17] Devarapalli, V., "Local HA to HA protocol", draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), March 2006. [18] Faizan, J., "Problem Statement: Home Agent Reliability", draft-jfaizan-mipv6-ha-reliability-01 (work in progress), February 2004. Wakikawa (Editor) Expires January 18, 2008 [Page 43] Internet-Draft HA Reliability July 2007 Appendix A. Change Log From Previous Versions Changes from draft-ietf-mip6-hareliability-00 o comment (see mail at 2007 June 20) from Wesley Eddy, Verizon Federal Network Systems Author's Address Ryuji Wakikawa (Editor) Keio University Department of Environmental Information, Keio University. 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81-466-49-1100 Fax: +81-466-49-1395 Email: ryuji@sfc.wide.ad.jp URI: http://www.wakikawa.org/ Wakikawa (Editor) Expires January 18, 2008 [Page 44] Internet-Draft HA Reliability 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). Wakikawa (Editor) Expires January 18, 2008 [Page 45]