idnits 2.17.1 draft-ietf-mip6-ha-switch-05.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 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. 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 (November 16, 2007) is 5999 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 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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-05.txt V. Devarapalli 5 Intended status: Standards Track Azaire Networks 6 Expires: May 16, 2008 H. Deng 7 China Mobile 8 J. Kempf 9 DoCoMo USA Labs 10 November 16, 2007 12 Mobility Header Home Agent Switch Message 13 draft-ietf-mip6-ha-switch-05.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....................................................3 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 [RFC3775] contains no provision to allow a home agent to 75 inform a mobile node that it needs to stop acting as the home agent 76 for the mobile node. For example, a home agent may wish to handoff 77 some of 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, called the Home Agent 81 Switch message, that can be used to send a handoff notification 82 between a home agent and mobile node. 84 The Home Agent Switch message does not attempt to solve all general 85 problems related to changing the home agent of a mobile node. In 86 particular, this protocol does not attempt to solve: 88 o The case where the Home Address of a mobile node must change in 89 order to switch to a new home agent. This operation should be 90 avoided using this message. 92 o Determining when a home agent should actively move mobile nodes 93 to another home agent. This decision should be made by a 94 backend protocol, for example, as described in [draft-mip6- 95 hareliability]. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC-2119 [RFC2119]. 103 3. Scenarios 105 Here are some example scenarios where a home agent signaling message 106 would be useful. 108 3.1 Overloaded 110 There are a number of reasons a home agent might be considered 111 overloaded. One might be that it is at, or near, its limit on the 112 number of home bindings it is willing to accept. Another is that it 113 has reached a pre-determined level of system resource usage - memory, 114 cpu cycles, etc. In either case, it would be desirable for a home 115 agent to reduce the number of home bindings before a failure occurs. 117 3.2 Load Balancing 119 A home agent might know of other home agents that are not as heavily 120 loaded as itself, learned through some other mechanism outside the 121 scope of this document. An operator may wish to try and balance this 122 load so a failure disrupts a smaller percentage of mobile nodes. 124 3.3 Maintenance 126 Most operators do periodic maintenance in order to maintain 127 reliability. If a home agent is being shutdown for maintenance, it 128 would be desirable to inform mobile nodes so they do not lose 129 mobility service. 131 3.4 Functional Load Balancing 133 A Mobile IPv6 home agent provides mobile nodes with two basic 134 services - a rendezvous server where correspondent nodes can find the 135 current care-of address for the mobile node, and as an overlay router 136 to tunnel traffic to/from the mobile node at its current care-of 137 address. 139 A mobility service provider could have two sets of home agents to 140 handle the two functions. The rendezvous function could be handled 141 by a machine specialized for high-speed transaction processing, while 142 the overlay router function could be handled by a machine with high 143 data throughput. 145 A mobile node would start on the rendezvous server home agent and 146 stay there if it does route optimization. However, if the original 147 home agent detects that the mobile node is not doing route 148 optimization, but instead reverse-tunneling traffic, it could 149 redirect the mobile node to a home agent with better data throughput. 151 3.5 Home Agent Renumbering 153 Periodically, a mobility service provider may want to shut-down home 154 agent services at a set of IPv6 addresses and bring service back up 155 at a new set of addresses. Note that this may not involve anything 156 as complex as IPv6 network renumbering [RFC4192], it may just involve 157 changing the addresses of the home agents. With a signaling message, 158 the service provider could inform mobile nodes to look for a new home 159 agent. 161 4. Home Agent Switch Message 163 The Home Agent Switch message is used by the home agent to signal the 164 mobile node that it needs to stop acting as the home agent for the 165 mobile node, and that it should acquire a new home agent. Home Agent 166 Switch messages are sent as described in Section 5. 168 The message described below follows the Mobility Header format 169 specified in Section 6.1 of [RFC3775]: 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Payload Proto | Header Len | MH Type | Reserved | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Checksum | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 176 | | 177 . . 178 . Message Data . 179 . . 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 The Home Agent Switch Message uses the MH Type value (TBD). When 184 this value is indicated in the MH Type field, the format of the 185 Message Data field in the Mobility Header is as follows: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |# of Addresses | Reserved | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 + + 194 . . 195 . Home Agent Addresses . 196 . . 197 + + 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 + + 202 . . 203 . Mobility options . 204 . . 205 + + 206 | | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 # of Addresses 211 An 8-bit unsigned integer indicating the number of IPv6 home agent 212 addresses in the message. If set to zero, the mobile node MUST 213 perform home agent discovery. 215 Reserved 217 8-bit field reserved for future use. The value MUST be initialized 218 to zero by the sender, and MUST be ignored by the receiver. 220 Home Agent Addresses 222 A list of alternate home agent addresses for the mobile node. The 223 number of addresses present in the list is indicated by the "# of 224 Addresses" field in the Home Agent Switch message. 226 Mobility options 228 Variable-length field of such length that the complete Mobility 229 Header is an integer multiple of 8 octets long. This field 230 contains zero or more TLV-encoded mobility options. The encoding 231 and format of defined options MUST follow the format specified in 232 Section 6.2 of [RFC3775]. The receiver MUST ignore and skip any 233 options which it does not understand. 235 The Binding Refresh Advice mobility option defined in Section 6.2.4 236 of [RFC3775] is valid for the Home Agent Switch message. 238 If no home agent addresses and no options are present in this 239 message, no padding is necessary and the Header Len field in the 240 Mobility Header will be set to 0. 242 5. Home Agent Operation 244 5.1 Sending Home Agent Switch Messages 246 When sending a Home Agent Switch message, the sending node constructs 247 the packet as it would any other Mobility Header, except: 249 o The MH Type field MUST be set to (TBD). 251 o If alternative home agent addresses are known, the sending home 252 agent SHOULD include them in the list of suggested alternate 253 home agents. The home agent addresses field should be 254 constructed as described in Section 10.5.1 of [RFC3775], which 255 will randomize addresses of the same preference in the list. 257 o The "# of addresses" field MUST be filled-in corresponding to 258 the number of home agent addresses included in the message. If 259 no addresses are present, the field MUST be set to zero, forcing 260 the mobile node to perform home agent discovery by some other 261 means. 263 o If the home agent is able to continue offering services to the 264 mobile node for some period of time, it MAY include a Binding 265 Refresh Advice mobility option indicating the time (in units of 266 4 seconds) until the binding will be deleted. 268 The Home Agent Switch message MUST use the home agent to mobile node 269 IPsec ESP authentication SA for integrity protection. 271 A home agent SHOULD send a Home Agent Switch message when a known 272 period of unavailability is pending so the mobile node has sufficient 273 time to find another suitable home agent. 275 The sending node does not need to be the current home agent for the 276 mobile node, for example as described in [draft-mip6-hareliability], 277 but it MUST have a security association with the mobile node so the 278 message is not rejected. In this case, the Home Agent Switch message 279 SHOULD only contain the address of the home agent sending the message 280 in the Home Agent Addresses field, which implies the mobile node 281 should switch to using the sender as its new home agent. 283 5.2 Retransmissions 285 If the home agent does not receive a response from the mobile node - 286 either a Binding Update message to delete its home binding if it is 287 the current home agent, or a Binding Update message to create a home 288 binding if it is not the current home agent, then it SHOULD 289 retransmit the message, until a response is received. The initial 290 value for the retransmission timer is INITIAL-HA-SWITCH-TIMEOUT. 292 The retransmissions by the home agent MUST use an exponential back- 293 off mechanism, in which the timeout period is doubled upon each 294 retransmission, until either the home agent gets a response from the 295 mobile node to delete its binding, or the timeout period reaches the 296 value MAX-HA-SWITCH-TIMEOUT. The home agent MAY continue to send 297 these messages at this slower rate indefinitely. 299 If the home agent included a Binding Refresh Advice mobility option, 300 then it SHOULD delay any retransmissions until at least one half of 301 the time period has expired, or INITIAL-HA-SWITCH-TIMEOUT, whichever 302 value is less. 304 5.3 Mobile Node Errors 306 If a mobile node does not understand how to process a Home Agent 307 Switch Message, it will send a Binding Error message as described in 308 Section 6.1. 310 If a mobile node is unreachable, in other words, it still has a home 311 binding with the home agent after reaching the timeout period of MAX- 312 HA-SWITCH-TIMEOUT, the home agent SHOULD NOT make any conclusions 313 about its status. 315 In either case, the home agent SHOULD attempt to continue providing 316 services until the lifetime of the binding expires. 318 Attempts by the mobile node to extend the binding lifetime with a 319 Binding Update message SHOULD be rejected, and a Binding 320 Acknowledgement SHOULD be returned with status value 129 321 (Administratively prohibited) as specified in Section 6.1.8 of 322 [RFC3775]. 324 6. Mobile Node Operation 326 6.1 Receiving Home Agent Switch Messages 328 Upon receiving a Home Agent Switch message, the Mobility Header MUST 329 be verified as specified in [RFC3775], specifically: 331 o The Checksum, MH type, Payload Proto and Header Len fields 332 MUST meet the requirements of Section 9.2 of [RFC3775]. 334 o The packet MUST be covered by the home agent to mobile node 335 IPsec ESP authentication SA for integrity protection. 337 If the packet is dropped due to the above tests, the receiving node 338 MUST follow the processing rules as Section 9.2 of [RFC3775] defines. 339 For example, it MUST send a Binding Error message with the Status 340 field set to 2 (unrecognized MH Type value) if it does not support 341 the message type. 343 Upon receipt of a Home Agent Switch message, the mobile node MUST 344 stop using its current home agent for services and MUST delete its 345 home binding by sending a Binding Update message as described in 346 Section 11.7.1 of [RFC3775]. This acts as an acknowledgement of the 347 Home Agent Switch message. Alternately, if the sender of the message 348 is not the current home agent, sending a Binding Update message to 349 create a home binding will act as an acknowledgement of the Home 350 Agent Switch message. Retransmissions of Binding Update messages 351 MUST use the procedures described in Section 11.8 of [RFC3775]. 353 If a Binding Refresh Advice mobility option is present, the mobile 354 node MAY delay the deletion of its home binding and continue to use 355 its current home agent until the calculated time period has expired. 357 If the Home Agent Switch message contains a list of alternate home 358 agent addresses, the mobile node SHOULD select a new home agent as 359 described in Section 6.2, and establish the necessary IPsec security 360 associations with the new home agent by whatever means required as 361 part of the mobile node/home agent bootstrapping protocol for the 362 home agent's mobility service provider. If no alternate home agent 363 addresses are included in the list, the mobile node MUST first 364 perform home agent discovery. 366 6.2 Selecting a Home Agent 368 In most cases, the home agent addresses in the Home Agent Switch 369 message will be of other home agents on the home link of the mobile 370 node (the computed prefix is the same). In this case, the mobile 371 node SHOULD select a new home agent from the addresses as they are 372 ordered in the list. If the first address in the list is unable to 373 provide service, then the subsequent addresses in the list should be 374 tried in-order. 376 In the case that the home agent addresses in the Home Agent Switch 377 message are not all home agents on the home link of the mobile node 378 (the computed prefix is different), the mobile node SHOULD select one 379 its home network prefix first, if available, followed by home agents 380 with other prefixes. Choosing a home agent with a different prefix 381 might require a change of the home address for the mobile node, which 382 could cause a loss of connectivity for any connections using the 383 current home address. 385 7. Operational Considerations 387 This document does not specify how an operator might use the Home 388 Agent Switch message in its network. However, it might be the case 389 that a home agent provides service for many thousands of mobile 390 nodes. Care should be taken to reduce the signaling overhead on the 391 network required for handing off many mobile nodes to an alternate 392 home agent. 394 In general, switching the home agent of a mobile node should only be 395 done when absolutely necessary, since it might cause a service 396 disruption if switch to a new home agent fails, and the mobile node 397 has to perform home agent discovery. 399 If this message is being used for load-balancing between a set of 400 home agents, they should all be configured with the same set of 401 prefixes so a home agent switch does not require a change of the home 402 address for a mobile node. That operation is not recommended and 403 should be avoided. 405 8. Procotol Constants 407 INITIAL-HA-SWITCH-TIMEOUT 5 seconds 408 MAX-HA-SWITCH-TIMEOUT 20 seconds 410 9. IANA Considerations 412 A new Mobility Header type is required for the following new message 413 described in Section 4: 415 (TBD) Home Agent Switch message 417 10. Security Considerations 419 As with other messages in [RFC3775], the Home Agent Switch message 420 MUST use the home agent to mobile node ESP encryption SA for 421 confidentiality protection, and MUST use the home agent to mobile 422 node ESP authentication SA for integrity protection. 424 The Home Agent Switch message MAY use the IPsec ESP SA in place for 425 Binding Updates and Acknowledgements as specified in Section 5.1 of 426 [RFC3775], in order to reduce the number of configured security 427 associations. This also gives the message authenticity protection. 429 Some operators may not want to reveal the list of home agents to on- 430 path listeners. In such a case, the Home Agent Switch message should 431 use the home agent to mobile node IPsec ESP encryption SA for 432 confidentiality protection. 434 11. References 436 11.1 Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC3775] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support 442 in IPv6", RFC 3775, June, 2004. 444 11.2 Informative References 446 [RFC4192] Baker, F., Lear, E., and Droms, R., "Procedures for 447 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 448 September, 2005. 450 [draft-mip6-hareliability] Wakikawa, R. (Editor), "Home Agent 451 Reliability Protocol", draft-ietf-mip6-hareliability-02.txt, July, 452 2007. 454 Acknowledgments 456 We would like to thank the authors of a number of previous drafts 457 that contributed content to this document: 459 o draft-wakikawa-mip6-nemo-haha-spec-00.txt 460 o draft-deng-mip6-ha-loadbalance-02.txt 461 o draft-kempf-mip6-ha-alert-00.txt 462 o draft-haley-mip6-mh-signaling-00.txt 464 Thanks also to Kilian Weniger, Jixing Liu, Alexandru Petrescu, Jouni 465 Korhonen, and Wolfgang Fritsche for their review and feedback. 467 Author's Addresses 468 Brian Haley 469 Hewlett-Packard Company 470 110 Spitbrook Road 471 Nashua, NH 03062, USA 472 Email: brian.haley@hp.com 474 Vijay Devarapalli 475 Azaire Networks 476 3121 Jay Street 477 Santa Clara, CA 95054 USA 478 Email: vijay.devarapalli@azairenet.com 480 James Kempf 481 DoCoMo USA Labs 482 181 Metro Drive 483 Suite 300 484 San Jose, CA 95110 USA 485 Email: kempf@docomolabs-usa.com 487 Hui Deng 488 China Mobile 489 53A, Xibianmennei Ave. 490 Xuanwu District 491 Beijing 100053 492 China 493 Email: denghui@chinamobile.com 495 Full Copyright Statement 497 Copyright (C) The IETF Trust (2007). 499 This document is subject to the rights, licenses and restrictions 500 contained in BCP 78, and except as set forth therein, the authors 501 retain all their rights. 503 This document and the information contained herein are provided on an 504 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 505 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 506 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 507 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 508 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 509 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 511 Intellectual Property 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Acknowledgement 537 Funding for the RFC Editor function is provided by the IETF 538 Administrative Support Activity (IASA).