idnits 2.17.1 draft-ietf-mip6-ha-switch-06.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 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 552. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (December 4, 2007) is 5960 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 (~~), 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-06.txt V. Devarapalli 5 Intended status: Standards Track Azaire Networks 6 Expires: June 4, 2008 H. Deng 7 China Mobile 8 J. Kempf 9 DoCoMo USA Labs 10 December 4, 2007 12 Mobility Header Home Agent Switch Message 13 draft-ietf-mip6-ha-switch-06.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............................................10 64 9. IANA Considerations...........................................10 65 10. Security Considerations......................................10 66 11. References...................................................10 67 11.1 Normative References.....................................10 68 11.2 Informative references...................................10 69 Acknowledgments..................................................11 70 Author's Addresses...............................................11 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, the following 389 requirements are placed on the usage: 391 o The use of this message needs to take into account possible 392 signaling overhead, congestion, load from the mechanism 393 itself, and the resulting registration to another home agent. 394 A home agent may provide service for thousands, if not 395 millions, of mobile nodes. Careless application of the Home 396 Agent Switch message may cause the new home agent, or some 397 other parts of the network, to suffer. As a result, it is 398 REQUIRED that applications of this message either employ a 399 feedback loop between resources of the new home agent and the 400 sending of additional Home Agent Switch messages, or apply a 401 maximum rate at which mobile nodes can be informed of the 402 switch that is far below the designated capacity of new 403 registrations that the set of home agents can process. If no 404 other information is available, this maximum rate should 405 default to MAX-HA-SWITCH-TRANSMIT-RATE. 407 o In general, switching the home agent of a mobile node should 408 only be done when absolutely necessary, since it might cause 409 a service disruption if the switch to a new home agent fails, 410 the new home agent is itself under an overload condition, or 411 the network connection of the new home agent is congested. 412 Similarly, the path characteristics via the new home agent 413 may be different, which may cause temporary difficulties for 414 end to end transport layer operation. 416 o If this message is being used for load-balancing between a set 417 of home agents, they should all be configured with the same 418 set of prefixes so a home agent switch does not require a 419 change of the home address for a mobile node. That operation 420 is NOT RECOMMENDED and should be avoided. 422 8. Procotol Constants 424 INITIAL-HA-SWITCH-TIMEOUT 5 seconds 425 MAX-HA-SWITCH-TIMEOUT 20 seconds 426 MAX-HA-SWITCH-TRANSMIT-RATE 1 per second 428 9. IANA Considerations 430 A new Mobility Header type is required for the following new message 431 described in Section 4: 433 (TBD) Home Agent Switch message 435 10. Security Considerations 437 As with other messages in [RFC3775], the Home Agent Switch message 438 MUST use the home agent to mobile node ESP encryption SA for 439 confidentiality protection, and MUST use the home agent to mobile 440 node ESP authentication SA for integrity protection. 442 The Home Agent Switch message MAY use the IPsec ESP SA in place for 443 Binding Updates and Acknowledgements as specified in Section 5.1 of 444 [RFC3775], in order to reduce the number of configured security 445 associations. This also gives the message authenticity protection. 447 Some operators may not want to reveal the list of home agents to on- 448 path listeners. In such a case, the Home Agent Switch message should 449 use the home agent to mobile node IPsec ESP encryption SA for 450 confidentiality protection. 452 11. References 454 11.1 Normative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC3775] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support 460 in IPv6", RFC 3775, June, 2004. 462 11.2 Informative References 464 [RFC4192] Baker, F., Lear, E., and Droms, R., "Procedures for 465 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 466 September, 2005. 468 [draft-mip6-hareliability] Wakikawa, R. (Editor), "Home Agent 469 Reliability Protocol", draft-ietf-mip6-hareliability-02.txt, July, 470 2007. 472 Acknowledgments 474 We would like to thank the authors of a number of previous drafts 475 that contributed content to this document: 477 o draft-wakikawa-mip6-nemo-haha-spec-00.txt 478 o draft-deng-mip6-ha-loadbalance-02.txt 479 o draft-kempf-mip6-ha-alert-00.txt 480 o draft-haley-mip6-mh-signaling-00.txt 482 Thanks also to Kilian Weniger, Jixing Liu, Alexandru Petrescu, Jouni 483 Korhonen, and Wolfgang Fritsche for their review and feedback. 485 Author's Addresses 487 Brian Haley 488 Hewlett-Packard Company 489 110 Spitbrook Road 490 Nashua, NH 03062, USA 491 Email: brian.haley@hp.com 493 Vijay Devarapalli 494 Azaire Networks 495 3121 Jay Street 496 Santa Clara, CA 95054 USA 497 Email: vijay.devarapalli@azairenet.com 499 James Kempf 500 DoCoMo USA Labs 501 181 Metro Drive 502 Suite 300 503 San Jose, CA 95110 USA 504 Email: kempf@docomolabs-usa.com 506 Hui Deng 507 China Mobile 508 53A, Xibianmennei Ave. 509 Xuanwu District 510 Beijing 100053 511 China 512 Email: denghui@chinamobile.com 514 Full Copyright Statement 516 Copyright (C) The IETF Trust (2007). 518 This document is subject to the rights, licenses and restrictions 519 contained in BCP 78, and except as set forth therein, the authors 520 retain all their rights. 522 This document and the information contained herein are provided on an 523 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 524 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 525 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 526 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 527 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 528 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Intellectual Property 532 The IETF takes no position regarding the validity or scope of any 533 Intellectual Property Rights or other rights that might be claimed to 534 pertain to the implementation or use of the technology described in 535 this document or the extent to which any license under such rights 536 might or might not be available; nor does it represent that it has 537 made any independent effort to identify any such rights. Information 538 on the procedures with respect to rights in RFC documents can be 539 found in BCP 78 and BCP 79. 541 Copies of IPR disclosures made to the IETF Secretariat and any 542 assurances of licenses to be made available, or the result of an 543 attempt made to obtain a general license or permission for the use of 544 such proprietary rights by implementers or users of this 545 specification can be obtained from the IETF on-line IPR repository at 546 http://www.ietf.org/ipr. 548 The IETF invites any interested party to bring to its attention any 549 copyrights, patents or patent applications, or other proprietary 550 rights that may cover technology that may be required to implement 551 this standard. Please address the information to the IETF at 552 ietf-ipr@ietf.org. 554 Acknowledgement 556 Funding for the RFC Editor function is provided by the IETF 557 Administrative Support Activity (IASA).