idnits 2.17.1 draft-ietf-mip6-hareliability-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (July 12, 2010) is 5037 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: 'RFC5723' is mentioned on line 1750, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3768 (Obsoleted by RFC 5798) Summary: 2 errors (**), 0 flaws (~~), 2 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 4 Intended status: Standards Track July 12, 2010 5 Expires: January 13, 2011 7 Home Agent Reliability Protocol (HARP) 8 draft-ietf-mip6-hareliability-06.txt 10 Abstract 12 The home agent can be a single point of failure when Mobile IPv6 and 13 its compatible protocols are operated in a system. It is critical to 14 provide home agent reliability in the event of a home agent crashing 15 or becoming unavailable. This would allow another home agent to take 16 over and continue providing service to the mobile nodes. This 17 document describes the problem scope briefly and provides mechanisms 18 of home agent failure detection, home agent state transfer, and home 19 agent switching for home agent redundancy and reliability. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 13, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Problem Statement and Requirements . . . . . . . . . . . . 6 65 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 11 68 3.1. Network Configuration . . . . . . . . . . . . . . . . . . 11 69 3.2. Home Agent Address Configuration . . . . . . . . . . . . . 12 71 4. Home Agent Operations . . . . . . . . . . . . . . . . . . . . 12 72 4.1. Home Agent List Management . . . . . . . . . . . . . . . . 12 73 4.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 14 74 4.3. Processing the HARP Messages . . . . . . . . . . . . . . . 14 75 4.3.1. IP field and Security Descriptions of HARP message . . 14 76 4.3.2. Processing Home Agent Hello (HA-HELLO) . . . . . . . . 16 77 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) . . . 17 78 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) . . . 18 79 4.4. State Synchronization . . . . . . . . . . . . . . . . . . 19 80 4.4.1. Binding Cache Information Management . . . . . . . . . 20 81 4.4.2. IP field and Security Descriptions of SS message . . . 20 82 4.4.3. Requesting State of Mobile Nodes (SS-REQ) . . . . . . 20 83 4.4.4. Sending State Information (SS-REP) . . . . . . . . . . 21 84 4.4.5. Synchronizing State (SS-REP and SS-ACK) . . . . . . . 22 85 4.5. Switching the Active Home Agent . . . . . . . . . . . . . 23 86 4.6. Consideration of Routing and Neighbor Discovery 87 Protocol (VHARP) . . . . . . . . . . . . . . . . . . . . . 24 88 4.7. Interworking with VRRP . . . . . . . . . . . . . . . . . . 25 89 4.8. Retransmissions and Rate Limiting . . . . . . . . . . . . 26 91 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 26 92 5.1. Home Agent Addresses Discovery . . . . . . . . . . . . . . 26 93 5.2. IPsec/IKE Establishment to Home Agents . . . . . . . . . . 27 94 5.3. Synchronizing State: K-bit treatment . . . . . . . . . . . 28 95 5.4. Receiving Home Agent Switch message . . . . . . . . . . . 28 97 6. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 29 98 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 29 99 6.1.1. HARP Message Format . . . . . . . . . . . . . . . . . 29 100 6.1.2. State Synchronization Message Format . . . . . . . . . 32 101 6.1.3. Home Agent Rekey Message . . . . . . . . . . . . . . . 34 102 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 35 103 6.2.1. Binding Cache Information Option . . . . . . . . . . . 35 104 6.2.2. State Synchronization Status Option . . . . . . . . . 36 105 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 38 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 109 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 39 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 113 10. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 39 115 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 41 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 123 1. Introduction 125 In Mobile IPv6 [RFC-3775] and its compatible protocols like NEMO 126 Basic Support [RFC-3963] and Dual Stack Mobile IPv6 [RFC-5555], if a 127 home agent loses the binding cache state, due to failure or some 128 other reason, it results in a loss of service for the mobile nodes. 129 It is beneficial to provide high availability and redundancy for a 130 home agent so that mobile nodes can avail of uninterrupted service 131 even when one home agent crashes or loses state. The Home Agent 132 Reliability protocol (HARP) is designed to manage standby home agents 133 and switch a home agent in case of the active home agent 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 to both a mobile node 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 Providing reliability by using multiple home agents with 151 individual home agent addresses. It requires binding re- 152 registration to the new home agent. 154 Virtual Home Agent Reliability Protocol (VHARP) 156 Providing reliability by using multiple home agents and single 157 virtual home agent address. It can virtually switch to the new 158 home agent without binding re-registration to the new home agent. 160 Active Home Agent 162 A home agent that is currently serving the mobile nodes. 164 Standby Home Agent 166 A home agent which will serve the mobile nodes when the active 167 home agent fails. 169 Failed Home Agent 171 A home agent that is not available due to hardware or software 172 failure, system maintenance, etc. 174 Redundant Home Agent Set 176 A group of an active and standby home agent(s). The Group 177 Identifier is used to identify a redundant home agent set. 178 Operators need to configure a value per redundant home agent set. 180 Virtual Home Agent Address 182 A home agent address shared among home agents in a redundant home 183 agent set. It is similar to virtual router address specified in 184 VRRP [RFC-3768] [RFC-5798]. The address is only activated on an 185 active home agent. 187 Home Agent Preference 189 This preference value is originally defined for Dynamic Home Agent 190 Address Discovery (DHAAD) in RFC3775. This protocol re-uses this 191 preference value for home agent selection when an active home 192 agent has failed. However, an operator can also define an 193 independent value used only for the home agent reliability 194 protocol if the operator wants to have different preference values 195 for DHAAD and the home agent reliability protocol. A home agent 196 SHOULD NOT use the same preference value of other home agents. 198 New Messages 200 Home Agent Reliability Protocol (HARP) message defined in 201 Section 6.1.1: 203 SwitchOver Request (SWO-REQ) 205 SwitchOver Reply (SWO-REP) 207 SwitchBack Request (SWB-REQ) 209 SwitchBack Reply (SWB-REP) 211 Switch Complete (SW-COMP) 213 Home Agent HELLO (HA-HELLO) 215 State Synchronization (SS) message defined in Section 6.1.2: 217 State Synchronization Request (SS-REQ) 219 State Synchronization Reply (SS-REP) 221 State Synchronization Reply-Ack (SS-ACK) 223 1.2. Problem Statement and Requirements 225 In Mobile IPv6 [RFC-3775, RFC-4877], a mobile node registers and 226 establishes a binding with only one home agent. The home agent 227 represents the possibility of a single point of failure for Mobile 228 IPv6. A home agent is responsible for multiple mobile nodes on its 229 home link. The failure of the home agent may then result in the loss 230 of connectivity for numerous mobile nodes located throughout the 231 Internet. To overcome this problem, Mobile IPv6 allows deployment of 232 multiple home agents on the home link so that upon the failure of a 233 home agent, a mobile node can re-establish its connection through a 234 new home agent. However, the base Mobile IPv6 specification does not 235 address home agent fail-over and dynamic transfer of service from one 236 home agent to another. This transfer of service from the failed home 237 agent to a new active home agent requires coordination or pre- 238 configuration among the home agents regarding security associations, 239 transfer of mobile node bindings, and other service information for 240 reliable Mobile IPv6 service in a deployment scenario. 242 For the home agent reliability solution, we define the following 243 requirements: 245 Reliable Home agent service 247 Multiple home agents are available for a home prefix and one of 248 them actively serves the mobile nodes. A standby home agent takes 249 over when the active home agent becomes unavailable. The transfer 250 of the MN-HA association should be transparent to applications and 251 should not take longer than the care-of-addresses update procedure 252 described in Mobile IPv6 [RFC-3775]. 254 Availability of a redundant home agent set 256 Availability of an active home agent address and a standby home 257 agent address at the bootstrapping period for the mobile node is 258 assumed. 260 State Synchronization 262 The information for mobile nodes must be able to be synchronized 263 between an active home agent and standby home agents. This 264 includes the Binding Cache, AAA information, other Mobile IPv6 and 265 NEMO related information. Note that the Home Agent Reliability 266 protocol exchanges only running states of mobile nodes. 267 Therefore, we do not have any specific operation for synchronizing 268 the configuration information. For instance, when Mobile IPv6 is 269 operated with Authentication protocol, synchronizing the 270 configurations of the Authentication protocol is out of scope in 271 this document. Operators MAY correctly set the configuration 272 information in multiple home agents. 274 Consideration of IPsec/IKE transfer 276 An active home agent maintains several IPsec and IKE states for 277 mobile nodes. These states are synchronized within the redundant 278 home agent set. The details are described in Section 7. 280 Secured Message Exchanges 282 The messages used between the home agents to transfer binding 283 cache information MAY be authenticated and encrypted. 285 Failure Detection 287 Redundant home agents must actively check for possible failure of 288 an active home agent. If a home agent supports an existing 289 failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC- 290 2281], it can re-use that mechanism to detect the home agent 291 failure. On the other hand, periodic Hello messages are 292 introduced to detect active home agent's service availability in 293 this document. 295 Failure Notification 297 If necessary, a mobile node is notified about the active home 298 agent failure by the standby home agent. 300 2. Protocol Overview 302 HARP assumes multiple home agents placement on a same home link or 303 different links and groups them into a redundant home agent set. One 304 of home agents is selected as an active home agent and receives a 305 binding update from mobile nodes. According to [RFC-3775, RFC-4877], 306 an active home agent maintains not only binding cache but also IPsec/ 307 IKEv2 states per mobile node, because Mobile IP adapts IPsec as its 308 security mechanism for signaling. 310 If the active home agent fails, all these information per mobile node 311 is vanished. As a result, all mobile nodes served by the failed home 312 agent will be disconnected. In HARP, other home agents , named 313 standby home agent, exchange the required information with the active 314 home agent in case of failure of the active home agent. HARP can let 315 standby home agent take over the failed home agent with such 316 information of the serving mobile nodes. 318 MN HA1 HA2 319 | |<-HA1-addr |<-HA2-addr 320 | | | 321 | (active) (standby) 322 | | | 323 | |<--------->| 1. Hello exchanges 324 |<--------->| | 2. Binding Registration to HA1 325 | |<--------->| 3. State exchanges 326 | | | 327 | X | HA1 FAILURE 328 | X | 329 | X | 4. Failure Detection 330 |<----------------------| 5. Sending Home Agent Switch message 331 |<--------------------->| 6. Binding Registration to HA2 332 | X (active) RECOVERY COMPLETE 333 | X | 335 Figure 1: Overview of Home Agent Reliability Protocol (HARP) 337 Figure 1 shows an example of the HARP operations. HA1 and HA2 belong 338 to the same redundant home agent set and are assigned with an 339 individual IP address (HA1 and HA2-addr) at the home link. Each home 340 agent can be seen as an individual home agent by mobile nodes. All 341 the home agents periodically send a hello message (named HA-HELLO) to 342 exchange the home agent information and also monitor the active home 343 agent's status (1). The mobile node registers its binding only with 344 the active home agent (2). The active home agent synchronizes the 345 serving mobile node information (i.e. home address) with the other 346 standby home agents periodically (3). 348 HARP introduces the new HA-HELLO message for failure detection, but 349 it should use any types of information to detect that failure. After 350 detecting failure of the active home agent (4), a standby home agent 351 whose preference value is the highest takes over the failed home 352 agent. For doing so, the standby home agent sends a Home Agent 353 Switch message to all the mobile nodes that were registered at the 354 failed home agent (5). The standby Home Agent set its own address in 355 the Home Agent Address field in the Home Agent Switch message so that 356 it will receive the binding update from the mobile node as an 357 acknowledgment of the sent Home Agent Switch message. The home agent 358 switch-over is complete when it receives binding updates from all the 359 mobile nodes (6). For protecting the Home Agent Switch, the mobile 360 node should have IPsec Security Associations (SA) with the standby 361 home agent before any failover. The mobile node may pre-establish 362 multiple IPsec SAs with all the home agents. 364 Although the active home agent manages IPsec/IKEv2 states per mobile 365 node, HARP does not offer any recovery mechanism of these states by 366 itself. IPsec/IKE states synchronization is out of scope in this 367 document. However, some Virtual Private Network (VPN) products have 368 proprietary IPsec/IKEv2 state synchronization among multiple boxes. 369 If IPsec/IKEv2 states can be recovered from the active home agent to 370 standby one, HARP can be operated slightly in different manner named 371 Virtual-HARP (VHARP). Unlike HARP, the standby home agents are an 372 exact copy of the active home agent. It is similar to the virtual 373 router concept of VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. Note 374 that HARP is mandatory and VHARP is optional in this document. VHARP 375 is shown in Figure 2. 377 MN HA1 HA2 378 | |<-HA-addr :<-HA-addr' 379 | | : 380 | (active) (standby) 381 |<--------->| : 1. Binding Registration to HA1 382 | |<--------->: 2. State exchanges 383 | | : 384 | X : HA1 FAILURE 385 | X : 386 | X : 3. Failure Detection 387 | X | 4. HA2 takes over the HA1 388 | X (active) RECOVERY COMPLETE 389 | X | 391 Figure 2: Overview of Virtual Home Agent Reliability Protocol (VHARP) 393 All the home agents (HA1 and HA2) in the redundant home agent set 394 share a virtual home agent address (HA-addr) and the routing will 395 ensure only the active home agent will be reachable using that 396 virtual home agent address. After a mobile node's binding 397 registration (1), the active home agent pushes all the states of its 398 mobile nodes to the other standby home agents (2). In VHARP, all the 399 states of a mobile node need to be synchronized. The example 400 information such as Binding Cache and Authentication, Authorization, 401 and Accounting (AAA) information, etc. 403 After detecting the active home agent has failed (3), the standby 404 home agent whose preference value is the highest takes over the 405 failed home agent. The standby home agent activates the virtual home 406 agent address on its interface attached to the home link. The 407 virtual home agent address's activation can be operated by VRRP. 408 Since all the necessary states of mobile nodes have already been 409 transferred to this standby home agent, the standby home agent can 410 immediately start acting as the active home agent (4). Unlike HARP, 411 the mobile node is not required to re-register its binding to a new 412 active home agent. The mobile node may use the IKEv2 resumption 413 mechanism [RFC-5723] to resume IPsec SA with the new active home 414 agent. 416 This document offers a new management mechanism of an active and 417 standby home agents by using a new Mobility Header (MH) message named 418 a HARP message as shown in Figure 3. This mechanism can be used in 419 both HARP and VHARP. Each home agent exchanges own home agent 420 information with the other home agents in its redundancy home agent 421 set by a Home Agent HELLO message (HA-HELLO) (1). The HA-HELLO 422 message can also be used to monitor the availability of the active 423 home agent. 425 HA1(active) HA2 HA3 .. HAn 426 | | | | 427 |<------>|<---->|<---->| 1. HELLO exchange 428 |------->| | | 2. HA1 sends SWB-REQ 429 |<-------| | | 3. HA2 sends SWB-REP 430 |------->| | | 4. HA2 sends SW-COMP 431 (standby) (active) | | HA2 BECOMES ACTIVE HA 432 | | | | 433 SYSTEM MAINTENANCE, ETC. 434 | | | | 435 |------->| | | 5. HA1 sends SWO-REQ 436 |<-------| | | 6. HA2 sends SWO-REP 437 |------->| | | 7. HA1 sends SW-COMP (optional) 438 (active) (standby) | | 8. HA1 returns to active HA 439 | | | | HA1 BECOMES ACTIVE AGAIN 441 Figure 3: Home Agent Management 443 In some scenarios the active home agent may need to stop serving 444 mobile nodes for system maintenance. This specification provides for 445 a manual home agent management. As shown in Figure 3, the active 446 home agent (HA1) sends a SwitchBack Request message (SWB-REQ) to a 447 standby home agent (HA2) (2). HA2 will acknowledge the message by 448 sending a SwitchBack Reply message (SWB-REP) to HA1 (3). In the HARP 449 operation, it takes certain time to complete home agent fail-over by 450 mobile nodes' re-registration to the new home agent. During this 451 fail-over operations, HA1 may continue serving the mobile nodes until 452 the switch over is completed. When HA2 completes the switch-over, it 453 SHOULD send a SW-COMP to HA1 (4). As soon as HA2 sends the SW-COMP, 454 it becomes the active home agent. HA1 becomes standby when it 455 receives SW-COMP. 457 After the down time, HA1 sends a SwitchOver Request (SWO-REQ) to HA2 458 in order to become the active home agent again (5). HA2 acknowledge 459 it by sending a SwitchOver Reply (SWO-REP) to HA1 (6). HA1 now 460 starts home agent fail-over operation. After the completion of fail- 461 over, HA1 sends a SW-COMP to HA2 (7). Then, HA1 returns to the 462 active home agent and HA2 fall back to a standby home agent (8). 464 3. Home Agent Configuration 466 3.1. Network Configuration 468 HARP supports two different configurations for standby home agents. 469 Standby home agents can be placed on the same home link or on a 470 different link. Figure 4 depicts the configuration where home agents 471 serving the same home network are located on the same link as defined 472 in [RFC-3775]. 474 HA1 HA2 HA3 HA4 .... HAn 475 | | | | | 476 --------+------+------+------+--------+--------- 477 Home Link 479 Figure 4: Local Recovery Configuration 481 Figure 5 illustrates when standby home agents are located on a 482 different link (illustrated as Recovery Link in Figure 5). Most 483 large operators have a very stringent requirement on network 484 availability even in the worst type of disaster or outage. This 485 configuration can achieve home agent recovery even if the entire home 486 link fails. This is called geographic redundancy and a well-known 487 configuration for Telecommunications operators. In Figure 5, home 488 agents (HA1-HA4) are placed in geographically separated regions 489 (region-1 and -2). If region-1 suffers a down time due to any 490 reason, all the sessions will be seamlessly taken over by the nodes 491 in region-2. Note that HA3 and HA4 cannot receive packets meant for 492 the home network until the route on the Routers is changed. The 493 routing must be also updated to direct the packets meant for the home 494 link to the recovery link. 496 ---------IGP------>|<---BGP--->|<-----IGP--------- 498 HA1 HA2 HA3 HA4 499 | | | | 500 --------+------+-----+ R---R---R +-----+------+------- 501 Home Link Routers Recovery Link 502 (region-1) (region-2) 504 Figure 5: Global Recovery Configuration 506 3.2. Home Agent Address Configuration 508 In HARP, each home agent obtains its individual IPv6 address from its 509 serving home prefix. In VHARP, all the home agents use a virtual 510 home agent address generated from the home prefix. 512 In addition, each home agent running VHARP need to obtain its 513 individual IPv6 address from its attached link. This IPv6 address is 514 used only for the VHARP operations between home agents and is not 515 revealed to mobile nodes for binding registration. 517 All the home agents MUST join the ALL_HA_MULTICAST_ADDR. In VHARP, 518 each home agent join the multicast group with its individual IPv6 519 address, but not with virtual home agent address. This multicast 520 address can be used to exchange the HA-HELLO message among the home 521 agents. On the other hand, if a home recovery link is separately 522 defined, each home agent always unicasts the HARP messages to home 523 agents configured at a geographically separated link. 525 4. Home Agent Operations 527 4.1. Home Agent List Management 529 In Mobile IPv6, each home agent periodically sends router 530 advertisements with the Home Address Information option [RFC-3775]. 531 HARP introduces a HARP HA-HELLO message to replace the router 532 advertisement. There are several reasons to use HA-HELLO message 533 instead of the Router Advertisement such as: 535 o A HA-HELLO message can be sent beyond the link, while a router 536 advertisement cannot be sent beyond the link. In case of 537 geographic redundancy, router advertisements cannot be sent to the 538 recovery link unless the home link and the recovery link are 539 virtually connected by L2TP, etc. 541 o A HA-HELLO message is defined to manage additional information 542 such as Group ID and Active/Standby Status of the home agents in 543 the home agent list. 545 o A HA-HELLO message is exchange only between home agents, while a 546 router advertisement is also processed by mobile nodes attached to 547 a home link. A HA-HELLO does not introduce any burden to the 548 mobile nodes even if it is frequently sent on the home link. 550 When a HA-HELLO is used to exchange the home agent information, each 551 home agent SHOULD NOT process the Home Agent Information option 552 carried by a Router Advertisement. A router advertisement is only 553 processed by mobile nodes. Operators may define different 554 configuration values to the parameters of the home agent information 555 for a HA-HELLO and a Router Advertisement. 557 This document requires additional information to the home agent list 558 defined in [RFC-3775]. The additional information is learned through 559 HA-HELLO message exchange. 561 o Group ID of a redundant home agent set. It is learned through the 562 Group ID field of the HA-HELLO. 564 o HA-HELLO Interval. This value is locally configured at every home 565 agent by operators and is learned through the Hello Interval field 566 of the HA-HELLO. 568 o An individual home agent address used in the VHARP operation. 569 This information is only required when VHARP is used in addition 570 to the virtual home agent address. It is learned through the 571 Source Address of the HA-HELLO message. 573 o VHARP capability. This information is learned through the V flag 574 of the HA-HELLO message. 576 o Current mode (HARP or VHARP). This information is learned through 577 the M flag of the HA-HELLO message. 579 o Active status. This information is learned through the A flag of 580 the HA-HELLO message. 582 4.2. Detecting Home Agent Failure 584 An active and standby home agents can monitor each other in several 585 ways. One method is to reuse other failure detection mechanisms 586 defined in VRRP[RFC-3768, RFC-5798] and HSRP [RFC-2281]. However, 587 VRRP and HSRP are not sufficient since they cannot detect the case 588 where the system is running but the Mobile IPv6 stack is not 589 operational. Failure events used in HARP/VHARP are listed below. 591 Loss of HA-HELLO 593 HARP/VHARP is an extension to Mobile IPv6 and can monitor 594 availability of Mobile IPv6 stack on each home agent by 595 periodically sending a HA-HELLO as a heart-beat. This HA-HELLO 596 can also be exchanged frequently enough to detect the failure 597 promptly without any additional overhead to mobile nodes attached 598 to the home link. In the event that a standby home agent does not 599 receive any HA-HELLOs from its peer for a configurable duration, 600 the standby home agent assumes that home agent's failure. The 601 detail of the Hello message is described in Section 4.3.2. 603 Monitored Server Failure by the Active Home Agent 605 There may be number of critical servers such as an AAA server in 606 the network that are essential for the ongoing Mobile IPv6 607 sessions at the home agent. Operators can have a policy in place 608 that the active home agent is treated as a failed home agent upon 609 detecting that the link to such servers has failed. 611 Routing Peer/Link Failure 613 Operators may require the home agent to detect its next-hop 614 routing peer failure. If the next-hop routing failure is fatal in 615 nature, or due to some other routing policies, the active home 616 agent is treated as a failed home gent and the recovering 617 operation should be started. 619 4.3. Processing the HARP Messages 621 4.3.1. IP field and Security Descriptions of HARP message 623 The HARP message format is defined in Section 6.1.1. If a HARP 624 message is unicasted, the destination address is one of Home Agent in 625 the same Redundant Home Agent set. If it is HA-HELLO message (by 626 setting the type field to 4), it can be multicasted. The destination 627 address MUST be set to ALL_HA_MULTICAST_ADDR. The source address 628 MUST be set to the sender's home agent address. Note that, in VHARP, 629 the virtual home agent address SHOULD NOT be set to source and 630 destination address. The IP address of the interface the packet is 631 being sent from SHOULD be used. 633 If a HARP message is unicasted, it SHOULD be authenticated by IPsec 634 AH and MAY be encrypted by IPsec ESP. If a HA-HELLO message is 635 multicasted, multicast extensions to IPsec [RFC-5374] SHOULD be 636 applied. If all the home agents are placed in a secure transport 637 network to exchange a HARP message, authentication and encryption MAY 638 be omitted. Which security verification is used depends on 639 operational policy. If security verification is failed for a 640 receiving HA-HELLO, the HA-HELLO MUST be discarded. 642 The following operations MUST be performed when transmitting a HARP 643 message. 645 o The incremented latest Sequence Number MUST be set to the Sequence 646 Number field. The Sequence Number SHOULD be initialized to zero 647 for the first Hello message. To accomplish sequence number 648 rollover, if the sequence number has already been assigned to be 649 the largest possible number representable as a 16-bit unsigned 650 integer, then when it is incremented it will then have a value of 651 zero (0). 653 o The sender's Group ID MUST be set to the Group ID field. 655 o The V-flag MUST be set if the sender is capable of VHARP. 657 o The M-flag MUST be unset if the sender is operated with HARP. 659 o The M-flag MUST be set if the sender is operated with VHARP. 661 o The A-flag MUST be set if the sender is the active home agent. 663 Performed the following functions when a HARP message is received. 665 o MUST verify the Group ID of the HARP message is equal to the 666 receiver's Group ID. 668 o MUST verify the sender of the HARP message belongs to the 669 receiver's same redundant home agent set 671 o MUST verify that the M flag is equal to the receiver's operating 672 mode. 674 o MUST verify the Sequence Number value in the HARP is larger than 675 the last received Sequence Number value. When the sequence number 676 rollover is occurred, the sequence number value in the HA-HELLO is 677 zero. 679 If any one of the above checks fails, the receiver SHOULD discard the 680 HARP message. 682 4.3.2. Processing Home Agent Hello (HA-HELLO) 684 4.3.2.1. Sending HA-Hello Message 686 Each home agent MUST send a HA-HELLO in following case: 688 o UNSOLICITED: Each home agent SHOULD periodically send a HA-HELLO. 689 The interval time is configured locally at each home agent. 691 o UNSOLICITED: When a home agent detects its local information 692 change, it should immediately send a HA-HELLO. 694 o SOLICITED: when a home agent receives a HA-HELLO with the R-flag 695 set. When the R-flag is set, the HA-HELLO can be requested to the 696 destination home agent. 698 A home agent can solicit a HA-HELLO to a particular home agent(s) in 699 the same redundant home agent set by unicasting or multicasting a HA- 700 HELLO with the R-flag set. Soliciting HA-HELLO is operated when: 702 o A new home agent boots up. The new home agent SHOULD solicit HA- 703 Hello messages by multicasting a HA-Hello message with the R-flag 704 set. 706 o A HA-HELLO has not been received after the specified hello 707 interval. The HA-HELLO MAY be solicited to the home agent. 709 o A home agent entry in the redundant home agent set is about to be 710 removed due to home agent lifetime expiration. The HA-HELLO 711 SHOULD be solicited to the home agent whose lifetime is soon 712 expired. 714 In addition to Section 4.3.1, the following operations MUST be 715 performed when transmitting a HA-HELLO. 717 o The Type field MUST be set to 4. 719 o The R-flag MUST be set if the sender solicits a HA-HELLO to the 720 other home agent(s). 722 o The appropriate home agent configuration values MUST be copied to 723 the Home Agent Preference, the Home Agent Lifetime, and Hello 724 Interval fields. 726 4.3.2.2. Receiving Hello Message 728 The receiver MUST perform the verification to the HA-HELLO described 729 in Section 4.3.1. After the verification, the receiver copies the 730 value stored in the HA-HELLO message to the corresponding home agent 731 list entry according to Section 4.1. 733 If the home agent lifetime field in the HA-HELLO is set to 0, the 734 receiver MUST remove the sender home agent from the home agents list. 736 If the R-flag is set in the received HA-HELLO, the receiver MUST send 737 a new HA-HELLO to the originator as described in Section 4.3.2.1. 739 4.3.3. Processing Home Agent Switch Over (SWO-REQ/REP) 741 When a standby home agent decides to become an active home agent, the 742 standby home agent sends a SwitchOver Request (SWO-REQ) to the 743 current active home agent with the following operations. 745 o MUST be unicasted only to the current active home agent 747 o MUST be sent from a standby home agent. The active home Agent 748 MUST NOT generate this message. 750 When an active home agent receives a SWO-REQ, it MUST operate the 751 following verification and operations in addition to Section 4.3.1: 753 o If the receiver of the SWO-REQ is not an active home agent, it 754 MUST send a SWO-REP with the Status field set to 130 (Not active 755 home agent). 757 o If the sender home agent does not belong to the same redundant 758 home agent set, a SWO-REP message MUST be sent to the sender with 759 the Status field set to 132 (Not in same redundant home agent 760 set). 762 o There is a case where the active home agent cannot be standby home 763 agent. The active home agent MUST reply a SWO-REP with the Status 764 field set to 129 (Administratively prohibited). 766 o Otherwise, the active home agent MUST become a standby home agent 767 and reply with a SWO-REP message with the Status field set to 0 768 (Success). 770 When a standby home agent receives a SWO-REP, it MUST operate the 771 following verification and operations in addition to Section 4.3.1: 773 o If the receiver is an active home agent, the SWO-REP MUST be 774 discarded. 776 o If the standby home agent receives an unexpected SWO-REP which is 777 not in reply to its SWO-REQ, it MUST ignore the SWO-REP. 779 o Otherwise, if the Status field of the SWO-REP is 0 (Success), the 780 standby home agent (the receiver of SWO-REP) immediately becomes 781 an active home agent. 783 o If the value in the Status field is greater than 128 an error has 784 occurred. In this case, the receiver MUST NOT attempt to be an 785 active home agent. 787 4.3.4. Processing Home Agent Switch Back (SWB-REQ/REP) 789 When an active home agent decides to become a standby home agent, it 790 sends a SWB-REQ to one of standby home agents. The reason for the 791 active home agent to send this message can be administrative 792 intervention, and events like Monitored Server Failure by the active 793 home agent or Routing Peer/Link Failure. The following operations 794 MUST be performed when SWB-REQ is sent. 796 o MUST be unicasted only to one of standby home agents in the same 797 redundant home agent set 799 o MUST be sent from an active home agent. The standby home Agent 800 MUST NOT generate this message. 802 When a home agent receives a SWB-REQ message, it verifies the message 803 as follows. 805 o If the sender home agent of the SWB-REQ is not an active home 806 agent, the receiver MUST reply a SWB-REP with the Status field is 807 set to 130 (Not active home agent). 809 o If the sending home agent does not belong to the same redundant 810 home agent set, a SWB-REP MUST be sent in which the Status field 811 set to 132 (Not in same redundant home agent set). 813 o Otherwise, the receiving home agent MUST send a SWB-REP with the 814 Status field is set to 0 (Success). 816 o After sending the SWB-REP, the standby home agent MUST NOT become 817 an active home agent immediately. This is because the active home 818 agent is still active until it receives the SWB-REP which is 819 acknowledging the SWB-REQ. The standby home agent SHOULD change 820 to active at least after LINK_TRAVERSAL_TIME. 822 When a home agent receives a SWB-REP message, it verifies the message 823 as follows. 825 o If the standby home agent receives an unexpected SWB-REP which is 826 not in reply to own SWB-REQ, it SHOULD ignore the SWO-REP. 828 o If the Status field of the SWB-REP is 0 (Success), the active home 829 agent immediately becomes a standby home agent. The sender home 830 agent of SWB-REP becomes an active home agent after certain time, 831 LINK_TRAVERSAL_TIME. 833 o If the value in the Status field is greater than 128, the receiver 834 of SWB-REP (active home agent) cannot become a standby home agent 835 and MUST continue to be an active home agent. 837 4.4. State Synchronization 839 A State Synchronization (SS) message format is defined in 840 Section 6.1.2. It can carry several state information about a mobile 841 node by setting mobility options in the Mobility Options field. The 842 following list shows examples of the mobility options which can be 843 specified in the state synchronization message. 845 o IPv6 Home Address (Binding Cache Option) 847 o Binding Cache Information (Binding Cache Option) 849 o NEMO Mobile Network Prefix (Mobile Network Prefix Option [RFC- 850 3963]) 852 o IPv4 Care-of Address (IPv4 Care-of Address Option [RFC-5555]) 854 o IPv4 Home Address (IPv4 Home Address Option [RFC-5555]) 856 o Binding Identifier (Binding Identifier Option [RFC-5648] 858 o AAA states (AAA Information Option) 860 o Miscellaneous states (Vendor Specific Mobility Option [RFC-5094]) 862 When a home agent need to send the state of multiple mobile nodes in 863 a single state synchronization message (SS-REQ or SS-REP), a Binding 864 Cache Information option is used as a separator. For each mobile 865 node, a Binding Cache Information option is placed first, followed by 866 any other options related to the mobile node if necessary. 868 In HARP, since a mobile node will re-register to the new active home 869 agent after home agent fail-over, it is not necessary for the standby 870 home agents to synchronize all the mobile nodes' state information. 871 The standby home agent only need to collect the home address 872 information of all the mobile nodes served by the active home agent. 873 The information is used to send the Home Agent Switch messages to all 874 the mobile node when the home agent failure is occurred. 876 In VHARP, home agent fail-over is completed without mobile nodes' 877 binding re-registration. Therefore, standby home agents need to copy 878 the complete state information of each mobile node registered with 879 the active home agent. 881 4.4.1. Binding Cache Information Management 883 In HARP, each standby home agent learns the partial binding cache 884 information such as a pair of a home address and a mobile node's 885 registering home agent address. This information is stored somewhere 886 in a standby home agent. 888 In VHARP, a standby home agent ideally copies the received binding 889 cache information and other mobile node's information into the 890 appropriate database so that it can act as an active home agent as 891 soon as it takes over the failed home agent. 893 4.4.2. IP field and Security Descriptions of SS message 895 A state synchronization message is only unicasted. The destination 896 address MUST be one of home agents in the same Redundant Home Agent 897 set. The source address MUST be set to the sender's home agent 898 address. Note that, in VHARP, the virtual home agent address MUST 899 NOT be set to the source address. IP address of the interface the 900 packet is being sent from SHOULD be used. 902 If a state synchronization message is unicasted, it SHOULD be 903 authenticated by IPsec AH and MAY be encrypted by IPsec ESP. If all 904 the home agents are placed in a secure transport network to exchange 905 the state synchronization message, authentication and encryption MAY 906 be omitted. If security verification is failed for a receiving state 907 synchronization message, the message MUST be discarded. Which 908 security mechanism is used depend on the operational policy. 910 4.4.3. Requesting State of Mobile Nodes (SS-REQ) 912 When a home agent needs the state information for a particular mobile 913 node or a subset of mobile nodes, it sends a SS-REQ message 914 constructed as follows: 916 o MUST set the Type field to 0 (Request). 918 o MUST set a random value in the Identifier field that does not 919 coincide with any other currently pending Requests. 921 o MUST include a Binding Cache Information option(s) which Home 922 Address field is set to the target home address. Other fields of 923 the Binding Cache Information option can be omitted. 925 o MUST set the unspecified address (::) in the Home Address field of 926 the Binding Cache Information option, if it solicits the state of 927 all the mobile nodes registering at the destination home agent of 928 the SS-REQ message. 930 o MUST include multiple binding cache information options in a SS- 931 REQ, if the sender requests multiple mobile nodes' information. 932 The sender SHOULD NOT send multiple SS-REQs per mobile node. 934 o MUST send a SS-REQ to the active home agent of the target mobile 935 node(s). 937 When a home agent receives a SS-REQ, it MUST perform the verification 938 described in Section 4.4.2 and following: 940 o If the receiver does not know the binding cache for the target 941 mobile node(s) specified in the received Binding Cache Information 942 option(s), it MUST ignore the SS-REQ and MUST NOT reply a SS-REQ. 944 o Otherwise, the receiver MUST reply a SS-REP including all the 945 state information of the target mobile node(s). 947 4.4.4. Sending State Information (SS-REP) 949 A SS-REP message(s) SHOULD be sent when: 951 1. The active home agent receives a SS-REQ. 953 2. The active home agent creates or deletes a binding cache entry 954 for a particular mobile node. 956 The active home agent MAY additionally send a SS-REP message in 957 following cases: 959 1. The active home agent updates the state information for all 960 sessions that changed since the last update in a periodic 961 interval 963 2. Often in VHARP, the active home agent MAY update a binding cache 964 entry for a particular mobile node whenever the binding cache 965 entry is updated. If an active home agent sends a SS-REP message 966 whenever the local state information changes, such as a binding 967 cache change, the number of the SS-REP messages can be quite 968 large. 970 Following rules must be applied when the active home agent constructs 971 a SS-REP. 973 o MUST copy the Identifier field of the SS-REQ to the same field of 974 the SS-REP, if the SS-REP is sent in response to the SS-REQ. 976 o MUST set zero to the Identifier field if the SS-REP is sent 977 without solicitation (no SS-REQ). 979 o MUST include required mobility options in the SS-REP. 981 * In HARP, a partial Binding Cache Information Option (the Home 982 Address Field only) MUST be included in the SS-REP. 984 * In VHARP, a full Binding Cache Information Option and other 985 required options shown in Section 6.1.2 MUST be included in the 986 SS-REP. 988 o MUST include the state of all the active mobile nodes registering 989 in the active home agent by the SS-REP when the unspecified 990 address is found in the Home Address mobility option carried with 991 the SS-REQ. The message may be fragmented depending on the total 992 size needed to carry all states. 994 4.4.5. Synchronizing State (SS-REP and SS-ACK) 996 When a home agent receives a SS-REP, it MUST take the following 997 operations. 999 o If no options are carried in the SS-REP, the home agent MUST 1000 ignore the SS-REP and MUST send SS-ACK with the Status 1001 Synchronization Status option which status value is set to [131: 1002 No Mobility Option] 1004 o If the sender of SS-REP is not in the same global home agent set, 1005 the home agent MUST reject the SS-REP and MUST send SS-ACK with 1006 the Status Synchronization Status option which status value is set 1007 to [130: Not in same global home agent set] 1009 o The receiver home agent MUST record the IPv6 address of the sender 1010 as the active home agent of the mobile node in its local binding 1011 cache. 1013 o The receiver home agent MUST update its binding cache and all 1014 other necessary information in a particular database(s). 1016 o The receiver home agent MUST send a SS-ACK with state 1017 synchronization status mobility options if A flag is set. 1019 If an active home agent requires an acknowledgment of a SS-REP, it 1020 MUST set the Ack flag in the SS-REP. The receiver of such SS-REP 1021 will send back a SS-ACK. The receiver MUST copy the Identifier value 1022 received in the SS-REP into SS-ACK in order to match the SS-REP and 1023 SS-ACK. 1025 4.5. Switching the Active Home Agent 1027 In HARP, the standby home agent which is going to be active MUST send 1028 a Home Agent Switch message [RFC-5142] to all the mobile nodes that 1029 were being served by the failed home agent. The following rules MUST 1030 be applied when transmitting a Home Agent Switch message. 1032 o MUST use IPsec ESP to the Home Agent Switch message. 1034 o MUST set only that standby home agent address in the Home Agent 1035 Switch message 1037 If there are a large number of mobile nodes served by the failed home 1038 agent, the overhead sending Home Agent Switch messages is high. This 1039 overhead cannot be avoided if the active home agent suddenly stop 1040 serving mobile node because of unexpected reasons (crash, network 1041 trouble, etc). However, if this switch over is operated under the 1042 administrative operation (maintenance, etc), the previous active home 1043 agent may continue serving the mobile nodes until the switch over is 1044 completed. Until the mobile node sends a binding update to the new 1045 active home agent, it still sends the packet to the previous home 1046 agent. 1048 Therefore, the new active home agent can notify the completion of 1049 switch-over to the previous active home agent by using a SW-COMP 1050 message. When the new active home agent completes the switch-over, 1051 it SHOULD send a SW-COMP to the previous active home agent. Until 1052 the previous home agent receives this message, it SHOULD continue 1053 serving any mobile nodes that are registered with it. Once the 1054 previous home agent receives the SW-COMP message, it can be shutdown 1055 or detached from the network safely. 1057 In VHARP, after detecting the active home agent has failed, the 1058 standby home agent whose preference value is the highest MUST take 1059 over the failed home agent. The standby home agent MUST activate the 1060 virtual home agent address. If a virtual MAC address as introduced 1061 in [RFC-3768, RFC-5798] is used, the standby home agent MUST start 1062 using that virtual MAC address as well. If VHARP run with VRRP and 1063 HSRP as described in Section 4.7, the virtual home agent address can 1064 be treated as a virtual router address in VRRP and HSRP. Therefore, 1065 VRRP and HSRP can automatically activate the virtual home agent 1066 address on the standby home agent after their election mechanism. 1067 Since all the necessary state has already been transferred to this 1068 standby home agent before the active home agent failed, it can 1069 immediately start acting as the active home agent. 1071 When the failed home agent recovers from failure and would return to 1072 the active home agent, it MUST re-establish IPsec SA with all the 1073 mobile nodes. All the mobile nodes lost IPsec SA with the home agent 1074 when the failure is occurred. Otherwise, it cannot be either a 1075 standby or active home agent for the mobile nodes. Therefore, as 1076 soon as the active home agent detects the recovery of the failed home 1077 agent, it sends a Home Agent Rekey message to all the mobile nodes 1078 served by other home agents in the same redundant home agent set, and 1079 includes the recovered home agent address in the Home Agent Addresses 1080 field. The detail of the Home Agent Rekey message is described in 1081 Section 6.1.3. The mobile node will re-key the SA by using The IKEv2 1082 resumption mechanism [RFC-5723]. Alternatively, the mobile node MAY 1083 start a new IKE session with the recovered home agent. 1085 4.6. Consideration of Routing and Neighbor Discovery Protocol (VHARP) 1087 This section gives a brief explanation of how a home agent interacts 1088 with routing and Neighbor Discovery Protocol (NDP) when is VHARP 1089 used. 1091 When a standby home agent becomes active in VHARP, it MUST start to 1092 advertise the home agent address and the home prefix of the home 1093 addresses serviced by the redundant home agent set into the routing 1094 infrastructure. This operation is normally done using a route 1095 selector such as BGP or an OSPF modifier. For example, we can use 1096 the AS_Path prepend operation for BGP, and the Metric field in OSPF 1097 for the route selection. When each home agent participates in OSPF 1098 routing, each home agent should be configured with the appropriate 1099 metric matched to the home agent preference value. When the active 1100 home agent fails, OSPF detects the failure and can dynamically switch 1101 the route to the standby home Agent based on the OSPF cost value. If 1102 this creates conflicts with the home agent preference value due to 1103 configuration errors, the routers on the home link may not route 1104 packets to the desired standby home agent. In order to change the 1105 OSPF cost correctly and dynamically, The operator takes other 1106 existing approaches. For example, most of router vendors have a 1107 private MIB to set the cost via SNMP, though this is a vendor- 1108 specific function. 1110 When an active home agent activates a home agent address, it SHOULD 1111 use a virtual MAC address as introduced in [RFC-3768, RFC-5798]. 1112 When the active home agent is changed, the neighbor cache of the 1113 active home agent is not necessarily updated on mobile nodes located 1114 on the home link. Otherwise, the new home agent MUST update the 1115 neighbor cache entry for the home agent address on all the mobile 1116 nodes located on the home link. In addition, Mobile IPv6 uses proxy 1117 NDP to intercept packets meant for mobile nodes which are away from 1118 the home link. However, it is unnecessary for the new active home 1119 agent to overwrite the existing proxy neighbor entries of the mobile 1120 nodes. 1122 4.7. Interworking with VRRP 1124 VRRP and HSRP specify an election protocol that dynamically assigns 1125 responsibility for a virtual router to one of the VRRP routers on a 1126 LAN. This operation is similar to the VHARP. For example, the VRRP 1127 router controlling the IP address(es) associated with a virtual 1128 router is called the Master, and forwards packets sent to these IP 1129 addresses. The election process provides dynamic fail over in the 1130 forwarding responsibility should the Master become unavailable. 1131 Although VRRP is used to guarantee home agent address reachability, 1132 it cannot be used for state synchronization and explicit switching of 1133 Master and Backup. Thus, the Home Agent Reliability protocol cannot 1134 be replaced by VRRP. This section explains how VRRP can interwork 1135 with HARP/VHARP. 1137 When VRRP is available, VRRP can replace the Hello message described 1138 in Section 6.1.1. However, some of information is missed by using 1139 VRRP. After receiving a VRRP message, each home agent SHOULD process 1140 the message and store the information as if it receives Home Agent 1141 Hello messages Section 4.3.2.2. The message format of VRRP can be 1142 found in Section 5.1 of [RFC-5798]. Each field is mapped as follows: 1144 o Virtual Rtr ID: Group ID is stored in the Virtual Rtr ID field. 1146 o Priority: Home Agent Preference is stored in the Priority field. 1147 Note that VRRP only has 8 bits for the Priority field. Therefore, 1148 values larger than 255 MUST NOT be assigned to the preference 1149 value. 1151 o Count IPv6 IPv6 Addr: This field MUST be always be 1. 1153 o Max Advert Int: This field MUST be mapped to the Hello Interval 1154 field of the Home Agent Hello message, though it only has 12 1155 bytes. 1157 o IPv6 address: A home agent address is stored in this field. 1159 Home Agent Lifetime, Sequence Number and Flags field are missed in 1160 the VRRP packet format. Therefore, operators SHOULD use the same 1161 statically configured value for Home Agent Lifetime. Each home agent 1162 does not check freshness of received VRRP message because of no 1163 sequence number. 1165 4.8. Retransmissions and Rate Limiting 1167 Home agents are responsible for retransmissions and rate limiting of 1168 SS-REQ, SWO-REQ, SWB-REQ messages for which they expect a response. 1169 The home agent MUST determine a value for the initial transmission 1170 timer: 1172 o If the home agent sends a SS-REQ message, it SHOULD use an initial 1173 retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER. 1175 o If a home agent sends a SWO-REQ or SWB-REQ message, it SHOULD use 1176 an initial retransmission interval of INITIAL_SWITCH_REQ_TIMER. 1178 If the sending home agent fails to receive a valid matching response 1179 within the selected initial retransmission interval, it SHOULD 1180 retransmit the message until a response is received. All of the 1181 above constants are specified in Section 8. 1183 The retransmission MUST use an exponential backoff process as 1184 described in [RFC-3775] until either the home agent receives a 1185 response, or the timeout period reaches the value 1186 MAC_HARELIABILITY_TIMEOUT. The home agent SHOULD use a separate 1187 back-off process for different message types and different 1188 destinations. The rate limiting of Mobility Header messages is the 1189 same as one in [RFC-3775]. A home agent MUST NOT send Mobility 1190 Header Messages to a particular home agent more than MAX_UPDATE_RATE 1191 (3) times a second, which is specified in [RFC-3775]. 1193 5. Mobile Node Operation 1195 This section describes the operations of a mobile node only when HARP 1196 is used. Non of operations in this section is required in VHARP. 1198 5.1. Home Agent Addresses Discovery 1200 A mobile node authenticates itself to two or more home agents and 1201 creates IPsec SAs with them during bootstrapping. When the active 1202 home agent fails, another home agent can use the pre-existing SA to 1203 notify the mobile node about the failure by sending a Home Agent 1204 Switch message. 1206 In order to discover multiple home agent addresses, two different 1207 mechanisms are defined in the bootstrapping solution in the split 1208 scenario [RFC-5026]. One is DNS lookup by home agent Name, the other 1209 is DNS lookup by Service Name. DHCPv6 can also be used in the 1210 integrated scenario [ID-BOOTINT] to provide home agent provisioning 1211 to mobile nodes. 1213 In the split scenario, a mobile node can use DNS lookup by Service 1214 Name to discover the home agents, as defined in [RFC-5026]. For 1215 example, if home agent reliability is required by a mobile node, DNS 1216 lookup by Service Name method is recommended for the mobile node to 1217 discover multiple home agents addresses. Therefore, mobile nodes 1218 will query the DNS SRV records with a service name of mip6 and 1219 protocol name of ipv6. The DNS SRV records includes multiple home 1220 agent addresses and different preference values and weights. The 1221 mobile node SHOULD choose two or more home agents from the home 1222 agents list according to their preference value. Then the mobile 1223 node should authenticate itself to these home agents via an IKEv2 1224 exchange. 1226 In the integrated scenario, a mobile node can use DHCPv6 to get home 1227 agent provisioning from an MSP or ASP, as already defined in [ID- 1228 BOOTINT]. The only requirement is that the DHCPv6 response must 1229 include multiple home agents' information in order to support home 1230 agent reliability. 1232 5.2. IPsec/IKE Establishment to Home Agents 1234 In this document, a mobile node need to manage an IPsec SA with a 1235 home agent(s). The following mechanism can be used to manage the 1236 IPsec SA(s) with a home agent(s). 1238 o IKEv1/v2 running per home agent (HARP) to establish multiple IPsec 1239 SAs for home agents. 1241 o The IKEv2 resumption mechanism [RFC-5723] to update an IPsec SA 1242 with the new home agent (VHARP) 1244 If IPsec/IKEv2 state synchronization mechanism is available in 1245 Virtual Private Network (VPN) products, none of above is required for 1246 the VHARP operation. The IPsec SAs per mobile node are seamlessly 1247 copied among multiple home agents. 1249 The mobile node MUST follow the standard IKEv2 exchange in the 1250 bootstrapping solution of the split scenario [RFC-5026]. If multiple 1251 IKEv2 are run per home agent, the mobile node MUST NOT attempt the 1252 home address assignment to standby home agents. 1254 5.3. Synchronizing State: K-bit treatment 1256 When a mobile node moves and the care-of address changes, it can use 1257 the Key Management Mobility Capability (K) bit in the Binding Update 1258 in order to update the peer endpoint of the key management protocol 1259 (ex. IKE Security Association). 1261 If an active home agent receives a Binding Update which K-bit is set, 1262 it MUST proceed the Binding Update as [RFC-3775]. In addition, the 1263 active home agent MUST notify the care-of address change to the other 1264 standby home agents. For doing so, it MUST send State 1265 Synchronization Reply message including Binding Cache Information 1266 option to all the other standby home agents. The flags of the 1267 Binding Update (ex. K-bit) MUST be copied to the flags field of the 1268 Binding Cache Information option. After all, the standby home agents 1269 know the existence of K-bit set in the Flag field of the Binding 1270 Cache Information option and update the peer endpoint of the key 1271 management protocol. 1273 If the K-bit is not set in the Binding Update, an active home agent 1274 needs to rerun the key management protocol. The active home agent 1275 MUST send State Synchronization Reply message including Binding Cache 1276 Information option to all the other standby home agents. K-bit is 1277 unset in the flags field of the Binding Cache Information option. 1278 The receivers of the State Synchronization Reply message (i.e. 1279 standby home agents) detect the care-of address change and rerun the 1280 key management protocol. 1282 5.4. Receiving Home Agent Switch message 1284 A mobile node must follow the verification and operations specified 1285 in [RFC-5142] when it receives a Home Agent Switch message. 1287 The Home Agent Switch message MUST be securely exchanged between a 1288 mobile node and a home agent by IPsec ESP. 1290 When the mobile node receives a Home Agent Switch message, and if the 1291 message contains the IPv6 address of a standby home agent, it MUST 1292 select the standby home agent as its active home agent and MUST send 1293 a new Binding Update message to it. 1295 The standby home agent address in the Home Agent Switch message MUST 1296 be equal to the sender of the Home Agent Switch message. If the IPv6 1297 address stored in the Home agent address field is different from the 1298 sender's source IPv6 address, the mobile node MUST send a binding 1299 update to the sender and MUST NOT use the IPv6 address in the Home 1300 Agent Switch message. 1302 6. Messages Format 1304 6.1. New Mobility Header Messages 1306 6.1.1. HARP Message Format 1308 The HARP message has the type field to identify different roles. The 1309 HARP message has the MH Type value TBD. 1311 0 1 2 3 1312 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 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Type | Group ID | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Sequence # |A|R|V|M|Rsvd | Status | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Home Agent Preference | Home Agent Lifetime | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Hello Interval | | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1322 | | 1323 . Mobility Options . 1324 . . 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 Figure 6: Home Agent Hello Message 1329 Type 1331 8-bit unsigned integer. It can be assigned one of the following 1332 values: 1334 0: SwitchOver Request (SWO-REQ) 1336 It is unicasted by a standby home agent that desires to become 1337 the active home agent. The receiver of the message MUST 1338 transition to standby state as soon as the message is received 1339 and validated successfully. 1341 1: SwitchOver Reply (SWO-REP) 1342 It is used to acknowledge the receipt of the corresponding SWO- 1343 REQ. 1345 2: SwitchBack Request (SWB-REQ) 1347 It is unicasted by an active home agent that desires to become 1348 a standby home agent. The receiver of this message SHOULD 1349 transition to active state as soon as the message is received 1350 and validated successfully. 1352 3: SwitchBack Reply (SWB-REP) 1354 It is used to acknowledge the receipt of the corresponding SWB- 1355 REQ. 1357 4: Switch Complete (SW-COMP) 1359 This message is used to indicate the completion of switch over, 1360 (i.e. sending home agent switch messages and receiving binding 1361 update messages from all the served mobile nodes). 1363 4: Home Agent HELLO (HA-HELLO) 1365 It MUST be either unicasted or multicasted to carry home agent 1366 information among the redundant home agent set. The HA-Hello 1367 message is defined for two purpose: 1) an alive check and 2) 1368 home agent information exchange. 1370 Group Identifier 1372 8-bit unsigned integer. This value is used to identify a 1373 particular redundant home agent set. 1375 Sequence # 1377 16-bit unsigned integer. The Sequence number of the HA-Hello 1378 message can be used to verify whether this Hello message is the 1379 latest one or not. 1381 (A)ctive flag 1383 Active Home Agent flag. If this flag is set, the sender of this 1384 HA-Hello message is an active home agent. 1386 (R)equest flag 1387 HA-HELLO requesting flag. If this flag is set, the receiver of 1388 this HA-Hello message must send back a HA-Hello message to the 1389 sender. 1391 (V)HARP capability flag 1393 VHARP capability Flag. If a home agent is capable of IPsec/IKE 1394 state synchronization, it MUST set this flag. 1396 (M)ode flag 1398 A home agent MUST set this flag only when VHARP is used in the 1399 current operation. If the flag is unset, the home agent currently 1400 operates HARP. (HARP:0, VHARP:1) 1402 Reserved 1404 This field is unused. It MUST be initialized to zero by the 1405 sender and MUST be ignored by the receiver. 1407 Status 1409 8-bit unsigned integer indicating the disposition of a SWO-REQ or 1410 SWB-REQ. This field is only valid in SWO-REP and SWB-REP. The 1411 following Status values are defined: 1413 0: Success 1415 128: Reason unspecified 1417 129: Administratively prohibited 1419 130: Not active home agent (The receiver of SWO-REQ is not the 1420 active home agent) 1422 131: Not standby home agent (The receiver of SWB-REQ is already 1423 the active home agent) 1425 132: Not in same redundant home agent set 1427 Home Agent Preference 1429 16-bit unsigned integer. The preference for the home agent 1430 sending the HA-Hello message. This preference is the same as the 1431 Home Agent Preference value of the Home Agent Information option 1432 as defined in [RFC-3775]. However, operators MAY use a different 1433 preference value for this operation. 1435 Home Agent Lifetime 1437 16-bit unsigned integer. The lifetime for the home agent sending 1438 the HA-Hello message. This lifetime is the same as the Home Agent 1439 Lifetime value of the Home Agent Information option as defined in 1440 [RFC-3775]. 1442 Hello Interval 1444 16-bit unsigned integer. The interval for the home agent sending 1445 this Hello message. 1447 Mobility Options 1449 No valid options are defined in this specification. 1451 6.1.2. State Synchronization Message Format 1453 This message is used to exchange state corresponding to a particular 1454 mobile node(s). It MUST be unicasted and MUST be authenticated by 1455 IPsec ESP. This message has the MH Type value TBD. 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Type |A| Reserved | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Identifier | | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1464 . . 1465 . Mobility Options . 1466 . . 1467 . | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 Figure 7: State Synchronization Message 1472 Type 1474 8-bit unsigned integer. It can be assigned one of the following 1475 values: 1477 0: State Synchronization Request (SS-REQ) 1478 It is used to solicit the active state corresponding to a 1479 particular mobile node. 1481 1: State Synchronization Reply (SS-REP) 1483 It is used between the home agents in the redundant home agent 1484 set to exchange binding cache information and any other 1485 information related to providing mobility service to the mobile 1486 nodes either periodically or in response to a SS-REQ. 1488 2: State Synchronization Reply-Ack (SS-ACK) 1490 This message is optional and is specially used when the links 1491 between home agents are not reliable. 1493 (A)ck flag 1495 This flag is valid only for SS-REP. If the sender requires 1496 explicit acknowledgment by SS-ACK, it MUST set this flag. 1498 Reserved 1500 This field is unused. It MUST be initialized to zero by the 1501 sender and MUST be ignored by the receiver. 1503 Identifier 1505 A 16-bit identifier to aid in matching state synchronization 1506 message. The identifier should never be set to 0. It should 1507 always be more than 1. 1509 Mobility Options 1511 Variable-length field of such length that the complete Mobility 1512 Header is an integer multiple of 8 octets long. This field 1513 contains zero or more TLV-encoded mobility options. The encoding 1514 and format of defined options are described in [RFC-3775]. The 1515 receiver MUST ignore and skip any options which it does not 1516 understand. This message requires at least one mobility option, 1517 therefore, there is no default length for this message. 1519 Binding Cache Information Option is mandatory in SS-REQ message. 1520 Multiple options can be stored in the same SS-REQ message. A home 1521 agent includes the mobile node's home address in the Binding Cache 1522 Information Option. If a home agent wants to solicit all the 1523 active mobile nodes' states, it can include the unspecified 1524 address (::) in an IPv6 address option. 1526 Binding Cache Information Option is mandatory in SS-REP. SS-REP 1527 can carry any of mobility options. The following options are just 1528 examples. 1530 * AAA Information Option 1532 * Vendor Specific Mobility Option [RFC-5094] 1534 * Mobile Network Prefix Option [RFC-3963] 1536 * IPv4 Care-of Address Option [RFC-5555] 1538 * IPv4 Home Address Option [RFC-5555] 1540 * Binding Identifier Option [RFC-5648] 1542 6.1.3. Home Agent Rekey Message 1544 This message is used to indicate that the mobile node SHOULD start an 1545 IPsec re-key with the home agent specified in the Home Agent 1546 Addresses field. This message is used when a failed home agent 1547 recovers and needs to re-establish IPsec SA/IKE state with a mobile 1548 node. This message MUST be unicasted to a mobile node by the active 1549 home agent and MUST be authenticated and encrypted by IPsec ESP. The 1550 Home Agent Rekey message has the MH Type value TBD. If no options 1551 are present in this message, no padding is necessary and the Header 1552 Len field will be set to 2. 1554 0 1 2 3 1555 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 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Reserved | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | | 1560 + + 1561 . Home Agent Addresses . 1562 + + 1563 | | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 . Mobility options . 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 Figure 8: Home Agent Rekey Message 1570 Reserved 1572 The reserved field is 16 bits 1574 Home Agent Address 1576 The receiver of this message MUST rekey the security asscoation 1577 with the specified home agent. 1579 When a mobile node receives a Home Agent Rekey message, it MUST 1580 verify the message as following. 1582 o The message MUST be sent from the receiver's active home agent. 1583 Otherwise, the message MUST be discarded. 1585 o The message MUST be protected by IPsec. Otherwise, the message 1586 MUST be discarded. 1588 o The message SHOULD contain one of standby home agent's address. 1589 If the home agent address is not known from the bootstrapping 1590 described in Section 5.1, the mobile node MUST NOT start an IKE 1591 session with the unknown home agent. Instead, it SHOULD re-start 1592 home agent discovery again to update its home agent address 1593 information. 1595 If all the above verfications are satisified, the mobile node MUST 1596 re-key the SA with the home agent addresses stored in the Home Agent 1597 Addresses field. 1599 6.2. New Mobility Options 1601 6.2.1. Binding Cache Information Option 1603 The binding cache information option is used to carry binding cache 1604 information of each mobile node. It has two different lengths 1605 depending on the number of fields. Two lengths can be set, 16 and 1606 40. The alignment requirement is either 8n+6 or 8n+2. The Binding 1607 Cache Information option is only valid in a State Synchronization 1608 message. Its format is as follows: 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Type = TBD | Length | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | | 1616 + + 1617 | Home Address | 1618 + + 1619 | | 1620 + + 1621 | | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 : : 1624 + + 1625 : : 1626 + Care-of Address + 1627 : : 1628 + + 1629 : : 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 : Flags : Sequence Number : 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 : Lifetime : Reserved : 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 Figure 9: Binding Cache Information Option 1638 The fields of Home Address is always mandated in a Binding Cache 1639 Information option. The Care-of Address, Flags, Sequence Number, and 1640 Lifetime fields are presented only if these values are necessary (ex. 1641 VHARP). The corresponding value in the binding cache database of the 1642 active home agent is copied to each field. Note that the 16-bit 1643 Reserved field MUST be set to zero. 1645 6.2.2. State Synchronization Status Option 1647 Figure 10 is a new mobility option of State Synchronization message. 1648 In the global HAHA, SS-ACK is mandatory for receivers of SS-REP to 1649 notify the global binding registration status 1650 0 1 2 3 1651 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 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | Type = TBD | Length | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Status | Reserved | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | | 1658 + + 1659 | Home Address | 1660 + + 1661 | | 1662 + + 1663 | | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 Figure 10: State Synchronization Status Option 1668 Type 1670 8-bit Type value. The value is TBD. 1672 Length 1674 8-bit length value. 1676 Status 1678 8 bit Status value of global binding registration. 1680 * 0: Success 1682 * 128: Reason unspecified 1684 * 129: Malformed SS-REP 1686 * 130: Not in same global home agent set 1688 * 131: No Mobility Option 1690 Reserved 1692 24 bit Reserved fields 1694 Home Address 1696 Corresponding home address of the status code. 1698 6.2.3. AAA Information Option 1700 This option is used to carry the AAA state of the mobile node's 1701 Mobile IPv6 sessions. The AAA state information can be carried in 1702 RADIUS or Diameter AVP formats including the user and session info. 1703 This information option is only valid in a State Synchronization 1704 message. 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 | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 . . 1712 . AAA AVPs . 1713 . . 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 Figure 11: AAA Information Option 1718 Type 1720 8-bit Type value. The value is TBD. 1722 Length 1724 8-bit length value. 1726 AAA AVPs 1728 Series of TLV encoded AAA AVPs (including vendor specific AVPs) 1729 carrying AAA-related information for each Mobile IPv6 and IPsec/ 1730 IKE session. 1732 7. Security Considerations 1734 All the messages newly defined in this document SHOULD be 1735 authenticated by IPsec AH and MAY be encrypted by IPsec ESP. When a 1736 HA-HELLO message is multicasted, the multicast extensions to IPsec 1737 [RFC-5374] is used. In some operational scenarios, home agents are 1738 located in deeply core network and securely managed. If there is a 1739 secure transport network between home agents, some of security 1740 mechanism can be turned off depending on administrative policy. 1742 A home agent switch message is reused for signaling between a home 1743 agent and a mobile node in HARP. It is protected by IPsec ESP as 1744 defined in [RFC-5142]. 1746 When an active home agent fails, mobile nodes using that home agent 1747 need to change its home agent to one of standby home agents. The 1748 mobile node need to update or establish the IPsec SA with the new 1749 home agent as described in Section 5.2. Existing mechanisms 1750 [RFC5723] are applied to this operation. 1752 8. Protocol Constants 1754 INITIAL_STATE_SYNC_REQ_TIMER: 3sec 1756 INITIAL_SWICH_REQ_TIMER: 1sec 1758 LINK_TRAVERSAL_TIME 150msec 1760 MAC_HARELIABILITY_TIMEOUT 16sec 1762 ALL_HA_MULTICAST_ADDR: TBD 1764 9. IANA Considerations 1766 The following Extension Types MUST be assigned by IANA: 1768 o Home Agent Reliability Protocol (HARP) Message 1770 o State Synchronization (SS) Message 1772 o Binding Cache Information Option 1774 o AAA Information Option 1776 o A new link-local multicast address (ALL_HA_MULTICAST_ADDR) for all 1777 home agents will be assigned by the IANA. 1779 10. Additional Authors 1781 This document is a result of discussions in the Mobile IPv6 Home 1782 Agent Reliability Design Team. The members of the design team that 1783 are listed below are authors that have contributed to this document: 1785 Samita Chakrabarti 1787 samita.chakrabarti@azairenet.com 1789 Kuntal Chowdhury 1791 kchowdhury@starentnetworks.com 1793 Hui Deng 1795 denghui@chinamobile.com 1797 Vijay Devarapalli 1799 vijay.devarapalli@azairenet.com 1801 Sri Gundavelli 1803 sgundave@cisco.com 1805 Brian Haley 1807 brian.haley@hp.com 1809 Behcet Sarikaya 1811 bsarikaya@huawei.com 1813 Ryuji Wakikawa 1815 ryuji.wakikawa@gmail.com 1817 11. Acknowledgements 1819 This document includes a lot of text from [ID-LOCALHAHA] and [ID- 1820 HAHA]. Therefore the authors of these two documents are 1821 acknowledged. We would also like to thank the authors of the home 1822 agent reliability problem statement [ID-PS-HARELIABILITY] for 1823 describing the problem succinctly and Alice Qin for her work on the 1824 hello protocol. 1826 12. References 1827 12.1. Normative References 1829 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1830 Requirement Levels", BCP 14, RFC 2119, March 1997. 1832 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1833 IPv6", RFC 3775, June 2004. 1835 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1836 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1837 January 2005. 1839 [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split 1840 scenario", RFC 5026, October 2007. 1842 [RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC 1843 5094, October 2007. 1845 [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message", 1846 RFC-5142, November 2007. 1848 [RFC-5374] B. Weis, G. GrossD. Ignjatic, "Multicast Extensions to 1849 the Security Architecture for the Internet Protocol", RFC 5374, 1850 November 2008 1852 [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack 1853 Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. 1855 [RFC-5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1856 and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, 1857 October 2009. 1859 [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via 1860 DHCPv6 for the Integrated Scenario", 1861 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), 1862 April 2008. 1864 12.2. Informative References 1866 [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot 1867 Standby Router Protocol (HSRP)", RFC 2281, March 1998. 1869 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1870 RFC 3753, June 2004. 1872 [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1873 RFC 3768, April 2004. 1875 [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with 1876 IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 1878 [RFC-5723] Y. Sheffer, H. Tschofenig, "Internet Key Exchange Protocol 1879 Version 2 (IKEv2) Session Resumption", RFC 5273, January 2010. 1881 [RFC-5798] S. Nadas, "Virtual Router Redundancy Protocol Version 3 1882 for IPv4 and IPv6", RFC 5798 (soon?), December 2009. 1884 [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", 1885 draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. 1887 [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", 1888 draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. 1890 [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent 1891 Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), 1892 February 2004. 1894 Author's Address 1896 Ryuji Wakikawa 1897 TOYOTA InfoTechnology Center, U.S.A., Inc. 1898 465 Bernardo Avenue 1899 Mountain View, CA 94043 1900 USA 1902 Email: ryuji@us.toyota-itc.com