idnits 2.17.1 draft-ietf-mip6-hareliability-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1922. 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 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 14, 2008) is 5763 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3768 (Obsoleted by RFC 5798) -- Obsolete informational reference (is this intentional?): RFC 5268 (Obsoleted by RFC 5568) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT (MIP6) Working Group R. Wakikawa (Editor) 3 Internet-Draft Toyota ITC 4 Intended status: Standards Track July 14, 2008 5 Expires: January 15, 2009 7 Home Agent Reliability Protocol 8 draft-ietf-mip6-hareliability-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 15, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The home agent can be a single point of failure when Mobile IPv6 is 42 operated in a system. It is critical to provide home agent 43 reliability in the event of a home agent crashing or becoming 44 unavailable. This would allow another home agent to take over and 45 continue providing service to the mobile nodes. This document 46 describes the problem scope briefly and provides a mechanism of home 47 agent failure detection, home agent state transfer, and home agent 48 switching for home agent redundancy and reliability. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Problem Statement and Requirements . . . . . . . . . . . . . . 6 58 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 59 4.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 8 60 4.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 9 61 4.3. Home Agent Management . . . . . . . . . . . . . . . . . . 10 63 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1. New Mobility Header Messages . . . . . . . . . . . . . . . 11 65 5.1.1. State Synchronization Message . . . . . . . . . . . . 11 66 5.1.2. Home Agent Control Message . . . . . . . . . . . . . . 13 67 5.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 15 68 5.1.4. Home Agent Switch Message . . . . . . . . . . . . . . 16 69 5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 17 70 5.2.1. IP address Option . . . . . . . . . . . . . . . . . . 17 71 5.2.2. Binding Cache Information Option . . . . . . . . . . . 17 72 5.2.3. AAA Information Option . . . . . . . . . . . . . . . . 18 74 6. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 20 75 6.1. Network Configuration . . . . . . . . . . . . . . . . . . 20 76 6.2. Address Configuration for Virtual Switch . . . . . . . . . 21 77 6.3. Address Configuration for Hard Switch . . . . . . . . . . 21 79 7. Home Agent Common Operation . . . . . . . . . . . . . . . . . 22 80 7.1. Home Agent List Management . . . . . . . . . . . . . . . . 22 81 7.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 22 82 7.3. Processing Hello Messages . . . . . . . . . . . . . . . . 23 83 7.3.1. Requesting Hello Message . . . . . . . . . . . . . . . 24 84 7.3.2. Sending Hello Message . . . . . . . . . . . . . . . . 24 85 7.3.3. Receiving Hello Message . . . . . . . . . . . . . . . 25 87 7.4. Processing State Synchronization Messages . . . . . . . . 26 88 7.4.1. Requesting State of a Particular Mobile Node(s) . . . 26 89 7.4.2. Synchronizing State . . . . . . . . . . . . . . . . . 27 90 7.4.3. Reliable Transmission by Explicit Acknowledgement . . 28 91 7.5. Processing Home Agent Control Messages . . . . . . . . . . 29 92 7.5.1. Standby Home Agent becomes an Active Home Agent . . . 29 93 7.5.2. Active Home Agent becomes in-active . . . . . . . . . 30 94 7.6. Interworking with VRRP . . . . . . . . . . . . . . . . . . 31 95 7.7. Retransmissions and Rate Limiting . . . . . . . . . . . . 32 97 8. Home Agent Virtual Switch . . . . . . . . . . . . . . . . . . 34 98 8.1. Consideration of Routing and Neighbor Discovery 99 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 34 100 8.2. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 34 102 9. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35 103 9.1. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 35 104 9.2. Sending Home Agent Switch Messages . . . . . . . . . . . . 35 105 9.3. Notification of Home Agent Switch Completion . . . . . . . 36 106 9.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 36 107 9.4.1. Home Agent Addresses Discovery . . . . . . . . . . . . 36 108 9.4.2. IKE/IPsec pre-establishment to Home Agents . . . . . . 37 109 9.4.3. Receiving Home Agent Switch message . . . . . . . . . 37 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 113 11. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 41 115 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 117 13. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 43 119 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 121 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 122 15.1. Normative References . . . . . . . . . . . . . . . . . . . 44 123 15.2. Informative References . . . . . . . . . . . . . . . . . . 44 125 Appendix A. Change Log From Previous Versions . . . . . . . . . . 46 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 128 Intellectual Property and Copyright Statements . . . . . . . . . . 47 130 1. Introduction 132 In Mobile IPv6 [RFC-3775] and NEMO Basic Support [RFC-3963], if a 133 home agent loses the binding cache state, due to failure or some 134 other reason, it results in a loss of service for the mobile nodes. 135 It is beneficial to provide high availability and redundancy for a 136 home agent so that mobile nodes can avail of uninterrupted service 137 even when one home agent crashes or loses state. The Home Agent 138 Reliability protocol is designed to synchronize the Mobile IPv6 139 states between active and standby home agents as VRRP[RFC-3768] or 140 HSRP [RFC-2281]. A home agent maintains not only binding cache but 141 also IPsec and IKE related states per mobile node. Mobile IPv6 142 mandates IPsec encryption for signaling of home binding registration 143 (BU and BA) and return routability (HoTI and HoT) as described in 144 [RFC-3776]. However, IPsec states synchronization is out of scope in 145 this document. The scope of Home Agent Reliability protocol is 146 limited to the management of Mobile IPv6 related states. Thus, we 147 define two different approaches such as Home Agent Virtual Switch and 148 Home Agent Hard Switch depending on the capability of IPsec state 149 synchronization. In both cases, a mobile node maintains only one 150 home binding at any given time. 152 Home Agent Virtual Switch 154 The Home Agent Virtual Switch operation can be used only if IPsec 155 state synchronization mechanism is available (outside of Home 156 Agent Reliability Protocol). The IPsec state per mobile node MUST 157 be shared between the active home agent and standby home agents in 158 the background. The active and the standby home agents are 159 addressed by the same home agent address, although only the active 160 home agent is accessible with the home agent address. Each mobile 161 node negotiates just one Security Association with the active home 162 agent. In case there is a failure of the active home agent, the 163 standby home agent takes over without the mobile node being aware 164 of the change in the home agent. 166 Home Agent Hard Switch 168 In the Home Agent Hard Switch, IPsec/IKE states synchronization is 169 not required. The home agents are addressed by different IP 170 addresses. When an active home agent fails, a mobile node will 171 receive a notification (Home Agent Switch message [RFC-5142]) from 172 a standby home agent, and send a Binding Update to the standby 173 home agent. In order for the mobile node to receive the Home 174 Agent Switch message securely from the standby home agent, the 175 mobile node needs to establish an IPsec SA with both the active 176 and the standby home agents beforehand. 178 2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC-2119]. 184 In this document, the term mobile node refers to both a mobile node 185 [RFC-3775] and a mobile router [RFC-3963]. 187 Mobility related terms used in this document are defined in [RFC- 188 3775] and [RFC-3753]. In addition or in replacement of these, the 189 following terms are defined or redefined: 191 Active Home Agent 193 A home agent that is currently serving the mobile nodes. 195 Standby Home Agent 197 A home agent which will serve the mobile nodes when the active 198 home agent fails. 200 Failed Home Agent 202 A home agent that is not available due to hardware or software 203 failure, system maintenance, etc. 205 Redundant Home Agent Set 207 A group of active and standby home agent(s). The Group Identifier 208 is used to identify a redundant home agent set. 210 Virtual Home Agent Address 212 A home agent address shared among home agents in a redundant home 213 agent set and used only in the Home Agent Virtual Switch case. 214 The address is only acitivated on an active home agent. 216 Home Agent Preference 218 This preference value is originally defined for Dynamic Home Agent 219 Address Discovery (DHAAD) in RFC3775. This protocol re-uses this 220 preference value for home agent selection when an active home 221 agent has failed. However, an operator can also define an 222 independent value used only for the home agent reliability 223 protocol if the operator wants to have different preference values 224 for DHAAD and the home agent reliability protocol. A home agent 225 SHOULD NOT use the same preference value of other home agents. 227 3. Problem Statement and Requirements 229 In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a 230 binding with only one home agent. Thus the home agent represents the 231 possibility of a single point of failure for Mobile IPv6. A home 232 agent is responsible for multiple mobile nodes on its home link. The 233 failure of the home agent may then result in the loss of connectivity 234 for numerous mobile nodes located throughout the Internet. To 235 overcome this problem, Mobile IPv6 allows deployment of multiple home 236 agents on the home link so that upon the failure of a home agent, a 237 mobile node can re-establish its connection through a new home agent. 238 However, the base Mobile IPv6 specification does not address home 239 agent failover and dynamic transfer of service from one home agent to 240 another. This transfer of service from the failed home agent to a 241 new active home agent requires coordination or pre-configuration 242 among the home agents regarding security associations, transfer of 243 mobile node bindings, and other service information for reliable 244 Mobile IPv6 service in a deployment scenario. 246 For the home agent reliability solution, we define the following 247 requirements: 249 Reliable Home agent service 251 Multiple home agents are available for a home prefix and one of 252 them actively serves the mobile nodes. A standby home agent takes 253 over when the active home agent becomes unavailable. The transfer 254 of the MN-HA association should be transparent to applications and 255 should not take longer than the care-of-addresses update procedure 256 described in Mobile IPv6 [RFC-3775]. 258 Availability of a redundant home agent set 260 Availability of an active home agent address and a standby home 261 agent address at the bootstrapping period for the mobile node is 262 assumed. 264 State Synchronization 266 The information for mobile nodes must be able to be synchronized 267 between an active home agent and standby home agents. This 268 includes the Binding Cache, AAA information, other Mobile IPv6 and 269 NEMO related information. Note that the Home Agent Reliability 270 protocol exchanges only running states of mobile nodes. 271 Therefore, we do not have any specific operation for synchronizing 272 the configuration information. For instance, when Mobile IPv6 is 273 operated with Authentication protocol, the synchronizing the 274 configurations of the Authentication protocol is out of scope in 275 this document. Operators MAY correctly configure in multiple home 276 agents. 278 Consideration of IPsec/IKE transfer 280 An active home agent maintains several IPsec and IKE states for 281 mobile nodes. These states are synchronized within the redundant 282 home agent set. The details are described in Section 10. 284 Secured Message Exchanges 286 The messages used between the home agents to transfer binding 287 cache information MAY be authenticated and encrypted. 289 Failure Detection 291 Redundant home agents must actively check for possible failure of 292 an active home agent. If a home agent supports an existing 293 failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC- 294 2281], it can re-use that mechanism to detect the home agent 295 failure. On the other hand, periodic Hello messages are 296 introduced to detect active home agent's service availability in 297 this document. 299 Failure Notification 301 If necessary, a mobile node is notified about the active home 302 agent failure by the standby home agent. 304 4. Protocol Overview 306 4.1. Home Agent Virtual Switch 308 A mobile node remains unaware about the change in the active home 309 agent since the home agents have replicated all session state 310 including IPsec/IKE/ESP states. IPsec/IKE/ESP state transfer is out 311 of scope of this document. 313 MN HA1(active) HA2(Standby) 314 | | . 315 |<--------->| | 1. IKE exchange (with HoA assignment) 316 |---------->| . 2. Binding Update 317 |<----------| . 3. Binding Acknowledgment 318 | | . 319 | |<--------->. 4. State exchanges (binding cache/IPsec) 320 | | . 321 | X . HA1 FAILURE 322 | X . 323 | X<----------. 5. Failure Detection 324 | X | 6. HA2 takes over the HA1 325 | X | 326 | X | RECOVERY COMPLETE 328 Figure 1: Overview of Home Agent Virtual Switch 330 The operations of the Home Agent Virtual Switch mode are shown in 331 Figure 1. A mobile node first attempts the IKE exchange for Security 332 Association (SA) setup and home address assignment (1). After 333 binding registration is done (2, 3), the active home agent pushes all 334 the states of its mobile nodes with a state synchronization message 335 (4). The standby home agent(s) is not active unless it takes over 336 from a failed home Agent. 338 When the active home agent's failure is detected (5), the standby 339 home agent activates the virtual home agent address on its interface 340 and takes over for the failed home agent. All the home agents in the 341 redundant home agent set share a virtual home agent address and the 342 routing will ensure only the active home agent will be reachable 343 using that virtual home agent address. The standby home agent can 344 serve all the mobile nodes for which the states are synchronized, 345 without any further message exchange, because it has all the 346 necessary information which it obtained from the failed home agent. 348 4.2. Home Agent Hard Switch 350 The overview of the Home Agent Hard Switch is shown in Figure 2. 351 This mode is not transparent to the mobile node when the active home 352 agent failure occurs. 354 MN HA1(active) HA2(Standby) 355 | | | 356 |<--------->| | 1. IKE exchange (with HoA assignment) 357 |---------->| | 2. Binding Update 358 |<----------| | 3. Binding Acknowledgment 359 |<--------------------->| 4. IKE exchange (without HoA assignment) 360 | | | 361 | |<--------->. 5. State exchanges (binding cache) 362 | | | 363 | X | HA1 FAILURE 364 | X | 365 | X<----------| 6. Failure Detection 366 |<----------------------| 7. Sending Home Agent 367 | X | Switch message 368 |<--------------------->| 8. Binding Registration 369 | X | 370 | X | RECOVERY COMPLETE 372 Figure 2: Overview of Home Agent Hard Switch 374 The mobile node establishes IPsec/IKE state with all the home agents 375 in the redundant home agent set beforehand (1 and 4), however it 376 registers its binding only with the active home agent (2 and 3). 377 When an active home agent fails, a standby home agent uses a pre- 378 existing IPsec SA to notify the mobile node about the failure by 379 securely sending a Home Agent Switch message. In order to discover 380 home agent addresses, two different mechanisms are defined, as 381 described in Section 9.4.1. The active home agent synchronizes the 382 required states of the mobile nodes, such as Binding Cache and AAA 383 information, with other standby home agents periodically (5). The 384 mobile node MUST NOT request a home address(es) assignment through 385 the IKE exchange to the standby home agent when it establishes an SA 386 with it (4). 388 When the standby home agent detects the failure of the active home 389 agent (6), it sends a Home Agent Switch message to all the mobile 390 nodes that were registered with the failed home agent (7). The Home 391 Agent Switch message must be encrypted by a pre-established IPsec SA. 392 After the switch message, the mobile node MUST send a binding update 393 to the new active home agent in order to update the Mobile IPv6 394 tunnel end points (8). 396 4.3. Home Agent Management 398 HA1(active) HA2 HA3 .. HAn 399 | | | | 400 |------->| | | 1. HA1 sends SwitchBack Request 401 |<-------| | | 2. HA2 sends SwitchBack Reply 402 | | | | 403 |<-------| | | 3. HA2 sends SwitchCompl (optional) 404 (standby) (active) | | HA2 BECOMES ACTIVE HA 405 | | | | 406 SYSTEM MAINTENANCE, ETC. 407 | | | | 408 |------->| | | 4. HA1 sends SwitchOver Request 409 |<-------| | | 5. HA2 sends SwitchOver Reply 410 | | | | 411 |------->| | | 6. HA1 sends SwitchCompl (optional) 412 (active) (standby) | | 7. HA1 returns to active HA 413 | | | | HA1 BECOMES ACTIVE AGAIN 415 Figure 3: Manual Home Agent Change 417 In some scenarios the active home agent may need to stop serving 418 mobile nodes for system maintenance. This specification provides for 419 a manual home agent switch by using SwitchBack Request and Reply 420 messages. As shown in Figure 3, the active home agent (HA1) sends a 421 SwitchBack Request message to a standby home agent (HA2). As soon as 422 HA2 receives the message, it becomes the active home agent. HA2 will 423 acknowledge the message by sending a SwitchBack Reply message to HA1. 424 HA1 becomes a standby home agent when it receives the SwitchBack 425 Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in 426 order to become the active home agent again. 428 The SwitchCompl message is used only in the Home Agent Hard Switch. 429 As shown in Section 9, it takes certain time to complete the home 430 agent switch. Thus, the old active home agent continues serving the 431 received packets for the mobile nodes during the switch process. As 432 soon as the new home agent completes the recovery, it sends 433 SwitchCompl message to the previous active home agent. SwitchCompl 434 is an optional operation in this specification. 436 5. Messages 438 5.1. New Mobility Header Messages 440 5.1.1. State Synchronization Message 442 This message is used to exchange state corresponding to a particular 443 mobile node(s). It MUST be unicasted and MUST be authenticated by 444 IPsec ESP. This message has the MH Type value TBD. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type |A| Reserved | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Identifier | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 453 . . 454 . Mobility Options . 455 . . 456 . | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 4: State Synchronization Message 461 Type 463 8-bit unsigned integer. It can be assigned one of the following 464 values: 466 0: Request 468 This message is called State Synchronization Request (SS-REQ) 469 and used to solicit the active state corresponding to a 470 particular mobile node. 472 1: Reply 474 The message is called State Synchronization Reply (SS-REP) and 475 is used between the home agents in the redundant home agent set 476 to exchange binding cache information and any other information 477 related to providing mobility service to the mobile nodes 478 either periodically or in response to a SS-REQ. 480 2: Reply-Ack 482 The message is called State Synchronization Reply-Ack (SS-ACK) 483 and is used to acknowledge to the SS-REP. This message is 484 optional and is specially used when the links between home 485 agents are not reliable. 487 Ack flag 489 This flag is valid only for SS-REP. If the sender requires 490 explicit acknowledgment by SS-ACK, it MUST set this flag. 492 Reserved 494 This field is unused. It MUST be initialized to zero by the 495 sender and MUST be ignored by the receiver. 497 Identifier 499 A 16-bit identifier to aid in matching state synchronization 500 message. The identifier should never be set to 0. It should 501 always be more than 1. 503 Mobility Options 505 Variable-length field of such length that the complete Mobility 506 Header is an integer multiple of 8 octets long. This field 507 contains zero or more TLV-encoded mobility options. The encoding 508 and format of defined options are described in [RFC-3775]. The 509 receiver MUST ignore and skip any options which it does not 510 understand. This message requires at least one mobility option, 511 therefore, there is no default length for this message. 513 One of the following options is mandatory in SS-REQ message. 514 Multiple same options can be stored in the same SS-REQ message, 515 (ex. two IP address options for two mobile nodes): 517 * IP Address Option (Sub-type: Home Address) defined in [RFC- 518 5268]. If a home agent wants the Binding Cache information for 519 a particular mobile node, it includes the mobile node's home 520 address in an IPv6 Address Option. If a home agent want to 521 solicit all the active mobile nodes' states, it can include the 522 unspecified address (0::0) in an IPv6 address option. 524 * Mobile Network Prefix Option. If a home agent wants to know 525 the forwarding state setup for a particular Mobile Network 526 Prefix, it includes a Mobile Network Prefix Option as defined 527 in [RFC-3963]. 529 * Vendor Specific Mobility Option. If a home agent wants vendor 530 specific information, it can solicit with this option as 531 defined in [RFC-5094]. 533 One of the following options is mandatory in SS-REP: 535 * Binding Cache Information Option 537 * AAA Information Option 539 * Vendor Specific Mobility Option 541 5.1.2. Home Agent Control Message 543 This message is used to control the status of a home agent to either 544 active or standby. This message MUST be unicasted between home 545 agents and MUST be authenticated and encrypted by IPsec ESP. The 546 Home Agent Control message has the MH Type value TBD. If no options 547 are present in this message, no padding is necessary and the Header 548 Len field will be set to 1. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type | Status | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 . . 556 . Mobility Options . 557 . . 558 . | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 5: Home Agent Control Message 563 Type 565 8-bit unsigned integer. It can be assigned one of the following 566 values: 568 0: SwitchOver Request (SO-REQ) 570 It is unicasted by a standby home agent that desires to become 571 the active home agent. The receiver of the message MUST 572 transition to standby state as soon as the message is received 573 and validated successfully. 575 1: SwitchOver Reply (SO-REP) 577 It is used to acknowledge the receipt of the corresponding SO- 578 REQ. 580 2: SwitchBack Request (SB-REQ) 582 It is unicasted by an active home agent that desires to become 583 a standby home agent. The receiver of this message SHOULD 584 transition to active state as soon as the message is received 585 and validated successfully. 587 3: SwitchBack Reply (SB-REP) 589 It is used to acknowledge the receipt of the corresponding SB- 590 REQ. 592 4: Switch Complete (SW-COMP) 594 This message is used to indicate the completion of switch over, 595 (i.e. sending home agent switch messages and receiving binding 596 update messages from all the served mobile nodes). 598 Status 600 8-bit unsigned integer indicating the disposition of a SO-REQ or 601 SB-REQ. This field is only valid in SO-REP and SB-REP. The 602 following Status values are defined: 604 0: Success 606 128: Reason unspecified 608 129: Administratively prohibited 610 130: Not active home agent (The receiver of SO-REQ is not the 611 active home agent) 613 131: Not standby home agent (The receiver of SB-REQ is already 614 the active home agent) 616 132: Not in same redundant home agent set 618 Mobility Options 619 No options are defined in this specification 621 5.1.3. Home Agent Hello Message 623 The Home Agent Hello (HA-HELLO) message MUST be either unicasted or 624 multicasted to carry home agent information among the redundant home 625 agent set. The HA-Hello message is defined for two purpose: 1) an 626 alive check and 2) home agent information exchange. A HA-HELLO 627 SHOULD be authenticated and encrypted by IPsec ESP when it is 628 unicasted. If a HA-Hello message is multicasted, IPsec ESP cannot be 629 applied. In this case the redundant home agent set should be located 630 in a secure network. Alternatively, all the home agents MUST have a 631 secure channel with each other. The HA-Hello has the MH Type value 632 TBD. If no options are present in this message, 0 octets of padding 633 are necessary and the Header Len field will be set to 2. 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Sequence # | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Home Agent Preference | Home Agent Lifetime | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Hello Interval | Group ID |A|R| Reserved | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 . . 646 . Mobility Options . 647 . . 648 . | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Figure 6: Home Agent Hello Message 653 Sequence # 655 16-bit unsigned integer. The Sequence number of the HA-Hello 656 message can be used to verify whether this Hello message is the 657 latest one or not. 659 Home Agent Preference 661 16-bit unsigned integer. The preference for the home agent 662 sending the HA-Hello message. This preference is the same as the 663 Home Agent Preference value of the Home Agent Information option 664 as defined in [RFC-3775]. However, operators MAY use a different 665 preference value for this operation. 667 Home Agent Lifetime 669 16-bit unsigned integer. The lifetime for the home agent sending 670 the HA-Hello message. This lifetime is the same as the Home Agent 671 Lifetime value of the Home Agent Information option as defined in 672 [RFC-3775]. 674 Hello Interval 676 16-bit unsigned integer. The interval for the home agent sending 677 this Hello message. 679 Group Identifier 681 8-bit unsigned integer. This value is used to identify a 682 particular redundant home agent set. 684 A flag 686 Active Home Agent flag. If this flag is set, the sender of this 687 HA-Hello message is an active home agent. 689 R flag 691 HA-HELLO requesting flag. If this flag is set, the receiver of 692 this HA-Hello message must send back a HA-Hello message to the 693 sender. 695 Reserved 697 This field is unused. It MUST be initialized to zero by the 698 sender and MUST be ignored by the receiver. 700 Mobility Options 702 No valid options are defined in this specification. 704 5.1.4. Home Agent Switch Message 706 This message is defined in Section 9.4.3. The Home Agent Reliability 707 protocol extends this message for the Home Agent Hard Switch. 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 |# of Addresses |I| Reserved | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | | 715 + + 716 . Home Agent Addresses . 717 + + 718 | | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 . Mobility options . 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 7: Home Agent Switch Message 725 IPsec Re-key (I) 727 The IPsec re-key (I) bit is set to indicate that the mobile node 728 SHOULD start an IPsec re-key with the home agent specified in the 729 Home Agent Addresses field. This flag is used when a failed home 730 agent recovers and needs to re-establish IPsec SA/IKE state with a 731 mobile node. When this flag is set, the mobile node does not 732 switch the home agent, but only re-key the SA. 734 Reserved 736 The reserve field is reduced from 8 to 7 bits 738 5.2. New Mobility Options 740 5.2.1. IP address Option 742 This option is already defined in the Fast Handovers for Mobile IPv6 743 (FMIP) specification [RFC-5268]. This document introduces new Sub- 744 Type values for home agent address and Home Address. 746 Option-Code 748 * 4: Home Address 750 5.2.2. Binding Cache Information Option 752 The binding cache information option has an alignment requirement of 753 8n+2. The Binding Cache Information option is only valid in a State 754 Synchronization message. Its format is as follows: 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Type = TBD | Length = 40 | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Flags | Sequence Number | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Lifetime | Reserved | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 + + 767 | Home Address | 768 + + 769 | | 770 + + 771 | | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 + + 775 | | 776 + Care-of Address + 777 | | 778 + + 779 | | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 . . 782 . . 783 . Mobile Network Prefix Option . 784 . . 785 . | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 Figure 8: Binding Cache Information Option 790 The fields of Home Address, Care-of Address, Flags, Sequence Number, 791 and Lifetime are copied from the registered binding of a particular 792 mobile node or mobile router. The 8-bit Reserved field MUST be set 793 to zero. If the R-flag is set to indicate this binding cache entry 794 is for a mobile router, then this option will be immediately followed 795 by one or more Mobile Network Prefix options. 797 5.2.3. AAA Information Option 799 This option is used to carry the AAA state of the mobile node's 800 Mobile IPv6 sessions. The AAA state information can be carried in 801 RADIUS or Diameter AVP formats including the user and session info. 802 This information option is only valid in a State Synchronization 803 message. 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Type = TBD | Length | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 . . 811 . . 812 . AAA AVPs . 813 . . 814 . . 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Figure 9: Vendor Specific Inforamtion Option 819 Type 821 8-bit Type value. The value is TBD. 823 Length 825 8-bit length value. 827 AAA AVPs 829 Series of TLV encoded AAA AVPs (including vendor specific AVPs) 830 carrying AAA-related information for each Mobile IPv6 and IPsec/ 831 IKE session. 833 6. Home Agent Configuration 835 6.1. Network Configuration 837 The Home Agent Reliability protocol supports two different 838 configurations for standby home agents. Standby home agents can be 839 placed on the same home link or on a different link. 841 HA1 HA2 HA3 HA4 .... HAn 842 | | | | | 843 --------+------+------+------+--------+--------- 844 Home Link 846 Figure 10: Local Recovery Configuration 848 Figure 10 depicts the configuration where home agents serving the 849 same home network are located on the same link. For example, HA2, 850 HA3 and HA4 are standby home agents of HA1. This is the same as what 851 Mobile IPv6 defines for home agent configuration. 853 ---------IGP------>|<---BGP--->|<-----IGP--------- 855 HA1 HA2 HA3 HA4 856 | | | | 857 --------+------+-----+ R---R---R +-----+------+------- 858 Home Link Routers Recovery Link 859 (region-1) (region-2) 861 Figure 11: Global Recovery Configuration 863 Figure 11 illustrates when standby home agents are located on a 864 different link (illustrated as Recovery Link in Figure 11). Most 865 large operators have a very stringent requirement on network 866 availability even in the worst type of disaster or outage. For 867 example, HAs in region-1 are backed up by HAs in region-2. These two 868 regions are geographically separated. If region-1 suffers a downtime 869 due to any reason, all the sessions will be seamlessly taken over by 870 the nodes in region-2. This is called geographic redundancy. This 871 is a well-known configuration for Telecommunications operators. It 872 can achieve home agent recovery even if the entire home link fails. 873 In Figure 11, HA3 and HA4 are standby home agents of HA1 and HA2. In 874 this case, HA3 and HA4 cannot receive packets meant for the home 875 network until the route on the Routers is changed. The routing must 876 be also updated to direct the packets meant for the home link to the 877 recovery link. 879 6.2. Address Configuration for Virtual Switch 881 Each standby home agent obtains its individual IPv6 address from its 882 attached link. This IPv6 address is used by the home agent 883 reliability protocol to exchange information with the associated home 884 agents. The link between home agents should be secured. 886 The virtual home agent's IPv6 address which is known by the mobile 887 node is shared with the standby home agents. When a home agent 888 fails, the standby home agent activates the IPv6 address of the 889 failed home agent and becomes the active home agent. The standby 890 home agent should not activate the IPv6 address until it knows the 891 active home agent is no longer reachable at the address, otherwise 892 address duplication will occur. To guarantee transparency of the 893 home agent virtual switch to mobile nodes located on the home link, 894 the neighbor cache of the home agent IP address MUST be carefully 895 operated. See Section 8.1 in detail. 897 6.3. Address Configuration for Hard Switch 899 Each standby home agent obtains its individual IPv6 address from its 900 attached link. This IPv6 address is used by the home agent 901 reliability protocol to exchange information with the associated home 902 agents. The link between home agents should be secured. 904 Each home agent configures itself with a different IPv6 address from 905 the same home prefix. This IPv6 address can be used for the Home 906 Agent Reliability protocol if the standby home agents are located at 907 the same link of the active home agent (Figure 10). In case of 908 Figure 11, the router must carefully route packets to the standby 909 home agents as described in Section 8.1. Once a mobile node 910 registers its binding with the active home agent, it may solicit an 911 IPsec/IKE exchange with standby home agents. These packets must be 912 routed to the recovery link. This can be achieved by installing host 913 routes for the standby home agents on the recovery link of the 914 router. 916 7. Home Agent Common Operation 918 7.1. Home Agent List Management 920 In Mobile IPv6 [RFC-3775], each home agent periodically sends router 921 advertisements with the Home Address Information option [RFC-3775] 922 when there are multiple home agents present on a link. This 923 information is managed in a home agent list. For the Home Agent 924 Reliability Protocol, HA-HELLO messages are used to manage the home 925 agent list. There are several reasons to use HA-HELLO message 926 instead of Router Advertisement such as: 928 1. In the Home Agent Virtual Switch mode, if the standby home agents 929 send unsolicited Router Advertisements to the home link, the 930 mobile nodes attached to the home link are aware of the presence 931 of standby home agents. However, the standby home agents must be 932 hidden until the active home agent fails. HA-Hello messages are 933 exchanged only between home agents. 935 2. As shown in Section 6.1, standby home agents are not always 936 configured at the same link. In this case, Router Advertisements 937 cannot be sent to the recovery link unless the home link and the 938 recovery link are connected (ex. L2TP). HA-HELLO can be sent 939 beyond the link. 941 3. The Home Agent Reliability protocol defines to manage additional 942 information such as Group ID and Active/Standby Status of the 943 home agents in the home agent list. 945 In Mobile IPv6, Router Advertisement are to carry the home agent 946 information to both mobile nodes on the home link and the home 947 agents. On the other hand, in the Home Agent Reliability protocol, 948 HA-Hello is to exchange the information among the home agents and the 949 Router Advertisement is used to notify the information to the mobile 950 nodes. The home agents SHOULD NOT process the Home Agent Information 951 option carried by Router Advertisement if HA-HELLO is available. 952 Operators can define different values to the parameters of the home 953 agent information for HA-HELLO and Router Advertisement. The 954 management operation of the home agent list is unchanged and defined 955 in [RFC-3775]. 957 7.2. Detecting Home Agent Failure 959 The active and standby home agents can monitor each other in several 960 ways. One method is to reuse other failure detection mechanisms 961 defined in VRRP[RFC-3768] and HSRP [RFC-2281] (see Section 7.6). 962 However, VRRP and HSRP cannot detect the case where the system is 963 running but the Mobile IPv6 stack is not operational. In the Home 964 Agent Reliability protocol, a new message called HA-HELLO is 965 periodically exchanged in the redundant home agent set as a heart- 966 beat. If HA-HELLO is implemented as a part of Mobile IPv6 stack, it 967 can detect the home agent failure (Mobile IPv6 stack failure). This 968 HA-HELLO can also be exchanged frequently enough to detect the 969 failure promptly and does not introduce any processing overhead to 970 the mobile node attached to the home link. 972 Failure events used in the Home Agent Reliability protocol are listed 973 below. 975 Loss of HA-HELLO 977 In the event that a standby home agent does not receive any HA- 978 HELLO from its peer which is currently the active home agent for a 979 configurable duration, the standby home agent assumes the active 980 home agent's failure. Any home agents can also request the home 981 agent information of the other home agent in the same redundant 982 home agent set by sending HA-HELLO with R-flag set. If HA-HELLO 983 is not replied from the target home agent within a configurable 984 amount of time, that home agent peer is considered to have failed. 985 The detail of the Hello message is described in Section 7.3. 987 Monitored Server Failure by the Active Home Agent 989 There may be number of critical servers such as AAA server in the 990 network that are essential for the ongoing Mobile IPv6 sessions at 991 the home agent. Operators can have a policy in place that the 992 active home agent is treated as a failed home agent upon detecting 993 that the link to such servers has failed. 995 Routing Peer/Link Failure 997 Operators may require the home agent to detect its next-hop 998 routing peer failure. If the next-hop routing failure is fatal in 999 nature, or due to some other routing policies, the active home 1000 agent is treated as a failed home gent and the recovering 1001 operation should be started. 1003 7.3. Processing Hello Messages 1005 HA-HELLO MUST be either unicasted or multicasted. A new multicast 1006 address (all_homeagent_multicast_address) will be assigned by the 1007 IANA. When all the home agents in a redundant home agent set are 1008 configured on a same home link, they MUST join the 1009 all_homeagent_multicast_address. On the other hand, if a home 1010 recovery link is separately defined as described in Figure 11, each 1011 home agent SHOULD unicast HA-HELLO. 1013 7.3.1. Requesting Hello Message 1015 A home agent can solicit HA-HELLO to a particular home agent in the 1016 same redundant home agent set by unicasting HA-HELLO with the R-flag 1017 set. The sender MUST fill the fields of the HA-HELLO with its home 1018 agent information. If a home agent needs to request HA-HELLO to all 1019 the home agents, it sends the HA-HELLO with R-flag set to the 1020 all_homeagent_multicast_address. Requesting HA-HELLO SHOULD be 1021 operated when: 1023 1. A new home agent needs to collect the information of all the 1024 other home agents in the same redundant home agent set. The HA- 1025 HELLO with R-flag set is multicasted to 1026 all_homeagent_multicast_address. 1028 2. A home agent entry in the redundant home agent list is about to 1029 be removed due to home agent lifetime expiration. The HA-HELLO 1030 with R-flag set is unicasted to the home agent whose lifetime is 1031 soon expired. 1033 3. HA-HELLO has not been received during the specified hello 1034 interval. The HA-HELLO with R-flag set is unicasted to the 1035 target home agent. 1037 7.3.2. Sending Hello Message 1039 Each home agent periodically sends HA-HELLO for the home agent's 1040 failure detection. The interval time is configured at each home 1041 agent. Each home agent MUST also send a HA-HELLO in following case: 1043 1. when a home agent receives a HA-HELLO with the R-flag set 1045 2. When a home agent detects its local information such as home 1046 agent preference, home agent lifetime, and registration status 1047 change. 1049 3. When a new home agent boots up, it SHOULD solicit Hello messages 1050 by multicasting a Hello message with the R-flag set in parallel 1051 with sending its own Hello message. 1053 When a home agent sends HA-HELLO, the following rule MUST be applied. 1055 o Whenever a home agent generates HA-HELLO, it MUST increment in the 1056 Sequence Number. The Sequence Number SHOULD be initialized to 1057 zero for the first Hello message. To accomplish sequence number 1058 rollover, if the sequence number has already been assigned to be 1059 the largest possible number representable as a 16-bit unsigned 1060 integer, then when it is incremented it will then have a value of 1061 zero (0). 1063 o It MUST also specify its own Group ID in HA-HELLO. 1065 o If a home agent is the active home agent, it MUST set the A-flag 1066 in HA-HELLO. 1068 o In the Home Agent Hard Switch mode, the source IPv6 address of HA- 1069 HELLO MUST be the home agent address. 1071 o In the Home Agent Virtual Switch mode, the home agent local 1072 address MUST be used. 1074 7.3.3. Receiving Hello Message 1076 When a home agent receives HA-HELLO, it SHOULD verify the HA-HELLO as 1077 follows: 1079 o If the HA-HELLO is not protected by IPsec ESP, it SHOULD be 1080 discarded. Note that, only if the HA-HELLO is sent on a dedicated 1081 link between the home agents, IPsec protection might not be always 1082 required. This depends on the operational policy. 1084 o If HA-HELLO is sent from non global IPv6 address, it MUST be 1085 discarded. 1087 o If the source IPv6 address of HA-HELLO is not belong to one of the 1088 home agents in the redundant home agent set, the HA-HELLO MUST be 1089 ignored. 1091 o If the Group ID field of the received HA-HELLO and the receiver's 1092 Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST 1093 NOT be sent to home agents whose Group ID is different from the 1094 sender. 1096 o If the Sequence Number value in the HA-HELLO is equal to or less 1097 than the last received Sequence Number value stored in the home 1098 agent list entry, the HA-HELLO MUST be discarded. 1100 o HA-HELLO satisfying all of above tests MUST be processed by 1101 receiver. The receiver copies home agent information in HA-HELLO 1102 to the corresponding home agent list entry. The home agent 1103 address of the sender is retrieved from the Source Address field 1104 of the IPv6 header of the HA-HELLO. 1106 o If the home agent lifetime field in the HA-HELLO is set to 0, the 1107 receiver removes the sender from the home agents list. 1109 o If the R-flag is set in the received HA-HELLO, the receiver MUST 1110 send a new HA-HELLO to the originator as described in 1111 Section 7.3.2. 1113 7.4. Processing State Synchronization Messages 1115 It is necessary for standby home agents to synchronize the state 1116 information of each mobile node registered with the active home 1117 agent. In the Home Agent Hard Switch mode, it is not necessary for 1118 the home agents to synchronize the complete binding cache 1119 information. The standby home agent needs the mapping information of 1120 the active home agent and the mobile node. The information is used 1121 to send the Home Agent Switch messages to all the mobile node served 1122 by the failed home agent. 1124 7.4.1. Requesting State of a Particular Mobile Node(s) 1126 When a home agent needs the state information for a particular mobile 1127 node or a subset of mobile nodes, it sends a SS-REQ message 1128 constructed as follows: 1130 o It MUST set the Type field to 0 (Request). 1132 o It MUST set a random value in the Identifier field that does not 1133 coincide with any other currently pending Requests. 1135 o It MUST include an IP address mobility option(s) which subtype is 1136 set to the home address if the target is mobile node(s). 1138 o It MUST include a Mobile Network Prefix mobility option(s) for 1139 mobile router(s). 1141 o It MUST set the unspecified address (0::0) in the Home Address 1142 mobility option if it solicits the state of all the mobile nodes 1143 and mobile routers registering at the receiver of SS-REQ 1144 (i.e.destination of SS-REQ). 1146 o In the Home Agent Virtual Switch, the sender of the SS-REQ MUST be 1147 a home agent local address of one of the home agents in the same 1148 redundant home agent set. 1150 o In the Home Agent Hard Switch, the sender of the SS-REQ MUST be a 1151 home agent address of one of the home agents in the same redundant 1152 home agent set. 1154 o The destination of the SS-REQ MUST be the active home agent for 1155 the requesting home address or mobile network prefix. The standby 1156 home agent MUST NOT reply the SS-RREP to the sender. 1158 When a home agent receives the SS-REQ, it MUST verify if SS-REQ is 1159 constructed with the above rules. If SS-REQ satisfy all the above 1160 tests, the receiver of the SS-REQ MUST reply SS-REP including the 1161 state information of the requested mobile node(s) and/or mobile 1162 network prefix(es) as described in Section Section 7.4.2. 1164 7.4.2. Synchronizing State 1166 State synchronization messages SHOULD be sent when: 1168 1. The active home agent receives SS-REQ. 1170 2. The active home agent creates a binding cache entry for a 1171 particular mobile node. 1173 3. The active home agent deletes a binding cache entry for a 1174 particular mobile node. 1176 The active home agent MAY additionally send state synchronization 1177 message in following cases: 1179 1. The active home agent update the state information for all 1180 sessions that changed since the last update in a periodic 1181 interval 1183 2. Only for the Home Agent Virtual Switch mode, the active home 1184 agent updates a binding cache entry for a particular mobile node 1185 whenever the binding cache entry is updated. In the Home Agent 1186 Hard Switch mode, standby home agents only need the mapping 1187 information of a home address of the mobile node/router and the 1188 home agent address of the active home agent to which the mobile 1189 node/router is currently registering. This mapping is used to 1190 send a Home Agent Switch message. 1192 If an active home agent sends a State Synchronization message 1193 whenever the local state information changes, such as a binding cache 1194 change, the number of the State Synchronization messages sent can be 1195 quite large. 1197 All the state information of the requested mobile nodes is stored in 1198 the SS-REP. Following rules must be applied when the active home 1199 constructs SS-REP. 1201 o If the SS-REP is sent in response to the SS-REQ, the active home 1202 agent MUST copy the Identifier field of the State Synchronization 1203 request message to the Identifier field in the SS-REP. Otherwise, 1204 it MUST set the Identifier field to 0. 1206 o When the active home agent stores the state of multiple mobile 1207 nodes in a SS-REP, a Binding Cache Information option is used as a 1208 separator. For each mobile node, a Binding Cache Information 1209 option is placed first, followed by any other options such as AAA 1210 option. When the next Binding Cache Information option is reached 1211 in the State Synchronization message, it indicates the information 1212 of a different mobile node. 1214 o If the unspecified address is found in the Home Address mobility 1215 option carried with the SS-REQ, the active home agent MUST return 1216 the state of all the active mobile nodes and mobile routers by the 1217 SS-REP. The IP fragmentation can be occurred depending on the 1218 total size of all the states. 1220 o A SS-REP MUST be authenticated and encrypted by IPsec ESP. 1222 o The destination and source home agents MUST belong to the same 1223 redundant home agent set. 1225 o In the Home Agent Hard Switch, the IPv6 source address MUST be set 1226 to the home agent address of the sender. 1228 o In the Home Agent Virtual Switch, the IPv6 source address MUST be 1229 set to the home agent local address of the sender. 1231 When a home agent receives a SS-REP, it MUST verify whether the SS- 1232 REP is constructed with the above rules or not. If the SS-REP does 1233 not satisfy all the rules above, it is discarded. Otherwise, the 1234 following operation must be taken. 1236 o The receiver of SS-REP MUST update its binding cache and all other 1237 necessary information such as AAA and vendor specific information 1238 in the particular database. 1240 o In the Home Agent Hard Switch mode, the receiver MUST record the 1241 IPv6 address of the sender as the active home agent of the mobile 1242 node. 1244 7.4.3. Reliable Transmission by Explicit Acknowledgement 1246 Signaling messages of the Home Agent Reliability protocol are not 1247 guaranteed reliable transmission due to the Mobility Header use. 1248 This is not always critical, because the link between home agents is 1249 carefully managed as stable and reliable. However, operators may 1250 need more explicit notification to confirm the message exchanges 1251 between home agents. This specification provides an optional 1252 acknowledgment to SS-REP messages. 1254 If an active home agent requires an acknowledgment of SS-REP, it set 1255 the Ack flag in the SS-REP. The receiver of such SS-REP will send 1256 back a SS-ACK. The receiver MUST copy the Identifier value received 1257 in the SS-REP into SS-ACK in order to match the SS-REP and SS-ACK. 1259 7.5. Processing Home Agent Control Messages 1261 7.5.1. Standby Home Agent becomes an Active Home Agent 1263 When a standby home agent decides to become an active home agent, the 1264 standby home agent sends a SO-REQ to the active home agent. This 1265 message MUST be unicasted to the active home agent and MUST be 1266 encrypted and authenticated by IPsec ESP. The active home Agent MUST 1267 NOT generate this message. 1269 When an active home agent receives a SO-REQ, it MUST operate the 1270 following verification and operations: 1272 o If the SO-REQ is not protected by IPsec, it MUST be discarded. 1274 o If the receiver of the SO-REQ is not an active home agent, it MUST 1275 send a SO-REP with the Status field set to 130 (Not active home 1276 agent). 1278 o If the sender home agent does not belong to the same redundant 1279 home agent set, a SO-REP message MUST be sent to the sender with 1280 the Status field set to 132 (Not in same redundant home agent 1281 set). 1283 o If the receiver is an active home agent, there is case where the 1284 active home agent cannot be standby home agent. In such case, the 1285 active home agent can reply a SO-REP with the Status field set to 1286 129 (Administratively prohibited). 1288 o Otherwise, the active home agent MUST become a standby home agent 1289 and reply with a SO-REP message with the Status field set to 0 1290 (Success). 1292 The SO-REP MUST be also protected by IPsec ESP. Otherwise, the 1293 message MUST be silently discarded. If the receiver of SO-REP did 1294 not send a SO-REQ message (i.e. unexpected SO-REP), the message MUST 1295 be ignored. If the Status field of the SwitchOver Reply message is 0 1296 (Success), the receiving standby home agent immediately becomes an 1297 active home agent as described in Section 8.2. If the value in the 1298 Status field is greater than 128 an error has occurred. In this 1299 case, the receiver MUST NOT attempt to be an active home agent. 1301 7.5.2. Active Home Agent becomes in-active 1303 When an active home agent decides to become a standby home agent, it 1304 sends a SB-REQ to one of standby home agent. The reason for the 1305 active home agent to send this message can be administrative 1306 intervention, and events like Monitored Server Failure by the active 1307 home agent or Routing Peer/Link Failure. This message MUST be 1308 unicasted to one of the standby home agents and MUST be encrypted and 1309 authenticated by IPsec ESP. A standby home agent MUST NOT generate 1310 this message. 1312 When a home agent receives a SwitchBack Request message, it first 1313 verifies the message. 1315 o If the SwitchBack Request message is not protected by IPsec ESP, 1316 it MUST be discarded. 1318 o If the sender home agent of the SB-REQ is not an active home 1319 agent, the receiver MUST reply a SB-REP with the Status field is 1320 set to 130 (Not active home agent). 1322 o If the sending home agent does not belong to the same redundant 1323 home agent set, a SB-REP MUST be sent in which the Status field 1324 set to 132 (Not in same redundant home agent set). 1326 o Otherwise, the receiving home agent MUST send a SB-REP with the 1327 Status field is set to 0 (Success). 1329 After sending the SwitchBack reply, it MUST NOT become an active home 1330 agent immediately. This is because the active home agent is still 1331 active until it receives the SB-REP which is acknowledging the SB- 1332 REQ. The standby home agent SHOULD change to active at least after 1333 LINK_TRAVERSAL_TIME. 1335 If a home agent receives a SB-REP, it MUST be protected by IPsec ESP, 1336 otherwise the message MUST be silently discarded. If the receiving 1337 home agent did not send a SB-REQ matched to the received SB-REP, the 1338 message MUST be silently discarded. If the Status field of the SB- 1339 REP is 0 (Success), the active home agent immediately becomes a 1340 standby home agent. The sender home agent of SB-REP becomes active 1341 home agent as described in Section 8.2. If the value in the Status 1342 field is greater than 128, the receiver of SB-REP (active home agent) 1343 cannot become a standby home agent and MUST continue to be an active 1344 home agent. 1346 7.6. Interworking with VRRP 1348 VRRP and HSRP specify an election protocol that dynamically assigns 1349 responsibility for a virtual router to one of the VRRP routers on a 1350 LAN. This operation is similar to the Home Agent Virtual Switch 1351 operation. For example, the VRRP router controlling the IP 1352 address(es) associated with a virtual router is called the Master, 1353 and forwards packets sent to these IP addresses. The election 1354 process provides dynamic fail over in the forwarding responsibility 1355 should the Master become unavailable. Although VRRP is used to 1356 guarantee home agent address reachability, it cannot be used for 1357 state synchronization and explicit switching of Master and Backup. 1358 Thus, the Home Agent Reliability protocol cannot be replaced by VRRP. 1359 This section explains how VRRP can interwork with the Home Agent 1360 Reliability protocol. 1362 When VRRP is available, VRRP can replace the Hello message described 1363 in Section 5.1.3. However, some of information is missed by using 1364 VRRP. After receiving a VRRP message, each home agent SHOULD process 1365 the message and store the information as if it receives Home Agent 1366 Hello messages Section 7.3.3. The Home Agents SHOULD still perform 1367 binding cache synchronization as described in Section 7.4 and SHOULD 1368 support the Home Agent Switch message as described in Section 9.2. 1370 In addition to this, VRRP is useful only if all home agents are 1371 located on the same link. If the home agents are topologically 1372 separated, the Home Agent Reliability protocol MUST be used. 1374 0 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr| 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 |(rsvd) | Adver Int | Checksum | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | | 1382 + + 1383 | IPv6 Address(es) | 1384 + + 1385 + + 1386 + + 1387 + + 1388 | | 1389 + + 1390 | | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 Figure 12: VRRP Packet Format 1394 The message format of VRRP is described in Figure 12. Each field is 1395 mapped as follows: 1397 Virtual Rtr ID 1399 Group ID is stored in the Virtual Rtr ID field. 1401 Priority 1403 Home Agent Preference is stored in the Priority field. Note that 1404 VRRP only has 8 bits for the Priority field. Therefore, values 1405 larger than 255 MUST NOT be assigned to the preference value. 1407 Count IPv6 IPv6 Addr 1409 This field MUST be always be 1. 1411 Advert Int 1413 This field MUST be mapped to the Hello Interval field of the Home 1414 Agent Hello message, though it only has 12 bytes. 1416 IPv6 address 1418 A home agent address is stored in this field. 1420 Home Agent Lifetime, Sequence Number and Flags field are missing in 1421 the VRRP packet format. Therefore, operators SHOULD use the same 1422 statically configured value for Home Agent Lifetime. Each home agent 1423 does not check freshness of received VRRP message because of no 1424 sequence number. If VRRP is used, a home agent cannot determine the 1425 active home agent from the VRRP message due to lack of A flag, and 1426 cannot request a VRRP advertisement to other home agents. 1428 7.7. Retransmissions and Rate Limiting 1430 Standby and active home agents are responsible for retransmissions 1431 and rate limiting of a SS-REQ, SO-REQ, SB-REQ messages for which they 1432 expect a response. The home agent MUST determine a value for the 1433 initial transmission timer: 1435 o If the home agent sends a SS-REQ message, it SHOULD use an initial 1436 retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER. 1438 o If a standby home agent sends a SO-REQ message, it SHOULD use an 1439 initial retransmission interval of INITIAL_SWICHOVER_REQ_TIMER. 1441 o If an active home agent sends a SB-REQ message, it SHOULD use an 1442 initial retransmission interval of INITIAL_SWICHBACK_REQ_TIMER . 1444 If the sending home agent fails to receive a valid matching response 1445 within the selected initial retransmission interval, it SHOULD 1446 retransmit the message until a response is received. All of the 1447 above constants are specified in Section 11. 1449 The retransmission MUST use an exponential backoff process as 1450 described in [RFC-3775] until either the home agent receives a 1451 response, or the timeout period reaches the value 1452 MAC_HARELIABILITY_TIMEOUT (16sec). The home agent SHOULD use a 1453 separate back-off process for different message types and different 1454 destinations. The rate limiting of Mobility Header messages is the 1455 same as one in [RFC-3775]. A home agent MUST NOT send Mobility 1456 Header Messages to a particular home agent more than MAX_UPDATE_RATE 1457 (3) times a second, which is specified in [RFC-3775]. 1459 8. Home Agent Virtual Switch 1461 8.1. Consideration of Routing and Neighbor Discovery Protocol 1463 This section gives a brief explanation of how a home agent interacts 1464 with routing and Neighbor Discovery Protocol (NDP) when the Home 1465 Agent Virtual Switch mode is used. 1467 When a standby home agent becomes active in the Home Agent Virtual 1468 Switch mode, it MUST start to advertise the home agent address and 1469 the home prefix of the home addresses serviced by the redundant home 1470 agent set into the routing infrastructure. This operation is 1471 normally done using a route selector such as BGP or an OSPF modifier. 1472 For example, we can use the AS_Path prepend operation for BGP, and 1473 the Metric field in OSPF for the route selection. When each home 1474 agent participates in OSPF routing, each home agent should be 1475 configured with the appropriate metric matched to the home agent 1476 preference value. When the active home agent fails, OSPF detects the 1477 failure and can dynamically switch the route to the standby home 1478 Agent based on the OSPF cost value. If this cost conflicts with the 1479 home agent preference value due to configuration errors, the routers 1480 on the home link may not route packets to the desired standby home 1481 agent. In order to change the OSPF cost correctly and dynamically, 1482 The operator takes other existing approaches. For example, most of 1483 router vendors have a private MIB to set the cost via SNMP, though 1484 this is a vendor-specific function. 1486 When an active home agent activates a home agent address, it SHOULD 1487 use a virtual MAC address as introduced in [RFC-3768]. When the 1488 active home agent is changed, the neighbor cache of the active home 1489 agent is not necessarily updated on mobile nodes located on the home 1490 link. Otherwise, the new home agent MUST update the neighbor cache 1491 entry for the home agent address on all the mobile nodes located on 1492 the home link. In addition, Mobile IPv6 uses proxy NDP to intercept 1493 packets meant for mobile nodes which are away from the home link. 1494 However, it is unnecessary for the new active home agent to overwrite 1495 the existing proxy neighbor entries of the mobile nodes. 1497 8.2. Home Agent Recovery 1499 After detecting the active home agent has failed, the standby home 1500 agent whose preference value is the highest MUST take over the failed 1501 home agent. The standby home agent MUST activate the virtual home 1502 agent address. If a virtual MAC address as introduced in [RFC-3768] 1503 is used, the standby home agent MUST start using that virtual MAC 1504 address as well. Since all the necessary state has already been 1505 transferred to this standby home agent before the active home agent 1506 failed, it can immediately start acting as the active home agent. 1508 9. Home Agent Hard Switch 1510 9.1. Home Agent Recovery 1512 After detecting the active home agent has failed, the standby home 1513 agent whose preference value is the highest MUST take over the failed 1514 home agent. The standby home agent MUST send a Home Agent Switch 1515 message to all the mobile nodes that were registered at the failed 1516 home agent as described in Section 9.2, using the pre-established 1517 IPsec SA. The standby Home Agent MUST set its own address in the 1518 Home Agent Address field in the Home Agent Switch message so that it 1519 will receive the binding update from the mobile node as an 1520 acknowledgment of the sent Home Agent Switch message. The home agent 1521 switch-over is complete when it receives binding updates from all the 1522 mobile nodes. It is important to remark that sending Home Agent 1523 Switch messages to all the mobile nodes at once may bring non- 1524 negligible overhead to the home agent. 1526 This overhead cannot be avoided if the active home agent suddenly 1527 stop serving mobile node because of unexpected reasons (crash, 1528 network trouble, etc). However, if this switch over is operated 1529 under the administrative operation (maintenance, etc), the previous 1530 active home agent may continue serving the mobile nodes until the 1531 switch over is completed. Until the mobile node sends a binding 1532 update to the new active home agent, it still sends the packet to the 1533 previous home agent in the Home Agent Hard Switch. Therefore, the 1534 new active home agent can notify the completion of switch-over to the 1535 previous active home agent by using Home Agent Control message as 1536 described in Section 9.3. As soon as this message is received, the 1537 previous active home agent can be shutdown or detached from the 1538 network safely. 1540 9.2. Sending Home Agent Switch Messages 1542 The standby home agent which is going to be active MUST send a Home 1543 Agent Switch message as defined in [RFC-5142] to all the mobile nodes 1544 that were being served by the failed home agent. The Home Agent 1545 Switch message must be securely sent to the mobile node by using 1546 IPsec ESP. The standby home agent MUST include only its own home 1547 agent address in the Home Agent Switch message. If there are a large 1548 number of mobile nodes served by the failed home agent, the overhead 1549 sending Home Agent Switch messages is high. Until a mobile node 1550 receives this Home Agent Switch messages, the mobile node's 1551 communication is discontinued. Therefore, until the standby home 1552 agent completes sending the Home Agent Switch message to all the 1553 mobile nodes and receives Binding Updates from all the mobile node, 1554 the failed home agent SHOULD serve mobile nodes if possible. This is 1555 the case when the active home agent is replaced by administrative 1556 operation with the Home Agent Control messages as described in 1557 Section 9.3. 1559 When a failed home agent recovers, it MUST re-establish an IPsec SA 1560 with each mobile node served by its redundant home agent set. 1561 Otherwise, it cannot be either a standby or active home agent for the 1562 mobile nodes. Therefore, as soon as the active home agent detects 1563 the recovery of the failed home agent, it sends a Home Agent Switch 1564 message with the I-flag set to all the mobile nodes serving by other 1565 home agents in the same redundant home agent set, and includes the 1566 recovered home agent address in the Home Agent Addresses field. The 1567 mobile node will re-key the SA, but it will not change the home agent 1568 by this home agent switch message which I-flag is set. 1570 9.3. Notification of Home Agent Switch Completion 1572 If the new active home agent completes the switch-over as described 1573 in Section 8.2, it SHOULD send a SW-COMP to the previous active home 1574 agent in the Home Agent Hard Switch case. Until the previous home 1575 agent receives this message, it SHOULD continue serving any mobile 1576 nodes that are registered with it. Once the previous home agent 1577 receives the SW-COMP message, it can stop home agent services. 1579 9.4. Mobile Node Operation 1581 9.4.1. Home Agent Addresses Discovery 1583 In the Home Agent Hard Switch mode, a mobile node authenticates 1584 itself to two or more home agents and creates IPsec SAs with them 1585 during bootstrapping. When the active home agent fails, another home 1586 agent can use the pre-existing SA to notify the mobile node about the 1587 failure by sending a Home Agent Switch message. 1589 In order to discover multiple home agent addresses, two different 1590 mechanisms are defined in the bootstrapping solution in the split 1591 scenario [RFC-5026]. One is DNS lookup by home agent Name, the other 1592 is DNS lookup by Service Name. DHCPv6 can also be used in the 1593 integrated scenario [ID-BOOTINT] to provide home agent provisioning 1594 to mobile nodes. 1596 In the split scenario, a mobile node can use DNS lookup by Service 1597 Name to discover the home agents, as defined in [RFC-5026]. For 1598 example, if home agent reliability is required by a mobile node, DNS 1599 lookup by Service Name method is recommended for the mobile node to 1600 discover multiple home agents addresses. Therefore, mobile nodes 1601 will query the DNS SRV records with a service name of mip6 and 1602 protocol name of ipv6. The DNS SRV records includes multiple home 1603 agent addresses and different preference values and weights. The 1604 mobile node SHOULD choose two or more home agents from the home 1605 agents list according to their preference value. Then the mobile 1606 node should authenticate itself to these home agents via an IKEv2 1607 exchange. 1609 In the integrated scenario, a mobile node can use DHCPv6 to get home 1610 agent provisioning from an MSP or ASP, as already defined in [ID- 1611 BOOTINT]. The only requirement is that the DHCPv6 response must 1612 include multiple home agents' information in order to support home 1613 agent reliability. 1615 9.4.2. IKE/IPsec pre-establishment to Home Agents 1617 After a mobile node obtains multiple home agent addresses, it needs 1618 to trigger multiple IKE exchanges with the multiple home agents 1619 selected from the home agent list. Since both IKEv1 and IKEv2 can be 1620 used to bootstrap Mobile IPv6, this solution does not introduce any 1621 new operations to co-operate with IKEv1 or IKEv2. It should initiate 1622 IKE for home agents as soon as home registration is complete. 1624 The mobile node MUST follow the standard IKEv2 exchange in the 1625 bootstrapping solution of the split scenario [RFC-5026]. Home 1626 Address configuration maybe also be included, if necessary, for the 1627 first IKE exchange. After its Home Address is assigned or approved 1628 by the first home agent, mobile node SHOULD register itself with the 1629 second home agent with IKE using the same Home Address. Therefore, 1630 no home address configuration should be used in the second IKEv2 1631 procedure. Note that the mobile node only sends a Binding Update 1632 message to the first home agent. 1634 9.4.3. Receiving Home Agent Switch message 1636 A mobile node must follow the operation specified in [RFC-5142] when 1637 it receives a Home Agent Switch message. 1639 If the I-flag is set in the received Home Agent Switch message, the 1640 mobile node MUST re-key the SA with the home agent addresses stored 1641 in the Home Agent Addresses field. The mobile node MUST NOT change 1642 its active home agent when the I-flag is set. If the home agent 1643 address is not known from the bootstrapping described in 1644 Section 9.4.1, the mobile node MUST NOT start an IKE session with the 1645 unknown home agent. Instead, it SHOULD re-start home agent discovery 1646 again to update its home agent address information. 1648 When the mobile node receives a Home Agent Switch message without 1649 I-flag set, and if the message contains the IPv6 address of a standby 1650 home agent, it MUST select the standby home agent in the switch 1651 message as the active home agent and send a new Binding Update 1652 message to it. Note that the standby home agent address in the Home 1653 Agent Switch MUST be equal to the sender of the Home Agent Switch 1654 message. The standby Home agent expects the Binding Update as an 1655 acknowledgment of the Home Agent Switch message. The mobile node 1656 already has a pre-established SA with the standby home agents and 1657 should use that SA to send the Binding Update. If the address stored 1658 in the Home agent address field is different from the sender, the 1659 mobile node MUST send a binding update to the sender. 1661 10. Security Considerations 1663 Since Mobile IPv6 operation requires ESP in transport mode between 1664 the mobile node and the home agent, we will discuss the ESP field 1665 synchronization issues between the mobile node and the redundant set 1666 of home agents. This synchronization is required only for Home Agent 1667 Virtual Switch mode. Most of fields should be synchronized based on 1668 [RFC-4301]. The ESP header has the following fields: 1670 SPI 1672 This field identifies the SAD at the receiver. 1674 The mobile node negotiates only one IPsec SA. Hence, the SPI 1675 value will remain unchanged upon home agent failover. 1677 Sequence Number 1679 This field is used for "anti-replay" feature of ESP. The 1680 transmitter must include this monotonically increasing number. 1681 The receiver may process the sequence number based on local 1682 policy. 1684 The mobile node and the redundant home agent set will have the 1685 same set of sequence numbers for transmit and receive. Hence, 1686 synchronization of the sequence number field is mandatory in this 1687 mode of operation. 1689 The SA1, SA2, SA3, SA4 could be synchronized between the home 1690 agents as these messages are not sent continuously. Moreover for 1691 the Binding Update case, if the mobile node is in the middle of 1692 sending a Binding Update to an active home agent for a binding 1693 refresh, and the active home agent is not available at that 1694 moment, the mobile node will not get any response from the active 1695 home agent. After a standby home agent becomes active, the mobile 1696 node will retry and it will receive the Binding Update from the 1697 mobile node with a sequence number that is +n from its last known 1698 sequence number for SA1. For the Binding Acknowledgment case 1699 (SA2), the standby home agent SHOULD add a random number to the 1700 last known sequence number over and above the replay window to 1701 ensure that the packet passes the replay check at the mobile node. 1702 The same applies to HoTi and HoT messages with SA3 and SA4. Note 1703 that this windowing of the sequence numbers for Mobile IPv6 1704 signaling is only needed to cover the corner cases when Binding 1705 Update or HoTi is in-flight and the active home agent fails. 1707 The technique explained above should work for user data packets if 1708 ESP is used to encrypt user data traffic as well. The actual 1709 switchover time and the routing infrastructure convergence time is 1710 the only latency that the user may perceive. 1712 Initialization Vector 1714 Since the Initialization Vector will be delivered in each exchange 1715 between a mobile node and home agent, this field is not 1716 necessarily synchronized between home agents. 1718 Others 1720 Other fields should be synchronized based on RFC4301 [RFC-4301] 1722 In the Home Agent Hard Switch mode, the standby home agent needs to 1723 send a Home Agent Switch message using IPsec encryption. Since the 1724 mobile node has pre-established an IPsec SA with both the active and 1725 standby home agents, the standby home agent can send the message to 1726 the mobile node with the pre-established IPsec SA. 1728 11. Protocol Constants 1730 INITIAL_STATE_SYNC_REQ_TIMER: 3sec 1732 INITIAL_SWICHOVER_REQ_TIMER: 1sec 1734 INITIAL_SWICHBACK_REQ_TIMER 1sec 1736 LINK_TRAVERSAL_TIME 150msec 1738 12. IANA Considerations 1740 o The values for following mobility header message MUST be assigned 1741 by IANA. 1743 * State Synchronization Message 1745 * Home Agent Control Message 1747 * Home Agent Hello Message 1749 * Home Agent Switch Message 1751 o The values for following mobility options MUST be assigned by 1752 IANA. 1754 1. Binding Cache Information Option 1756 2. AAA Information Option 1758 o New Option Code for the IP address option defined in [RFC-5268] 1760 13. Additional Authors 1762 This document is a result of discussions in the Mobile IPv6 Home 1763 Agent Reliability Design Team. The members of the design team that 1764 are listed below are authors that have contributed to this document: 1766 Samita Chakrabarti 1768 samita.chakrabarti@azairenet.com 1770 Kuntal Chowdhury 1772 kchowdhury@starentnetworks.com 1774 Hui Deng 1776 denghui@chinamobile.com 1778 Vijay Devarapalli 1780 vijay.devarapalli@azairenet.com 1782 Sri Gundavelli 1784 sgundave@cisco.com 1786 Brian Haley 1788 brian.haley@hp.com 1790 Behcet Sarikaya 1792 bsarikaya@huawei.com 1794 Ryuji Wakikawa 1796 ryuji@sfc.wide.ad.jp 1798 14. Acknowledgements 1800 This document includes a lot of text from [ID-LOCALHAHA] and [ID- 1801 HAHA]. Therefore the authors of these two documents are 1802 acknowledged. We would also like to thank the authors of the home 1803 agent reliability problem statement [ID-PS-HARELIABILITY] for 1804 describing the problem succinctly and Alice Qin for her work on the 1805 hello protocol. 1807 15. References 1809 15.1. Normative References 1811 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1812 Requirement Levels", BCP 14, RFC 2119, March 1997. 1814 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1815 IPv6", RFC 3775, June 2004. 1817 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1818 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1819 January 2005. 1821 [RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC 1822 5094, October 2007. 1824 [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message", 1825 RFC-5142, November 2007. 1827 [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split 1828 scenario", RFC 5026, October 2007. 1830 [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via 1831 DHCPv6 for the Integrated Scenario", 1832 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), 1833 April 2008. 1835 15.2. Informative References 1837 [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1838 RFC 3768, April 2004. 1840 [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot 1841 Standby Router Protocol (HSRP)", RFC 2281, March 1998. 1843 [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1844 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", 1845 RFC 3776, June 2004. 1847 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 1848 Internet Protocol", RFC 4301, December 2005. 1850 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1851 RFC 3753, June 2004. 1853 [RFC-5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 1854 2008. 1856 [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", 1857 draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. 1859 [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", 1860 draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. 1862 [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent 1863 Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), 1864 February 2004. 1866 Appendix A. Change Log From Previous Versions 1868 Changes from draft-ietf-mip6-hareliability-03 1870 o Only Editorial Update and No Technical Change 1872 Author's Address 1874 Ryuji Wakikawa 1875 Toyota ITC 1876 6-6-20 Akasaka, Minato-ku 1877 Tokyo 107-0052 1878 Japan 1880 Phone: +81-3-5561-8276 1881 Fax: +81-3-5561-8292 1882 Email: ryuji@jp.toyota-itc.com 1884 Full Copyright Statement 1886 Copyright (C) The IETF Trust (2008). 1888 This document is subject to the rights, licenses and restrictions 1889 contained in BCP 78, and except as set forth therein, the authors 1890 retain all their rights. 1892 This document and the information contained herein are provided on an 1893 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1894 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1895 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1896 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1897 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1900 Intellectual Property 1902 The IETF takes no position regarding the validity or scope of any 1903 Intellectual Property Rights or other rights that might be claimed to 1904 pertain to the implementation or use of the technology described in 1905 this document or the extent to which any license under such rights 1906 might or might not be available; nor does it represent that it has 1907 made any independent effort to identify any such rights. Information 1908 on the procedures with respect to rights in RFC documents can be 1909 found in BCP 78 and BCP 79. 1911 Copies of IPR disclosures made to the IETF Secretariat and any 1912 assurances of licenses to be made available, or the result of an 1913 attempt made to obtain a general license or permission for the use of 1914 such proprietary rights by implementers or users of this 1915 specification can be obtained from the IETF on-line IPR repository at 1916 http://www.ietf.org/ipr. 1918 The IETF invites any interested party to bring to its attention any 1919 copyrights, patents or patent applications, or other proprietary 1920 rights that may cover technology that may be required to implement 1921 this standard. Please address the information to the IETF at 1922 ietf-ipr@ietf.org. 1924 Acknowledgment 1926 Funding for the RFC Editor function is provided by the IETF 1927 Administrative Support Activity (IASA).