idnits 2.17.00 (12 Aug 2021) /tmp/idnits30006/draft-jfaizan-mipv6-ha-reliability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 401, but no explicit reference was found in the text == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 ** Obsolete normative reference: RFC 2409 (ref. '2') (Obsoleted by RFC 4306) == Outdated reference: draft-ietf-mobileip-mipv6-ha-ipsec has been published as RFC 3776 ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) -- Duplicate reference: RFC2119, mentioned in '6', was also mentioned in '4'. Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Jahanzeb Faizan 3 Internet-Draft Hesham El-Rewini 4 Expires: August, 2004 Southern Methodist University 5 Mohammad Khalil 6 Nortel Networks 7 February, 2004 9 Problem Statement: Home Agent Reliability 10 draft-jfaizan-mipv6-ha-reliability-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 In Mobile IPv6, the Mobile Node is dependent on a single Home Agent 41 for the seamless roaming over the Internet. Mobile IPv6 also allows 42 deployment of multiple Home Agents on the home link for providing 43 continuous service to Mobile Node in case of Home Agent failure. But 44 switching of service from the failed Home Agent to another functional 45 Home Agent on the home link is problematic and the base Mobile IPv6 46 specifications does not currently have well-described solutions. This 47 document aims to describe and illustrate these problems, and propose 48 some guidelines for possible solutions. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3 54 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Mobile IPv6 Deployment Scenario . . . . . . . . . . . . . . . .5 58 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . .5 59 3.1 Failure . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1 Home Agent Failure . . . . . . . . . . . . . . . . 6 61 3.1.2 Home Link Failure . . . . . . . . . . . . . . . . .6 62 3.2 Failure Detection . . . . . . . . . . . . . . . . . . . . 6 63 3.3 Recovery . . . . . . . . . . . . . . . . . . . . . . . . .7 64 3.4 IPsec Security Association with new Home Agent . . . . . .7 65 3.4.1 Dynamic Keying . . . . . . . . . . . . . . . . . . 7 66 3.4.2 Manual Keying . . . . . . . . . . . . . . . . . . .7 67 3.5 Correct Ordering . . . . . . . . . . . . . . . . . . . . .8 68 3.6 Load Balancing . . . . . . . . . . . . . . . . . . . . . .8 70 4. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . .8 71 4.1 Security Implications . . . . . . . . . . . . . . . . . . 8 72 4.2 IPsec Security with new Home Agent . . . . . . . . . . . .8 73 4.3 Seamless failure . . . . . . . . . . . . . . . . . . . . .8 74 4.4 Mobile Node functionality . . . . . . . . . . . . . . . . 9 75 4.5 Messages over air interface . . . . . . . . . . . . . . . 9 76 4.6 Home Agent addition and failure . . . . . . . . . . . . . 9 77 4.7 Load Balancing. . . . . . . . . . . . . . . . . . . . . . 9 79 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .10 83 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .10 85 Intellectual Property and Copyright Statements . . . . . . . .10 87 Appendix: Changes from the previous version. . . . . . . . . .11 89 1. Introduction 91 Mobile IPv6[1] is designed to allow a Mobile Node(MN) to change its 92 point of IP subnet attachment in the Internet at the network or IP 93 layer. MN is always identified by it Home Address regardless of its 94 current location. Its mobility is not limited by conventional IP 95 network boundaries. In Mobile IPv6 system the Home Agent(HA) remains 96 at conventional IPv6 subnet called the home link and when the MN is 97 at the home link then the packets sent to it are routed through 98 conventional IPv6[5] routing mechanisms. When the MN is not at home 99 link it registers its remote point of attachment address called 100 Care-of Address with the HA. This allows HA to forward packets, 101 addressed to the MN at its home link, to its current location. 103 In Mobile IPv6 system, as currently specified, a single HA services 104 multiple MNs. Mobile IPv6 also allows deployment of multiple HAs on 105 the same link so that if the serving HA fails then any other HA 106 on the link can provide service to the MN. 108 The goal of this draft is to: 110 o Articulate the problems resulting from the failure of a serving 111 HA and switching of service to another HA. 113 o Specify a set of framework guidelines to evaluate proposed 114 solutions. 116 1.1 Overview of the Problem 118 In Mobile IPv6, MN registers and establishes a connection with only 119 one HA. The MN is reliant on this HA for its connectivity. Thus the 120 HA represents the possibility of a single point of failure for Mobile 121 IPv6. A HA may be responsible for multiple MNs on the home link. The 122 failure of a single HA may then result in the loss of connectivity 123 for numerous MNs located throughout the Internet. Thus the HA and MN 124 taken together have a shared fate. A MN cannot afford the loss of its 125 HA. To overcome this problem Mobile IPv6 allows deployment of 126 multiple HAs on the home link so that upon the failure of serving HA, 127 another HA can take over the functions of failed HA and thus provide 128 continuous service to the MN(s) registered with failed HA. This 129 transfer of service from the failed HA to a new working HA is 130 problematic and the current specification of Mobile IPv6 does not 131 provide solution to these problems. 133 1.2 Terminology 135 Following terms are not re-defined. They are included for the 136 convenience of the readers. 138 Mobile IPv6 139 Mobile IP for IPv6 [1] 141 Mobile Node (MN) 142 A node that can change its point of attachment from one link 143 to another, while still being reachable via its home address. 145 IP 146 Internet Protocol Version 6 (IPv6).[5] 148 Home Address 149 A unicast routable address assigned to a MN, used as the 150 permanent address of the MN. This address is within the MN's 151 home link. Standard IP routing mechanisms will deliver 152 packets destined for a MN's home address to its home 153 link.MNs can have multiple home addresses, for instance when 154 there are multiple home prefixes on the home link. 156 Home Link 157 The link on which a MN's home subnet prefix is defined. 159 Home Agent (HA) 160 A router on a MN's home link with which the MN has registered 161 its current Care-of address. While the MN is away from home, 162 the HA intercepts packets on the home link destined to the 163 MN's home address, encapsulates them, and tunnels them to the 164 MN's registered Ccare-of address. 166 Care-of Address 167 A unicast routable address associated with a MN while 168 visiting a foreign link; the subnet prefix of this IP address 169 is a foreign subnet prefix. Among the multiple 170 Care-of addresses that a MN may have at any given time (e.g., 171 with different subnet prefixes), the one registered with the 172 MN's HA for a given home address is called its "primary" 173 care-of address. 175 IPsec Security Association 176 An IPSec security association is a cooperative relationship 177 formed by the sharing of cryptographic keying material and 178 associated context. Security associations are simplex. That 179 is, two security associations are needed to protect 180 bidirectional traffic between two nodes, one for each 181 direction. 183 Home Registration 185 A registration between the MN and its HA, authorized by the 186 use of IPsec. 188 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [6]. 192 2. Mobile IPv6 Deployment Scenario 194 This section describes a basic deployment scenario where multiple 195 HAs, referred as HAs 1..n, have to coexist on the same home link to 196 provide continuous service to MN in case of failure of the serving 197 HA. MN runs Mobile IPv6 MN functionality with the mobility signaling 198 messages protected by IPsec. Also all the HAs 1..n run Mobile IPv6 HA 199 functionality along with IPsec server software. Initially MN is 200 registered and has IPv6 tunnel with HA_1. 202 ..Foreign Network.. ......Home Network............ 203 . . . . 204 . +----+ . . +-------+ . 205 . |MN | .<=========> . | HA_1 | . 206 . | | . . +-------+ +-------+ . 207 . +----+ . . ..... | HA_n | . 208 . . . +-------+ +-------+ . 209 . . . | HA_2 | . 210 . . . +-------+ . 211 ................... .............................. 212 Figure 1 214 3. Problem statement 216 This section uses the scenario discussed in section 2 to describe the 217 problems associated with the failure of serving HA and as the result 218 of this switching of service to another HA on the home link. Consider 219 the failure of HA_1. and switching of service to a new HA_x 220 (where x = 2..n) on the same home link. This whole process of failure 221 detection and switching is problematic. The problems are discussed 222 in the following sub-sections. 224 3.1 Failure 226 The following sub-sections introduce two possible scenarios of 227 failure. 229 3.1.1 Home Agent Failure 231 There could be single or multiple HAs failure on the home link. Since 232 MN could register only with a single HA on the home link which is 233 HA_1 in our scenario, so failure of multiple HAs is not going to 234 effect the normal operation of Mobile IPv6. We are only concerned 235 with the serving HA failure on the home link. 237 3.1.2 Home Link Failure 239 There could be failure of home link which will make it inaccessible 240 to the MN. If this occurs then even the serving HA_1 is operational, 241 to the MN it would appear that its serving HA_1 has failed. 243 3.2 Failure Detection 245 Transfer of service from the failed HA_1 to new HA_x will occur after 246 the detection of failure by MN. MN could detect the failure of HA_1 247 under certain conditions. These are listed below. 249 o When MN sends Binding Update(BU) message to the failed HA_1 and 250 does not receive matching Binding Acknowledgment(BA) message, it 251 will retransmit BUs until timeout occurs. Upon this MN will come to 252 know about the failure of HA_1. 254 o Similarly when MN sends Mobile Prefix Solicitation(MPS) message to 255 the failed HA_1 and does not receive Mobile Prefix Advertisement, 256 it will retransmit MPSs until timeout occurs and that's how it will 257 come to know that HA_1 has failed. 259 According to Mobile IPv6 MN after sending first BU or MPS message to 260 failed HA_1 will wait for a initial timeout period which is set to 261 INITIAL_BINDACK_TIMEOUT (1 second) in case of BU and 262 INITIAL_SOLICIT_TIMER (3 seconds) in case of MPS. This timeout period 263 will be doubled for each subsequent BU or MPS message until value of 264 MAX_BINACK_TIMEOUT (32 seconds) is reached. MN MAY send infinite BUs 265 or MPSs to failed HA_1 before the final timeout occurs. 267 So the detection of failed HA_1 will be delayed by a considerable 268 amount of time. Also there will be many messages transmitted over the 269 air interface during this period. Moreover BU and MPS are not 270 periodic rather on demand. MN will send BU only to register new 271 Care-of Address or to extend the lifetime of existing registration 272 with its serving HA. Similarly MN will send MPS only when its serving 273 HA's address is about to become invalid. As a result MN will suffer 274 packet loss and disconnectivity problems. This could have noticeable 275 performance implications on real-time applications. 277 3.3 Recovery 279 Once the failure is detected, according to the current specifications 280 of Mobile IPv6 MN will try to register its Care-of Address with any 281 other HA on the home link. For this MN must know which other HAs are 282 available on the home link. MN MAY start Dynamic Home Agent 283 discovery(DHAD)[1] protocol and as a result will get a list of 284 available HAs on the home link. MN could then select HA_x (in our 285 scenario) on the list as its potential serving HA. MN will send BU 286 message to HA_x setting Home Registration(H) bit. 288 But this recovery mechanism is problematic. If there is only one 289 HA available on the home link then according to current 290 specifications of Mobile IPv6 even if the retransmission parameter 291 MAX_BINACK_TIMEOUT (32 seconds) is reached MN will continue to send 292 BU messages to the HA_1 until it receives valid BA message and this 293 will never happen because HA_1 has failed. This makes the MN enter 294 into an endless loop. 296 Even if there are multiple HAs exist (as in our scenario), besides 297 failure detection, there is an extra burden on MN to perform 298 Home Registration with the new HA and in some cases multiple 299 Home Registrations if there are unsuccessful attempts. Also if there 300 is no information about the available HAs on the home link then MN 301 has to perform DHAD. All these factors together result in extra 302 messages overhead on the air interface, service interruption and 303 burden on MN. 305 3.4 IPsec Security Association with new Home Agent 307 According to the current specifications of Mobile IPv6 MN and HA_x 308 MUST use IPsec Security Associations to protect the integrity and 309 authenticity of the BUs and BAs. There are two methods of 310 establishing such Associations. 312 3.4.1 Dynamic Keying 314 If MN and the new HA_x does not have existing Security Association to 315 protect the BU, IKE[2] (referred as Dynamic Keying) will be 316 initiated according to the guidelines defined in [3]. The latency 317 caused by IKE transactions might cause performance degradation. 319 3.4.2 Manual Keying 321 The problem of Dynamic Keying can be avoided by Manual Keying. It 322 involves out-of-band entry of Security Associations in MN and HA. MN 323 can be statically configured for a set of HAs among HAs 1..n and 324 corresponding Security Associations before launching MN in the 325 Mobile IPv6 network. This will allow MN to register with any other 326 HA and use appropriate Security Associations upon the failure of it's 327 serving HA. But this policy is not flexible enough to accommodate the 328 dynamic nature of home link. 330 3.5 Correct Ordering 332 Upon the HA_1 failure the sequence number information in the Binding 333 Cache of HA_1 will also be lost. The new HA_x to which MN will switch 334 will not have the knowledge about the sequence number of last sent BU 335 by the MN. This introduces new security vulnerabilities to the 336 Mobile IPv6. 338 3.6 Load Balancing 340 Mobile IPv6 does not include any specification about how the HAs 341 on home link will do load balancing among them. This is important for 342 utilizing the services of all HAs on the home link efficiently. 344 4. Solution Guidelines 346 This section describes guidelines for a solution to the above 347 mentioned problems. The sub-sections discuss the guidelines in a 348 decreasing order of importance. 350 4.1 Security Implications 352 The solution MUST NOT introduce any new security vulnerabilities to 353 the Mobile IPv6. 355 4.2 IPsec Security with new Home Agent 357 The solution SHOULD provide a mechanism to quickly establish IPsec 358 Security Association between the MN and the new HA such that the 359 service interruption is minimal. 361 4.3 Seamless failure 363 It is recommended that the failure of HA should be transparent from 364 the MN. This will contribute in minimizing the period of service 365 interruption. 367 4.4 Mobile Node functionality 369 The solution SHOULD cause minimal modification to the MN operation 370 as it is defined by Mobile IPv6. 372 4.5 Messages over air interface 374 The solution SHOULD use minimal new messages. 376 4.6 Home Agent addition and failure 378 The solution SHOULD provide recovery mechanism for the failed HA. 379 Also any new HA added on the home link SHOULD be ready to serve in 380 minimum amount of time possible. 382 4.7 Load Balancing 384 The solution SHOULD provide load balancing mechanism for the HAs on 385 the home link. It could be of centralized or distributed nature. 387 References 389 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 390 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), August 391 2003. 393 [2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 394 RFC 2409, November 1998. 396 [3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 397 Protect Mobile IPv6 Signaling between Mobile Nodes and Home 398 Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in 399 progress), June 2003. 401 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 402 Levels", BCP 14, RFC 2119, March 1997. 404 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 405 Specification", RFC 2460, December 1998. 407 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 408 Levels", BCP 14, RFC 2119, March 1997. 410 Authors' Addresses 412 Jahanzeb Faizan 413 Southern Methodist University 414 Computer Science and Engineering Department. 415 6425 N Ownby Dr., SIC #300D 416 Dallas, TX, 75205, USA 418 Phone +1 214-768-3712, Fax +1 214-768-3085 419 EMail: jfaizan@smu.edu 421 Hesham El-Rewini 422 Southern Methodist University 423 Computer Science and Engineering Department. 424 6425 N Ownby Dr., SIC #306C 425 Dallas, TX, 75205, USA 427 Phone +1 214-768-3278, Fax +1 214-768-3085 428 EMail: rewini@engr.smu.edu 430 Mohammad Khalil 431 Nortel Networks 432 Richardson, TX, USA 434 Phone: +1 972-685-0564 435 EMail: mkhalil@nortelnetworks 437 Acknowledgements 439 The authors would like to thank Vijay Devarapalli and Ryuji Wakikawa 440 for their continuous feedback and helping us improve this draft. 442 Funding for the RFC Editor function is currently provided by the 443 Internet Society. 445 Intellectual Property Statement 447 The IETF takes no position regarding the validity or scope of any 448 intellectual property or other rights that might be claimed to 449 pertain to the implementation or use of the technology described in 450 this document or the extent to which any license under such rights 451 might or might not be available; neither does it represent that it 452 has made any effort to identify any such rights. Information on the 453 IETF's procedures with respect to rights in standards-track and 454 standards-related documentation can be found in BCP-11. Copies of 455 claims of rights made available for publication and any assurances of 456 licenses to be made available, or the result of an attempt made to 457 obtain a general license or permission for the use of such 458 proprietary rights by implementers or users of this specification can 459 be obtained from the IETF Secretariat. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 464 Full Copyright Statement 466 Copyright (C) The Internet Society (2003). All Rights Reserved. 468 This document and translations of it may be copied and furnished to 469 others, and derivative works that comment on or otherwise explain it 470 or assist in its implementation may be prepared, copied, published 471 and distributed, in whole or in part, without restriction of any 472 kind, provided that the above copyright notice and this paragraph are 473 included on all such copies and derivative works. However, this 474 document itself may not be modified in any way, such as by removing 475 the copyright notice or references to the Internet Society or other 476 Internet organizations, except as needed for the purpose of 477 developing Internet standards in which case the procedures for 478 copyrights defined in the Internet Standards process must be 479 followed, or as required to translate it into languages other than 480 English. 482 The limited permissions granted above are perpetual and will not be 483 revoked by the Internet Society or its successors or assignees. 485 This document and the information contained herein is provided on an 486 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 487 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 488 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 489 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 490 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 492 Appendix: Changes from Previous Version 494 The following changes have been made to this document from version 495 00: 497 o Addition of types of failure, correct ordering and load balancing 498 sections in the problem statement. 500 o Also failure detection and recovery sections are explained in 501 more detail in the problem statement. 503 o IPsec Security Associations with the new Home Agent section is 504 organized into Dynamic and Manual Keying sub-sections. 506 o Load balancing requirement is added in the solution guidelines 507 section.