idnits 2.17.1 draft-ietf-mip6-hareliability-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 13, 2009) is 5401 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 normative reference: RFC 4282 (Obsoleted by RFC 7542) -- 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 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 13, 2009 5 Expires: January 14, 2010 7 Home Agent Reliability Protocol 8 draft-ietf-mip6-hareliability-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 14, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The home agent can be a single point of failure when Mobile IPv6 is 47 operated in a system. It is critical to provide home agent 48 reliability in the event of a home agent crashing or becoming 49 unavailable. This would allow another home agent to take over and 50 continue providing service to the mobile nodes. This document 51 describes the problem scope briefly and provides a mechanism of home 52 agent failure detection, home agent state transfer, and home agent 53 switching for home agent redundancy and reliability. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Problem Statement and Requirements . . . . . . . . . . . . . . 6 63 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 8 65 4.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 9 66 4.3. Home Agent Management . . . . . . . . . . . . . . . . . . 10 68 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. New Mobility Header Messages . . . . . . . . . . . . . . . 11 70 5.1.1. State Synchronization Message . . . . . . . . . . . . 11 71 5.1.2. Home Agent Control Message . . . . . . . . . . . . . . 13 72 5.1.3. Home Agent Hello Message . . . . . . . . . . . . . . . 15 73 5.1.4. Home Agent Rekey Message . . . . . . . . . . . . . . . 17 74 5.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 17 75 5.2.1. IP address Option . . . . . . . . . . . . . . . . . . 18 76 5.2.2. Binding Cache Information Option . . . . . . . . . . . 18 77 5.2.3. AAA Information Option . . . . . . . . . . . . . . . . 19 79 6. Home Agent Configuration . . . . . . . . . . . . . . . . . . . 20 80 6.1. Network Configuration . . . . . . . . . . . . . . . . . . 20 81 6.2. Address Configuration for Virtual Switch . . . . . . . . . 21 82 6.3. Address Configuration for Hard Switch . . . . . . . . . . 21 84 7. Home Agent Common Operation . . . . . . . . . . . . . . . . . 22 85 7.1. Home Agent List Management . . . . . . . . . . . . . . . . 22 86 7.2. Detecting Home Agent Failure . . . . . . . . . . . . . . . 22 87 7.3. Processing Hello Messages . . . . . . . . . . . . . . . . 23 88 7.3.1. Requesting Hello Message . . . . . . . . . . . . . . . 24 89 7.3.2. Sending Hello Message . . . . . . . . . . . . . . . . 24 90 7.3.3. Receiving Hello Message . . . . . . . . . . . . . . . 25 92 7.4. Processing State Synchronization Messages . . . . . . . . 26 93 7.4.1. Requesting State of a Particular Mobile Node(s) . . . 26 94 7.4.2. Synchronizing State . . . . . . . . . . . . . . . . . 27 95 7.4.3. Reliable Transmission by Explicit Acknowledgement . . 28 96 7.5. Processing Home Agent Control Messages . . . . . . . . . . 29 97 7.5.1. Standby Home Agent becomes an Active Home Agent . . . 29 98 7.5.2. Active Home Agent becomes inactive . . . . . . . . . . 30 99 7.6. Interworking with VRRP . . . . . . . . . . . . . . . . . . 31 100 7.7. Retransmissions and Rate Limiting . . . . . . . . . . . . 32 102 8. Home Agent Virtual Switch . . . . . . . . . . . . . . . . . . 34 103 8.1. Consideration of Routing and Neighbor Discovery 104 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 34 105 8.2. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 34 107 9. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . . . 35 108 9.1. Home Agent Recovery . . . . . . . . . . . . . . . . . . . 35 109 9.2. Sending Home Agent Switch Messages . . . . . . . . . . . . 35 110 9.3. Sending Home Agent Rekey Messages . . . . . . . . . . . . 36 111 9.4. Notification of Home Agent Switch Completion . . . . . . . 36 112 9.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 36 113 9.5.1. Home Agent Addresses Discovery . . . . . . . . . . . . 36 114 9.5.2. IKE/IPsec pre-establishment to Home Agents . . . . . . 37 115 9.5.3. Synchronizing State: K-bit treatment . . . . . . . . . 37 116 9.5.4. Receiving Home Agent Switch message . . . . . . . . . 38 117 9.5.5. Receiving Home Agent Rekey message . . . . . . . . . . 38 119 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 121 11. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 42 123 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 125 13. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 44 127 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 129 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 130 15.1. Normative References . . . . . . . . . . . . . . . . . . . 45 131 15.2. Informative References . . . . . . . . . . . . . . . . . . 45 133 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 135 1. Introduction 137 In Mobile IPv6 [RFC-3775] and NEMO Basic Support [RFC-3963], if a 138 home agent loses the binding cache state, due to failure or some 139 other reason, it results in a loss of service for the mobile nodes. 140 It is beneficial to provide high availability and redundancy for a 141 home agent so that mobile nodes can avail of uninterrupted service 142 even when one home agent crashes or loses state. The Home Agent 143 Reliability protocol is designed to synchronize the Mobile IPv6 144 states between active and standby home agents as VRRP[RFC-3768] or 145 HSRP [RFC-2281]. A home agent maintains not only binding cache but 146 also IPsec and IKE related states per mobile node. Mobile IPv6 147 mandates IPsec encryption for signaling of home binding registration 148 (BU and BA) and return routability (HoTI and HoT) as described in 149 [RFC-3776]. However, IPsec states synchronization is out of scope in 150 this document. The scope of Home Agent Reliability protocol is 151 limited to the management of Mobile IPv6 related states. Thus, we 152 define two different approaches such as Home Agent Virtual Switch and 153 Home Agent Hard Switch depending on the capability of IPsec state 154 synchronization. In both cases, a mobile node maintains only one 155 home binding at any given time. 157 Home Agent Virtual Switch 159 The Home Agent Virtual Switch operation can be used only if IPsec 160 state synchronization mechanism is available (outside of Home 161 Agent Reliability Protocol). The IPsec state per mobile node MUST 162 be shared between the active home agent and standby home agents in 163 the background. The active and the standby home agents are 164 addressed by the same home agent address, although only the active 165 home agent is accessible with the home agent address. Each mobile 166 node negotiates just one Security Association with the active home 167 agent. In case there is a failure of the active home agent, the 168 standby home agent takes over without the mobile node being aware 169 of the change in the home agent. 171 Home Agent Hard Switch 173 In the Home Agent Hard Switch, IPsec/IKE states synchronization is 174 not required. The home agents are addressed by different IP 175 addresses. When an active home agent fails, a mobile node will 176 receive a notification (Home Agent Switch message [RFC-5142]) from 177 a standby home agent, and send a Binding Update to the standby 178 home agent. In order for the mobile node to receive the Home 179 Agent Switch message securely from the standby home agent, the 180 mobile node needs to establish an IPsec SA with both the active 181 and the standby home agents beforehand. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC-2119]. 189 In this document, the term mobile node refers to both a mobile node 190 [RFC-3775] and a mobile router [RFC-3963]. 192 Mobility related terms used in this document are defined in [RFC- 193 3775] and [RFC-3753]. In addition or in replacement of these, the 194 following terms are defined or redefined: 196 Active Home Agent 198 A home agent that is currently serving the mobile nodes. 200 Standby Home Agent 202 A home agent which will serve the mobile nodes when the active 203 home agent fails. 205 Failed Home Agent 207 A home agent that is not available due to hardware or software 208 failure, system maintenance, etc. 210 Redundant Home Agent Set 212 A group of active and standby home agent(s). The Group Identifier 213 is used to identify a redundant home agent set. 215 Virtual Home Agent Address 217 A home agent address shared among home agents in a redundant home 218 agent set and used only in the Home Agent Virtual Switch case. 219 The address is only activated on an active home agent. 221 Home Agent Preference 223 This preference value is originally defined for Dynamic Home Agent 224 Address Discovery (DHAAD) in RFC3775. This protocol re-uses this 225 preference value for home agent selection when an active home 226 agent has failed. However, an operator can also define an 227 independent value used only for the home agent reliability 228 protocol if the operator wants to have different preference values 229 for DHAAD and the home agent reliability protocol. A home agent 230 SHOULD NOT use the same preference value of other home agents. 232 3. Problem Statement and Requirements 234 In Mobile IPv6 [RFC-3775], a mobile node registers and establishes a 235 binding with only one home agent. Thus the home agent represents the 236 possibility of a single point of failure for Mobile IPv6. A home 237 agent is responsible for multiple mobile nodes on its home link. The 238 failure of the home agent may then result in the loss of connectivity 239 for numerous mobile nodes located throughout the Internet. To 240 overcome this problem, Mobile IPv6 allows deployment of multiple home 241 agents on the home link so that upon the failure of a home agent, a 242 mobile node can re-establish its connection through a new home agent. 243 However, the base Mobile IPv6 specification does not address home 244 agent failover and dynamic transfer of service from one home agent to 245 another. This transfer of service from the failed home agent to a 246 new active home agent requires coordination or pre-configuration 247 among the home agents regarding security associations, transfer of 248 mobile node bindings, and other service information for reliable 249 Mobile IPv6 service in a deployment scenario. 251 For the home agent reliability solution, we define the following 252 requirements: 254 Reliable Home agent service 256 Multiple home agents are available for a home prefix and one of 257 them actively serves the mobile nodes. A standby home agent takes 258 over when the active home agent becomes unavailable. The transfer 259 of the MN-HA association should be transparent to applications and 260 should not take longer than the care-of-addresses update procedure 261 described in Mobile IPv6 [RFC-3775]. 263 Availability of a redundant home agent set 265 Availability of an active home agent address and a standby home 266 agent address at the bootstrapping period for the mobile node is 267 assumed. 269 State Synchronization 271 The information for mobile nodes must be able to be synchronized 272 between an active home agent and standby home agents. This 273 includes the Binding Cache, AAA information, other Mobile IPv6 and 274 NEMO related information. Note that the Home Agent Reliability 275 protocol exchanges only running states of mobile nodes. 276 Therefore, we do not have any specific operation for synchronizing 277 the configuration information. For instance, when Mobile IPv6 is 278 operated with Authentication protocol, synchronizing the 279 configurations of the Authentication protocol is out of scope in 280 this document. Operators MAY correctly set the configuration 281 information in multiple home agents. 283 Consideration of IPsec/IKE transfer 285 An active home agent maintains several IPsec and IKE states for 286 mobile nodes. These states are synchronized within the redundant 287 home agent set. The details are described in Section 10. 289 Secured Message Exchanges 291 The messages used between the home agents to transfer binding 292 cache information MAY be authenticated and encrypted. 294 Failure Detection 296 Redundant home agents must actively check for possible failure of 297 an active home agent. If a home agent supports an existing 298 failure detection mechanism such as VRRP[RFC-3768] or HSRP [RFC- 299 2281], it can re-use that mechanism to detect the home agent 300 failure. On the other hand, periodic Hello messages are 301 introduced to detect active home agent's service availability in 302 this document. 304 Failure Notification 306 If necessary, a mobile node is notified about the active home 307 agent failure by the standby home agent. 309 4. Protocol Overview 311 4.1. Home Agent Virtual Switch 313 A mobile node remains unaware about the change in the active home 314 agent since the home agents have replicated all session state 315 including IPsec/IKE states. IPsec/IKE state transfer is out of scope 316 of this document. 318 MN HA1(active) HA2(Standby) 319 | | . 320 |<--------->| | 1. IKE exchange (with HoA assignment) 321 |---------->| . 2. Binding Update 322 |<----------| . 3. Binding Acknowledgment 323 | | . 324 | |<--------->. 4. State exchanges (binding cache/IPsec) 325 | | . 326 | X . HA1 FAILURE 327 | X . 328 | X<----------. 5. Failure Detection 329 | X | 6. HA2 takes over the HA1 330 | X | 331 | X | RECOVERY COMPLETE 333 Figure 1: Overview of Home Agent Virtual Switch 335 The operations of the Home Agent Virtual Switch mode are shown in 336 Figure 1. A mobile node first attempts the IKE exchange for Security 337 Association (SA) setup and home address assignment (1). After 338 binding registration is done (2, 3), the active home agent pushes all 339 the states of its mobile nodes with a state synchronization message 340 (4). The standby home agent(s) is not active unless it takes over 341 from a failed home Agent. 343 When the active home agent's failure is detected (5), the standby 344 home agent activates the virtual home agent address on its interface 345 and takes over for the failed home agent. All the home agents in the 346 redundant home agent set share a virtual home agent address and the 347 routing will ensure only the active home agent will be reachable 348 using that virtual home agent address. The standby home agent can 349 serve all the mobile nodes for which the states are synchronized, 350 without any further message exchange, because it has all the 351 necessary information which it obtained from the failed home agent. 353 4.2. Home Agent Hard Switch 355 The overview of the Home Agent Hard Switch is shown in Figure 2. 356 This mode is not transparent to the mobile node when the active home 357 agent failure occurs. 359 MN HA1(active) HA2(Standby) 360 | | | 361 |<--------->| | 1. IKE exchange (with HoA assignment) 362 |---------->| | 2. Binding Update 363 |<----------| | 3. Binding Acknowledgment 364 |<--------------------->| 4. IKE exchange (without HoA assignment) 365 | | | 366 | |<--------->. 5. State exchanges (binding cache) 367 | | | 368 | X | HA1 FAILURE 369 | X | 370 | X<----------| 6. Failure Detection 371 |<----------------------| 7. Sending Home Agent 372 | X | Switch message 373 |<--------------------->| 8. Binding Registration 374 | X | 375 | X | RECOVERY COMPLETE 377 Figure 2: Overview of Home Agent Hard Switch 379 The mobile node establishes IPsec/IKE state with all the home agents 380 in the redundant home agent set beforehand (1 and 4), however it 381 registers its binding only with the active home agent (2 and 3). 382 When an active home agent fails, a standby home agent uses a pre- 383 existing IPsec SA to notify the mobile node about the failure by 384 securely sending a Home Agent Switch message. In order to discover 385 home agent addresses, two different mechanisms are defined, as 386 described in Section 9.5.1. The active home agent synchronizes the 387 required states of the mobile nodes, such as Binding Cache and AAA 388 information, with other standby home agents periodically (5). The 389 mobile node MUST NOT request a home address(es) assignment through 390 the IKE exchange to the standby home agent when it establishes an SA 391 with it (4). 393 When the standby home agent detects the failure of the active home 394 agent (6), it sends a Home Agent Switch message to all the mobile 395 nodes that were registered with the failed home agent (7). The Home 396 Agent Switch message must be encrypted by a pre-established IPsec SA. 397 After the switch message, the mobile node MUST send a binding update 398 to the new active home agent in order to update the Mobile IPv6 399 tunnel endpoints (8). 401 4.3. Home Agent Management 403 HA1(active) HA2 HA3 .. HAn 404 | | | | 405 |------->| | | 1. HA1 sends SwitchBack Request 406 |<-------| | | 2. HA2 sends SwitchBack Reply 407 | | | | 408 |<-------| | | 3. HA2 sends SwitchCompl (optional) 409 (standby) (active) | | HA2 BECOMES ACTIVE HA 410 | | | | 411 SYSTEM MAINTENANCE, ETC. 412 | | | | 413 |------->| | | 4. HA1 sends SwitchOver Request 414 |<-------| | | 5. HA2 sends SwitchOver Reply 415 | | | | 416 |------->| | | 6. HA1 sends SwitchCompl (optional) 417 (active) (standby) | | 7. HA1 returns to active HA 418 | | | | HA1 BECOMES ACTIVE AGAIN 420 Figure 3: Manual Home Agent Change 422 In some scenarios the active home agent may need to stop serving 423 mobile nodes for system maintenance. This specification provides for 424 a manual home agent switch by using SwitchBack Request and Reply 425 messages. As shown in Figure 3, the active home agent (HA1) sends a 426 SwitchBack Request message to a standby home agent (HA2). As soon as 427 HA2 receives the message, it becomes the active home agent. HA2 will 428 acknowledge the message by sending a SwitchBack Reply message to HA1. 429 HA1 becomes a standby home agent when it receives the SwitchBack 430 Reply. After the downtime, HA1 sends a SwitchOver Request to HA2 in 431 order to become the active home agent again. 433 The SwitchCompl message is used only in the Home Agent Hard Switch. 434 As shown in Section 9, it takes certain time to complete the home 435 agent switch. Thus, the old active home agent continues serving the 436 received packets for the mobile nodes during the switch process. As 437 soon as the new home agent completes the recovery, it sends 438 SwitchCompl message to the previous active home agent. SwitchCompl 439 is an optional operation in this specification. 441 5. Messages 443 5.1. New Mobility Header Messages 445 5.1.1. State Synchronization Message 447 This message is used to exchange state corresponding to a particular 448 mobile node(s). It MUST be unicasted and MUST be authenticated by 449 IPsec ESP. This message has the MH Type value TBD. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type |A| Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Identifier | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 458 . . 459 . Mobility Options . 460 . . 461 . | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 4: State Synchronization Message 466 Type 468 8-bit unsigned integer. It can be assigned one of the following 469 values: 471 0: Request 473 This message is called State Synchronization Request (SS-REQ) 474 and used to solicit the active state corresponding to a 475 particular mobile node. 477 1: Reply 479 The message is called State Synchronization Reply (SS-REP) and 480 is used between the home agents in the redundant home agent set 481 to exchange binding cache information and any other information 482 related to providing mobility service to the mobile nodes 483 either periodically or in response to a SS-REQ. 485 2: Reply-Ack 487 The message is called State Synchronization Reply-Ack (SS-ACK) 488 and is used to acknowledge the SS-REP. This message is 489 optional and is specially used when the links between home 490 agents are not reliable. 492 Ack flag 494 This flag is valid only for SS-REP. If the sender requires 495 explicit acknowledgment by SS-ACK, it MUST set this flag. 497 Reserved 499 This field is unused. It MUST be initialized to zero by the 500 sender and MUST be ignored by the receiver. 502 Identifier 504 A 16-bit identifier to aid in matching state synchronization 505 message. The identifier should never be set to 0. It should 506 always be more than 1. 508 Mobility Options 510 Variable-length field of such length that the complete Mobility 511 Header is an integer multiple of 8 octets long. This field 512 contains zero or more TLV-encoded mobility options. The encoding 513 and format of defined options are described in [RFC-3775]. The 514 receiver MUST ignore and skip any options which it does not 515 understand. This message requires at least one mobility option, 516 therefore, there is no default length for this message. 518 One of the following options is mandatory in SS-REQ message. 519 Multiple same options can be stored in the same SS-REQ message, 520 (ex. two IP address options for two mobile nodes): 522 * IP Address Option (Sub-type: Home Address) defined in [RFC- 523 5268]. If a home agent wants the Binding Cache information for 524 a particular mobile node, it includes the mobile node's home 525 address in an IPv6 Address Option. If a home agent wants to 526 solicit all the active mobile nodes' states, it can include the 527 unspecified address (::) in an IPv6 address option. 529 * Mobile Network Prefix Option. If a home agent wants to know 530 the forwarding state setup for a particular Mobile Network 531 Prefix, it includes a Mobile Network Prefix Option as defined 532 in [RFC-3963]. 534 * The Mobile Node Identifier option defined in [RFC4283]. If a 535 home agent wants the Binding Cache information for a particular 536 mobile node, it can include the mobile node's identifier (ex. 537 Network Access Identifier (NAI) [RFC4282]) in this option. 539 * Vendor Specific Mobility Option. If a home agent wants vendor 540 specific information, it can solicit with this option as 541 defined in [RFC-5094]. 543 One of the following options is mandatory in SS-REP: 545 * Binding Cache Information Option 547 * AAA Information Option 549 * Vendor Specific Mobility Option 551 5.1.2. Home Agent Control Message 553 This message is used to control the status of a home agent to either 554 active or standby. This message MUST be unicasted between home 555 agents and MUST be authenticated and encrypted by IPsec ESP. The 556 Home Agent Control message has the MH Type value TBD. If no options 557 are present in this message, no padding is necessary and the Header 558 Len field will be set to 1. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Status | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 . . 566 . Mobility Options . 567 . . 568 . | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 5: Home Agent Control Message 573 Type 575 8-bit unsigned integer. It can be assigned one of the following 576 values: 578 0: SwitchOver Request (SO-REQ) 580 It is unicasted by a standby home agent that desires to become 581 the active home agent. The receiver of the message MUST 582 transition to standby state as soon as the message is received 583 and validated successfully. 585 1: SwitchOver Reply (SO-REP) 587 It is used to acknowledge the receipt of the corresponding SO- 588 REQ. 590 2: SwitchBack Request (SB-REQ) 592 It is unicasted by an active home agent that desires to become 593 a standby home agent. The receiver of this message SHOULD 594 transition to active state as soon as the message is received 595 and validated successfully. 597 3: SwitchBack Reply (SB-REP) 599 It is used to acknowledge the receipt of the corresponding SB- 600 REQ. 602 4: Switch Complete (SW-COMP) 604 This message is used to indicate the completion of switch over, 605 (i.e. sending home agent switch messages and receiving binding 606 update messages from all the served mobile nodes). 608 Status 610 8-bit unsigned integer indicating the disposition of a SO-REQ or 611 SB-REQ. This field is only valid in SO-REP and SB-REP. The 612 following Status values are defined: 614 0: Success 616 128: Reason unspecified 618 129: Administratively prohibited 620 130: Not active home agent (The receiver of SO-REQ is not the 621 active home agent) 622 131: Not standby home agent (The receiver of SB-REQ is already 623 the active home agent) 625 132: Not in same redundant home agent set 627 Mobility Options 629 No options are defined in this specification 631 5.1.3. Home Agent Hello Message 633 The Home Agent Hello (HA-HELLO) message MUST be either unicasted or 634 multicasted to carry home agent information among the redundant home 635 agent set. The HA-Hello message is defined for two purpose: 1) an 636 alive check and 2) home agent information exchange. A HA-HELLO 637 SHOULD be authenticated and encrypted by IPsec ESP when it is 638 unicasted. If a HA-Hello message is multicasted, IPsec ESP cannot be 639 applied. In this case the redundant home agent set should be located 640 in a secure network. Alternatively, all the home agents MUST have a 641 secure channel with each other. The HA-Hello has the MH Type value 642 TBD. If no options are present in this message, 0 octets of padding 643 are necessary and the Header Len field will be set to 2. 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Sequence # | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Home Agent Preference | Home Agent Lifetime | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Hello Interval | Group ID |A|R| Reserved | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | | 655 . . 656 . Mobility Options . 657 . . 658 . | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Figure 6: Home Agent Hello Message 663 Sequence # 664 16-bit unsigned integer. The Sequence number of the HA-Hello 665 message can be used to verify whether this Hello message is the 666 latest one or not. 668 Home Agent Preference 670 16-bit unsigned integer. The preference for the home agent 671 sending the HA-Hello message. This preference is the same as the 672 Home Agent Preference value of the Home Agent Information option 673 as defined in [RFC-3775]. However, operators MAY use a different 674 preference value for this operation. 676 Home Agent Lifetime 678 16-bit unsigned integer. The lifetime for the home agent sending 679 the HA-Hello message. This lifetime is the same as the Home Agent 680 Lifetime value of the Home Agent Information option as defined in 681 [RFC-3775]. 683 Hello Interval 685 16-bit unsigned integer. The interval for the home agent sending 686 this Hello message. 688 Group Identifier 690 8-bit unsigned integer. This value is used to identify a 691 particular redundant home agent set. 693 A flag 695 Active Home Agent flag. If this flag is set, the sender of this 696 HA-Hello message is an active home agent. 698 R flag 700 HA-HELLO requesting flag. If this flag is set, the receiver of 701 this HA-Hello message must send back a HA-Hello message to the 702 sender. 704 Reserved 706 This field is unused. It MUST be initialized to zero by the 707 sender and MUST be ignored by the receiver. 709 Mobility Options 711 No valid options are defined in this specification. 713 5.1.4. Home Agent Rekey Message 715 This message is used to indicate that the mobile node SHOULD start an 716 IPsec re-key with the home agent specified in the Home Agent 717 Addresses field. This message is used when a failed home agent 718 recovers and needs to re-establish IPsec SA/IKE state with a mobile 719 node. This message MUST be unicasted to a mobile node by the active 720 home agent and MUST be authenticated and encrypted by IPsec ESP. The 721 Home Agent Rekey message has the MH Type value TBD. If no options 722 are present in this message, no padding is necessary and the Header 723 Len field will be set to 2. 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Reserved | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | | 731 + + 732 . Home Agent Addresses . 733 + + 734 | | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 . Mobility options . 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 7: Home Agent Rekey Message 741 Reserved 743 The reserved field is 16 bits 745 Home Agent Address 747 The receiver of this message MUST rekey the security asscoation 748 with the specified home agent. 750 5.2. New Mobility Options 751 5.2.1. IP address Option 753 This option is already defined in the Fast Handovers for Mobile IPv6 754 (FMIP) specification [RFC-5268]. This document introduces new Sub- 755 Type values for home agent address and Home Address. 757 Option-Code 759 * 4: Home Address 761 5.2.2. Binding Cache Information Option 763 The binding cache information option has an alignment requirement of 764 8n+2. The Binding Cache Information option is only valid in a State 765 Synchronization message. Its format is as follows: 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Type = TBD | Length = 40 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Flags | Sequence Number | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Lifetime | Reserved | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | | 777 + + 778 | Home Address | 779 + + 780 | | 781 + + 782 | | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 + + 786 | | 787 + Care-of Address + 788 | | 789 + + 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 . . 793 . . 794 . Mobile Network Prefix Option . 795 . . 796 . | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Figure 8: Binding Cache Information Option 800 The fields of Home Address, Care-of Address, Flags, Sequence Number, 801 and Lifetime are copied from the registered binding of a particular 802 mobile node or mobile router. The 16-bit Reserved field MUST be set 803 to zero. If the R-flag is set to indicate this binding cache entry 804 is for a mobile router, then this option will be immediately followed 805 by one or more Mobile Network Prefix options. 807 5.2.3. AAA Information Option 809 This option is used to carry the AAA state of the mobile node's 810 Mobile IPv6 sessions. The AAA state information can be carried in 811 RADIUS or Diameter AVP formats including the user and session info. 812 This information option is only valid in a State Synchronization 813 message. 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Type = TBD | Length | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 . . 821 . . 822 . AAA AVPs . 823 . . 824 . . 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Figure 9: Vendor Specific Information Option 829 Type 831 8-bit Type value. The value is TBD. 833 Length 835 8-bit length value. 837 AAA AVPs 839 Series of TLV encoded AAA AVPs (including vendor specific AVPs) 840 carrying AAA-related information for each Mobile IPv6 and IPsec/ 841 IKE session. 843 6. Home Agent Configuration 845 6.1. Network Configuration 847 The Home Agent Reliability protocol supports two different 848 configurations for standby home agents. Standby home agents can be 849 placed on the same home link or on a different link. 851 HA1 HA2 HA3 HA4 .... HAn 852 | | | | | 853 --------+------+------+------+--------+--------- 854 Home Link 856 Figure 10: Local Recovery Configuration 858 Figure 10 depicts the configuration where home agents serving the 859 same home network are located on the same link. For example, HA2, 860 HA3 and HA4 are standby home agents of HA1. This is the same as what 861 Mobile IPv6 defines for home agent configuration. 863 ---------IGP------>|<---BGP--->|<-----IGP--------- 865 HA1 HA2 HA3 HA4 866 | | | | 867 --------+------+-----+ R---R---R +-----+------+------- 868 Home Link Routers Recovery Link 869 (region-1) (region-2) 871 Figure 11: Global Recovery Configuration 873 Figure 11 illustrates when standby home agents are located on a 874 different link (illustrated as Recovery Link in Figure 11). Most 875 large operators have a very stringent requirement on network 876 availability even in the worst type of disaster or outage. For 877 example, HAs in region-1 are backed up by HAs in region-2. These two 878 regions are geographically separated. If region-1 suffers a downtime 879 due to any reason, all the sessions will be seamlessly taken over by 880 the nodes in region-2. This is called geographic redundancy. This 881 is a well-known configuration for Telecommunications operators. It 882 can achieve home agent recovery even if the entire home link fails. 883 In Figure 11, HA3 and HA4 are standby home agents of HA1 and HA2. In 884 this case, HA3 and HA4 cannot receive packets meant for the home 885 network until the route on the Routers is changed. The routing must 886 be also updated to direct the packets meant for the home link to the 887 recovery link. 889 6.2. Address Configuration for Virtual Switch 891 Each standby home agent obtains its individual IPv6 address from its 892 attached link. This IPv6 address is used by the home agent 893 reliability protocol to exchange information with the associated home 894 agents. The link between home agents should be secured. 896 The virtual home agent's IPv6 address which is known by the mobile 897 node is shared with the standby home agents. When a home agent 898 fails, the standby home agent activates the IPv6 address of the 899 failed home agent and becomes the active home agent. The standby 900 home agent should not activate the IPv6 address until it knows the 901 active home agent is no longer reachable at the address, otherwise 902 address duplication will occur. To guarantee transparency of the 903 home agent virtual switch to mobile nodes located on the home link, 904 the neighbor cache of the home agent IP address MUST be carefully 905 operated. See Section 8.1 in detail. 907 6.3. Address Configuration for Hard Switch 909 Each standby home agent obtains its individual IPv6 address from its 910 attached link. This IPv6 address is used by the home agent 911 reliability protocol to exchange information with the associated home 912 agents. The link between home agents should be secured. 914 Each home agent configures itself with a different IPv6 address from 915 the same home prefix. This IPv6 address can be used for the Home 916 Agent Reliability protocol if the standby home agents are located at 917 the same link of the active home agent (Figure 10). In case of 918 Figure 11, the router must carefully route packets to the standby 919 home agents as described in Section 8.1. Once a mobile node 920 registers its binding with the active home agent, it may solicit an 921 IPsec/IKE exchange with standby home agents. These packets must be 922 routed to the recovery link. This can be achieved by installing host 923 routes for the standby home agents on the recovery link of the 924 router. 926 7. Home Agent Common Operation 928 7.1. Home Agent List Management 930 In Mobile IPv6 [RFC-3775], each home agent periodically sends router 931 advertisements with the Home Address Information option [RFC-3775] 932 when there are multiple home agents present on a link. This 933 information is managed in a home agent list. For the Home Agent 934 Reliability Protocol, HA-HELLO messages are used to manage the home 935 agent list. There are several reasons to use HA-HELLO message 936 instead of Router Advertisement such as: 938 1. In the Home Agent Virtual Switch mode, if the standby home agents 939 send unsolicited Router Advertisements to the home link, the 940 mobile nodes attached to the home link are aware of the presence 941 of standby home agents. However, the standby home agents must be 942 hidden until the active home agent fails. HA-Hello messages are 943 exchanged only between home agents. 945 2. As shown in Section 6.1, standby home agents are not always 946 configured at the same link. In this case, Router Advertisements 947 cannot be sent to the recovery link unless the home link and the 948 recovery link are connected (ex. L2TP). HA-HELLO can be sent 949 beyond the link. 951 3. The Home Agent Reliability protocol is defined to manage 952 additional information such as Group ID and Active/Standby Status 953 of the home agents in the home agent list. 955 In Mobile IPv6, Router Advertisement are to carry the home agent 956 information to both mobile nodes on the home link and the home 957 agents. On the other hand, in the Home Agent Reliability protocol, 958 HA-Hello is to exchange the information among the home agents and the 959 Router Advertisement is used to notify the information to the mobile 960 nodes on the home link. The home agents SHOULD NOT process the Home 961 Agent Information option carried by Router Advertisement if HA-HELLO 962 is available. Operators can define different values to the 963 parameters of the home agent information for HA-HELLO and Router 964 Advertisement. The management operation of the home agent list is 965 unchanged and defined in [RFC-3775]. 967 7.2. Detecting Home Agent Failure 969 The active and standby home agents can monitor each other in several 970 ways. One method is to reuse other failure detection mechanisms 971 defined in VRRP[RFC-3768] and HSRP [RFC-2281] (see Section 7.6). 972 However, VRRP and HSRP cannot detect the case where the system is 973 running but the Mobile IPv6 stack is not operational. In the Home 974 Agent Reliability protocol, a new message called HA-HELLO is 975 periodically exchanged in the redundant home agent set as a heart- 976 beat. If HA-HELLO is implemented as a part of Mobile IPv6 stack, it 977 can detect the home agent failure (Mobile IPv6 stack failure). This 978 HA-HELLO can also be exchanged frequently enough to detect the 979 failure promptly and does not introduce any processing overhead to 980 the mobile node attached to the home link. 982 Failure events used in the Home Agent Reliability protocol are listed 983 below. 985 Loss of HA-HELLO 987 In the event that a standby home agent does not receive any HA- 988 HELLO from its peer which is currently the active home agent for a 989 configurable duration, the standby home agent assumes the active 990 home agent's failure. Any home agents can also request the home 991 agent information of the other home agent in the same redundant 992 home agent set by sending HA-HELLO with R-flag set. If HA-HELLO 993 is not replied from the target home agent within a configurable 994 amount of time, that home agent peer is considered to have failed. 995 The detail of the Hello message is described in Section 7.3. 997 Monitored Server Failure by the Active Home Agent 999 There may be number of critical servers such as AAA server in the 1000 network that are essential for the ongoing Mobile IPv6 sessions at 1001 the home agent. Operators can have a policy in place that the 1002 active home agent is treated as a failed home agent upon detecting 1003 that the link to such servers has failed. 1005 Routing Peer/Link Failure 1007 Operators may require the home agent to detect its next-hop 1008 routing peer failure. If the next-hop routing failure is fatal in 1009 nature, or due to some other routing policies, the active home 1010 agent is treated as a failed home gent and the recovering 1011 operation should be started. 1013 7.3. Processing Hello Messages 1015 HA-HELLO MUST be either unicasted or multicasted. A new multicast 1016 address (all_homeagent_multicast_address) will be assigned by the 1017 IANA. When all the home agents in a redundant home agent set are 1018 configured on a same home link, they MUST join the 1019 all_homeagent_multicast_address. On the other hand, if a home 1020 recovery link is separately defined as described in Figure 11, each 1021 home agent SHOULD unicast HA-HELLO. 1023 7.3.1. Requesting Hello Message 1025 A home agent can solicit HA-HELLO to a particular home agent in the 1026 same redundant home agent set by unicasting HA-HELLO with the R-flag 1027 set. The sender MUST fill the fields of the HA-HELLO with its home 1028 agent information. If a home agent needs to request HA-HELLO to all 1029 the home agents, it sends the HA-HELLO with R-flag set to the 1030 all_homeagent_multicast_address. Requesting HA-HELLO SHOULD be 1031 operated when: 1033 1. A new home agent needs to collect the information of all the 1034 other home agents in the same redundant home agent set. The HA- 1035 HELLO with R-flag set is multicasted to 1036 all_homeagent_multicast_address. 1038 2. A home agent entry in the redundant home agent list is about to 1039 be removed due to home agent lifetime expiration. The HA-HELLO 1040 with R-flag set is unicasted to the home agent whose lifetime is 1041 soon expired. 1043 3. HA-HELLO has not been received during the specified hello 1044 interval. The HA-HELLO with R-flag set is unicasted to the 1045 target home agent. 1047 7.3.2. Sending Hello Message 1049 Each home agent periodically sends HA-HELLO for the home agent's 1050 failure detection. The interval time is configured at each home 1051 agent. Each home agent MUST also send a HA-HELLO in following case: 1053 1. when a home agent receives a HA-HELLO with the R-flag set 1055 2. When a home agent detects its local information such as home 1056 agent preference, home agent lifetime, and registration status 1057 change. 1059 3. When a new home agent boots up, it SHOULD solicit Hello messages 1060 by multicasting a Hello message with the R-flag set in parallel 1061 with sending its own Hello message. 1063 When a home agent sends HA-HELLO, the following rule MUST be applied. 1065 o Whenever a home agent generates HA-HELLO, it MUST increment the 1066 Sequence Number. The Sequence Number SHOULD be initialized to 1067 zero for the first Hello message. To accomplish sequence number 1068 rollover, if the sequence number has already been assigned to be 1069 the largest possible number representable as a 16-bit unsigned 1070 integer, then when it is incremented it will then have a value of 1071 zero (0). 1073 o It MUST also specify its own Group ID in HA-HELLO. 1075 o If a home agent is the active home agent, it MUST set the A-flag 1076 in HA-HELLO. 1078 o In the Home Agent Hard Switch mode, the source IPv6 address of HA- 1079 HELLO MUST be the home agent address. 1081 o In the Home Agent Virtual Switch mode, the home agent local 1082 address MUST be used. 1084 7.3.3. Receiving Hello Message 1086 When a home agent receives HA-HELLO, it SHOULD verify the HA-HELLO as 1087 follows: 1089 o If the HA-HELLO is not protected by IPsec ESP, it SHOULD be 1090 discarded. Note that, only if the HA-HELLO is sent on a dedicated 1091 link between the home agents, IPsec protection might not be always 1092 required. This depends on the operational policy. 1094 o If HA-HELLO is sent from non global IPv6 address, it MUST be 1095 discarded. 1097 o If the source IPv6 address of HA-HELLO does not belong to one of 1098 the home agents in the redundant home agent set, the HA-HELLO MUST 1099 be ignored. 1101 o If the Group ID field of the received HA-HELLO and the receiver's 1102 Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST 1103 NOT be unicasted to home agents whose Group ID is different from 1104 the sender. 1106 o If the Sequence Number value in the HA-HELLO is equal to or less 1107 than the last received Sequence Number value stored in the home 1108 agent list entry, the HA-HELLO MUST be discarded. When the 1109 sequence number rollover is occurred, the sequence number value in 1110 the HA-HELLO SHOULD be zero. 1112 o HA-HELLO satisfying all of above tests MUST be processed by 1113 receiver. The receiver copies home agent information in HA-HELLO 1114 to the corresponding home agent list entry. The home agent 1115 address of the sender is retrieved from the Source Address field 1116 of the IPv6 header of the HA-HELLO. 1118 o If the home agent lifetime field in the HA-HELLO is set to 0, the 1119 receiver removes the sender from the home agents list. 1121 o If the R-flag is set in the received HA-HELLO, the receiver MUST 1122 send a new HA-HELLO to the originator as described in 1123 Section 7.3.2. 1125 7.4. Processing State Synchronization Messages 1127 It is necessary for standby home agents to synchronize the state 1128 information of each mobile node registered with the active home 1129 agent. In the Home Agent Hard Switch mode, it is not necessary for 1130 the home agents to synchronize the complete binding cache 1131 information. The standby home agent needs the mapping information of 1132 the active home agent and the mobile node. The information is used 1133 to send the Home Agent Switch messages to all the mobile node served 1134 by the failed home agent. 1136 7.4.1. Requesting State of a Particular Mobile Node(s) 1138 When a home agent needs the state information for a particular mobile 1139 node or a subset of mobile nodes, it sends a SS-REQ message 1140 constructed as follows: 1142 o It MUST set the Type field to 0 (Request). 1144 o It MUST set a random value in the Identifier field that does not 1145 coincide with any other currently pending Requests. 1147 o It MUST include an IP address mobility option(s) which subtype is 1148 set to the home address if the target is mobile node(s). 1150 o It MUST include a Mobile Network Prefix mobility option(s) for 1151 mobile router(s). 1153 o It MUST set the unspecified address (::) in the Home Address 1154 mobility option if it solicits the state of all the mobile nodes 1155 and mobile routers registering at the receiver of SS-REQ 1156 (i.e.destination of SS-REQ). 1158 o In the Home Agent Virtual Switch, the sender of the SS-REQ MUST be 1159 a home agent local address of one of the home agents in the same 1160 redundant home agent set. 1162 o In the Home Agent Hard Switch, the sender of the SS-REQ MUST be a 1163 home agent address of one of the home agents in the same redundant 1164 home agent set. 1166 o The destination of the SS-REQ MUST be the active home agent for 1167 the requesting home address or mobile network prefix. The standby 1168 home agent MUST NOT reply the SS-RREP to the sender. 1170 When a home agent receives the SS-REQ, it MUST verify if SS-REQ is 1171 constructed with the above rules. If SS-REQ satisfy all the above 1172 tests, the receiver of the SS-REQ MUST reply SS-REP including the 1173 state information of the requested mobile node(s) and/or mobile 1174 network prefix(es) as described in Section Section 7.4.2. 1176 7.4.2. Synchronizing State 1178 State synchronization messages SHOULD be sent when: 1180 1. The active home agent receives SS-REQ. 1182 2. The active home agent creates a binding cache entry for a 1183 particular mobile node. 1185 3. The active home agent deletes a binding cache entry for a 1186 particular mobile node. 1188 The active home agent MAY additionally send state synchronization 1189 message in following cases: 1191 1. The active home agent update the state information for all 1192 sessions that changed since the last update in a periodic 1193 interval 1195 2. Only for the Home Agent Virtual Switch mode, the active home 1196 agent updates a binding cache entry for a particular mobile node 1197 whenever the binding cache entry is updated. In the Home Agent 1198 Hard Switch mode, standby home agents only need the mapping 1199 information of a home address of the mobile node/router and the 1200 home agent address of the active home agent to which the mobile 1201 node/router is currently registering. This mapping is used to 1202 send a Home Agent Switch message. 1204 If an active home agent sends a State Synchronization message 1205 whenever the local state information changes, such as a binding cache 1206 change, the number of the State Synchronization messages sent can be 1207 quite large. 1209 All the state information of the requested mobile nodes is stored in 1210 the SS-REP. Following rules must be applied when the active home 1211 agent constructs SS-REP. 1213 o If the SS-REP is sent in response to the SS-REQ, the active home 1214 agent MUST copy the Identifier field of the State Synchronization 1215 request message to the Identifier field in the SS-REP. Otherwise, 1216 it MUST set the Identifier field to 0. 1218 o When the active home agent stores the state of multiple mobile 1219 nodes in a SS-REP, a Binding Cache Information option is used as a 1220 separator. For each mobile node, a Binding Cache Information 1221 option is placed first, followed by any other options such as AAA 1222 option. When the next Binding Cache Information option is reached 1223 in the State Synchronization message, it indicates the information 1224 of a different mobile node. 1226 o If the unspecified address is found in the Home Address mobility 1227 option carried with the SS-REQ, the active home agent MUST return 1228 the state of all the active mobile nodes and mobile routers by the 1229 SS-REP. The message may be fragemented depending on the total 1230 size needed to carry all states. 1232 o A SS-REP MUST be authenticated and encrypted by IPsec ESP. 1234 o The destination and source home agents MUST belong to the same 1235 redundant home agent set. 1237 o In the Home Agent Hard Switch, the IPv6 source address MUST be set 1238 to the home agent address of the sender. 1240 o In the Home Agent Virtual Switch, the IPv6 source address MUST be 1241 set to the home agent local address of the sender. 1243 When a home agent receives a SS-REP, it MUST verify whether the SS- 1244 REP is constructed with the above rules or not. If the SS-REP does 1245 not satisfy all the rules above, it is discarded. Otherwise, the 1246 following operation must be taken. 1248 o The receiver of SS-REP MUST update its binding cache and all other 1249 necessary information such as AAA and vendor specific information 1250 in the particular database. 1252 o In the Home Agent Hard Switch mode, the receiver MUST record the 1253 IPv6 address of the sender as the active home agent of the mobile 1254 node. 1256 7.4.3. Reliable Transmission by Explicit Acknowledgement 1258 Signaling messages of the Home Agent Reliability protocol are not 1259 guaranteed reliable transmission due to the Mobility Header use. 1260 This is not always critical, because the link between home agents is 1261 carefully managed as stable and reliable. However, operators may 1262 need more explicit notification to confirm the message exchanges 1263 between home agents. This specification provides an optional 1264 acknowledgment to SS-REP messages. 1266 If an active home agent requires an acknowledgment of SS-REP, it set 1267 the Ack flag in the SS-REP. The receiver of such SS-REP will send 1268 back a SS-ACK. The receiver MUST copy the Identifier value received 1269 in the SS-REP into SS-ACK in order to match the SS-REP and SS-ACK. 1271 7.5. Processing Home Agent Control Messages 1273 7.5.1. Standby Home Agent becomes an Active Home Agent 1275 When a standby home agent decides to become an active home agent, the 1276 standby home agent sends a SO-REQ to the active home agent. This 1277 message MUST be unicasted to the active home agent and MUST be 1278 encrypted and authenticated by IPsec ESP. The active home Agent MUST 1279 NOT generate this message. 1281 When an active home agent receives a SO-REQ, it MUST operate the 1282 following verification and operations: 1284 o If the SO-REQ is not protected by IPsec, it MUST be discarded. 1286 o If the receiver of the SO-REQ is not an active home agent, it MUST 1287 send a SO-REP with the Status field set to 130 (Not active home 1288 agent). 1290 o If the sender home agent does not belong to the same redundant 1291 home agent set, a SO-REP message MUST be sent to the sender with 1292 the Status field set to 132 (Not in same redundant home agent 1293 set). 1295 o If the receiver is an active home agent, there is case where the 1296 active home agent cannot be standby home agent. In such case, the 1297 active home agent can reply a SO-REP with the Status field set to 1298 129 (Administratively prohibited). 1300 o Otherwise, the active home agent MUST become a standby home agent 1301 and reply with a SO-REP message with the Status field set to 0 1302 (Success). 1304 The SO-REP MUST be also protected by IPsec ESP. Otherwise, the 1305 message MUST be silently discarded. If the receiver of SO-REP did 1306 not send a SO-REQ message (i.e. unexpected SO-REP), the message MUST 1307 be ignored. If the Status field of the SwitchOver Reply message is 0 1308 (Success), the receiving standby home agent immediately becomes an 1309 active home agent as described in Section 8.2. If the value in the 1310 Status field is greater than 128 an error has occurred. In this 1311 case, the receiver MUST NOT attempt to be an active home agent. 1313 7.5.2. Active Home Agent becomes inactive 1315 When an active home agent decides to become a standby home agent, it 1316 sends a SB-REQ to one of standby home agent. The reason for the 1317 active home agent to send this message can be administrative 1318 intervention, and events like Monitored Server Failure by the active 1319 home agent or Routing Peer/Link Failure. This message MUST be 1320 unicasted to one of the standby home agents and MUST be encrypted and 1321 authenticated by IPsec ESP. A standby home agent MUST NOT generate 1322 this message. 1324 When a home agent receives a SwitchBack Request message, it first 1325 verifies the message. 1327 o If the SwitchBack Request message is not protected by IPsec ESP, 1328 it MUST be discarded. 1330 o If the sender home agent of the SB-REQ is not an active home 1331 agent, the receiver MUST reply a SB-REP with the Status field is 1332 set to 130 (Not active home agent). 1334 o If the sending home agent does not belong to the same redundant 1335 home agent set, a SB-REP MUST be sent in which the Status field 1336 set to 132 (Not in same redundant home agent set). 1338 o Otherwise, the receiving home agent MUST send a SB-REP with the 1339 Status field is set to 0 (Success). 1341 After sending the SwitchBack reply, it MUST NOT become an active home 1342 agent immediately. This is because the active home agent is still 1343 active until it receives the SB-REP which is acknowledging the SB- 1344 REQ. The standby home agent SHOULD change to active at least after 1345 LINK_TRAVERSAL_TIME. 1347 If a home agent receives a SB-REP, it MUST be protected by IPsec ESP, 1348 otherwise the message MUST be silently discarded. If the receiving 1349 home agent did not send a SB-REQ matched to the received SB-REP, the 1350 message MUST be silently discarded. If the Status field of the SB- 1351 REP is 0 (Success), the active home agent immediately becomes a 1352 standby home agent. The sender home agent of SB-REP becomes active 1353 home agent as described in Section 8.2. If the value in the Status 1354 field is greater than 128, the receiver of SB-REP (active home agent) 1355 cannot become a standby home agent and MUST continue to be an active 1356 home agent. 1358 7.6. Interworking with VRRP 1360 VRRP and HSRP specify an election protocol that dynamically assigns 1361 responsibility for a virtual router to one of the VRRP routers on a 1362 LAN. This operation is similar to the Home Agent Virtual Switch 1363 operation. For example, the VRRP router controlling the IP 1364 address(es) associated with a virtual router is called the Master, 1365 and forwards packets sent to these IP addresses. The election 1366 process provides dynamic fail over in the forwarding responsibility 1367 should the Master become unavailable. Although VRRP is used to 1368 guarantee home agent address reachability, it cannot be used for 1369 state synchronization and explicit switching of Master and Backup. 1370 Thus, the Home Agent Reliability protocol cannot be replaced by VRRP. 1371 This section explains how VRRP can interwork with the Home Agent 1372 Reliability protocol. 1374 When VRRP is available, VRRP can replace the Hello message described 1375 in Section 5.1.3. However, some of information is missed by using 1376 VRRP. After receiving a VRRP message, each home agent SHOULD process 1377 the message and store the information as if it receives Home Agent 1378 Hello messages Section 7.3.3. The Home Agents SHOULD still perform 1379 binding cache synchronization as described in Section 7.4 and SHOULD 1380 support the Home Agent Switch message as described in Section 9.2. 1382 In addition to this, VRRP is useful only if all home agents are 1383 located on the same link. If the home agents are topologically 1384 separated, the Home Agent Reliability protocol MUST be used. 1386 0 1 2 3 1387 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 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 |Version| Type | Virtual Rtr ID| Priority |Count IPv6 Addr| 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 |(rsvd) | Adver Int | Checksum | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | | 1394 + + 1395 | IPv6 Address(es) | 1396 + + 1397 + + 1398 + + 1399 + + 1400 | | 1401 + + 1402 | | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 Figure 12: VRRP Packet Format 1406 The message format of VRRP is described in Figure 12. Each field is 1407 mapped as follows: 1409 Virtual Rtr ID 1411 Group ID is stored in the Virtual Rtr ID field. 1413 Priority 1415 Home Agent Preference is stored in the Priority field. Note that 1416 VRRP only has 8 bits for the Priority field. Therefore, values 1417 larger than 255 MUST NOT be assigned to the preference value. 1419 Count IPv6 IPv6 Addr 1421 This field MUST be always be 1. 1423 Advert Int 1425 This field MUST be mapped to the Hello Interval field of the Home 1426 Agent Hello message, though it only has 12 bytes. 1428 IPv6 address 1430 A home agent address is stored in this field. 1432 Home Agent Lifetime, Sequence Number and Flags field are missing in 1433 the VRRP packet format. Therefore, operators SHOULD use the same 1434 statically configured value for Home Agent Lifetime. Each home agent 1435 does not check freshness of received VRRP message because of no 1436 sequence number. If VRRP is used, a home agent cannot determine the 1437 active home agent from the VRRP message due to lack of A flag, and 1438 cannot request a VRRP advertisement to other home agents. 1440 7.7. Retransmissions and Rate Limiting 1442 Standby and active home agents are responsible for retransmissions 1443 and rate limiting of a SS-REQ, SO-REQ, SB-REQ messages for which they 1444 expect a response. The home agent MUST determine a value for the 1445 initial transmission timer: 1447 o If the home agent sends a SS-REQ message, it SHOULD use an initial 1448 retransmission interval of INITIAL_STATE_SYNC_REQ_TIMER. 1450 o If a standby home agent sends a SO-REQ message, it SHOULD use an 1451 initial retransmission interval of INITIAL_SWICHOVER_REQ_TIMER. 1453 o If an active home agent sends a SB-REQ message, it SHOULD use an 1454 initial retransmission interval of INITIAL_SWICHBACK_REQ_TIMER . 1456 If the sending home agent fails to receive a valid matching response 1457 within the selected initial retransmission interval, it SHOULD 1458 retransmit the message until a response is received. All of the 1459 above constants are specified in Section 11. 1461 The retransmission MUST use an exponential backoff process as 1462 described in [RFC-3775] until either the home agent receives a 1463 response, or the timeout period reaches the value 1464 MAC_HARELIABILITY_TIMEOUT (16sec). The home agent SHOULD use a 1465 separate back-off process for different message types and different 1466 destinations. The rate limiting of Mobility Header messages is the 1467 same as one in [RFC-3775]. A home agent MUST NOT send Mobility 1468 Header Messages to a particular home agent more than MAX_UPDATE_RATE 1469 (3) times a second, which is specified in [RFC-3775]. 1471 8. Home Agent Virtual Switch 1473 8.1. Consideration of Routing and Neighbor Discovery Protocol 1475 This section gives a brief explanation of how a home agent interacts 1476 with routing and Neighbor Discovery Protocol (NDP) when the Home 1477 Agent Virtual Switch mode is used. 1479 When a standby home agent becomes active in the Home Agent Virtual 1480 Switch mode, it MUST start to advertise the home agent address and 1481 the home prefix of the home addresses serviced by the redundant home 1482 agent set into the routing infrastructure. This operation is 1483 normally done using a route selector such as BGP or an OSPF modifier. 1484 For example, we can use the AS_Path prepend operation for BGP, and 1485 the Metric field in OSPF for the route selection. When each home 1486 agent participates in OSPF routing, each home agent should be 1487 configured with the appropriate metric matched to the home agent 1488 preference value. When the active home agent fails, OSPF detects the 1489 failure and can dynamically switch the route to the standby home 1490 Agent based on the OSPF cost value. If this creates conflicts with 1491 the home agent preference value due to configuration errors, the 1492 routers on the home link may not route packets to the desired standby 1493 home agent. In order to change the OSPF cost correctly and 1494 dynamically, The operator takes other existing approaches. For 1495 example, most of router vendors have a private MIB to set the cost 1496 via SNMP, though this is a vendor-specific function. 1498 When an active home agent activates a home agent address, it SHOULD 1499 use a virtual MAC address as introduced in [RFC-3768]. When the 1500 active home agent is changed, the neighbor cache of the active home 1501 agent is not necessarily updated on mobile nodes located on the home 1502 link. Otherwise, the new home agent MUST update the neighbor cache 1503 entry for the home agent address on all the mobile nodes located on 1504 the home link. In addition, Mobile IPv6 uses proxy NDP to intercept 1505 packets meant for mobile nodes which are away from the home link. 1506 However, it is unnecessary for the new active home agent to overwrite 1507 the existing proxy neighbor entries of the mobile nodes. 1509 8.2. Home Agent Recovery 1511 After detecting the active home agent has failed, the standby home 1512 agent whose preference value is the highest MUST take over the failed 1513 home agent. The standby home agent MUST activate the virtual home 1514 agent address. If a virtual MAC address as introduced in [RFC-3768] 1515 is used, the standby home agent MUST start using that virtual MAC 1516 address as well. Since all the necessary state has already been 1517 transferred to this standby home agent before the active home agent 1518 failed, it can immediately start acting as the active home agent. 1520 9. Home Agent Hard Switch 1522 9.1. Home Agent Recovery 1524 After detecting the active home agent has failed, the standby home 1525 agent whose preference value is the highest MUST take over the failed 1526 home agent. The standby home agent MUST send a Home Agent Switch 1527 message to all the mobile nodes that were registered at the failed 1528 home agent as described in Section 9.2, using the pre-established 1529 IPsec SA. The standby Home Agent MUST set its own address in the 1530 Home Agent Address field in the Home Agent Switch message so that it 1531 will receive the binding update from the mobile node as an 1532 acknowledgement of the sent Home Agent Switch message. The home 1533 agent switch-over is complete when it receives binding updates from 1534 all the mobile nodes. It is important to remark that sending Home 1535 Agent Switch messages to all the mobile nodes at once may bring non- 1536 negligible overhead to the home agent. 1538 This overhead cannot be avoided if the active home agent suddenly 1539 stop serving mobile node because of unexpected reasons (crash, 1540 network trouble, etc). However, if this switch over is operated 1541 under the administrative operation (maintenance, etc), the previous 1542 active home agent may continue serving the mobile nodes until the 1543 switch over is completed. Until the mobile node sends a binding 1544 update to the new active home agent, it still sends the packet to the 1545 previous home agent in the Home Agent Hard Switch. Therefore, the 1546 new active home agent can notify the completion of switch-over to the 1547 previous active home agent by using Home Agent Control message as 1548 described in Section 9.4. As soon as this message is received, the 1549 previous active home agent can be shutdown or detached from the 1550 network safely. 1552 9.2. Sending Home Agent Switch Messages 1554 The standby home agent which is going to be active MUST send a Home 1555 Agent Switch message as defined in [RFC-5142] to all the mobile nodes 1556 that were being served by the failed home agent. The Home Agent 1557 Switch message must be securely sent to the mobile node by using 1558 IPsec ESP. The standby home agent MUST include only its own home 1559 agent address in the Home Agent Switch message. If there are a large 1560 number of mobile nodes served by the failed home agent, the overhead 1561 sending Home Agent Switch messages is high. Until a mobile node 1562 receives this Home Agent Switch messages, the mobile node's 1563 communication is discontinued. Therefore, until the standby home 1564 agent completes sending the Home Agent Switch message to all the 1565 mobile nodes and receives Binding Updates from all the mobile node, 1566 the failed home agent SHOULD serve mobile nodes if possible. This is 1567 the case when the active home agent is replaced by administrative 1568 operation with the Home Agent Control messages as described in 1569 Section 9.4. 1571 9.3. Sending Home Agent Rekey Messages 1573 When a failed home agent recovers, it MUST re-establish an IPsec SA 1574 with each mobile node served by its redundant home agent set. 1575 Otherwise, it cannot be either a standby or active home agent for the 1576 mobile nodes. Therefore, as soon as the active home agent detects 1577 the recovery of the failed home agent, it sends a Home Agent Rekey 1578 message to all the mobile nodes served by other home agents in the 1579 same redundant home agent set, and includes the recovered home agent 1580 address in the Home Agent Addresses field. The mobile node will re- 1581 key the SA. 1583 9.4. Notification of Home Agent Switch Completion 1585 If the new active home agent completes the switch-over as described 1586 in Section 8.2, it SHOULD send a SW-COMP to the previous active home 1587 agent in the Home Agent Hard Switch case. Until the previous home 1588 agent receives this message, it SHOULD continue serving any mobile 1589 nodes that are registered with it. Once the previous home agent 1590 receives the SW-COMP message, it can stop home agent services. 1592 9.5. Mobile Node Operation 1594 9.5.1. Home Agent Addresses Discovery 1596 In the Home Agent Hard Switch mode, a mobile node authenticates 1597 itself to two or more home agents and creates IPsec SAs with them 1598 during bootstrapping. When the active home agent fails, another home 1599 agent can use the pre-existing SA to notify the mobile node about the 1600 failure by sending a Home Agent Switch message. 1602 In order to discover multiple home agent addresses, two different 1603 mechanisms are defined in the bootstrapping solution in the split 1604 scenario [RFC-5026]. One is DNS lookup by home agent Name, the other 1605 is DNS lookup by Service Name. DHCPv6 can also be used in the 1606 integrated scenario [ID-BOOTINT] to provide home agent provisioning 1607 to mobile nodes. 1609 In the split scenario, a mobile node can use DNS lookup by Service 1610 Name to discover the home agents, as defined in [RFC-5026]. For 1611 example, if home agent reliability is required by a mobile node, DNS 1612 lookup by Service Name method is recommended for the mobile node to 1613 discover multiple home agents addresses. Therefore, mobile nodes 1614 will query the DNS SRV records with a service name of mip6 and 1615 protocol name of ipv6. The DNS SRV records includes multiple home 1616 agent addresses and different preference values and weights. The 1617 mobile node SHOULD choose two or more home agents from the home 1618 agents list according to their preference value. Then the mobile 1619 node should authenticate itself to these home agents via an IKEv2 1620 exchange. 1622 In the integrated scenario, a mobile node can use DHCPv6 to get home 1623 agent provisioning from an MSP or ASP, as already defined in [ID- 1624 BOOTINT]. The only requirement is that the DHCPv6 response must 1625 include multiple home agents' information in order to support home 1626 agent reliability. 1628 9.5.2. IKE/IPsec pre-establishment to Home Agents 1630 After a mobile node obtains multiple home agent addresses, it needs 1631 to trigger multiple IKE exchanges with the multiple home agents 1632 selected from the home agent list. Since both IKEv1 and IKEv2 can be 1633 used to bootstrap Mobile IPv6, this solution does not introduce any 1634 new operations to co-operate with IKEv1 or IKEv2. It should initiate 1635 IKE for home agents as soon as home registration is complete. 1637 The mobile node MUST follow the standard IKEv2 exchange in the 1638 bootstrapping solution of the split scenario [RFC-5026]. Home 1639 Address configuration maybe also be included, if necessary, for the 1640 first IKE exchange. After its Home Address is assigned or approved 1641 by the first home agent, mobile node SHOULD register itself with the 1642 second home agent with IKE using the same Home Address. Therefore, 1643 no home address configuration should be used in the second IKEv2 1644 procedure. Note that the mobile node only sends a Binding Update 1645 message to the first home agent. 1647 9.5.3. Synchronizing State: K-bit treatment 1649 When a mobile node moves and the care-of address changes, it can use 1650 the Key Management Mobility Capability (K) bit in the Binding Update 1651 in order to update the peer endpoint of the key management protocol 1652 (ex. IKE Security Association). 1654 If an active home agent receives a Binding Update which K-bit is set, 1655 it MUST proceed the Binding Update as [RFC-3775]. In addition, the 1656 active home agent MUST notify the care-of address change to the other 1657 standby home agents. For doing so, it MUST send State 1658 Synchronization Reply message including Binding Cache Information 1659 option to all the other standby home agents. The flags of the 1660 Binding Update (ex. K-bit) MUST be copied to the flags field of the 1661 Binding Cache Information option. After all, the standby home agents 1662 know the existence of K-bit set in the Flag field of the Binding 1663 Cache Information option and update the peer endpoint of the key 1664 management protocol. 1666 If the K-bit is not set in the Binding Update, an active home agent 1667 needs to rerun the key management protocol. The active home agent 1668 MUST send State Synchronization Reply message including Binding Cache 1669 Information option to all the other standby home agents. K-bit is 1670 unset in the flags field of the Binding Cache Information option. 1671 The receivers of the State Synchronization Reply message (i.e. 1672 standby home agents) detect the care-of address change and rerun the 1673 key management protocol. 1675 9.5.4. Receiving Home Agent Switch message 1677 A mobile node must follow the operation specified in [RFC-5142] when 1678 it receives a Home Agent Switch message. 1680 When the mobile node receives a Home Agent Switch message, and if the 1681 message contains the IPv6 address of a standby home agent, it MUST 1682 select the standby home agent in the switch message as the active 1683 home agent and send a new Binding Update message to it. Note that 1684 the standby home agent address in the Home Agent Switch MUST be equal 1685 to the sender of the Home Agent Switch message. The standby Home 1686 agent expects the Binding Update as an acknowledgment of the Home 1687 Agent Switch message. The mobile node already has a pre-established 1688 SA with the standby home agents and should use that SA to send the 1689 Binding Update. If the address stored in the Home agent address 1690 field is different from the sender, the mobile node MUST send a 1691 binding update to the sender. 1693 9.5.5. Receiving Home Agent Rekey message 1695 When a mobile node receives a Home Agent Rekey message, it MUST 1696 verify the message as following 1698 o The message MUST be sent from the receiver's active home agent. 1699 Otherwise, the message MUST be discarded. 1701 o The message MUST be protected by IPsec. Otherwise, the message 1702 MUST be discarded. 1704 o The message SHOULD contain one of standby home agent's address. 1705 If the home agent address is not known from the bootstrapping 1706 described in Section 9.5.1, the mobile node MUST NOT start an IKE 1707 session with the unknown home agent. Instead, it SHOULD re-start 1708 home agent discovery again to update its home agent address 1709 information. 1711 If all the above verfications are satisified, the mobile node MUST 1712 re-key the SA with the home agent addresses stored in the Home Agent 1713 Addresses field. 1715 10. Security Considerations 1717 Since Mobile IPv6 operation requires ESP in transport mode between 1718 the mobile node and the home agent, we will discuss the ESP field 1719 synchronization issues between the mobile node and the redundant set 1720 of home agents. This synchronization is required only for Home Agent 1721 Virtual Switch mode. Most of fields should be synchronized based on 1722 [RFC-4301]. The ESP header has the following fields: 1724 SPI 1726 This field identifies the SAD at the receiver. 1728 The mobile node negotiates only one IPsec SA. Hence, the SPI 1729 value will remain unchanged upon home agent failover. 1731 Sequence Number 1733 This field is used for "anti-replay" feature of ESP. The 1734 transmitter must include this monotonically increasing number. 1735 The receiver may process the sequence number based on local 1736 policy. 1738 The mobile node and the redundant home agent set will have the 1739 same set of sequence numbers for transmit and receive. Hence, 1740 synchronization of the sequence number field is mandatory in this 1741 mode of operation. 1743 The SA1, SA2, SA3, SA4 could be synchronized between the home 1744 agents as these messages are not sent continuously. Moreover for 1745 the Binding Update case, if the mobile node is in the middle of 1746 sending a Binding Update to an active home agent for a binding 1747 refresh, and the active home agent is not available at that 1748 moment, the mobile node will not get any response from the active 1749 home agent. After a standby home agent becomes active, the mobile 1750 node will retry and it will receive the Binding Update from the 1751 mobile node with a sequence number that is +n from its last known 1752 sequence number for SA1. For the Binding Acknowledgment case 1753 (SA2), the standby home agent SHOULD add a random number to the 1754 last known sequence number over and above the replay window to 1755 ensure that the packet passes the replay check at the mobile node. 1756 The same applies to HoTi and HoT messages with SA3 and SA4. Note 1757 that this windowing of the sequence numbers for Mobile IPv6 1758 signaling is only needed to cover the corner cases when Binding 1759 Update or HoTi is in-flight and the active home agent fails. 1761 The technique explained above should work for user data packets if 1762 ESP is used to encrypt user data traffic as well. The actual 1763 switchover time and the routing infrastructure convergence time is 1764 the only latency that the user may perceive. 1766 Initialization Vector 1768 Since the Initialization Vector will be delivered in each exchange 1769 between a mobile node and home agent, this field is not 1770 necessarily synchronized between home agents. 1772 Others 1774 Other fields should be synchronized based on RFC4301 [RFC-4301] 1776 In the Home Agent Hard Switch mode, the standby home agent needs to 1777 send a Home Agent Switch message using IPsec encryption. Since the 1778 mobile node has pre-established an IPsec SA with both the active and 1779 standby home agents, the standby home agent can send the message to 1780 the mobile node with the pre-established IPsec SA. 1782 11. Protocol Constants 1784 INITIAL_STATE_SYNC_REQ_TIMER: 3sec 1786 INITIAL_SWICHOVER_REQ_TIMER: 1sec 1788 INITIAL_SWICHBACK_REQ_TIMER 1sec 1790 LINK_TRAVERSAL_TIME 150msec 1792 12. IANA Considerations 1794 o The values for following mobility header message MUST be assigned 1795 by IANA. 1797 * State Synchronization Message 1799 * Home Agent Control Message 1801 * Home Agent Hello Message 1803 * Home Agent Rekey Message 1805 o The values for following mobility options MUST be assigned by 1806 IANA. 1808 1. Binding Cache Information Option 1810 2. AAA Information Option 1812 o New Option Code for the IP address option defined in [RFC-5268] 1814 13. Additional Authors 1816 This document is a result of discussions in the Mobile IPv6 Home 1817 Agent Reliability Design Team. The members of the design team that 1818 are listed below are authors that have contributed to this document: 1820 Samita Chakrabarti 1822 samita.chakrabarti@azairenet.com 1824 Kuntal Chowdhury 1826 kchowdhury@starentnetworks.com 1828 Hui Deng 1830 denghui@chinamobile.com 1832 Vijay Devarapalli 1834 vijay.devarapalli@azairenet.com 1836 Sri Gundavelli 1838 sgundave@cisco.com 1840 Brian Haley 1842 brian.haley@hp.com 1844 Behcet Sarikaya 1846 bsarikaya@huawei.com 1848 Ryuji Wakikawa 1850 ryuji@sfc.wide.ad.jp 1852 14. Acknowledgements 1854 This document includes a lot of text from [ID-LOCALHAHA] and [ID- 1855 HAHA]. Therefore the authors of these two documents are 1856 acknowledged. We would also like to thank the authors of the home 1857 agent reliability problem statement [ID-PS-HARELIABILITY] for 1858 describing the problem succinctly and Alice Qin for her work on the 1859 hello protocol. 1861 15. References 1863 15.1. Normative References 1865 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1866 Requirement Levels", BCP 14, RFC 2119, March 1997. 1868 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1869 IPv6", RFC 3775, June 2004. 1871 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1872 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1873 January 2005. 1875 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1876 Network Access Identifier", RFC 4282, December 2005. 1878 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1879 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", 1880 RFC 4283, November 2005. 1882 [RFC-5094] Devarapalli, V., "Mobile IPv6 Vendor Specific Option", RFC 1883 5094, October 2007. 1885 [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message", 1886 RFC-5142, November 2007. 1888 [RFC-5026] Giaretta, G., "Mobile IPv6 bootstrapping in split 1889 scenario", RFC 5026, October 2007. 1891 [ID-BOOTINT] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via 1892 DHCPv6 for the Integrated Scenario", 1893 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in progress), 1894 April 2008. 1896 15.2. Informative References 1898 [RFC-3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 1899 RFC 3768, April 2004. 1901 [RFC-2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot 1902 Standby Router Protocol (HSRP)", RFC 2281, March 1998. 1904 [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1905 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", 1906 RFC 3776, June 2004. 1908 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 1909 Internet Protocol", RFC 4301, December 2005. 1911 [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1912 RFC 3753, June 2004. 1914 [RFC-5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 1915 2008. 1917 [ID-HAHA] Wakikawa, R., "Inter Home Agents Protocol Specification", 1918 draft-wakikawa-mip6-nemo-haha-spec-01 (expired), March 2006. 1920 [ID-LOCALHAHA] Devarapalli, V., "Local HA to HA protocol", 1921 draft-devarapalli-mip6-nemo-local-haha-01 (expired), March 2006. 1923 [ID-PS-HARELIABILITY] Faizan, J., "Problem Statement: Home Agent 1924 Reliability", draft-jfaizan-mipv6-ha-reliability-01 (expired), 1925 February 2004. 1927 Author's Address 1929 Ryuji Wakikawa 1930 TOYOTA InfoTechnology Center, U.S.A., Inc. 1931 465 Bernardo Avenue 1932 Mountain View, CA 94043 1933 USA 1935 Email: ryuji@us.toyota-itc.com