idnits 2.17.1 draft-wakikawa-mip6-nemo-haha-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Overview of Inter Home Agents Protocol' ) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 268: '...entry from the Home Agent List and MAY...' RFC 2119 keyword, line 278: '...their Binding Cache. Home Agents MUST...' RFC 2119 keyword, line 396: '... This message MUST include the Mobil...' RFC 2119 keyword, line 399: '...nt HELLO message MUST be authenticated...' RFC 2119 keyword, line 427: '... This message MUST include either th...' (55 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A Home Agent MUST know other Home Agents which configured in different links beforehand. This is manually configured on each Home Agent. This mechanism MUST be used only between Home Agents on different links serving the same home prefix. It SHOULD not be used between Home Agents on the same link. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1099, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1118, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-22 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '3') == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-05 ** Obsolete normative reference: RFC 2402 (ref. '5') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-01 -- No information found for draft-ietf-nemo-basic-usage - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2461 (ref. '9') (Obsoleted by RFC 4861) == Outdated reference: A later version (-06) exists of draft-ietf-seamoby-mobility-terminology-05 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-mobility-terminology (ref. '10') Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6/NEMO Working Group Ryuji Wakikawa 3 INTERNET DRAFT Keio University/WIDE 4 Category: Standards Track Vijay Devarapalli 5 16 Feb 2004 Nokia 6 Pascal Thubert 7 Cisco Systems 9 Inter Home Agents Protocol (HAHA) 10 draft-wakikawa-mip6-nemo-haha-01.txt 12 Status of This Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes an inter Home Agents (HAHA) protocol to 35 provide multiple Home Agents support for both Mobile IPv6 and the 36 Nemo Basic Support protocol. The HAHA protocol provides Home Agent 37 redundancy and load-balancing for both protocols. The HAHA protocol 38 allows multiple Home Agents to be placed at different links. It also 39 allows a Mobile Node to utilize multiple Home Agents simultaneously. 40 The protocol consists of 3 mechanisms, Home Agent List management, 41 Binding Synchronization, and Home Agent Switching. A Mobile Node 42 picks one Home Agent as its primary Home Agent and registers with it. 43 The primary Home Agent synchronizes the binding cache information 44 with other Home Agents. Any of Home Agents can intercept a packet 45 meant for the Mobile Node and tunnel the packet directly to its 46 current Care-of address. Alternatively, the Home Agent can tunnel 47 the packet to the primary Home Agent. 49 Contents 51 Status of This Memo 1 53 Abstract 1 55 1. Introduction 4 57 2. Terminology 6 59 3. Overview of Inter Home Agents Protocol 7 61 4. Message Formats 10 62 4.1. New Mobility Header Messages . . . . . . . . . . . . . . 10 63 4.1.1. Home Agent HELLO Message . . . . . . . . . . . . 10 64 4.1.2. Binding Information Request Message . . . . . . . 11 65 4.1.3. Binding Information Update Message . . . . . . . 13 66 4.1.4. Binding Information Acknowledgment Message . . . 13 67 4.1.5. Home Agent Switch Request Message . . . . . . . . 14 68 4.2. New Mobility Options . . . . . . . . . . . . . . . . . . 15 69 4.2.1. Home Address . . . . . . . . . . . . . . . . . . 15 70 4.2.2. Mobile Network Prefix Option . . . . . . . . . . 15 71 4.2.3. Binding Cache Entry Information Option . . . . . 16 73 5. Home Agent Lists Management 17 75 6. Home Agent Failure Detection 18 77 7. Binding Synchronization among Home Agents 19 78 7.1. Requesting Binding . . . . . . . . . . . . . . . . . . . 19 79 7.2. Notifying Binding . . . . . . . . . . . . . . . . . . . . 19 81 8. Primary Home Agent Switching 21 82 8.1. Home Agent initiated Switching . . . . . . . . . . . . . 21 83 8.2. Mobile Node initiated Switching . . . . . . . . . . . . . 21 85 9. Scenarios 23 86 9.1. Single Home Agent Activation . . . . . . . . . . . . . . 23 87 9.2. Multiple Home Agent Activation . . . . . . . . . . . . . 24 89 10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol 27 91 11. IANA Considerations 29 93 12. Security Considerations 30 95 A. Changes from -00 32 96 B. Distributed Home Network 33 98 Addresses 38 99 1. Introduction 101 In Mobile IPv6 [2], a Mobile Host could be tunneling and receiving 102 all its traffic through a bi-directional tunnel with its Home Agent, 103 unless it uses Route Optimization with its Correspondent Nodes. In 104 Nemo Basic Support protocol [7], the default mode of operation is 105 to tunnel all traffic meant for the Mobile Network through the Home 106 Agent serving the Mobile Router. Consequently, Home Agents could 107 become a considerable bottleneck in the performance of Mobile IPv6 108 and Nemo protocols. This becomes more significant when the Home 109 Agent serves thousands of Mobile Hosts and Mobile Routers. Sometimes 110 the Mobile Network could be closer to the Correspondent Node than 111 the Home Agent. If the Mobile Router could pick another Home Agent 112 closer to its current location, the tunneling overhead on every 113 packet could be reduced to a much shorter path in the Internet. 115 This draft specifies the inter Home Agents protocol (HAHA protocol) 116 to provide reliability, redundancy and load balancing of Home Agents. 117 Problem statements of Home Agent Reliability is summarized in [1]. 119 For the HAHA protocol, the definition of Home Agent is extended to 120 place multiple Home Agents at different links. Multiple Home Agents 121 could be located on different links and still serve the same home 122 prefix. Mobile IPv6 uses a IPv6 Neighbor Discovery based mechanism 123 for maintaining the list of Home Agents serving the same prefix, at 124 each Home Agent. If the Home Agents are not present on the same 125 physical link, Neighbor Discovery based mechanisms don't work. The 126 HAHA protocol defines a mechanism for Home Agents List management 127 using new MH messages for Home Agents located on different links. 128 Network configurations such as Home Network Prefix Assignments and 129 route distributions among Home Agents are described in [8]. In 130 appendix B, a distributed home network scenarios are described. 132 The HAHA protocol makes it possible to have two new scenarios which 133 would not have possible with Mobile IPv6 and the Nemo Basic Support 134 Protocol. These scenarios are Single Home Agent Activation and 135 Multiple Home Agent Activation and are explained in the following 136 paragraphs. 138 In the scenario of Single Home Agent Activation, a Mobile Node always 139 selects the best Home Agent to register its binding depending on 140 Mobile Node's current location or Home Agent status. The Mobile 141 Node's binding is always maintained by the single Home Agent. For 142 example, when a Mobile Node registers its binding to the nearest Home 143 Agent, the path between the Mobile Node and the Home Agent can be the 144 shortest possible path. This is particularly useful for a Mobile 145 Node which moves over geographically wide areas such as a Mobile 146 Router on an airplane. 148 In the scenario of Multiple Home Agent Activation, a Mobile Nodes 149 registers its binding to multiple Home Agents at the same time. 150 The Mobile Node sends a binding update to its primary home agent. 151 After the home registration, the primary Home Agent exchanges the 152 binding information with the other Home Agents. The Mobile Node's 153 binding is maintained by multiple Home Agent. Thereafter, the Mobile 154 Node can use any of these Home Agents which have the binding. The 155 Mobile Node can accept packets which are tunneled by any of the Home 156 Agents. Alternatively, a Home Agent who intercepts packets can 157 tunnel packets to the primary Home Agent. In this case, the Mobile 158 Node receives packets through the primary Home Agent. If many Home 159 Agents are scattered on the Internet, the Home Agent nearest to the 160 correspondent node intercepts packets meant for the Mobile Node or 161 the Mobile Network and tunnels them to the Mobile Node. The route 162 path between the correspondent node and the Home Agent can be kept 163 short. 165 2. Terminology 167 There is a separate Nemo terminology document [3], which defines the 168 terms related to Network Mobility used in the document. 170 The keywords ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL 171 NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and 172 ``OPTIONAL'' in this document are to be interpreted as described in 173 RFC 2119. 175 Home Agent 177 A Home Agent is originally defined in [2]. Traditional 178 Home Agents, if they all serve the same home prefix are 179 configured on a single link. This document extends the 180 definition of Home Agents such that the Home Agents need 181 not be on the same link. There could be multiple Home 182 Agents attached to different links serving the same home 183 prefix. 185 Primary Home Agent 187 A Home Agent who receives Binding Update from a Mobile 188 Router. The Mobile Router is always associated with a 189 primary Home Agent to register its binding. 191 Mobile Node, Mobile Host, and Mobile Router 193 In this document,three terms are used to express mobile 194 entities as defined at [10]. A Mobile Host is an end 195 host capable of Mobile IPv6. A Mobile Router is a router 196 of a mobile network supporting the Basic NEMO protocol. A 197 Mobile Node is entity moving on the Internet. A Mobile 198 Node implies either a Mobile Host, Mobile Router, or both. 200 3. Overview of Inter Home Agents Protocol 202 The HAHA protocol addresses the issues of home agent reliability 203 described in [1]. The HAHA protocol prevents Home Agent failure and 204 Home Link failure from Mobile IPv6. It provides mechanism of failure 205 detection and its recovery by binding synchronization. 207 Local HAs Distribtuion Global Home Distribution 209 Home Link1 210 ----+---- 211 +--------+ | 212 |Internet| +--------+ | 213 +--------+ |Internet|---+ Home Link2 214 | +--------+ | 215 --+---+---+--Home Link | 216 | | | ----+------ 217 HA HA HA Home Link3 219 The Combination 221 Home Link1 222 HA HA HA 223 | | | 224 +---+---+ 225 | +- HA 226 +--------+ | 227 |Internet|----+- HA Home Link2 228 +--------+ | 229 | +- HA 230 +----+----+ 231 | | | Home Link3 232 HA HA HA 234 Local Home Agent distribution is the configuration when multiple 235 home agents are placed locally in same routing domain. Multiple 236 home agents are configured at the same home link for a particular 237 mobile nodes. When one of home agents goes down, another home agent 238 takes over the inactive home agent and serves same mobile nodes 239 continuously. It is possible to balance load locally among home 240 agents. Local multiplexing is effective for load balancing and home 241 agent redundancy. 243 Global Home Agent distribution is used to avoid home link failure. 244 Multiple home agents are placed globally despite routing domains. 245 Multiple home agents serving a same home network are distributed 246 to different routing domains. Therefore, the routes for the home 247 network are advertised from multiple routing domains. Each mobile 248 node can pick the best home agent among distributed home agents 249 according to network environments and topological position. 251 When multiple Home Agents are configured at different links, each 252 Home Agent is expected to know the other Home Agents beforehand and 253 establishes Security Association with them for a secure path towards 254 the other Home Agents. 256 Each Home Agent maintains a list of all other Home Agents that serve 257 the same Home Network. The Mobile IPv6 mechanism of using router 258 advertisements for maintaining the Home Agent list cannot be used 259 if the Home Agents are placed on geographically different links, 260 because router advertisements can not be sent over link-local scope. 261 Therefore, each Home Agents periodically unicasts a Home Agent HELLO 262 message instead of Router Advertisement to the other Home Agents 263 configured at different links. Whenever a Home Agent receives a Home 264 Agent HELLO message, it updates its Home Agent List according to the 265 information in the received HELLO message. The Home Agent manages 266 the Home Agent List as same as the Mobile IPv6 specification. If 267 the lifetime of an entry is expired in the Home Agent List, the Home 268 Agent should delete the the entry from the Home Agent List and MAY 269 assume the Home Agent which entry is deleted becomes unreachable 270 (i.e. system down). 272 Synchronizing Binding of a particular Mobile Node allow to activate 273 multiple Home Agents simultaneously. When a primary Home Agent 274 receives a Binding Update and creates a Binding, it notifies the 275 Binding to the other Home Agents by unicasting Binding Information 276 Update messages. Home Agents receiving the Binding Information 277 Update message records Binding information and the address of the 278 primary Home Agent into their Binding Cache. Home Agents MUST 279 return Binding Information Acknowledgment messages with appropriate 280 status code to the sender Home Agent. A Home Agent sends a Binding 281 Information Request message to solicit a Binding Information Update 282 message to the primary Home Agent if needed. 284 When a Home Agent wants a Mobile Node to change the primary Home 285 Agent, it sends a Home Agent Switch Request message to trigger 286 the Dynamic Home Agent Address Discovery to a Mobile Node. After 287 receiving an ICMP Home Agent Address Discovery Request, the Home 288 Agent should reply an ICMP Home Agent Address Discovery Reply with 289 addresses of appropriate Home Agent addresses. If the Home Agent 290 has already had the desired new primary Home Agent, it contains 291 the address of the new Home Agent in the Home Agent Switch Request 292 message. The Mobile Node switches its primary Home Agent to the new 293 Home Agent. When the Mobile Node changes the primary Home Agent 294 proactively, it selects a new Home Agent from its home agent list. 296 After determination of the new Home Agent, it simply registers its 297 binding to the new Home Agent. The Mobile Node should de-register 298 its binding from the old Home Agent before the home registration to 299 the new Home Agent. 301 The scenarios for the HAHA protocol are described in Section 9. In 302 the Single Home Agent Activation scenario, only a primary Home Agent 303 manages a binding for a Mobile Node and takes responsibility for 304 tunneling packets from and to a Mobile Node. The Mobile Node can 305 switch its primary Home Agent to a Home Agent located in different 306 link by the HAHA protocol. 308 In the Multiple Home Agents Activation scenario, a primary Home Agent 309 shares the registered binding for a Mobile Node with all other Home 310 Agents. Each Home Agent intercepts packets and take responsibility 311 for delivering intercepted packets to either the Mobile Node or 312 the primary Home Agent. The Mobile Node accepts tunneled packets 313 directly from the Home Agent. Otherwise, when the primary Home Agent 314 receives tunneled packets from other Home Agents, it delivers packets 315 to the Mobile Node. The Mobile Node always tunnels outgoing packets 316 to the primary Home Agent. The Mobile Node can switch its primary 317 Home Agent to a Home Agent located in different link by the HAHA 318 protocol. 320 4. Message Formats 322 4.1. New Mobility Header Messages 324 The Mobility Header format is defined in section 6 of [2]. This 325 document defines five new mobility messages. 327 4.1.1. Home Agent HELLO Message 329 The Home Agent HELLO message is pulsed to other Home Agents in order 330 to inform activeness of the sender home agent. The format of the 331 Home Agent HELLO message is as follows: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Sequence | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Home Agent Preference | Home Agent Lifetime | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | HELLO Interval | Reserved | Prefix length| 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 | | 344 | Home Agent Address | 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 . . 349 . Mobility Options . 350 . . 351 . | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Sequence 356 16-bit unsigned integer. The Sequence number of the HELLO 357 message can be used to verify whether this HELLO message is the 358 latest one or not. This value does not need to be recorded in 359 Home Agent List. 361 Home Agent Preference 363 16-bit unsigned integer. The preference for the home agent 364 sending this hello. This preference is same as the home agent 365 preference value of home agent information option defined in 366 Mobile IPv6. 368 Home Agent Lifetime 370 16-bit unsigned integer. The lifetime for the home agent 371 sending this HELLO. This lifetime is same as the home agent 372 Lifetime value of home agent information option defined in 373 Mobile IPv6. 375 HELLO Interval 377 16-bit unsigned integer. The interval for the home agent 378 sending this HELLO. 380 Reserved 382 8-bit unsigned integer. It must be initialized to zero by the 383 sender and must be ignored by the receiver. 385 Prefix Length 387 8-bit unsigned integer. The prefix length of the home prefix 388 that HA is serving. The home prefix is retrieved from the 389 Prefix Length field and following Home Agent Address field. 391 Home Agent Address 393 A 16 byte field contains an IPv6 global address of the home 394 agent sending this hello. 396 This message MUST include the Mobile Network Prefix Option defined in 397 section 4.2.2 that is served by the Home Agent if available. 399 Home Agent HELLO message MUST be authenticated and encrypted by IPsec 400 ESP. 402 4.1.2. Binding Information Request Message 404 The Binding Information Request Message is used to request Binding 405 Cache Information corresponding to a particular Mobile Node. It is 406 sent only between Home Agents. The format of the Binding Information 407 Request message is as follows: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Identifier | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 . . 416 . Mobility Options . 417 . . 418 . | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Identifier 423 The 16-bit identifier to aid in matching Home Agent Information 424 Update message. The identifier should never be set to 0. It 425 should always be more than 1. 427 This message MUST include either the Home Address mobility option 428 defined in section 4.2.1 or the Mobile Network Prefix Option 429 defined in section 4.2.2. If a Home Agents want the Binding Cache 430 Information for a particular Mobile Node it includes a Home Address 431 mobility option. If a Home Agent wants to know the forwarding state 432 setting up for a particular Mobile Network Prefix, it includes the 433 Mobile Network Prefix Option. 435 This message is optional if Home Agents send out unsolicited Binding 436 Information Update messages. 438 Binding Information Request message MUST be authenticated and 439 encrypted by IPsec ESP. 441 4.1.3. Binding Information Update Message 443 The Binding Information Update message is used by the Home Agents 444 to exchange Binding Cache Information. The message format is as 445 follows: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Identifier | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 . . 454 . Mobility Options . 455 . . 456 . | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Identifier 461 The 16-bit identifier to aid in matching Home Agent Information 462 Request and Home Agent Information Acknowledge message. The 463 identifier should never be set to 0. It should always be 464 more than 1. The identifier should be set random number for 465 unsolicited Binding Information Update messages. Otherwise, 466 the identifier should be set to the identifier in a Binding 467 Information Request message if this is a solicited Binding 468 Information Update message. 470 This message MUST include Binding Cache Entry Information option. 472 Binding Information Update message MUST be authenticated and 473 encrypted by IPsec ESP. 475 4.1.4. Binding Information Acknowledgment Message 477 The Binding Information Acknowledgment message is used by the Home 478 Agents to confirm recipient of a Binding Information Update message. 479 The message format is as follows: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Identifier | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Status | Reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Identifier 491 The 16-bit identifier should be copied from the identifier 492 field of the received Home Agent Information Update message. 494 Status 496 16-bit Status value. Values of Status field greater than or 497 equal to 128 indicate that the Binding Infroamtion Update was 498 rejected by the receiving node. The following Status values 499 are currently defined: 501 0 Binding is successfully synchronized 503 Reserved 505 16-bit field reserved for future use. The value SHOULD be 506 initialized to zero by the sender, and MUST be ignored by the 507 receiver. 509 Binding Information Acknowledgment message MUST be authenticated and 510 encrypted by IPsec ESP. 512 4.1.5. Home Agent Switch Request Message 514 This message is sent by a Home Agent to a Mobile Node to trigger 515 Dynamic Home Agent Discovery. The message format is as follows: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Reserved | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 + + 524 | | 525 + Home Agent Address + 526 | | 527 + + 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Reserved 533 16-bit field reserved for future use. The value SHOULD be 534 initialized to zero by the sender, and MUST be ignored by the 535 receiver. 537 Home Agent Address 539 A 16 byte field contains the new primary Home Agent Address. 540 The Home Agent address MUST be recorded in the Home Agent list 541 of the Mobile Router. If this field does not contain the 542 valid global IPv6 address or the unknown Home Agent address, 543 the Mobile Router sends dynamic Home Agent address discovery 544 request message. Otherwise, the Mobile Router switches to this 545 Home Agent immediately as its primary Home Agent. 547 Home Agent Switch Request message MUST be authenticated and encrypted 548 by the use of IPsec ESP mode. 550 4.2. New Mobility Options 552 4.2.1. Home Address 554 The Home Address option has an alignment requirement of 8n+6. Its 555 format is as follows: 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type = 0x8 | Option Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 + + 564 | Home Address | 565 + + 566 | | 567 + + 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 This option is used when the Home Agent needs to figure out the 572 Binding Cache information for a particular Mobile Node or Mobile 573 Router. not useful when each Home Agent sends an unsolicited binding 574 cache information for each BU it receives. 576 4.2.2. Mobile Network Prefix Option 578 This option is already defined in the Nemo basic support [7]. This 579 option is included in the Binding Information Request message only if 580 a Home Agent is requesting information regarding a particular Mobile 581 Network Prefix. 583 4.2.3. Binding Cache Entry Information Option 585 The Binding Cache Entry Information option has an alignment 586 requirement of 8n+2. Its format is as follows: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type = 0x9 | Option Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 + + 595 | Home Address | 596 + + 597 | | 598 + + 599 | | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | | 602 + + 603 | | 604 + Care-of Address + 605 | | 606 + + 607 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Flags | Sequence Number | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Lifetime | Reserved | # of MNPs | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 . Mobile Network Prefixes . 615 . . 617 Binding Cache Entry Information option is valid in the Binding 618 Information Update. 620 The fields of Home Address, Care-of Address, Flags, Sequence Number, 621 and Lifetime are copied from the registered binding of a particular 622 Mobile Node or Mobile Router. 8-bit Reserved field MUST be set to 623 zero. 625 The field ``Number of MNPs'' tells the receiving Home Agent which 626 Mobile Network Prefixes are owned by a Mobile Router. The receiving 627 Home Agent can then setup forwarding for each Mobile Network Prefix. 628 for Mobile IPv6, the ``Number of MNPs'' field is set to 0. 630 5. Home Agent Lists Management 632 Mobile IPv6 uses Router Advertisement messages to manage Home Agent 633 lists on each Home Agents. When Home Agents are placed at different 634 links, Router Solicitation and Advertisement messages can not be used 635 due to link-local limitation. Therefore, a new MH message is defined 636 to notify similar information of Router Advertisement among Home 637 Agents over the home link. 639 A Home Agent MUST know other Home Agents which configured in 640 different links beforehand. This is manually configured on each 641 Home Agent. This mechanism MUST be used only between Home Agents on 642 different links serving the same home prefix. It SHOULD not be used 643 between Home Agents on the same link. 645 A Home Agent MUST periodically send a Home Agent HELLO message. The 646 Home Agent SHOULD also send a Home Agent HELLO message when its local 647 information such as preference, lifetime, and registration status, 648 etc. changes. 650 A Home Agent HELLO message MUST be constructed with same information 651 of a Router Advertisement message described in section 7 of [2] and 652 MUST be sent by a unicast to the destination (other Home Agents). 654 The receiver of a Home Agent HELLO message MUST verify the Source 655 address field of the IPv6 header. If a Home Agent HELLO message 656 is received from unknown Home Agent, the message MUST be silently 657 dropped. If the source address is not in the list of known Home 658 Agents, the message MUST be silently dropped. Otherwise, the 659 receiver processes the Home Agent HELLO message to update its Home 660 Agent list. The Sequence field should be checked to ensure the 661 freshness of the received HELLO message. 663 Any Home Agent HELLO message satisfying all of these tests MUST be 664 processed to update its Home Agent list. The receiver Home Agent 665 copy each field of the Home Agent HELLO message to its local Home 666 Agent List. If the Lifetime field is set to zero, the receiver MUST 667 delete the sender Home Agent from the Home Agent List. 669 When a new Home Agent boots up, it SHOULD wait particular time to 670 listen Home Agent HELLO messages of all configured Home Agents. 672 6. Home Agent Failure Detection 674 Each Home Agent detects Home Agent failure by monitoring lifetime of 675 each Home Agent List entry. 677 When an entry is deleted because of lack of either Router 678 Advertisements or Home Agent HELLO messages, the Home Agent is 679 treated as invalid. 681 When Home Agent Lifetime is notified with zero by Router 682 Advertisements or Home Agent HELLO messages, the receiver MUST mark 683 the sender Home Agent as invalid, too. 685 7. Binding Synchronization among Home Agents 687 A binding for a particular Mobile Node is shared among Home Agents. 688 Therefore, each Home Agents can always know the binding for a 689 particular Mobile Node and the primary Home Agent which is currently 690 serving the Mobile Node. This makes it possible for Mobile Nodes to 691 utilize multiple Home Agents simultaneously. 693 Binding synchronization messages can be sent with either unicast 694 or multicast routing. If unicast routing is used, full mesh 695 flooding is required. Full mesh flooding incurs high overhead for 696 synchronizing information among multiple entities. But there are 697 existing mechanisms like CARP and BGP reflector mechanism to reduce 698 the overhead. Therefore this document does not discuss any optimized 699 synchronization schemes. This document assumes full mesh flooding, 700 however, it can be replaced by any other mechanism which achieves 701 full mesh flooding. 703 7.1. Requesting Binding 705 When a Home Agent wants a binding for a particular Mobile Node, it 706 can solicit Binding Information Update message. The Home Agent sends 707 a Binding Information Request message to the primary Home Agent of 708 the Mobile Node. The Home Agent MUST set a random value to the 709 Identifier field in the Binding Information Request message and MUST 710 include either a Home Address mobility option or a Mobile Network 711 Prefix mobility option. 713 7.2. Notifying Binding 715 The primary Home Agent sends Binding Information Update messages when 716 it is solicited by Binding Information Request message or when it 717 creates or updates binding for a particular Mobile Node. 719 When the primary Home Agent receives a Binding Information Request 720 message, it MUST verifies the Source address field of the IPv6 721 header. If the source address is not among the known Home Agents, 722 the message MUST be silently discarded. 724 If a Home Agent who receives a Binding Information Request message 725 is not the primary Home Agent for the requested Mobile Node, it 726 MUST ignore the message. Otherwise, it SHOULD reply to the Binding 727 Information Request message. 729 The binding information of the requested Mobile Node are stored in 730 the Binding Information Update message. The primary Home Agent 731 MUST copy the binding information of the requested Mobile Node to 732 each fields of a Binding Cache Entry Information option. If the 733 Binding Information Update message is sent in response to the Binding 734 Information Request message, the primary Home Agent MUST copy the 735 Identifier field of the Request message to the same filed in the 736 Update message. Otherwise, it MUST set zero to the Identifier field. 738 When a Home Agent receives a Binding Information Update message, it 739 MUST verify the Source address field of the IPv6 header. If the 740 source address is not among the known Home Agents, the message MUST 741 be silently discarded. If the Binding Information Update message 742 is sent from the primary Home Agent, the Home Agent SHOULD record 743 the binding information and the primary Home Agent address into its 744 Binding Cache. After registering the binding, the Home Agent MUST 745 return a Binding Information Acknowledgement message to the sender 746 Home Agent of the Binding Information Update message. 748 If the sender Home Agent of the Binding Information Update message 749 does not receive a Binding Information Acknowledgement message, it 750 MUST retry to send a Binding Information Update message. 752 Both a Binding Information Update message, a Binding Information 753 Request message and a Binding Infromation Acknowledgement message 754 MUST be authenticated and encrypted by IPsec ESP. If a message does 755 not have IPsec ESP header, the message MUST be ignored. 757 8. Primary Home Agent Switching 759 A Mobile Node always associates with the best Home Agent from Home 760 Agents configured for the Mobile Node. The Mobile Node initiates 761 dynamic Home Agent discovery to get the most appropriate Home Agents. 762 The Mobile Node can ensure the best Home Agent by issuing a Dynamic 763 Home Agent Address Discovery Request message at each visiting foreign 764 links. Alternatively, Home Agent can send Home Agent Switch Request 765 message as a trigger of a Dynamic Home Agent Address Discovery 766 Request message to the Mobile Node. 768 The Home Agent initiated switching is useful for load-sharing of each 769 Home Agents. A Home Agent can control the load average by moving 770 some of Mobile Nodes to other Home Agents compulsory. 772 The Mobile Node initiated switching guarantees a Mobile Node to 773 register its binding to the best Home Agent all the time. For 774 example, the best Home Agent is the nearest one. 776 8.1. Home Agent initiated Switching 778 A Mobile Node can change its primary Home Agent when it is requested 779 by a Home Agent. When a Mobile Node receives a Home Agent Switch 780 Request, it checks the Home Address field in the request. If the 781 address in the Home Address field is global scope address and is 782 already recorded in the Home Agent list of the Mobile Node, the 783 Mobile Node MUST immediately switch to the requested Home Agent by 784 the Home Agent Switch Request. 786 On the other hand, if the requested address in the Home Agent Switch 787 Request message is either unknown or empty, the Mobile Node MUST send 788 a Dynamic Home Agent Discovery Request message to the Mobile IPv6 789 Home-Agents anycast address. After receiving a Dynamic Home Agent 790 Discovery Reply, the Mobile Node selects the most appropriate home 791 agent and changes its primary Home Agent to the selected Home Agent. 793 The primary Home Agent switching is completed when the Mobile Node 794 registers its binding to the new Home Agent. 796 8.2. Mobile Node initiated Switching 798 When a Mobile Node decides to change its primary Home Agent, it 799 selects the new Home Agent from its Home Agent list. The Mobile Node 800 can start Dynamic Home Agent Address Discovery mechanism to update 801 Home Agents information such as a preference value of each Home 802 Agents. 804 After selection of a new Home Agent, it registers its binding to the 805 new Home Agent. 807 9. Scenarios 809 This section describes assumed scenarios of the HAHA protocol. 810 Network configurations such as Home Prefix assignments and route 811 managements are described in [8]. 813 Two scenario are introduced such as the Single Home Agent Activation 814 and the Multiple Home Agents Activation. Both can be applied to both 815 Mobile IPv6 and the Nemo basic support protocol. 817 In each figures descrbied below, the operation of Binding Information 818 Acknowledgement message is omitted. The binding notification is 819 assumed to be success all the time in this Section. 821 9.1. Single Home Agent Activation 823 MN PHA HA2 HA3 CN 824 | | | | | 825 |------>| | | | 1. Home Registration 826 | | | | | 827 |======>|---------------------->| 2. Sending Packet to CN 828 | | | | | via Primary HA"(PHA) 829 |<======|<----------------------| 3. Sending Packet to MN 830 | | | | | via PHA 831 |<------|(HA1) | | | 4. Trigger primary HA switching 832 | | | | | 833 |-------------->|(PHA) | | 5. Sending Binding Update 834 | | | | | 835 | |<------|------>| | 6. Soliciting the binding 836 | | | | | to other HAs. (no reply) 837 |<--------------| | | 7. Sending Binding Acknowledgement 838 | | | | | 839 |==============>|-------------->| 8. Sending Packet to CN 840 | | | | | 841 |<==============|<--------------| 9. Sending Packet to CN 842 | | | | | 844 Figure 1: Local Home Agent Distribution 846 All packets meant for a Mobile Node are routed to the primary Home 847 Agent and are intercepted by the primary Home Agent as well as both 848 Mobile IPv6 and Nemo basic support. Then, the primary Home Agent 849 tunnels packets to the Mobile Node according to either the registered 850 binding cache or the forwarding states established by a Binding 851 Update (Seq2 and Seq3). 853 When the Mobile Node switches its primary Home Agent, it sends a 854 Binding Update to the new primary Home Agent (Seq5). The new primary 855 Home Agent receiving the Binding Update verifies whether the other 856 Home Agents still hold the binding for the Mobile Node. It sends 857 Binding Information Request messages to all the other Home Agents 858 (Seq6). If it receives any Binding Information Update message in 859 response to the Binding Information Request messages, it sends a 860 Binding Acknowledge to the Mobile Node with the status value set to 861 144 (another Home Agent is still active). Otherwise, the Home Agent 862 accepts the Binding Update and becomes the primary Home Agent for the 863 Mobile Node (Seq7). 865 If the Mobile Node receives the Binding Acknowledge with a negative 866 status code, it de-registers its binding from the old primary Home 867 Agent and retries to send a Binding Update to the new primary Home 868 Agent. Before trying home registration to the new Home Agent, the 869 Mobile Node should de-register its binding from the current primary 870 Home Agent. 872 When the Mobile Node receives a Home Agent Switch Request from the 873 current primary Home Agent, it MUST switch its primary Home Agent 874 to the new Home Agent specified in the Home Agent Switch Request. 875 The Mobile Node can also switch the primary Home Agent proactively 876 without the Home Agent Switch Request. 878 9.2. Multiple Home Agent Activation 880 Each Home Agent synchronizes a binding for a particular Mobile Node 881 by the HAHA protocol. If all the Home Agents who have the binding 882 for the Mobile Node can setup forwarding for the Home Address and the 883 mobile network prefixes owned by the Mobile Node if any, it tunnels 884 intercepted packets directly to the Mobile Node (Fig 3). On the 885 other hand, if the Home Agent does not enable forwarding for the 886 Home Address and the mobile network prefixes, it tunnels intercepted 887 packets to the primary Home Agent (Fig 2) first. Then the primary 888 Home Agent re-tunnels packets to the Mobile Node. It is a matter of 889 operations whether forwarding setting is enable on all the Home Agent 890 or not. 892 In the figure 2, a Mobile Node first registers its binding to the 893 primary Home Agent (Seq1). Once the primary Home Agent creates 894 a binding for the Home Address of the Mobile Node and sets up 895 forwarding for the Mobile Network Prefixes, it sends Binding 896 Information Update messages to other Home Agents to synchronize the 897 binding information (Seq2 and Seq3). When a Home Agent receives the 898 Binding Information Update message, it records the binding and the 899 primary Home Agent address (which can be retrieved from the source 900 MN PHA HA2 CN1 HA3 CN2 901 | | | | | | 902 |------>| | | | | 1. Home Registration 903 | | | | | | 904 | |------>| | | | 2. Sending binding to HA2 905 | | | | | | 906 | |---------------------->| | 3. Sending binding to HA3 907 | | | | | | 908 |======>|-------------->| | | 4. Sending Packet to CN1 909 | | | | | | via PHA 910 |<======|<------|<------| | | 5. Sending Packet to MN 911 | | | | | | via HA2 and PHA 912 |======>|------------------------------>| 6. Sending Packet to CN2 913 | | | | | | via PHA 914 |<======|<----------------------|<------| 7. Sending Packet to MN 915 | | | | | | via HA3 and PHA 916 |-------------->|(PHA) | | | 8. Home Registration 917 | | | | | | 918 | (HA1)|<------|-------------->| | 9. Sending binding to 919 | | | | | | HA1 and HA3 920 |==============>|---------------------->| 10. Sending Packet to CN2 921 | | | | | | via PHA 922 |<==============|<--------------|<------| 11. Sending Packet to MN 923 | | | | | | via HA3 and PHA 925 Figure 2: Multiple Home Agents with single bi-directional tunnel 927 address of the Binding Information Update messages) in the binding 928 cache entry. 930 After the completion of the binding synchronization, all Home 931 Agents start to distribute the network routes for the Mobile Network 932 Prefixes to the Internet in the basic NEMO case. Therefore, when the 933 Mobile Network Node communicates with a Correspondent Node, outgoing 934 packets from the Mobile Network are tunneled to the closer primary 935 Home Agent (Seq4) and incoming packets to the Mobile Network are 936 intercepted by the Home Agent which is close to the Correspondent 937 Node (Seq5). Then, the intercepted packets are forwarded/tunneled to 938 the primary Home Agent. The primary Home Agent delivers the packets 939 to the Mobile Router through the bi-directional tunnel (Seq5). In 940 Mobile IPv6, the operation is same except for lack of Mobile Network 941 Prefixes. 943 If the Mobile Node decides to switch its primary Home Agent due to 944 its movement, it sends a Binding Update to the new primary home 945 agent. Then, the new primary Home Agent starts to synchronize the 946 binding information with other Home Agents (Seq9). All Home Agent 947 updates the binding and the primary Home Agent address according to 948 the received Binding Information Update message. 950 MN HA1 HA2 CN1 HA3 CN2 951 | | | | | | 952 |------>| | | | | 1. Home Registration 953 | | | | | | 954 | |------>| | | | 2. Sending the binding 955 | | | | | | to HA2 956 | |---------------------->| | 3. Sending the binding 957 | | | | | | to HA3 958 |======>|-------------->| | | 4. Sending Packet to CN1 959 | | | | | | via HA1 960 |<==============|<------| | | 5. Replying to MN 961 | | | | | | via HA2 962 |======>|------------------------------>| 6. Sending Packet to CN2 963 | | | | | | via HA1 964 |<==============================|<------| 7. Replying to MN 965 | | | | | | via HA3 967 Figure 3: Multiple Home Agents with multiple 968 bi-directional tunnels 970 In the figure 3, a Mobile Node first sends a Binding Update to its 971 primary Home Agent (Seq1). The primary Home Agent also notifies the 972 binding information to other Home Agents by using Binding Information 973 Update messages (Seq2 and Seq3). When a Home Agent receives the 974 Binding Information Update message, it records the binding and the 975 primary home agent address as a binding cache entry for the Mobile 976 Node and sets up forwarding for mobile network prefixes if any. 978 After creating the binding cache entry and setting up forwarding, 979 each Home Agent starts to distribute network routes for the mobile 980 network prefixes to the Internet. When the Mobile Network Node 981 communicates with a Correspondent Node, outgoing packets from 982 the mobile network are tunneled to the primary Home Agent (Seq4). 983 Incoming packets to the mobile network are intercepted by the Home 984 Agent which is close to the Correspondent Node (Seq5). Then, the 985 intercepted packets are tunneled directly to the current Care-of 986 Address according to binding and forwarding (Seq5). 988 The procedure of primary Home Agent switching is same as the 989 procedure described in Fig 2. 991 10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol 993 The HAHA protocol modifies the below items of Mobile IPv6 [2] and the 994 Nemo Basic Support protocol [7]. 996 - The new status values for the Binding Acknowledgment. 998 When a Mobile Node receives this status for its home 999 registration, it MUST de-register its binding from the old 1000 primary Home Agent and SHOULD re-try home registration. A Home 1001 Agent SHOULD use this status value only in the Single Home 1002 Agent Activation scenario. The primary Home Agent can not be 1003 duplicated in the scenario and can only have a binding for a 1004 particular Mobile Node all the time. 1006 Status 1008 144 Another primary Home Agent is still active. 1010 - Binding Cache Registration 1011 The conceptual fields of each Binding Cache entry are defined 1012 in [2]. The HAHA protocol introduces an additional field to 1013 record the primary Home Agent address for a Mobile Node. 1015 When a Home Agent receives a Binding Information Update message, 1016 it creates or updates the binding cache entry. The Home Agent 1017 MUST record the primary Home Agent address in the binding cache 1018 entry. The address can be derived from the Source address field 1019 of IPv6 header in the Binding Information Update message. 1021 When a primary Home Agent receives a Binding Update from a Mobile 1022 Node, it MUST records its own address as the primary Home Agent 1023 address in the binding cache entry. 1025 - Tunneling packets to Mobile Node Home Agents 1026 Home Agents who registers a binding by the HAHA protocol can 1027 tunnel packets meant for the Mobile Node or Mobile Network to 1028 the current Care-of Address as well as the primary Home Agent. 1029 The Mobile Node can accept the tunneled packets. The Mobile 1030 Node MUST know all the Home Agents who has its binding in the 1031 home agent list so as to verify the Source address of outer IPv6 1032 header. 1034 - Tunneling packets to primary Home Agent from Home Agents 1035 When one of Home Agents who has a binding intercepts packets 1036 meant for a particular Mobile Node, the Home Agent can tunnel 1037 packets to the primary Home Agent recorded in the binding cache. 1039 The primary Home Agent tunnels packets to the current Care-of 1040 Address of the Mobile Node. 1042 11. IANA Considerations 1044 This document defines three new Mobility Header messages 1046 - Home Agent HELLO Message 1048 - Binding Information Request Message 1050 - Binding Information Update Message 1052 - Binding Information Acknowledgment Message 1054 - Home Agent Switch Request Message 1056 This document defines two new Mobility Options. 1058 - Home Address 1060 - Binding Cache Entry Information 1062 12. Security Considerations 1064 Multiple Home Agents advertise routes for either same Home Prefix and 1065 possibly Mobile Network Prefix in the HAHA protocol, these routes 1066 MUST be correctly advertised. System Administrators MUST prevent 1067 malicious (blackhole) routes for these prefixes. 1069 A Home Agent MUST know the other Home Agent serving a same Mobile 1070 Node and MUST establish a secure association with each Home Agent. 1071 All signaling messages between the Mobile Node and the Home Agent 1072 MUST be authenticated and encrypted by IPsec ESP [5]. 1074 The Mobile Node MUST verify that packets are tunneled through the 1075 known Home Agent. In Multiple Home Agent Activation scenario, the 1076 Mobile Node may receives packets tunneled by multiple Home Agents. 1077 The Mobile Node MUST know all Home Agents who has its binding by the 1078 HAHA protocol in its Home Agent List by using Home Agent Address 1079 Discovery. It is necessary for a Mobile Node to know all other Home 1080 Agents in order to protect attacks launched by malicious Home Agents. 1082 Please refer to the Mobile IPv6 specification [2] and the Nemo Basic 1083 Support protocol specification [7] for security considerations. 1085 References 1087 [1] J. Faizan, H. El-Rewini, M. Khalil, Problem Statement: Home 1088 Agent Reliability (work in progress). Internet Draft, IETF. 1089 draft-jfaizan-mipv6-ha-reliability-01.txt Februry 2004. 1091 [2] D. Johnson, C. Perkins and J. Arkko. Mobility Support 1092 in IPv6 (work in progress). Internet Draft, IETF. 1093 draft-ietf-mobileip-ipv6-22.txt. May 2003. 1095 [3] T. Ernst and H. Lach. Network Mobility Support Terminology (work 1096 in progress). Internet Draft, IETF. draft-ietf-nemo-terminology 1097 -00.txt May 2003. 1099 [4] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to 1100 Protect Mobile IPv6 Signaling between Mobile Nodes and 1101 Home Agents (work in progress). Internet Draft, IETF. 1102 draft-ietf-mobileip-mipv6-ha-ipsec-05.txt May 2003 1104 [5] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). 1105 RFC 2402, IETF. November 1998. 1107 [6] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 1108 Specification. RFC 2473, IETF. December 1998. 1110 [7] V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert. 1111 Nemo Basic Support Protocol (work in progress). Internet Draft, 1112 IETF. draft-ietf-nemo-basic-support-01.txt September 2003 1114 [8] P. Thubert and R. Wakikawa and V. Devarapalli. Examples of 1115 basic Nemo usage (work in progress). Internet Draft, IETF. 1116 draft-ietf-nemo-basic-usage-00.txt October 14 2003. 1118 [9] T. Narten and E. Nordmark and W. Simpson. Neighbor Discovery for 1119 IP Version 6 (IPv6). RFC 2461, IETF. December 1998. 1121 [10] J. Manner and M. Kojo. Mobility Related Terminology. 1122 draft-ietf-seamoby-mobility-terminology-05.txt November 2003 1124 A. Changes from -00 1126 - Obsolete two ICMP messages (Home Agent Solicitation and 1127 Advertisement Message) 1129 - Add a new MH message called Home Agent HELLO message 1131 - Change the name of Binding Information Reply Message to Binding 1132 Information Update Message 1134 - Add a new MH message called Binding Information Acknowledgment 1135 Message 1137 - Add a section for a detailed example in Appendix B 1139 B. Distributed Home Network 1141 This section describes a detailed example how multiple Home Agents 1142 are configured in different routing domains. The HAHA protocol does 1143 not completely cover all operations for this example at this time. 1144 Readers are expected to read [8] before reading this section. 1146 In distributed home network, a global Home is advertised by several 1147 sites that are geographically distributed and meshed using tunnels 1148 in a VPN fashion. Mobile Nodes locate the closest site using 1149 DHAAD against the global Home Network and bind there. Some form of 1150 inter-site synchronization (e.g. a routing protocol), which Mobile 1151 IPv6 and Nemo Basic Support do not provide, must take place in order 1152 to allow packets to be routed between the incoming site to the Mobile 1153 Node. The HAHA (Home Agent to Home Agent) protocol is being designed 1154 for that purpose. 1156 In one model, each site is responsible for a subnet of Home. When a 1157 Mobile Node roams far from its natural (default) site, it registers 1158 to a Home Agent on a remote site, that takes the registration and 1159 notifies at least the natural site of the foreign registration. 1161 There are at least 3 approaches in order to locate the Home Agent 1162 that has a registration for a given Mobile Node, Router or Mobile 1163 Network: 1165 - reactive 1166 This method is also referred to as 'on-demand'. In case 1167 of a binding cache miss, a Home Agent floods a Binding 1168 Information Request message to all the other Home Agents with 1169 the (destination of the packet) home address that is sought 1170 for. Every Home Agent that has a registration for that home 1171 address or for a Mobile Network that encompasses that home 1172 address responds. This approach is traditionally used in fast 1173 changing configurations, for instance if Mobile Nodes register 1174 and de-register very often. 1176 - proactive 1177 An information is pushed to all Home Agents with the Home 1178 Address and the Mobile Network Prefixes each time by Binding 1179 Information Update message This approach is preferred for stable 1180 configurations, for instance if Mobile IP is used as a tool to 1181 simplify the configuration and reconfiguration of mostly stable 1182 networks. 1184 - predictive 1185 Ranges of Home Addresses and prefixes are assigned to the Home 1186 Agents, following a rule that is commonly computed by all Home 1187 Agents. Dynamic Home Agent Address Discovery (DHAAD) returns 1188 only the address of one Home Agent, the one that is pre-allocated 1189 for that Mobile Node. When the wrong Home Agent intercepts 1190 packets, it can compute which is the right Home Agent and forward 1191 packets to it at L2 if they are directly connected, or via a HAHA 1192 tunnel which is established between Home Agents. This is what we 1193 call 'Z' routing. 1195 CN --------> closest HA CN ----------> closest HA 1196 / | 1197 / | 1198 / | 1199 / | 1200 / | 1201 Assigned / | 1202 HA v V 1203 ----------> Mobile Node Mobile Node 1205 The Predictive Mode minimizes the control traffic, which may be 1206 required for a large configuration. Some additional controls would 1207 be necessary for the HAHA protocol to allow the negotiation and the 1208 distribution of the shares of Home to be attributed to each Home 1209 Agent. 1211 One specific advantage of not relying on a Home Link for HAHA 1212 communication is that for a large configuration, the Home Agents can 1213 be organized hierarchically and distributed geographically, as a set 1214 of local clusters linked together to form a global Home Network. 1216 For instance, it is possible for a large ISP to partition the Home 1217 Network for a given worldwide service, and assign a partition to a 1218 cluster of Home Agents in each of the geographies. In predictive 1219 mode, each Home Agent in the world would be able to compute the 1220 best suited Home Agent in its local cluster (call this a Acting 1221 Home Agent) and the best suited Home Agent worldwide (call this the 1222 Assigned Home Agent) for each and any Home Address. 1224 HA HA 1225 | ______ | 1226 --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- 1227 | | | | ______ | | | | 1228 MR1 MR2 MRi MRN MR1 MR2 MRi MRN 1229 ------ ------ ------ ------ ------ ------ ---- - ---- 1230 /64 A:B:1:i::/64 /64 A:B:n:i::/64 1232 Distributed Home Network /48 1233 <------------------------------------------------------------------> 1235 extended HN Aggregated HN Virtual HN 1236 <----------------------><---------------------->...<---------------> 1238 Home Mob Mob Mob Mob Mob Mob Mob 1239 <-----><----->...<-----><-----><----->...<----->...<----->...<-----> 1241 Any Home Agent processing an anycast DHAAD can predict the Assigned 1242 Home Agent and local Acting Home Agents for a Home Address if that 1243 information is added to the DHAAD request. In the case of Mobile 1244 Routers, the service must be arranged in such ways that, for a given 1245 registration, all the Mobile Networks are assigned to a same Home 1246 Agent. 1248 Possible flows: In order to register, a Mobile Node uses DHAAD which 1249 returns one Home Agent in the closest cluster. This can be a Acting 1250 Home Agent if the Mobile Node is roaming far from Home, but hopefully 1251 it is in general the Assigned Home Agent for that Mobile Node. When 1252 this is a Acting Home Agent, it needs to register to the Assigned 1253 Home Agent as proxy binding. 1255 When a packet destined to a given Home Address arrives at a Home 1256 Agent from a Correspondent Node: 1258 If the Home Agent is Assigned Home Agent for that Home Address and it 1259 has a direct registration (it is primary), the Home Agent forwards 1260 the packet over its bi-directional tunnel established with the Mobile 1261 Node (the MNHA tunnel). If it has a proxy registration (it is 1262 secondary), it forwards the packet to the primary Acting Home Agent - 1263 or directly to the Mobile Node if that is practical for tunnel setup 1264 and security reasons. Else it drops the packet. 1266 Else If the Home Agent is Acting Home Agent for that Home Address and 1267 it has a direct registration (it is primary), the Home Agent forwards 1268 the packet over its MNHA tunnel. If it has a proxy registration (it 1269 is secondary), it forwards the packet to the primary Acting Home 1270 Agent - or directly to the Mobile Node if that is practical for 1271 tunnel setup and security reasons. Else, it forwards the packet to 1272 the Assigned Home Agent. 1274 CN ----------> Acting HA 1275 / closest to CN 1276 / 1277 / 1278 / 1279 Assigned / 1280 HA V 1281 " 1282 " 1283 " 1284 " 1285 " 1286 " Acting HA primary 1287 MN <----------- for that registration 1288 (closest to MN) 1290 CN ----------> closest HA 1291 | to CN 1292 | 1293 | 1294 | 1295 | 1296 v Acting HA, primary 1297 MN <--------- for that registration 1298 (closest to MN) 1300 Else (if the Home Agent is the 'wrong Home Agent') the Home Agent 1301 tunnels the packet to the best suited of the local Home Agents, be it 1302 the Assigned Home Agent, or a local Acting Home Agent. 1304 In the worst case, the packet may bounce from the receiving 1305 Home Agent to the local Acting Home Agent, then to the Assigned 1306 Home Agent, and finally to the Acting Home Agent that has the 1307 registration. It is up to the Assigned Home Agent to forward the 1308 proxy binding states to the Acting Home Agent on the receiving side 1309 in order to allow Acting Home Agent to Acting Home Agent 'Z' routing. 1311 If the Home Agents are distributed geographically, it is expected 1312 that, in general, the angles of the Z (the Home Agents) are close to 1313 the Mobile Node and Correspondent Node respectively, relatively to 1314 the distance between the Home Agents, which makes the cost of the 1315 bouncing acceptable in terms of distance and hops. 1317 When a packet from a registered Mobile Node arrives over the MNHA 1318 tunnel to a Home Agent (one that it is registered to), the Home Agent 1319 forwards the packet directly to the Correspondent Node. That Home 1320 Agent is supposed to be close to the Mobile Node, making the MN-HA-CN 1321 triangle as flat as possible and limiting the cost of the dogleg. 1323 Authors Addresses 1325 Ryuji Wakikawa 1326 Keio University and WIDE 1327 5322 Endo Fujisawa Kanagawa 1328 252-8520 1329 Japan 1330 Email: ryuji@sfc.wide.ad.jp 1332 Vijay Devarapalli 1333 Nokia Research Center 1334 313 Fairchild Drive 1335 Mountain View, CA 94043 1336 USA 1337 Email: vijay.devarapalli@nokia.com 1339 Pascal Thubert 1340 Cisco Systems Technology Center 1341 Village d'Entreprises Green Side 1342 400, Avenue Roumanille 1343 Biot - Sophia Antipolis 06410 1344 France 1345 Email: pthubert@cisco.com 1347 Full Copyright Statement 1349 Copyright (C) The Internet Society (2003). All Rights Reserved. 1351 This document and translations of it may be copied and furnished to 1352 others, and derivative works that comment on or otherwise explain it 1353 or assist in its implementation may be prepared, copied, published 1354 and distributed, in whole or in part, without restriction of any 1355 kind, provided that the above copyright notice and this paragraph 1356 are included on all such copies and derivative works. However, 1357 this document itself may not be modified in any way, such as by 1358 removing the copyright notice or references to the Internet Society 1359 or other Internet organizations, except as needed for the purpose 1360 of developing Internet standards in which case the procedures 1361 for copyrights defined in the Internet Standards process must be 1362 followed, or as required to translate it into languages other than 1363 English. 1365 The limited permissions granted above are perpetual and will not be 1366 revoked by the Internet Society or its successors or assignees. 1368 This document and the information contained herein is provided on an 1369 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1370 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1371 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1372 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1373 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1375 Acknowledgement 1377 Funding for the RFC Editor function is currently provided by the 1378 Internet Society.