idnits 2.17.1 draft-ietf-mip6-hareliability-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1849. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1839. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 19, 2006) is 6514 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 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2461 (ref. '4') (Obsoleted by RFC 4861) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-ha-switch-01 -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '9') (Obsoleted by RFC 5268) == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-02 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-00 == Outdated reference: A later version (-02) exists of draft-devarapalli-mip6-ikev1-bootstrap-01 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group R. Wakikawa (Editor) 3 Internet-Draft Keio University 4 Expires: December 21, 2006 June 19, 2006 6 Home Agent Reliability Protocol 7 draft-ietf-mip6-hareliability-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 21, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The home agent can be a single point of failure when Mobile IPv6 is 41 used in a system. It is critical to provide home agent reliability 42 in the event of a home agent crashing or becoming unavailable. This 43 would allow another home agent to take over and continue providing 44 service to the mobile nodes. This document describes the problem 45 scope briefly and provides a mechanism for achieving home agent 46 reliability. Note that this document is not completed yet. DT is 47 still discussing some items. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 57 4. Goals for the Solution . . . . . . . . . . . . . . . . . . . . 8 59 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 60 5.1. Home Agent Virtual Switch . . . . . . . . . . . . . . . . 10 61 5.2. Home Agent Hard Switch . . . . . . . . . . . . . . . . . . 11 62 5.3. Failure Detection and Home Agent Management . . . . . . . 13 64 6. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 6.1. New Mobility Header Messages . . . . . . . . . . . . . . . 16 66 6.1.1. Home Agent Hello Request Message . . . . . . . . . . . 16 67 6.1.2. Home Agent Hello Message . . . . . . . . . . . . . . . 17 68 6.1.3. State Synchronization Request Message . . . . . . . . 20 69 6.1.4. State Synchronization Message . . . . . . . . . . . . 21 70 6.1.5. Home Agent SwitchOver Request Message . . . . . . . . 22 71 6.1.6. Home Agent SwitchOver Reply Message . . . . . . . . . 23 72 6.1.7. Home Agent SwitchBack Request Message . . . . . . . . 23 73 6.1.8. Home Agent SwitchBack Reply Message . . . . . . . . . 24 74 6.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 25 75 6.2.1. IP address Option . . . . . . . . . . . . . . . . . . 25 76 6.2.2. Binding Cache Information Option . . . . . . . . . . . 25 77 6.2.3. AAA Information Option . . . . . . . . . . . . . . . . 27 78 6.2.4. Vendor Specific Information Option . . . . . . . . . . 27 80 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 29 81 7.1. Home Agent Configuration . . . . . . . . . . . . . . . . . 29 82 7.2. Hello messages Manipulation . . . . . . . . . . . . . . . 30 83 7.2.1. Sending Hello Request . . . . . . . . . . . . . . . . 31 84 7.2.2. Receiving Hello Request . . . . . . . . . . . . . . . 31 85 7.2.3. Sending Hello . . . . . . . . . . . . . . . . . . . . 31 86 7.2.4. Receiving Hello . . . . . . . . . . . . . . . . . . . 32 87 7.3. Failure Detection . . . . . . . . . . . . . . . . . . . . 32 88 7.4. Active Home Agent Change . . . . . . . . . . . . . . . . . 33 89 7.5. Processing State Synchronization Messages . . . . . . . . 34 90 7.5.1. Sending State Synchronization Request . . . . . . . . 34 91 7.5.2. Receiving State Synchronization Request . . . . . . . 34 92 7.5.3. Sending State Synchronization . . . . . . . . . . . . 34 93 7.5.4. Receiving State Synchronization . . . . . . . . . . . 35 94 7.6. Processing Home Agent SwitchOver Messages . . . . . . . . 35 95 7.6.1. Sending Home Agent SwitchOver Request . . . . . . . . 35 96 7.6.2. Sending Home Agent SwitchOver Reply . . . . . . . . . 36 97 7.6.3. Receiving Home Agent SwitchOver Reply . . . . . . . . 36 98 7.7. Processing Home Agent SwitchBack Messages . . . . . . . . 36 99 7.7.1. Sending Home Agent SwitchBack Request . . . . . . . . 36 100 7.7.2. Sending Home Agent SwitchBack Reply . . . . . . . . . 37 101 7.7.3. Receiving Home Agent SwitchBack Reply . . . . . . . . 37 102 7.8. Sending Home Agent Switch Message . . . . . . . . . . . . 37 104 8. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 38 105 8.1. Standby Home Agent Addresses Discovery . . . . . . . . . . 38 106 8.2. IKE/IPsec pre-establishment to Home Agents . . . . . . . . 38 107 8.3. Receiving Home Agent Switch message . . . . . . . . . . . 39 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 111 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 113 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 115 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 116 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 117 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 120 Intellectual Property and Copyright Statements . . . . . . . . . . 47 122 1. Introduction 124 In Mobile IPv6 [1] and NEMO Basic Support[2], mobile nodes may use a 125 bi-directional tunnel with their Home Agents for all traffic with the 126 correspondent nodes. A home agent on the home link maintains a 127 binding cache entry for each mobile node and uses the binding cache 128 entry to route any traffic meant for the mobile node or the mobile 129 network. If the mobile node is not on the home link and does not 130 have a binding cache entry at the home agent, it is neither reachable 131 at its home address nor able to setup new sessions with its home 132 address. If a home agent loses the binding cache state, due to 133 failure or some other reason, it results in loss of service for the 134 mobile nodes. 136 It would be very beneficial to provide high availability and 137 redundancy for a home agent so that the mobile nodes can avail of 138 uninterrupted service even when one home agent crashes or loses 139 state. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [3]. 147 In this document, the term mobile node refers to both a mobile node 148 [1] and a mobile router [2]. 150 Some of the mobility related terms used in this document are defined 151 in [1] and [7]. In addition or in replacement of these, the 152 following terms are defined or redefined: 154 Active Home Agent 156 A home agent that is currently serving the mobile nodes 158 Standby Home Agent 160 A home agent which will serve the mobile nodes when the active 161 home agent fails. 163 Failed Home Agent 165 A home agent that is not available due to hardware or software 166 failure, system maintenance, etc. 168 Redundant Home Agent Set 170 A pair of an Active Home Agent and Standby Home Agent(s). The 171 Group Identifier is introduced to identify a Redundant Home Agent 172 set. The Group ID is exchanged by Hello messages. 174 Binding Synchronization 176 Synchronization of binding cache entries within the redundant home 177 agent set 179 Home Agent Preference 181 This preference value is defined for DHAAD in RFC3775. This 182 protocol uses this preference value for home agent selection when 183 an active home agent is failed. However, an operator can also 184 define an independent value only for home agent reliability 185 protocol if the operator wants to have different preference value 186 for DHAAD and home agent reliability protocol. A Home Agent 187 SHOULD NOT use the same preference value of other Home Agents for 188 this protocol. 190 Home Agent Hard Switch 192 The Home Agent Hard Switch is used when IPsec states cannot be 193 synchronized between an active and a Standby Home Agent. In this 194 case each home agent negotiates independent IPsec SAs with a 195 mobile node. The mobile node will be notified to change its home 196 agent to one of Standby Home Agent. 198 Home Agent Virtual Switch 200 In this case IPsec states are synchronized within the redundant 201 home agent set. A given mobile node has only one IPsec SA and one 202 mobility binding. Upon failure of the Active Home Agent, the 203 Standby Home Agent begins to serve the mobile nodes without having 204 to notify the mobile nodes about the failure event in the network. 206 3. Problem Statement 208 In Mobile IPv6 base specification, a mobile node registers and 209 establishes a connection with only one Home Agent. Thus the Home 210 Agent represents the possibility of a single point of failure for 211 Mobile IPv6. A Home Agent may be responsible for multiple mobile 212 nodes on the home link. The failure of the Home Agent may then 213 result in the loss of connectivity for numerous mobile nodes located 214 throughout the Internet. To overcome this problem, Mobile IPv6 215 allows deployment of multiple Home Agents on the home link so that 216 upon the failure of serving Home Agent, mobile node can re-establish 217 its connection through the new Home Agent. However, base Mobile IPv6 218 specification does not address the Home Agent failover and dynamic 219 transfer of service from one Home agent to another. This transfer of 220 service from the Failed Home Agent to a new working Home Agent 221 requires co-ordination or pre-configuration among the Home agents 222 regarding security association, transfer of mobile-node related 223 binding and other service information for the reliable Mobile IPv6 224 service in a deployment scenario. 226 4. Goals for the Solution 228 For the home agent reliability solution, we define the following 229 requirements. 231 Reliable Home agent service 233 Multiple home agents are available for a home prefix and one of 234 them is actively serves the mobile nodes. A standby home agent 235 takes over when the Active Home Agent becomes unavailable. The 236 transfer of the MN-HA association should be transparent to the 237 application and should not take longer than care-of-addresses 238 update procedure described in the Mobile IPv6 [1]. 240 Availability of a redundant home agent set 242 Availability of an Active Home Agent address and a standby Home 243 Agent address at the bootstrapping period to Mobile Node is 244 assumed. 246 State Synchronization 248 The information for mobile nodes must be synchronized between an 249 Active Home Agent and Standby Home Agents. The information is 250 Binding Cache, IPsec/IKE states, AAA information, vendor specific 251 information. 253 Consideration of IPsec/IKE transfer 255 An Active Home Agent maintains several IPsec and IKE states for 256 mobile nodes. These states are synchronized within the redundant 257 Home Agent set. The details are described in Section 9. 259 Secured Message Exchanges 261 The messages used between the home agents to transfer binding 262 cache information MAY be authenticated and encrypted. 264 Failure Detection 266 Redundant home agents must actively check for possible failure of 267 an Active Home Agent. Periodic hello messages should be used to 268 detect Active Home Agent's service availability 270 Failure Notification 271 If necessary a mobile node is notified about the active home agent 272 failure by the Standby Home Agent in Home Agent Hard Switch mode 273 of operation 275 5. Protocol Overview 277 This specification provides two modes for home agent local 278 reliability. 280 o Home Agent Virtual Switch: In this mode the active and the 281 redundant home agents are all accessible through the same IP 282 address. IPsec/IKE states must be synchronized between the active 283 and a redundant home agent(s). The mechanism used to synchronize 284 IPsec state is currently considered out of scope for this document 285 and not described here. In this mode, a mobile node always 286 establishes IPsec SAs only with the Active Home Agent. The IPsec 287 state will be shared within the redundant home agent set in 288 background. In case there is a failure the Standby Home Agent 289 takes over without the mobile node being aware of the change in 290 the home agent. 292 o Home Agent Hard Switch: In this mode the home agents are addressed 293 by different IP addresses and the mobile node is aware of the 294 change in the home agent. This mode is also useful when the IPsec 295 state cannot be synchronized. In this mode, a standby home agent 296 must solicit mobile nodes to re-establish IPsec/IKE for Mobile 297 IPv6 signaling. This IPsec re-establishment is triggered when a 298 mobile node changes its home agent after receiving a home agent 299 switch message from a standby home agent. In order to exchange 300 this message securely between a Standby Home Agent and a mobile 301 node, a mobile node need to establish IPsec SA with both an Active 302 Home Agent and redundant home agents beforehand. With this 303 multiple IPsec SAs, a mobile node will receive a notification from 304 the Standby Home Agent and start to use the Standby Home Agent 305 when the Active Home Agent failed. 307 All new messages defined in this document are defined as Mobility 308 Header messages so that the HA reliability protocol can be extended 309 later, if needed, to provide home link redundancy. (i.e. Protocol is 310 not tight with the link boundary) 312 5.1. Home Agent Virtual Switch 314 In the case of the virtual home agent switch, a mobile node remains 315 agnostic about the change in the serving home agent. The home agents 316 have replicated all session state including the IPsec/IKE/ESP sates. 317 The ESP sequence numbers, which is used to prevent replay attack, may 318 not be synchronized momentarily. However, this should not pose any 319 problem as both ends of the IPsec ESP tunnel should use sequence 320 numbers that are greater than the last known sequence numbers to 321 either ends. The Standby Home Agent should add a random number (+n) 322 over and above the anti-replay window to ensure that the packet 323 received by the mobile node passes ESP replay check. 325 The operations of the Home Agent Virtual Switch are shown in 326 Figure 1. After binding registration is done (2, 3), the Active Home 327 Agent pushes all the states of mobile nodes by a state 328 synchronization message in a periodic interval (4). The Active Home 329 Agent synchronizes the IPsec state information with the Standby Home 330 Agent(s), too. This state synchronization should be done 331 periodically in order to match the ESP sequence number and anti- 332 replay window among home agents. The Standby Home Agent(s) is not 333 active unless it takes over from a Failed Home Agent. 335 When the Active Home Agent's failure is detected (5), the Standby 336 Home Agent activates the IP address of the failed home agent on it 337 and takes over from the Failed Home Agent. All the home agents in 338 the redundant home agent set share a virtual address and the routing 339 will ensure only the Active Home Agent will be reachable using that 340 virtual address. The Standby Home Agent can serve all the mobile 341 nodes for which the states are synchronized, without any further 342 message exchange because it has all the necessary information which 343 it obtained from the failed home agent. 345 MN HA1(active) HA2(Standby) 346 | | . 347 |<--------->| . 1. IPsec/IKE 348 | | . 349 |---------->| . 2. Binding Update 350 |<----------| . 3. Binding Acknowledgement 351 | | . 352 | |<--------->. 4. State exchanges (Binding cache/IPsec) 353 | | . 354 | X . HA1 FAILURE 355 | X . 356 | X<----------. 5. Failure Detection 357 | X | 358 | X | 6. HA2 takes over the HA1 359 | X | 360 | X | RECOVERY COMPLETE 362 Figure 1: Overview of Home Agent Virtual Switch 364 5.2. Home Agent Hard Switch 366 The Home Agent Hard Switch is shown in Figure 2. This mode is not 367 transparent to mobile node when there is a home agent failure and 368 another home agent takes over. 370 MN HA1(active) HA2(Standby) 371 | | | 372 |<--------->| | 1. IKE exchange (w/HoA assignment) 373 | | | 374 |---------->| | 2. Binding Update 375 |<----------| | 3. Binding Acknowledgement 376 | | | 377 |<--------------------->| 4. IKE exchange (wo/HoA assignment) 378 | | | 379 | |<--------->| 5. State Exchanges 380 | | | 381 | X | HA1 FAILURE 382 | X | 383 | X<----------| 6. Failure Detection 384 | X | 385 |<----------------------| 7. Sending home agent 386 | X | Switch message 387 | X | 388 |<--------------------->| 8. Binding Registration (optional) 389 | X | 390 | X | RECOVERY COMPLETE 392 Figure 2: Overview of Home Agent Hard Switch 394 In this mode, a mobile node establish IPsec SA with multiple home 395 agents beforehand. When an Active Home Agent fails, the other 396 Standby Home Agent could use pre-existing IPsec SA to notify the 397 Mobile Node about the failure. After the notification, the mobile 398 node will use the Standby Home Agent as its home agent. 400 In order to discover the home agent address, two different mechanisms 401 are defined in the bootstrapping solution in split scenario. One is 402 DNS lookup by home agent Name, the other is DNS lookup by Service 403 Name. The mobile node sends a DNS SRV request and acquires IP 404 addresses and preferences of a redundant home agent set. In 405 integrated scenario, DHCPv6 is used to provide home agent provision 406 to Mobile Node. 408 The mobile node establishes IPsec/IKE state with the other acquired 409 home agents beforehand (1 and 4), however it registers only with the 410 Active Home Agent (2 and 3). The Active Home Agent synchronizes 411 required states of mobile nodes such as Binding Cache information and 412 AAA information, etc. with other standby home agents periodically 413 (5). 415 When the Standby Home Agent detects the failure of the active home 416 agent (6), it sends a home agent switch message to all the mobile 417 nodes that were registered to the Failed Home Agent (7). The home 418 agent switch message must be encrypted by pre-established IPsec SA. 419 After the switch message, the mobile node MAY send a binding update 420 and registers it with the new Active Home Agent in order to update 421 MIP6 tunnel's end points (8). However, this binding registration can 422 be skipped since the Standby Home Agent synchronizes the binding 423 cache information with the Active Home Agent periodically. The 424 mobile node only changes its home agent address to the new Active 425 Home Agent. 427 5.3. Failure Detection and Home Agent Management 429 HA1(active) HA2 HA3 .. HAn 430 | | | | 431 |<------>| | | 1. Hello exchange 432 |<------------->| | 433 |<-------------------->| 434 | | | | 435 (Failed) | | | A FAILURE OCCURS 436 X | | | 437 X | | | 3. Standby HAs detects 438 X | | | failure. 439 X | | | 440 X (active) | | 4. HA2 becomes Active HA 441 X | | | 442 | | | | HA1 RECOVER NOW 443 (standby) | | | 444 |------->| | | 5. HA1 sends SwitchOver Request 445 |<-------| | | 6. HA2 sends SwitchOver Reply 446 | | | | 447 (active) (standby) | | 7. HA1 returns to active HA 448 | | | | 449 | | | | HA1 BECOMES ACTIVE AGAIN 451 Figure 3: Home Agent Management 453 Figure 3 illustrates the mechanism by which a Standby Home Agent 454 takes over from a failed home agent. This operation is common for 455 both the hard and the virtual switch modes. The home agent whose 456 preference is the highest among the Standby Home Agents takes over 457 immediately after it detects failure of the Active Home Agent. The 458 preference value can be same as the home agent preference value of 459 RFC3775, while the operator can define an independent value only for 460 home agent reliability protocol. 462 The Home Agents in the redundant Home Agent set exchange periodic 463 Hello messages to convey their information to the peers (1). The 464 Hello messages can either be unicast or multicast. In order to 465 explicitly query the state information of its peer(s), any Home Agent 466 can send a Hello request to its peer(s) in the redundant Home Agent 467 set. The Hello message exchange is the basis of failure detection 468 and automatic switchover in this scheme (3 and 4). 470 When HA1 recovers in Figure 3, it needs to remain in the standby 471 state. This prevents it to automatically take over from the 472 currently active Home Agent. HA1 sends a SwitchOver Request to the 473 currently active Home Agent (i.e. HA2) only if the system 474 administrator issues a manual command, if the monitored server fails, 475 if the routing peer/link fails. The currently Active Home Agent can 476 be known through the exchange of Hello messages. HA1 may need to 477 send Hello Request message to all the Standby Home Agents, when it 478 recovered from the failure. When HA2 receives the Home Agent 479 SwitchOver Request from HA1 it changes its state to standby and sends 480 back the SwitchOver Reply message to HA1. HA1 returns to active home 481 agent status immediately after receiving the SwitchOver reply. 483 HA1(active) HA2 HA3 .. HAn 484 | | | | 485 |------->| | | 1. HA1 sends SwitchBack Request 486 |<-------| | | 2. HA2 sends SwitchBack Reply 487 | | | | 488 (standby) (active) | | HA2 BECOMES ACTIVE HA 489 | | | | 490 SYSTEM MAINTENANCE, ETC. 491 | | | | 492 |------->| | | 3. HA1 sends SwitchOver Request 493 |<-------| | | 4. HA2 sends SwitchOver Reply 494 | | | | 495 (active) (standby) | | 5. HA1 returns to active HA 496 | | | | HA1 BECOMES ACTIVE AGAIN 498 Figure 4: Manual Home Agent Change 500 In some scenarios the Active Home Agent may need to stop serving the 501 mobile nodes for system maintenance. This specification provides 502 manual home agent change by using Home Agent SwitchBack Request and 503 Reply messages. As shown in Figure 4, the Active Home Agent (HA1) 504 sends Home Agent SwitchBack Request to an Standby Home Agent. As 505 soon as HA2 receives the message, it becomes the Active Home Agent. 506 HA2 also acknowledges with the Home Agent SwitchBack reply to HA1. 507 HA1 becomes standby when it receives the SwitchBack reply. After the 508 downtime, HA1 sends a Home Agent SwitchOver Request to HA2 in order 509 to return to become an Active Home Agent again. This operation is 510 same as Figure 3 512 6. Messages 514 This document defines following new messages: 516 o New Mobility Header Messages 518 * Home Agent Hello Request Message 520 * Home Agent Hello Message 522 * State Synchronization Request Message 524 * State Synchronization Message 526 * Home Agent SwitchOver Request Message 528 * Home Agent SwitchOver Reply Message 530 * Home Agent SwitchBack Request Message 532 * Home Agent SwitchBack Reply Message 534 o New Mobility Options 536 * Binding Cache Information Option 538 * AAA Information Option 540 * Vendor Specific Information Option 542 We may add more mobility options in the future document. The DT is 543 currently discussing the needs and the formats of IPsec/IKE state 544 information Option and BGP/OSPF modifier option for state 545 synchronization message. 547 Home Agent Switch message is defined in [8]. This message is also 548 used in operation of Home Agent Hard Switch. 550 6.1. New Mobility Header Messages 552 6.1.1. Home Agent Hello Request Message 554 The message is unicasted to a home agent to solicit a Hello message 555 from a home agent. The receiver of this Hello Request message MUST 556 return a Hello message to the originator of this request message. A 557 Home Agent Hello message SHOULD be authenticated and encrypted by 558 IPsec ESP. 560 The Hello Request message has the MH Type value TBD. When this value 561 is indicated in the MH Type field, the format of the Message Data 562 field in the Mobility Header is as follows: 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Sequence # | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 . . 571 . Mobility Options . 572 . . 573 . | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 5: Home Agent Hello Request Message 578 Sequence # 580 16-bit unsigned integer. The Sequence number of the Hello message 581 can be used to verify whether this Hello message is the latest one 582 or not. 584 Mobility Options 586 Variable-length field of such length that the complete Mobility 587 Header is an integer multiple of 8 octets long. This field 588 contains zero or more TLV-encoded mobility options. The encoding 589 and format of defined options are described in Section 6.2 of [1]. 590 The receiver MUST ignore and skip any options which it does not 591 understand. There MAY be additional information, associated with 592 this HELLO Request message that need not be present in all HELLO 593 Request messages sent. Mobility options allow future extensions 594 to the format of the HELLO Request message to be defined. 596 If no options are present in this message, no padding is necessary 597 and the Header Len field will be set to 1. 599 6.1.2. Home Agent Hello Message 601 The message is either unicasted or multicasted to carry Home Agent 602 information among the Redundant home agent set. This Hello message 603 is used by any home agents to detect the failure of a redundant peer 604 in the redundant Home Agent set. This message can be sent either 605 periodically or in reply to Hello Request message. A home agent 606 Hello message SHOULD be authenticated and encrypted by IPsec ESP when 607 it is unicasted. If a Hello message is multicasted, IPsec ESP cannot 608 be applied. Hence if multicast is used, the redundant Home Agent set 609 should be in a secure network. 611 The Standby Home Agents and the Active Home Agent must exchange the 612 home agent information. Although Mobile IPv6 uses a router 613 advertisement to exchange home agent information periodically, the 614 Hello message can be replaced with the router advertisement. 616 If the Standby Home Agent misses this Hello message from it's peer 617 Active Home Agent for a configured number of times, it SHOULD assume 618 that the Active Home Agent has failed. If the active home agent does 619 not periodically send the Hello message, each standby home agent 620 needs to solicit it by sending a Hello Request message. 622 The Hello message has the MH Type value TBD. When this value is 623 indicated in the MH Type field, the format of the Message Data field 624 in the Mobility Header is as follows: 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Sequence # | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Home Agent Preference | Home Agent Lifetime | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Hello Interval | Group ID |A| Reserved | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | | 636 . . 637 . Mobility Options . 638 . . 639 . | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 6: Home Agent Hello Message 644 Sequence # 646 16-bit unsigned integer. The Sequence number of the Hello message 647 can be used to verify whether this Hello message is the latest one 648 or not. 650 Home Agent Preference 652 16-bit unsigned integer. The preference for the home agent 653 sending this hello. This preference is same as the home agent 654 preference value of home agent information option defined in 655 Mobile IPv6. However, if operators want to use the different 656 preference value for this operation, it can use different value 657 from the preference defined in RFC3775 659 Home Agent Lifetime 661 16-bit unsigned integer. The lifetime for the home agent sending 662 this Hello. This lifetime is same as the home agent Lifetime 663 value of home agent information option defined in Mobile IPv6. 665 Hello Interval 667 16-bit unsigned integer. The interval for the home agent sending 668 this Hello. 670 Group Identifier 672 8-bit unsigned integer. This value is used to identify a 673 particular redundant home agent set. 675 A flag 677 If this flag is set, the sender of this Hello message is an Active 678 Home Agent. Otherwise, the sender is Standby Home Agent 680 Reserved 682 7-bit unsigned integer. It must be initialized to zero by the 683 sender and must be ignored by the receiver. 685 Mobility Options 687 Variable-length field of such length that the complete Mobility 688 Header is an integer multiple of 8 octets long. This field 689 contains zero or more TLV-encoded mobility options. The encoding 690 and format of defined options are described in [1]. The receiver 691 MUST ignore and skip any options which it does not understand. 693 The following options are valid in a Hello: 695 * IP Address Option (Sub-type: Home Agent Address): A Home Agent 696 Address and its Prefix Length are stored in an IP address 697 option. If there are multiple home network prefixes serving by 698 a home agent, multiple IP address options should be used in a 699 Hello message. 701 If no options are present in this message, 0 octets of padding are 702 necessary and the Header Len field will be set to 2. 704 6.1.3. State Synchronization Request Message 706 This message is used to request state corresponding to a particular 707 mobile node. It is a unicast message and MUST be authenticated. The 708 State Synchronization Request message is used to solicit the active 709 state corresponding to a particular Mobile Node. The format of the 710 message is as follows: 712 The State Synchronization Request has the MH Type value TBD. When 713 this value is indicated in the MH Type field, the format of the 714 Message Data field in the Mobility Header is as follows: 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Identifier | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 . . 723 . Mobility Options . 724 . . 725 . | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Figure 7: State Synchronization Request Message 730 Identifier 732 The 16-bit identifier to aid in matching state synchronization 733 message. The identifier should never be set to 0. It should 734 always be more than 1. 736 Mobility Options 738 Variable-length field of such length that the complete Mobility 739 Header is an integer multiple of 8 octets long. This field 740 contains zero or more TLV-encoded mobility options. The encoding 741 and format of defined options are described in [1]. The receiver 742 MUST ignore and skip any options which it does not understand. 744 The following options are valid in a State Synchronization Request 745 message. One of the following options is mandatory in State 746 Synchronization Request message. : 748 * IP Address Option (Sub-type: Home Address)[9]. If a Home 749 Agents wants the Binding Cache information for a particular 750 Mobile Node, it includes an IPv6 Address Option (Sub-type: Home 751 Address). 753 * Mobile Network Prefix Option: If a home agent wants to know the 754 forwarding state setting up for a particular Mobile Network 755 Prefix, it includes a Mobile Network Prefix Option defined in 756 [2]. 758 If no options are present in this message, no padding is necessary 759 and the Header Len field will be set to 1. 761 6.1.4. State Synchronization Message 763 The State Synchronization message is used between the home agents in 764 the Home Agent redundant set to exchange binding cache information, 765 IPsec state and any other information related to providing mobility 766 service to the mobile nodes. It is an unicast message. The state 767 synchronization can be sent by an active home agent either 768 periodically or in response to a state synchronization Request 769 message. 771 The State Synchronization message has the MH Type value TBD. When 772 this value is indicated in the MH Type field, the format of the 773 Message Data field in the Mobility Header is as follows: 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Identifier | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | | 781 . . 782 . Mobility Options . 783 . . 784 . | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Figure 8: State Synchronization Message 788 Identifier 790 The 16-bit identifier to aid in matching state synchronization 791 reply message. The identifier should never be set to 0. It 792 should always be more than 1. 794 Mobility Options 796 Variable-length field of such length that the complete Mobility 797 Header is an integer multiple of 8 octets long. This field 798 contains zero or more TLV-encoded mobility options. The encoding 799 and format of defined options are described in [1]. The receiver 800 MUST ignore and skip any options which it does not understand. 802 The following options are valid in a State Synchronization 803 message. One of the following options is mandate in State 804 Synchronization message. : 806 * Binding Cache Information Option. 808 * AAA Information Option. 810 * Vendor Specific Information Option. 812 This message requires at least one of mobility options. Therefore, 813 there is no default length for this message. 815 6.1.5. Home Agent SwitchOver Request Message 817 This message is unicasted by a Standby Home Agent that desires to 818 become the Active Home Agent for all the Mobile IPv6 sessions. The 819 receiver of the message MUST transit to inactive state as soon as the 820 message is received and validated. 822 The Home Agent SwitchOver Request message has the MH Type value TBD. 823 The message MUST be authenticated and encrypted by IPsec ESP.When 824 this value is indicated in the MH Type field, the format of the 825 Message Data field in the Mobility Header is as follows: 827 0 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Reserved | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Figure 9: Home Agent SwitchOver Request Message 834 No padding is necessary and the Header Len field will be set to 1. 836 6.1.6. Home Agent SwitchOver Reply Message 838 This message is used to acknowledge the receipt of the corresponding 839 Home Agent SwitchOver Request message. The reply message should 840 contain status_code field to convey the result of processing the 841 received Home Agent SwitchOver Request message. 843 The Home Agent SwitchOver message has the MH Type value TBD. When 844 this value is indicated in the MH Type field, the format of the 845 Message Data field in the Mobility Header is as follows: 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Status | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 Figure 10: Home Agent SwitchOver Reply Message 855 Status 857 16-bit Status value. Values of Status field greater than or equal 858 to 128 indicate that the Home Agent SwitchOver Request was 859 rejected by the receiving node. The following Status values are 860 currently defined: 862 0: success 864 128: The receiver of the Home Agent SwitchOver Request message 865 is not the Active Home Agent 867 129: failed, Admin Prohibited. 869 No padding is necessary and the Header Len field will be set to 1. 871 6.1.7. Home Agent SwitchBack Request Message 873 This message is unicasted by an Active Home Agent that desires to 874 become the inactive Home Agent for all the Mobile IPv6 sessions. The 875 receiver of this message SHOULD transit to active state as soon as 876 the message is received and validated. 878 The Home Agent SwitchBack Request message has the MH Type value TBD. 879 The message MUST be authenticated and encrypted by IPsec ESP. When 880 this value is indicated in the MH Type field, the format of the 881 Message Data field in the Mobility Header is as follows: 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Reserved | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 Figure 11: Home Agent SwitchBack Request Message 891 No padding is necessary and the Header Len field will be set to 1. 893 6.1.8. Home Agent SwitchBack Reply Message 895 This message is used to acknowledge the receipt of the corresponding 896 Home Agent SwitchBack Request message. The message should contain 897 status_code field to convey the result of processing Home Agent 898 SwitchBack Request message. 900 The Home Agent SwitchBack Reply message has the MH Type value TBD. 901 When this value is indicated in the MH Type field, the format of the 902 Message Data field in the Mobility Header is as follows: 904 0 1 2 3 905 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 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Status | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Figure 12: Home Agent SwitchBack Reply Message 912 Status 914 16-bit Status value. Values of Status field greater than or equal 915 to 128 indicate that the Home Agent SwitchBack Request was 916 rejected by the receiving node. The following Status values are 917 currently defined: 919 0: success 920 128: The receiver of Home Agent SwitchBack Request is already 921 the Active Home Agent 923 129: failed, Admin Prohibited. 925 No padding is necessary and the Header Len field will be set to 1. 927 6.2. New Mobility Options 929 6.2.1. IP address Option 931 This option is already defined at FMIP specification[9]. This 932 document introduces new Sub-Type value for home agent address and 933 Home Address. 935 Option-Code 937 * 4: Home Agent Address 939 * 5: Home Address 941 6.2.2. Binding Cache Information Option 943 The binding cache information option has an alignment requirement of 944 8n+2. Its format is as follows: 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Type = TBD | Length = 40 | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Flags | Sequence Number | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Lifetime | Reserved | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | | 956 + + 957 | Home Address | 958 + + 959 | | 960 + + 961 | | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | | 964 + + 965 | | 966 + Care-of Address + 967 | | 968 + + 969 | | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 . . 972 . . 973 . Mobile Network Prefix Option . 974 . . 975 . | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 Figure 13: Binding Cache Information Option 980 The binding cache information option is valid in a state 981 synchronization message. 983 The fields of Home Address, Care-of Address, Flags, Sequence Number, 984 and Lifetime are copied from the registered binding of a particular 985 Mobile Node or Mobile Router. 8-bit Reserved field MUST be set to 986 zero. 988 If the R-flag is set to indicate this binding cache entry is for a 989 Mobile Router, then this option will be immediately followed by one 990 or more Mobile Network Prefix options. 992 6.2.3. AAA Information Option 994 The AAA option is used to carry the AAA state of the Mobile Node's 995 MIP6 sessions. The AAA state information can be conveyed in RADIUS 996 or Diameter AVP formats including the user and session info. This 997 information option is valid in a state synchronization message. 999 0 1 2 3 1000 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 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Type = TBD | Length | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 . . 1005 . . 1006 . AAA AVPs . 1007 . . 1008 . | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 Figure 14: Vendor Specific Inforamtion Option 1013 Type 1015 8-bit Type value. The value is TBD. 1017 Length 1019 8-bit length value. 1021 AAA AVPs 1023 Series of TLV encoded AAA AVPs (including vendor specific AVPs) 1024 carrying AAA related information for each MIP6 and IPsec/IKE 1025 sessions. 1027 Reserved 1029 16-bit field reserved for future use. The value SHOULD be 1030 initialized to zero by the sender, and MUST be ignored by the 1031 receiver. 1033 6.2.4. Vendor Specific Information Option 1035 The Vendor Specific information option is used to carry the vendor 1036 specific information of a home agent. The Vendor Specific 1037 information option is valid in a state synchronization message. 1039 0 1 2 3 1040 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 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Type = TBD | Length | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Vendor Code | Reserved | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 . . 1047 . . 1048 . Vendor Specific Information . 1049 . . 1050 . | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Figure 15: Vendor Specific Inforamtion Option 1055 Type 1057 8-bit Type value. The value is TBD. 1059 Length 1061 8-bit length value. 1063 Vendor Code 1065 16-bit vendor code can be defined by each vendor. 1067 Reserved 1069 16-bit field reserved for future use. The value SHOULD be 1070 initialized to zero by the sender, and MUST be ignored by the 1071 receiver. 1073 7. Home Agent Operation 1075 7.1. Home Agent Configuration 1077 There are two approaches to place Standby Home Agents. The first 1078 configuration is that a Standby Home Agent is located at the same 1079 link (i.e. home link) of home agents. Another one is that the 1080 Standby Home Agent is located at the different link from the home 1081 link. The differences are whether home agent and Standby Home Agents 1082 share the link or not. 1084 HA1 HA2 HA3 HA4 .... HAn 1085 | | | | | 1086 --------+------+------+------+--------+--------- 1087 Home Link 1089 Figure 16: Local Recovery Configuration 1091 Figure 16 depicts the configuration where home agents serving the 1092 same home network are located on the same link. For example, HA3 and 1093 HA4 are Standby Home Agents of HA1 and HA2. This is what Mobile IPv6 1094 defines for home agent configuration. 1096 HA1 HA2 HA3 HA4 1097 | | | | 1098 --------+------+-----+ R +-----+------+------- 1099 Home Link Router Recovery Link 1101 Figure 17: Global Recovery Configuration 1103 Figure 17 illustrates when standby home agents are located on 1104 different link (named recovery link in the figure). For example, HA3 1105 and HA4 are standby home agents of HA1 and HA2. In this case, HA3 1106 and HA4 cannot receive the packets meant for the home network till 1107 the route on the Router is changed. The advantage of this 1108 configuration is that Standby Home Agents can recover the failure of 1109 the home link. If the home link becomes unreachable, the local 1110 recovery is useless. However, this configuration can achieve the 1111 home agent recovery even if the entire home link fails. In this 1112 configuration, the routing must be also updated to direct the packets 1113 meant for the home link to the recovery link. 1115 Each Standby Home Agent obtains its individual IP address from the 1116 link. This IP address is used for home agent reliability protocol to 1117 exchange information with the associated home agent. The link 1118 between home agents should be secured. 1120 When Home Agent Virtual Switch is used, the home agent's IP address 1121 which is known by the mobile node can be shared with Standby Home 1122 Agents. When a home agent fails, the standby home agent takes the IP 1123 address out of the failed home agent. Then the Standby Home Agent 1124 can uses the IP address for further home agent operations as being an 1125 Active Home Agent. The Standby Home Agent should not activate the IP 1126 address until the Active Home Agent is dead and the reachability to 1127 the IP address is lost. Otherwise, address duplication will occurs. 1128 This operation is normally done using route selector such as BGP and 1129 OSPF modifier. As an example we can use the AS_Path prepend 1130 operation for BGP and Metric field in the OSPF for route selection. 1131 The Ha reliability DT may define a new mobility option to carry 1132 respective BGP/OSPF modifier information. 1134 Alternatively, in Home Agent Hard Switch case, The home agent address 1135 may be different, but the home addresses and the home link prefix are 1136 the same. In this case, all the reachability of mobile nodes will be 1137 lost during the recovery procedure, since the IP address of Failed 1138 Home Agent is no longer active and all the packets meant for the IP 1139 address will be discarded. The Standby Home Agent must notify mobile 1140 nodes to change the associating home agent. Thus, the mobile node 1141 will detect the home agent changes by knowing the new IP address of 1142 the standby home agent. The home agent has to use the same technique 1143 as in virtual switch mode to advertise the routes into the routing 1144 infrastructure. 1146 7.2. Hello messages Manipulation 1148 Mobile IPv6 [1] defines a mechanism for maintaining a home agent list 1149 when there are multiple home agents present on a link. It is based 1150 on each home agent sending a router advertisement periodically on the 1151 home link with a Home Address Information option [1]. However, this 1152 mechanism is governed by how a router sends a router advertisement as 1153 defined in [4]. There are restrictions on how often a router 1154 advertisement can be sent and on how they are processed by routers 1155 that receive them. Moreover, the router advertisements are not sent 1156 frequently enough to rely on the absence of the router advertisement 1157 to detect a home agent failure. Moreover, when home agents are 1158 placed at different links, Router Solicitation and Advertisement 1159 messages [4] can not be used due to link-local limitation. 1161 In this document, new Mobility Header messages are defined in 1162 Section 6.1.1 and Section 6.1.2 to notify similar information of 1163 Router Advertisement among home agents over the home link. 1165 7.2.1. Sending Hello Request 1167 A home agent can solicit a Hello message by sending a Hello Request 1168 message. The Hello Request message is unicasted to an Active Home 1169 Agent or a Standby Home Agent. This message should be encrypted and 1170 authenticated by IPsec ESP mode. An originator of the Hello Request 1171 message must specify the random sequence value. The sequence value 1172 is used to match the Hello message which is sent from the receiver of 1173 the Hello Request message. 1175 7.2.2. Receiving Hello Request 1177 When a home agent receives a hello Request message, it SHOULD verify 1178 correct IPsec protection. If the message is not protected, it SHOULD 1179 be silently discarded. However, if the Hello messages can be sent on 1180 a dedicated link between the home agents and in such a case, IPsec 1181 protection is not required. 1183 If the sender home agent is not in the same redundant home agent set, 1184 the message MUST be silently ignored, too. 1186 The sequence field should be copied to the Hello message which will 1187 be sent in reply to the hello Request message. This sequence number 1188 is used as a transaction ID for the Hello message exchange. 1190 7.2.3. Sending Hello 1192 A home agent Hello message MUST be constructed with same information 1193 of a Router Advertisement message described in section 7 of [1]. The 1194 Hello messages can be unicasted or multicasted. A new multicast 1195 address will be assigned by the IANA. All the home agents on the 1196 home link should join this multicast address. When the Hello 1197 messages are used for maintaining the home agents list, the home 1198 agent SHOULD NOT use the home agent Information option in the router 1199 advertisements to manage the home agents list. 1201 The Hello message MUST be sent when a home agent is requested by a 1202 hello Request message. The Hello message can be also periodically 1203 sent. In addition, the home agent SHOULD send a home agent Hello 1204 message to home agents of the redundant home agent set when it boots 1205 up and its local information such as preference, lifetime, and 1206 registration status, etc. change. The interval between two Hello 1207 messages is configurable on the home agents. When a new home agent 1208 boots up, it SHOULD wait a particular time to listen home agent Hello 1209 messages of all configured Home Agents. Alternatively, it can 1210 solicit Hello message by sending a Hello Request message. 1212 If a home agent is the Active Home Agent, it MUST set A flag in Hello 1213 Messages. 1215 7.2.4. Receiving Hello 1217 The receiver of a Home Agent Hello message MUST verify the source 1218 address field of the IPv6 header. If a Home Agent Hello message is 1219 received from unknown home agent, the message MUST be silently 1220 dropped. If the source address is not in the list of known home 1221 agents, the message MUST be silently dropped. In addition to this 1222 source address check, Group ID is introduced in this document. This 1223 Group ID is used to identify a particular redundant home agent set. 1224 If the Group ID field is specified in a Hello message, the receiver 1225 MUST process only the Hello which group ID is matched. This Group ID 1226 is verified when the Hello message is multicasted. The Hello message 1227 MUST NOT be sent to a home agent whose Group ID is different from the 1228 sender. If the Group ID is set to zero, the receiver MUST ignore 1229 this field. 1231 Any Home Agent Hello message satisfying all of these tests MUST be 1232 processed to update its home agent list. The Home Agents list can be 1233 ordered based on the home agent preference value. If the home agent 1234 lifetime field in the Hello message is set to 0, the receiver removes 1235 the sender home agent that from the home agents list. 1237 7.3. Failure Detection 1239 When a home agent meets an error and cannot fulfill home agent 1240 functionality, the Standby Home Agent must detect the failure and 1241 should act as the Active Home Agent. The failure detection is 1242 important feature of Home Agent local reliability. 1244 The most common way to detect failure is using periodic message 1245 exchange such as Hello of routing protocols. This mechanism is often 1246 used to detect failure on many protocols. In the real scenario, when 1247 a home agent crashed, it can happened that only home agent 1248 functionality is down and network reachability to home agent is 1249 alive. In this case, ICMP type of message such as ping can not be 1250 used to detect the home agent failure. Therefore, we define a new 1251 Hello message to detect the home agent failure. 1253 The Active and the Standby Home Agents exchange periodic Hello 1254 messages to monitor one another's status. Hello request message may 1255 be used by any Home Agent to explicitly request state information 1256 from any other Home Agent in the redundant Home Agent set. If a Home 1257 Agent Hello message is not received from a Home Agent peer within a 1258 configurable amount of time, then that home agent peer is considered 1259 to have failed. 1261 Example Failure Events: 1263 Loss of Communication with the Active Peer Home Agent 1265 The redundant Home Agent set should have knowledge of each others 1266 state. In order to achieve that, we define Hello message 1267 exchanges. In the event that the Home Agent that is currently 1268 inactive does not receive any Hello message from its peer which is 1269 currently active for a configurable duration, the Home Agent may 1270 decide to become active. 1272 Monitored Server Failure by the Active Home Agent 1274 There may be number of critical servers in the network that are 1275 essential for the ongoing Mobile IPv6 session at the Home Agent. 1276 One such server may be the AAA server which is receiving the 1277 accounting information for the session. The operator may have a 1278 policy in place that requires the Home Agent to initiate 1279 SwitchOver procedure upon detecting that the link to such a server 1280 has failed. 1282 Routing Peer/Link Failure 1284 In some cases, the operator may like the Home Agent to detect a 1285 next hop routing peer failure. If the next hop routing peer 1286 fails, the operator may want the Home Agent to initiate SwitchOver 1287 if the failure is fatal in nature or due to some other routing 1288 policies. 1290 7.4. Active Home Agent Change 1292 There are two cases when a Standby Home Agent takes over an Active 1293 Home Agent. The first case is when a Standby Home Agent detects 1294 failure of the Active Home Agent described in Section 7.3. The 1295 Standby Home Agent immediately becomes an Active Home Agent. The 1296 second case is when a home agent receives a Home Agent SwitchOver 1297 Request message described in Section 7.6. 1299 Upon detecting failure of an Active Home Agent, the Standby Home 1300 Agent becomes Active. If there are more than one Standby Home Agent 1301 or when there are two Home Agents in the redundant Home Agent set, 1302 but both of them boots up at the same time, two values are used to 1303 break any tie. The Home Agent with lowest BGP/OSPF modifier value 1304 becomes Active. If the BGP/OSPF modifiers are the same, then the 1305 home agent preference values (configured by the system administrator) 1306 is used to break the tie. 1308 When the Standby Home Agent becomes active, it MUST start to 1309 advertise the home agent address and the home prefix of the home 1310 addresses serviced by the redundant home agent set into the routing 1311 infrastructure. This is operated by using route selector such as BGP 1312 and OSPF modifier. In addition, if necessary, the new active home 1313 agent must overwrite the neighbor entries of the mobile nodes in 1314 order to intercept packets of the mobile nodes. 1316 7.5. Processing State Synchronization Messages 1318 It is necessary for Standby Home Agent to synchronize the state 1319 information of each mobile node stored in the active home agent. In 1320 Home Agent Virtual Switch mode, the synchronized state information is 1321 used by a Standby Home Agent when it takes over the Failed Home 1322 Agent. In Home Agent Hard Switch mode, the Standby Home Agent starts 1323 the trigger to all the mobile nodes registering to the Failed Home 1324 Agent when the home agent failure is detected. This state 1325 synchronization must be securely operated. 1327 7.5.1. Sending State Synchronization Request 1329 When a Standby Home Agent wants state for a particular Mobile Node 1330 such as Binding Cache, AAA, etc, it can solicit State Synchronization 1331 message by sending State Synchronization Request. This is optional 1332 operation of a standby home agent. The Standby Home Agent MUST set a 1333 random value to the Identifier field in the state synchronization 1334 Request message and MUST include either a Home Address mobility 1335 option or a Mobile Network Prefix mobility option. The Standby Home 1336 Agent can store multiple home address mobility options or mobile 1337 network prefix mobility options to request state information for 1338 multiple mobile nodes by a single state synchronization Request 1339 message. 1341 7.5.2. Receiving State Synchronization Request 1343 If the received state synchronization Request message is not 1344 protected by IPsec ESP, the message must be silently discarded. If 1345 the sender home agent is not belong to the same redundant home agent 1346 set, the message must be silently ignored. Moreover, if a receiver 1347 is not the Active Home Agent for the requested home address or mobile 1348 network prefix, it MUST silently discard the message. Otherwise, the 1349 receiver MUST reply with a State Synchronization message including 1350 state information for the requested mobile node(s). 1352 7.5.3. Sending State Synchronization 1354 A state synchronization message can be sent either: 1356 o when an Active Home Agent receives a state synchronization Request 1357 message 1359 o when an Active Home Agent creates/updates binding cache for a 1360 particular Mobile Node. 1362 o in a periodic interval to update the state info for all sessions 1363 that changed since last update. 1365 If an Active Home Agent sends the state synchronization message 1366 whenever the local state information such as binding cache changed, 1367 the size of the state synchronization message are large. The Active 1368 Home Agent should update the state information with an interval which 1369 is configured by system administrator. 1371 The binding cache of the requested Mobile Node are stored in the 1372 state synchronization message. The Active Home Agent MUST copy the 1373 binding cache of the requested Mobile Node to each fields of a 1374 binding cache information option. If the state synchronization 1375 message is sent in response to the state synchronization Request 1376 message, the Active Home Agent MUST copy the Identifier field of the 1377 state synchronization Request message to the same filed in the state 1378 synchronization message. Otherwise, it MUST set zero to the 1379 Identifier field. 1381 The Active Home Agent can store state of multiple mobile nodes in a 1382 state synchronization message 1384 7.5.4. Receiving State Synchronization 1386 A state synchronization message MUST be authenticated and encrypted 1387 by IPsec ESP mode. If not, the message MUST be ignored. When a Home 1388 Agent receives a state synchronization message, it MUST verify the 1389 Source address field of the IPv6 header. If the source address do 1390 not belong to any home agents of the redundant home agent set, the 1391 message MUST be silently discarded. The receiver home agent SHOULD 1392 record the state and the Active Home Agent address into its Binding 1393 Cache. 1395 7.6. Processing Home Agent SwitchOver Messages 1397 7.6.1. Sending Home Agent SwitchOver Request 1399 When a Standby Home Agent decides to become an active home agent, it 1400 MAY send a home agent SwitchOver Request message to an Active Home 1401 Agent. The reason for the Standby Home Agent to send this message is 1402 administrative intervention. The Standby Home Agent sends with a 1403 mobility header which type is set to the home agent SwitchOver 1404 Request type. This message must be encrypted and authenticated by 1405 IPsec ESP. The Active Home Agent MUST NOT generate this message. 1407 7.6.2. Sending Home Agent SwitchOver Reply 1409 A home agent SwitchOver reply is sent in reply to a home agent 1410 SwitchOver Request message. When a home agent receives a home agent 1411 SwitchOver Request message, it first verifies the message. If the 1412 request message is not protected by IPsec, it MUST be silently 1413 discarded. In addition, if the sender home agent is not belong to 1414 the same redundant home agent set, the message MUST be silently 1415 discarded. 1417 If a receiver home agent is not an Active Home Agent, it replies a 1418 home agent SwitchOver reply which status field set to 128. 1419 Otherwise, the receiver home agent MUST become a Standby Home Agent 1420 and replies a home agent SwitchOver reply which status field set to 1421 zero. 1423 7.6.3. Receiving Home Agent SwitchOver Reply 1425 If a home agent receives a home agent SwitchOver reply, the message 1426 MUST be protected by IPsec. Otherwise, the message MUST be silently 1427 discarded. If a receiver home agent did not send a home agent 1428 SwitchOver Request beforehand, the message MUST be silently 1429 discarded. 1431 If the status field of the SwitchOver reply message indicates zero, 1432 the receiver Standby Home Agent immediately becomes an Active Home 1433 Agent. If the status value is greater than 128, an error is 1434 occurred. Thus, the receiver cannot be an active home agent. 1436 7.7. Processing Home Agent SwitchBack Messages 1438 7.7.1. Sending Home Agent SwitchBack Request 1440 When an Active Home Agent decides to become an in-active home agent 1441 (i.e. Standby Home Agent), it MAY send a home agent SwitchBack 1442 Request message to a Standby Home Agent. The reason for the Active 1443 Home Agent to send this message is administrative intervention, and 1444 events like Monitored Server Failure by the Active Home Agent or 1445 Routing Peer/Link Failure. The Active Home Agent sends it with a 1446 mobility header which type is set to the home agent SwitchBack 1447 Request type. This message must be encrypted and authenticated by 1448 IPsec ESP. A Standby Home Agent MUST NOT generate this message. 1450 7.7.2. Sending Home Agent SwitchBack Reply 1452 A home agent SwitchBack reply is sent in reply to a home agent 1453 SwitchBack Request message. When a home agent receives a home agent 1454 SwitchBack Request message, it first verifies the message. If the 1455 request message is not protected by IPsec, it MUST be silently 1456 discarded. In addition, if the sender home agent is not belong to 1457 the same redundant home agent set, the message MUST be silently 1458 discarded. If the sender home agent of SwitchBack Request message is 1459 not an Active Home Agent, the message MUST be silently discarded. 1461 If a receiver home agent of SwitchBack Request message is already an 1462 Active Home Agent, it replies home agent SwitchBack reply which 1463 status field set to 128. Otherwise, the receiver home agent MUST 1464 become an Active Home Agent and replies a home agent SwitchBack reply 1465 which status field set to zero. 1467 7.7.3. Receiving Home Agent SwitchBack Reply 1469 If a home agent receives a home agent SwitchBack reply, the message 1470 MUST be protected by IPsec. Otherwise, the message MUST be silently 1471 discarded. If a receiver home agent did not send a home agent 1472 SwitchBack Request message beforehand, the message MUST be silently 1473 discarded, too. 1475 If the status field of the SwitchBack reply message indicates zero, 1476 the receiver home agent immediately becomes an in-Active Home Agent. 1477 If the status value is greater than 128, some error is occurred. 1478 Thus, the receiver cannot be an in-active home agent and MUST 1479 continue to be an Active Home Agent. 1481 7.8. Sending Home Agent Switch Message 1483 If an Active Home Agent fails, another Standby Home Agent on the home 1484 link can take over the Failed Home Agent in the Home Agent Hard 1485 Switch mode. This operation is valid only for the Home Agent Hard 1486 Switch mode. The Standby Home Agent MUST send a home agent Switch 1487 message defined in [8] to all the mobile nodes that were being served 1488 by the Failed Home Agent. The message must be encrypted with pre- 1489 established SA. The standby home agent should include its own IP 1490 address in the home agent switch message. 1492 Note that a Home Agent Switch message is sent to each mobile node 1493 served by the home agent. If there are a large number of mobile 1494 nodes, sending Home Agent Switch messages will cause a lot of 1495 signaling overhead on the network. 1497 8. Mobile Node Operation 1499 Operations described in this section are valid only for the home 1500 agent hard switch mode. When the Home Agent Virtual Switch is used, 1501 all the operations can be skipped. 1503 8.1. Standby Home Agent Addresses Discovery 1505 To provide home agent reliability, one possible solution is that the 1506 Mobile Node authenticate itself to two home agents and creates IPsec 1507 SA with two home agents in bootstrapping. When one home agent fails 1508 the other home agent could use pre-existing SA to notify the Mobile 1509 Node about the failure. 1511 In the Home Agent Hard Switch mode, multiple home agent addresses are 1512 valid in the home network. In order to discover the home agent 1513 address, two different mechanisms are defined in the bootstrapping 1514 solution in split scenario [10]. One is DNS lookup by home agent 1515 Name, the other is DNS lookup by Service Name. Also in integrated 1516 scenario [11], DHCPv6 is used to provide home agent provision to 1517 Mobile Node. 1519 In the split scenario, Mobile Node can use DNS lookup by Service Name 1520 to discover the home agents, as defined in [10]. For example, If 1521 home agent reliability is required by the Mobile Node, DNS lookup by 1522 Service Name method is recommended for Mobile to discovery multiple 1523 home agents addresses. Therefore Mobile Node will query the DNS SRV 1524 records with service name of mip6 and protocol name of ipv6. the DNS 1525 SRV records includes multiple home agents addresses and different 1526 preference value and weight. The mobile node SHOULD choose two home 1527 agents from the Home Agents list according to there preference value. 1528 Then the Mobile Node should authenticate itself to both home agents 1529 via IKEv2 exchange. 1531 In the integrated scenario, Mobile Node can use DHCPv6 to get home 1532 agents provision from MSP or ASP, as already defined in [11]. The 1533 only requirement is that the DHCPv6 response must include multiple 1534 home agent information in order to support home agent reliability. 1536 8.2. IKE/IPsec pre-establishment to Home Agents 1538 After Mobile Node get multiple Home Agent addresses, it need to 1539 trigger multiple IKE exchange with multiple home agents selected from 1540 the Home Agent list. Since both IKEv1 and IKEv2 can be used to 1541 bootstrap Mobile IPv6, this solution does not introduce any new 1542 operations to co-operate with IKEv1 or IKEv2. It should initiate IKE 1543 for home agents as soon as home registration is completed. 1545 The Mobile Node MUST follow standard IKEv2 exchange in bootstrapping 1546 solution of split scenario [10], or IKEv1 bootstrap solution [12]. if 1547 needed by Mobile Node, Home Address configuration maybe included for 1548 the first IKE exchange. After its Home Address is assigned or 1549 approved by the first home agent, Mobile Node SHOULD register itself 1550 to the second home agent by IKE using the same Home Address. 1551 Therefore, no HoA configuration should be used in the second IKEv2 1552 procedure. Note that the Mobile Node sends Binding Update Message to 1553 the first home agent. 1555 8.3. Receiving Home Agent Switch message 1557 A mobile node must follow the operation specified in [8] when it 1558 receives home agent switch message. 1560 When the mobile node receives a Home Agent Switch message, and if the 1561 message contains the IP address of standby home agent, it picks the 1562 Standby Home Agent in the request message as the Active Home Agent 1563 and sends a Binding Update message to it. The mobile node have 1564 already pre-established SA with the home agent and use the SA to send 1565 Binding Update. However, in this specification, the binding cache 1566 information is already synchronized among the redundant home agent 1567 set, the mobile node can skip this binding re-registration to the new 1568 active home agent. In this case, the mobile node only updates the 1569 Home Agent address of all the binding update list, MIP6 tunnel end 1570 points, etc. 1572 9. Security Considerations 1574 Mobile IPv6 depends on IPsec and IKE for binding home registration 1575 described in [5]. A mobile node must encrypt a binding update sent 1576 to a home agent. In addition, the mobile node exchanges HoTI and HoT 1577 messages through a home agent by using IPsec tunnel mode. Therefore, 1578 before a home agent failure, these IPsec states (below is example) 1579 should be synchronized among home agents of a redundant home agent 1580 set. 1582 mobile node may encrypt particular data traffic sent to the Internet. 1584 o Security Policy Database (SPD) and Selector Information 1586 o Security Association (SA) for Binding Registration (SA1 and SA2) 1588 o SA for HoTI/HoT Exchange (SA3 and SA4) 1590 o SA for Mobile Prefix Discovery (SA5 and SA6) 1592 o SA for data packets if any (SA7 and SA8) 1594 The Home Agent reliability scheme for Mobile IPv6 involves IPsec 1595 tunnel SwitchOver upon Home Agent failure. There are various ways 1596 this can be achieved e.g. setting up of multiple IPsec security 1597 associations between the Mobile Node and the Home Agent sets. 1598 Another way could be, the Home Agents periodically check pointing 1599 IPsec session state including the per packet sequence numbers for the 1600 Mobile Node. We can call these two possible Home Agent redundancy 1601 modes as follows: 1603 1. Home Agent Hard Switch. In this mode, the Mobile Node and the 1604 redundant Home Agent set negotiates independent IPsec SAs. 1606 2. Home Agent Virtual Switch. In this mode, the Mobile Node 1607 negotiates just one SA for both the redundant Home Agent set. 1609 In both the cases, the mobile node maintains only one binding cache 1610 at any given time. In the Home Agent Hard Switch case, the mobile 1611 node needs to switch binding from active to Standby Home Agent upon 1612 failover. IPsec redundancy need synchronize both SPD, Selector and 1613 SAD information from one home agent to another home agent. 1615 Since Mobile IPv6 operation requires ESP in transport mode between 1616 the Mobile Node and the Home Agent, we will talk about the ESP field 1617 synchronization issues between the Mobile Node and the redundant set 1618 of Home Agents. Most of fields should be synchronized based on 1619 RFC4301[6]. The ESP header has the following fields: 1621 SPI 1623 This field identifies the SAD at the receiver. 1625 Home Agent Hard Switch Mode 1627 the Mobile Node and the redundant Home Agent set negotiates 1628 separate/independent IPsec SAs. Therefore, the SPI value will 1629 vary depending on which Home Agent the Mobile Node selects to 1630 send/receive data packets. 1632 Home Agent Virtual Switch Mode 1634 The Mobile Node negotiates only one IPsec SA. Hence, the SPI 1635 value will remain unchanged upon Home Agent SwitchOver. 1637 Sequence Number 1639 This field is used for "anti-replay" feature of ESP. The 1640 transmitter must include this monotonically increasing number. 1641 The receiver may process the sequence number based on local 1642 policy. 1644 Home Agent Hard Switch Mode 1646 The Mobile Node and the redundant Home Agent set will have 1647 independent set of sequence numbers. Therefore, the Mobile 1648 Node and the Home Agent needs to choose the most appropriate 1649 sequence number to be used. Synchronization of the sequence 1650 number field between the Home Agents is not mandatory in this 1651 mode of operation. 1653 Home Agent Virtual Swtich Mode 1655 The Mobile Node and the redundant Home Agent set will have the 1656 same set of sequence numbers for transmit and receive. Hence, 1657 synchronization of the sequence number field is mandatory in 1658 this mode of operation. 1660 For MIP6 signaling i.e. BU/BA, HoTi/HoT etc. the SA1, SA2, SA3, 1661 SA4 could be synchronized between the Home Agents as these 1662 messages are not sent continuously. Moreover for the BU Case, if 1663 the Mobile Node is in the middle of sending a BU to the Home Agent 1664 (Active Home Agent) for binding refresh, and the Home Agent is 1665 crashing at that moment. The Mobile Node will not get any 1666 response from the Home Agent. The Mobile Node will retry. After 1667 the Standby Home Agent becomes active, it will receive BU from the 1668 Mobile Node with a sequence number that is +n from its last known 1669 sequence number for SA1. For the BA case (SA2), the Standby Home 1670 Agent SHOULD add a random number to the last known sequence number 1671 over and above the replay window to ensure that the packet passes 1672 replay check at the Mobile Node. The same applies to HoTi and HoT 1673 messages with SA3 and SA4. Note that this windowing of the 1674 sequence numbers for MIP6 signaling is only needed to cover the 1675 corner cases when BU/HoTi is in air and the Active Home Agent 1676 fails. 1678 The technique explained above should work fine for user data 1679 packets if ESP is used to encrypt user data traffic as well. The 1680 actual switchover time and the routing infrastructure convergence 1681 time is the only latency that the user may perceive. 1683 Initialization Vector 1685 Since each time, IV will be delivered between Mobile Node and Home 1686 Agent, so this field is not necessarily synchronized between home 1687 agents. 1689 Others 1691 Other fields should be synchronized based on RFC4301[6] 1693 In Home Agent Hard Switch mode, the Standby Home Agent needs to send 1694 a home agent switch message in secure way ( i.e. required IPsec 1695 encryption to the trigger). The mobile node pre-establishes IPsec SA 1696 with the Standby Home Agent, as well as an active home agent. The 1697 Standby Home Agent can send a trigger to the mobile node with the 1698 pre-established IPsec SA. 1700 10. Contributors 1702 This document is a result of discussions in the Mobile IPv6 Home 1703 Agent Reliability Design Team. The members of the design team are 1704 listed below: 1706 Samita Chakrabarti 1708 samita.chakrabarti@sun.com 1710 Kuntal Chowdhury 1712 kchowdhury@starentnetworks.com 1714 Hui Deng 1716 hdeng@hitachi.cn 1718 Vijay Devarapalli 1720 vijay.devarapalli@azairenet.com 1722 Sri Gundavelli 1724 gundave@cisco.com 1726 Brian Haley 1728 brian.haley@hp.com 1730 Behcet Sarikaya 1732 bsarikaya@huawei.com 1734 Ryuji Wakikawa 1736 ryuji@sfc.wide.ad.jp 1738 11. Acknowledgements 1740 This document includes a lot of text from [13] and [14]. Therefore 1741 the authors of these two documents are acknowledged. We would also 1742 like to thank the authors of the home agent reliability problem 1743 statement [15] for describing the problem succinctly and Alice Qin 1744 for her work on the hello protocol. 1746 12. References 1748 12.1. Normative References 1750 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1751 IPv6", RFC 3775, June 2004. 1753 [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1754 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1755 January 2005. 1757 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1758 Levels", BCP 14, RFC 2119, March 1997. 1760 [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1761 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1763 [5] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1764 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1765 Agents", RFC 3776, June 2004. 1767 [6] Kent, S. and K. Seo, "Security Architecture for the Internet 1768 Protocol", RFC 4301, December 2005. 1770 12.2. Informative References 1772 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 1773 RFC 3753, June 2004. 1775 [8] Haley, B., "Mobility Header Home Agent Switch Message", 1776 draft-ietf-mip6-ha-switch-01 (work in progress), June 2006. 1778 [9] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1779 July 2005. 1781 [10] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1782 draft-ietf-mip6-bootstrapping-split-02 (work in progress), 1783 March 2006. 1785 [11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 1786 the Integrated Scenario", 1787 draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in 1788 progress), October 2005. 1790 [12] Devarapalli, V. and M. Parthasarathy, "Mobile IPv6 1791 Bootstrapping with IKEv1", 1792 draft-devarapalli-mip6-ikev1-bootstrap-01 (work in progress), 1793 March 2006. 1795 [13] Wakikawa, R., "Inter Home Agents Protocol Specification", 1796 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 1797 March 2006. 1799 [14] Devarapalli, V., "Local HA to HA protocol", 1800 draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), 1801 March 2006. 1803 [15] Faizan, J., "Problem Statement: Home Agent Reliability", 1804 draft-jfaizan-mipv6-ha-reliability-01 (work in progress), 1805 February 2004. 1807 Author's Address 1809 Ryuji Wakikawa 1810 Keio University 1811 Department of Environmental Information, Keio University 1812 5322 Endo, Fujisawa, Kanagawa 252-8520 1813 Japan 1815 Email: ryuji@sfc.wide.ad.jp 1817 Intellectual Property Statement 1819 The IETF takes no position regarding the validity or scope of any 1820 Intellectual Property Rights or other rights that might be claimed to 1821 pertain to the implementation or use of the technology described in 1822 this document or the extent to which any license under such rights 1823 might or might not be available; nor does it represent that it has 1824 made any independent effort to identify any such rights. Information 1825 on the procedures with respect to rights in RFC documents can be 1826 found in BCP 78 and BCP 79. 1828 Copies of IPR disclosures made to the IETF Secretariat and any 1829 assurances of licenses to be made available, or the result of an 1830 attempt made to obtain a general license or permission for the use of 1831 such proprietary rights by implementers or users of this 1832 specification can be obtained from the IETF on-line IPR repository at 1833 http://www.ietf.org/ipr. 1835 The IETF invites any interested party to bring to its attention any 1836 copyrights, patents or patent applications, or other proprietary 1837 rights that may cover technology that may be required to implement 1838 this standard. Please address the information to the IETF at 1839 ietf-ipr@ietf.org. 1841 Disclaimer of Validity 1843 This document and the information contained herein are provided on an 1844 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1845 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1846 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1847 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1848 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1849 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1851 Copyright Statement 1853 Copyright (C) The Internet Society (2006). This document is subject 1854 to the rights, licenses and restrictions contained in BCP 78, and 1855 except as set forth therein, the authors retain all their rights. 1857 Acknowledgment 1859 Funding for the RFC Editor function is currently provided by the 1860 Internet Society.