idnits 2.17.1 draft-ietf-mip6-ha-switch-03.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 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. 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 (March 2007) is 6245 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-01 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-03.txt V. Devarapalli 5 Intended status: Standards Track Azaire Networks 6 Expires: September, 2007 H. Deng 7 Hitachi 8 J. Kempf 9 DoCoMo USA Labs 10 March 2007 12 Mobility Header Home Agent Switch Message 13 draft-ietf-mip6-ha-switch-03.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 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119 [1]. 49 Table of Contents 51 1. Introduction...................................................2 52 2. Scenarios......................................................2 53 2.1 Overloaded.................................................3 54 2.2 Load Balancing.............................................3 55 2.3 Maintenance................................................3 56 2.4 Functional Load Balancing..................................3 57 2.5 Home Agent Renumbering.....................................3 58 3. Home Agent Switch Message......................................4 59 4. Home Agent Operation...........................................6 60 4.1 Sending Home Agent Switch Messages.........................6 61 4.2 Retransmissions............................................7 62 4.3 Mobile Node Errors.........................................7 63 5. Mobile Node Operation..........................................8 64 5.1 Receiving Home Agent Switch Messages.......................8 65 5.2 Selecting a Home Agent.....................................8 66 6. Operational Considerations.....................................9 67 7. Procotol Constants.............................................9 68 8. IANA Considerations............................................9 69 9. Security Considerations........................................9 70 10. References...................................................10 71 10.1 Normative References.....................................10 72 10.2 Informative references...................................10 73 Acknowledgments..................................................10 74 Author's Addresses...............................................11 76 1. Introduction 78 RFC 3775 [2] contains no provision to allow a home agent to inform a 79 mobile node that it needs to stop acting as the home agent for the 80 mobile node. For example, a home agent may wish to handoff some of 81 its mobile nodes to another home agent because it has become 82 overloaded or it is going offline. 84 This protocol describes a signaling message type that can be used to 85 send a handoff notification between a home agent and mobile node. 87 2. Scenarios 89 Here are some example scenarios where a home agent signaling message 90 would be useful. 92 2.1 Overloaded 94 There are a number of reasons a home agent might be considered 95 overloaded. One might be that it is at, or near, its limit on the 96 number of home bindings it is willing to accept. Another is that it 97 has reached a pre-determined level of system resource usage - memory, 98 cpu cycles, etc. In either case, it would be desirable for a home 99 agent to reduce the number of home bindings before a failure occurs. 101 2.2 Load Balancing 103 A home agent might know of other home agents that are not as heavily 104 loaded as itself, learned through some other mechanism outside the 105 scope of this document. An operator may wish to try and balance this 106 load so a failure disrupts a smaller percentage of mobile nodes. 108 2.3 Maintenance 110 Most operators do periodic maintenance in order to maintain 111 reliability. If a home agent is being shutdown for maintenance, it 112 would be desirable to inform mobile nodes so they do not lose 113 mobility service. 115 2.4 Functional Load Balancing 117 A Mobile IPv6 home agent provides mobile nodes with two basic 118 services - a rendezvous server where correspondent nodes can find the 119 current care-of address for the mobile node, and as an overlay router 120 to tunnel traffic to/from the mobile node at its current care-of 121 address. 123 A mobility service provider could have two sets of home agents to 124 handle the two functions. The rendezvous function could be handled 125 by a machine specialized for high-speed transaction processing, while 126 the overlay router function could be handled by a machine with high 127 data throughput. 129 A mobile node would start on the rendezvous server home agent and 130 stay there if it does route optimization. However, if the original 131 home agent detects that the mobile node is not doing route 132 optimization, but instead reverse-tunneling traffic, it could 133 redirect the mobile node to a home agent with better data throughput. 135 2.5 Home Agent Renumbering 137 Periodically, a mobility service provider may want to shut-down home 138 agent services at a set of IPv6 addresses and bring service back up 139 at a new set of addresses. Note that this may not involve anything 140 as complex as IPv6 network renumbering, it may just involve changing 141 the addresses of the home agents. With a signaling message, the 142 service provider could inform mobile nodes to look for a new home 143 agent. 145 3. Home Agent Switch Message 147 The Home Agent Switch message is used by the home agent to signal the 148 mobile node that it needs to stop acting as the home agent for the 149 mobile node, and that it should acquire a new home agent. Home Agent 150 Switch messages are sent as described in Section 4. 152 The message described below follows the Mobility Header format 153 specified in Section 6.1 of [2]: 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Payload Proto | Header Len | MH Type | Reserved | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Checksum | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 160 | | 161 . . 162 . Message Data . 163 . . 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 The Home Agent Switch Message uses the MH Type value (TBD). When 168 this value is indicated in the MH Type field, the format of the 169 Message Data field in the Mobility Header is as follows: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |# of Addresses | Reserved | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | | 177 + + 178 . . 179 . Home Agent Addresses . 180 . . 181 + + 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 + + 186 . . 187 . Mobility options . 188 . . 189 + + 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 # of Addresses 195 An 8-bit unsigned integer indicating the number of IPv6 home agent 196 addresses in the message. If set to zero, the mobile node MUST 197 perform home agent discovery. 199 Reserved 201 8-bit field reserved for future use. The value MUST be initialized 202 to zero by the sender, and MUST be ignored by the receiver. 204 Home Agent Addresses 206 A list of alternate home agent addresses for the mobile node. The 207 number of addresses present in the list is indicated by the "# of 208 Addresses" field in the Home Agent Switch message. 210 Mobility options 212 Variable-length field of such length that the complete Mobility 213 Header is an integer multiple of 8 octets long. This field 214 contains zero of more TLV-encoded mobility options. The encoding 215 and format of defined options MUST follow the format specified in 216 Section 6.2 of [2]. The receiver MUST ignore and skip any options 217 with it does not understand. 219 The Binding Refresh Advice mobility option defined in Section 6.2.4 220 of [2] is valid for the Home Agent Switch message. 222 If no home agent addresses and no options are present in this 223 message, no padding is necessary and the Header Len field in the 224 Mobility Header will be set to 0. 226 4. Home Agent Operation 228 4.1 Sending Home Agent Switch Messages 230 When sending a Home Agent Switch message, the sending node constructs 231 the packet as it would any other Mobility Header, except: 233 o The MH Type field MUST be set to (TBD). 235 o If alternative home agent addresses are known, the sending home 236 agent SHOULD include them in the list of suggested alternate 237 home agents. The home agent addresses field should be 238 constructed as described in Section 10.5.1 of [2], which will 239 randomize addresses of the same preference in the list. 241 o The "# of addresses" field MUST be filled-in corresponding to 242 the number of home agent addresses included in the message. If 243 no addresses are present, the field MUST be set to zero, forcing 244 the mobile node to perform home agent discovery by some other 245 means. 247 o If the home agent is able to continue offering services to the 248 mobile node for some period of time, it MAY include a Binding 249 Refresh Advice mobility option indicating the time (in units of 250 4 seconds) until the binding will be deleted. 252 The Home Agent Switch message MUST be authenticated in one of the 253 following ways: 255 o The home agent to mobile node IPsec ESP authentication SA for 256 integrity protection. 258 o A home agent to mobile node authentication option, such as [3]. 260 A home agent SHOULD send a Home Agent Switch message when a known 261 period of unavailability is pending so the mobile node has sufficient 262 time to find another suitable home agent. 264 The sending node does not need to be the current home agent for the 265 mobile node, for example as described in [4], but it MUST have a 266 security association with the mobile node so the message is not 267 rejected. In this case, the Home Agent Switch message SHOULD only 268 contain the address of the home agent sending the message in the Home 269 Agent Addresses field, which implies the mobile node should switch to 270 using the sender as its new home agent. 272 4.2 Retransmissions 274 If the home agent does not receive a response from the mobile node - 275 either a Binding Update message to delete its home binding if it is 276 the current home agent, or a Binding Update message to create a home 277 binding if it is not the current home agent, then it SHOULD 278 retransmit the message, until a response is received. The initial 279 value for the retransmission timer is INITIAL-HA-SWITCH-TIMEOUT. 281 The retransmissions by the home agent MUST use an exponential back- 282 off mechanism, in which the timeout period is doubled upon each 283 retransmission, until either the home agent gets a response from the 284 mobile node to delete its binding, or the timeout period reaches the 285 value MAX-HA-SWITCH-TIMEOUT. 287 If the home agent included a Binding Refresh Advice mobility option, 288 then it SHOULD delay any retransmissions until at least one half of 289 the time period has expired, or INITIAL-HA-SWITCH-TIMEOUT, whichever 290 value is less. 292 4.3 Mobile Node Errors 294 If a mobile node does not understand how to process a Home Agent 295 Switch Message, it will send a Binding Error message as described in 296 Section 5.1. 298 If a mobile node is unreachable, in other words, it still has a home 299 binding with the home agent after reaching the timeout period of MAX- 300 HA-SWITCH-TIMEOUT, the home agent SHOULD NOT make any conclusions 301 about its status. 303 In either case, the home agent SHOULD attempt to continue providing 304 services until the lifetime of the binding expires. 306 Attempts by the mobile node to extend the binding lifetime with a 307 Binding Update message SHOULD be rejected, and a Binding 308 Acknowledgement SHOULD be returned with status value 129 309 (Administratively prohibited) as specified in Section 6.1.8 of [2]. 311 5. Mobile Node Operation 313 5.1 Receiving Home Agent Switch Messages 315 Upon receiving a Home Agent Switch message, the Mobility Header MUST 316 be verified as specified in [2], specifically: 318 o The Checksum, MH type, Payload Proto and Header Len fields 319 MUST meet the requirements of Section 9.2 of [2]. 321 o The packet MUST be authenticated, either by the home agent to 322 mobile node IPsec ESP authentication SA for integrity 323 protection, or a home agent to mobile node authentication 324 option. 326 If the packet is dropped due to the above tests, the receiving node 327 MUST follow the processing rules as Section 9.2 of [2] defines. For 328 example, it MUST send a Binding Error message with the Status field 329 set to 2 (unrecognized MH Type value) if it does not support the 330 message type. 332 Upon receipt of a Home Agent Switch message, the mobile node MUST 333 stop using its current home agent for services and MUST delete its 334 home binding by sending a Binding Update message as described in [2]. 335 This acts as an acknowledgement of the Home Agent Switch message. 336 Alternately, if the sender of the message is not the current home 337 agent, sending a Binding Update message to create a home binding will 338 act as an acknowledgement of the Home Agent Switch message. 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 5.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 5.2 Selecting a Home Agent 354 In most cases, the home agent addresses in the Home Agent Switch 355 message will be of other home agents on the home link of the mobile 356 node. In this case, the mobile node SHOULD select a new home agent 357 from the addresses as they are ordered in the list. If the first 358 address in the list is unable to provide service, then the subsequent 359 addresses in the list should be tried in-order. 361 In the case that the home agent addresses in the Home Agent Switch 362 message are not all home agents on the home link of the mobile node 363 (the computed prefix is different), the mobile node SHOULD select one 364 on the home link first, if available, followed by home agents not on 365 the home link. Choosing a home agent not on the home link might 366 require a change of the home address for the mobile node, which could 367 cause a loss of connectivity for any connections using the current 368 home address. 370 6. Operational Considerations 372 This document does not specify how an operator might use the Home 373 Agent Switch message in its network. However, it might be the case 374 that a home agent provides service for many thousands of mobile 375 nodes. Care should be taken to reduce the signaling overhead 376 required for handing off many mobile nodes to an alternate home 377 agent. 379 7. Procotol Constants 381 INITIAL-HA-SWITCH-TIMEOUT 5 seconds 382 MAX-HA-SWITCH-TIMEOUT 20 seconds 384 8. IANA Considerations 386 A new Mobility Header type is required for the following new message 387 described in Section 3: 389 (TBD) Home Agent Switch message 391 9. Security Considerations 393 The Home Agent Switch message MUST be authenticated by one of the 394 following methods: 396 o The home agent to mobile node IPsec ESP authentication SA for 397 integrity protection as described in [2]. 399 o A home agent to mobile node authentication option, such as 400 [3]. 402 The Home Agent Switch message MAY use the IPsec ESP SA in place for 403 Binding Updates and Acknowledgements as specified in Section 5.1 of 404 [2], in order to reduce the number of configured security 405 associations. This also gives the message authenticity protection. 407 Some operators may not want to reveal the list of home agents to on- 408 path listeners. In such a case, the Home Agent Switch message should 409 use the home agent to mobile node IPsec ESP encryption SA for 410 confidentiality protection. 412 10. References 414 10.1 Normative References 416 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 417 Levels", BCP 14, RFC 2119, March 1997 419 [2] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in 420 IPv6", RFC 3775, June, 2004. 422 10.2 Informative references 424 [3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and Chowdhury, K., 425 "Authentication Protocol for Mobile IPv6", RFC 4285, January, 426 2006. 428 [4] Wakikawa, R. (Editor), "Home Agent Reliability Protocol", draft- 429 ietf-mip6-hareliability-01.txt, October, 2006. 431 Acknowledgments 433 We would like to thank the authors of a number of previous drafts 434 that contributed content to this document: 436 o draft-wakikawa-mip6-nemo-haha-spec-00.txt 437 o draft-deng-mip6-ha-loadbalance-02.txt 438 o draft-kempf-mip6-ha-alert-00.txt 439 o draft-haley-mip6-mh-signaling-00.txt 441 Thanks also to Kilian Weniger, Jixing Liu, Alexandru Petrescu, Jouni 442 Korhonen, and Wolfgang Fritsche for their review and feedback. 444 Author's Addresses 446 Brian Haley 447 Hewlett-Packard Company 448 110 Spitbrook Road 449 Nashua, NH 03062, USA 450 Email: brian.haley@hp.com 452 Vijay Devarapalli 453 Azaire Networks 454 3121 Jay Street 455 Santa Clara, CA 95054 USA 456 Email: vijay.devarapalli@azairenet.com 458 James Kempf 459 DoCoMo USA Labs 460 181 Metro Drive 461 Suite 300 462 San Jose, CA 95110 USA 463 Email: kempf@docomolabs-usa.com 465 Hui Deng 466 Research & Development Center 467 Hitachi (China), Investment Ltd. 468 Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu 469 Chao Yang District, Beijing 100004, China 470 Email: hdeng@hitachi.cn 472 Full Copyright Statement 474 Copyright (C) The IETF Trust (2007). 476 This document is subject to the rights, licenses and restrictions 477 contained in BCP 78, and except as set forth therein, the authors 478 retain all their rights. 480 This document and the information contained herein are provided on an 481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 483 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 484 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 485 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 488 Intellectual Property 490 The IETF takes no position regarding the validity or scope of any 491 Intellectual Property Rights or other rights that might be claimed to 492 pertain to the implementation or use of the technology described in 493 this document or the extent to which any license under such rights 494 might or might not be available; nor does it represent that it has 495 made any independent effort to identify any such rights. Information 496 on the procedures with respect to rights in RFC documents can be 497 found in BCP 78 and BCP 79. 499 Copies of IPR disclosures made to the IETF Secretariat and any 500 assurances of licenses to be made available, or the result of an 501 attempt made to obtain a general license or permission for the use of 502 such proprietary rights by implementers or users of this 503 specification can be obtained from the IETF on-line IPR repository at 504 http://www.ietf.org/ipr. 506 The IETF invites any interested party to bring to its attention any 507 copyrights, patents or patent applications, or other proprietary 508 rights that may cover technology that may be required to implement 509 this standard. Please address the information to the IETF at 510 ietf-ipr@ietf.org. 512 Acknowledgement 514 Funding for the RFC Editor function is provided by the IETF 515 Administrative Support Activity (IASA).