idnits 2.17.1 draft-ietf-mobileip-lmm-requirements-04.txt: -(69): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(328): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(427): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(428): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(431): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(432): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(435): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(436): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(439): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(448): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 10 instances of lines with non-ascii characters in the document. == 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 an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4.0 Security Considerations' ) ** 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.) ** There are 225 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], 6], [7], [8], [9], [4,5,, [2,3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 168: '...istration domain MUST always be able t...' RFC 2119 keyword, line 175: '...2.1 LMM protocol MUST provide for "sec...' RFC 2119 keyword, line 178: '...pecific information and signaling MUST...' RFC 2119 keyword, line 182: '... protection MUST exist mutually b...' RFC 2119 keyword, line 184: '...2.2 LMM protocol MUST NOT interfere wi...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 232 has weird spacing: '...itional point...' == Line 265 has weird spacing: '...g group to de...' == Line 312 has weird spacing: '...], even thoug...' == Line 415 has weird spacing: '...Perkins and...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The LMM framework MUST not prevent header compression from being applied. It is recommended that andidate LMM designs that require additional header overhead for tunnel be reviewed by the ROHC working group to determine if the header compressor can be restarted from transferred compressor context when handover occurs without requiring any full header packet exchange on the new link. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The LMM design SHOULD not prohibit optimal placement of LMM agents to reduce or eliminate additional triangle routing introduced by LMM. -- 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 (October 2003) is 7498 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '4' on line 427 looks like a reference -- Missing reference section? '5' on line 431 looks like a reference -- Missing reference section? '6' on line 435 looks like a reference -- Missing reference section? '3' on line 424 looks like a reference -- Missing reference section? '7' on line 439 looks like a reference -- Missing reference section? '2' on line 421 looks like a reference -- Missing reference section? '1' on line 415 looks like a reference -- Missing reference section? '8' on line 444 looks like a reference -- Missing reference section? '9' on line 447 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carl Williams, Editor 3 Internet Engineering Task Force MCSR Labs 5 Issued: October 2003 6 Expires: April 2004 8 Localized Mobility Management Requirements 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as 'work in progress.' 26 The list of current Internet-Drafts can be accessed at 27 http://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 Abstract 34 This document describes requirements for Localized Mobility 35 Management (LMM) for Mobile IP and Mobile IPv6 protocols. 36 These requirements are intended to guide the design of a protocol 37 specification for LMM. Localized Mobility Management, in general, 38 introduces enhancements to Mobile IPv4 and Mobile IPv6 to 39 reduce the amount of latency in binding updates sent to the Home 40 Agent and, for route-optimization, Correspondent Nodes, upon 41 Care of Address change. In addition, LMM seeks to reduce the 42 amount of signaling over the global Internet when a mobile 43 node traverses within a defined local domain. The identified 44 requirements are essential for localized mobility management 45 functionality. They are intended to be used as a guide for 46 analysis on the observed benefits over the identified requirements 47 for architecting and deploying LMM schemes. 49 Table of Contents 51 1.0 Introduction .................................................... 2 52 2.0 Terminology ..................................................... 4 53 3.0 Requirements .................................................... 4 54 3.1 Intra-domain mobility ........................................ 4 55 3.2 Security ..................................................... 4 56 3.3 Induced LMM functional requirement ........................... 5 57 3.4 Scalability, Reliability, and Performance .................... 5 58 3.5 Mobility Management Support .................................. 7 59 3.6 Auto-configuration capabilities for LMM constituents.......... 7 60 3.7 LMM Inter-working with IP routing infrastructure requirement.. 8 61 3.8 Sparse routing element population requirement ................ 8 62 3.9 Support for Mobile IPv4 or Mobile IPv6 Handover .............. 8 63 3.10 Simple network design requirement ........................... 8 64 3.11 Stability ................................................... 9 65 3.12 QoS Requirements ............................................ 9 66 4.0 Security Considerations ......................................... 9 67 5.0 Acknowledgments ................................................. 9 68 6.0 References ...................................................... 9 69 Appendix A � LMM Requirements and HMIPv6............................. 11 70 Author's Addresses .................................................. 11 71 Full Copyright Statement ............................................ 11 73 1.0 Introduction 75 In order to meet the demands of real-time applications and the expectations 76 of future wireless users for service level quality similar to the one of 77 wireline users, IP based mobility management is facing a number of technical 78 challenges in terms of performance and scalability [4, 5, 6]. These manifest 79 themselves as increased latencies in the control signaling between a Mobile 80 Node and its peer entities, namely the Home Agent (HA) and its Corresponding 81 Nodes (CNs). 83 In the base Mobile IP protocol [3], movement between two subnets 84 requires that the Mobile Node obtain a new Care of Address in the 85 new subnet. This allows the Mobile Node to receive traffic on the 86 new subnet. In order for the routing change to become effective, 87 however, the Mobile Node must issue a binding update (also known in 88 Mobile IPv4 as a Home Agent registration) to the Home Agent so that 89 the Home Agent can change the routing from the previous subnet to 90 the new subnet. The binding update establishes a host route on the 91 Home Agent between the Mobile Node's Home Address and its new Care 92 of Address. In addition, if route optimization is in use [3], the 93 Mobile Node may also issue binding updates to Correspondent Nodes to 94 allow them to send traffic directly to the new Care of Address 95 rather than tunneling their traffic through the Home Agent. 97 Traffic destined for the Mobile Node is sent to the old Care of 98 Address and is, effectively, dropped until the Home Agent processes 99 the MIPv6 Binding Update or MIPv4 Home Agent Registration. If the 100 Mobile Node is at some geographical and topological distance away 101 from the Home Agent and Correspondent Nodes, the amount of time 102 involved in sending the binding updates may be greater than 100 103 hundred milliseconds. This latency in routing update may cause 104 some packets for the Mobile Node to be lost at the old Access Router. 105 Recently, Mobile IP has been extended by certain local mobility mechanisms, 106 aiming to alleviate the above performance limitations; they are identified 107 as hierarchical/regional or more generically Localized Mobility Management 108 (LMM). LMM schemes allow the Mobile Node to continue receiving traffic on 109 the new subnet without any change in the Home Agent or Correspondent 110 Node binding. The latency involved in updating the Care of Address bindings 111 at far geographical and topological distances is eliminated or reduced until 112 such time as the Mobile Node is in a position to manage the latency cost. 114 Having provided some motivation and brief summary of the underlying 115 principles of LMM, it is important to enumerate goals for LMM. 117 Goals for LMM: 119 - reduce the signaling induced by changes in the 120 point of attachment due to the movement of a host; 121 reduction in signaling delay will minimize 122 packet loss and possible session loss; 124 - reduce the usage of air-interface and network 125 resources for mobility; 127 - reduce the processing overhead at the peer nodes, 128 thereby improving protocol scalability; 130 - avoid or minimize the changes of, or impact to the 131 Mobile Node, Home Agent or the Correspondent Node; 133 - avoid creating single points of failure; 135 - simplify the network design and provisioning 136 for enabling LMM capability in a network; 138 - allow progressive LMM deployment capabilities. 140 Identifying a solid set of requirements that will render the 141 protocol internals, for some LMM scheme, robust enough to 142 cater for the aforementioned considerations becomes essential 143 in designing a widely accepted solution. The remainder of this 144 document present a set of requirements that encompass essential 145 considerations for the design of an LMM scheme. It is with this 146 foundation that we can seek to ensure that the resulting LMM 147 solution will best preserve the fundamental philosophies and 148 architectural principles of the Internet in practice today. 150 2.0 Terminology 152 Please also see [7] for mobility terminology used in this document. 154 3.0 LMM Requirements 156 This section describes the requirements for a LMM solution. The 157 requirements are relevant to both Mobile IPv4 and Mobile IPv6. 159 3.1 Intra-domain mobility 161 LMM is introduced to minimize the signaling traffic to the Home Agent 162 and/or Correspondent Node(s) for intra-domain mobility (within a 163 Local Coverage Area). This is the fundamental reason for 164 introducing localized mobility management extensions to core Mobile 165 IPv6. 167 In the LMM infrastructure a Correspondent Node or Home Agent outside 168 the administration domain MUST always be able to address the mobile 169 host by the same IP address, so that from the point of view of hosts 170 outside the administration domain, the IP address of the mobile host 171 remains fixed regardless of any changes in the Mobile Node's subnet. 173 3.2 Security 175 3.2.1 LMM protocol MUST provide for "security provisioning" within the 176 respective local coverage area. 178 The security of exchanging LMM specific information and signaling MUST 179 be ensured. Security provisioning includes protecting the integrity, 180 confidentiality, and authenticity of the transfer of LMM specific 181 information within the administration domain. If applicable, replay 182 protection MUST exist mutually between the LMM agents. 184 3.2.2 LMM protocol MUST NOT interfere with the security provisioning that 185 exists between the Home Agent and the Mobile Node. 187 3.2.3 LMM protocol MUST NOT interfere with the security provisioning that 188 exists between the Correspondent Node and the Mobile Node. 190 3.2.4 LMM protocol MUST NOT introduce new security holes or the possibility 191 for DOS-style attacks. 193 3.3 Induced LMM functional requirements 195 3.3.1 Any Localized Mobility Management protocol MUST NOT inject 196 any additional functionality over base Mobility [2, 3] at the 197 Home Agent or any of its peer CNs. Thus, the LMM framework 198 MUST NOT add any modifications or extensions to the Correspondent 199 Node(s) and Home Agent. It is essential to minimize 200 the involvement of the Mobile Node in routing beyond what is in 201 the basic MIP and MIpv6 protocol. Preferences, load balancing, and 202 other complex schemes requiring heavy mobile node involvement 203 in the mobility management task SHOULD BE avoided. 205 3.3.2 Non-LMM-aware routers, hosts, Home Agents, and Mobile Nodes 206 MUST be able to interoperate with LMM agents. 208 3.3.3 The LMM framework MUST NOT increase the number of messages between 209 the mobile host and the respective Correspondent Node(s) and Home 210 Agent. Indeed, the LMM framework MUST minimize the global 211 signaling between the MN and its peers. The amount 212 of regional signaling MUST NOT surpass the amount of global 213 signaling that would have otherwise occurred if LMM were not 214 present. 216 3.4 Scalability, Reliability, and Performance 218 3.4.1 The LMM complexity MUST increase at most linearly with the 219 size of the local domain and the number of Mobile Nodes. 221 3.4.2 Any Localized Mobility Management protocol MUST assure that 222 that LMM routing state scales at most linearly with the number 223 of Mobile Nodes registered, and that the increase in routing 224 state is confined to those ARs/ANRs involved in implementing 225 the LMM protocol at hand. This would involve MIP-specific 226 routing state as binding caches in addition to standard 227 routing table host routes. While host routes cannot be 228 eliminated by any mobility management protocol including 229 base IP mobility, any LMM protocol MUST keep the number of 230 host routes to a minimum. 232 3.4.3 The LMM framework MUST NOT introduce additional points of failure in 233 the network. The current access router would be excluded from 234 this requirement. 236 3.4.4 The LMM framework MUST NOT interfere with the basic IP mobility 237 performance of a mobile host communications with a Correspondent 238 Node(s). 240 3.4.5 Scalable expansion of the network 242 The LMM framework MUST allow for scalable expansion of the network 243 and provide for reasonable network configuration with regard 244 to peering, inter-administrative domain connectivity, and other 245 inter-administrative domain interoperability characteristics of 246 interest to wireless ISPs. The LMM framework MUST NOT introduce 247 any additional restrictions in how wireless ISPs configure their 248 network, nor how they interconnect with other networks beyond 249 those introduced by standard IP routing. In addition, the 250 amount of regional signaling MUST NOT increase as the Local 251 Domain expands in size. 253 3.4.6 Resilience to topological changes 255 The LMM protocols MUST be topology-independent. The LMM protocols 256 MUST be able to adapt to topological changes within the domain. The 257 topological changes may include the addition or removal/failure of 258 LMM agents or that of changes in the routing of the local domain 259 over which the LMM scheme is applied. 261 3.4.7 Header or Tunneling overhead 263 The LMM framework MUST not prevent header compression from being applied. 264 It is recommended that andidate LMM designs that require additional header 265 overhead for tunnel be reviewed by the ROHC working group to determine if 266 the header compressor can be restarted from transferred compressor context 267 when handover occurs without requiring any full header packet exchange on 268 the new link. 270 3.4.8 Optimized signaling within the Local Coverage Area 272 By its very nature, LMM reintroduces triangle routing into Mobile IPv6 273 in that all traffic must go through the LMM agent. There is no way 274 to avoid this. The LMM framework SHOULD be designed in such a way 275 as to reduce the length of the unwanted triangle leg. 277 The LMM design SHOULD not prohibit optimal placement of LMM agents to 278 reduce or eliminate additional triangle routing introduced by LMM. 280 NOTE: It is not required that a LMM scheme specify LMM agents as part 281 of its solution. 283 3.5 Mobility Management Support 285 The following LMM requirements pertain to both inter-domain and 286 intra-domain hand-off. 288 3.5.1 The LMM framework MUST NOT increase the amount of latency or amount of 289 packet loss that exists with the core Mobile IP and Mobile IPv6 290 specification [2, 3]. Indeed, the LMM framework SHOULD decrease the 291 amount of latency or amount of packet loss that exists with the 292 core mobility protocols. 294 3.5.2 The LMM framework MUST NOT increase the amount of service disruption 295 that already exists with the core mobility specifications. 296 Again, the LMM framework SHOULD decrease the amount of service 297 disruption that already exists with the core mobility protocols. 299 3.5.3 The LMM framework MUST NOT increase the number of messages between 300 the mobile host and the respective Correspondent Node(s) and Home 301 Agent as is in the core mobility specifications [2, 3]. The LMM 302 framework SHOULD decrease the number of messages between the 303 mobile host and the respective Correspondent Node(s) and Home 304 Agent as is in the core mobility specifications [2, 3]. 306 3.6 Auto-configuration capabilities for LMM constituents 308 It is desirable that in order to allow for simple incremental 309 deployment of an LMM scheme, the local mobility agents MUST 310 require minimal (if any) manual configuration. This plug-and-play 311 feature could make use of IPv6 auto-configuration mechanisms in 312 the case of Mobile IPv6 [3], even though most likely other 313 automatic configurations will be needed (such as, for example, 314 learning about adjacent LMM agents). Auto-configuration also 315 facilitates the network to dynamically adapt to general topological 316 changes (whether planned or due to link or node failures). 318 3.7 LMM inter-working with IP routing infrastructure requirement 320 The LMM framework MUST NOT disrupt core IP routing outside 321 the local domain. 323 3.8 Sparse routing element population requirement 325 Any LMM protocol MUST be designed to be geared towards 326 incremental deployment capabilities; the latter implies 327 that the LMM scheme itself imposes minimum requirements 328 on the carrier�s network. Incremental deployment capabilities 329 for an LMM protocol signifies that an initial set of sparse 330 LMM agents can populate the administration domain of a network 331 provider and operate sufficiently. In addition, any LMM 332 scheme MUST be compatible with any additional deployment 333 of LMM agents in future infrastructure expansions; that is to 334 say, allow progressive LMM deployment capabilities. 336 It is for this reason that the LMM framework MUST NOT require 337 that all routing elements be assumed to be LMM-aware in the 338 signaling interactions of an LMM protocol. The LMM framework 339 MUST BE supported, at the very minimum, by a sparse (proper 340 subset) LMM agent population that is co-located within the 341 routing topology of a single administration domain. 343 3.9 Support for Mobile IPv4 or Mobile IPv6 Handover 345 Since one of the primary goals of LMM is to minimize 346 signaling during handover, an LMM solution MUST be 347 available for the standardized Mobile IPv4 or Mobile IPv6 348 handover algorithms. LMM and the Mobile IP or Mobile IPv6 349 handover algorithms MUST maintain compatibility in their 350 signaling interactions for fulfilling complementary roles 351 with respect to each other. 353 This requirement SHOULD NOT be interpreted as ruling out 354 useful optimizations of LMM and Mobile IP or Mobile IPv6 handoff 355 schemes that simplify the implementation or deployment of LMM or 356 Mobile IP or Mobile IPv6 handoff. 358 3.10 Simple Network design requirement 360 LMM SHOULD simplify the network design and provisioning for enabling LMM 361 capability in a network and allow progressive LMM deployment capabilities. 363 INTERNET Draft Localized Mobility Management Requirements October 2003 365 3.11 Stability 367 LMM MUST avoid any forwarding loops. 369 3.12 Quality of Service requirements 371 3.12.1 The LMM MUST have the ability to coexist with 372 QoS schemes to hide the mobility of the MN to its peer 373 by avoiding end-to-end QoS signaling. 375 3.12.2 The LMM MUST have the ability to coexist with QoS 376 schemes to facilitate the new provisioning of both uplink 377 and downlink QoS after a handoff. 379 4.0 Security Considerations 381 This document does not generate any additional security considerations. 383 5.0 Acknowledgments 385 Thank you to all who participated in the LMM requirement discussion 386 on the Mobile IP working group alias. First, the editor wishes to recognize 387 Theo Pagtzis's work on LMM requirement analysis. Theo has contributed 388 significantly to the LMM discussion on the mailing list and at IETF 389 working group meetings and has provided text for various requirements. 390 Special thanks also to Gabriel Montenegro, John Loughney, Alper Yegin, Alberto 391 Lopez Toledo, and Madjid Nakhjiri for providing input to the draft in its 392 preliminary stage and many other comments they had. 393 Thanks to the LMM requirement analysis design team: Hesham Soliman, Erik 394 Nordmark, Theo Pagtzis, James Kempf, and Jari Malinen. 396 Additional comments on the LMM requirements were received from: Charlie 397 Perkins, Muhammad Jaseemuddin, Tom Weckstr, Jim Bound, Gopal Dommety, 398 Glenn Morrow, Arthur Ross, Samita Chakrabarti, Karim El-Malki, Phil Neumiller, 399 Behcet Sarikaya, Karann Chew, Michael Thomas, Pat Calhoun, Bill Gage, Vinod 400 Choyi, John Loughney, Wolfgang Schoenfeld, David Martin, Daichi Funato, Ichiro 401 Okajima, Jari Malinen, Kacheong Poon, Koshimi Takashi, and Cedric Westphal. 403 An LMM requirement analysis of this body of work was completed by a number 404 of members of the Mobile IP working group and published in [1] below. 406 In addition special thanks to the Mobile IP working group chairs, 407 Phil Roberts, Gabriel Montengro, and Basavaraj Patil, for their input as 408 well as capturing/organizing the initial set of requirements from the 409 discussions. 411 6.0 References 413 Normative References 415 [1] T. Pagtzis, C. Williams, P. Kirstein, C. Perkins and 416 A. Yegin, "Requirements for Localised IP Mobility 417 Management", Proceedings of IEEE Wireless Communications 418 and Networking Conference (WCNC2003), Louisiana, 419 New Orleans, March 2003. 421 [2] Perkins, C., "IP Mobility Support for IPv4," 422 RFC3344, August 2002. 424 [3] David B. Johnson, Charles Perkins, J. Arkko, 425 "Mobility Support in IPv6", Work in Progress, June 2003. 427 [4] G. Karlsson, �Quality Requirements for Multimedia Network 428 Services�, Proceedings of Radiovetenskap ach kommunikation, 429 June 1996, pp. 96-100. 431 [5] T. Kurita, S. Iai, and N. Kitawaki, �Effects of transmission 432 delay in audiovisual communications�, Electronics and 433 Communications in Japan, Vol 77, no 3, pp. 63-74, 1995. 435 [6] Y. Wang, M. Claypool, and Z. Zuo, �An Empirical Study of 436 RealVideo Performance Across the Internet�, in Proceedings of 437 ACM SIGCOMM Internet Measurement Workshop, Nov. 2001. 439 [7] J. Manner, M. Kojo, �Mobility Related Terminology�, 440 Work in Progress, April 2003. 442 Informative References 444 [8] R. Koodli. (Editor), "Fast Handovers for Mobile 445 IPv6"; Work in Progress; October 2003. 447 [9] Soliman, H., Castelluccia, C., El-Malki, K., Bellier L., 448 �Hierarchical Mobile Ipv6 mobility management (HMIPv6)�, 449 Work in progress, June 2003. 451 Appendix A - LMM requirements and HMIPv6 453 HMIPv6 was evaluated as a localized mobility management protocol, and that it 454 was mostly found to satisfy the requirements put forth in this document. This 455 section details one exception with some explanation. 457 Exception 1: 459 One LMM requirement that needs further clarification with respect to HMIPv6 is 460 the requirement that states that LMM should not introduce additional single 461 points of failure. The HMIPv6 Mobility Anchor Point (MAP) is a new single 462 point of failure. Proposals for HMIPv6 MAP replication can be optionally 463 incorporated in order to avoid this new single point of failure. Such proposals 464 can also be applied to the base Mobile IPv6 specification to also allow for Home 465 Agent failover as well. 467 Author Address 469 Carl Williams 470 MCSR Labs 471 3790 El Camino Real 472 Palo ALto, CA 94306 USA 473 phone: +1 650 279 5903 474 email: carlw@mcsr-labs.org 476 Full Copyright Statement 478 Copyright (C) The Internet Society (2000). All Rights Reserved. 480 This document and translations of it may be copied and furnished to 481 others, and derivative works that comment on or otherwise explain it 482 or assist in its implementation may be prepared, copied, published 483 and distributed, in whole or in part, without restriction of any 484 kind, provided that the above copyright notice and this paragraph 485 are included on all such copies and derivative works. However, this 486 document itself may not be modified in any way, such as by removing 487 the copyright notice or references to the Internet Society or other 488 Internet organizations, except as needed for the purpose of 489 developing Internet standards in which case the procedures for 490 copyrights defined in the Internet Standards process must be 491 followed, or as required to translate it into languages other than 492 English. 494 The limited permissions granted above are perpetual and will not be 495 revoked by the Internet Society or its successors or assigns. 496 This document and the information contained herein is provided on an 497 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 498 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 499 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 500 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 501 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.