idnits 2.17.1 draft-haley-mip6-ha-switch-01.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 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6589 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) Summary: 4 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-haley-mip6-ha-switch-01.txt V. Devarapalli 5 Expires: September, 2006 Nokia 6 H. Deng 7 Hitachi 8 J. Kempf 9 DoCoMo USA Labs 10 March 2006 12 Mobility Header Home Agent Switch Message 13 draft-haley-mip6-ha-switch-01.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 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [1]. 50 Table of Contents 52 1. Introduction...................................................2 53 2. Scenarios......................................................2 54 2.1 Overloaded.................................................3 55 2.2 Load Balancing.............................................3 56 2.3 Maintenance................................................3 57 2.4 Functional Load Balancing..................................3 58 2.5 Home Agent Renumbering.....................................3 59 3. Home Agent Switch Message......................................4 60 4. Home Agent Operation...........................................6 61 4.1 Sending Home Agent Switch Messages.........................6 62 4.2 Retransmissions............................................6 63 4.3 Mobile Node Errors.........................................7 64 5. Mobile Node Operation..........................................7 65 5.1 Receiving Home Agent Switch Messages.......................7 66 6. Operational Considerations.....................................8 67 7. Procotol Constants.............................................8 68 8. IANA Considerations............................................8 69 9. Security Considerations........................................8 70 10. References....................................................9 71 10.1 Normative References......................................9 72 10.2 Informative references....................................9 73 Acknowledgments...................................................9 74 Author's Addresses................................................9 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 88 Here are some example scenarios where a home agent signaling message 89 would be useful. 91 2.1 Overloaded 93 There are a number of reasons a home agent might be considered 94 overloaded. One might be that it is at, or near, its limit on the 95 number of home bindings it is willing to accept. Another is that it 96 has reached a pre-determined level of system resource usage - memory, 97 cpu cycles, etc. In either case, it would be desirable for a home 98 agent to reduce the number of home bindings before a failure occurs. 100 2.2 Load Balancing 102 A home agent might know of other home agents on the link that are not 103 as heavily loaded as itself, learned through some other mechanism 104 outside the scope of this document. An operator may wish to try and 105 balance this load so a failure disrupts a smaller percentage of 106 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 136 Periodically, a mobility service provider may want to shut-down home 137 agent services at a set of IPv6 addresses and bring service back up 138 at a new set of addresses. Note that this may not involve anything 139 as complex as IPv6 network renumbering, it may just involve changing 140 the addresses of the home agents. There are various reasons why a 141 mobility service provider might want to do this; an example is if the 142 service provider revokes the account of a user it has reason to 143 believe might use the old home agent address to disrupt service for 144 other users. With a signaling message, the service provider could 145 inform mobile nodes to look for a new home agent. 147 3. 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 4. 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 A 16-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 16-bit field reserved for future use. The value MUST be 204 initialized to zero by the sender, and MUST be ignored by the 205 receiver. 207 Home Agent Addresses 209 A list of alternate home agent addresses on the home link for the 210 mobile node. The number of addresses present in the list is 211 indicated by the "# of Addresses" field in the Home Agent Switch 212 message. 214 Mobility options 215 Variable-length field of such length that the complete Mobility 216 Header is an integer multiple of 8 octets long. This field 217 contains zero of more TLV-encoded mobility options. The encoding 218 and format of defined options MUST follow the format specified in 219 Section 6.2 of [2]. The receiver MUST ignore and skip any options 220 with it does not understand. 222 This specification does not define any options valid for the Home 223 Agent Switch message. 225 If no home agent addresses and no options are present in this 226 message, no padding is necessary and the Header Len field in the 227 Mobility Header will be set to 0. 229 4. Home Agent Operation 231 4.1 Sending Home Agent Switch Messages 233 When sending a Home Agent Switch message, the sending node constructs 234 the packet as it would any other Mobility Header, except: 236 o The MH Type field MUST be set to (TBD). 238 o If alternative home agent addresses are known, the sending home 239 agent SHOULD include them in the list of suggested alternate 240 home agents. The home agent addresses field should be 241 constructed as described in Section 10.5.1 of [2]. 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 The Home Agent Switch message MUST use the home agent to mobile node 250 IPsec ESP authentication SA for integrity protection. 252 A home agent SHOULD send a Home Agent Switch message when a known 253 period of unavailability is pending so the mobile node has sufficient 254 time to find another suitable home agent. 256 4.2 Retransmissions 258 If the home agent does not receive a response from the mobile node (a 259 Binding Update message to delete its home binding), then it SHOULD 260 retransmit the message, until a response is received. The initial 261 value for the retransmission timer is INITIAL-HA-SWITCH-TIMEOUT. 263 The retransmissions by the home agent MUST use an exponential back- 264 off mechanism, in which the timeout period is doubled upon each 265 retransmission, until either the home agent gets a response from the 266 mobile node to delete its binding, or the timeout period reaches the 267 value MAX-HA-SWITCH-TIMEOUT. 269 4.3 Mobile Node Errors 271 If a mobile node does not understand how to process a Home Agent 272 Switch Message, it will send a Binding Error message as described in 273 Section 5.1. 275 If a mobile node is unreachable, in other words, it still has a home 276 binding with the home agent after reaching the timeout period of MAX- 277 HA-SWITCH-TIMEOUT, the home agent SHOULD NOT make any conclusions 278 about its status. 280 In either case, the home agent SHOULD attempt to continue providing 281 services until the lifetime of the binding expires. 283 Attempts by the mobile node to extend the binding lifetime with a 284 Binding Update message SHOULD be rejected, and a Binding 285 Acknowledgement SHOULD be returned with status value 129 286 (Administratively prohibited) as specified in Section 6.1.8 of [2]. 288 5. Mobile Node Operation 290 5.1 Receiving Home Agent Switch Messages 292 Upon receiving a Home Agent Switch message, the Mobility Header MUST 293 be verified as specified in [2], specifically: 295 o The Checksum, MH type, Payload Proto and Header Len fields 296 MUST meet the requirements of Section 9.2 of [2]. 298 o The packet MUST be covered by the home agent to mobile node 299 IPsec ESP authentication SA for integrity protection. 301 If the packet is dropped due to the above tests, the receiving node 302 MUST follow the processing rules as Section 9.2 of [2] defines. For 303 example, it MUST send a Binding Error message with the Status field 304 set to 2 (unrecognized MH Type value) if it does not support the 305 message type. 307 Upon receipt of a Home Agent Switch message, the mobile node MUST 308 stop using its current home agent for services and MUST delete its 309 home binding by sending a Binding Update message as described in [2]. 310 This acts as an acknowledgement of the Home Agent Switch message. 312 If the Home Agent Switch message contains a list of alternate home 313 agent addresses, the mobile node SHOULD select a home agent at random 314 and establish the necessary IPsec security associations with the new 315 home agent by whatever means required as part of the mobile node/home 316 agent bootstrapping protocol for the home agent's mobility service 317 provider. If no alternate home agent addresses are included in the 318 list, the mobile node MUST first perform home agent discovery. 320 6. Operational Considerations 322 This document does not specify how an operator might use the Home 323 Agent Switch message in its network. However, it might be the case 324 that a home agent provides service for many thousands of mobile 325 nodes. Care should be taken to reduce the signaling overhead 326 required for handing off many mobile nodes to an alternate home 327 agent. 329 7. Procotol Constants 331 INITIAL-HA-SWITCH-TIMEOUT 5 seconds 332 MAX-HA-SWITCH-TIMEOUT 20 seconds 334 8. IANA Considerations 336 A new Mobility Header type is required for the following new message 337 described in Section 3: 339 (TBD) Home Agent Switch message 341 9. Security Considerations 343 As with other messages in [2], the Home Agent Switch message MUST use 344 the home agent to mobile node IPsec ESP authentication SA for 345 integrity protection. 347 The Home Agent Switch message MAY use the IPsec ESP SA in place for 348 Binding Updates and Acknowledgements as specified in Section 5.1 of 349 [2], in order to reduce the number of configured security 350 associations. This also gives the message authenticity protection. 352 Some operators may not want to reveal the list of home agents on the 353 home link to on-path listeners. In such a case, the Home Agent 354 Switch message should use the home agent to mobile node IPsec ESP 355 encryption SA for confidentiality protection. 357 10. References 359 10.1 Normative References 361 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 362 Levels", BCP 14, RFC 2119, March 1997 364 [2] Johnson, D. Perkins, C., and Arkko, J., "Mobility Support in 365 IPv6", RFC 3775, June, 2004. 367 10.2 Informative references 369 Acknowledgments 371 We would like to thank the authors of a number of previous drafts 372 that contributed content to this document: 374 o draft-wakikawa-mip6-nemo-haha-spec-00.txt 375 o draft-deng-mip6-ha-loadbalance-02.txt 376 o draft-kempf-mip6-ha-alert-00.txt 377 o draft-haley-mip6-mh-signaling-00.txt 379 Author's Addresses 381 Brian Haley 382 Hewlett-Packard Company 383 110 Spitbrook Road 384 Nashua, NH 03062, USA 385 Email: brian.haley@hp.com 387 Vijay Devarapalli 388 Nokia Research Center 389 313 Fairchild Drive 390 Mountain View, CA 94043 USA 391 Email: vijay.devarapalli@nokia.com 393 James Kempf 394 DoCoMo USA Labs 395 181 Metro Drive 396 Suite 300 397 San Jose, CA 95110 USA 398 Email: kempf@docomolabs-usa.com 399 Hui Deng 400 Research & Development Center 401 Hitachi (China), Investment Ltd. 402 Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu 403 Chao Yang District, Beijing 100004, China 404 Email: hdeng@hitachi.cn 406 Intellectual Property Statement 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed to 410 pertain to the implementation or use of the technology described in 411 this document or the extent to which any license under such rights 412 might or might not be available; nor does it represent that it has 413 made any independent effort to identify any such rights. Information 414 on the procedures with respect to rights in RFC documents can be 415 found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use of 420 such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository at 422 http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights that may cover technology that may be required to implement 427 this standard. Please address the information to the IETF at 428 ietf-ipr@ietf.org. 430 Disclaimer of Validity 432 This document and the information contained herein are provided on an 433 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 434 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 435 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 436 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 437 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 438 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 440 Copyright Statement 442 Copyright (C) The Internet Society (2006). This document is subject 443 to the rights, licenses and restrictions contained in BCP 78, and 444 except as set forth therein, the authors retain all their rights. 446 Acknowledgment 448 Funding for the RFC Editor function is currently provided by the 449 Internet Society.