idnits 2.17.1 draft-ietf-mip6-hareliability-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1879. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 17, 2007) is 6127 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3768 (ref. '4') (Obsoleted by RFC 5798) ** Downref: Normative reference to an Informational RFC: RFC 2281 (ref. '5') == Outdated reference: A later version (-03) exists of draft-ietf-mip6-vsm-00 ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-ha-switch-01 -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '12') (Obsoleted by RFC 5268) == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-02 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-00 == Outdated reference: A later version (-02) exists of draft-devarapalli-mip6-ikev1-bootstrap-01 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group R. Wakikawa (Editor) 3 Internet-Draft Keio University 4 Intended status: Standards Track July 17, 2007 5 Expires: January 18, 2008 7 Home Agent Reliability Protocol 8 draft-ietf-mip6-hareliability-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 18, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The home agent can be a single point of failure when Mobile IPv6 is 42 used in a system. It is critical to provide home agent reliability 43 in the event of a home agent crashing or becoming unavailable. This 44 would allow another home agent to take over and continue providing 45 service to the mobile nodes. This document describes the problem 46 scope briefly and provides a mechanism of home agent failure 47 detection, home agent state transfer, and home agent switching for 48 home agent redundancy and reliability. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Problem Statement and Requirements . . . . . . . . . . . . . . 6 58 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Home Agent Network Configuration . . . . . . . . . . . . . 10 62 5.2. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 11 63 5.3. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 12 64 5.4. Active Home Agent Management . . . . . . . . . . . . . . . 13 66 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 14 68 6.1.1. State Synchronization Message . . . . . . . . . . . . 14 69 6.1.2. Home Agent Control Message . . . . . . . . . . . . . . 16 70 6.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 18 71 6.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 20 72 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 20 73 6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 20 74 6.2.2. Binding Cache Information Option . . . . . . . . . . . 21 75 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 22 77 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 23 78 7.1. Home Agent Address Configuration . . . . . . . . . . . . . 23 79 7.2. Consideration of Routing and Neighbor Discovery 80 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 7.3. Home Agent List Management . . . . . . . . . . . . . . . . 24 82 7.4. Detecting Home Agent Failure . . . . . . . . . . . . . . . 25 83 7.5. Home Agent Switch Over . . . . . . . . . . . . . . . . . . 26 84 7.6. Processing Hello Messages . . . . . . . . . . . . . . . . 27 85 7.6.1. Requesting Hello Message . . . . . . . . . . . . . . . 27 86 7.6.2. Sending Hello Message . . . . . . . . . . . . . . . . 27 87 7.6.3. Receiving Hello Message . . . . . . . . . . . . . . . 28 88 7.7. Processing State Synchronization Messages . . . . . . . . 29 89 7.7.1. Soliciting State of a Particular Mobile Node or 90 Subset of Mobile Nodes . . . . . . . . . . . . . . . . 29 91 7.7.2. Synchronizing State of Mobile Nodes . . . . . . . . . 30 92 7.8. Processing Home Agent Control Messages . . . . . . . . . . 31 93 7.8.1. Standby Home Agent becomes an Active Home Agent . . . 31 94 7.8.2. Active Home Agent becomes in-active . . . . . . . . . 32 95 7.9. Sending Home Agent Switch Messages . . . . . . . . . . . . 32 96 7.10. Interworking with VRRP . . . . . . . . . . . . . . . . . . 33 97 7.11. Retransmissions and Rate Limiting . . . . . . . . . . . . 35 99 8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 36 100 8.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 36 101 8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 36 102 8.3. Receiving Home Agent Switch message . . . . . . . . . . . 37 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 106 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40 108 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41 110 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 112 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 113 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 114 13.2. Informative References . . . . . . . . . . . . . . . . . . 42 116 Appendix A. Change Log From Previous Versions . . . . . . . . . . 44 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 119 Intellectual Property and Copyright Statements . . . . . . . . . . 45 121 1. Introduction 123 In Mobile IPv6 [1] and NEMO Basic Support[2], mobile nodes may use a 124 bi-directional tunnel with their home agents for all traffic with 125 correspondent nodes. A home agent on the home link maintains a 126 binding cache entry for each mobile node and uses the binding cache 127 entry to route any traffic meant for the mobile node or the mobile 128 network. If the mobile node is not on the home link and does not 129 have a binding cache entry at the home agent, it is neither reachable 130 at its home address nor able to setup new sessions with its home 131 address. If a home agent loses the binding cache state, due to 132 failure or some other reason, it results in a loss of service for the 133 mobile nodes. 135 It is beneficial to provide high availability and redundancy for a 136 home agent so that mobile nodes can avail of uninterrupted service 137 even when one home agent crashes or loses state. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [3]. 145 In this document, the term mobile node refers to both a mobile node 146 [1] and a mobile router [2]. 148 Some of the mobility related terms used in this document are defined 149 in [1] and [10]. In addition or in replacement of these, the 150 following terms are defined or redefined: 152 Active Home Agent 154 A home agent that is currently serving the mobile nodes. 156 Standby Home Agent 158 A home agent which will serve the mobile nodes when the active 159 home agent fails. 161 Failed Home Agent 163 A home agent that is not available due to hardware or software 164 failure, system maintenance, etc. 166 Redundant Home Agent Set 168 A group of active and standby home agent(s). The Group Identifier 169 is used to identify a redundant home agent set. The Group ID is 170 exchanged by Hello messages. 172 Binding Synchronization 174 Synchronization of binding cache entries within the redundant home 175 agent set. 177 Home Agent Preference 179 This preference value is defined for Duplicate Home Agent Address 180 Discovery (DHAAD) in RFC3775. This protocol uses this preference 181 value for home agent selection when an active home agent has 182 failed. However, an operator can also define an independent value 183 used only for the home agent reliability protocol if the operator 184 wants to have different preference values for DHAAD and the home 185 agent reliability protocol. A home agent SHOULD NOT use the same 186 preference value as other home agents for this protocol. 188 3. Problem Statement and Requirements 190 In Mobile IPv6 [1], a mobile node registers and establishes a binding 191 with only one home agent. Thus the home agent represents the 192 possibility of a single point of failure for Mobile IPv6. A home 193 agent may be responsible for multiple mobile nodes on the home link. 194 The failure of the home agent may then result in the loss of 195 connectivity for numerous mobile nodes located throughout the 196 Internet. To overcome this problem, Mobile IPv6 allows deployment of 197 multiple home agents on the home link so that upon the failure of a 198 home agent, a mobile node can re-establish its connection through a 199 new home agent. However, the base Mobile IPv6 specification does not 200 address home agent failover and dynamic transfer of service from one 201 home agent to another. This transfer of service from the failed home 202 agent to a new working home agent requires coordination or pre- 203 configuration among the home agents regarding security associations, 204 transfer of mobile node bindings, and other service information for 205 reliable Mobile IPv6 service in a deployment scenario. 207 For the home agent reliability solution, we define the following 208 requirements: 210 Reliable Home agent service 212 Multiple home agents are available for a home prefix and one of 213 them actively serves the mobile nodes. A standby home agent takes 214 over when the active home agent becomes unavailable. The transfer 215 of the MN-HA association should be transparent to applications and 216 should not take longer than the care-of-addresses update procedure 217 described in Mobile IPv6 [1]. 219 Availability of a redundant home agent set 221 Availability of an active home agent address and a standby home 222 agent address at the bootstrapping period for the mobile node is 223 assumed. 225 State Synchronization 227 The information for mobile nodes must be able to be synchronized 228 between an active home agent and standby home agents. This 229 includes the Binding Cache, AAA information, other Mobile IPv6 and 230 NEMO related information. 232 Consideration of IPsec/IKE transfer 233 An active home agent maintains several IPsec and IKE states for 234 mobile nodes. These states are synchronized within the redundant 235 home agent set. The details are described in Section 9. 237 Secured Message Exchanges 239 The messages used between the home agents to transfer binding 240 cache information MAY be authenticated and encrypted. 242 Failure Detection 244 Redundant home agents must actively check for possible failure of 245 an active home agent. If a home agent supports an existing 246 failure detection mechanism such as VRRP[4] or HSRP[5], it can re- 247 use that mechanism to detect the home agent failure. On the other 248 hand, periodic Hello messages are introduced to detect active home 249 agent's service availability in this document. 251 Failure Notification 253 If necessary, a mobile node is notified about the active home 254 agent failure by the standby home agent. 256 4. Protocol Design 258 Mobile IPv6 depends on IPsec and IKE for home binding registration as 259 described in [6]. A mobile node must encrypt a Binding Update sent 260 to a home agent. In addition, the mobile node exchanges HoTI and HoT 261 messages through the home agent by using IPsec tunnel mode. 262 Therefore, before home agent failure, these IPsec states should be 263 synchronized among home agents of a redundant home agent set. A 264 mobile node may also encrypt particular data traffic sent to nodes in 265 the Internet. IPsec information required by Mobile IPv6 is listed 266 below. 268 o Security Policy Database (SPD) and Selector Information 270 o Security Association (SA) for Binding Registration (SA1 and SA2) 272 o SA for HoTI/HoT Exchange (SA3 and SA4) 274 o SA for Mobile Prefix Discovery (SA5 and SA6) 276 o SA for data packets if any (SA7 and SA8) 278 There are various ways this can be achieved. One is to setup 279 multiple IPsec security associations between the mobile node and the 280 home agent sets. Another is to have the home agents periodically 281 check-point IPsec session state, including the per packet sequence 282 numbers, for the mobile node. Thus, we define two possible home 283 agent redundancy modes as follows: 285 Home Agent Virtual Switch 287 Each mobile node negotiates just one SA with an active home agent 288 in a redundant home agent set. The IPsec state will be shared 289 within the redundant home agent set in the background. The active 290 and the redundant home agents are addressed by the same home agent 291 address, although only the active home agent is accessible by the 292 home agent address all of the time. IPsec/IKE states must be 293 synchronized between the active and standby home agents. The 294 mechanism used to synchronize IPsec state is considered out of 295 scope for this document. In case there is a failure of the active 296 home agent, the standby home agent takes over without the mobile 297 node being aware of the change in the home agent. 299 In a redundant home agent set, a single home agent address is used 300 by the active home agent. Thus, all the mobile nodes served by a 301 redundant home agent set MUST associate with the same home agent 302 (the active home agent) all the time. 304 Home Agent Hard Switch 306 The home agents are addressed by different IP addresses and the 307 mobile node is aware of the change of home agent. A Mobile node 308 and all home agents in a redundant home agent set negotiate 309 independent IPsec SAs. This mode is especially useful when the 310 IPsec/IKE states cannot be synchronized. However, the home agent 311 change is not transparent to the mobile node. When an active home 312 agent fails, a mobile node will receive a notification (a Home 313 Agent Switch message [11]) from a standby home agent, and send a 314 Binding Update to the standby home agent. In order to exchange 315 the Home Agent Switch message securely between the standby home 316 agent and a mobile node, the mobile node needs to establish an 317 IPsec SA with both the active and the standby home agents in the 318 redundant home agent set beforehand. 320 Since each home agent has a different address, an active home 321 agent can be defined for each mobile node. When a mobile node 322 boots, it will discover home agents and create IPsec SAs with 323 them. It will then decide which one of the home agents is its 324 active home agent. For example, when two home agents serve a home 325 network, half of the mobile nodes might register with one home 326 agent and the rest of mobile nodes with another home agent. When 327 one of the home agents fails, a standby home agent, whose 328 preference value is next highest than the failed home agent, can 329 trigger a home agent switch by sending a Home Agent Switch message 330 to the mobile nodes that were registered with the failed home 331 agent. 333 In both the cases, the mobile node maintains only one home binding at 334 any given time. In the Home Agent Hard Switch mode, the mobile node 335 needs to switch its binding from the active to standby home agent 336 upon failover. The bindings are synchronized among home agents in 337 the redundant home agent set in the background when the Home Agent 338 Virtual Switch mode is used. 340 All new messages defined in this document are defined as Mobility 341 Header messages so that the Home Agent Reliability protocol can be 342 extended to provide home link redundancy. 344 Finally, the reasons why we defined a new Hello message instead of 345 using VRRP is described in Section 7.3 and Section 7.4. We also give 346 instructions on how operators can run both VRRP and the Home Agent 347 Reliability protocol at the same time in Section 7.10. 349 5. Protocol Overview 351 5.1. Home Agent Network Configuration 353 The Home Agent Reliability protocol supports two different 354 configurations for standby home agents. Standby home agents can be 355 placed on the same home link as the active home agent, or on a 356 different link. The Global Recovery described below is not included 357 in this document, although the Home Agent Reliability protocol can 358 support this with slight modifications to home agent operations. 360 HA1 HA2 HA3 HA4 .... HAn 361 | | | | | 362 --------+------+------+------+--------+--------- 363 Home Link 365 Figure 1: Local Recovery Configuration 367 Figure 1 depicts the configuration where home agents serving the same 368 home network are located on the same link. For example, HA2, HA3 and 369 HA4 are standby home agents of HA1. This is the same as what Mobile 370 IPv6 defines for home agent configuration. 372 ---------IGP------>|<---BGP--->|<-----IGP--------- 374 HA1 HA2 HA3 HA4 375 | | | | 376 --------+------+-----+ R---R---R +-----+------+------- 377 Home Link Routers Recovery Link 379 Figure 2: Global Recovery Configuration 381 Figure 2 illustrates when standby home agents are located on a 382 different link (named the recovery link in Figure 2). HA3 and HA4 383 are standby home agents of HA1 and HA2. In this case, HA3 and HA4 384 cannot receive packets meant for the home network until the route on 385 the Routers is changed. The advantage of this configuration is that 386 standby home agents can recover from a failure of the home link. 387 This configuration can achieve home agent recovery even if the entire 388 home link fails. In this configuration, the routing must be also 389 updated to direct the packets meant for the home link to the recovery 390 link. 392 This geographic redundancy is not a requirement by most SDOs 393 (Standards Development Organization), but is required by operators. 394 Most large operators have a very stringent requirement on network 395 availability even in the worst type of disaster or outage. For 396 example, critical nodes in region-1 are backed up by nodes in 397 region-2. These two regions are geographically separated. If 398 region-1 suffers a downtime due to any reason, all the sessions will 399 be seamlessly taken over by the nodes in region-2. This is called 400 geographic redundancy. This is a well-known configuration for 401 Telecommunications operators. 403 5.2. Home Agent Virtual Switch 405 A mobile node remains unaware about the change in the active home 406 agent since the home agents have replicated all session state 407 including the IPsec/IKE/ESP states. The IPsec/IKE/ESP state transfer 408 is out of scope of this document. 410 MN HA1(active) HA2(Standby) 411 | | . 412 |<--------->| | 1. IKE exchange (with HoA assignment) 413 |---------->| . 2. Binding Update 414 |<----------| . 3. Binding Acknowledgment 415 | | . 416 | |<--------->. 4. State exchanges (binding cache/IPsec) 417 | | . 418 | X . HA1 FAILURE 419 | X . 420 | X<----------. 5. Failure Detection 421 | X | 6. HA2 takes over the HA1 422 | X | 423 | X | RECOVERY COMPLETE 425 Figure 3: Overview of Home Agent Virtual Switch 427 The operations of the Home Agent Virtual Switch mode are shown in 428 Figure 3. The mobile node first attempts the IKE exchange for 429 Security Association (SA) setup and home address assignment (1). 430 After binding registration is done (2, 3), the active home agent 431 pushes all the states of its mobile nodes with a state 432 synchronization message (4). The standby home agent(s) is not active 433 unless it takes over from a failed home Agent. 435 When the active home agent's failure is detected (5), the standby 436 home agent activates the IP address of the failed home agent on it 437 and takes over for the failed home agent. All the home agents in the 438 redundant home agent set share a virtual home agent address and the 439 routing will ensure only the active home agent will be reachable 440 using that virtual home agent address. The standby home agent can 441 serve all the mobile nodes for which the states are synchronized, 442 without any further message exchange, because it has all the 443 necessary information which it obtained from the failed home agent. 445 5.3. Home Agent Hard Switch 447 The overview of the Home Agent Hard Switch is shown in Figure 4. 448 This mode is not transparent to the mobile node when the active home 449 agent failure occurs. 451 MN HA1(active) HA2(Standby) 452 | | | 453 |<--------->| | 1. IKE exchange (with HoA assignment) 454 |---------->| | 2. Binding Update 455 |<----------| | 3. Binding Acknowledgment 456 |<--------------------->| 4. IKE exchange (without HoA assignment) 457 | | | 458 | |<--------->. 5. State exchanges (binding cache) 459 | | | 460 | X | HA1 FAILURE 461 | X | 462 | X<----------| 6. Failure Detection 463 |<----------------------| 7. Sending Home Agent 464 | X | Switch message 465 |<--------------------->| 8. Binding Registration 466 | X | 467 | X | RECOVERY COMPLETE 469 Figure 4: Overview of Home Agent Hard Switch 471 The mobile node establishes IPsec/IKE state with all the home agents 472 in the redundant home agent set beforehand (1 and 4), however it 473 registers its binding only with the active home agent (2 and 3). 474 When an active home agent fails, a standby home agent uses a pre- 475 existing IPsec SA to notify the mobile node about the failure by 476 securely sending a Home Agent Switch message. In order to discover 477 home agent addresses, two different mechanisms are defined, as 478 described in Section 8.1. The active home agent synchronizes the 479 required states of the mobile nodes, such as Binding Cache and AAA 480 information, with other standby home agents periodically (5). The 481 mobile node MUST NOT request a home address(es) assignment through 482 the IKE exchange to the standby home agent when it establishes an SA 483 with it (4). 485 When the standby home agent detects the failure of the active home 486 agent (6), it sends a Home Agent Switch message to all the mobile 487 nodes that were registered with the failed home agent (7). The Home 488 Agent Switch message must be encrypted by a pre-established IPsec SA. 489 After the switch message, the mobile node MUST send a binding update 490 to the new active home agent in order to update the Mobile IPv6 491 tunnel end points (8). 493 5.4. Active Home Agent Management 495 HA1(active) HA2 HA3 .. HAn 496 | | | | 497 |------->| | | 1. HA1 sends SwitchBack Request 498 |<-------| | | 2. HA2 sends SwitchBack Reply 499 | | | | 500 (standby) (active) | | HA2 BECOMES ACTIVE HA 501 | | | | 502 SYSTEM MAINTENANCE, ETC. 503 | | | | 504 |------->| | | 3. HA1 sends SwitchOver Request 505 |<-------| | | 4. HA2 sends SwitchOver Reply 506 | | | | 507 (active) (standby) | | 5. HA1 returns to active HA 508 | | | | HA1 BECOMES ACTIVE AGAIN 510 Figure 5: Manual Home Agent Change 512 In some scenarios the active home agent may need to stop serving 513 mobile nodes for system maintenance. This specification provides for 514 a manual home agent switch by using SwitchBack Request and Reply 515 messages. As shown in Figure 5, the active home agent (HA1) sends a 516 SwitchBack Request message to a standby home agent (HA2). As soon as 517 HA2 receives the message, it becomes the active home agent. HA2 will 518 acknowledge the message by sending a SwitchBack Reply message to HA1. 519 HA1 becomes a standby home agent when it receives the SwitchBack 520 Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in 521 order to become the active home agent again. 523 6. Messages 525 6.1. New Mobility Header Messages 527 6.1.1. State Synchronization Message 529 This message is used to exchange state corresponding to a particular 530 mobile node. It MUST be unicasted and MUST be authenticated by IPsec 531 ESP. The State Synchronization message has the MH Type value TBD. 532 When this value is indicated in the MH Type field, the format of the 533 Message Data field in the Mobility Header is as follows: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type | Reserved | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Identifier | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 542 . . 543 . Mobility Options . 544 . . 545 . | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 6: State Synchronization Message 550 Type 552 8-bit unsigned integer. It can be assigned one of the following 553 values: 555 0: Request 557 This message is called State Synchronization Request and used 558 to request state corresponding to a particular mobile node. 559 The State Synchronization Request is used to solicit the active 560 state corresponding to a particular mobile node. 562 1: Reply 564 The message is called State Synchronization Reply and is used 565 between the home agents in the redundant home agent set to 566 exchange binding cache information and any other information 567 related to providing mobility service to the mobile nodes. The 568 State Synchronization Reply can be sent by an active home agent 569 either periodically or in response to a State Synchronization 570 Request. 572 Reserved 574 8-bit unsigned integer. It must be initialized to zero by the 575 sender and must be ignored by the receiver. 577 Identifier 579 A 16-bit identifier to aid in matching state synchronization 580 messages. The identifier should never be set to 0. It should 581 always be more than 1. 583 Mobility Options 585 Variable-length field of such length that the complete Mobility 586 Header is an integer multiple of 8 octets long. This field 587 contains zero or more TLV-encoded mobility options. The encoding 588 and format of defined options are described in [1]. The receiver 589 MUST ignore and skip any options which it does not understand. 591 One of the following options is mandatory in State Synchronization 592 Request message. : 594 * IP Address Option (Sub-type: Home Address)[12]. If a home 595 agent wants the Binding Cache information for a particular 596 mobile node, it includes an IPv6 Address Option. 598 * Mobile Network Prefix Option. If a home agent wants to know 599 the forwarding state setup for a particular Mobile Network 600 Prefix, it includes a Mobile Network Prefix Option as defined 601 in [2]. 603 * Vendor Specific Mobility Option. If a home agent wants vendor 604 specific information, it can solicit with this option as 605 defined in [7]. 607 One of the following options is mandatory in State Synchronization 608 Reply. : 610 * Binding Cache Information Option 612 * AAA Information Option 614 * Vendor Specific Mobility Option 616 This message requires at least one mobility option, therefore, there 617 is no default length for this message. 619 6.1.2. Home Agent Control Message 621 This message is used to control the status of a home agent to either 622 active or standby. This message MUST be unicasted between home 623 agents and MUST be authenticated and encrypted by IPsec ESP. The 624 Home Agent Control message has the MH Type value TBD. When this 625 value is indicated in the MH Type field, the format of the Message 626 Data field in the Mobility Header is as follows: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type | Status | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 . . 634 . Mobility Options . 635 . . 636 . | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Figure 7: Home Agent Control Message 641 Type 643 8-bit unsigned integer. It can be assigned one of the following 644 values: 646 0: SwitchOver Request 648 This message is called SwitchOver Request. It is unicasted by 649 a standby home agent that desires to become the active home 650 agent. The receiver of the message MUST transition to standby 651 state as soon as the message is received and validated 652 successfully. 654 1: SwitchOver Reply 656 This message is called SwitchOver Reply. It is used to 657 acknowledge the receipt of the corresponding SwitchOver 658 Request. 660 2: SwitchBack Request 662 This message is called SwitchBack Request. It is unicasted by 663 an active home agent that desires to become the a standby home 664 agent. The receiver of this message SHOULD transition to 665 active state as soon as the message is received and validated 666 successfully. 668 3: SwitchBack Reply 670 This message is called SwitchBack Reply. It is used to 671 acknowledge the receipt of the corresponding SwitchBack 672 Request. 674 Status 676 8-bit unsigned integer indicating the disposition of a Switchover 677 Request or SwitchBack Request message. This field is only valid 678 in SwitchOver Reply and SwitchBack Reply messages. The following 679 Status values are defined: 681 0: Success 683 128: Reason unspecified 685 129: Administratively prohibited 687 130: Not active home agent (The receiver of the SwitchOver 688 Request message is not the active home agent) 690 131: Not standby home agent (The receiver of the SwitchBack 691 Request is already the active home agent) 693 132: Not in same redundant home agent set 695 Mobility Options 697 Variable-length field of such length that the complete Mobility 698 Header is an integer multiple of 8 octets long. This field 699 contains zero or more TLV-encoded mobility options. The encoding 700 and format of defined options are described in [1]. The receiver 701 MUST ignore and skip any options which it does not understand. No 702 options are defined in this specification 704 If no options are present in this message, no padding is necessary 705 and the Header Len field will be set to 1. 707 6.1.3. Home Agent Hello Message 709 This messages can be replaced by other protocols as described in 710 Section 7.10. If this message is used, it MUST be either unicasted 711 or multicasted to carry home agent information among the redundant 712 home agent set. The Hello message is defined for two purpose: 1) an 713 alive check and 2) home agent information exchange. A home agent 714 Hello message SHOULD be authenticated and encrypted by IPsec ESP when 715 it is unicasted. If a Hello message is multicasted, IPsec ESP cannot 716 be applied. In this case the redundant home agent set should be 717 located in a secure network. Alternatively, all the home agents MUST 718 have a secure channel with each other. The Hello message has the MH 719 Type value TBD. When this value is indicated in the MH Type field, 720 the format of the Message Data field in the Mobility Header is as 721 follows: 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Sequence # | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Home Agent Preference | Home Agent Lifetime | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Hello Interval | Group ID |A|R| Reserved | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | | 733 . . 734 . Mobility Options . 735 . . 736 . | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 8: Home Agent Hello Message 741 Sequence # 743 16-bit unsigned integer. The Sequence number of the Hello message 744 can be used to verify whether this Hello message is the latest one 745 or not. 747 Home Agent Preference 749 16-bit unsigned integer. The preference for the home agent 750 sending this Hello message. This preference is the same as the 751 Home Agent Preference value of the Home Agent Information option 752 as defined in [1]. However, operators MAY use a different 753 preference value for this operation. 755 Home Agent Lifetime 757 16-bit unsigned integer. The lifetime for the home agent sending 758 this Hello message. This lifetime is the same as the Home Agent 759 Lifetime value of the Home Agent Information option as defined in 760 [1]. 762 Hello Interval 764 16-bit unsigned integer. The interval for the home agent sending 765 this Hello message. 767 Group Identifier 769 8-bit unsigned integer. This value is used to identify a 770 particular redundant home agent set. 772 A flag 774 If this flag is set, the sender of this Hello message is an active 775 home agent. Otherwise, the sender is standby home agent 777 R flag 779 If this flag is set, the receiver of this Hello message must send 780 back a Hello message to the sender. 782 Reserved 784 6-bit unsigned integer. It must be initialized to zero by the 785 sender and must be ignored by the receiver. 787 Mobility Options 789 Variable-length field of such length that the complete Mobility 790 Header is an integer multiple of 8 octets long. This field 791 contains zero or more TLV-encoded mobility options. The encoding 792 and format of defined options are described in [1]. The receiver 793 MUST ignore and skip any options which it does not understand. No 794 valid options are defined in this specification. 796 If no options are present in this message, 0 octets of padding are 797 necessary and the Header Len field will be set to 2. 799 6.1.4. Home Agent Switch Message 801 This message is defined in Section 8.3. The Home Agent Reliability 802 protocol extends this message for the Home Agent Hard Switch. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 |# of Addresses |I| Reserved | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | | 810 + + 811 . Home Agent Addresses . 812 + + 813 | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 . Mobility options . 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Figure 9: Home Agent Switch Message 820 IPsec Re-key (I) 822 The IPsec rekey (I) bit is set to indicate that the mobile node 823 SHOULD start an IPsec re-key with the home agent specified in the 824 Home Agent Addresses field. This flag is used when a failed home 825 agent recovers and needs to re-establish IPsec SA/IKE state with a 826 mobile node. 828 Reserved 830 The reserve field is reduced from 8 to 7 bits 832 6.2. New Mobility Options 834 6.2.1. IP address Option 836 This option is already defined in the Fast Handovers for Mobile IPv6 837 (FMIP) specification [12]. This document introduces new Sub-Type 838 values for home agent address and Home Address. 840 Option-Code 842 * 4: Home Agent Address 843 * 5: Home Address 845 6.2.2. Binding Cache Information Option 847 The binding cache information option has an alignment requirement of 848 8n+2. Its format is as follows: 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Type = TBD | Length = 40 | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Flags | Sequence Number | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Lifetime | Reserved | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | | 860 + + 861 | Home Address | 862 + + 863 | | 864 + + 865 | | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | | 868 + + 869 | | 870 + Care-of Address + 871 | | 872 + + 873 | | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 . . 876 . . 877 . Mobile Network Prefix Option . 878 . . 879 . | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Figure 10: Binding Cache Information Option 884 The Binding Cache Information option is only valid in a State 885 Synchronization message. 887 The fields of Home Address, Care-of Address, Flags, Sequence Number, 888 and Lifetime are copied from the registered binding of a particular 889 mobile node or mobile router. The 8-bit Reserved field MUST be set 890 to zero. If the R-flag is set to indicate this binding cache entry 891 is for a mobile router, then this option will be immediately followed 892 by one or more Mobile Network Prefix options. 894 6.2.3. AAA Information Option 896 The AAA option is used to carry the AAA state of the mobile node's 897 Mobile IPv6 sessions. The AAA state information can be conveyed in 898 RADIUS or Diameter AVP formats including the user and session info. 899 This information option is only valid in a State Synchronization 900 message. 902 0 1 2 3 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Type = TBD | Length | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 . . 908 . . 909 . AAA AVPs . 910 . . 911 . | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 11: Vendor Specific Inforamtion Option 916 Type 918 8-bit Type value. The value is TBD. 920 Length 922 8-bit length value. 924 AAA AVPs 926 Series of TLV encoded AAA AVPs (including vendor specific AVPs) 927 carrying AAA-related information for each Mobile IPv6 and IPsec/ 928 IKE session. 930 7. Home Agent Operation 932 7.1. Home Agent Address Configuration 934 Each standby home agent obtains its individual IPv6 address from its 935 attached link. This IPv6 address is used by the home agent 936 reliability protocol to exchange information with the associated home 937 agents. The link between home agents should be secured. 939 When the Home Agent Virtual Switch mode is used, the virtual home 940 agent IPv6 address which is known by the mobile node is shared with 941 the standby home agents. When a home agent fails, the standby home 942 agent activates the IPv6 address of the failed home agent and becomes 943 the active home agent. The standby home agent should not activate 944 the IPv6 address until it knows the active home agent is no longer 945 reachable at the address, otherwise address duplication will occur. 946 To guarantee transparency of the home agent virtual switch to mobile 947 nodes located on the home link, the neighbor cache of the home agent 948 IP address MUST be carefully operated. See Section 7.2 in detail. 950 When the Home Agent Hard Switch mode is used, each home agent 951 configures itself with a different IPv6 address from the same home 952 prefix. This IPv6 address can be used for the Home Agent Reliability 953 protocol if the standby home agents are located at the same link of 954 the active home agent (Figure 1). In case of Figure 2, the router 955 must carefully route packets to the standby home agents as described 956 in Section 7.2. Once a mobile node registers its binding with the 957 active home agent, it may solicit an IPsec/IKE exchange with standby 958 home agents. These packets must be routed to the recovery link. 959 This can be achieved by installing host routes for the standby home 960 agents on the recovery link of the router. 962 7.2. Consideration of Routing and Neighbor Discovery Protocol 964 This section gives a brief explanation of how a home agent interacts 965 with routing and Neighbor Discovery Protocol (NDP) when the Home 966 Agent Virtual Switch mode is used. 968 When a standby home agent becomes active in the Home Agent Virtual 969 Switch mode, it MUST start to advertise the home agent address and 970 the home prefix of the home addresses serviced by the redundant home 971 agent set into the routing infrastructure. This operation is 972 normally done using a route selector such as BGP or an OSPF modifier. 973 For example, we can use the AS_Path prepend operation for BGP, and 974 the Metric field in OSPF for route selection. 976 For instance, home agents should run OSPF with the appropriate cost 977 so that the active home agent whose preference is highest can receive 978 the packets from the other routers on the home link. When the active 979 home agent is down, OSPF detects the failure and can dynamically 980 switch the route to the standby home Agent based on the OSPF cost 981 value. If this cost conflicts with the home agent preference value 982 due to misconfiguration, the routers on the home link may not route 983 packets to the desired standby home agent. Therefore, the home agent 984 MAY dynamically change the OSPF cost based on the home agent 985 preference value. Most of router vendors have a private MIB to set 986 the cost via SNMP, though this is a vendor-specific function. The 987 operator can consider other existing approaches to update routes on 988 the routers at the home link. 990 When an active home agent activates a home agent address, it SHOULD 991 use a virtual MAC address as introduced in [4]. When the active home 992 agent is changed, the neighbor cache of the active home agent is not 993 necessarily updated on mobile nodes located on the home link. 994 Otherwise, the new home agent MUST update the neighbor cache entry 995 for the home agent address on all the mobile nodes located on the 996 home link. In addition, Mobile IPv6 uses proxy NDP to intercept 997 packets meant for mobile nodes which are away from the home link. 998 However, it is unnecessary for the new active home agent to overwrite 999 the existing proxy neighbor entries of the mobile nodes. 1001 7.3. Home Agent List Management 1003 In Mobile IPv6 [1], each home agent periodically sends router 1004 advertisements with a Home Address Information option [1] for 1005 exchanging home agent information when there are multiple home agents 1006 present on a link. This information is managed in a home agent list 1007 introduced in [1]. When the Home Agent Reliability Protocol is used, 1008 Hello messages are used to update the home agent list. There are 1009 several reasons to use Hello message instead of Router Advertisement 1010 on the Home Agent Reliability protocol: 1012 1. Router Advertisements are sent among home agents and also to 1013 mobile nodes. When the Home Agent Virtual Switch is used, 1014 standby home agents MUST NOT generate unsolicited Router 1015 Advertisements. The standby home agents MUST be transparent to 1016 all mobile nodes. Hello messages are exchanged only with other 1017 home agents. 1019 2. Router Solicitation and Advertisement messages [8] cannot be used 1020 due to link-local limitations. However, as shown in Section 5.1, 1021 standby home agents are not always configured on the same link. 1022 Router Advertisements cannot be used in this case. 1024 3. The Home Agent Reliability protocol is required to exchange 1025 additional information such as Group ID and Active/Standby Status 1026 of the home agents. 1028 When Hello messages are used, the Home Agent Information Option [1] 1029 MAY NOT be used in Router Advertisements on the home link, because 1030 all necessary information will be present in the Hello messages. 1031 However, mobile nodes located on the home link require this 1032 information for home agent discovery. In addition, if operators want 1033 to use different parameters such as Preference value for home agents 1034 and mobile nodes, they can utilize both Router Advertisements and 1035 Hello messages. Router Advertisements are used to carry the home 1036 agent information for mobile nodes, and Hello message are used to 1037 carry information for Home Agent Reliability operation. If an 1038 operator decides not to use the Hello messages, Router Advertisements 1039 MUST be used to update the home agent list. 1041 Since Hello messages carry all the necessary information filled-in 1042 from the home agent list, the management of the home agent list is 1043 unchanged. If a standby home agent removes an active home agent from 1044 the list because its lifetime has become zero, it can start recovery 1045 according to this document. Section 7.4 describes failure detection 1046 in detail. 1048 7.4. Detecting Home Agent Failure 1050 The active and standby home agents can monitor each other's status in 1051 multiple ways. One method is to reuse other failure detection 1052 mechanisms such as VRRP[4] and HSRP[5] described in Section 7.10. 1053 This document also defines its own method by using periodic exchanges 1054 of Hello messages to monitor status. The reasons to specify Hello 1055 messages are: 1057 1. Hello messages can be sent off-link for global recovery is 1058 required by an operator. Router Advertisements cannot be used in 1059 this scenario since their scope is link-local. Thus, Hello 1060 messages are necessary to exchange home agent information among 1061 home agents in a globally redundant home agent set. 1063 2. If Router Advertisements and VRRP are used for periodic messages, 1064 they may not detect the case where the system is running but the 1065 Mobile IPv6 stack is not operational. Mobile IPv6 may be 1066 implemented as a userland daemon, so if Hello messages are used, 1067 the failure of a home agent can be easily detected, assuming 1068 Hello message functionality is implemented in the same home agent 1069 daemon. 1071 3. Hello messages can be frequently exchanged to detect failure, 1072 while there is a restriction on how often Router Advertisements 1073 can be sent, and on how they are processed by routers that 1074 receive them. Router Advertisements are also not sent frequently 1075 enough to rely on their absence to detect a home agent failure. 1077 A Hello request message (R-flag set) may be used by any home agent to 1078 request state information from any other home agent in the redundant 1079 home agent set. If a Hello message is not received from a home agent 1080 peer within a configurable amount of time, then that home agent peer 1081 is considered to have failed. The detail of the Hello message is 1082 described in Section 7.6. Failure events used in the Home Agent 1083 Reliability protocol are listed below. 1085 Loss of Communication with the Active Peer Home Agent 1087 In the event that a standby home agent does not receive any Hello 1088 message from its peer which is currently the active home agent for 1089 a configurable duration, the standby home agent may decide to 1090 become the active home agent. 1092 Monitored Server Failure by the Active Home Agent 1094 There may be number of critical servers in the network that are 1095 essential for the ongoing Mobile IPv6 sessions at the home agent. 1096 One such server may be the AAA server which is receiving the 1097 accounting information for the session. The operator may have a 1098 policy in place that requires the home agent to initiate a switch- 1099 over procedure upon detecting that the link to such a server has 1100 failed. 1102 Routing Peer/Link Failure 1104 In some cases, an operator may require the home agent to detect a 1105 next-hop routing peer failure. If the next-hop routing peer 1106 fails, the operator may want the home agent to initiate a switch- 1107 over procedure if the failure is fatal in nature, or due to some 1108 other routing policies. 1110 7.5. Home Agent Switch Over 1112 After detecting the active home agent has failed, a standby home 1113 agent whose preference value is the highest MUST take over for the 1114 failed home agent. 1116 In the Home Agent Virtual Switch mode, the standby home agent MUST 1117 activate the virtual home agent address. If a virtual MAC address as 1118 introduced in [4] is used, the standby home agent MUST start using 1119 the virtual MAC address as well. Since all the necessary state has 1120 already been transferred to this standby home agent before the active 1121 home agent failed, it can immediately start acting as the active home 1122 agent. 1124 In the Home Agent Hard Switch mode, the standby home agent MUST send 1125 a Home Agent Switch message to all the mobile nodes that were 1126 registered at the failed home agent as described in Section 7.9, 1127 using the pre-established IPsec SA. The home agent switch-over is 1128 complete when it receives binding updates from all the mobile nodes. 1130 7.6. Processing Hello Messages 1132 Hello messages can be unicasted or multicasted. A new multicast 1133 address will be assigned by the IANA. When all home agents in a 1134 redundant home agent set are configured on a same home link, they 1135 MUST join a new multicast address (TBA) and multicast Hello. On the 1136 other hand, if a home link is separated as described in Figure 2, 1137 each home agent MUST unicast Hello messages. 1139 7.6.1. Requesting Hello Message 1141 A home agent can solicit a Hello message from a particular home agent 1142 in the same redundant home agent set by unicasting or multicasting a 1143 Hello message with the R-flag set. The sender MUST fill the fields 1144 of the Hello message with it's home agent information. When a Hello 1145 message is unicasted, only the destination of the Hello message will 1146 answer it. On the other hand, if a Hello message is multicasted, all 1147 the home agents in the multicast group will reply to the Hello 1148 message. This Hello request message SHOULD be generated when: 1150 o A new home agent needs to collect information of the other home 1151 agents in the same redundant home agent set. In this case it 1152 SHOULD multicast a Hello message in which the R-flag is set. 1154 o A home agent entry in the redundant home agent list is about to be 1155 removed due to home agent lifetime expiration. 1157 o A Hello message has not been received during the specified hello 1158 interval. 1160 7.6.2. Sending Hello Message 1162 The Hello message MUST be sent when a home agent receives a Hello 1163 message with the R-flag set, indicating a request is required, 1164 otherwise Hello messages are periodically sent according to the pre- 1165 configured Hello interval. In addition, a home agent SHOULD send a 1166 Hello message to the home agents of the redundant home agent set when 1167 it boots up and its local information, such as home agent preference, 1168 home agent lifetime, and registration status, etc., change. When a 1169 new home agent boots up, it SHOULD solicit Hello messages by 1170 multicasting a Hello message with the R-flag set in parallel with 1171 sending its own Hello message. 1173 Whenever a home agent generates Hello message, it MUST increment in 1174 the Sequence Number by 1. The Sequence Number SHOULD be initialized 1175 to zero for the first Hello message. To accomplish sequence number 1176 rollover, if the sequence number has already been assigned to be the 1177 largest possible number representable as a 16-bit unsigned integer, 1178 then when it is incremented it will then have a value of zero (0). 1179 It MUST also specify its own Group ID in the Group ID field of the 1180 Hello message. If a home agent is the active home agent, it MUST set 1181 the A-flag in it's Hello Messages. In the Home Agent Hard Switch 1182 mode, the source address of Hello messages MUST be the configured 1183 home agent address. In the Home Agent Virtual Switch mode, the 1184 individual IPv6 addresses of each home agent MUST be used. 1186 7.6.3. Receiving Hello Message 1188 When a home agent receives a Hello message, it SHOULD verify IPsec 1189 ESP protection. If the message is not protected, it SHOULD be 1190 silently discarded. However, if the Hello messages is sent on a 1191 dedicated link between the home agents, IPsec protection is not 1192 required. If a Hello message is sent from an IPv6 address whose 1193 scope is not global, the message MUST be silently discarded. 1195 If the sending home agent is not in the same redundant home agent 1196 set, the message MUST be silently ignored. This can be done by 1197 comparing the Group ID field of the received Hello message with its 1198 own Group ID value. Hello messages MUST NOT be sent to a home agent 1199 whose Group ID is different from the sender. If the Sequence Number 1200 value in the Hello message is equal to or less than the Sequence 1201 Number value stored in the home agent list entry, the Hello message 1202 MUST be discarded. 1204 Any Hello message satisfying all of these tests MUST be processed to 1205 update the redundant home agent list. The receiver copies home agent 1206 information in the Hello message to the corresponding redundant home 1207 agent list entry. The home agent address of the sender is retrieved 1208 from the Source Address field of the IPv6 header of the Hello 1209 message. If the home agent lifetime field in the Hello message is 1210 set to 0, the receiver removes the sender from the redundant home 1211 agents list. 1213 If the R-flag is set in the received Hello message, the receiver MUST 1214 reply with a Hello message to the originator as described in 1215 Section 7.6.2. 1217 7.7. Processing State Synchronization Messages 1219 It is necessary for standby home agents to synchronize the state 1220 information of each mobile node registered with the active home 1221 agent. In the Home Agent Virtual Switch mode, the synchronized state 1222 information is used by a standby home agent when it takes over for 1223 the failed home agent. In the Home Agent Hard Switch mode, the 1224 standby home agent starts the switch-over of all the mobile nodes 1225 registered to the failed home agent when the home agent failure is 1226 detected. Thus, the Binding Cache entry MUST be modified to keep the 1227 active home agent address of each mobile node. 1229 7.7.1. Soliciting State of a Particular Mobile Node or Subset of Mobile 1230 Nodes 1232 When a standby home agent wants state information for a particular 1233 mobile node or a subset of mobile nodes, such as Binding Cache, AAA, 1234 etc., it MAY solicit this state by sending a State Synchronization 1235 message constructed as follows: 1237 o It MUST set the Type field to 0 (Request). 1239 o It MUST set a random value in the Identifier field that does not 1240 coincide with any other currently pending Requests. 1242 o It MUST include either a Home Address mobility option indicating 1243 the mobile node, or a Mobile Network Prefix mobility option 1244 indicating the mobile router. The standby home agent can send 1245 multiple home address and mobile network prefix mobility options 1246 to request state information for multiple mobile nodes in a single 1247 State Synchronization request message. 1249 When a home agent receives the State Synchronization message with the 1250 Type field set to 0 (Request), it MUST verify the message as follows: 1252 o The state synchronization message MUST be protected by IPsec ESP. 1254 o The sending home agent MUST belong to the same redundant home 1255 agent set 1257 o The receiver MUST be the active home agent for the requested home 1258 address or mobile network prefix. 1260 Any packet carrying a State Synchronization message which fails to 1261 satisfy all of these tests MUST be silently ignored. 1263 Otherwise, the receiver MUST reply with a State Synchronization 1264 message including state information for the requested mobile node(s) 1265 and/or mobile network prefix(es) as described in Section 1266 Section 7.7.2. 1268 7.7.2. Synchronizing State of Mobile Nodes 1270 A state synchronization message can be sent either: 1272 o When an active home agent receives a state synchronization message 1273 in which the Type field is set to 0 (Request). 1275 o When an active home agent creates a binding cache entry for a 1276 particular mobile node. 1278 o When an active home agent deletes a binding cache entry for a 1279 particular mobile node. 1281 o When an active home agent updates a binding cache entry for a 1282 particular mobile node, only when operating in the Home Agent 1283 Virtual Switch mode. In the Home Agent Hard Switch mode, standby 1284 home agents only use this binding cache information to send a Home 1285 Agent Switch message, so only need a home address of all the 1286 mobile nodes registered to the active home agent of the same 1287 redundant home agent set. 1289 o In a periodic interval to update the state information for all 1290 sessions that changed since the last update. 1292 If an active home agent sends a State Synchronization message 1293 whenever the local state information changes, such as a binding cache 1294 change, the number of the State Synchronization messages sent can be 1295 quite large. 1297 The binding cache information of the requested mobile nodes is stored 1298 in the State Synchronization message. The active home agent MUST 1299 copy the binding cache information of the requested mobile nodes into 1300 Binding Cache Information options. If the State Synchronization 1301 message is sent in response to a State Synchronization request 1302 message, the active home agent MUST copy the Identifier field of the 1303 State Synchronization request message to the Identifier field in the 1304 State Synchronization reply message. Otherwise, it MUST set the 1305 Identifier field to 0. 1307 When the active home agent stores the state of multiple mobile nodes 1308 in a state synchronization message, a Binding Cache Information 1309 option is used as a separator. For each mobile node, a Binding Cache 1310 Information option is placed first, followed by any other options. 1311 When the next Binding Cache Information option is reached in the 1312 State Synchronization message, it indicates the information of a 1313 different mobile node. 1315 A State Synchronization message MUST be authenticated and encrypted 1316 by IPsec ESP mode, otherwise the message MUST be ignored. When a 1317 home agent receives a State Synchronization message, it MUST verify 1318 the Source address field of the IPv6 header. If the source address 1319 does not belong to any home agent in the redundant home agent set, 1320 the message MUST be silently discarded. After successfully verifying 1321 the message, the receiving home agent MUST update its binding cache 1322 and all other necessary information such as AAA and vendor specific 1323 information in the particular database. In the Home Agent Hard 1324 Switch mode, the receiver MUST also record the IPv6 address of the 1325 sender (the active home agent). 1327 7.8. Processing Home Agent Control Messages 1329 7.8.1. Standby Home Agent becomes an Active Home Agent 1331 When a standby home agent decides to become an active home agent, the 1332 standby home agent sends a SwitchOver Request message (a Home Agent 1333 Control message in which the Type field is set to 0) to the active 1334 home agent. This message MUST be unicasted to the active home agent 1335 and MUST be encrypted and authenticated by IPsec ESP. The active 1336 home Agent MUST NOT generate this message. 1338 When an active home agent receives a SwitchOver Request, it first 1339 verifies the received Home Agent Control message. If the request 1340 message is not protected by IPsec, it MUST be silently discarded. If 1341 the home agent is not an active home agent, it MUST send a SwitchOver 1342 Reply message (a Home Agent Control message in which the Type field 1343 is set to 1) with the Status field set to 130 (Not active home 1344 agent). If the receiver is an active home agent and does not want 1345 this standby home agent to become the active home agent, it MUST 1346 reply a SwitchOver reply with the Status field set to 129 1347 (Administratively prohibited). In addition, if the sending home 1348 agent does not belong to the same redundant home agent set, a 1349 SwitchOver Reply message MUST be sent to the sender with the Status 1350 field set to 132 (Not in same redundant home agent set). Otherwise, 1351 the active home agent MUST become a standby home agent and reply with 1352 a SwitchOver Reply message with the Status field set to 0 (Success). 1354 If a home agent receives a SwitchOver Reply message, it MUST be 1355 protected by IPsec ESP. Otherwise, the message MUST be silently 1356 discarded. If the receiving home agent did not send a SwitchOver 1357 Request message, the message MUST be silently ignored. If the Status 1358 field of the SwitchOver Reply message is 0 (Success), the receiving 1359 standby home agent immediately becomes an active home agent. If the 1360 value in the Status field is greater than 128 an error has occurred. 1362 In this case, the receiver MUST NOT become an active home agent. 1364 7.8.2. Active Home Agent becomes in-active 1366 When an active home agent decides to become an in-active home agent, 1367 it sends a SwitchBack Request message (i.e. a Home Agent Control 1368 message with Type field set to 3) to a standby home agent. The 1369 reason for the active home agent to send this message can be 1370 administrative intervention, and events like Monitored Server Failure 1371 by the active home agent or Routing Peer/Link Failure. This message 1372 MUST be unicasted to one of the standby home agents and MUST be 1373 encrypted and authenticated by IPsec ESP. A standby home agent MUST 1374 NOT generate this message. 1376 A SwitchBack Reply is sent in reply to a SwitchBack Request message. 1377 When a home agent receives a SwitchBack Request message, it first 1378 verifies the message. If the SwitchBack Request message is not 1379 protected by IPsec ESP, it MUST be silently discarded. If the 1380 sending home agent of the SwitchBack Request message is not an active 1381 home agent, the receiver MUST reply with a SwitchBack Reply (a Home 1382 Agent Control message in which the Type field is set to 4) in which 1383 the Status field is set to 130 (Not active home agent). If the 1384 sending home agent does not belong to the same redundant home agent 1385 set, a SwitchBack Reply message MUST be sent in which the Status 1386 field set to 132 (Not in same redundant home agent set). Otherwise, 1387 the receiving home agent MUST send a SwitchBack Reply message in 1388 which the Status field is set to 0 (Success). After sending the 1389 SwitchBack reply, it MUST NOT become an active home agent 1390 immediately. This is because the active home agent is still active 1391 until it receives the SwitchBack Reply message acknowledging the 1392 SwitchBack Request. The standby home agent SHOULD change to active 1393 at least after LINK_TRAVERSAL_TIME. 1395 If a home agent receives a SwitchBack Reply message, it MUST be 1396 protected by IPsec ESP, otherwise the message MUST be silently 1397 discarded. If the receiving home agent did not send a SwitchBack 1398 Request message beforehand, the message MUST be silently discarded. 1399 If the Status field of the SwitchBack Reply message is 0 (Success), 1400 the receiving home agent immediately becomes an in-active home agent. 1401 If the value in the Status field is greater than 128, an error has 1402 occurred. In this case, the receiver cannot become an in-active home 1403 agent and MUST continue to be an active home agent. 1405 7.9. Sending Home Agent Switch Messages 1407 This operation is valid only for the Home Agent Hard Switch mode. 1408 The standby home agent MUST send a Home Agent Switch message as 1409 defined in [11] to all the mobile nodes that were being served by the 1410 failed home agent. Since the active home agent address is recorded 1411 in each synchronized binding cache, the standby home agent knows 1412 which mobile nodes were served by the failed home agent. The Home 1413 Agent Switch message must be encrypted with a pre-established SA. 1414 The standby home agent should include its own IPv6 address in the 1415 Home Agent Switch message. Note that a Home Agent Switch message is 1416 sent to each mobile node served by the home agent. If there is a 1417 large number of mobile nodes, sending Home Agent Switch messages will 1418 cause a lot of signaling overhead on the network. 1420 When a failed home agent recovers, it MUST re-establish an IPsec SA 1421 with each mobile node served by its redundant home agent set. 1422 Otherwise, it cannot be either a standby or active home agent for the 1423 mobile nodes. Therefore, it sends a Home Agent Switch message with 1424 the I-flag set to all the mobile nodes serving by other home agents 1425 in the same redundant home agent set, and includes its own home agent 1426 address in the Home Agent Addresses field. 1428 7.10. Interworking with VRRP 1430 VRRP and HSRP specify an election protocol that dynamically assigns 1431 responsibility for a virtual router to one of the VRRP routers on a 1432 LAN. This operation is similar to the Home Agent Virtual Switch 1433 operation. For example, the VRRP router controlling the IP 1434 address(es) associated with a virtual router is called the Master, 1435 and forwards packets sent to these IP addresses. The election 1436 process provides dynamic fail over in the forwarding responsibility 1437 should the Master become unavailable. Although VRRP is used to 1438 guarantee home agent address reachability, it cannot be used for 1439 state synchronization and explicit switching of Master and Backup. 1440 Thus, the Home Agent Reliability protocol cannot be replaced by VRRP. 1441 This section explains how VRRP can interwork with the Home Agent 1442 Reliability protocol. 1444 When VRRP is available, VRRP can replace the Hello message described 1445 in Section 6.1.3. However, some of information is missed by using 1446 VRRP. After receiving a VRRP message, each home agent SHOULD process 1447 the message and store the information as if it receives Home Agent 1448 Hello messages Section 7.6.3. The Home Agents SHOULD still perform 1449 binding cache synchronization as described in Section 7.7 and SHOULD 1450 support the Home Agent Switch message as described in Section 7.9. 1452 In addition to this, VRRP is useful only if all home agents are 1453 located on the same link. If the home agents are topologically 1454 separated, the Home Agent Reliability protocol MUST be used. 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr| 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 |(rsvd) | Adver Int | Checksum | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | | 1464 + + 1465 | IPv6 Address(es) | 1466 + + 1467 + + 1468 + + 1469 + + 1470 | | 1471 + + 1472 | | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 Figure 12: VRRP Packet Format 1477 The message format of VRRP is described in Figure 12. Each field is 1478 mapped as follows: 1480 Virtual Rtr ID 1482 Group ID is stored in the Virtual Rtr ID field. 1484 Priority 1486 Home Agent Preference is stored in the Priority field. Note that 1487 VRRP only has 8 bits for the Priority field. Therefore, values 1488 larger than 255 MUST NOT be assigned to the preference value. 1490 Count IPv6 IPv6 Addr 1492 This field MUST be always be 1. 1494 Advert Int 1496 This field MUST be mapped to the Hello Interval field of the Home 1497 Agent Hello message, though it only has 12 bytes. 1499 IPv6 address 1501 A home agent address is stored in this field. 1503 Home Agent Lifetime, Sequence Number and Flags field are missing in 1504 the VRRP packet format. Therefore, operators SHOULD use the same 1505 statically configured value for Home Agent Lifetime. Each home agent 1506 does not check freshness of received VRRP message because of no 1507 sequence number. If VRRP is used, a home agent cannot determine the 1508 active home agent from the VRRP message due to lack of A flag, and 1509 cannot request a VRRP advertisement to other home agents. 1511 7.11. Retransmissions and Rate Limiting 1513 Standby and active home agents are responsible for retransmissions 1514 and rate limiting of a State Synchronization Request, Switchover 1515 Request, SwitchBack Request messages for which they expect a 1516 response. The home agent MUST determine a value for the initial 1517 transmission timer: 1519 o If the home agent sends a State Synchronization Request message, 1520 it SHOULD use an initial retransmission interval of 1521 INITIAL_STATE_SYNC_REQ_TIMER. 1523 o If a standby home agent sends a Switchover Request message, it 1524 SHOULD use an initial retransmission interval of 1525 INITIAL_SWICHOVER_REQ_TIMER. 1527 o If an active home agent sends a SwitchBack Request message, it 1528 SHOULD use an initial retransmission interval of 1529 INITIAL_SWICHBACK_REQ_TIMER . 1531 If the sending home agent fails to receive a valid matching response 1532 within the selected initial retransmission interval, it SHOULD 1533 retransmit the message until a response is received. All of the 1534 above constants are specified in Section 10. 1536 The retransmission MUST use an exponential backoff process as 1537 described in [1] until either the home agent receives a response, or 1538 the timeout period reaches the value MAC_HARELIABILITY_TIMEOUT 1539 (16sec). The home agent SHOULD use a separate back-off process for 1540 different message types and different destinations. The rate 1541 limiting of Mobility Header messages is the same as one in [1]. A 1542 home agent MUST NOT send Mobility Header Messages to a particular 1543 home agent more than MAX_UPDATE_RATE (3) times a second, which is 1544 specified in [1]. 1546 8. Mobile Node Operation 1548 Operations described in this section are valid only for the Home 1549 Agent Hard Switch mode. When the Home Agent Virtual Switch is used, 1550 all these operations can be skipped. 1552 8.1. Home Agent Addresses Discovery 1554 To provide home agent reliability with the Home Agent Hard Switch 1555 mode, a mobile node authenticates itself to two or more home agents 1556 and creates IPsec SAs with them during bootstrapping. When one home 1557 agent fails, another home agent can use the pre-existing SA to notify 1558 the mobile node about the failure. 1560 Multiple home agent addresses are available in a home network. In 1561 order to discover these home agent addresses, two different 1562 mechanisms are defined in the bootstrapping solution in the split 1563 scenario [13]. One is DNS lookup by home agent Name, the other is 1564 DNS lookup by Service Name. DHCPv6 can also be used in the 1565 integrated scenario [14] to provide home agent provisioning to mobile 1566 nodes. 1568 In the split scenario, a mobile node can use DNS lookup by Service 1569 Name to discover the home agents, as defined in [13]. For example, 1570 if home agent reliability is required by a mobile node, DNS lookup by 1571 Service Name method is recommended for the mobile node to discover 1572 multiple home agents addresses. Therefore, mobile nodes will query 1573 the DNS SRV records with a service name of mip6 and protocol name of 1574 ipv6. The DNS SRV records includes multiple home agent addresses and 1575 different preference values and weights. The mobile node SHOULD 1576 choose two or more home agents from the home agents list according to 1577 their preference value. Then the mobile node should authenticate 1578 itself to these home agents via an IKEv2 exchange. 1580 In the integrated scenario, a mobile node can use DHCPv6 to get home 1581 agent provisioning from an MSP or ASP, as already defined in [14]. 1582 The only requirement is that the DHCPv6 response must include 1583 multiple home agents' information in order to support home agent 1584 reliability. 1586 8.2. IKE/IPsec pre-establishment to Home Agents 1588 After a mobile node gets multiple home agent addresses, it needs to 1589 trigger multiple IKE exchanges with theh multiple home agents 1590 selected from the home agent list. Since both IKEv1 and IKEv2 can be 1591 used to bootstrap Mobile IPv6, this solution does not introduce any 1592 new operations to co-operate with IKEv1 or IKEv2. It should initiate 1593 IKE for home agents as soon as home registration is complete. 1595 The mobile node MUST follow the standard IKEv2 exchange in the 1596 bootstrapping solution of the split scenario [13], or the IKEv1 1597 bootstrapping solution [15]. Home Address configuration maybe also 1598 be included, if necessary, for the first IKE exchange. After its 1599 Home Address is assigned or approved by the first home agent, mobile 1600 node SHOULD register itself with the second home agent with IKE using 1601 the same Home Address. Therefore, no home address configuration 1602 should be used in the second IKEv2 procedure. Note that the mobile 1603 node only sends a Binding Update message to the first home agent. 1605 8.3. Receiving Home Agent Switch message 1607 A mobile node must follow the operation specified in [11] when it 1608 receives a Home Agent Switch message. 1610 If the I-flag is set in the received Home Agent Switch message, the 1611 mobile node MUST re-key the SA with the home agent addresses stored 1612 in the Home Agent Addresses field. The mobile node MUST NOT change 1613 its active home agent when the I-flag is set. If the home agent 1614 address is not known from the bootstrapping described in Section 8.1, 1615 the mobile node MUST NOT start an IKE session with the unknown home 1616 agent. Instead, it SHOULD re-start home agent discovery again to 1617 update its home agent address information. 1619 When the mobile node receives a Home Agent Switch message without 1620 I-flag set, and if the message contains the IPv6 address of a standby 1621 home agent, it SHOULD pick the standby home agent in the switch 1622 message as the active home agent and send a Binding Update message to 1623 it. The mobile node already has a pre-established SA with the home 1624 agent and should use that SA to send the Binding Update. 1626 9. Security Considerations 1628 Since Mobile IPv6 operation requires ESP in transport mode between 1629 the mobile node and the home agent, we will discuss the ESP field 1630 synchronization issues between the mobile node and the redundant set 1631 of home agents. This synchronization is required only for Home Agent 1632 Virtual Switch mode. Most of fields should be synchronized based on 1633 RFC4301 [9]. The ESP header has the following fields: 1635 SPI 1637 This field identifies the SAD at the receiver. 1639 The mobile node negotiates only one IPsec SA. Hence, the SPI 1640 value will remain unchanged upon home agent failover. 1642 Sequence Number 1644 This field is used for "anti-replay" feature of ESP. The 1645 transmitter must include this monotonically increasing number. 1646 The receiver may process the sequence number based on local 1647 policy. 1649 The mobile node and the redundant home agent set will have the 1650 same set of sequence numbers for transmit and receive. Hence, 1651 synchronization of the sequence number field is mandatory in this 1652 mode of operation. 1654 As described in Section 4, the SA1, SA2, SA3, SA4 could be 1655 synchronized between the home agents as these messages are not 1656 sent continuously. Moreover for the Binding Update case, if the 1657 mobile node is in the middle of sending a Binding Update to an 1658 active home agent for a binding refresh, and the active home agent 1659 is not available at that moment, the mobile node will not get any 1660 response from the active home agent. After a standby home agent 1661 becomes active, the mobile node will retry and it will receive the 1662 Binding Update from the mobile node with a sequence number that is 1663 +n from its last known sequence number for SA1. For the Binding 1664 Acknowledgement case (SA2), the standby home agent SHOULD add a 1665 random number to the last known sequence number over and above the 1666 replay window to ensure that the packet passes the replay check at 1667 the mobile node. The same applies to HoTi and HoT messages with 1668 SA3 and SA4. Note that this windowing of the sequence numbers for 1669 Mobile IPv6 signaling is only needed to cover the corner cases 1670 when Binding Update or HoTi is in-flight and the active home agent 1671 fails. 1673 The technique explained above should work for user data packets if 1674 ESP is used to encrypt user data traffic as well. The actual 1675 switchover time and the routing infrastructure convergence time is 1676 the only latency that the user may perceive. 1678 Initialization Vector 1680 Since the Initialization Vector will be delivered in each exchange 1681 between a mobile node and home agent, this field is not 1682 necessarily synchronized between home agents. 1684 Others 1686 Other fields should be synchronized based on RFC4301[9] 1688 In the Home Agent Hard Switch mode, the standby home agent needs to 1689 send a Home Agent Switch message using IPsec encryption. Since the 1690 mobile node has pre-established an IPsec SA with both the active and 1691 standby home agents, the standby home agent can send the message to 1692 the mobile node with the pre-established IPsec SA. 1694 10. Protocol Constants 1696 INITIAL_STATE_SYNC_REQ_TIMER: 3sec 1698 INITIAL_SWICHOVER_REQ_TIMER: 1sec 1700 INITIAL_SWICHBACK_REQ_TIMER 1sec 1702 LINK_TRAVERSAL_TIME 150msec 1704 11. Contributors 1706 This document is a result of discussions in the Mobile IPv6 Home 1707 Agent Reliability Design Team. The members of the design team that 1708 are listed below are authors that have contributed to this document: 1710 Samita Chakrabarti 1712 samita.chakrabarti@azairenet.com 1714 Kuntal Chowdhury 1716 kchowdhury@starentnetworks.com 1718 Hui Deng 1720 hdeng@hitachi.cn 1722 Vijay Devarapalli 1724 vijay.devarapalli@azairenet.com 1726 Sri Gundavelli 1728 sgundave@cisco.com 1730 Brian Haley 1732 brian.haley@hp.com 1734 Behcet Sarikaya 1736 bsarikaya@huawei.com 1738 Ryuji Wakikawa 1740 ryuji@sfc.wide.ad.jp 1742 12. Acknowledgements 1744 This document includes a lot of text from [16] and [17]. Therefore 1745 the authors of these two documents are acknowledged. We would also 1746 like to thank the authors of the home agent reliability problem 1747 statement [18] for describing the problem succinctly and Alice Qin 1748 for her work on the hello protocol. 1750 13. References 1752 13.1. Normative References 1754 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1755 IPv6", RFC 3775, June 2004. 1757 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1758 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1759 January 2005. 1761 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1762 Levels", BCP 14, RFC 2119, March 1997. 1764 [4] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1765 RFC 3768, April 2004. 1767 [5] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby 1768 Router Protocol (HSRP)", RFC 2281, March 1998. 1770 [6] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1771 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1772 Agents", RFC 3776, June 2004. 1774 [7] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", 1775 draft-ietf-mip6-vsm-00 (work in progress), December 2006. 1777 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1778 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1780 [9] Kent, S. and K. Seo, "Security Architecture for the Internet 1781 Protocol", RFC 4301, December 2005. 1783 13.2. Informative References 1785 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 1786 RFC 3753, June 2004. 1788 [11] Haley, B., "Mobility Header Home Agent Switch Message", 1789 draft-ietf-mip6-ha-switch-01 (work in progress), June 2006. 1791 [12] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1792 July 2005. 1794 [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1795 draft-ietf-mip6-bootstrapping-split-02 (work in progress), 1796 March 2006. 1798 [14] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 1799 the Integrated Scenario", 1800 draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in 1801 progress), October 2005. 1803 [15] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6 1804 Bootstrapping with IKEv1", 1805 draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress), 1806 March 2006. 1808 [16] Wakikawa, R., "Inter Home Agents Protocol Specification", 1809 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 1810 March 2006. 1812 [17] Devarapalli, V., "Local HA to HA protocol", 1813 draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), 1814 March 2006. 1816 [18] Faizan, J., "Problem Statement: Home Agent Reliability", 1817 draft-jfaizan-mipv6-ha-reliability-01 (work in progress), 1818 February 2004. 1820 Appendix A. Change Log From Previous Versions 1822 Changes from draft-ietf-mip6-hareliability-00 1824 o comment (see mail at 2007 June 20) from Wesley Eddy, Verizon 1825 Federal Network Systems 1827 Author's Address 1829 Ryuji Wakikawa (Editor) 1830 Keio University 1831 Department of Environmental Information, Keio University. 1832 5322 Endo 1833 Fujisawa, Kanagawa 252-8520 1834 Japan 1836 Phone: +81-466-49-1100 1837 Fax: +81-466-49-1395 1838 Email: ryuji@sfc.wide.ad.jp 1839 URI: http://www.wakikawa.org/ 1841 Full Copyright Statement 1843 Copyright (C) The IETF Trust (2007). 1845 This document is subject to the rights, licenses and restrictions 1846 contained in BCP 78, and except as set forth therein, the authors 1847 retain all their rights. 1849 This document and the information contained herein are provided on an 1850 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1851 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1852 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1853 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1854 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1855 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1857 Intellectual Property 1859 The IETF takes no position regarding the validity or scope of any 1860 Intellectual Property Rights or other rights that might be claimed to 1861 pertain to the implementation or use of the technology described in 1862 this document or the extent to which any license under such rights 1863 might or might not be available; nor does it represent that it has 1864 made any independent effort to identify any such rights. Information 1865 on the procedures with respect to rights in RFC documents can be 1866 found in BCP 78 and BCP 79. 1868 Copies of IPR disclosures made to the IETF Secretariat and any 1869 assurances of licenses to be made available, or the result of an 1870 attempt made to obtain a general license or permission for the use of 1871 such proprietary rights by implementers or users of this 1872 specification can be obtained from the IETF on-line IPR repository at 1873 http://www.ietf.org/ipr. 1875 The IETF invites any interested party to bring to its attention any 1876 copyrights, patents or patent applications, or other proprietary 1877 rights that may cover technology that may be required to implement 1878 this standard. Please address the information to the IETF at 1879 ietf-ipr@ietf.org. 1881 Acknowledgment 1883 Funding for the RFC Editor function is provided by the IETF 1884 Administrative Support Activity (IASA).