idnits 2.17.1 draft-ietf-mip6-hareliability-01.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 1849. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1873. 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 (March 5, 2007) is 6256 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 March 5, 2007 5 Expires: September 6, 2007 7 Home Agent Reliability Protocol 8 draft-ietf-mip6-hareliability-01.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 September 6, 2007. 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 . . . . . . . . 28 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 tje 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 any SDO (Standards 393 Development Organization), but is required by operators. Most large 394 operators have a very stringent requirement on network availability 395 even in the worst type of disaster or outage. For example, critical 396 nodes in region-1 are backed up by nodes in region-2. These two 397 regions are geographically separated. If region-1 suffers a downtime 398 due to any reason, all the sessions will be seamlessly taken over by 399 the nodes in region-2. This is called geographic redundancy. This 400 is a well-known configuration for Telecommunications operators. 402 5.2. Home Agent Virtual Switch 404 A mobile node remains unaware about the change in the active home 405 agent since the home agents have replicated all session state 406 including the IPsec/IKE/ESP states. The IPsec/IKE/ESP state transfer 407 is out of scope of this document. 409 MN HA1(active) HA2(Standby) 410 | | . 411 |<--------->| | 1. IKE exchange (with HoA assignment) 412 |---------->| . 2. Binding Update 413 |<----------| . 3. Binding Acknowledgment 414 | | . 415 | |<--------->. 4. State exchanges (binding cache/IPsec) 416 | | . 417 | X . HA1 FAILURE 418 | X . 419 | X<----------. 5. Failure Detection 420 | X | 6. HA2 takes over the HA1 421 | X | 422 | X | RECOVERY COMPLETE 424 Figure 3: Overview of Home Agent Virtual Switch 426 The operations of the Home Agent Virtual Switch mode are shown in 427 Figure 3. The mobile node first attempts the IKE exchange for 428 Security Association (SA) setup and home address assignment (1). 429 After binding registration is done (2, 3), the active home agent 430 pushes all the states of its mobile nodes with a state 431 synchronization message (4). The standby home agent(s) is not active 432 unless it takes over from a failed home Agent. 434 When the active home agent's failure is detected (5), the standby 435 home agent activates the IP address of the failed home agent on it 436 and takes over for the failed home agent. All the home agents in the 437 redundant home agent set share a virtual home agent address and the 438 routing will ensure only the active home agent will be reachable 439 using that virtual home agent address. The standby home agent can 440 serve all the mobile nodes for which the states are synchronized, 441 without any further message exchange, because it has all the 442 necessary information which it obtained from the failed home agent. 444 5.3. Home Agent Hard Switch 446 The overview of the Home Agent Hard Switch is shown in Figure 4. 447 This mode is not transparent to the mobile node when the active home 448 agent failure occurs. 450 MN HA1(active) HA2(Standby) 451 | | | 452 |<--------->| | 1. IKE exchange (with HoA assignment) 453 |---------->| | 2. Binding Update 454 |<----------| | 3. Binding Acknowledgment 455 |<--------------------->| 4. IKE exchange (without HoA assignment) 456 | | | 457 | |<--------->. 5. State exchanges (binding cache) 458 | | | 459 | X | HA1 FAILURE 460 | X | 461 | X<----------| 6. Failure Detection 462 |<----------------------| 7. Sending Home Agent 463 | X | Switch message 464 |<--------------------->| 8. Binding Registration 465 | X | 466 | X | RECOVERY COMPLETE 468 Figure 4: Overview of Home Agent Hard Switch 470 The mobile node establishes IPsec/IKE state with all the home agents 471 in the redundant home agent set beforehand (1 and 4), however it 472 registers its binding only with the active home agent (2 and 3). 473 When an active home agent fails, a standby home agent uses a pre- 474 existing IPsec SA to notify the mobile node about the failure by 475 securely sending a Home Agent Switch message. In order to discover 476 home agent addresses, two different mechanisms are defined, as 477 described in Section 8.1. The active home agent synchronizes the 478 required states of the mobile nodes, such as Binding Cache and AAA 479 information, with other standby home agents periodically (5). The 480 mobile node MUST NOT request a home address(es) assignment through 481 the IKE exchange to the standby home agent when it establishes an SA 482 with it (4). 484 When the standby home agent detects the failure of the active home 485 agent (6), it sends a Home Agent Switch message to all the mobile 486 nodes that were registered with the failed home agent (7). The Home 487 Agent Switch message must be encrypted by a pre-established IPsec SA. 488 After the switch message, the mobile node MUST send a binding update 489 to the new active home agent in order to update the Mobile IPv6 490 tunnel end points (8). 492 5.4. Active Home Agent Management 494 HA1(active) HA2 HA3 .. HAn 495 | | | | 496 |------->| | | 1. HA1 sends SwitchBack Request 497 |<-------| | | 2. HA2 sends SwitchBack Reply 498 | | | | 499 (standby) (active) | | HA2 BECOMES ACTIVE HA 500 | | | | 501 SYSTEM MAINTENANCE, ETC. 502 | | | | 503 |------->| | | 3. HA1 sends SwitchOver Request 504 |<-------| | | 4. HA2 sends SwitchOver Reply 505 | | | | 506 (active) (standby) | | 5. HA1 returns to active HA 507 | | | | HA1 BECOMES ACTIVE AGAIN 509 Figure 5: Manual Home Agent Change 511 In some scenarios the active home agent may need to stop serving 512 mobile nodes for system maintenance. This specification provides for 513 a manual home agent switch by using SwitchBack Request and Reply 514 messages. As shown in Figure 5, the active home agent (HA1) sends a 515 SwitchBack Request message to a standby home agent (HA2). As soon as 516 HA2 receives the message, it becomes the active home agent. HA2 will 517 acknowledge the message by sending a SwitchBack Reply message to HA1. 518 HA1 becomes a standby home agent when it receives the SwitchBack 519 Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in 520 order to become the active home agent again. 522 6. Messages 524 6.1. New Mobility Header Messages 526 6.1.1. State Synchronization Message 528 This message is used to exchange state corresponding to a particular 529 mobile node. It MUST be unicasted and MUST be authenticated by IPsec 530 ESP. The State Synchronization message has the MH Type value TBD. 531 When this value is indicated in the MH Type field, the format of the 532 Message Data field in the Mobility Header is as follows: 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Type | Reserved | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Identifier | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 541 . . 542 . Mobility Options . 543 . . 544 . | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 6: State Synchronization Message 549 Type 551 8-bit unsigned integer. It can be assigned one of the following 552 values: 554 0: Request 556 This message is called State Synchronization Request and used 557 to request state corresponding to a particular mobile node. 558 The State Synchronization Request is used to solicit the active 559 state corresponding to a particular mobile node. 561 1: Reply 563 The message is called State Synchronization Reply and is used 564 between the home agents in the redundant home agent set to 565 exchange binding cache information and any other information 566 related to providing mobility service to the mobile nodes. The 567 State Synchronization Reply can be sent by an active home agent 568 either periodically or in response to a State Synchronization 569 Request. 571 Reserved 573 8-bit unsigned integer. It must be initialized to zero by the 574 sender and must be ignored by the receiver. 576 Identifier 578 A 16-bit identifier to aid in matching state synchronization 579 messages. The identifier should never be set to 0. It should 580 always be more than 1. 582 Mobility Options 584 Variable-length field of such length that the complete Mobility 585 Header is an integer multiple of 8 octets long. This field 586 contains zero or more TLV-encoded mobility options. The encoding 587 and format of defined options are described in [1]. The receiver 588 MUST ignore and skip any options which it does not understand. 590 One of the following options is mandatory in State Synchronization 591 Request message. : 593 * IP Address Option (Sub-type: Home Address)[12]. If a home 594 agent wants the Binding Cache information for a particular 595 mobile node, it includes an IPv6 Address Option. 597 * Mobile Network Prefix Option. If a home agent wants to know 598 the forwarding state setup for a particular Mobile Network 599 Prefix, it includes a Mobile Network Prefix Option as defined 600 in [2]. 602 * Vendor Specific Mobility Option. If a home agent wants vendor 603 specific information, it can solicit with this option as 604 defined in [7]. 606 One of the following options is mandatory in State Synchronization 607 Reply. : 609 * Binding Cache Information Option 611 * AAA Information Option 613 * Vendor Specific Mobility Option 615 This message requires at least one mobility option, therefore, there 616 is no default length for this message. 618 6.1.2. Home Agent Control Message 620 This message is used to control the status of a home agent to either 621 active or standby. This message MUST be unicasted between home 622 agents and MUST be authenticated and encrypted by IPsec ESP. The 623 Home Agent Control message has the MH Type value TBD. When this 624 value is indicated in the MH Type field, the format of the Message 625 Data field in the Mobility Header is as follows: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Type | Status | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 . . 633 . Mobility Options . 634 . . 635 . | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 7: Home Agent Control Message 640 Type 642 8-bit unsigned integer. It can be assigned one of the following 643 values: 645 0: SwitchOver Request 647 This message is called SwitchOver Request. It is unicasted by 648 a standby home agent that desires to become the active home 649 agent. The receiver of the message MUST transition to standby 650 state as soon as the message is received and validated 651 successfully. 653 1: SwitchOver Reply 655 This message is called SwitchOver Reply. It is used to 656 acknowledge the receipt of the corresponding SwitchOver 657 Request. 659 2: SwitchBack Request 661 This message is called SwitchBack Request. It is unicasted by 662 an active home agent that desires to become the a standby home 663 agent. The receiver of this message SHOULD transition to 664 active state as soon as the message is received and validated 665 successfully. 667 3: SwitchBack Reply 669 This message is called SwitchBack Reply. It is used to 670 acknowledge the receipt of the corresponding SwitchBack 671 Request. 673 Status 675 8-bit unsigned integer indicating the disposition of a Switchover 676 Request or SwitchBack Request message. This field is only valid 677 in SwitchOver Reply and SwitchBack Reply messages. The following 678 Status values are defined: 680 0: Success 682 128: Reason unspecified 684 129: Administratively prohibited 686 130: Not active home agent (The receiver of the SwitchOver 687 Request message is not the active home agent) 689 131: Not standby home agent (The receiver of the SwitchBack 690 Request is already the active home agent) 692 132: Not in same redundant home agent set 694 Mobility Options 696 Variable-length field of such length that the complete Mobility 697 Header is an integer multiple of 8 octets long. This field 698 contains zero or more TLV-encoded mobility options. The encoding 699 and format of defined options are described in [1]. The receiver 700 MUST ignore and skip any options which it does not understand. No 701 options are defined in this specification 703 If no options are present in this message, no padding is necessary 704 and the Header Len field will be set to 1. 706 6.1.3. Home Agent Hello Message 708 This messages can be replaced by other protocols as described in 709 Section 7.10. If this message is used, it MUST be either unicasted 710 or multicasted to carry home agent information among the redundant 711 home agent set. The Hello message is defined for two purpose: 1) an 712 alive check and 2) home agent information exchange. A home agent 713 Hello message SHOULD be authenticated and encrypted by IPsec ESP when 714 it is unicasted. If a Hello message is multicasted, IPsec ESP cannot 715 be applied. In this case the redundant home agent set should be 716 located in a secure network. Alternatively, all the home agents MUST 717 have a secure channel with each other. The Hello message has the MH 718 Type value TBD. When this value is indicated in the MH Type field, 719 the format of the Message Data field in the Mobility Header is as 720 follows: 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Sequence # | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Home Agent Preference | Home Agent Lifetime | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Hello Interval | Group ID |A|R| Reserved | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | | 732 . . 733 . Mobility Options . 734 . . 735 . | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 8: Home Agent Hello Message 740 Sequence # 742 16-bit unsigned integer. The Sequence number of the Hello message 743 can be used to verify whether this Hello message is the latest one 744 or not. 746 Home Agent Preference 748 16-bit unsigned integer. The preference for the home agent 749 sending this Hello message. This preference is the same as the 750 Home Agent Preference value of the Home Agent Information option 751 as defined in [1]. However, operators MAY use a different 752 preference value for this operation. 754 Home Agent Lifetime 756 16-bit unsigned integer. The lifetime for the home agent sending 757 this Hello message. This lifetime is the same as the Home Agent 758 Lifetime value of the Home Agent Information option as defined in 759 [1]. 761 Hello Interval 763 16-bit unsigned integer. The interval for the home agent sending 764 this Hello message. 766 Group Identifier 768 8-bit unsigned integer. This value is used to identify a 769 particular redundant home agent set. 771 A flag 773 If this flag is set, the sender of this Hello message is an active 774 home agent. Otherwise, the sender is standby home agent 776 R flag 778 If this flag is set, the receiver of this Hello message must send 779 back a Hello message to the sender. 781 Reserved 783 6-bit unsigned integer. It must be initialized to zero by the 784 sender and must be ignored by the receiver. 786 Mobility Options 788 Variable-length field of such length that the complete Mobility 789 Header is an integer multiple of 8 octets long. This field 790 contains zero or more TLV-encoded mobility options. The encoding 791 and format of defined options are described in [1]. The receiver 792 MUST ignore and skip any options which it does not understand. No 793 valid options are defined in this specification. 795 If no options are present in this message, 0 octets of padding are 796 necessary and the Header Len field will be set to 2. 798 6.1.4. Home Agent Switch Message 800 This message is defined in Section 8.3. The Home Agent Reliability 801 protocol extends this message for the Home Agent Hard Switch. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 |# of Addresses |I| Reserved | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 + + 810 . Home Agent Addresses . 811 + + 812 | | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 . Mobility options . 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Figure 9: Home Agent Switch Message 819 IPsec Re-key (I) 821 The IPsec rekey (I) bit is set to indicate that the mobile node 822 SHOULD start an IPsec re-key with the home agent specified in the 823 Home Agent Addresses field. This flag is used when a failed home 824 agent recovers and needs to re-establish IPsec SA/IKE state with a 825 mobile node. 827 Reserved 829 The reserve field is reduced from 8 to 7 bits 831 6.2. New Mobility Options 833 6.2.1. IP address Option 835 This option is already defined in the Fast Handovers for Mobile IPv6 836 (FMIP) specification [12]. This document introduces new Sub-Type 837 values for home agent address and Home Address. 839 Option-Code 841 * 4: Home Agent Address 842 * 5: Home Address 844 6.2.2. Binding Cache Information Option 846 The binding cache information option has an alignment requirement of 847 8n+2. Its format is as follows: 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Type = TBD | Length = 40 | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Flags | Sequence Number | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Lifetime | Reserved | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | | 859 + + 860 | Home Address | 861 + + 862 | | 863 + + 864 | | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | | 867 + + 868 | | 869 + Care-of Address + 870 | | 871 + + 872 | | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 . . 875 . . 876 . Mobile Network Prefix Option . 877 . . 878 . | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Figure 10: Binding Cache Information Option 883 The Binding Cache Information option is only valid in a State 884 Synchronization message. 886 The fields of Home Address, Care-of Address, Flags, Sequence Number, 887 and Lifetime are copied from the registered binding of a particular 888 mobile node or mobile router. The 8-bit Reserved field MUST be set 889 to zero. If the R-flag is set to indicate this binding cache entry 890 is for a mobile router, then this option will be immediately followed 891 by one or more Mobile Network Prefix options. 893 6.2.3. AAA Information Option 895 The AAA option is used to carry the AAA state of the mobile node's 896 Mobile IPv6 sessions. The AAA state information can be conveyed in 897 RADIUS or Diameter AVP formats including the user and session info. 898 This information option is only valid in a State Synchronization 899 message. 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Type = TBD | Length | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 . . 907 . . 908 . AAA AVPs . 909 . . 910 . | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Figure 11: Vendor Specific Inforamtion Option 915 Type 917 8-bit Type value. The value is TBD. 919 Length 921 8-bit length value. 923 AAA AVPs 925 Series of TLV encoded AAA AVPs (including vendor specific AVPs) 926 carrying AAA-related information for each Mobile IPv6 and IPsec/ 927 IKE session. 929 7. Home Agent Operation 931 7.1. Home Agent Address Configuration 933 Each standby home agent obtains its individual IPv6 address from its 934 attached link. This IPv6 address is used by the home agent 935 reliability protocol to exchange information with the associated home 936 agents. The link between home agents should be secured. 938 When the Home Agent Virtual Switch mode is used, the virtual home 939 agent IPv6 address which is known by the mobile node is shared with 940 the standby home agents. When a home agent fails, the standby home 941 agent activates the IPv6 address of the failed home agent and becomes 942 the active home agent. The standby home agent should not activate 943 the IPv6 address until it knows the active home agent is no longer 944 reachable at the address, otherwise address duplication will occur. 945 To guarantee transparency of the home agent virtual switch to mobile 946 nodes located on the home link, the neighbor cache of the home agent 947 IP address MUST be carefully operated. See Section 7.2 in detail. 949 When the Home Agent Hard Switch mode is used, each home agent 950 configures itself with a different IPv6 address from the same home 951 prefix. This IPv6 address can be used for the Home Agent Reliability 952 protocol if the standby home agents are located at the same link of 953 the active home agent (Figure 1). In case of Figure 2, the router 954 must carefully route packets to the standby home agents as described 955 in Section 7.2. Once a mobile node registers its binding with the 956 active home agent, it may solicit an IPsec/IKE exchange with standby 957 home agents. These packets must be routed to the recovery link. 958 This can be achieved by installing host routes for the standby home 959 agents on the recovery link of the router. 961 7.2. Consideration of Routing and Neighbor Discovery Protocol 963 This section gives a brief explanation of how a home agent interacts 964 with routing and Neighbor Discovery Protocol (NDP) when the Home 965 Agent Virtual Switch mode is used. 967 When a standby home agent becomes active in the Home Agent Virtual 968 Switch mode, it MUST start to advertise the home agent address and 969 the home prefix of the home addresses serviced by the redundant home 970 agent set into the routing infrastructure. This operation is 971 normally done using a route selector such as BGP or an OSPF modifier. 972 For example, we can use the AS_Path prepend operation for BGP, and 973 the Metric field in OSPF for route selection. 975 For instance, home agents should run OSPF with the appropriate cost 976 so that the active home agent whose preference is highest can receive 977 the packets from the other routers on the home link. When the active 978 home agent is down, OSPF detects the failure and can dynamically 979 switch the route to the standby home Agent based on the OSPF cost 980 value. If this cost conflicts with the home agent preference value 981 due to misconfiguration, the routers on the home link may not route 982 packets to the desired standby home agent. Therefore, the home agent 983 MAY dynamically change the OSPF cost based on the home agent 984 preference value. Most of router vendors have a private MIB to set 985 the cost via SNMP, though this is a vendor-specific function. The 986 operator can consider other existing approaches to update routes on 987 the routers at the home link. 989 When an active home agent activates a home agent address, it SHOULD 990 use a virtual MAC address as introduced in [4]. When the active home 991 agent is changed, the neighbor cache of the active home agent is not 992 necessarily updated on mobile nodes located on the home link. 993 Otherwise, the new home agent MUST update the neighbor cache entry 994 for the home agent address on all the mobile nodes located on the 995 home link. In addition, Mobile IPv6 uses proxy NDP to intercept 996 packets meant for mobile nodes which are away from the home link. 997 However, it is unnecessary for the new active home agent to overwrite 998 the existing proxy neighbor entries of the mobile nodes. 1000 7.3. Home Agent List Management 1002 In Mobile IPv6 [1], each home agent periodically sends router 1003 advertisements with a Home Address Information option [1] for 1004 exchanging home agent information when there are multiple home agents 1005 present on a link. This information is managed in a home agent list 1006 introduced in [1]. When the Home Agent Reliability Protocol is used, 1007 Hello messages are used to update the home agent list. There are 1008 several reasons to use Hello message instead of Router Advertisement 1009 on the Home Agent Reliability protocol: 1011 1. Router Advertisements are sent among home agents and also to 1012 mobile nodes. When the Home Agent Virtual Switch is used, 1013 standby home agents MUST NOT generate unsolicited Router 1014 Advertisements. The standby home agents MUST be transparent to 1015 all mobile nodes. Hello messages are exchanged only with other 1016 home agents. 1018 2. Router Solicitation and Advertisement messages [8] cannot be used 1019 due to link-local limitations. However, as shown in Section 5.1, 1020 standby home agents are not always configured on the same link. 1021 Router Advertisements cannot be used in this case. 1023 3. The Home Agent Reliability protocol is required to exchange 1024 additional information such as Group ID and Active/Standby Status 1025 of the home agents. 1027 When Hello messages are used, the Home Agent Information Option [1] 1028 MAY NOT be used in Router Advertisements on the home link, because 1029 all necessary information will be present in the Hello messages. 1030 However, mobile nodes located on the home link require this 1031 information for home agent discovery. In addition, if operators want 1032 to use different parameters such as Preference value for home agents 1033 and mobile nodes, they can utilize both Router Advertisements and 1034 Hello messages. Router Advertisements are used to carry the home 1035 agent information for mobile nodes, and Hello message are used to 1036 carry information for Home Agent Reliability operation. If an 1037 operator decides not to use the Hello messages, Router Advertisements 1038 MUST be used to update the home agent list. 1040 Since Hello messages carry all the necessary information filled-in 1041 from the home agent list, the management of the home agent list is 1042 unchanged. If a standby home agent removes an active home agent from 1043 the list because it's lifetime has become zero, it can start recovery 1044 according to this document. < xref target="subsec:failuredetection"/> 1045 describes failure detection in detail. 1047 7.4. Detecting Home Agent Failure 1049 The active and standby home agents can monitor each other's status in 1050 multiple ways. One method is to reuse other failure detection 1051 mechanisms such as VRRP[4] and HSRP[5] described in Section 7.10. 1052 This document also defines its own method by using periodic exchanges 1053 of Hello messages to monitor status. The reasons to specify Hello 1054 messages are: 1056 1. Hello messages can be sent off-link for global recovery is 1057 required by an operator. Router Advertisements cannot be used in 1058 this scenario since their scope is link-local. Thus, Hello 1059 messages are necessary to exchange home agent information among 1060 home agents in a globally redundant home agent set. 1062 2. If Router Advertisements and VRRP are used for periodic messages, 1063 they may not detect the case where the system is running but the 1064 Mobile IPv6 stack is not operational. Mobile IPv6 may be 1065 implemented as a userland daemon, so if Hello messages are used, 1066 the failure of a home agent can be easily detected, assuming 1067 Hello message functionality is implemented in the same home agent 1068 daemon. 1070 3. Hello messages can be frequently exchanged to detect failure, 1071 while there is a restriction on how often Router Advertisements 1072 can be sent, and on how they are processed by routers that 1073 receive them. Router Advertisements are also not sent frequently 1074 enough to rely on their absence to detect a home agent failure. 1076 A Hello request message (R-flag set) may be used by any home agent to 1077 request state information from any other home agent in the redundant 1078 home agent set. If a Hello message is not received from a home agent 1079 peer within a configurable amount of time, then that home agent peer 1080 is considered to have failed. The detail of the Hello message is 1081 described in Section 7.6. Failure events used in the Home Agent 1082 Reliability protocol are listed below. 1084 Loss of Communication with the Active Peer Home Agent 1086 In the event that a standby home agent does not receive any Hello 1087 message from its peer which is currently the active home agent for 1088 a configurable duration, the standby home agent may decide to 1089 become the active home agent. 1091 Monitored Server Failure by the Active Home Agent 1093 There may be number of critical servers in the network that are 1094 essential for the ongoing Mobile IPv6 sessions at the home agent. 1095 One such server may be the AAA server which is receiving the 1096 accounting information for the session. The operator may have a 1097 policy in place that requires the home agent to initiate a switch- 1098 over procedure upon detecting that the link to such a server has 1099 failed. 1101 Routing Peer/Link Failure 1103 In some cases, an operator may require the home agent to detect a 1104 next-hop routing peer failure. If the next-hop routing peer 1105 fails, the operator may want the home agent to initiate a switch- 1106 over procedure if the failure is fatal in nature, or due to some 1107 other routing policies. 1109 7.5. Home Agent Switch Over 1111 After detecting the active home agent has failed, a standby home 1112 agent whose preference value is the highest MUST take over for the 1113 failed home agent. 1115 In the Home Agent Virtual Switch mode, the standby home agent MUST 1116 activate the virtual home agent address. If a virtual MAC address as 1117 introduced in [4] is used, the standby home agent MUST start using 1118 the virtual MAC address as well. Since all the necessary state has 1119 already been transferred to this standby home agent before the active 1120 home agent failed, it can immediately start acting as the active home 1121 agent. 1123 In the Home Agent Hard Switch mode, the standby home agent MUST send 1124 a Home Agent Switch message to all the mobile nodes that were 1125 registered at the failed home agent as described in Section 7.9, 1126 using the pre-established IPsec SA. The home agent switch-over is 1127 complete when it receives binding updates from all the mobile nodes. 1129 7.6. Processing Hello Messages 1131 Hello messages can be unicasted or multicasted. A new multicast 1132 address will be assigned by the IANA. When all home agents in a 1133 redundant home agent set are configured on a same home link, they 1134 MUST join a new multicast address (TBA) and multicast Hello. On the 1135 other hand, if a home link is separated as described in Figure 2, 1136 each home agent MUST unicast Hello messages. 1138 7.6.1. Requesting Hello Message 1140 A home agent can solicit a Hello message from a particular home agent 1141 in the same redundant home agent set by unicasting or multicasting a 1142 Hello message with the R-flag set. The sender MUST fill the fields 1143 of the Hello message with it's home agent information. When a Hello 1144 message is unicasted, only the destination of the Hello message will 1145 answer it. On the other hand, if a Hello message is multicasted, all 1146 the home agents in the multicast group will reply to the Hello 1147 message. This Hello request message SHOULD be generated when: 1149 o A new home agent needs to collect information of the other home 1150 agents in the same redundant home agent set. In this case it 1151 SHOULD multicast a Hello message in which the R-flag is set. 1153 o A home agent entry in the redundant home agent list is about to be 1154 removed due to home agent lifetime expiration. 1156 o A Hello message has not been received during the specified hello 1157 interval. 1159 7.6.2. Sending Hello Message 1161 The Hello message MUST be sent when a home agent receives a Hello 1162 message with the R-flag set, indicating a request is required, 1163 otherwise Hello messages are periodically sent according to the pre- 1164 configured Hello interval. In addition, a home agent SHOULD send a 1165 Hello message to the home agents of the redundant home agent set when 1166 it boots up and its local information, such as home agent preference, 1167 home agent lifetime, and registration status, etc., change. When a 1168 new home agent boots up, it SHOULD solicit Hello messages by 1169 multicasting a Hello message with the R-flag set in parallel with 1170 sending own Hello message. 1172 Whenever a home agent generates Hello message, it MUST increment in 1173 the Sequence Number by 1. It MUST also specify its own Group ID in 1174 the Group ID field of the Hello message. If a home agent is the 1175 active home agent, it MUST set the A-flag in it's Hello Messages. In 1176 the Home Agent Hard Switch mode, the source address of Hello messages 1177 MUST be the configured home agent address. In the Home Agent Virtual 1178 Switch mode, the individual IPv6 addresses of each home agent MUST be 1179 used. 1181 7.6.3. Receiving Hello Message 1183 When a home agent receives a Hello message, it SHOULD verify IPsec 1184 ESP protection. If the message is not protected, it SHOULD be 1185 silently discarded. However, if the Hello messages is sent on a 1186 dedicated link between the home agents, IPsec protection is not 1187 required. If a Hello message is sent from an IPv6 address whose 1188 scope is not global, the message MUST be silently discarded. 1190 If the sending home agent is not in the same redundant home agent 1191 set, the message MUST be silently ignored. This can be done by 1192 comparing the Group ID field of the received Hello message with the 1193 own Group ID value. Hello messages MUST NOT be sent to a home agent 1194 whose Group ID is different from the sender. If the Sequence Number 1195 value in the Hello message is equal to or less than the Sequence 1196 Number value stored in the home agent list entry, the Hello message 1197 MUST be discarded. 1199 Any Hello message satisfying all of these tests MUST be processed to 1200 update the redundant home agent list. The receiver copies home agent 1201 information in the Hello message to the corresponding redundant home 1202 agent list entry. The home agent address of the sender is retrieved 1203 from the Source Address field of the IPv6 header of the Hello 1204 message. If the home agent lifetime field in the Hello message is 1205 set to 0, the receiver removes the sender from the redundant home 1206 agents list. 1208 If the R-flag is set in the received Hello message, the receiver MUST 1209 reply with a Hello message to the originator as described in 1210 Section 7.6.2. 1212 7.7. Processing State Synchronization Messages 1214 It is necessary for standby home agents to synchronize the state 1215 information of each mobile node registered with the active home 1216 agent. In the Home Agent Virtual Switch mode, the synchronized state 1217 information is used by a standby home agent when it takes over for 1218 the failed home agent. In the Home Agent Hard Switch mode, the 1219 standby home agent starts the switch-over of all the mobile nodes 1220 registered to the failed home agent when the home agent failure is 1221 detected. Thus, the Binding Cache entry MUST be modified to keep the 1222 active home agent address of each mobile node. 1224 7.7.1. Soliciting State of a Particular Mobile Node or Subset of Mobile 1225 Nodes 1227 When a standby home agent wants state information for a particular 1228 mobile node or a subset of mobile nodes, such as Binding Cache, AAA, 1229 etc., it MAY solicit this state by sending a State Synchronization 1230 message constructed as follows: 1232 o It MUST set the Type field to 0 (Request). 1234 o It MUST set a random value in the Identifier field. 1236 o It MUST include either a Home Address mobility option indicating 1237 the mobile node, or a Mobile Network Prefix mobility option 1238 indicating the mobile router. The standby home agent can send 1239 multiple home address and mobile network prefix mobility options 1240 to request state information for multiple mobile nodes in a single 1241 State Synchronization request message. 1243 When a home agent receives the State Synchronization message with the 1244 Type field set to 0 (Request), it MUST verify the message as follows: 1246 o The state synchronization message MUST be protected by IPsec ESP. 1248 o The sending home agent MUST belong to the same redundant home 1249 agent set 1251 o The receiver MUST be the active home agent for the requested home 1252 address or mobile network prefix. 1254 Any packet carrying a State Synchronization message which fails to 1255 satisfy all of these tests MUST be silently ignored. 1257 Otherwise, the receiver MUST reply with a State Synchronization 1258 message including state information for the requested mobile node(s) 1259 and/or mobile network prefix(es) as described in Section 1260 Section 7.7.2. 1262 7.7.2. Synchronizing State of Mobile Nodes 1264 A state synchronization message can be sent either: 1266 o When an active home agent receives a state synchronization message 1267 in which the Type field is set to 0 (Request). 1269 o When an active home agent creates a binding cache entry for a 1270 particular mobile node. 1272 o When an active home agent deletes a binding cache entry for a 1273 particular mobile node. 1275 o When an active home agent updates a binding cache entry for a 1276 particular mobile node, only when operating in the Home Agent 1277 Virtual Switch mode. In the Home Agent Hard Switch mode, standby 1278 home agents only use this binding cache information to send a Home 1279 Agent Switch message, so only need a home address of all the 1280 mobile nodes registered to the active home agent of the same 1281 redundant home agent set. 1283 o In a periodic interval to update the state information for all 1284 sessions that changed since the last update. 1286 If an active home agent sends a State Synchronization message 1287 whenever the local state information changes, such as a binding cache 1288 change, the number of the State Synchronization messages sent can be 1289 quite large. 1291 The binding cache information of the requested mobile nodes is stored 1292 in the State Synchronization message. The active home agent MUST 1293 copy the binding cache information of the requested mobile nodes into 1294 Binding Cache Information options. If the State Synchronization 1295 message is sent in response to a State Synchronization request 1296 message, the active home agent MUST copy the Identifier field of the 1297 State Synchronization request message to the Identifier field in the 1298 State Synchronization reply message. Otherwise, it MUST set the 1299 Identifier field to 0. 1301 When the active home agent stores the state of multiple mobile nodes 1302 in a state synchronization message, a Binding Cache Information 1303 option is used as a separator. For each mobile node, a Binding Cache 1304 Information option is placed first, followed by any other options. 1305 When the next Binding Cache Information option is reached in the 1306 State Synchronization message, it indicates the information of a 1307 different mobile node. 1309 A State Synchronization message MUST be authenticated and encrypted 1310 by IPsec ESP mode, otherwise the message MUST be ignored. When a 1311 home agent receives a State Synchronization message, it MUST verify 1312 the Source address field of the IPv6 header. If the source address 1313 does not belong to any home agent in the redundant home agent set, 1314 the message MUST be silently discarded. After successfully verifying 1315 the message, the receiving home agent MUST update its binding cache 1316 and all other necessary information such as AAA and vendor specific 1317 information in the particular database. In the Home Agent Hard 1318 Switch mode, the receiver MUST also record the IPv6 address of the 1319 sender (the active home agent). 1321 7.8. Processing Home Agent Control Messages 1323 7.8.1. Standby Home Agent becomes an Active Home Agent 1325 When a standby home agent decides to become an active home agent, the 1326 standby home agent sends a SwitchOver Request message (a Home Agent 1327 Control message in which the Type field is set to 0) to the active 1328 home agent. This message MUST be unicasted to the active home agent 1329 and MUST be encrypted and authenticated by IPsec ESP. The active 1330 home Agent MUST NOT generate this message. 1332 When an active home agent receives a SwitchOver Request, it first 1333 verifies the received Home Agent Control message. If the request 1334 message is not protected by IPsec, it MUST be silently discarded. If 1335 the home agent is not an active home agent, it MUST send a SwitchOver 1336 Reply message (a Home Agent Control message in which the Type field 1337 is set to 1) with the Status field set to 130 (Not active home 1338 agent). If the receiver is an active home agent and does not want 1339 this standby home agent to become the active home agent, it MUST 1340 reply a SwitchOver reply with the Status field set to 129 1341 (Administratively prohibited). In addition, if the sending home 1342 agent does not belong to the same redundant home agent set, a 1343 SwitchOver Reply message MUST be sent to the sender with the Status 1344 field set to 132 (Not in same redundant home agent set). Otherwise, 1345 the active home agent MUST become a standby home agent and reply with 1346 a SwitchOver Reply message with the Status field set to 0 (Success). 1348 If a home agent receives a SwitchOver Reply message, it MUST be 1349 protected by IPsec ESP. Otherwise, the message MUST be silently 1350 discarded. If the receiving home agent did not send a SwitchOver 1351 Request message, the message MUST be silently ignored. If the Status 1352 field of the SwitchOver Reply message is 0 (Success), the receiving 1353 standby home agent immediately becomes an active home agent. If the 1354 value in the Status field is greater than 128 an error has occurred. 1355 In this case, the receiver MUST NOT become an active home agent. 1357 7.8.2. Active Home Agent becomes in-active 1359 When an active home agent decides to become an in-active home agent, 1360 it sends a SwitchBack Request message (i.e. a Home Agent Control 1361 message with Type field set to 3) to a standby home agent. The 1362 reason for the active home agent to send this message can be 1363 administrative intervention, and events like Monitored Server Failure 1364 by the active home agent or Routing Peer/Link Failure. This message 1365 MUST be unicasted to one of the standby home agents and MUST be 1366 encrypted and authenticated by IPsec ESP. A standby home agent MUST 1367 NOT generate this message. 1369 A SwitchBack Reply is sent in reply to a SwitchBack Request message. 1370 When a home agent receives a SwitchBack Request message, it first 1371 verifies the message. If the SwitchBack Request message is not 1372 protected by IPsec ESP, it MUST be silently discarded. If the 1373 sending home agent of the SwitchBack Request message is not an active 1374 home agent, the receiver MUST reply with a SwitchBack Reply (a Home 1375 Agent Control message in which the Type field is set to 4) in which 1376 the Status field is set to 130 (Not active home agent). If the 1377 sending home agent does not belong to the same redundant home agent 1378 set, a SwitchBack Reply message MUST be sent in which the Status 1379 field set to 132 (Not in same redundant home agent set). Otherwise, 1380 the receiving home agent MUST send a SwitchBack Reply message in 1381 which the Status field is set to 0 (Success). After sending the 1382 SwitchBack reply, it MUST NOT become an active home agent 1383 immediately. This is because the active home agent is still active 1384 until it receives the SwitchBack Reply message acknowledging the 1385 SwitchBack Request. The standby home agent SHOULD change to active 1386 at least after LINK_TRAVERSAL_TIME. 1388 If a home agent receives a SwitchBack Reply message, it MUST be 1389 protected by IPsec ESP, otherwise the message MUST be silently 1390 discarded. If the receiving home agent did not send a SwitchBack 1391 Request message beforehand, the message MUST be silently discarded. 1392 If the Status field of the SwitchBack Reply message is 0 (Success), 1393 the receiving home agent immediately becomes an in-active home agent. 1394 If the value in the Status field is greater than 128, an error has 1395 occurred. In this case, the receiver cannot become an in-active home 1396 agent and MUST continue to be an active home agent. 1398 7.9. Sending Home Agent Switch Messages 1400 This operation is valid only for the Home Agent Hard Switch mode. 1401 The standby home agent MUST send a Home Agent Switch message as 1402 defined in [11] to all the mobile nodes that were being served by the 1403 failed home agent. Since the active home agent address is recorded 1404 in each synchronized binding cache, the standby home agent knows 1405 which mobile nodes were served by the failed home agent. The Home 1406 Agent Switch message must be encrypted with a pre-established SA. 1407 The standby home agent should include its own IPv6 address in the 1408 Home Agent Switch message. Note that a Home Agent Switch message is 1409 sent to each mobile node served by the home agent. If there is a 1410 large number of mobile nodes, sending Home Agent Switch messages will 1411 cause a lot of signaling overhead on the network. 1413 When a failed home agent recovers, it MUST re-establish an IPsec SA 1414 with each mobile node served by its redundant home agent set. 1415 Otherwise, it cannot be either a standby or active home agent for the 1416 mobile nodes. Therefore, it sends a Home Agent Switch message with 1417 the I-flag set to all the mobile nodes serving by other home agents 1418 in the same redundant home agent set, and includes its own home agent 1419 address in the Home Agent Addresses field. 1421 7.10. Interworking with VRRP 1423 VRRP and HSRP specify an election protocol that dynamically assigns 1424 responsibility for a virtual router to one of the VRRP routers on a 1425 LAN. This operation is similar to the Home Agent Virtual Switch 1426 operation. For example, the VRRP router controlling the IP 1427 address(es) associated with a virtual router is called the Master, 1428 and forwards packets sent to these IP addresses. The election 1429 process provides dynamic fail over in the forwarding responsibility 1430 should the Master become unavailable. Although VRRP is used to 1431 guarantee home agent address reachability, it cannot be used for 1432 state synchronization and explicit switching of Master and Backup. 1433 Thus, the Home Agent Reliability protocol cannot be replaced by VRRP. 1434 This section explains how VRRP can interwork with the Home Agent 1435 Reliability protocol. 1437 When VRRP is available, VRRP can replace the Hello message described 1438 in Section 6.1.3. However, some of information is missed by using 1439 VRRP. After receiving a VRRP message, each home agent SHOULD process 1440 the message and store the information as if it receives Home Agent 1441 Hello messages Section 7.6.3. The Home Agents SHOULD still perform 1442 binding cache synchronization as described in Section 7.7 and SHOULD 1443 support the Home Agent Switch message as described in Section 7.9. 1445 In addition to this, VRRP is useful only if all home agents are 1446 located on the same link. If the home agents are topologically 1447 separated, the Home Agent Reliability protocol MUST be used. 1449 0 1 2 3 1450 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 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr| 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 |(rsvd) | Adver Int | Checksum | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | | 1457 + + 1458 | IPv6 Address(es) | 1459 + + 1460 + + 1461 + + 1462 + + 1463 | | 1464 + + 1465 | | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 Figure 12: VRRP Packet Format 1470 The message format of VRRP is described in Figure 12. Each field is 1471 mapped as follows: 1473 Virtual Rtr ID 1475 Group ID is stored in the Virtual Rtr ID field. 1477 Priority 1479 Home Agent Preference is stored in the Priority field. Note that 1480 VRRP only has 8 bits for the Priority field. Therefore, values 1481 larger than 255 MUST NOT be assigned to the preference value. 1483 Count IPv6 IPv6 Addr 1485 This field MUST be always be 1. 1487 Advert Int 1489 This field MUST be mapped to the Hello Interval field of the Home 1490 Agent Hello message, though it only has 12 bytes. 1492 IPv6 address 1494 A home agent address is stored in this field. 1496 Home Agent Lifetime, Sequence Number and Flags field are missing in 1497 the VRRP packet format. Therefore, operators SHOULD use the same 1498 statically configured value for Home Agent Lifetime. Each home agent 1499 does not check freshness of received VRRP message because of no 1500 sequence number. If VRRP is used, a home agent cannot determine the 1501 active home agent from the VRRP message due to lack of A flag, and 1502 cannot request a VRRP advertisement to other home agents. 1504 7.11. Retransmissions and Rate Limiting 1506 Standby and active home agents are responsible for retransmissions 1507 and rate limiting of a State Synchronization Request, Switchover 1508 Request, SwitchBack Request messages for which they expect a 1509 response. The home agent MUST determine a value for the initial 1510 transmission timer: 1512 o If the home agent sends a State Synchronization Request message, 1513 it SHOULD use an initial retransmission interval of 1514 INITIAL_STATE_SYNC_REQ_TIMER. 1516 o If a standby home agent sends a Switchover Request message, it 1517 SHOULD use an initial retransmission interval of 1518 INITIAL_SWICHOVER_REQ_TIMER. 1520 o If an active home agent sends a SwitchBack Request message, it 1521 SHOULD use an initial retransmission interval of 1522 INITIAL_SWICHBACK_REQ_TIMER . 1524 If the sending home agent fails to receive a valid matching response 1525 within the selected initial retransmission interval, it SHOULD 1526 retransmit the message until a response is received. All of the 1527 above constants are specified in Section 10. 1529 The retransmission MUST use an exponential backoff process as 1530 described in [1] until either the home agent receives a response, or 1531 the timeout period reaches the value MAC_HARELIABILITY_TIMEOUT 1532 (16sec). The home agent SHOULD use a separate back-off process for 1533 different message types and different destinations. The rate 1534 limiting of Mobility Header messages is the same as one in [1]. A 1535 home agent MUST NOT send Mobility Header Messages to a particular 1536 home agent more than MAX_UPDATE_RATE (3) times a second, which is 1537 specified in [1]. 1539 8. Mobile Node Operation 1541 Operations described in this section are valid only for the Home 1542 Agent Hard Switch mode. When the Home Agent Virtual Switch is used, 1543 all these operations can be skipped. 1545 8.1. Home Agent Addresses Discovery 1547 To provide home agent reliability with the Home Agent Hard Switch 1548 mode, a mobile node authenticates itself to two or more home agents 1549 and creates IPsec SAs with them during bootstrapping. When one home 1550 agent fails, another home agent can use the pre-existing SA to notify 1551 the mobile node about the failure. 1553 Multiple home agent addresses are available in a home network. In 1554 order to discover these home agent addresses, two different 1555 mechanisms are defined in the bootstrapping solution in the split 1556 scenario [13]. One is DNS lookup by home agent Name, the other is 1557 DNS lookup by Service Name. DHCPv6 can also be used in the 1558 integrated scenario [14] to provide home agent provisioning to mobile 1559 nodes. 1561 In the split scenario, a mobile node can use DNS lookup by Service 1562 Name to discover the home agents, as defined in [13]. For example, 1563 if home agent reliability is required by a mobile node, DNS lookup by 1564 Service Name method is recommended for the mobile node to discover 1565 multiple home agents addresses. Therefore, mobile nodes will query 1566 the DNS SRV records with a service name of mip6 and protocol name of 1567 ipv6. The DNS SRV records includes multiple home agent addresses and 1568 different preference values and weights. The mobile node SHOULD 1569 choose two or more home agents from the home agents list according to 1570 their preference value. Then the mobile node should authenticate 1571 itself to these home agents via an IKEv2 exchange. 1573 In the integrated scenario, a mobile node can use DHCPv6 to get home 1574 agent provisioning from an MSP or ASP, as already defined in [14]. 1575 The only requirement is that the DHCPv6 response must include 1576 multiple home agents' information in order to support home agent 1577 reliability. 1579 8.2. IKE/IPsec pre-establishment to Home Agents 1581 After a mobile node gets multiple home agent addresses, it needs to 1582 trigger multiple IKE exchanges with theh multiple home agents 1583 selected from the home agent list. Since both IKEv1 and IKEv2 can be 1584 used to bootstrap Mobile IPv6, this solution does not introduce any 1585 new operations to co-operate with IKEv1 or IKEv2. It should initiate 1586 IKE for home agents as soon as home registration is complete. 1588 The mobile node MUST follow the standard IKEv2 exchange in the 1589 bootstrapping solution of the split scenario [13], or the IKEv1 1590 bootstrapping solution [15]. Home Address configuration maybe also 1591 be included, if necessary, for the first IKE exchange. After its 1592 Home Address is assigned or approved by the first home agent, mobile 1593 node SHOULD register itself with the second home agent with IKE using 1594 the same Home Address. Therefore, no home address configuration 1595 should be used in the second IKEv2 procedure. Note that the mobile 1596 node only sends a Binding Update message to the first home agent. 1598 8.3. Receiving Home Agent Switch message 1600 A mobile node must follow the operation specified in [11] when it 1601 receives a Home Agent Switch message. 1603 If the I-flag is set in the received Home Agent Switch message, the 1604 mobile node MUST re-key the SA with the home agent addresses stored 1605 in the Home Agent Addresses field. The mobile node MUST NOT change 1606 its active home agent when the I-flag is set. If the home agent 1607 address is not known from the bootstrapping described in Section 8.1, 1608 the mobile node MUST NOT start an IKE session with the unknown home 1609 agent. Instead, it SHOULD re-start home agent discovery again to 1610 update its home agent address information. 1612 When the mobile node receives a Home Agent Switch message without 1613 I-flag set, and if the message contains the IPv6 address of a standby 1614 home agent, it SHOULD pick the standby home agent in the switch 1615 message as the active home agent and send a Binding Update message to 1616 it. The mobile node already has a pre-established SA with the home 1617 agent and should use that SA to send the Binding Update. 1619 9. Security Considerations 1621 Since Mobile IPv6 operation requires ESP in transport mode between 1622 the mobile node and the home agent, we will discuss the ESP field 1623 synchronization issues between the mobile node and the redundant set 1624 of home agents. This synchronization is required only for Home Agent 1625 Virtual Switch mode. Most of fields should be synchronized based on 1626 RFC4301 [9]. The ESP header has the following fields: 1628 SPI 1630 This field identifies the SAD at the receiver. 1632 The mobile node negotiates only one IPsec SA. Hence, the SPI 1633 value will remain unchanged upon home agent failover. 1635 Sequence Number 1637 This field is used for "anti-replay" feature of ESP. The 1638 transmitter must include this monotonically increasing number. 1639 The receiver may process the sequence number based on local 1640 policy. 1642 The mobile node and the redundant home agent set will have the 1643 same set of sequence numbers for transmit and receive. Hence, 1644 synchronization of the sequence number field is mandatory in this 1645 mode of operation. 1647 As described in Section 4, the SA1, SA2, SA3, SA4 could be 1648 synchronized between the home agents as these messages are not 1649 sent continuously. Moreover for the Binding Update case, if the 1650 mobile node is in the middle of sending a Binding Update to an 1651 active home agent for a binding refresh, and the active home agent 1652 is not available at that moment, the mobile node will not get any 1653 response from the active home agent. After a standby home agent 1654 becomes active, the mobile node will retry and it will receive the 1655 Binding Update from the mobile node with a sequence number that is 1656 +n from its last known sequence number for SA1. For the Binding 1657 Acknowledgement case (SA2), the standby home agent SHOULD add a 1658 random number to the last known sequence number over and above the 1659 replay window to ensure that the packet passes the replay check at 1660 the mobile node. The same applies to HoTi and HoT messages with 1661 SA3 and SA4. Note that this windowing of the sequence numbers for 1662 Mobile IPv6 signaling is only needed to cover the corner cases 1663 when Binding Update or HoTi is in-flight and the active home agent 1664 fails. 1666 The technique explained above should work for user data packets if 1667 ESP is used to encrypt user data traffic as well. The actual 1668 switchover time and the routing infrastructure convergence time is 1669 the only latency that the user may perceive. 1671 Initialization Vector 1673 Since the Initialization Vector will be delivered in each exchange 1674 between a mobile node and home agent, this field is not 1675 necessarily synchronized between home agents. 1677 Others 1679 Other fields should be synchronized based on RFC4301[9] 1681 In the Home Agent Hard Switch mode, the standby home agent needs to 1682 send a Home Agent Switch message using IPsec encryption. Since the 1683 mobile node has pre-established an IPsec SA with both the active and 1684 standby home agents, the standby home agent can send the message to 1685 the mobile node with the pre-established IPsec SA. 1687 10. Protocol Constants 1689 INITIAL_STATE_SYNC_REQ_TIMER: 3sec 1691 INITIAL_SWICHOVER_REQ_TIMER: 1sec 1693 INITIAL_SWICHBACK_REQ_TIMER 1sec 1695 LINK_TRAVERSAL_TIME 150msec 1697 11. Contributors 1699 This document is a result of discussions in the Mobile IPv6 Home 1700 Agent Reliability Design Team. The members of the design team that 1701 are listed below are authors that have contributed to this document: 1703 Samita Chakrabarti 1705 samita.chakrabarti@azairenet.com 1707 Kuntal Chowdhury 1709 kchowdhury@starentnetworks.com 1711 Hui Deng 1713 hdeng@hitachi.cn 1715 Vijay Devarapalli 1717 vijay.devarapalli@azairenet.com 1719 Sri Gundavelli 1721 sgundave@cisco.com 1723 Brian Haley 1725 brian.haley@hp.com 1727 Behcet Sarikaya 1729 bsarikaya@huawei.com 1731 Ryuji Wakikawa 1733 ryuji@sfc.wide.ad.jp 1735 12. Acknowledgements 1737 This document includes a lot of text from [16] and [17]. Therefore 1738 the authors of these two documents are acknowledged. We would also 1739 like to thank the authors of the home agent reliability problem 1740 statement [18] for describing the problem succinctly and Alice Qin 1741 for her work on the hello protocol. 1743 13. References 1745 13.1. Normative References 1747 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1748 IPv6", RFC 3775, June 2004. 1750 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1751 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1752 January 2005. 1754 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1755 Levels", BCP 14, RFC 2119, March 1997. 1757 [4] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1758 RFC 3768, April 2004. 1760 [5] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby 1761 Router Protocol (HSRP)", RFC 2281, March 1998. 1763 [6] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1764 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1765 Agents", RFC 3776, June 2004. 1767 [7] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", 1768 draft-ietf-mip6-vsm-00 (work in progress), December 2006. 1770 [8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1771 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1773 [9] Kent, S. and K. Seo, "Security Architecture for the Internet 1774 Protocol", RFC 4301, December 2005. 1776 13.2. Informative References 1778 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 1779 RFC 3753, June 2004. 1781 [11] Haley, B., "Mobility Header Home Agent Switch Message", 1782 draft-ietf-mip6-ha-switch-01 (work in progress), June 2006. 1784 [12] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1785 July 2005. 1787 [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1788 draft-ietf-mip6-bootstrapping-split-02 (work in progress), 1789 March 2006. 1791 [14] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 1792 the Integrated Scenario", 1793 draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in 1794 progress), October 2005. 1796 [15] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6 1797 Bootstrapping with IKEv1", 1798 draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress), 1799 March 2006. 1801 [16] Wakikawa, R., "Inter Home Agents Protocol Specification", 1802 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 1803 March 2006. 1805 [17] Devarapalli, V., "Local HA to HA protocol", 1806 draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), 1807 March 2006. 1809 [18] Faizan, J., "Problem Statement: Home Agent Reliability", 1810 draft-jfaizan-mipv6-ha-reliability-01 (work in progress), 1811 February 2004. 1813 Appendix A. Change Log From Previous Versions 1815 Changes from draft-ietf-mip6-hareliability-00 1817 o Combining State Synchronization Request message and State 1818 Synchronization message 1820 o Combining home agent SwitchOver Request & Reply and SwitchBack 1821 Request & Reply messages. 1823 o Many Editorial Changes 1825 Author's Address 1827 Ryuji Wakikawa 1828 Keio University 1829 Department of Environmental Information, Keio University 1830 5322 Endo, Fujisawa, Kanagawa 252-8520 1831 Japan 1833 Email: ryuji@sfc.wide.ad.jp 1835 Full Copyright Statement 1837 Copyright (C) The IETF Trust (2007). 1839 This document is subject to the rights, licenses and restrictions 1840 contained in BCP 78, and except as set forth therein, the authors 1841 retain all their rights. 1843 This document and the information contained herein are provided on an 1844 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1845 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1846 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1847 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1848 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1849 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1851 Intellectual Property 1853 The IETF takes no position regarding the validity or scope of any 1854 Intellectual Property Rights or other rights that might be claimed to 1855 pertain to the implementation or use of the technology described in 1856 this document or the extent to which any license under such rights 1857 might or might not be available; nor does it represent that it has 1858 made any independent effort to identify any such rights. Information 1859 on the procedures with respect to rights in RFC documents can be 1860 found in BCP 78 and BCP 79. 1862 Copies of IPR disclosures made to the IETF Secretariat and any 1863 assurances of licenses to be made available, or the result of an 1864 attempt made to obtain a general license or permission for the use of 1865 such proprietary rights by implementers or users of this 1866 specification can be obtained from the IETF on-line IPR repository at 1867 http://www.ietf.org/ipr. 1869 The IETF invites any interested party to bring to its attention any 1870 copyrights, patents or patent applications, or other proprietary 1871 rights that may cover technology that may be required to implement 1872 this standard. Please address the information to the IETF at 1873 ietf-ipr@ietf.org. 1875 Acknowledgment 1877 Funding for the RFC Editor function is provided by the IETF 1878 Administrative Support Activity (IASA).