idnits 2.17.00 (12 Aug 2021) /tmp/idnits42328/draft-koh-dihap-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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 626), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 12) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances 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 229: '...ved for future use. The value MUST be...' RFC 2119 keyword, line 230: '... the sender, and MUST be ignored by th...' RFC 2119 keyword, line 274: '...n contained within this update MUST be...' RFC 2119 keyword, line 325: '...n contained within this update MUST be...' RFC 2119 keyword, line 379: '... The mobile node MUST be able to inter...' (9 more instances...) 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 2004) is 6549 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) == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') ** Obsolete normative reference: RFC 3775 (ref. '6') (Obsoleted by RFC 6275) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Koh 2 Internet-Draft C. Ng 3 Expires: November 30, 2004 Panasonic Singapore Labs 4 J. Hirano 5 Panasonic 6 June 2004 8 Dynamic Inter Home Agent Protocol 9 draft-koh-dihap-00 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 30, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This draft describes a proposed Dynamic Inter Home Agent solution to 42 provide redundancy and load balancing of Home Agents. The proposed 43 solution recommends additional communication between home agents that 44 may be located far apart in terms of network topology but still 45 belonging to or are trusted by the same administrative domains 46 (service providers). While the mobile node is roaming away from its 47 home network, intervening home agents in the path of the 48 bidirectional tunnel between the mobile node and its registered home 49 agent may detect its presence. The intervening home agents that are 50 affiliated to the current home agent of the mobile node then proceed 51 to update it of their availability to serve as home agent for the 52 mobile node. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview of Dynamic Inter Home Agents Protocol . . . . . . . . 4 59 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1 Home Agent Change Message . . . . . . . . . . . . . . . . 5 61 4.2 Affiliated Home Agent Update Message . . . . . . . . . . . 6 62 4.3 Home Interface List Update Message . . . . . . . . . . . . 7 63 5. Home Interface List . . . . . . . . . . . . . . . . . . . . . 9 64 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 9 65 6.1 Home Agent Notification . . . . . . . . . . . . . . . . . 10 66 6.1.1 Separate Anycast . . . . . . . . . . . . . . . . . . . 10 67 6.1.2 Piggy-backed Anycast . . . . . . . . . . . . . . . . . 10 68 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 10 69 7.1 Original Home Agent . . . . . . . . . . . . . . . . . . . 10 70 7.1.1 Solo Operation . . . . . . . . . . . . . . . . . . . . 10 71 7.1.2 Centralised Operation . . . . . . . . . . . . . . . . 11 72 7.2 Affiliated Home Agent . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 77 Intellectual Property and Copyright Statements . . . . . . . . 15 79 1. Introduction 81 For Mobile IPv6 [6], mobile nodes either tunnel its traffic through a 82 bi-directional tunnel via its home agent or it may employ route 83 optimisation with the correspondent node it is in communication with. 84 For NEMO Basic Support [1], the default mode of operation is to 85 tunnel all traffic meant for the mobile network through the home 86 agent serving the mobile router. As such, home agents may greatly 87 affect the effectiveness and efficiency with respect to the terminals 88 that deploy these two protocols. With the widespread prolification 89 of mobile terminals and supporting services, this may gain increasing 90 importance as a influencing factor. Sometimes, the mobile host and 91 its network could be closer to the correspondent node than the Home 92 Agent or the home agent becomes increasing congested and overloaded. 93 By choosing a home closer to its current location, the network 94 traffic could be significantly reduced as well as improving the 95 overall performance of the mobile host or network. One solution for 96 solving this problem is described in [3], the Inter Home Agents 97 Protocol proposes that the mobile node be provided with multiple home 98 agents and any of the home agents can forward packets to and from the 99 the mobile node. However, the downside to the proposed solution is 100 the constant updating between all of the home agents. This is 101 irregardless of whether or not the other home agents are useful to 102 the mobile node. There is hence a fixed increase in signalling 103 overhead per number of home agents involved. 105 This draft describes a proposed Dynamic Inter Home Agent solution to 106 provide redundancy and load balancing of Home Agents. The proposed 107 solution recommends additional communication between home agents that 108 may be located far apart in terms of network topology but still 109 belonging to or are trusted by the same administrative domains 110 (service providers). While the mobile node is roaming away from its 111 home network, intervening home agents in the path of the 112 bidirectional tunnel between the mobile node and its registered home 113 agent may detect its presence. The intervening home agents that are 114 affiliated to the current home agent of the mobile node then proceed 115 to update it of their availability to serve as home agent for the 116 mobile node. 118 The proposed solution employs the use of an addition Home Interface 119 List as a repository of the received updates from other home agents 120 including local interfaces that are serving as home agents. The 121 location of the Home Interface List gives rise to the two operation 122 modes of the solution. When the list is located on the home agent 123 itself, this is referred to as the solo mode of operation. However, 124 it is possible to locate the list on a topologically different 125 location. This is referred to as the centralised mode of operation. 127 2. Terminology 129 There are separate documents regarding Mobility terminology [5] as 130 well as Nemo terminology [2], which defines the terms related to 131 Network Mobility used in the document. This document in addition 132 defines the following term. 134 Affiliated Home Agent 136 A home agent that is known and trusted by a singular or group 137 of home agents. 139 3. Overview of Dynamic Inter Home Agents Protocol 141 When a home agent is deployed, each home agent should be configured 142 with the prefixes of other affiliated home agents. 144 A Home Interface List comprising of information such as interface and 145 mobile node addresses should be available to the home agent. The 146 list may be located on the home agent or at a remote location (e.g. 147 some other home agent) that is preconfigured in the home agent. This 148 information is different from the Binding Cache of the home agent as 149 its entries comprises of all the available interfaces able to serve 150 as a home agent. Each entry should preferably have a metric to 151 indicate preference for use as a home agent interface. The 152 preference metric should be updated as the situation requires it. 153 Each entry may optionally have a corresponding mobile node address to 154 indicate that the interface should only be considered for the 155 indicated mobile node. For each such mobile node entry, there should 156 also be a corresponding selection metric. 158 The home agent should first register all of its interfaces available 159 to serve as home agent interfaces with the Home Interface List. When 160 a registered interface is no longer available, it should be 161 deregistered from the List. Unavailability may be due possibly to 162 the link going down or congestion. 164 When choosing an interface to serve as the home agent for the mobile 165 node, the home agent may choose from its available local interfaces 166 or it may alternatively consult the Home Interface List. 168 +-----------------------------------------------------+ 169 | | 170 | Internet HA4 | 171 | | 172 | HA2 | 173 | | +-------+ 174 | /---|==HA==| Home | 175 | /-----/ | |Network| 176 | /------/ | +-------+ 177 | /-----HA3-----/ Packet Path | 178 | MN-----HA1----/ | 179 | | 180 +-----------------------------------------------------+ 182 During normal operation, the home agent (HA1, HA3) may detect or be 183 informed of the presence of mobile nodes (MN) registered with an 184 affiliated home agent (HA) roaming in their vicinity. Upon such 185 occasion, the home agent (HA1, HA3) may choose to inform the 186 destination affiliated home agent (HA)of its availability to serve as 187 a home agent for the mobile node (MN). The Home Interface List of 188 the destination affiliated home agent (HA) is updated accordingly. 190 The home agent (HA) may choose to actively inform a registered mobile 191 node (MN) to switch to another home agent interface. In this case, a 192 Home Agent Change message may be sent to the mobile node (MN) with 193 the address of the new home agent interface address (HA1). The 194 mobile node (MN) should then proceed to register itself with the 195 given home agent interface (HA1). 197 The Home Interface List may be shared amongst several home agents. 198 In this scenario, the list may be hosted on one of the home agents or 199 at another remote location. 201 4. Message Formats 203 4.1 Home Agent Change Message 205 The Home Agent Change message is used by a home agent to request a 206 mobile node to perform a home registration with a specific home 207 agent. 209 The Home Agent Change message uses the MH Type value 8. When this 210 value is indicated in the MH Type field, the format of the Message 211 Data field in the Mobility Header is as follows: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Reserved | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 + + 220 | | 221 + Alternate Home Agent Address + 222 | | 223 + + 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Reserved 229 16-bit field reserved for future use. The value MUST be 230 initialized to zero by the sender, and MUST be ignored by the 231 receiver. 233 Alternate Home Agent Address 235 The address of the new home agent with which the mobile node 236 should initiate a home registration. 238 4.2 Affiliated Home Agent Update Message 240 The Affiliated Home Agent Update message is used by an affiliated 241 home agent to inform a home agent of its availability and suitability 242 to act as a home agent for the detected mobile node in question. 244 The Affiliated Home Agent Update message uses the MH Type value 9. 245 When this value is indicated in the MH Type field, the format of the 246 Message Data field in the Mobility Header is as follows: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |Hop Limit Count| Lifetime | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 + + 255 | | 256 + Detected Mobile Node Care-of-Address + 257 | | 258 + + 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Hop Limit Count 264 8-bit field specify the initial Hop Count of the IPv6 header. 265 By subtracting Hop Limit Count from the Hop Count, it is 266 possible to estimate the distance (in hops) of the affiliated 267 home agent from the registered home agent. This value may then 268 be used as the metric value in the Home Interface List Update 269 message. 271 Lifetime 273 8-bit unsigned integer. The number of time units remaining 274 before the information contained within this update MUST be 275 considered expired. One time unit is 4 seconds. 277 Detected Mobile Node Care-of-Address 279 The current Care-of-Address of the mobile node that was 280 detected by the affiliated home agent. 282 4.3 Home Interface List Update Message 284 The Home Interface List Update message is used by a home agent to 285 update the Home Interface List when the home agent is operating in 286 centralised mode. This means that the Home Interface List is 287 actually hosted on an entity at a remote location and the home agent 288 itself. 290 The Home Interface List Update message uses the MH Type value 10. 291 When this value is indicated in the MH Type field, the format of the 292 Message Data field in the Mobility Header is as follows: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Metric | Lifetime | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | | 300 + + 301 | | 302 + Home Agent Interface Address + 303 | | 304 + + 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 . . 309 . Mobile Node Home Address . 310 . . 311 | | 313 Metric 315 8-bit unsigned integer. The number reflections the 316 desirability of using the interface specified in the message as 317 a home agent. Metric values for entries of local interfaces 318 should not used to compare with the metric values for entries 319 created for affiliated home agents as their derivation may 320 differ. 322 Lifetime 324 8-bit unsigned integer. The number of time units remaining 325 before the information contained within this update MUST be 326 considered expired. One time unit is 4 seconds. 328 Home Agent Interface Address 330 The address of the interface that is available to serve as a 331 home agent. If the Mobile Node Home Address field exists, the 332 interface will only serve as home agent for that mobile node. 334 Mobile Node Home Address 336 Only found for messages corresponding to Affiliated Home Agent 337 Update messages. This field may be left out if not applicable. 338 The existence of this field may be deduced from the Header Len 339 field of the Mobility Header. 341 5. Home Interface List 343 The Home Interface List maintains a record of available interfaces 344 for which may serve as home agents for mobile nodes. A Home 345 Interface List may either be maintained by each home agent node or 346 else at a known location. The Home Interface List may be implemented 347 in any manner consistent with the external behavior described in this 348 document, for example by being combined with the node's Binding Cache 349 as maintained by Mobile IP. When responding to a home registration 350 request or performing load balancing for congested interfaces, the 351 home agent may choose to utilise local interfaces or else the Home 352 Interface List should be searched. 354 Each Home Interface List entry conceptually contains the following 355 fields: 357 o The address of the interface to serve as a home agent 359 o The address of the specific mobile node for which the interface is 360 willing to serve as a home agent. This value may be left blank. 361 Entries with a value in this field should be given higher priority 362 when a request is made for the mobile node in question. 364 o A metric value. This may be a preference value for using this 365 interface. When there is a valid value in the mobile node address 366 field however, this metric may be used to signify the proximity of 367 the interface to the mobile node in question. 369 o A lifetime value, indicating the remaining lifetime for this Home 370 Interface List entry. This may be mandatory for all entries in a 371 remotely located Home Interface List, else required only for 372 entries with a valid mobile node address field value. 374 The Home Interface List should be updated when interfaces come out or 375 are taken off due to congestion or otherwise. 377 6. Mobile Node Operation 379 The mobile node MUST be able to interpret the new Home Agent Change 380 message in order for the Dynamic Inter Home Agent Protocol to 381 function. Upon the receipt of the option, the mobile node should 382 perform the following actions: 384 o Check that there is a corresponding home registration entry for 385 the source address given in the packet containing the option. If a 386 corresponding entry is not found, the packet MUST be silently 387 discarded. 389 o If a corresponding home registration entry was found, the 390 Alternate Home Agent Address should be retrieved from the option 391 and the Home Registration process started with the new Home Agent. 393 o The mobile node MAY choose to expire the home registration with 394 its old home agent, it may otherwise allow it to expire normally. 396 6.1 Home Agent Notification 398 The mobile MAY choose to take no specific action to notify any nearby 399 home agents. However, this may be the least effective method of 400 implementing the solution. Better alternatives involving the use of 401 anycasting are given below. 403 6.1.1 Separate Anycast 405 For a mobile node that implements the Separate Anycast, whenever the 406 mobile node sends a Binding Update to its registered home agent, a 407 separate packet with the destination address set to the value of 408 Mobile IPv6 Home-Agents anycast address [4] is sent. The source 409 address of the packet should be set to the mobile node's current 410 Care-of-Address. The packet should contain the address of the mobile 411 node's current home agent. 413 6.1.2 Piggy-backed Anycast 415 For a mobile node that implements the Piggy-backed Anycast, the 416 mobile node should encapsulate the Binding Update to its registered 417 home agent. The new IPv6 header should have the source address set to 418 the mobile node's current Care-of-address and the destination address 419 as the Mobile IPv6 Home-Agents anycast address. 421 7. Home Agent Operation 423 7.1 Original Home Agent 425 The original home agent is the home agent with which the mobile node 426 currently has a home registration. When the Home Interface List is 427 located on the home agent itself, it is described as performing in 428 solo mode. Locating the Home Interface List on a remote interface or 429 on another home agent is called the centralised operation mode. 431 7.1.1 Solo Operation 433 The home agent operates as per Mobile IP [6] and NEMO [1], however, 434 it should also register the interfaces on which it is serving as a 435 home agent with the Home Interface List. Home registration requests 436 are handled normally. However, if and when it decides to do load 437 balancing either due to traffic congestion or impending link going 438 down, it MAY arbitrarily choose a local interface or else query the 439 Home Interface List. It MAY then send a message with the Home Agent 440 Change message to the affected mobile node(s) requesting that the 441 mobile node register itself with the new home agent. 443 When the home agent receives an Affiliated Home Agent Update message 444 addressed to itself, it should perform the following actions: 446 o Check that the source address of the packet contains the address 447 belonging to an affiliated home agent or group of home agents. The 448 packet should be silently discarded otherwise. 450 o Check that the Detected Mobile Node Care-of-Address field has a 451 corresponding Care-of-Address entry in the Binding Cache and that 452 it is a Home Registration. 454 o Update the Home Interface List with the address of the affiliated 455 home agent interface, the specified mobile node's home address, 456 the lifetime for which the entry is valid and the metric. The 457 metric described here is calculated by deducting the Hop Limit 458 Count field in the Affiliated Home Agent Update message from the 459 current Hop Limit value in the IPv6 header field. This should 460 yield the approximate distance (in hops) to the affiliated home 461 agent. 463 7.1.2 Centralised Operation 465 The home agent in centralised operation is essentially similar to 466 solo operation. The key difference being that all updates to the 467 Home Interface List should be forwarded to the entity hosting the 468 list. Additionally, the home agent should update its local interfaces 469 that are serving as home agents with the remote Home Interface List 470 together with a lifetime entry and should periodically do so before 471 the lifetime expires. 473 When the home agent receives an Affiliated Home Agent Update message 474 from a intermediate home agent, it should as per Solo operation check 475 that the source home agent of the the message is valid. The Detected 476 Mobile Node Care-of-Address field is then checked with the Binding 477 Cache for a match. Assuming a match is found, the Home Interface List 478 Update message is created and sent to be updated at the remote Home 479 Interface List. 481 The remote Home Interface List may be queried for a home agent 482 address by the home agent by sending a Query message with a payload 483 consisting of a magic number and the home address of the mobile node. 484 The Reply message from the Home Interface List should have a payload 485 consisting of the same magic number contained in the Query message as 486 well as the selected home agent interface address. 488 It is assumed that the home agents and the entity hosting the Home 489 Interface List are known to each other. 491 7.2 Affiliated Home Agent 493 Affiliated home agents MAY actively scan forwarded packets for the 494 existence of a mobility header and an affiliated home agent address 495 in the destination address field. They then send a Alternate Home 496 Agent Update to the destination address of the intercepted packet. 497 This assumes that the home agent is also a operating as a router. 498 The more efficient and effective method would be for the mobile node 499 to use anycasting. In any case, the affiliated home agent would take 500 the following actions: 502 o Detect presence of Binding Updates to a home agent. 504 o Check that destination home agent belongs to list of affiliated 505 home agents (e.g. by checking the network prefix). Perform 506 relevant packet processing. Forwarding the packet if it was 507 intercepted, Decapsulating and forwarding a piggy-backed anycast 508 or discarding a separate anycast notification packet. 510 o Check Home Interface List to look for available interface to serve 511 as the home agent for the mobile node. 513 o Create and send the Affiliated Home Agent Update message and send 514 it to the home agent specified in the destination address. 516 8. IANA Considerations 518 This document defines three new Mobility Header messages 520 o Home Agent Change Message 522 o Affiliated Home Agent Update Message 524 o Home Interface List Update Message 526 9. Security Considerations 528 A home agent MUST know whether the other home agent is an affiliated 529 home agent. Affiliated home agents SHOULD establish secure 530 associations with each other before sending Affiliated Home Agent 531 Updates. All signaling messages between the home agents SHOULD be 532 authenticated and encrypted (e.g. by using IPsec ESP) 534 Please refer to the Mobile IPv6 specification [6] and the NEMO Basic 535 Support protocol specification [1] for security considerations. 537 10 References 539 [1] Devarapalli, V., "Network Mobility (NEMO) Basic Support 540 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 541 June 2004. 543 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 544 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 546 [3] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home Agents 547 Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in 548 progress), February 2004. 550 [4] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 551 Addresses", IETF RFC 2526, March 1999. 553 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 554 3753, June 2004. 556 [6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 557 IPv6", RFC 3775, June 2004. 559 Authors' Addresses 561 Benjamin Koh 562 Panasonic Singapore Laboratories Pte Ltd 563 Blk 1022 Tai Seng Ave #06-3530 564 Tai Seng Industrial Estate 565 Singapore 534415 566 SG 568 EMail: benjamin@psl.com.sg 569 Chan-Wah Ng 570 Panasonic Singapore Laboratories Pte Ltd 571 Blk 1022 Tai Seng Ave #06-3530 572 Tai Seng Industrial Estate 573 Singapore 534415 574 SG 576 Phone: +65 65505420 577 EMail: cwng@psl.com.sg 579 Jun Hirano 580 Matsushita Electric Industrial Co., Ltd. (Panasonic) 581 5-3 Hikarino-oka 582 Yokosuka, Kanagawa 239-0847 583 JP 585 Phone: +81 46 840 5123 586 EMail: hirano.jun@jp.panasonic.com 588 Intellectual Property Statement 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the IETF's procedures with respect to rights in IETF Documents can 597 be found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org. 612 Disclaimer of Validity 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 617 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 618 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 619 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Copyright Statement 624 Copyright (C) The Internet Society (2004). This document is subject 625 to the rights, licenses and restrictions contained in BCP 78, and 626 except as set forth therein, the authors retain all their rights. 628 Acknowledgment 630 Funding for the RFC Editor function is currently provided by the 631 Internet Society.