idnits 2.17.1 draft-ietf-mip6-hareliability-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (October 20, 2010) is 4936 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) == Missing Reference: 'HA1-addr' is mentioned on line 339, but not defined == Missing Reference: 'HA2-addr' is mentioned on line 339, but not defined == Missing Reference: 'HA-addr' is mentioned on line 396, but not defined == Missing Reference: 'RFC5723' is mentioned on line 1762, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-13) exists of draft-ietf-mext-rfc3775bis-10 -- Obsolete informational reference (is this intentional?): RFC 3768 (Obsoleted by RFC 5798) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group R. Wakikawa (Editor) 3 Internet-Draft Toyota ITC USA. 4 Intended status: Standards Track October 20, 2010 5 Expires: April 23, 2011 7 Home Agent Reliability Protocol (HARP) 8 draft-ietf-mip6-hareliability-07.txt 10 Abstract 12 The home agent can be a single point of failure when Mobile IPv6 and 13 its associated supporting protocols are operated in a system. It is 14 critical to provide home agent reliability in the event of a home 15 agent crashing or becoming unavailable. This would allow another 16 home agent to take over and continue providing service to the mobile 17 nodes. This document describes the problem scope briefly and 18 provides mechanisms of home agent failure detection, home agent state 19 transfer, and home agent switching for home agent redundancy and 20 reliability. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 23, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2. Problem Statement and Requirements . . . . . . . . . . . . 6 60 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 62 3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 12 63 3.1. Network Configuration . . . . . . . . . . . . . . . . . . 12 64 3.2. Home Agent Address Configuration . . . . . . . . . . . . . 13 66 4. Home Agent Operations . . . . . . . . . . . . . . . . . . . . 13 67 4.1. Home Agent List Management . . . . . . . . . . . . . . . . 13 68 4.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 14 69 4.3. Processing the HARP Messages . . . . . . . . . . . . . . . 15 70 4.3.1. IP field and Security Descriptions of HARP message . . 15 71 4.3.2. Processing Home Agent Hello (HA-HELLO) . . . . . . . . 16 72 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) . . . 17 73 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) . . . 19 74 4.4. State Synchronization . . . . . . . . . . . . . . . . . . 20 75 4.4.1. Binding Cache Information Management . . . . . . . . . 21 76 4.4.2. IP field and Security Descriptions of SS message . . . 21 77 4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 21 78 4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 22 79 4.4.5. Synchronizing State (SS-REP and SS-ACK) . . . . . . . 23 80 4.5. Switching the Active Home Agent . . . . . . . . . . . . . 23 81 4.6. Consideration of Routing and Neighbor Discovery 82 Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 25 83 4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 26 84 4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26 86 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 27 87 5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 27 88 5.2. IPsec/IKE Establishment to Home Agents . . . . . . . . . . 28 89 5.3. Synchronizing State: K-bit treatment . . . . . . . . . . . 28 90 5.4. Receiving Home Agent Switch message . . . . . . . . . . . 29 92 6. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 29 93 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 29 94 6.1.1. HARP Message Format . . . . . . . . . . . . . . . . . 29 95 6.1.2. State Synchronization Message Format . . . . . . . . . 33 96 6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 35 97 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 36 98 6.2.1. Binding Cache Information Option . . . . . . . . . . . 36 99 6.2.2. State Synchronization Status Option . . . . . . . . . 37 100 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 39 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 104 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40 106 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 40 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 110 11. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 40 112 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 115 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 116 13.2. Informative References . . . . . . . . . . . . . . . . . . 42 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 120 1. Introduction 122 In Mobile IPv6 [RFC-3775] and its derivatives protocols like NEMO 123 Basic Support [RFC-3963] and Dual Stack Mobile IPv6 [RFC-5555], if a 124 home agent loses the binding cache state or even network 125 connectivity, due to its failure or some other reason, it results in 126 a loss of service for the mobile nodes. It is beneficial to provide 127 high availability and redundancy for a home agent so that mobile 128 nodes can avail of uninterrupted service even when one home agent 129 crashes or loses state. The Home Agent Reliability protocol (HARP) 130 is designed to manage standby home agents and switch service from an 131 active to a standby home agent in the case of an active Home Agent 132 failing. 134 [RFC-3775] will be updated by [ID-3775bis] soon. 136 1.1. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC-2119]. 142 In this document, the term mobile node refers both to a mobile host 143 [RFC-3775] and a mobile router [RFC-3963]. 145 Mobility related terms used in this document are defined in [RFC- 146 3775] and [RFC-3753]. In addition or in replacement of these, the 147 following terms are defined or redefined: 149 Home Agent Reliability Protocol (HARP) 151 A protocol between Mobile IPv6 Home agents which provides 152 reliability by moving state and service from an active home agent 153 to a standby in the case of the active home agent failing. HARP 154 assumes multiple home agents placement on a same home link or 155 different links and groups them into a redundant home agent set. 156 One of home agents is selected as an active home agent. In case 157 of the active home agent's failure, a standby home agent can take 158 over and become the active home agent. Since each home agent is 159 assigned individual home agent addresses, a mobile node is aware 160 of home agent failures and needs to register its binding to the 161 new active home agent again. 163 Virtual Home Agent Reliability Protocol (VHARP) 164 A protocol between Mobile IPv6 Home agents which provides 165 reliability by cloning an active home agent. Unlike HARP, the 166 standby home agents are an exact copy of the active home agent 167 including home agent IP address. It is similar to the virtual 168 router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. 169 The VHARP operations are transparent to a mobile node. 171 Active Home Agent 173 A home agent that is currently serving the mobile nodes. 175 Standby Home Agent 177 A home agent which can serve the mobile nodes when the active home 178 agent fails. 180 Failed Home Agent 182 A home agent that is not available due to hardware or software 183 failure, system maintenance, etc. 185 Active Home Agent Address 187 An IPv6 address of the Active Home Agent. 189 Standby Home Agent Address 191 An IPv6 address of the Standby Home Agent. 193 Redundant Home Agent Set 195 A grouping which includes an active and standby home agent(s). 196 The Group Identifier is used to identify a redundant home agent 197 set. Operators need to configure a value per redundant home agent 198 set. 200 Virtual Home Agent Address 202 A home agent address shared among home agents in a redundant home 203 agent set. It is similar to virtual router address specified in 204 VRRP [RFC-3768] [RFC-5798]. The address is only activated on an 205 active home agent. 207 Home Agent Preference 208 This preference value is originally defined for Dynamic Home Agent 209 Address Discovery (DHAAD) in RFC3775. This protocol re-uses this 210 preference value for home agent selection when an active home 211 agent has failed. A home agent SHOULD NOT share the same 212 preference value with other home agents. Meanwhile, operators can 213 also define an independent value for the home agent reliability 214 protocol. It is useful when operators want to have different 215 operational policy to the preference values of DHAAD and the Home 216 Agent Reliability Protocol. 218 New Messages 220 Home Agent Reliability Protocol (HARP) message defined in 221 Section 6.1.1: 223 SwitchOver Request (SWO-REQ) 225 SwitchOver Reply (SWO-REP) 227 SwitchBack Request (SWB-REQ) 229 SwitchBack Reply (SWB-REP) 231 Switch Complete (SW-COMP) 233 Home Agent HELLO (HA-HELLO) 235 State Synchronization (SS) message defined in Section 6.1.2: 237 State Synchronization Request (SS-REQ) 239 State Synchronization Reply (SS-REP) 241 State Synchronization Reply-Ack (SS-ACK) 243 1.2. Problem Statement and Requirements 245 In Mobile IPv6 [RFC-3775, RFC-4877], a mobile node registers and 246 establishes a binding with only one home agent. The home agent 247 represents the possibility of a single point of failure for Mobile 248 IPv6. A home agent is responsible for multiple mobile nodes on its 249 home link. The failure of the home agent may then result in the loss 250 of connectivity for numerous mobile nodes located throughout the 251 Internet. To overcome this problem, Mobile IPv6 allows deployment of 252 multiple home agents on the home link so that upon the failure of a 253 home agent, a mobile node can re-establish its connection through a 254 new home agent. However, the base Mobile IPv6 specification does not 255 address home agent fail-over and dynamic transfer of service from one 256 home agent to another. This transfer of service from the failed home 257 agent to a new active home agent requires coordination or pre- 258 configuration among the home agents regarding security associations, 259 transfer of mobile node bindings, and other service information for 260 reliable Mobile IPv6 service in a deployment scenario. 262 For the home agent reliability solution, we define the following 263 generic requirements: 265 Reliable Home Agent service 267 Multiple home agents are available for a home prefix and one of 268 them actively serves the mobile nodes. A standby home agent takes 269 over when the active home agent becomes unavailable. The transfer 270 of the MN-HA association should be transparent to applications and 271 should not take longer than the care-of-addresses update procedure 272 described in Mobile IPv6 [RFC-3775]. 274 Availability of a redundant home agent set 276 Availability of an active home agent address and a standby home 277 agent address at the bootstrapping period for the mobile node is 278 assumed. 280 State Synchronization 282 The information for mobile nodes must be able to be synchronized 283 between an active home agent and standby home agents. This 284 includes the Binding Cache, AAA information, other Mobile IPv6 and 285 NEMO related information. Note that the Home Agent Reliability 286 protocol exchanges only running states of mobile nodes. 287 Therefore, we do not have any specific operation for synchronizing 288 the configuration information. For instance, when Mobile IPv6 is 289 operated with Authentication protocol [RFC-4285], synchronizing 290 the configurations of the Authentication protocol is out of scope 291 in this document. Operators MAY correctly set the configuration 292 information in multiple home agents. 294 Consideration of IPsec/IKE transfer 296 An active home agent maintains several IPsec and IKE states for 297 mobile nodes. These states are synchronized within the redundant 298 home agent set. (Note this is out of scope in this document.) 300 Secured Message Exchanges 301 The messages used between the home agents to transfer binding 302 cache information MAY be authenticated and encrypted. 304 Failure Detection 306 Redundant home agents must actively check for possible failure of 307 an active home agent. If a home agent supports an existing 308 failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC- 309 2281], it can re-use that mechanism to detect the home agent 310 failure. On the other hand, periodic Hello messages are 311 introduced to detect active home agent's service availability in 312 this document. 314 Failure Notification 316 If necessary, a mobile node is notified about the active home 317 agent failure by the standby home agent. 319 2. Protocol Overview 321 HARP works when one or more home agents are provisioned on a home 322 link or different links and these are grouped into a redundant home 323 agent set. One of home agents is selected as an active home agent 324 and receives a binding update from mobile nodes. According to [RFC- 325 3775, RFC-4877], an active home agent maintains not only binding 326 cache but also IPsec/IKEv2 states per mobile node, because Mobile 327 IPv6 relies on IPsec for securing the signaling and optionally user 328 plane traffic. 330 If the active home agent fails, all state information associated with 331 an MN is lost. As a result, all mobile nodes served by the failed 332 home agent will be disconnected. In HARP, other home agents , named 333 standby home agent, exchange the required information with the active 334 home agent in case of failure of the active home agent. HARP can let 335 standby home agent take over the failed home agent with such 336 information of the serving mobile nodes. 338 MN HA1 HA2 339 | [HA1-addr] [HA2-addr] 340 | | | 341 | (active) (standby) 342 | | | 343 | |<--------->| 1. Hello exchanges 344 |<--------->| | 2. Binding Registration to HA1 345 | |<--------->| 3. State exchanges 346 | | | 347 | X | HA1 FAILURE 348 | X | 349 | X | 4. Failure Detection 350 |<----------------------| 5. Sending Home Agent Switch message 351 |<--------------------->| 6. Binding Registration to HA2 352 | X (active) RECOVERY COMPLETE 353 | X | 355 Figure 1: Overview of Home Agent Reliability Protocol (HARP) 357 Figure 1 shows an example of the HARP operations. HA1 and HA2 belong 358 to the same redundant home agent set and are assigned with an 359 individual IP address (HA1 and HA2-addr) at the home link. Each home 360 agent can be seen as an individual home agent by mobile nodes. All 361 the home agents periodically send a hello message (named HA-HELLO) to 362 exchange the home agent information and also monitor the active home 363 agent's status (1). The mobile node registers its binding only with 364 the active home agent (2). The active home agent synchronizes the 365 serving mobile node information (i.e. home address) with the other 366 standby home agents periodically (3). 368 HARP introduces the new HA-HELLO message for failure detection, but 369 it may use any types of information to detect that failure. After 370 detecting failure of the active home agent (4), a standby home agent 371 whose preference value is the highest takes over the failed home 372 agent. For doing so, the standby home agent sends a Home Agent 373 Switch message to all the mobile nodes that were registered at the 374 failed home agent (5). The standby Home Agent sets its own address 375 in the Home Agent Address field in the Home Agent Switch message so 376 that it will receive the binding update from the mobile node as an 377 acknowledgment of the sent Home Agent Switch message. The home agent 378 switch-over is complete when it receives binding updates from all the 379 mobile nodes (6). For protecting the Home Agent Switch, the mobile 380 node should have IPsec Security Associations (SA) with the standby 381 home agent before any failover. The mobile node may pre-establish 382 multiple IPsec SAs with all the home agents. 384 Although the active home agent manages IPsec/IKEv2 states per mobile 385 node, HARP does not offer any recovery mechanism of these states by 386 itself. IPsec/IKE states synchronization is out of scope in this 387 document. If IPsec/IKEv2 states can be recovered from the active 388 home agent to standby one, HARP can be operated slightly in different 389 manner named Virtual-HARP (VHARP). Unlike HARP, the standby home 390 agents are an exact copy of the active home agent. It is similar to 391 the virtual router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC- 392 2281]. Note that HARP is mandatory and VHARP is optional in this 393 document. VHARP is shown in Figure 2. 395 MN HA1 HA2 396 | [HA-addr] [HA-addr'] 397 | | : 398 | (active) (standby) 399 |<--------->| : 1. Binding Registration to HA1 400 | |<--------->: 2. State exchanges 401 | | : 402 | X : HA1 FAILURE 403 | X : 404 | X : 3. Failure Detection 405 | X | 4. HA2 takes over the HA1 406 | X (active) RECOVERY COMPLETE 407 | X | 409 Figure 2: Overview of Virtual Home Agent Reliability Protocol (VHARP) 411 All the home agents (HA1 and HA2) in the redundant home agent set 412 share a virtual home agent address (HA-addr) and the routing will 413 ensure only the active home agent will be reachable using that 414 virtual home agent address. After a mobile node's binding 415 registration (1), the active home agent pushes all the states of its 416 mobile nodes to the other standby home agents (2). In VHARP, all the 417 states of a mobile node need to be synchronized. The example 418 information such as Binding Cache and Authentication, Authorization, 419 and Accounting (AAA) information, etc. 421 After detecting the active home agent has failed (3), the standby 422 home agent whose preference value is the highest takes over the 423 failed home agent. The standby home agent activates the virtual home 424 agent address on its interface attached to the home link. The 425 virtual home agent address's activation can be operated by VRRP. 426 Since all the necessary states of mobile nodes have already been 427 transferred to this standby home agent, the standby home agent can 428 immediately start acting as the active home agent (4). Unlike HARP, 429 the mobile node is not required to re-register its binding to a new 430 active home agent. The mobile node may use the IKEv2 resumption 431 mechanism [RFC-5723] to resume IPsec SA with the new active home 432 agent. 434 This document offers a new management mechanism of active and standby 435 home agents by using a new Mobility Header (MH) message named a HARP 436 message as shown in Figure 3. This mechanism can be used in both 437 HARP and VHARP. Each home agent exchanges own home agent information 438 with the other home agents in its redundancy home agent set by a Home 439 Agent HELLO message (HA-HELLO) (1). The HA-HELLO message can also be 440 used to monitor the availability of the active home agent. 442 HA1(active) HA2 HA3 .. HAn 443 | | | | 444 |<------>|<---->|<---->| 1. HELLO exchange 445 |------->| | | 2. HA1 sends SWB-REQ 446 |<-------| | | 3. HA2 sends SWB-REP 447 |------->| | | 4. HA2 sends SW-COMP 448 (standby) (active) | | HA2 BECOMES ACTIVE HA 449 | | | | 450 SYSTEM MAINTENANCE, ETC. 451 | | | | 452 |------->| | | 5. HA1 sends SWO-REQ 453 |<-------| | | 6. HA2 sends SWO-REP 454 |------->| | | 7. HA1 sends SW-COMP (optional) 455 (active) (standby) | | 8. HA1 returns to active HA 456 | | | | HA1 BECOMES ACTIVE AGAIN 458 Figure 3: Home Agent Management 460 In some scenarios the active home agent may need to stop serving 461 mobile nodes for system maintenance. This specification enables 462 manual intervention for home agent management. As shown in Figure 3, 463 the active home agent (HA1) sends a SwitchBack Request message (SWB- 464 REQ) to a standby home agent (HA2) (2). HA2 will acknowledge the 465 message by sending a SwitchBack Reply message (SWB-REP) to HA1 (3). 466 In the HARP operation, it takes certain time to complete home agent 467 fail-over by mobile nodes' re-registration to the new home agent. 468 During this fail-over operations, HA1 may continue serving the mobile 469 nodes until the switch over is completed. When HA2 decides the 470 switch-over is completed, it MAY send an optional message, SW-COMP, 471 to HA1 (4). As soon as HA2 sends the SW-COMP, it becomes the active 472 home agent. HA1 becomes standby when it receives SW-COMP. If SW- 473 COMP is not used, HA2 and HA1 changes their status appropriately. 475 After the down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2 476 in order to become the active home agent again (5). HA2 acknowledges 477 it by sending a SwitchOver Reply (SWO-REP) to HA1 (6). HA1 now 478 starts home agent fail-over operation. After the completion of fail- 479 over, HA1 sends a SW-COMP to HA2 (7). Then, HA1 returns to the 480 active home agent and HA2 fall back to a standby home agent (8). 482 3. Home Agent Configuration 484 3.1. Network Configuration 486 HARP supports two different configurations for standby home agents. 487 Standby home agents can be placed on the same home link or on a 488 different link. Figure 4 depicts the configuration where home agents 489 serving the same home network are located on the same link as defined 490 in [RFC-3775]. 492 HA1 HA2 HA3 HA4 .... HAn 493 | | | | | 494 --------+------+------+------+--------+--------- 495 Home Link 497 Figure 4: Local Recovery Configuration 499 Figure 5 illustrates when standby home agents are located on a 500 different link (illustrated as Recovery Link in Figure 5). Most 501 large operators have a very stringent requirement on network 502 availability even in the worst type of disaster or outage. This 503 configuration can achieve home agent recovery even if the entire home 504 link fails. This is called geographic redundancy and a well-known 505 configuration for Telecommunications operators. In Figure 5, home 506 agents (HA1-HA4) are placed in geographically separated regions 507 (region-1 and -2). If region-1 suffers a down time due to any 508 reason, all the sessions will be seamlessly taken over by the nodes 509 in region-2. Note that HA3 and HA4 cannot receive packets meant for 510 the home network until the route on the Routers is changed. The 511 routing must be also updated to direct the packets meant for the home 512 link to the recovery link. 514 ---------IGP------>|<---BGP--->|<-----IGP--------- 516 HA1 HA2 HA3 HA4 517 | | | | 518 --------+------+-----+ R---R---R +-----+------+------- 519 Home Link Routers Recovery Link 520 (region-1) (region-2) 521 Figure 5: Global Recovery Configuration 523 3.2. Home Agent Address Configuration 525 In HARP, each home agent obtains its individual IPv6 address from its 526 serving home prefix. In VHARP, all the home agents use a virtual 527 home agent address generated from the home prefix. 529 In addition, each home agent running VHARP needs to obtain its 530 individual IPv6 address from its attached link. This IPv6 address is 531 used only for the VHARP operations between home agents and is not 532 revealed to mobile nodes for binding registration. 534 All the home agents MUST join the ALL_HA_MULTICAST_ADDR. In VHARP, 535 each home agent join the multicast group with its individual IPv6 536 address, but not with virtual home agent address. This multicast 537 address can be used to exchange the HA-HELLO message among the home 538 agents. On the other hand, if a home recovery link is separately 539 defined, each home agent always unicast the HARP messages to home 540 agents configured at a geographically separated link. 542 4. Home Agent Operations 544 4.1. Home Agent List Management 546 In Mobile IPv6, each home agent periodically sends router 547 advertisements with the Home Address Information option [RFC-3775]. 548 HARP introduces a HARP HA-HELLO message to replace the router 549 advertisement. There are several reasons to use HA-HELLO message 550 instead of the Router Advertisement such as: 552 o A HA-HELLO message can be sent beyond the link, while a router 553 advertisement cannot be sent beyond the link. In case of 554 geographic redundancy, router advertisements cannot be sent to the 555 recovery link unless the home link and the recovery link are 556 virtually connected by L2TP, etc. 558 o A HA-HELLO message is defined to manage additional information 559 such as Group ID and Active/Standby Status of the home agents in 560 the home agent list. 562 o A HA-HELLO message is exchange only between home agents, while a 563 router advertisement is also processed by mobile nodes attached to 564 a home link. A HA-HELLO does not introduce any burden to the 565 mobile nodes even if it is frequently sent on the home link. 567 When a HA-HELLO is used to exchange the home agent information, each 568 home agent SHOULD NOT process the Home Agent Information option 569 carried by a Router Advertisement. A router advertisement is only 570 processed by mobile nodes. Operators may define different 571 configuration values to the parameters of the home agent information 572 for a HA-HELLO and a Router Advertisement. 574 This document requires additional information to the home agent list 575 defined in [RFC-3775]. The additional information is learned through 576 HA-HELLO message exchange. 578 o Group ID of a redundant home agent set. It is learned through the 579 Group ID field of the HA-HELLO. 581 o HA-HELLO Interval. This value is locally configured at every home 582 agent by operators and is learned through the Hello Interval field 583 of the HA-HELLO. 585 o An individual home agent address used in the VHARP operation. 586 This information is only required when VHARP is used in addition 587 to the virtual home agent address. It is learned through the 588 Source Address of the HA-HELLO message. 590 o VHARP capability. This information is learned through the V flag 591 of the HA-HELLO message. 593 o Current mode (HARP or VHARP). This information is learned through 594 the M flag of the HA-HELLO message. 596 o Active status. This information is learned through the A flag of 597 the HA-HELLO message. 599 4.2. Detecting Home Agent Failure 601 An active and standby home agents can monitor each other in several 602 ways. One method is to reuse other failure detection mechanisms 603 defined in VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. However, 604 VRRP and HSRP are not sufficient since they cannot detect the case 605 where the system is running but the Mobile IPv6 stack is not 606 operational. Failure events used in HARP/VHARP are listed below. 608 Loss of HA-HELLO 610 HARP/VHARP is an extension to Mobile IPv6 and can monitor 611 availability of Mobile IPv6 stack on each home agent by 612 periodically sending a HA-HELLO as a heart-beat. This HA-HELLO 613 can also be exchanged frequently enough to detect the failure 614 promptly without any additional overhead to mobile nodes attached 615 to the home link. In the event that a standby home agent does not 616 receive any HA-HELLOs from its peer for a configurable duration, 617 the standby home agent assumes that home agent's failure. The 618 detail of the Hello message is described in Section 4.3.2. 620 Monitored Server Failure by the Active Home Agent 622 There may be number of critical servers such as an AAA server in 623 the network that are essential for the ongoing Mobile IPv6 624 sessions at the home agent. Operators can have a policy in place 625 that the active home agent is treated as a failed home agent upon 626 detecting that the link to such servers has failed. 628 Routing Peer/Link Failure 630 Operators may require the home agent to detect its next-hop 631 routing peer failure. If the next-hop routing failure is fatal in 632 nature, or due to some other routing policies, the active home 633 agent is treated as a failed home gent and the recovering 634 operation should be started. 636 4.3. Processing the HARP Messages 638 4.3.1. IP field and Security Descriptions of HARP message 640 The HARP message format is defined in Section 6.1.1. If a HARP 641 message is unicast, the destination address is one of Home Agent in 642 the same Redundant Home Agent set. If it is HA-HELLO message (by 643 setting the type field to 4), it can be multicast. The destination 644 address MUST be set to ALL_HA_MULTICAST_ADDR. The source address 645 MUST be set to the sender's home agent address. Note that, in VHARP, 646 the virtual home agent address SHOULD NOT be set to source or 647 destination address. The IP address of the interface the packet is 648 being sent from SHOULD be used. 650 If a HARP message is unicast, it SHOULD be secured by IPsec ESP. If 651 a HA-HELLO message is multicast, multicast extensions to IPsec [RFC- 652 5374] SHOULD be applied. If all the home agents are placed in a 653 secure transport network to exchange a HARP message, authentication 654 and encryption MAY be omitted. Which security verification is used 655 depends on operational policy. If security verification is failed 656 for a receiving HA-HELLO, the HA-HELLO MUST be discarded. 658 The following operations MUST be performed when transmitting a HARP 659 message. 661 o The incremented latest Sequence Number MUST be set to the Sequence 662 Number field. The Sequence Number SHOULD be initialized to zero 663 for the first Hello message. To accomplish sequence number 664 rollover, if the sequence number has already been assigned to be 665 the largest possible number representable as a 16-bit unsigned 666 integer, then when it is incremented it will then have a value of 667 zero (0). 669 o The sender's Group ID MUST be set to the Group ID field. 671 o The V-flag MUST be set if the sender is capable of VHARP. 673 o The M-flag MUST be unset if the sender is operated with HARP. 675 o The M-flag MUST be set if the sender is operated with VHARP. 677 o The A-flag MUST be set if the sender is the active home agent. 679 The following functions MUST be performed when a HARP message is 680 received. 682 o MUST verify the Group ID of the HARP message is equal to the 683 receiver's Group ID. 685 o MUST verify the sender of the HARP message belongs to the 686 receiver's same redundant home agent set 688 o MUST verify that the M flag is equal to the receiver's operating 689 mode. 691 o MUST verify the Sequence Number value in the HARP is larger than 692 the last received Sequence Number value. When the sequence number 693 rollover is occurred, the sequence number value in the HA-HELLO is 694 zero. 696 If any one of the above checks fails, the receiver SHOULD discard the 697 HARP message. 699 4.3.2. Processing Home Agent Hello (HA-HELLO) 701 4.3.2.1. Sending HA-Hello Message 703 Each home agent MUST send a HA-HELLO in following case: 705 o UNSOLICITED: Each home agent SHOULD periodically send a HA-HELLO. 706 The interval time is configured locally at each home agent. 708 o UNSOLICITED: When a home agent detects its local information 709 change, it should immediately send a HA-HELLO. 711 o SOLICITED: when a home agent receives a HA-HELLO with the R-flag 712 set, the HA-HELLO can be requested to the destination home agent. 714 A home agent can solicit a HA-HELLO to a particular home agent(s) in 715 the same redundant home agent set by unicasting or multicasting a HA- 716 HELLO with the R-flag set. Soliciting HA-HELLO is operated when: 718 o A new home agent boots up. The new home agent SHOULD solicit HA- 719 Hello messages by multicasting a HA-Hello message with the R-flag 720 set. 722 o A HA-HELLO has not been received after the specified hello 723 interval. The HA-HELLO MAY be solicited to the home agent. 725 o A home agent entry in the redundant home agent set is about to be 726 removed due to home agent lifetime expiration. The HA-HELLO 727 SHOULD be solicited to the home agent whose lifetime is soon 728 expired. 730 In addition to Section 4.3.1, the following operations MUST be 731 performed when transmitting a HA-HELLO. 733 o The Type field MUST be set to 4. 735 o The R-flag MUST be set if the sender solicits a HA-HELLO to the 736 other home agent(s). 738 o The appropriate home agent configuration values MUST be copied to 739 the Home Agent Preference, the Home Agent Lifetime, and Hello 740 Interval fields. 742 4.3.2.2. Receiving Hello Message 744 The receiver MUST perform the verification to the HA-HELLO described 745 in Section 4.3.1. After the verification, the receiver copies the 746 value stored in the HA-HELLO message to the corresponding home agent 747 list entry according to Section 4.1. 749 If the home agent lifetime field in the HA-HELLO is set to 0, the 750 receiver MUST remove the sender home agent from the home agents list. 752 If the R-flag is set in the received HA-HELLO, the receiver MUST send 753 a new HA-HELLO to the originator as described in Section 4.3.2.1. 755 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) 757 When a standby home agent decides to become an active home agent, the 758 standby home agent sends a SwitchOver Request (SWO-REQ) to the 759 current active home agent with the following operations. 761 o MUST be unicast only to the current active home agent 763 o MUST be sent from a standby home agent. The active home Agent 764 MUST NOT generate this message. 766 When an active home agent receives a SWO-REQ, it MUST operate the 767 following verifications and operations in addition to Section 4.3.1 769 o If the receiver of the SWO-REQ is not an active home agent, it 770 MUST send a SWO-REP with the Status field set to 130 (Not active 771 home agent). 773 o If the sender home agent does not belong to the same redundant 774 home agent set, a SWO-REP message MUST be sent to the sender with 775 the Status field set to 132 (Not in same redundant home agent 776 set). 778 o If there are any other reasons that the receiver cannot accept the 779 SWO-REP, the active home agent MUST reply a SWO-REP with the 780 Status field set to 129 (Administratively prohibited). 782 o Otherwise, the active home agent MUST become a standby home agent 783 and reply with a SWO-REP message with the Status field set to 0 784 (Success). 786 When a standby home agent receives a SWO-REP, it MUST operate the 787 following verifications and operations in addition to Section 4.3.1: 789 o If the receiver is an active home agent, the SWO-REP MUST be 790 discarded. 792 o If the standby home agent receives an unexpected SWO-REP which is 793 not in reply to its SWO-REQ, it MUST ignore the SWO-REP. 795 o Otherwise, if the Status field of the SWO-REP is 0 (Success), the 796 standby home agent (the receiver of SWO-REP) immediately becomes 797 an active home agent. 799 o If the value in the Status field is greater than 128 an error has 800 occurred. In this case, the receiver MUST NOT attempt to be an 801 active home agent. 803 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) 805 When an active home agent decides to become a standby home agent, it 806 sends a SWB-REQ to one of standby home agents. The reason for the 807 active home agent to send this message can be administrative 808 intervention, and events like Monitored Server Failure by the active 809 home agent or Routing Peer/Link Failure. The following operations 810 MUST be performed when SWB-REQ is sent. 812 o MUST be unicast only to one of standby home agents in the same 813 redundant home agent set 815 o MUST be sent from an active home agent. A standby home Agent MUST 816 NOT generate this message. 818 When a home agent receives a SWB-REQ message, it verifies the message 819 as follows. 821 o If the sender home agent of the SWB-REQ is not an active home 822 agent, the receiver MUST reply a SWB-REP with the Status field is 823 set to 130 (Not active home agent). 825 o If the sending home agent does not belong to the same redundant 826 home agent set, a SWB-REP MUST be sent in which the Status field 827 set to 132 (Not in same redundant home agent set). 829 o Otherwise, the receiving home agent MUST send a SWB-REP with the 830 Status field set to 0 (Success). 832 o After sending the SWB-REP, the standby home agent MUST NOT become 833 an active home agent immediately. This is because the active home 834 agent is still active until it receives the SWB-REP which is 835 acknowledging the SWB-REQ. The standby home agent SHOULD change 836 to active at least after LINK_TRAVERSAL_TIME. The default value 837 of LINK_TRAVERSAL_TIME is defined in Section 9. 839 When a home agent receives a SWB-REP message, it verifies the message 840 as follows. 842 o If the standby home agent receives an unexpected SWB-REP which is 843 not in reply to own SWB-REQ, it SHOULD ignore the SWO-REP. 845 o If the Status field of the SWB-REP is 0 (Success), the active home 846 agent immediately becomes a standby home agent. The sender home 847 agent of SWB-REP becomes an active home agent after certain time, 848 LINK_TRAVERSAL_TIME. 850 o If the value in the Status field is greater than 128, the receiver 851 of SWB-REP (active home agent) cannot become a standby home agent 852 and MUST continue to be an active home agent. 854 4.4. State Synchronization 856 A State Synchronization (SS) message format is defined in 857 Section 6.1.2. It can carry multiple aspects of the state 858 information associated with a mobile node by setting mobility options 859 in the Mobility Options field. The following list shows examples of 860 the mobility options which can be specified in the state 861 synchronization message. 863 o IPv6 Home Address (Binding Cache Option) 865 o Binding Cache Information (Binding Cache Option) 867 o NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC- 868 3963]) 870 o IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555]) 872 o IPv4 Home Address (IPv4 Home Address Option [RFC-5555]) 874 o Binding Identifier (Binding Identifier Option [RFC-5648] 876 o AAA states (AAA Information Option) 878 o Miscellaneous states (Vendor Specific Mobility Option [RFC-5094]) 880 When a home agent needs to send the state of multiple mobile nodes in 881 a single state synchronization message (SS-REQ or SS-REP), a Binding 882 Cache Information option is used as a separator. For each mobile 883 node, a Binding Cache Information option is placed first, followed by 884 any other options related to the mobile node if necessary. 886 In HARP, since a mobile node will re-register to the new active home 887 agent after home agent fail-over, it is not necessary for the standby 888 home agents to synchronize all the mobile nodes' state information. 889 The standby home agent only need to collect the home address 890 information of all the mobile nodes served by the active home agent. 891 The information is used to send the Home Agent Switch messages to all 892 the mobile node when the home agent failure is occurred. 894 In the case of VHARP, home agent fail-over is accomplished without 895 the mobile nodes having to perform re-registration. Therefore, 896 standby home agents need to copy the complete state information of 897 each mobile node registered with the active home agent. 899 4.4.1. Binding Cache Information Management 901 In HARP, each standby home agent learns the partial binding cache 902 information such as a pair of a home address and a mobile node's 903 registering home agent address. 905 In VHARP, a standby home agent ideally copies the received binding 906 cache information and other mobile node's information into the 907 appropriate database so that it can act as an active home agent as 908 soon as it takes over the failed home agent. 910 4.4.2. IP field and Security Descriptions of SS message 912 A state synchronization message is unicast. The destination address 913 MUST be one of home agents in the same Redundant Home Agent set. The 914 source address MUST be set to the sender's home agent address. Note 915 that, in VHARP, the virtual home agent address MUST NOT be set to the 916 source address. IP address of the interface the packet is being sent 917 from SHOULD be used. 919 It SHOULD be secured by IPsec ESP. If all the home agents are placed 920 in a secure transport network to exchange the state synchronization 921 message, authentication and encryption MAY be omitted. If security 922 verification is failed for a receiving state synchronization message, 923 the message MUST be discarded. The choice of security mechanism used 924 depends on the operational model of the network. 926 4.4.3. Requesting State of Mobile Nodes (SS-REQ) 928 When a home agent needs the state information for a particular mobile 929 node or a subset of mobile nodes, it sends a SS-REQ message 930 constructed as follows: 932 o MUST set the Type field to 0 (Request). 934 o MUST set a random value in the Identifier field that does not 935 coincide with any other currently pending Requests. 937 o MUST include a Binding Cache Information option(s) which Home 938 Address field is set to the target home address. Other fields of 939 the Binding Cache Information option can be omitted. 941 o MUST set the unspecified address (::) in the Home Address field of 942 the Binding Cache Information option, if it solicits the state of 943 all the mobile nodes registering at the destination home agent of 944 the SS-REQ message. 946 o MUST include multiple binding cache information options in a SS- 947 REQ, if the sender requests multiple mobile nodes' information. 948 The sender SHOULD NOT send multiple SS-REQs per mobile node. 950 o MUST send a SS-REQ to the active home agent of the target mobile 951 node(s). 953 When a home agent receives a SS-REQ, it MUST perform the verification 954 described in Section 4.4.2 and following: 956 o If the receiver does not know the binding cache for the target 957 mobile node(s) specified in the received Binding Cache Information 958 option(s), it MUST ignore the SS-REQ and MUST NOT reply a SS-REQ. 960 o Otherwise, the receiver MUST reply a SS-REP including all the 961 state information of the target mobile node(s). 963 4.4.4. Sending State Information (SS-REP) 965 A SS-REP message(s) SHOULD be sent when: 967 1. The active home agent receives a SS-REQ. 969 2. The active home agent creates or deletes a binding cache entry 970 for a particular mobile node. 972 The active home agent MAY additionally send a SS-REP message in 973 following cases: 975 1. The active home agent updates the state information for all 976 sessions that changed since the last update in a periodic 977 interval 979 2. Often in VHARP, the active home agent MAY update a binding cache 980 entry for a particular mobile node whenever the binding cache 981 entry is updated. If an active home agent sends a SS-REP message 982 whenever the local state information changes, such as a binding 983 cache change, the number of the SS-REP messages can be quite 984 large. 986 Following rules must be applied when the active home agent constructs 987 a SS-REP. 989 o MUST copy the Identifier field of the SS-REQ to the same field of 990 the SS-REP, if the SS-REP is sent in response to the SS-REQ. 992 o MUST set zero to the Identifier field if the SS-REP is sent 993 without solicitation (no SS-REQ). 995 o MUST include required mobility options in the SS-REP. 997 * In HARP, a partial Binding Cache Information Option (the Home 998 Address Field only) MUST be included in the SS-REP. 1000 * In VHARP, a full Binding Cache Information Option and other 1001 required options shown in Section 6.1.2 MUST be included in the 1002 SS-REP. 1004 o MUST include the state of all the active mobile nodes registering 1005 in the active home agent by the SS-REP when the unspecified 1006 address is found in the Home Address mobility option carried with 1007 the SS-REQ. The message may be fragmented depending on the total 1008 size needed to carry all states. 1010 4.4.5. Synchronizing State (SS-REP and SS-ACK) 1012 When a home agent receives a SS-REP, it MUST take the following 1013 operations. 1015 o If no options are carried in the SS-REP, the home agent just 1016 ignores the SS-REP. 1018 o If the sender of SS-REP is not in the same global home agent set, 1019 the home agent MUST reject the SS-REP and MUST send SS-ACK with 1020 the Status Synchronization Status option which status value is set 1021 to [130: Not in same global home agent set] 1023 o The receiver home agent MUST record the IPv6 address of the sender 1024 as the active home agent of the mobile node in its local binding 1025 cache. 1027 o The receiver home agent MUST update its binding cache and all 1028 other necessary information in a particular database(s). 1030 o The receiver home agent MUST send a SS-ACK with state 1031 synchronization status mobility options if A flag is set. 1033 If an active home agent requires an acknowledgment of a SS-REP, it 1034 MUST set the Ack flag in the SS-REP. The receiver of such SS-REP 1035 will send back a SS-ACK. The receiver MUST copy the Identifier value 1036 received in the SS-REP into SS-ACK in order to match the SS-REP and 1037 SS-ACK. 1039 4.5. Switching the Active Home Agent 1041 In HARP, the standby home agent which is going to be active MUST send 1042 a Home Agent Switch message [RFC-5142] to all the mobile nodes that 1043 were being served by the failed home agent. The following rules MUST 1044 be applied when transmitting a Home Agent Switch message. 1046 o MUST use IPsec ESP to protect the Home Agent Switch message. 1048 o MUST set the address of the standby home agent address who is the 1049 sender of this Home Agent Switch message in the Home Agent Address 1050 field of the Home Agent Switch message [RFC-5142]. 1052 If there are a large number of mobile nodes served by the failed home 1053 agent, the overhead sending Home Agent Switch messages is high. This 1054 overhead cannot be avoided if the active home agent suddenly stop 1055 serving mobile node because of unexpected reasons (crash, network 1056 trouble, etc). However, if this switch over is operated under the 1057 administrative operation (maintenance, etc), the previous active home 1058 agent may continue serving the mobile nodes until the switch over is 1059 completed. Until the mobile node sends a binding update to the new 1060 active home agent, it still sends the packet to the previous home 1061 agent. 1063 Therefore, the new active home agent can notify the completion of 1064 switch-over to the previous active home agent by using a SW-COMP 1065 message. When the new active home agent completes the switch-over, 1066 it SHOULD send a SW-COMP to the previous active home agent. Until 1067 the previous home agent receives this message, it SHOULD continue 1068 serving any mobile nodes that are registered with it. Once the 1069 previous home agent receives the SW-COMP message, it can be shutdown 1070 or detached from the network safely. 1072 In VHARP, after detecting the active home agent has failed, the 1073 standby home agent whose preference value is the highest MUST take 1074 over the failed home agent. The standby home agent MUST activate the 1075 virtual home agent address and its virtual MAC address. A virtual 1076 MAC address as introduced in [RFC-3768, RFC-5798] SHOULD be used in 1077 VHARP. If VHARP run with VRRP and HSRP as described in Section 4.7, 1078 the virtual home agent address can be treated as a virtual router 1079 address in VRRP and HSRP. Therefore, VRRP and HSRP can automatically 1080 activate the virtual home agent address on the standby home agent 1081 after their election mechanism. Since all the necessary state has 1082 already been transferred to this standby home agent before the active 1083 home agent failed, it can immediately start acting as the active home 1084 agent. 1086 When the failed home agent recovers from failure and would return to 1087 the active home agent, it MUST re-establish IPsec SA with all the 1088 mobile nodes. All the mobile nodes lost IPsec SA with the home agent 1089 when the failure has occurred. Otherwise, it cannot be either a 1090 standby or active home agent for the mobile nodes. Therefore, as 1091 soon as the active home agent detects the recovery of the failed home 1092 agent, it sends a Home Agent Rekey message to all the mobile nodes 1093 served by other home agents in the same redundant home agent set, and 1094 includes the recovered home agent address in the Home Agent Addresses 1095 field. The detail of the Home Agent Rekey message is described in 1096 Section 6.1.3. The mobile node will re-key the SA by using The IKEv2 1097 resumption mechanism [RFC-5723]. Alternatively, the mobile node MAY 1098 start a new IKE session with the recovered home agent. 1100 4.6. Consideration of Routing and Neighbor Discovery Protocol (VHARP) 1102 This section gives a brief explanation of how a home agent interacts 1103 with routing and Neighbor Discovery Protocol (NDP) when is VHARP 1104 used. 1106 When a standby home agent becomes active in VHARP, it MUST start to 1107 advertise the home agent address and the home prefix of the home 1108 addresses serviced by the redundant home agent set into the routing 1109 infrastructure. This operation is normally done using a route 1110 selector such as BGP or an OSPF modifier. For example, we can use 1111 the AS_Path prepend operation for BGP, and the Metric field in OSPF 1112 for the route selection. When each home agent participates in OSPF 1113 routing, each home agent should be configured with the appropriate 1114 metric matched to the home agent preference value. When the active 1115 home agent fails, OSPF detects the failure and can dynamically switch 1116 the route to the standby home Agent based on the OSPF cost value. If 1117 this creates conflicts with the home agent preference value due to 1118 configuration errors, the routers on the home link may not route 1119 packets to the desired standby home agent. In order to change the 1120 OSPF cost correctly and dynamically, The operator takes other 1121 existing approaches. For example, most of router vendors have a 1122 private MIB to set the cost via SNMP, though this is a vendor- 1123 specific function. 1125 When an active home agent activates a home agent address, it SHOULD 1126 use a virtual MAC address as introduced in [RFC-3768, RFC-5798]. 1127 When the active home agent is changed, the neighbor cache of the 1128 active home agent is not necessarily updated on mobile nodes located 1129 on the home link. Otherwise, the new home agent MUST update the 1130 neighbor cache entry for the home agent address on all the mobile 1131 nodes located on the home link. In addition, Mobile IPv6 uses proxy 1132 NDP to intercept packets meant for mobile nodes which are away from 1133 the home link. However, it is unnecessary for the new active home 1134 agent to overwrite the existing proxy neighbor entries of the mobile 1135 nodes. 1137 4.7. Interworking with VRRP 1139 VRRP and HSRP specify an election protocol that dynamically assigns 1140 responsibility for a virtual router to one of the VRRP routers on a 1141 LAN. This operation is similar to the VHARP. For example, the VRRP 1142 router controlling the IP address(es) associated with a virtual 1143 router is called the Master, and forwards packets sent to these IP 1144 addresses. The election process provides dynamic fail over in the 1145 forwarding responsibility should the Master become unavailable. 1146 Although VRRP is used to guarantee home agent address reachability, 1147 it cannot be used for state synchronization and explicit switching of 1148 Master and Backup. Thus, the Home Agent Reliability Protocol cannot 1149 be replaced by VRRP. This section explains how VRRP can interwork 1150 with HARP/VHARP. 1152 When VRRP is available, VRRP can replace the Hello message described 1153 in Section 6.1.1. However, some of information is missed by using 1154 VRRP. After receiving a VRRP message, each home agent SHOULD process 1155 the message and store the information as if it receives Home Agent 1156 Hello messages Section 4.3.2.2. The message format of VRRP can be 1157 found in Section 5.1 of [RFC-5798]. Each field is mapped as follows: 1159 o Virtual Rtr ID: Group ID is stored in the Virtual Rtr ID field. 1161 o Priority: Home Agent Preference is stored in the Priority field. 1162 Note that VRRP only has 8 bits for the Priority field. Therefore, 1163 values larger than 255 MUST NOT be assigned to the preference 1164 value. 1166 o Count IPv6 IPv6 Addr: This field MUST be always be 1. 1168 o Max Advert Int: This field MUST be mapped to the Hello Interval 1169 field of the Home Agent Hello message, though it only has 12 1170 bytes. 1172 o IPv6 address: A home agent address is stored in this field. 1174 Home Agent Lifetime, Sequence Number and Flags field are missed in 1175 the VRRP packet format. Therefore, operators SHOULD use the same 1176 statically configured value for Home Agent Lifetime. Each home agent 1177 does not check freshness of received VRRP message because of no 1178 sequence number. 1180 4.8. Retransmissions and Rate Limiting 1182 Home agents are responsible for retransmissions and rate limiting of 1183 SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response. 1184 The home agent MUST determine a value for the initial transmission 1185 timer: 1187 o If the home agent sends a SS-REQ message, it SHOULD use an initial 1188 retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER. 1190 o If a home agent sends a SWO-REQ or SWB-REQ message, it SHOULD use 1191 an initial retransmission interval of INITIAL_SWITCH_REQ_TIMER. 1193 If the sending home agent fails to receive a valid matching response 1194 within the selected initial retransmission interval, it SHOULD 1195 retransmit the message until a response is received. All of the 1196 above constants are specified in Section 8. 1198 The retransmission MUST use an exponential backoff process as 1199 described in [RFC-3775] until either the home agent receives a 1200 response, or the timeout period reaches the value 1201 MAC_HARELIABILITY_TIMEOUT. The home agent SHOULD use a separate 1202 back-off process for different message types and different 1203 destinations. The rate limiting of Mobility Header messages is the 1204 same as one in [RFC-3775]. A home agent MUST NOT send Mobility 1205 Header Messages to a particular home agent more than MAX_UPDATE_RATE 1206 (3) times a second, which is specified in [RFC-3775]. 1208 5. Mobile Node Operation 1210 This section describes the operations of a mobile node only when HARP 1211 is used. None of the operations in this section is required in 1212 VHARP. 1214 5.1. Home Agent Addresses Discovery 1216 A mobile node authenticates itself to two or more home agents and 1217 creates IPsec SAs with them during bootstrapping. When the active 1218 home agent fails, another home agent can use the pre-existing SA to 1219 notify the mobile node about the failure by sending a Home Agent 1220 Switch message. 1222 In order to discover multiple home agent addresses, two different 1223 mechanisms are defined in the bootstrapping solution in the split 1224 scenario [RFC-5026]. One is DNS lookup by home agent Name, the other 1225 is DNS lookup by Service Name. DHCPv6 can also be used in the 1226 integrated scenario [ID-BOOTINT] to provide home agent provisioning 1227 to mobile nodes. 1229 In the split scenario, a mobile node can use DNS lookup by Service 1230 Name to discover the home agents, as defined in [RFC-5026]. For 1231 example, if home agent reliability is required by a mobile node, DNS 1232 lookup by Service Name method is recommended for the mobile node to 1233 discover multiple home agents addresses. Therefore, mobile nodes 1234 will query the DNS SRV records with a service name of mip6 and 1235 protocol name of ipv6. The DNS SRV records includes multiple home 1236 agent addresses and different preference values and weights. The 1237 mobile node SHOULD choose two or more home agents from the home 1238 agents list according to their preference value. Then the mobile 1239 node should authenticate itself to these home agents via an IKEv2 1240 exchange. 1242 In the integrated scenario, a mobile node can use DHCPv6 to get home 1243 agent provisioning from an MSP or ASP, as already defined in [ID- 1244 BOOTINT]. The only requirement is that the DHCPv6 response must 1245 include multiple home agents' information in order to support home 1246 agent reliability. 1248 5.2. IPsec/IKE Establishment to Home Agents 1250 In this document, a mobile node need to manage an IPsec SA with a 1251 home agent(s). The following mechanism can be used to manage the 1252 IPsec SA(s) with a home agent(s). 1254 o IKEv1/v2 running per home agent (HARP) to establish multiple IPsec 1255 SAs for home agents. 1257 o The IKEv2 resumption mechanism [RFC-5723] to update an IPsec SA 1258 with the new home agent (VHARP) 1260 If IPsec/IKEv2 state synchronization mechanism is available in 1261 Virtual Private Network (VPN) products, none of above is required for 1262 the VHARP operation. The IPsec SAs per mobile node are seamlessly 1263 copied among multiple home agents. 1265 The mobile node MUST follow the standard IKEv2 exchange in the 1266 bootstrapping solution of the split scenario [RFC-5026]. If multiple 1267 IKEv2 are run per home agent, the mobile node MUST NOT attempt the 1268 home address assignment to standby home agents. 1270 5.3. Synchronizing State: K-bit treatment 1272 When a mobile node moves and the care-of address changes, it can use 1273 the Key Management Mobility Capability (K) bit in the Binding Update 1274 in order to update the peer endpoint of the key management protocol 1275 (ex. IKE Security Association). 1277 If an active home agent receives a Binding Update which K-bit is set, 1278 it MUST process the Binding Update as [RFC-3775]. In addition, the 1279 active home agent MUST notify the care-of address change to the other 1280 standby home agents. For doing so, it MUST send State 1281 Synchronization Reply message including Binding Cache Information 1282 option to all the other standby home agents. The flags of the 1283 Binding Update (ex. K-bit) MUST be copied to the flags field of the 1284 Binding Cache Information option. After all, the standby home agents 1285 know the existence of K-bit set in the Flag field of the Binding 1286 Cache Information option and update the peer endpoint of the key 1287 management protocol. 1289 If the K-bit is not set in the Binding Update, an active home agent 1290 needs to rerun the key management protocol. The active home agent 1291 MUST send State Synchronization Reply message including Binding Cache 1292 Information option to all the other standby home agents. K-bit is 1293 unset in the flags field of the Binding Cache Information option. 1294 The receivers of the State Synchronization Reply message (i.e. 1295 standby home agents) detect the care-of address change and rerun the 1296 key management protocol. 1298 5.4. Receiving Home Agent Switch message 1300 A mobile node must follow the verification and operations specified 1301 in [RFC-5142] when it receives a Home Agent Switch message. 1303 The Home Agent Switch message MUST be securely exchanged between a 1304 mobile node and a home agent by IPsec ESP. 1306 When the mobile node receives a Home Agent Switch message, and if the 1307 message contains the IPv6 address of a standby home agent, it MUST 1308 select the standby home agent as its active home agent and MUST send 1309 a new Binding Update message to it. 1311 The standby home agent address in the Home Agent Switch message MUST 1312 be equal to the sender of the Home Agent Switch message. If the IPv6 1313 address stored in the Home agent address field is different from the 1314 sender's source IPv6 address, the mobile node MUST send a binding 1315 update to the sender and MUST NOT use the IPv6 address in the Home 1316 Agent Switch message. 1318 6. Messages Format 1320 6.1. New Mobility Header Messages 1322 6.1.1. HARP Message Format 1324 The HARP message has the type field to identify different roles. The 1325 HARP message has the MH Type value TBD. 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Type | Group ID | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Sequence # |A|R|V|M|Rsvd | Status | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Home Agent Preference | Home Agent Lifetime | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Hello Interval | | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1338 | | 1339 . Mobility Options . 1340 . . 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 Figure 6: Home Agent Hello Message 1345 Type 1347 8-bit unsigned integer. It can be assigned one of the following 1348 values: 1350 0: SwitchOver Request (SWO-REQ) 1352 It is unicast by a standby home agent that desires to become 1353 the active home agent. The receiver of the message MUST 1354 transition to standby state as soon as the message is received 1355 and validated successfully. 1357 1: SwitchOver Reply (SWO-REP) 1359 It is used to acknowledge the receipt of the corresponding SWO- 1360 REQ. 1362 2: SwitchBack Request (SWB-REQ) 1364 It is unicast by an active home agent that desires to become a 1365 standby home agent. The receiver of this message SHOULD 1366 transition to active state as soon as the message is received 1367 and validated successfully. 1369 3: SwitchBack Reply (SWB-REP) 1370 It is used to acknowledge the receipt of the corresponding SWB- 1371 REQ. 1373 4: Switch Complete (SW-COMP) 1375 This message is used to indicate the completion of switch over, 1376 (i.e. sending home agent switch messages and receiving binding 1377 update messages from all the served mobile nodes). 1379 4: Home Agent HELLO (HA-HELLO) 1381 It MUST be either unicast or multicast to carry home agent 1382 information among the redundant home agent set. The HA-Hello 1383 message is defined for two purpose: 1) an alive check and 2) 1384 home agent information exchange. 1386 Group Identifier 1388 8-bit unsigned integer. This value is used to identify a 1389 particular redundant home agent set. 1391 Sequence # 1393 16-bit unsigned integer. The Sequence number of the HA-Hello 1394 message can be used to verify whether this Hello message is the 1395 latest one or not. 1397 (A)ctive flag 1399 Active Home Agent flag. If this flag is set, the sender of this 1400 HA-Hello message is an active home agent. 1402 (R)equest flag 1404 HA-HELLO requesting flag. If this flag is set, the receiver of 1405 this HA-Hello message must send back a HA-Hello message to the 1406 sender. 1408 (V)HARP capability flag 1410 VHARP capability Flag. If a home agent is capable of IPsec/IKE 1411 state synchronization, it MUST set this flag. 1413 (M)ode flag 1414 A home agent MUST set this flag only when VHARP is used in the 1415 current operation. If the flag is unset, the home agent currently 1416 operates HARP. (HARP:0, VHARP:1) 1418 Reserved 1420 This field is unused. It MUST be initialized to zero by the 1421 sender and MUST be ignored by the receiver. 1423 Status 1425 8-bit unsigned integer indicating the disposition of a SWO-REQ or 1426 SWB-REQ. This field is only valid in SWO-REP and SWB-REP. The 1427 following Status values are defined: 1429 0: Success 1431 128: Reason unspecified 1433 129: Administratively prohibited 1435 130: Not active home agent (The receiver of SWO-REQ is not the 1436 active home agent) 1438 131: Not standby home agent (The receiver of SWB-REQ is already 1439 the active home agent) 1441 132: Not in same redundant home agent set 1443 Home Agent Preference 1445 16-bit unsigned integer. The preference for the home agent 1446 sending the HA-Hello message. This preference is the same as the 1447 Home Agent Preference value of the Home Agent Information option 1448 as defined in [RFC-3775]. However, operators MAY use a different 1449 preference value for this operation. 1451 Home Agent Lifetime 1453 16-bit unsigned integer. The lifetime for the home agent sending 1454 the HA-Hello message. This lifetime is the same as the Home Agent 1455 Lifetime value of the Home Agent Information option as defined in 1456 [RFC-3775]. 1458 Hello Interval 1459 16-bit unsigned integer. The interval for the home agent sending 1460 this Hello message. 1462 Mobility Options 1464 No valid options are defined in this specification. 1466 6.1.2. State Synchronization Message Format 1468 This message is used to exchange state corresponding to a particular 1469 mobile node(s). It MUST be unicast and MUST be authenticated by 1470 IPsec ESP. This message has the MH Type value TBD. 1472 0 1 2 3 1473 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 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Type |A| Reserved | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Identifier | | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1479 . . 1480 . Mobility Options . 1481 . . 1482 . | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 Figure 7: State Synchronization Message 1487 Type 1489 8-bit unsigned integer. It can be assigned one of the following 1490 values: 1492 0: State Synchronization Request (SS-REQ) 1494 It is used to solicit the active state corresponding to a 1495 particular mobile node. 1497 1: State Synchronization Reply (SS-REP) 1499 It is used between the home agents in the redundant home agent 1500 set to exchange binding cache information and any other 1501 information related to providing mobility service to the mobile 1502 nodes either periodically or in response to a SS-REQ. 1504 2: State Synchronization Reply-Ack (SS-ACK) 1506 This message is optional and is specially used when the links 1507 between home agents are not reliable. 1509 (A)ck flag 1511 This flag is valid only for SS-REP. If the sender requires 1512 explicit acknowledgment by SS-ACK, it MUST set this flag. 1514 Reserved 1516 This field is unused. It MUST be initialized to zero by the 1517 sender and MUST be ignored by the receiver. 1519 Identifier 1521 A 16-bit identifier to aid in matching state synchronization 1522 message. The identifier should never be set to 0. It should 1523 always be more than 1. 1525 Mobility Options 1527 Variable-length field of such length that the complete Mobility 1528 Header is an integer multiple of 8 octets long. This field 1529 contains zero or more TLV-encoded mobility options. The encoding 1530 and format of defined options are described in [RFC-3775]. The 1531 receiver MUST ignore and skip any options which it does not 1532 understand. This message requires at least one mobility option, 1533 therefore, there is no default length for this message. 1535 Binding Cache Information Option is mandatory in SS-REQ message. 1536 Multiple options can be stored in the same SS-REQ message. A home 1537 agent includes the mobile node's home address in the Binding Cache 1538 Information Option. If a home agent wants to solicit all the 1539 active mobile nodes' states, it can include the unspecified 1540 address (::) in an IPv6 address option. 1542 Binding Cache Information Option is mandatory in SS-REP. SS-REP 1543 can carry any of mobility options. The following options are just 1544 examples. 1546 * AAA Information Option 1548 * Vendor Specific Mobility Option [RFC-5094] 1550 * Mobile Network Prefix Option [RFC-3963] 1551 * IPv4 Care-of Address Option [RFC-5555] 1553 * IPv4 Home Address Option [RFC-5555] 1555 * Binding Identifier Option [RFC-5648] 1557 6.1.3. Home Agent Rekey Message 1559 This message is used to indicate that the mobile node SHOULD start an 1560 IPsec re-key with the home agent specified in the Home Agent 1561 Addresses field. This message is used when a failed home agent 1562 recovers and needs to re-establish IPsec SA/IKE state with a mobile 1563 node. This message MUST be unicast to a mobile node by the active 1564 home agent and MUST be authenticated and encrypted by IPsec ESP. The 1565 Home Agent Rekey message has the MH Type value TBD. If no options 1566 are present in this message, no padding is necessary and the Header 1567 Len field will be set to 2. 1569 0 1 2 3 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Reserved | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | | 1575 + + 1576 . Home Agent Addresses . 1577 + + 1578 | | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 . Mobility options . 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 Figure 8: Home Agent Rekey Message 1585 Reserved 1587 The reserved field is 16 bits 1589 Home Agent Address 1591 The receiver of this message MUST rekey the security association 1592 with the specified home agent. 1594 When a mobile node receives a Home Agent Rekey message, it MUST 1595 verify the message as following. 1597 o The message MUST be sent from the receiver's active home agent. 1598 Otherwise, the message MUST be discarded. 1600 o The message MUST be protected by IPsec. Otherwise, the message 1601 MUST be discarded. 1603 o The message SHOULD contain one of standby home agent's address. 1604 If the home agent address is not known from the bootstrapping 1605 described in Section 5.1, the mobile node MUST NOT start an IKE 1606 session with the unknown home agent. Instead, it SHOULD re-start 1607 home agent discovery again to update its home agent address 1608 information. 1610 If all the above verifications are satisfied, the mobile node MUST 1611 re-key the SA with the home agent addresses stored in the Home Agent 1612 Addresses field. 1614 6.2. New Mobility Options 1616 6.2.1. Binding Cache Information Option 1618 The binding cache information option is used to carry binding cache 1619 information of each mobile node. It has two different lengths 1620 depending on the number of fields. Two lengths can be set, 16 and 1621 40. The alignment requirement is either 8n+6 or 8n+2. The Binding 1622 Cache Information option is only valid in a State Synchronization 1623 message. Its format is as follows: 1625 0 1 2 3 1626 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 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Type = TBD | Length | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | | 1631 + + 1632 | Home Address | 1633 + + 1634 | | 1635 + + 1636 | | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 : : 1639 + + 1640 : : 1641 + Care-of Address + 1642 : : 1643 + + 1644 : : 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 : Flags : Sequence Number : 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 : Lifetime : Reserved : 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 Figure 9: Binding Cache Information Option 1653 The fields of Home Address is always mandated in a Binding Cache 1654 Information option. The Care-of Address, Flags, Sequence Number, and 1655 Lifetime fields are presented only if these values are necessary (ex. 1656 VHARP). The corresponding value in the binding cache database of the 1657 active home agent is copied to each field. Note that the 16-bit 1658 Reserved field MUST be set to zero. 1660 6.2.2. State Synchronization Status Option 1662 Figure 10 is a new mobility option of State Synchronization message. 1663 In the global HAHA, SS-ACK is mandatory for receivers of SS-REP to 1664 notify the global binding registration status 1665 0 1 2 3 1666 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 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | Type = TBD | Length | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | Status | Reserved | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | | 1673 + + 1674 | Home Address | 1675 + + 1676 | | 1677 + + 1678 | | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 Figure 10: State Synchronization Status Option 1683 Type 1685 8-bit Type value. The value is TBD. 1687 Length 1689 8-bit length value. 1691 Status 1693 8 bit Status value of global binding registration. 1695 * 0: Success 1697 * 128: Reason unspecified 1699 * 129: Malformed SS-REP 1701 * 130: Not in same global home agent set 1703 Reserved 1705 24 bit Reserved fields 1707 Home Address 1708 Corresponding home address of the status code. 1710 6.2.3. AAA Information Option 1712 This option is used to carry the AAA state of the mobile node's 1713 Mobile IPv6 sessions. The AAA state information can be carried in 1714 RADIUS or Diameter AVP formats including the user and session info. 1715 This information option is only valid in a State Synchronization 1716 message. 1718 0 1 2 3 1719 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 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | Type = TBD | Length | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 . . 1724 . AAA AVPs . 1725 . . 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 Figure 11: AAA Information Option 1730 Type 1732 8-bit Type value. The value is TBD. 1734 Length 1736 8-bit length value. 1738 AAA AVPs 1740 Series of TLV encoded AAA AVPs (including vendor specific AVPs) 1741 carrying AAA-related information for each Mobile IPv6 and IPsec/ 1742 IKE session. 1744 7. Security Considerations 1746 All the messages newly defined in this document SHOULD be secured by 1747 IPsec ESP. When a HA-HELLO message is multicast, the multicast 1748 extensions to IPsec [RFC-5374] is used. In some operational 1749 scenarios, home agents are located in deeply core network and 1750 securely managed. If there is a secure transport network between 1751 home agents, some of security mechanism can be turned off depending 1752 on administrative policy. 1754 A home agent switch message is reused for signaling between a home 1755 agent and a mobile node in HARP. It is protected by IPsec ESP as 1756 defined in [RFC-5142]. 1758 When an active home agent fails, mobile nodes using that home agent 1759 need to change its home agent to one of standby home agents. The 1760 mobile node need to update or establish the IPsec SA with the new 1761 home agent as described in Section 5.2. Existing mechanisms 1762 [RFC5723] are applied to this operation. 1764 8. Protocol Constants 1766 INITIAL_STATE_SYNC_REQ_TIMER: 3sec 1768 INITIAL_SWITCH_REQ_TIMER: 1sec 1770 MAC_HARELIABILITY_TIMEOUT 16sec 1772 ALL_HA_MULTICAST_ADDR: TBD 1774 9. Protocol Configuration Variables 1776 LINK_TRAVERSAL_TIME: default 150msec 1778 10. IANA Considerations 1780 The following Extension Types MUST be assigned by IANA: 1782 o Home Agent Reliability Protocol (HARP) Message 1784 o State Synchronization (SS) Message 1786 o Binding Cache Information Option 1788 o AAA Information Option 1790 o A new link-local multicast address (ALL_HA_MULTICAST_ADDR) for all 1791 home agents will be assigned by the IANA. 1793 11. Additional Authors 1795 This document is a result of discussions in the Mobile IPv6 Home 1796 Agent Reliability Design Team. The members of the design team that 1797 are listed below are authors that have contributed to this document: 1799 Samita Chakrabarti 1801 samita.chakrabarti@azairenet.com 1803 Kuntal Chowdhury 1805 kchowdhury@starentnetworks.com 1807 Hui Deng 1809 denghui@chinamobile.com 1811 Vijay Devarapalli 1813 vijay.devarapalli@azairenet.com 1815 Sri Gundavelli 1817 sgundave@cisco.com 1819 Brian Haley 1821 brian.haley@hp.com 1823 Behcet Sarikaya 1825 bsarikaya@huawei.com 1827 Ryuji Wakikawa 1829 ryuji.wakikawa@gmail.com 1831 12. Acknowledgements 1833 This document includes a lot of text from [ID-LOCALHAHA] and [ID- 1834 HAHA]. Therefore the authors of these two documents are 1835 acknowledged. We would also like to thank the authors of the home 1836 agent reliability problem statement [ID-PS-HARELIABILITY] for 1837 describing the problem succinctly and Alice Qin for her work on the 1838 hello protocol. 1840 13. References 1841 13.1. Normative References 1843 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1844 Requirement Levels", BCP 14, RFC 2119, March 1997. 1846 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1847 IPv6", RFC 3775, June 2004. 1849 [ID-3775bis] Perkins, C., Johnson, D., Arkko, J., "Mobility Support 1850 in IPv6", draft-ietf-mext-rfc3775bis-10.txt, Octover 2010. 1852 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1853 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1854 January 2005. 1856 [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split 1857 scenario", RFC 5026, October 2007. 1859 [RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC 1860 5094, October 2007. 1862 [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message", 1863 RFC-5142, November 2007. 1865 [RFC-5374] B. Weis, G. GrossD. Ignjatic, "Multicast Extensions to 1866 the Security Architecture for the Internet Protocol", RFC 5374, 1867 November 2008 1869 [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack 1870 Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. 1872 [RFC-5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1873 and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, 1874 October 2009. 1876 [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via 1877 DHCPv6 for the Integrated Scenario", 1878 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), 1879 April 2008. 1881 13.2. Informative References 1883 [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot 1884 Standby Router Protocol (HSRP)", RFC 2281, March 1998. 1886 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1887 RFC 3753, June 2004. 1889 [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1890 RFC 3768, April 2004. 1892 [RFC-4285] A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury, 1893 "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006 1895 [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with 1896 IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 1898 [RFC-5723] Y. Sheffer, H. Tschofenig, "Internet Key Exchange Protocol 1899 Version 2 (IKEv2) Session Resumption", RFC 5273, January 2010. 1901 [RFC-5798] S. Nadas, "Virtual Router Redundancy Protocol Version 3 1902 for IPv4 and IPv6", RFC 5798 (soon?), December 2009. 1904 [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", 1905 draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. 1907 [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", 1908 draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. 1910 [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent 1911 Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), 1912 February 2004. 1914 Author's Address 1916 Ryuji Wakikawa 1917 TOYOTA InfoTechnology Center, U.S.A., Inc. 1918 465 Bernardo Avenue 1919 Mountain View, CA 94043 1920 USA 1922 Email: ryuji.wakikawa@gmail.com