idnits 2.17.1 draft-ietf-mip6-hareliability-08.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 (November 9, 2010) is 4910 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 343, but not defined == Missing Reference: 'HA2-addr' is mentioned on line 343, but not defined == Missing Reference: 'RFC- 2281' is mentioned on line 396, but not defined Unexpected reference format, failed extracting the RFC number: RFC- 2281 == Missing Reference: 'HA-addr' is mentioned on line 400, but not defined == Missing Reference: 'RFC5723' is mentioned on line 1794, 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 (~~), 7 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 November 9, 2010 5 Expires: May 13, 2011 7 Home Agent Reliability Protocol (HARP) 8 draft-ietf-mip6-hareliability-08.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 May 13, 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 . . . . . . . . . . . . . . . . . . . 11 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 State 77 Synchronization message . . . . . . . . . . . . . . . 21 78 4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 21 79 4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 22 80 4.4.5. Synchronizing State (SS-REP and SS-ACK) . . . . . . . 23 81 4.5. Switching the Active Home Agent . . . . . . . . . . . . . 24 82 4.6. Consideration of Routing and Neighbor Discovery 83 Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 25 84 4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 26 85 4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26 87 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 27 88 5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 27 89 5.2. IPsec/IKE Establishment to Home Agents . . . . . . . . . . 28 90 5.3. Synchronizing State: K-bit treatment . . . . . . . . . . . 28 91 5.4. Receiving Home Agent Switch message . . . . . . . . . . . 29 93 6. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 29 94 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 29 95 6.1.1. HARP Message Format . . . . . . . . . . . . . . . . . 29 96 6.1.2. State Synchronization Message Format . . . . . . . . . 33 97 6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 35 98 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 36 99 6.2.1. Binding Cache Information Option . . . . . . . . . . . 36 100 6.2.2. State Synchronization Status Option . . . . . . . . . 38 101 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 39 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 105 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 40 107 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 40 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 111 11. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 41 113 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 115 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 116 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 117 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 121 1. Introduction 123 In Mobile IPv6 [RFC-3775, ID-3775bis] and its derivative protocols 124 like NEMO Basic Support [RFC-3963] and Dual Stack Mobile IPv6 [RFC- 125 5555], if a home agent loses binding cache state or even network 126 connectivity due to its failure, or some other reason, the result is 127 a loss of service for the mobile nodes. It is beneficial to provide 128 high availability and redundancy for a home agent so that mobile 129 nodes can have uninterrupted service even when one home agent crashes 130 or loses state. The Home Agent Reliability Protocol (HARP) is 131 designed to manage standby home agents, and switch service from an 132 active to a standby home agent in the case of an active home agent 133 failure. 135 1.1. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC-2119]. 141 In this document, the term mobile node refers both to a mobile host 142 [RFC-3775] and a mobile router [RFC-3963]. 144 Mobility related terms used in this document are defined in [RFC- 145 3775] and [RFC-3753]. In addition or in replacement of these, the 146 following terms are defined or redefined: 148 Home Agent Reliability Protocol (HARP) 150 A protocol between Mobile IPv6 home agents that provides 151 reliability by moving state and service from an active home agent 152 to a standby, in the case of an active home agent failure. HARP 153 can accomodate multiple home agents being placed on the same home 154 link, or on different links, by grouping them into a redundant 155 home agent set. One of home agents is selected as an active home 156 agent. If the active home agent fails, a standby home agent can 157 take over and become the active home agent. Since each home agent 158 is assigned individual home agent addresses, a mobile node is 159 aware of home agent failures and needs to register its binding to 160 the new active home agent again. 162 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]. 170 The VHARP operations are transparent to a mobile node. 172 Active Home Agent 174 A home agent that is currently serving the mobile nodes. 176 Standby Home Agent 178 A home agent which can serve the mobile nodes when the active home 179 agent fails. 181 Failed Home Agent 183 A home agent that is not available due to hardware or software 184 failure, system maintenance, etc. 186 Active Home Agent Address 188 An IPv6 address of the Active Home Agent. 190 Standby Home Agent Address 192 An IPv6 address of the Standby Home Agent. 194 Redundant Home Agent Set 196 A grouping which includes an active and standby home agent(s). 197 The Group Identifier is used to identify a redundant home agent 198 set. Operators need to configure a unique value per redundant 199 home agent set. 201 Virtual Home Agent Address 203 A home agent address shared among home agents in a redundant home 204 agent set. It is similar to virtual router address specified in 205 VRRP [RFC-3768, RFC-5798]. The address is only activated on an 206 active home agent. 208 Home Agent Preference 210 This preference value was originally defined for Dynamic Home 211 Agent Address Discovery (DHAAD) in RFC3775. This protocol re-uses 212 this preference value for home agent selection when an active home 213 agent has failed. A home agent SHOULD NOT share the same 214 preference value with other home agents. Meanwhile, operators can 215 also define an independent value for the home agent reliability 216 protocol. It is useful when operators want to assign different 217 operational policies to the preference values of DHAAD and the 218 Home Agent Reliability Protocol. 220 New Messages 222 Home Agent Reliability Protocol (HARP) message defined in 223 Section 6.1.1: 225 SwitchOver Request (SWO-REQ) 227 SwitchOver Reply (SWO-REP) 229 SwitchBack Request (SWB-REQ) 231 SwitchBack Reply (SWB-REP) 233 Switch Complete (SW-COMP) 235 Home Agent HELLO (HA-HELLO) 237 State Synchronization (SS) message defined in Section 6.1.2: 239 State Synchronization Request (SS-REQ) 241 State Synchronization Reply (SS-REP) 243 State Synchronization Reply-Ack (SS-ACK) 245 1.2. Problem Statement and Requirements 247 In Mobile IPv6 [RFC-3775, RFC-4877], a mobile node registers and 248 establishes a binding with only one home agent. The home agent 249 represents the possibility of a single point of failure for Mobile 250 IPv6. A home agent is responsible for multiple mobile nodes on its 251 home link. The failure of the home agent may then result in the loss 252 of connectivity for numerous mobile nodes located throughout the 253 Internet. To overcome this problem, Mobile IPv6 allows deployment of 254 multiple home agents on the home link so that upon the failure of a 255 home agent, a mobile node can re-establish its connection through a 256 new home agent. However, the base Mobile IPv6 specification does not 257 address home agent fail-over and dynamic transfer of service from one 258 home agent to another. This transfer of service from the failed home 259 agent to a new active home agent requires coordination or pre- 260 configuration among the home agents regarding security associations, 261 transfer of mobile node bindings, and other service information for 262 reliable Mobile IPv6 service in a deployment scenario. 264 For the home agent reliability solution, we define the following 265 generic requirements: 267 Reliable Home Agent service 269 Multiple home agents are available for a home prefix, and one of 270 them actively serves the mobile nodes. A standby home agent takes 271 over when the active home agent becomes unavailable. The transfer 272 of the MN-HA association should be transparent to applications and 273 should not take longer than the care-of-addresses update procedure 274 described in Mobile IPv6 [RFC-3775]. 276 Availability of a Redundant Home Agent Set 278 Availability of an active home agent address and a standby home 279 agent address at the bootstrapping period for the mobile node is 280 assumed. 282 State Synchronization 284 The information for mobile nodes must be able to be synchronized 285 between an active home agent and standby home agent(s). This 286 includes the Binding Cache, AAA information, and other Mobile IPv6 287 and NEMO related information. Note that the Home Agent 288 Reliability Protocol only exchanges state information for active 289 mobile nodes. Therefore, we do not have any specific operation 290 for synchronizing the configuration information. For instance, 291 when Mobile IPv6 is operated with Authentication protocol [RFC- 292 4285], synchronizing the configurations of the Authentication 293 protocol is out of scope in this document. Operators MAY 294 correctly set the configuration information in multiple home 295 agents. 297 Consideration of IPsec/IKE Transfer 299 An active home agent maintains several IPsec and IKE states for 300 mobile nodes. These states are synchronized within the redundant 301 home agent set. (Note this is out of scope in this document.) 303 Secured Message Exchanges 305 The messages used between the home agents to transfer binding 306 cache information MAY be authenticated and encrypted. 308 Failure Detection 310 Redundant home agents must actively check for possible failure of 311 an active home agent. If a home agent supports an existing 312 failure detection mechanism such as VRRP [RFC-3768, RFC-5798] or 313 HSRP [RFC-2281], it can re-use that mechanism to detect home agent 314 failure. In addition, periodic Hello messages are introduced in 315 this document to detect active an home agent's service 316 availability. 318 Failure Notification 320 If necessary, a mobile node is notified about the active home 321 agent failure by the standby home agent. 323 2. Protocol Overview 325 HARP works when one or more home agents are provisioned on a home 326 link, or different links, and these are grouped into a redundant home 327 agent set. One home agent is selected as the active home agent and 328 receives binding updates from mobile nodes. According to [RFC- 3775, 329 RFC-4877], an active home agent maintains not only binding cache 330 information, but also IPsec/IKEv2 states per mobile node, because 331 Mobile IPv6 relies on IPsec for securing the signaling, and 332 optionally user plane traffic. 334 If the active home agent fails, all state information associated with 335 a mobile node is lost. As a result, all mobile nodes served by the 336 failed home agent will be disconnected. In HARP, other home agents, 337 called standby home agents, exchange the required information with 338 the active home agent. In case of a failure of the active home 339 agent, HARP can let a standby home agent take over for the failed 340 home agent with this information about the active mobile nodes. 342 MN HA1 HA2 343 | [HA1-addr] [HA2-addr] 344 | | | 345 | (active) (standby) 346 | | | 347 | |<--------->| 1. Hello exchanges 348 |<--------->| | 2. Binding Registration to HA1 349 | |<--------->| 3. State exchanges 350 | | | 351 | X | HA1 FAILURE 352 | X | 353 | X | 4. Failure Detection 354 |<----------------------| 5. Sending Home Agent Switch message 355 |<--------------------->| 6. Binding Registration to HA2 356 | X (active) RECOVERY COMPLETE 357 | X | 359 Figure 1: Overview of Home Agent Reliability Protocol (HARP) 361 Figure 1 shows an example of the HARP operations. HA1 and HA2 belong 362 to the same redundant home agent set and are assigned with an 363 individual IP address (HA1-addr and HA2-addr) at the home link. Each 364 home agent can be seen as an individual home agent by mobile nodes. 365 All the home agents periodically send a Hello message (named HA- 366 HELLO) to exchange the home agent information, as well as monitor the 367 state of the active home agent (1). The mobile node registers its 368 binding with only the active home agent (2). The active home agent 369 synchronizes the active mobile node information with the other 370 standby home agents periodically (3). 372 HARP introduces the new HA-HELLO message for failure detection, but 373 it may use any type of information to detect that failure. After 374 detecting the failure of the active home agent (4), the standby home 375 agent whose preference value is the highest takes over for the failed 376 home agent. Once completed, the standby home agent sends a Home 377 Agent Switch message to all the mobile nodes that were registered at 378 the failed home agent (5). The standby home agent puts its own 379 address in the Home Agent Address field of the Home Agent Switch 380 message so that it will receive the binding update from the mobile 381 node as an acknowledgment of the sent Home Agent Switch message. The 382 home agent switch-over is complete when it receives binding updates 383 from all the mobile nodes (6). For protecting the Home Agent Switch 384 message, the mobile node should have an IPsec Security Association 385 (SA) with the standby home agent before the failover. The mobile 386 node may pre-establish multiple IPsec SAs with all the home agents. 388 Although the active home agent manages IPsec/IKEv2 states per mobile 389 node, HARP does not offer any recovery mechanism of these states by 390 itself. IPsec/IKE state synchronization is out of scope in this 391 document. If IPsec/IKEv2 state can be recovered from the active home 392 agent on the standby home agent, HARP can be operated in a slightly 393 different manner called Virtual-HARP (VHARP). Unlike HARP, the 394 standby home agents are an exact copy of the active home agent. It 395 is similar to the virtual router concept of VRRP [RFC-3768, RFC-5798] 396 and HSRP [RFC- 2281]. Note that HARP is mandatory and VHARP is 397 optional in this document. VHARP is shown in Figure 2. 399 MN HA1 HA2 400 | [HA-addr] [HA-addr'] 401 | | : 402 | (active) (standby) 403 |<--------->| : 1. Binding Registration to HA1 404 | |<--------->: 2. State exchanges 405 | | : 406 | X : HA1 FAILURE 407 | X : 408 | X : 3. Failure Detection 409 | X | 4. HA2 takes over the HA1 410 | X (active) RECOVERY COMPLETE 411 | X | 413 Figure 2: Overview of Virtual Home Agent Reliability Protocol (VHARP) 415 All the home agents (HA1 and HA2) in the redundant home agent set 416 share a virtual home agent address (HA-addr), and routing ensures 417 only the active home agent will be reachable using that virtual home 418 agent address. After a mobile node's binding registration (1), the 419 active home agent pushes the states of all of its mobile nodes to the 420 other standby home agents (2). In VHARP, all the states of a mobile 421 node need to be synchronized. For example, information such as the 422 Binding Cache, and Authentication, Authorization, and Accounting 423 (AAA) information. 425 After detecting the active home agent has failed (3), the standby 426 home agent whose preference value is the highest takes over the 427 failed home agent. The standby home agent activates the virtual home 428 agent address on its interface attached to the home link. The 429 virtual home agent address activation can be operated by VRRP. Since 430 all the necessary states of mobile nodes have already been 431 transferred to this standby home agent, the standby home agent can 432 immediately start acting as the active home agent (4). Unlike HARP, 433 the mobile node is not required to re-register its binding to a new 434 active home agent. The mobile node may use the IKEv2 resumption 435 mechanism [RFC-5723] to resume it's IPsec SA with the new active home 436 agent. 438 This document offers a new management mechanism of active and standby 439 home agents by using a new Mobility Header (MH) message called a HARP 440 message as shown in Figure 3. This mechanism can be used in both 441 HARP and VHARP. Each home agent exchanges its own home agent 442 information with the other home agents in its redundant home agent 443 set by a Home Agent HELLO message (HA-HELLO) (1). The HA-HELLO 444 message can also be used to monitor the availability of the active 445 home agent. 447 HA1(active) HA2 HA3 .. HAn 448 | | | | 449 |<------>|<---->|<---->| 1. HELLO exchange 450 |------->| | | 2. HA1 sends SWB-REQ 451 |<-------| | | 3. HA2 sends SWB-REP 452 |------->| | | 4. HA2 sends SW-COMP 453 (standby) (active) | | HA2 BECOMES ACTIVE HA 454 | | | | 455 SYSTEM MAINTENANCE, ETC. 456 | | | | 457 |------->| | | 5. HA1 sends SWO-REQ 458 |<-------| | | 6. HA2 sends SWO-REP 459 |------->| | | 7. HA1 sends SW-COMP (optional) 460 (active) (standby) | | 8. HA1 returns to active HA 461 | | | | HA1 BECOMES ACTIVE AGAIN 463 Figure 3: Home Agent Management 465 In some scenarios, the active home agent may need to stop serving 466 mobile nodes for system maintenance. This specification enables 467 manual intervention for home agent management. As shown in Figure 3, 468 the active home agent (HA1) sends a SwitchBack Request message (SWB- 469 REQ) to a standby home agent (HA2) (2). HA2 will acknowledge the 470 message by sending a SwitchBack Reply message (SWB-REP) to HA1 (3). 471 In HARP operation, it could take a long time to complete home agent 472 failover since all mobile nodes must re-register with the new home 473 agent. During this failover operation, HA1 may continue serving the 474 mobile nodes until the switch-over is completed. When HA2 decides 475 the switch-over has completed, it MAY send an optional message, SW- 476 COMP, to HA1 (4). As soon as HA2 sends the SW-COMP, it becomes the 477 active home agent. HA1 becomes a standby home agent when it receives 478 SW-COMP. If SW-COMP is not used, HA2 and HA1 change their status 479 appropriately. 481 After maintenance is complete and HA1 is back online, HA1 sends a 482 SwitchOver Request (SWO-REQ) to HA2 in order to become the active 483 home agent again (5). HA2 acknowledges it by sending a SwitchOver 484 Reply (SWO-REP) back to HA1 (6). HA1 now starts the home agent 485 failover operation. After the switch-over is complete, HA1 sends a 486 SW-COMP to HA2 (7). Then, HA1 becomes the active home agent and HA2 487 becomes a standby home agent (8). 489 3. Home Agent Configuration 490 3.1. Network Configuration 492 HARP supports two different configurations for standby home agents. 493 Standby home agents can be placed on the same home link or on 494 different links. Figure 4 depicts the configuration where home 495 agents serving the same home network are located on the same link as 496 defined in [RFC-3775]. 498 HA1 HA2 HA3 HA4 .... HAn 499 | | | | | 500 --------+------+------+------+--------+--------- 501 Home Link 503 Figure 4: Local Recovery Configuration 505 Figure 5 illustrates when standby home agents are located on 506 different links (illustrated as Recovery Link in Figure 5). Most 507 large operators have a very stringent requirement on network 508 availability even in the worst type of disaster or outage. This 509 configuration can achieve home agent recovery even if the entire home 510 link fails. This is called geographic redundancy, and is a well- 511 known configuration for Telecommunications operators. In Figure 5, 512 home agents (HA1-HA4) are placed in geographically separated regions 513 (region-1 and region-2). If region-1 suffers down time for any 514 reason, all the sessions will be seamlessly taken over by the nodes 515 in region-2. Note that HA3 and HA4 cannot receive packets meant for 516 the home network until the route on the Routers is changed. The 517 routing must also be updated to direct the packets meant for the home 518 link to the recovery link. 520 ---------IGP------>|<---BGP--->|<-----IGP--------- 522 HA1 HA2 HA3 HA4 523 | | | | 524 --------+------+-----+ R---R---R +-----+------+------- 525 Home Link Routers Recovery Link 526 (region-1) (region-2) 528 Figure 5: Global Recovery Configuration 530 3.2. Home Agent Address Configuration 532 In HARP, each home agent obtains its individual IPv6 address from its 533 serving home prefix. In VHARP, all the home agents use a virtual 534 home agent address generated from the home prefix. 536 In addition, each home agent running VHARP needs to obtain its 537 individual IPv6 address from its attached link. This IPv6 address is 538 used only for VHARP operations between home agents and is not 539 revealed to mobile nodes for binding registration. 541 All the home agents MUST join the ALL_HA_MULTICAST_ADDR. In VHARP, 542 each home agent joins the multicast group with its individual IPv6 543 address, but not with the virtual home agent address. This multicast 544 address can be used to exchange HA-HELLO messages among the home 545 agents. Alternatively, if a remote home recovery link is defined, 546 each home agent unicasts the HARP messages to home agents configured 547 at the remote recovery link. 549 4. Home Agent Operations 551 4.1. Home Agent List Management 553 In Mobile IPv6, each home agent periodically sends router 554 advertisements with the Home Address Information option [RFC-3775]. 555 HARP introduces a HARP HA-HELLO message to replace the router 556 advertisement. There are several reasons to use HA-HELLO messages 557 instead of a Router Advertisement such as: 559 o A HA-HELLO message can be sent beyond the link, while a router 560 advertisement cannot. In case of geographic redundancy, Router 561 Advertisements cannot be sent to the recovery link unless the home 562 link and the recovery link are virtually connected, for example, 563 by L2TP. 565 o A HA-HELLO message is defined to manage additional information, 566 such as Group ID and Active/Standby Status of the home agents in 567 the home agent list. 569 o A HA-HELLO message is exchanged only between home agents, while a 570 Router Advertisement is also processed by mobile nodes attached to 571 a home link. A HA-HELLO does not introduce any burden to the 572 mobile nodes even if it is frequently sent on the home link. 574 When a HA-HELLO is used to exchange home agent information, each home 575 agent SHOULD NOT process the Home Agent Information option carried by 576 a Router Advertisement. Router Advertisements are only processed by 577 mobile nodes. Operators may define different configuration values to 578 the parameters of the home agent information for a HA-HELLO and a 579 Router Advertisement. 581 This document requires additional information to be added the 582 conceptual Home Agents list defined in [RFC-3775]. The additional 583 information is learned through HA-HELLO message exchange. 585 o Group ID of a redundant home agent set. It is learned through the 586 Group ID field of the HA-HELLO. 588 o HA-HELLO Interval. This value is locally configured at every home 589 agent by operators, and is learned through the Hello Interval 590 field of the HA-HELLO. 592 o Individual home agent addresses used in the VHARP operation. This 593 information is only required when VHARP is used in addition to the 594 virtual home agent address. It is learned through the Source 595 Address of the HA-HELLO message. 597 o VHARP capability. This information is learned through the V flag 598 of the HA-HELLO message. 600 o Current mode (HARP or VHARP). This information is learned through 601 the M flag of the HA-HELLO message. 603 o Active status. This information is learned through the A flag of 604 the HA-HELLO message. 606 4.2. Detecting Home Agent Failure 608 Active and standby home agents can monitor each other in several 609 ways. One method is to reuse other failure detection mechanisms 610 defined in VRRP [RFC-3768, RFC-5798] and HSRP [RFC-2281]. However, 611 VRRP and HSRP are not sufficient since they cannot detect the case 612 where the system is running, but the Mobile IPv6 stack is not 613 operational. Failure events used in HARP/VHARP are listed below. 615 Loss of HA-HELLO 617 HARP/VHARP is an extension to Mobile IPv6, and can monitor the 618 availability of Mobile IPv6 services on each home agent by 619 periodically sending a HA-HELLO as a heart-beat. This HA-HELLO 620 can be exchanged frequently enough to detect a failure without any 621 additional overhead to mobile nodes attached to the home link. In 622 the event that a standby home agent does not receive any HA-HELLOs 623 from its peer for a configurable duration of time, the standby 624 home agent assumes the peer home agent has failed. Details of the 625 Hello message are described in Section 4.3.2. 627 Monitored Server Failure by the Active Home Agent 629 There may be a number of critical servers, such as an AAA, in the 630 network that are essential for ongoing Mobile IPv6 sessions at the 631 home agent. Operators can have a policy in place for which the 632 active home agent is treated as a failed home agent upon detecting 633 that the link to such servers has failed. 635 Routing Peer/Link Failure 637 Operators may require the home agent to detect its next-hop 638 routing peer failure. If the next-hop routing failure is fatal in 639 nature, or due to some other routing policies, the active home 640 agent is treated as a failed home agent and the recovery operation 641 should be started. 643 4.3. Processing the HARP Messages 645 4.3.1. IP field and Security Descriptions of HARP message 647 The HARP message format is defined in Section 6.1.1. If a HARP 648 message is unicast, the destination address MUST be one of the Home 649 Agents in the same Redundant Home Agent set. If it is a HA-HELLO 650 message, designated by setting the type field to 4, it can be 651 multicast. The destination address MUST be set to the 652 ALL_HA_MULTICAST_ADDR address. The source address MUST be set to the 653 sender's home agent address. Note that in VHARP, the virtual home 654 agent address SHOULD NOT be set to the source or destination address. 655 Instead, the IP address of the interface the packet is being sent 656 from SHOULD be used. 658 If a HARP message is unicast, it SHOULD be secured by IPsec ESP. If 659 a HA-HELLO message is multicast, multicast extensions to IPsec [RFC- 660 5374] SHOULD be applied. If all the home agents are placed in a 661 secure transport network to exchange a HARP message, authentication 662 and encryption MAY be omitted. Which security verification is used 663 depends on operational policy. If security verification fails for a 664 received HA-HELLO, the HA-HELLO MUST be discarded. 666 The following operations MUST be performed when transmitting a HARP 667 message: 669 o The incremented latest Sequence Number MUST be set in the Sequence 670 Number field. The Sequence Number SHOULD be initialized to zero 671 for the first Hello message. To accomplish sequence number 672 rollover, if the sequence number has already been assigned to be 673 the largest possible number representable as a 16-bit unsigned 674 integer, then when it is incremented it will then have a value of 675 zero (0). 677 o The sender's Group ID MUST be set in the Group ID field. 679 o The V-flag MUST be set if the sender is capable of VHARP. 681 o The M-flag MUST be unset if the sender is operating in HARP mode. 683 o The M-flag MUST be set if the sender is operating in VHARP mode. 685 o The A-flag MUST be set if the sender is the active home agent. 687 The following functions MUST be performed when a HARP message is 688 received: 690 o The Group ID in the HARP message MUST match the receiver's Group 691 ID. 693 o The source address of the HARP message MUST belong to a home agent 694 in the receiver's redundant home agent set. 696 o The M-flag MUST match the receiver's operating mode. 698 o The Sequence Number value in the HARP message MUST be larger than 699 the last received Sequence Number value. When the sequence number 700 rollover occurrs, the sequence number value in the HA-HELLO MUST 701 be zero. 703 If any one of the above checks fails, the receiver SHOULD discard the 704 HARP message. 706 4.3.2. Processing Home Agent Hello (HA-HELLO) 708 4.3.2.1. Sending HA-Hello Messages 710 Each home agent MUST send a HA-HELLO in the following cases: 712 o UNSOLICITED: Each home agent SHOULD periodically send a HA-HELLO. 713 The time interval is configured locally at each home agent. 715 o UNSOLICITED: When a home agent detects its local information has 716 changed it should immediately send a HA-HELLO. 718 o SOLICITED: When a home agent receives a HA-HELLO with the R-flag 719 set, the HA-HELLO can be sent to the destination home agent. 721 A home agent can solicit a HA-HELLO from a particular home agent(s) 722 in the same redundant home agent set by unicasting or multicasting a 723 HA- HELLO with the R-flag set. Soliciting a HA-HELLO happens when: 725 o A new home agent boots up. The new home agent SHOULD solicit HA- 726 Hello messages by multicasting a HA-Hello message with the R-flag 727 set to 1. 729 o If a HA-HELLO has not been received after the specified Hello 730 Interval, a HA-HELLO MAY be solicited to the home agent. 732 o A home agent entry in the redundant home agent set is about to be 733 removed due to home agent lifetime expiration. A HA-HELLO SHOULD 734 be solicited from the home agent whose lifetime is soon expired. 736 In addition to Section 4.3.1, the following operations MUST be 737 performed when transmitting a HA-HELLO. 739 o The Type field MUST be set to 4. 741 o The R-flag MUST be set if the sender is soliciting a HA-HELLO from 742 the other home agent(s). 744 o The appropriate home agent configuration values MUST be copied to 745 the Home Agent Preference, the Home Agent Lifetime, and Hello 746 Interval fields. 748 4.3.2.2. Receiving Hello Messages 750 The receiver MUST perform the verification of the HA-HELLO described 751 in Section 4.3.1. After the verification, the receiver copies the 752 values stored in the HA-HELLO message to the corresponding home agent 753 list entry according to Section 4.1. 755 If the home agent lifetime field in the HA-HELLO is set to 0, the 756 receiver MUST remove the sending home agent from the home agents 757 list. 759 If the R-flag is set in the received HA-HELLO, the receiver MUST send 760 a new HA-HELLO to the originator as described in Section 4.3.2.1. 762 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) 764 When a standby home agent decides to become an active home agent, the 765 standby home agent sends a SwitchOver Request (SWO-REQ) to the 766 current active home agent in the following way: 768 o It MUST be unicast to only the current active home agent. 770 o It MUST be sent from a standby home agent. The active home agent 771 MUST NOT generate this message. 773 When an active home agent receives a SWO-REQ, it MUST do the 774 following verifications and operations, in addition to what is 775 described in Section 4.3.1 777 o If the receiver of the SWO-REQ is not an active home agent, it 778 MUST send a SWO-REP with the Status field set to 130 (Not active 779 home agent). 781 o If the sending home agent does not belong to the same redundant 782 home agent set, a SWO-REP message MUST be sent to the sender with 783 the Status field set to 132 (Not in same redundant home agent 784 set). 786 o If there are any other reasons that the receiver cannot accept the 787 SWO-REP, the active home agent MUST reply a SWO-REP with the 788 Status field set to 129 (Administratively prohibited). 790 o Otherwise, the active home agent MUST become a standby home agent 791 and reply with a SWO-REP message with the Status field set to 0 792 (Success). 794 When a standby home agent receives a SWO-REP, it MUST do the 795 following verifications and operations, in addition to what is 796 described in Section 4.3.1: 798 o If the receiver is an active home agent, the SWO-REP MUST be 799 discarded. 801 o If the standby home agent receives an unsolicited SWO-REP which is 802 not in reply to an SWO-REQ it has sent, it MUST ignore the SWO- 803 REP. 805 o Otherwise, if the Status field of the SWO-REP is 0 (Success), the 806 standby home agent (the receiver of the SWO-REP) immediately 807 becomes an active home agent. 809 o If the value in the Status field is greater than 128, an error has 810 occurred. In this case, the receiver MUST NOT attempt to be an 811 active home agent. 813 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) 815 When an active home agent decides to become a standby home agent, it 816 sends a SWB-REQ to one of the standby home agents. The reason for 817 the active home agent sending this message might be due to an 818 administrative intervention, or an event like Monitored Server 819 Failure by the active home agent, or due to a Routing Peer/Link 820 Failure. The following operations MUST be performed when SWB-REQ is 821 sent: 823 o It MUST be unicast to only one of the standby home agents in the 824 same redundant home agent set. 826 o It MUST be sent from an active home agent. A standby home Agent 827 MUST NOT generate this message. 829 When a home agent receives a SWB-REQ message, it verifies the message 830 as follows: 832 o If the sending home agent of the SWB-REQ is not an active home 833 agent, a SWB-REP MUST be sent in which the Status field is set to 834 130 (Not active home agent). 836 o If the sending home agent does not belong to the same redundant 837 home agent set, a SWB-REP MUST be sent in which the Status field 838 is set to 132 (Not in same redundant home agent set). 840 o Otherwise, the receiving home agent MUST send a SWB-REP with the 841 Status field set to 0 (Success). 843 o After sending the SWB-REP, the standby home agent MUST NOT become 844 an active home agent immediately. This is because the active home 845 agent is still active until it receives the SWB-REP acknowledging 846 the SWB-REQ it sent. The standby home agent SHOULD change to 847 active after LINK_TRAVERSAL_TIME. The default value of 848 LINK_TRAVERSAL_TIME is defined in Section 9. 850 When a home agent receives a SWB-REP message, it verifies the message 851 as follows: 853 o If the standby home agent received an unsolicited SWB-REP not in 854 reply to it's own SWB-REQ, it SHOULD ignore the SWO-REP. 856 o If the Status field of the SWB-REP is 0 (Success), the active home 857 agent should immediately become a standby home agent. The sending 858 home agent of SWB-REP becomes an active home agent after 859 LINK_TRAVERSAL_TIME. 861 o If the value in the Status field is greater than 128, the receiver 862 of the SWB-REP (active home agent) cannot become a standby home 863 agent and MUST continue to be an active home agent. 865 4.4. State Synchronization 867 The State Synchronization (SS) message format is defined in 868 Section 6.1.2. It can carry multiple aspects of the state 869 information associated with a mobile node by setting mobility options 870 in the Mobility Options field. The following list shows examples of 871 the mobility options which can be specified in the state 872 synchronization message: 874 o IPv6 Home Address (Binding Cache Option) 876 o Binding Cache Information (Binding Cache Option) 878 o NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC- 879 3963]) 881 o IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555]) 883 o IPv4 Home Address (IPv4 Home Address Option [RFC-5555]) 885 o Binding Identifier (Binding Identifier Option [RFC-5648] 887 o AAA states (AAA Information Option) 889 o Miscellaneous states (Vendor Specific Mobility Option [RFC-5094]) 891 When a home agent needs to send the state of multiple mobile nodes in 892 a single state synchronization message (SS-REQ or SS-REP), a Binding 893 Cache Information option is used as a separator. For each mobile 894 node, a Binding Cache Information option is placed first, followed by 895 any other options related to the mobile node, if necessary. 897 In HARP, since a mobile node will re-register to the new active home 898 agent after a home agent failover, it is not necessary for the 899 standby home agents to synchronize all the mobile nodes' state 900 information. The standby home agents only need to collect the home 901 address information of all the mobile nodes served by the active home 902 agent. The information is used to send Home Agent Switch messages to 903 all the mobile nodes when a home agent failure occurs. 905 In the case of VHARP, home agent fail-over is accomplished without 906 the mobile nodes having to perform re-registration. Therefore, 907 standby home agents need to copy the complete state information of 908 each mobile node registered with the active home agent. 910 4.4.1. Binding Cache Information Management 912 In HARP, each standby home agent learns the partial binding cache 913 information such as a pair of a home address and a mobile node's 914 registering home agent address. 916 In VHARP, a standby home agent ideally copies the received binding 917 cache information and other mobile node's information into the 918 appropriate database so that it can act as an active home agent as 919 soon as it takes over the failed home agent. 921 4.4.2. IP field and Security Descriptions of State Synchronization 922 message 924 A state synchronization message is unicast. The destination address 925 MUST be one of the home agents in the same Redundant Home Agent set. 926 The source address MUST be set to the sender's home agent address. 927 Note, that in VHARP, the virtual home agent address MUST NOT be set 928 to the source address, the IP address of the interface the packet is 929 being sent from SHOULD be used. 931 The message SHOULD be secured by IPsec ESP. If all the home agents 932 are placed in a secure transport network to exchange the state 933 synchronization message, authentication and encryption MAY be 934 omitted. If security verification fails for a received state 935 synchronization message, the message MUST be discarded. The choice 936 of security mechanism used depends on the operational model of the 937 network. 939 4.4.3. Requesting State of Mobile Nodes (SS-REQ) 941 When a home agent needs the state information for a particular mobile 942 node, or a subset of mobile nodes, it sends a SS-REQ message 943 constructed as follows: 945 o It MUST set the Type field to 0 (Request). 947 o It MUST set a random value in the Identifier field that does not 948 coincide with any other currently pending Requests. 950 o It MUST include a Binding Cache Information option(s) in which the 951 Home Address field is set to the target home address. Other 952 fields of the Binding Cache Information option can be omitted. 954 o If the request is for the state of all the mobile nodes registered 955 at the destination home agent for the SS-REQ message, it MUST set 956 the Home Address field of the Binding Cache Information option to 957 the unspecified address (::). 959 o If the sender is requesting information about multiple mobile 960 nodes, it MUST include multiple binding cache information options 961 in a single SS-REQ. The sender SHOULD NOT send multiple SS-REQs 962 per mobile node. 964 o It MUST send a SS-REQ to the active home agent of the target 965 mobile node(s). 967 When a home agent receives a SS-REQ, it MUST perform the verification 968 described in Section 4.4.2 and the following: 970 o If the receiver does not have binding cache information for the 971 target mobile node(s) specified in the received Binding Cache 972 Information option(s), it MUST ignore the SS-REQ and MUST NOT 973 reply with a SS-REQ. 975 o Otherwise, the receiver MUST reply with a SS-REP, including all 976 the state information of the target mobile node(s). 978 4.4.4. Sending State Information (SS-REP) 980 An SS-REP message(s) SHOULD be sent when: 982 1. The active home agent receives an SS-REQ. 984 2. The active home agent creates or deletes a binding cache entry 985 for a particular mobile node. 987 The active home agent MAY additionally send an SS-REP message in the 988 following cases: 990 1. The active home agent updates the state information for all 991 sessions that have changed since the last update in a periodic 992 interval. 994 2. Often in VHARP, the active home agent MAY update a binding cache 995 entry for a particular mobile node whenever the binding cache 996 entry is updated. If an active home agent sends an SS-REP 997 message whenever the local state information changes, such as a 998 binding cache change, the number of the SS-REP messages can be 999 quite large. 1001 The following rules must be applied when the active home agent 1002 constructs a SS-REP: 1004 o It MUST copy the Identifier field of the SS-REQ to the same field 1005 of the SS-REP, if the SS-REP is sent in response to the SS-REQ. 1007 o It MUST set the Identifier field to zero (0) if the SS-REP is sent 1008 without solicitation (no SS-REQ). 1010 o It MUST include the required mobility options in the SS-REP. 1012 * In HARP, a partial Binding Cache Information option (the Home 1013 Address Field only) MUST be included in the SS-REP. 1015 * In VHARP, a full Binding Cache Information option, and other 1016 required options shown in Section 6.1.2, MUST be included in 1017 the SS-REP. 1019 o It MUST include the state of all the active mobile nodes 1020 registered at the active home agent in the SS-REP when the 1021 unspecified address is found in the Home Address mobility option 1022 carried with the SS-REQ. The message may be fragmented depending 1023 on the total size needed to carry all states. 1025 4.4.5. Synchronizing State (SS-REP and SS-ACK) 1027 When a home agent receives a SS-REP, it MUST take the following 1028 operations: 1030 o If no options are carried in the SS-REP, the home agent MUST 1031 ignore the SS-REP. 1033 o If the sender of SS-REP is not in the same global home agent set, 1034 the home agent MUST reject the SS-REP and MUST send SS-ACK with 1035 the Status Synchronization Status option in which status value is 1036 set to [130: Not in same global home agent set] 1038 o The receiver MUST record the IPv6 address of the sender as the 1039 active home agent of the mobile node in its local binding cache. 1041 o The receiver MUST update its binding cache, and all other 1042 necessary information, in its database(s). 1044 o If the A-flag is set in the SS-REP, the receiver MUST reply with 1045 an SS-ACK. 1047 If an active home agent requires an acknowledgment of a SS-REP, it 1048 MUST set the A-flag (Ack) in the SS-REP. The receiver of the SS-REP 1049 will send back an SS-ACK. The receiver MUST copy the Identifier 1050 value received in the SS-REP into the SS-ACK in order to match the 1051 SS-REP and SS-ACK. 1053 4.5. Switching the Active Home Agent 1055 In HARP, the standby home agent which is going to be active MUST send 1056 a Home Agent Switch message [RFC-5142] to all the mobile nodes that 1057 were being served by the failed home agent. The following rules MUST 1058 be applied when transmitting a Home Agent Switch message. 1060 o MUST use IPsec ESP to protect the Home Agent Switch message. 1062 o MUST set the address of the standby home agent address who is the 1063 sender of this Home Agent Switch message in the Home Agent Address 1064 field of the Home Agent Switch message [RFC-5142]. 1066 If there are a large number of mobile nodes served by the failed home 1067 agent, the overhead of sending Home Agent Switch messages is high. 1068 This overhead cannot be avoided if the active home agent suddenly 1069 stopped serving mobile nodes due to an unexpected reason (crash, 1070 network trouble, etc). However, if this switch-over is an 1071 administrative operation (maintenance, etc), the previous active home 1072 agent may continue serving the mobile nodes until the switch-over is 1073 complete. Until the mobile node sends a binding update to the new 1074 active home agent, it still sends packets to the previous home agent. 1076 When the new active home agent completes the switch-over, it SHOULD 1077 send a SW-COMP to the previous active home agent. Until the previous 1078 home agent receives this message, it SHOULD continue serving any 1079 mobile nodes that are registered with it. Once the previous home 1080 agent receives the SW-COMP message, it can be shutdown or detached 1081 from the network safely. 1083 In VHARP, after detecting the active home agent has failed, the 1084 standby home agent whose preference value is the highest MUST take 1085 over for the failed home agent. The standby home agent MUST activate 1086 the virtual home agent address and its virtual MAC address. A 1087 virtual MAC address as introduced in [RFC-3768, RFC-5798] SHOULD be 1088 used in VHARP. If VHARP is run with VRRP and HSRP as described in 1089 Section 4.7, the virtual home agent address can be treated as a 1090 virtual router address in VRRP and HSRP. Therefore, VRRP and HSRP 1091 can automatically activate the virtual home agent address on the 1092 standby home agent after their election mechanism has completed. 1093 Since all the necessary state has already been transferred to this 1094 standby home agent before the active home agent failed, it can 1095 immediately start acting as the active home agent. 1097 When the failed home agent is restarted and wants to become the 1098 active home agent again, it MUST re-establish an IPsec SA with each 1099 mobile node, as all the mobile nodes will have purged their IPsec SA 1100 with the home agent when the failure occurred. Otherwise, it cannot 1101 be a standby or active home agent for the mobile nodes. Therefore, 1102 as soon as the active home agent detects the recovery of the failed 1103 home agent, it sends a Home Agent Rekey message to all the mobile 1104 nodes served by other home agents in the same redundant home agent 1105 set, and includes the recovered home agent address in the Home Agent 1106 Addresses field. The detail of the Home Agent Rekey message is 1107 described in Section 6.1.3. The mobile node will re-key the SA by 1108 using The IKEv2 resumption mechanism [RFC-5723]. Alternatively, the 1109 mobile node MAY start a new IKE session with the recovered home 1110 agent. 1112 4.6. Consideration of Routing and Neighbor Discovery Protocol (VHARP) 1114 This section gives a brief explanation of how a home agent interacts 1115 with routing and Neighbor Discovery when VHARP is used. 1117 When a standby home agent becomes active in VHARP, it MUST start to 1118 advertise the home agent address, and the home prefix of the home 1119 addresses serviced by the redundant home agent set, into the routing 1120 infrastructure. This operation is normally done using a route 1121 selector such as BGP, or an OSPF modifier. For example, we can use 1122 the AS_Path prepend operation for BGP, and the Metric field in OSPF 1123 for the route selection. When each home agent participates in OSPF 1124 routing, each home agent should be configured with the appropriate 1125 metric matched to the home agent preference value. When the active 1126 home agent fails, OSPF detects the failure and can dynamically switch 1127 the route to the standby home Agent based on the OSPF cost value. If 1128 this creates conflicts with the home agent preference value due to 1129 configuration errors, the routers on the home link may not route 1130 packets to the desired standby home agent. In order to change the 1131 OSPF cost correctly and dynamically, the operator would use its 1132 existing approaches. For example, most router vendors have a private 1133 MIB to set the OSPF cost via SNMP, though this is a vendor- specific 1134 function. 1136 When an active home agent activates a home agent address, it SHOULD 1137 use a virtual MAC address as introduced in [RFC-3768, RFC-5798]. 1138 When the active home agent is changed, the neighbor cache of the 1139 active home agent is not necessarily updated on mobile nodes located 1140 on the home link. Otherwise, the new home agent MUST update the 1141 neighbor cache entry for the home agent address on all the mobile 1142 nodes located on the home link. In addition, Mobile IPv6 uses proxy 1143 Neighbour Discovery to intercept packets meant for mobile nodes which 1144 are away from the home link. However, it is unnecessary for the new 1145 active home agent to overwrite the existing proxy neighbor entries of 1146 the mobile nodes. 1148 4.7. Interworking with VRRP 1150 VRRP and HSRP specify an election protocol that dynamically assigns 1151 responsibility for a virtual router to one of the VRRP routers on a 1152 LAN. This operation is similar to VHARP. For example, the VRRP 1153 router controlling the IP address(es) associated with a virtual 1154 router is called the Master, and forwards packets sent to these IP 1155 addresses. The election process provides dynamic failover in the 1156 forwarding responsibility should the Master become unavailable. 1157 Although VRRP is used to guarantee home agent address reachability, 1158 it cannot be used for state synchronization and explicit switching of 1159 Master and Backup. Thus, the Home Agent Reliability Protocol cannot 1160 be replaced by VRRP. This section explains how VRRP can interwork 1161 with HARP/VHARP. 1163 When VRRP is available, VRRP can replace the Hello message described 1164 in Section 6.1.1. However, some information is missing by using just 1165 VRRP. After receiving a VRRP message, each home agent SHOULD process 1166 the message and store the information as if it had received a Home 1167 Agent Hello message, as described in Section 4.3.2.2. The message 1168 format of VRRP can be found in Section 5.1 of [RFC-5798]. Each field 1169 is mapped as follows: 1171 o Virtual Rtr ID: Group ID is stored in the Virtual Rtr ID field. 1173 o Priority: Home Agent Preference is stored in the Priority field. 1174 Note that VRRP only has 8 bits for the Priority field. Therefore, 1175 values larger than 255 MUST NOT be assigned to the preference 1176 value. 1178 o Count IPv6 IPv6 Addr: This field MUST be always be 1. 1180 o Max Advert Int: This field MUST be mapped to the Hello Interval 1181 field of the Home Agent Hello message, though it only has 12 1182 bytes. 1184 o IPv6 address: A home agent address is stored in this field. 1186 Home Agent Lifetime, Sequence Number and Flags fields are not present 1187 in the VRRP packet format. Therefore, operators SHOULD use the same 1188 statically configured value for Home Agent Lifetime. Each home agent 1189 does not check the freshness of received VRRP message because there 1190 is no sequence number. 1192 4.8. Retransmissions and Rate Limiting 1194 Home agents are responsible for retransmissions and rate limiting of 1195 SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response. 1197 The home agent MUST determine a value for the initial transmission 1198 timer: 1200 o If the home agent sends a SS-REQ message, it SHOULD use an initial 1201 retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER. 1203 o If a home agent sends a SWO-REQ or SWB-REQ message, it SHOULD use 1204 an initial retransmission interval of INITIAL_SWITCH_REQ_TIMER. 1206 If the sending home agent fails to receive a valid matching response 1207 within the selected initial retransmission interval, it SHOULD 1208 retransmit the message until a response is received. All of the 1209 above constants are specified in Section 8. 1211 The retransmission MUST use an exponential backoff process as 1212 described in [RFC-3775] until either the home agent receives a 1213 response, or the timeout period reaches the value 1214 MAC_HARELIABILITY_TIMEOUT. The home agent SHOULD use a separate 1215 back-off process for different message types and different 1216 destinations. The rate limiting of Mobility Header messages is the 1217 same as one in [RFC-3775]. A home agent MUST NOT send Mobility 1218 Header Messages to a particular home agent more than MAX_UPDATE_RATE 1219 (3) times a second, which is specified in [RFC-3775]. 1221 5. Mobile Node Operation 1223 This section describes the operations of a mobile node only when HARP 1224 is used. None of the operations in this section are required with 1225 VHARP. 1227 5.1. Home Agent Addresses Discovery 1229 A mobile node authenticates itself to two or more home agents and 1230 creates IPsec SAs with them during bootstrapping. When the active 1231 home agent fails, another home agent can use the pre-existing SA to 1232 notify the mobile node about the failure by sending a Home Agent 1233 Switch message. 1235 In order to discover multiple home agent addresses, two different 1236 mechanisms are defined in the bootstrapping solution in the split 1237 scenario [RFC-5026]. One is DNS lookup by home agent Name, the other 1238 is DNS lookup by Service Name. DHCPv6 can also be used in the 1239 integrated scenario [ID-BOOTINT] to provide home agent provisioning 1240 to mobile nodes. 1242 In the split scenario, a mobile node can use DNS lookup by Service 1243 Name to discover the home agents, as defined in [RFC-5026]. For 1244 example, if home agent reliability is required by a mobile node, DNS 1245 lookup by Service Name method is recommended for the mobile node to 1246 discover multiple home agent addresses. Therefore, mobile nodes will 1247 query the DNS SRV records with a service name of mip6 and protocol 1248 name of ipv6. The DNS SRV records includes multiple home agent 1249 addresses and different preference values and weights. The mobile 1250 node SHOULD choose two or more home agents from the home agents list 1251 according to their preference value. Then the mobile node should 1252 authenticate itself to these home agents via an IKEv2 exchange. 1254 In the integrated scenario, a mobile node can use DHCPv6 to get home 1255 agent provisioning from an MSP or ASP, as already defined in [ID- 1256 BOOTINT]. The only requirement is that the DHCPv6 response must 1257 include multiple home agents' information in order to support home 1258 agent reliability. 1260 5.2. IPsec/IKE Establishment to Home Agents 1262 In this document, a mobile node needs to manage an IPsec SA with a 1263 home agent(s). The following mechanisms can be used to manage the 1264 IPsec SA(s) with a home agent(s): 1266 o IKEv1/v2 running per home agent (HARP) to establish multiple IPsec 1267 SAs for home agents. 1269 o The IKEv2 resumption mechanism [RFC-5723] to update an IPsec SA 1270 with the new home agent (VHARP) 1272 If an IPsec/IKEv2 state synchronization mechanism is available in 1273 Virtual Private Network (VPN) products, none of above is required for 1274 the VHARP operation. The IPsec SAs per mobile node are seamlessly 1275 copied among multiple home agents. 1277 The mobile node MUST follow the standard IKEv2 exchange in the 1278 bootstrapping solution of the split scenario [RFC-5026]. If multiple 1279 IKEv2 operations are run per home agent, the mobile node MUST NOT 1280 attempt the home address assignment to standby home agents. 1282 5.3. Synchronizing State: K-bit treatment 1284 When a mobile node moves and the care-of address changes, it can use 1285 the Key Management Mobility Capability (K) bit in the Binding Update 1286 in order to update the peer endpoint of the key management protocol, 1287 for example, the IKE Security Association. 1289 If an active home agent receives a Binding Update with the K-bit set, 1290 it MUST process the Binding Update as specified in [RFC-3775]. In 1291 addition, the active home agent MUST notify the other standby home 1292 agents of the care-of address change. To do so, it MUST send a State 1293 Synchronization Reply message, including a Binding Cache Information 1294 option, to all the other standby home agents. The flags of the 1295 Binding Update MUST be copied to the flags field of the Binding Cache 1296 Information option. The standby home agents will update the peer 1297 endpoint of the key management protocol upon detecting the K-bit it 1298 set in the Flag field of the Binding Cache Information option. 1300 If the K-bit is not set in the Binding Update, an active home agent 1301 needs to rerun the key management protocol. The active home agent 1302 MUST send State Synchronization Reply messages, including Binding 1303 Cache Information options, to all the other standby home agents. The 1304 flags of the Binding Update MUST be copied to the flags field of the 1305 Binding Cache Information option. The standby home agents that 1306 receive the State Synchronization Reply message will detect the 1307 care-of address change and rerun the key management protocol. 1309 5.4. Receiving Home Agent Switch message 1311 A mobile node must follow the verification and operations specified 1312 in [RFC-5142] when it receives a Home Agent Switch message. 1314 The Home Agent Switch message MUST be securely exchanged between a 1315 mobile node and a home agent by using IPsec ESP. 1317 When the mobile node receives a Home Agent Switch message, if the 1318 message contains the IPv6 address of a standby home agent, it MUST 1319 select the standby home agent as its active home agent and MUST send 1320 a new Binding Update message to it. 1322 The standby home agent address in the Home Agent Switch message MUST 1323 be equal to the sender of the Home Agent Switch message. If the IPv6 1324 address stored in the Home Agent address field is different from the 1325 sender's source IPv6 address, the mobile node MUST send a binding 1326 update to the sender and MUST NOT use the IPv6 address in the Home 1327 Agent Switch message. 1329 6. Messages Format 1331 6.1. New Mobility Header Messages 1333 6.1.1. HARP Message Format 1335 The HARP message has the type field to identify different roles. The 1336 HARP message has the MH Type value TBD. 1338 0 1 2 3 1339 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 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Type | Group ID | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Sequence # |A|R|V|M| Rsvd | Status | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Home Agent Preference | Home Agent Lifetime | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Hello Interval | | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1349 | | 1350 . Mobility Options . 1351 . . 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 6: Home Agent Hello Message 1356 Type 1358 8-bit unsigned integer. It can be assigned one of the following 1359 values: 1361 0: SwitchOver Request (SWO-REQ) 1363 Unicast by a standby home agent that desires to become the 1364 active home agent. The receiver of the message MUST transition 1365 to standby state as soon as the message is received and 1366 validated successfully. 1368 1: SwitchOver Reply (SWO-REP) 1370 Used to acknowledge the receipt of the corresponding SWO-REQ. 1372 2: SwitchBack Request (SWB-REQ) 1374 Unicast by an active home agent that desires to become a 1375 standby home agent. The receiver of this message SHOULD 1376 transition to active state as soon as the message is received 1377 and validated successfully. 1379 3: SwitchBack Reply (SWB-REP) 1381 Used to acknowledge the receipt of the corresponding SWB-REQ. 1383 4: Switch Complete (SW-COMP) 1385 Used to indicate the completion of a switch-over, (i.e. sending 1386 Home Agent Switch messages, and receiving binding update 1387 messages from all the served mobile nodes). 1389 4: Home Agent HELLO (HA-HELLO) 1391 Used to carry home agent information among the redundant home 1392 agent set. MUST be either unicast or multicast. The HA-Hello 1393 message is defined for two purpose: 1) an alive check and 2) 1394 home agent information exchange. 1396 Group Identifier 1398 8-bit unsigned integer. This value is used to identify a 1399 particular redundant home agent set. 1401 Sequence # 1403 16-bit unsigned integer. The Sequence number of the HA-Hello 1404 message can be used to verify whether this Hello message is the 1405 latest one or not. 1407 (A)ctive flag 1409 Active Home Agent flag. If this flag is set, the sender of this 1410 HA-Hello message is an active home agent. 1412 (R)equest flag 1414 HA-HELLO requesting flag. If this flag is set, the receiver of 1415 this HA-Hello message must send back a HA-Hello message to the 1416 sender. 1418 (V)HARP capability flag 1420 VHARP capability Flag. If a home agent is capable of IPsec/IKE 1421 state synchronization, it MUST set this flag. 1423 (M)ode flag 1425 A home agent MUST set this flag only when VHARP is used in the 1426 current operation. If the flag is unset, the home agent currently 1427 operates HARP. (HARP:0, VHARP:1) 1429 Reserved 1431 This field is unused. It MUST be initialized to zero by the 1432 sender and MUST be ignored by the receiver. 1434 Status 1436 8-bit unsigned integer indicating the disposition of a SWO-REQ or 1437 SWB-REQ. This field is only valid in SWO-REP and SWB-REP 1438 messages. The following Status values are defined: 1440 0: Success 1442 128: Reason unspecified 1444 129: Administratively prohibited 1446 130: Not active home agent (The receiver of SWO-REQ is not the 1447 active home agent) 1449 131: Not standby home agent (The receiver of SWB-REQ is already 1450 the active home agent) 1452 132: Not in same redundant home agent set 1454 Home Agent Preference 1456 16-bit unsigned integer. The preference for the home agent 1457 sending the HA-Hello message. This preference is the same as the 1458 Home Agent Preference value of the Home Agent Information option 1459 as defined in [RFC-3775]. However, operators MAY use a different 1460 preference value for this operation. 1462 Home Agent Lifetime 1464 16-bit unsigned integer. The lifetime for the home agent sending 1465 the HA-Hello message. This lifetime is the same as the Home Agent 1466 Lifetime value of the Home Agent Information option as defined in 1467 [RFC-3775]. 1469 Hello Interval 1471 16-bit unsigned integer. The interval for the home agent sending 1472 this Hello message. 1474 Mobility Options 1476 Variable-length field of such length that the complete Mobility 1477 Header is an integer multiple of 8 octets long. This field 1478 contains zero or more TLV-encoded mobility options. The encoding 1479 and format of defined options are described in [RFC-3775]. The 1480 receiver MUST ignore and skip any options which it does not 1481 understand. This specification does not define any options valid 1482 for the HARP message. 1484 6.1.2. State Synchronization Message Format 1486 This message is used to exchange state corresponding to a particular 1487 mobile node(s). It MUST be unicast and MUST be authenticated by 1488 IPsec ESP. This message has the MH Type value TBD. 1490 0 1 2 3 1491 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 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Type |A| Reserved | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Identifier | | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1497 . . 1498 . Mobility Options . 1499 . . 1500 . | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 Figure 7: State Synchronization Message 1505 Type 1507 8-bit unsigned integer. It can be assigned one of the following 1508 values: 1510 0: State Synchronization Request (SS-REQ) 1512 Used to solicit the active state corresponding to a particular 1513 mobile node. 1515 1: State Synchronization Reply (SS-REP) 1516 Used between the home agents in the redundant home agent set to 1517 exchange binding cache and any other information related to 1518 providing mobility service to the mobile nodes. Sent either 1519 periodically or in response to a SS-REQ. 1521 2: State Synchronization Reply-Ack (SS-ACK) 1523 This message is optional and is used only when the links 1524 between home agents are not reliable. 1526 (A)ck flag 1528 This flag is valid only for SS-REP. If the sender requires 1529 explicit acknowledgment by an SS-ACK, it MUST set this flag. 1531 Reserved 1533 This field is unused. It MUST be initialized to zero by the 1534 sender and MUST be ignored by the receiver. 1536 Identifier 1538 A 16-bit identifier to aid in matching state synchronization 1539 messages. The identifier should never be set to 0. It should 1540 always be more than 1. 1542 Mobility Options 1544 Variable-length field of such length that the complete Mobility 1545 Header is an integer multiple of 8 octets long. This field 1546 contains zero or more TLV-encoded mobility options. The encoding 1547 and format of defined options are described in [RFC-3775]. The 1548 receiver MUST ignore and skip any options which it does not 1549 understand. This message requires at least one mobility option, 1550 therefore, there is no default length for this message. 1552 Binding Cache Information Option is mandatory in the SS-REQ 1553 message. Multiple options can be stored in the same SS-REQ 1554 message. A home agent includes the mobile node's home address in 1555 the Binding Cache Information option. If a home agent wants to 1556 solicit all the active mobile nodes' states, it can include the 1557 unspecified address (::) in an IPv6 address option. 1559 Binding Cache Information option is mandatory in SS-REP. SS-REP 1560 can carry many mobility options. The following options are just 1561 examples. 1563 * AAA Information Option 1565 * Vendor Specific Mobility Option [RFC-5094] 1567 * Mobile Network Prefix Option [RFC-3963] 1569 * IPv4 Care-of Address Option [RFC-5555] 1571 * IPv4 Home Address Option [RFC-5555] 1573 * Binding Identifier Option [RFC-5648] 1575 6.1.3. Home Agent Rekey Message 1577 This message is used to indicate that the mobile node SHOULD start an 1578 IPsec re-key with the home agent specified in the Home Agent 1579 Addresses field. This message is used when a failed home agent 1580 recovers and needs to re-establish IPsec SA/IKE state with a mobile 1581 node. This message MUST be unicast to a mobile node by the active 1582 home agent and MUST be authenticated and encrypted by IPsec ESP. The 1583 Home Agent Rekey message has the MH Type value TBD. If no options 1584 are present in this message, no padding is necessary and the Header 1585 Len field will be set to 2. 1587 0 1 2 3 1588 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 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Reserved | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | | 1593 + + 1594 . Home Agent Addresses . 1595 + + 1596 | | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 . Mobility options . 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 Figure 8: Home Agent Rekey Message 1603 Reserved 1605 A 16-bit field reserved for future use. The value MUST be 1606 initialized to zero by the sender, and MUST be ignored by the 1607 receiver. 1609 Home Agent Address 1611 The receiver of this message MUST re-key the security association 1612 with the specified home agent. 1614 When a mobile node receives a Home Agent Rekey message, it MUST 1615 verify the message as follows: 1617 o The message MUST be sent from the receiver's active home agent. 1618 Otherwise, the message MUST be discarded. 1620 o The message MUST be protected by IPsec ESP. Otherwise, the 1621 message MUST be discarded. 1623 o The message SHOULD contain one of the standby home agent's 1624 addresses. If the home agent address is not known from the 1625 bootstrapping described in Section 5.1, the mobile node MUST NOT 1626 start an IKE re-key session with the unknown home agent. Instead, 1627 it SHOULD re-start home agent discovery to update its home agent 1628 address information. 1630 If all the above verifications are satisfied, the mobile node MUST 1631 re-key the SA with the home agent addresses stored in the Home Agent 1632 Addresses field. 1634 6.2. New Mobility Options 1636 6.2.1. Binding Cache Information Option 1638 The Binding Cache Information option is used to carry Binding Cache 1639 Information of each mobile node. This option is only valid in a 1640 State Synchronization message. Its format is as follows: 1642 0 1 2 3 1643 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 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Type = TBD | Length | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | | 1648 + + 1649 | Home Address | 1650 + + 1651 | | 1652 + + 1653 | | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 : : 1656 + + 1657 : : 1658 + Care-of Address + 1659 : : 1660 + + 1661 : : 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 : Flags : Sequence Number : 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 : Lifetime : Reserved : 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 Figure 9: Binding Cache Information Option 1670 Length 1672 8-bit unsigned integer, representing the length in octets of the 1673 mobility option, not including the Option Type and Option Length 1674 fields. There are two valid length values, 16 and 40, depending 1675 on the number of fields in use. The alignment requirement is 1676 either 8n+6 (length 16) or 8n+2 (length 40). 1678 Home Address 1680 The Home Address of a mobile node. 1682 Care-of Address 1684 Flags 1685 Sequence Number 1687 Lifetime 1689 Optional values only used in VHARP, in which case the 1690 corresponding value from the binding cache database of the active 1691 home agent is copied into each field. 1693 Reserved 1695 A 16-bit field reserved for future use. The value MUST be 1696 initialized to zero by the sender, and MUST be ignored by the 1697 receiver. 1699 6.2.2. State Synchronization Status Option 1701 The State Synchronization Status option is used to carry the status 1702 value of an SS-ACK for a received SS-REP. In [ID-HAHA], SS-ACK is 1703 mandatory in response of an SS-REP to update global binding 1704 registration status. 1706 0 1 2 3 1707 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 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Type = TBD | Length = 20 | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Status | Reserved | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | | 1714 + + 1715 | Home Address | 1716 + + 1717 | | 1718 + + 1719 | | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 Figure 10: State Synchronization Status Option 1724 Status 1726 8-bit unsigned integer indicating the status of the SS-REP. 1728 * 0: Success 1729 * 128: Reason unspecified 1731 * 129: Malformed SS-REP 1733 * 130: Not in same global home agent set 1735 Reserved 1737 A 24-bit field reserved for future use. The value MUST be 1738 initialized to zero by the sender, and MUST be ignored by the 1739 receiver. 1741 Home Address 1743 Corresponding home address of the mobile node. 1745 6.2.3. AAA Information Option 1747 This option is used to carry the AAA state of the mobile node's 1748 Mobile IPv6 sessions. The AAA state information can be carried in 1749 RADIUS or Diameter AVP formats, including the user and session info. 1750 This information option is only valid in a State Synchronization 1751 message. 1753 0 1 2 3 1754 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 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Type = TBD | Length | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 . . 1759 . AAA AVPs . 1760 . . 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 Figure 11: AAA Information Option 1765 Length 1767 8-bit unsigned integer, representing the length in octets of the 1768 mobility option, not including the Option Type and Option Length 1769 fields. 1771 AAA AVPs 1772 A series of TLV-encoded AAA AVPs (including vendor specific AVPs) 1773 carrying AAA-related information for each Mobile IPv6 and IPsec/ 1774 IKE session. 1776 7. Security Considerations 1778 All the messages newly defined in this document SHOULD be secured by 1779 IPsec ESP. When a HA-HELLO message is multicast, the multicast 1780 extensions to IPsec [RFC-5374] is used. In some operational 1781 scenarios, home agents are located deep in the core network and 1782 securely managed. If there is a secure transport network between 1783 home agents, some of security mechanism can be disabled, depending on 1784 administrative policy. 1786 A Home Agent Switch message is reused for signaling between a home 1787 agent and a mobile node in HARP. It is protected by IPsec ESP as 1788 defined in [RFC-5142]. 1790 When an active home agent fails, mobile nodes using that home agent 1791 need to change their home agent to one of standby home agents. The 1792 mobile node needs to update or establish the IPsec SA with the new 1793 home agent as described in Section 5.2. Existing mechanisms 1794 [RFC5723] are applied to this operation. 1796 8. Protocol Constants 1798 INITIAL_STATE_SYNC_REQ_TIMER: 3sec 1800 INITIAL_SWITCH_REQ_TIMER: 1sec 1802 MAC_HARELIABILITY_TIMEOUT 16sec 1804 ALL_HA_MULTICAST_ADDR: TBD 1806 9. Protocol Configuration Variables 1808 LINK_TRAVERSAL_TIME: default 150msec 1810 10. IANA Considerations 1812 The following Extension Types MUST be assigned by IANA: 1814 o Home Agent Reliability Protocol (HARP) Message 1815 o State Synchronization (SS) Message 1817 o Binding Cache Information Option 1819 o AAA Information Option 1821 o A new link-local multicast address (ALL_HA_MULTICAST_ADDR) for all 1822 home agents will be assigned by the IANA. 1824 11. Additional Authors 1826 This document is a result of discussions in the Mobile IPv6 Home 1827 Agent Reliability Design Team. The members of the design team that 1828 are listed below are authors that have contributed to this document: 1830 Samita Chakrabarti 1832 samita.chakrabarti@azairenet.com 1834 Kuntal Chowdhury 1836 kchowdhury@starentnetworks.com 1838 Hui Deng 1840 denghui@chinamobile.com 1842 Vijay Devarapalli 1844 vijay.devarapalli@azairenet.com 1846 Sri Gundavelli 1848 sgundave@cisco.com 1850 Brian Haley 1852 brian.haley@hp.com 1854 Behcet Sarikaya 1856 bsarikaya@huawei.com 1858 Ryuji Wakikawa 1859 ryuji.wakikawa@gmail.com 1861 12. Acknowledgements 1863 This document includes a lot of text from [ID-LOCALHAHA] and [ID- 1864 HAHA]. Therefore the authors of these two documents are 1865 acknowledged. We would also like to thank the authors of the home 1866 agent reliability problem statement [ID-PS-HARELIABILITY] for 1867 describing the problem succinctly and Alice Qin for her work on the 1868 hello protocol. 1870 13. References 1872 13.1. Normative References 1874 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1875 Requirement Levels", BCP 14, RFC 2119, March 1997. 1877 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1878 IPv6", RFC 3775, June 2004. 1880 [ID-3775bis] Perkins, C., Johnson, D., Arkko, J., "Mobility Support 1881 in IPv6", draft-ietf-mext-rfc3775bis-10.txt, Octover 2010. 1883 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1884 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1885 January 2005. 1887 [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split 1888 scenario", RFC 5026, October 2007. 1890 [RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC 1891 5094, October 2007. 1893 [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message", 1894 RFC-5142, November 2007. 1896 [RFC-5374] B. Weis, G. GrossD. Ignjatic, "Multicast Extensions to 1897 the Security Architecture for the Internet Protocol", RFC 5374, 1898 November 2008 1900 [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack 1901 Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. 1903 [RFC-5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1904 and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, 1905 October 2009. 1907 [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via 1908 DHCPv6 for the Integrated Scenario", 1909 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), 1910 April 2008. 1912 13.2. Informative References 1914 [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot 1915 Standby Router Protocol (HSRP)", RFC 2281, March 1998. 1917 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1918 RFC 3753, June 2004. 1920 [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1921 RFC 3768, April 2004. 1923 [RFC-4285] A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury, 1924 "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006 1926 [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with 1927 IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 1929 [RFC-5723] Y. Sheffer, H. Tschofenig, "Internet Key Exchange Protocol 1930 Version 2 (IKEv2) Session Resumption", RFC 5273, January 2010. 1932 [RFC-5798] S. Nadas, "Virtual Router Redundancy Protocol Version 3 1933 for IPv4 and IPv6", RFC 5798 (soon?), December 2009. 1935 [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", 1936 draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. 1938 [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", 1939 draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. 1941 [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent 1942 Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), 1943 February 2004. 1945 Author's Address 1947 Ryuji Wakikawa 1948 TOYOTA InfoTechnology Center, U.S.A., Inc. 1949 465 Bernardo Avenue 1950 Mountain View, CA 94043 1951 USA 1953 Email: ryuji.wakikawa@gmail.com