idnits 2.17.1 draft-ietf-mip6-ha-switch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 507. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2007) is 6027 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-09) exists of draft-ietf-mip6-hareliability-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IPv6 B. Haley 3 Internet Draft Hewlett-Packard 4 Document: draft-ietf-mip6-ha-switch-04.txt V. Devarapalli 5 Intended status: Standards Track Azaire Networks 6 Expires: April 26, 2008 H. Deng 7 Hitachi 8 J. Kempf 9 DoCoMo USA Labs 10 October 26, 2007 12 Mobility Header Home Agent Switch Message 13 draft-ietf-mip6-ha-switch-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document specifies a new Mobility Header message type that can 41 be used between a home agent and mobile node to signal a mobile node 42 that it should acquire a new home agent. 44 Table of Contents 46 1. Introduction...................................................2 47 2. Terminology....................................................2 48 3. Scenarios......................................................3 49 3.1 Overloaded.................................................3 50 3.2 Load Balancing.............................................3 51 3.3 Maintenance................................................3 52 3.4 Functional Load Balancing..................................3 53 3.5 Home Agent Renumbering.....................................4 54 4. Home Agent Switch Message......................................4 55 5. Home Agent Operation...........................................6 56 5.1 Sending Home Agent Switch Messages.........................6 57 5.2 Retransmissions............................................7 58 5.3 Mobile Node Errors.........................................7 59 6. Mobile Node Operation..........................................8 60 6.1 Receiving Home Agent Switch Messages.......................8 61 6.2 Selecting a Home Agent.....................................8 62 7. Operational Considerations.....................................9 63 8. Procotol Constants.............................................9 64 9. IANA Considerations............................................9 65 10. Security Considerations.......................................9 66 11. References...................................................10 67 11.1 Normative References.....................................10 68 11.2 Informative references...................................10 69 Acknowledgments..................................................10 70 Author's Addresses...............................................10 72 1. Introduction 74 RFC 3775 [2] contains no provision to allow a home agent to inform a 75 mobile node that it needs to stop acting as the home agent for the 76 mobile node. For example, a home agent may wish to handoff some of 77 its mobile nodes to another home agent because it has become 78 overloaded or it is going offline. 80 This protocol describes a signaling message type that can be used to 81 send a handoff notification between a home agent and mobile node. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [1]. 89 3. Scenarios 91 Here are some example scenarios where a home agent signaling message 92 would be useful. 94 3.1 Overloaded 96 There are a number of reasons a home agent might be considered 97 overloaded. One might be that it is at, or near, its limit on the 98 number of home bindings it is willing to accept. Another is that it 99 has reached a pre-determined level of system resource usage - memory, 100 cpu cycles, etc. In either case, it would be desirable for a home 101 agent to reduce the number of home bindings before a failure occurs. 103 3.2 Load Balancing 105 A home agent might know of other home agents that are not as heavily 106 loaded as itself, learned through some other mechanism outside the 107 scope of this document. An operator may wish to try and balance this 108 load so a failure disrupts a smaller percentage of mobile nodes. 110 3.3 Maintenance 112 Most operators do periodic maintenance in order to maintain 113 reliability. If a home agent is being shutdown for maintenance, it 114 would be desirable to inform mobile nodes so they do not lose 115 mobility service. 117 3.4 Functional Load Balancing 119 A Mobile IPv6 home agent provides mobile nodes with two basic 120 services - a rendezvous server where correspondent nodes can find the 121 current care-of address for the mobile node, and as an overlay router 122 to tunnel traffic to/from the mobile node at its current care-of 123 address. 125 A mobility service provider could have two sets of home agents to 126 handle the two functions. The rendezvous function could be handled 127 by a machine specialized for high-speed transaction processing, while 128 the overlay router function could be handled by a machine with high 129 data throughput. 131 A mobile node would start on the rendezvous server home agent and 132 stay there if it does route optimization. However, if the original 133 home agent detects that the mobile node is not doing route 134 optimization, but instead reverse-tunneling traffic, it could 135 redirect the mobile node to a home agent with better data throughput. 137 3.5 Home Agent Renumbering 139 Periodically, a mobility service provider may want to shut-down home 140 agent services at a set of IPv6 addresses and bring service back up 141 at a new set of addresses. Note that this may not involve anything 142 as complex as IPv6 network renumbering [3], it may just involve 143 changing the addresses of the home agents. With a signaling message, 144 the service provider could inform mobile nodes to look for a new home 145 agent. 147 4. Home Agent Switch Message 149 The Home Agent Switch message is used by the home agent to signal the 150 mobile node that it needs to stop acting as the home agent for the 151 mobile node, and that it should acquire a new home agent. Home Agent 152 Switch messages are sent as described in Section 5. 154 The message described below follows the Mobility Header format 155 specified in Section 6.1 of [2]: 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Payload Proto | Header Len | MH Type | Reserved | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Checksum | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 162 | | 163 . . 164 . Message Data . 165 . . 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 The Home Agent Switch Message uses the MH Type value (TBD). When 170 this value is indicated in the MH Type field, the format of the 171 Message Data field in the Mobility Header is as follows: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |# of Addresses | Reserved | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 + + 180 . . 181 . Home Agent Addresses . 182 . . 183 + + 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 + + 188 . . 189 . Mobility options . 190 . . 191 + + 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 # of Addresses 197 An 8-bit unsigned integer indicating the number of IPv6 home agent 198 addresses in the message. If set to zero, the mobile node MUST 199 perform home agent discovery. 201 Reserved 203 8-bit field reserved for future use. The value MUST be initialized 204 to zero by the sender, and MUST be ignored by the receiver. 206 Home Agent Addresses 208 A list of alternate home agent addresses for the mobile node. The 209 number of addresses present in the list is indicated by the "# of 210 Addresses" field in the Home Agent Switch message. 212 Mobility options 214 Variable-length field of such length that the complete Mobility 215 Header is an integer multiple of 8 octets long. This field 216 contains zero or more TLV-encoded mobility options. The encoding 217 and format of defined options MUST follow the format specified in 218 Section 6.2 of [2]. The receiver MUST ignore and skip any options 219 which it does not understand. 221 The Binding Refresh Advice mobility option defined in Section 6.2.4 222 of [2] is valid for the Home Agent Switch message. 224 If no home agent addresses and no options are present in this 225 message, no padding is necessary and the Header Len field in the 226 Mobility Header will be set to 0. 228 5. Home Agent Operation 230 5.1 Sending Home Agent Switch Messages 232 When sending a Home Agent Switch message, the sending node constructs 233 the packet as it would any other Mobility Header, except: 235 o The MH Type field MUST be set to (TBD). 237 o If alternative home agent addresses are known, the sending home 238 agent SHOULD include them in the list of suggested alternate 239 home agents. The home agent addresses field should be 240 constructed as described in Section 10.5.1 of [2], which will 241 randomize addresses of the same preference in the list. 243 o The "# of addresses" field MUST be filled-in corresponding to 244 the number of home agent addresses included in the message. If 245 no addresses are present, the field MUST be set to zero, forcing 246 the mobile node to perform home agent discovery by some other 247 means. 249 o If the home agent is able to continue offering services to the 250 mobile node for some period of time, it MAY include a Binding 251 Refresh Advice mobility option indicating the time (in units of 252 4 seconds) until the binding will be deleted. 254 The Home Agent Switch message MUST use the home agent to mobile node 255 IPsec ESP authentication SA for integrity protection. 257 A home agent SHOULD send a Home Agent Switch message when a known 258 period of unavailability is pending so the mobile node has sufficient 259 time to find another suitable home agent. 261 The sending node does not need to be the current home agent for the 262 mobile node, for example as described in [4], but it MUST have a 263 security association with the mobile node so the message is not 264 rejected. In this case, the Home Agent Switch message SHOULD only 265 contain the address of the home agent sending the message in the Home 266 Agent Addresses field, which implies the mobile node should switch to 267 using the sender as its new home agent. 269 5.2 Retransmissions 271 If the home agent does not receive a response from the mobile node - 272 either a Binding Update message to delete its home binding if it is 273 the current home agent, or a Binding Update message to create a home 274 binding if it is not the current home agent, then it SHOULD 275 retransmit the message, until a response is received. The initial 276 value for the retransmission timer is INITIAL-HA-SWITCH-TIMEOUT. 278 The retransmissions by the home agent MUST use an exponential back- 279 off mechanism, in which the timeout period is doubled upon each 280 retransmission, until either the home agent gets a response from the 281 mobile node to delete its binding, or the timeout period reaches the 282 value MAX-HA-SWITCH-TIMEOUT. The home agent MAY continue to send 283 these messages at this slower rate indefinitely. 285 If the home agent included a Binding Refresh Advice mobility option, 286 then it SHOULD delay any retransmissions until at least one half of 287 the time period has expired, or INITIAL-HA-SWITCH-TIMEOUT, whichever 288 value is less. 290 5.3 Mobile Node Errors 292 If a mobile node does not understand how to process a Home Agent 293 Switch Message, it will send a Binding Error message as described in 294 Section 6.1. 296 If a mobile node is unreachable, in other words, it still has a home 297 binding with the home agent after reaching the timeout period of MAX- 298 HA-SWITCH-TIMEOUT, the home agent SHOULD NOT make any conclusions 299 about its status. 301 In either case, the home agent SHOULD attempt to continue providing 302 services until the lifetime of the binding expires. 304 Attempts by the mobile node to extend the binding lifetime with a 305 Binding Update message SHOULD be rejected, and a Binding 306 Acknowledgement SHOULD be returned with status value 129 307 (Administratively prohibited) as specified in Section 6.1.8 of [2]. 309 6. Mobile Node Operation 311 6.1 Receiving Home Agent Switch Messages 313 Upon receiving a Home Agent Switch message, the Mobility Header MUST 314 be verified as specified in [2], specifically: 316 o The Checksum, MH type, Payload Proto and Header Len fields 317 MUST meet the requirements of Section 9.2 of [2]. 319 o The packet MUST be authenticated, either by the home agent to 320 mobile node IPsec ESP authentication SA for integrity 321 protection, or a home agent to mobile node authentication 322 option. 324 If the packet is dropped due to the above tests, the receiving node 325 MUST follow the processing rules as Section 9.2 of [2] defines. For 326 example, it MUST send a Binding Error message with the Status field 327 set to 2 (unrecognized MH Type value) if it does not support the 328 message type. 330 Upon receipt of a Home Agent Switch message, the mobile node MUST 331 stop using its current home agent for services and MUST delete its 332 home binding by sending a Binding Update message as described in 333 Section 11.7.1 of [2]. This acts as an acknowledgement of the Home 334 Agent Switch message. Alternately, if the sender of the message is 335 not the current home agent, sending a Binding Update message to 336 create a home binding will act as an acknowledgement of the Home 337 Agent Switch message. Retransmissions of Binding Update messages 338 MUST use the procedures described in Section 11.8 of [2]. 340 If a Binding Refresh Advice mobility option is present, the mobile 341 node MAY delay the deletion of its home binding and continue to use 342 its current home agent until the calculated time period has expired. 344 If the Home Agent Switch message contains a list of alternate home 345 agent addresses, the mobile node SHOULD select a new home agent as 346 described in Section 6.2, and establish the necessary IPsec security 347 associations with the new home agent by whatever means required as 348 part of the mobile node/home agent bootstrapping protocol for the 349 home agent's mobility service provider. If no alternate home agent 350 addresses are included in the list, the mobile node MUST first 351 perform home agent discovery. 353 6.2 Selecting a Home Agent 355 In most cases, the home agent addresses in the Home Agent Switch 356 message will be of other home agents on the home link of the mobile 357 node (the computed prefix is the same). In this case, the mobile 358 node SHOULD select a new home agent from the addresses as they are 359 ordered in the list. If the first address in the list is unable to 360 provide service, then the subsequent addresses in the list should be 361 tried in-order. 363 In the case that the home agent addresses in the Home Agent Switch 364 message are not all home agents on the home link of the mobile node 365 (the computed prefix is different), the mobile node SHOULD select one 366 its home network prefix first, if available, followed by home agents 367 with other prefixes. Choosing a home agent with a different prefix 368 might require a change of the home address for the mobile node, which 369 could cause a loss of connectivity for any connections using the 370 current home address. 372 7. Operational Considerations 374 This document does not specify how an operator might use the Home 375 Agent Switch message in its network. However, it might be the case 376 that a home agent provides service for many thousands of mobile 377 nodes. Care should be taken to reduce the signaling overhead on the 378 network required for handing off many mobile nodes to an alternate 379 home agent. 381 8. Procotol Constants 383 INITIAL-HA-SWITCH-TIMEOUT 5 seconds 384 MAX-HA-SWITCH-TIMEOUT 20 seconds 386 9. IANA Considerations 388 A new Mobility Header type is required for the following new message 389 described in Section 4: 391 (TBD) Home Agent Switch message 393 10. Security Considerations 395 As with other messages in [2], the Home Agent Switch message MUST use 396 the home agent to mobile node ESP encryption SA for confidentiality 397 protection, and MUST use the home agent to mobile node ESP 398 authentication SA for integrity protection. 400 The Home Agent Switch message MAY use the IPsec ESP SA in place for 401 Binding Updates and Acknowledgements as specified in Section 5.1 of 402 [2], in order to reduce the number of configured security 403 associations. This also gives the message authenticity protection. 405 Some operators may not want to reveal the list of home agents to on- 406 path listeners. In such a case, the Home Agent Switch message should 407 use the home agent to mobile node IPsec ESP encryption SA for 408 confidentiality protection. 410 11. References 412 11.1 Normative References 414 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 415 Levels", BCP 14, RFC 2119, March 1997. 417 [2] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 418 IPv6", RFC 3775, June, 2004. 420 11.2 Informative References 422 [3] Baker, F., Lear, E., and Droms, R., "Procedures for Renumbering 423 an IPv6 Network without a Flag Day", RFC 4192, September, 2005. 425 [4] Wakikawa, R. (Editor), "Home Agent Reliability Protocol", draft- 426 ietf-mip6-hareliability-02.txt, July, 2007. 428 Acknowledgments 430 We would like to thank the authors of a number of previous drafts 431 that contributed content to this document: 433 o draft-wakikawa-mip6-nemo-haha-spec-00.txt 434 o draft-deng-mip6-ha-loadbalance-02.txt 435 o draft-kempf-mip6-ha-alert-00.txt 436 o draft-haley-mip6-mh-signaling-00.txt 438 Thanks also to Kilian Weniger, Jixing Liu, Alexandru Petrescu, Jouni 439 Korhonen, and Wolfgang Fritsche for their review and feedback. 441 Author's Addresses 443 Brian Haley 444 Hewlett-Packard Company 445 110 Spitbrook Road 446 Nashua, NH 03062, USA 447 Email: brian.haley@hp.com 449 Vijay Devarapalli 450 Azaire Networks 451 3121 Jay Street 452 Santa Clara, CA 95054 USA 453 Email: vijay.devarapalli@azairenet.com 455 James Kempf 456 DoCoMo USA Labs 457 181 Metro Drive 458 Suite 300 459 San Jose, CA 95110 USA 460 Email: kempf@docomolabs-usa.com 462 Hui Deng 463 Research & Development Center 464 Hitachi (China), Investment Ltd. 465 Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu 466 Chao Yang District, Beijing 100004, China 467 Email: hdeng@hitachi.cn 469 Full Copyright Statement 471 Copyright (C) The IETF Trust (2007). 473 This document is subject to the rights, licenses and restrictions 474 contained in BCP 78, and except as set forth therein, the authors 475 retain all their rights. 477 This document and the information contained herein are provided on an 478 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 479 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 480 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 481 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 482 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 483 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 Intellectual Property 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. 509 Acknowledgement 511 Funding for the RFC Editor function is provided by the IETF 512 Administrative Support Activity (IASA).