idnits 2.17.1 draft-ietf-mobileip-lmm-requirements-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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 21 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** 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 235: '...istration domain MUST always be able t...' RFC 2119 keyword, line 246: '...2.1 LMM protocol MUST provide for "sec...' RFC 2119 keyword, line 249: '...pecific information and signaling MUST...' RFC 2119 keyword, line 253: '... protection MUST exist mutually betw...' RFC 2119 keyword, line 255: '...2.2 LMM protocol MUST provide for the ...' (49 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (March 1, 2002) is 8089 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) == Unused Reference: '5' is defined on line 531, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 541, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-04) exists of draft-manner-seamoby-terms-02 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-02) exists of draft-proberts-local-subnet-mobility-problem-01 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 2002 (ref. '5') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carl Williams, Editor 2 Internet Engineering Task Force DoCoMo USA Labs 4 Issued: March 1, 2002 5 Expires: September 7, 2002 7 Localized Mobility Management Requirements for IPv6 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as 'work in progress.' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes requirements for Localized Mobility 34 Management (LMM) for Mobile IPv6. These requirements are intended 35 to guide the design of a protocol specification for LMMv6. 36 Localized Mobility Management, in general introduces Local Mobility 37 Agent functionality for proxying a Regional care of address that 38 remains the same while the mobile node moves within a Local Mobility 39 Domain, which reduces the binding update signaling latency and the 40 signaling load outside the Local Mobility Domain. By its very nature 41 LMM also serves as a mechanism to hide the Mobile Node's location 42 from observers outside the administration domain (Local Mobility 43 Domain). The identified requirements are essential for localized 44 mobility management functionality. They are intended to be used as 45 a guide for analysis on the observed benefits over the 46 identified requirements for architecting and deploying LMM schemes. 48 Table of Contents 50 1.0 Introduction .................................................... 2 51 2.0 Terminology ..................................................... 4 52 3.0 Requirements .................................................... 5 53 3.1 Intra-domain mobility ........................................ 5 54 3.2 Security ..................................................... 6 55 3.3 Induced LMM functional requirement ........................... 6 56 3.4 Scalability, Reliability, and Performance .................... 7 57 3.5 Mobility Management Support .................................. 8 58 3.6 Auto-configuration capabilities for LMM constituents.......... 9 59 3.7 Interworking with IP routing infrastructure requirement....... 9 60 3.8 Sparse routing element population requirement ................ 9 61 3.9 Support for Mobile IPv6 Handover ............................. 10 62 3.10 Simple network design requirement ........................... 10 63 3.11 Location privacy and tracking support ....................... 10 64 3.12 Stability ................................................... 10 65 3.13 QoS Requirements ............................................ 10 66 4.0 Acknowledgments ................................................. 11 67 5.0 References ...................................................... 12 68 6.0 Author's Addresses .............................................. 12 69 7.0 Full Copyright Statement ........................................ 13 71 1.0 Introduction 73 In order to meet the demands of real-time applications and the 74 expectations of future wireless users for service level quality 75 similar to the one of wireline users, base mobility management in 76 IP networks, and in particular Mobile IPv6 is facing a number 77 of technical challenges in terms of performance and scalability. 78 These manifest themselves as increased latencies in the control 79 signaling between a Mobile Node and its peer entities, namely the 80 Home Agent (HA) and its Corresponding Nodes (CNs). 82 1.1 Motivation 84 It is well established that real-time applications impose stringent 85 requirements in terms of delay and packet loss. From an IP 86 mobility perspective any induced latency would cause these 87 applications to experience noticeable degradation in quality as the 88 mobile user transits within the same or over different internet 89 (ISPs) or context (CSPs) service providers. This is further 90 exacerbated as the rate of transition of the MN (handoff) increases, 91 between different such service or content providers manifested in 92 form of provisioning (domains). [1] 94 When a MN transits from its home domain to a foreign one, it 95 is required to provide its Home Agent with its current mobility 96 bindings that yield a reachable destination on the visiting domain. 97 The MN must send an inter-domain Binding Updates (BU) to notify 98 both its HA and its communicating CN(s) about its movement that 99 has caused attachment to a new Access Router (AR). For large 100 round-trip times (RTT) between the MN and its HA or CNs (in the 101 order of 300-500 ms), the mobility management signaling is bound 102 to introduce delays as well as potential packet loss in the 103 forwarding of traffic through the HA tunnel (triangular routing) 104 or through direct communication between the MN and the CN. [1] 106 Furthermore, for a high rate of handoff, the BU of the MN 107 is soon to be rendered invalid; that will require new BUs 108 to be generated at a much higher frequency by the MN and 109 thus result in a signaling overhead for its peer 110 communicating entities; this is bounded by the RTT between 111 the MN and its peers (HA and CNs). 113 1.2 Principles of LMM 115 To alleviate the above mentioned mobility issues, extensions to 116 the Mobile IPv6 protocol are proposed to minimize or at best, 117 eliminate frequent mobility management signaling (BUs) to its 118 HA and its peer CNs, caused by frequent change of care-of address. 119 This is achieved by introducing Localized Mobility Management 120 Agents (LMM agents) into the visited domain with functionality 121 similar to a HA. Thus, control messages are either localized 122 (regional) or global signals. Localized signals are those that 123 are bound within a single administrative domain and generally 124 targeted towards the LMM agent(s) whereas global signals are 125 those that are communicated across different administrative 126 domains with their destination the true peers of the MN. 127 With the introduction of regional control messages the 128 signaling load of the MNs corresponding HA and CNs is reduced 129 as long as the MN stays within the administrative domain. [1] 131 As it has been pointed out, the main issues behind LMMs is to 132 eliminate frequent Binding Updates to both HA and CN entities. 133 This is done introducing a level of indirection by assigning 134 two care-of addresses to each MN: one on-link care-of address 135 (LCoA), and one regional care-of address. The change of the 136 on-link CoA is visible (mobility-local) only within the visited 137 domain for the purpose of mobility. The regional care-of 138 address is visible to those peer entities outside the local 139 domain (mobility-global) and it changes when the MN moves between 140 different administrative domains. 142 1.3 Consideration points for LMM design 144 Having provided some motivation and brief summary of the underlying 145 principles of LMM, it is important to enumerate goals for LMM. 147 Goals for LMM: 149 - reduce the signaling induced by changes in the 150 point of attachment due to the movement of a host; 151 this is the fundamental reason for introducing 152 localized mobility management extensions to core 153 Mobile IPv6. 155 - provide a mechanism whereby the mobile nodes 156 location is hidden from observers outside the 157 administration domain. 159 - reduce the usage of air-interface and network 160 resources for mobility; 162 - avoid or minimize the changes of, or impact to the 163 Mobile Node, Home Agent or the Correspondent Node; 165 - avoid creating single points of failure; 167 - simplify the network design and provisioning 168 for enabling LMM capability in a network; 170 - allow progressive LMM deployment capabilities. 172 Identifying a solid set of requirements that will render the 173 protocol internals, for some LMM scheme, robust enough to 174 cater for the aforementioned considerations becomes essential 175 in designing a widely accepted solution. The remainder of this 176 document present a set of requirements that encompass essential 177 considerations for the design of an LMM scheme. It is with this 178 foundation that we can seek to ensure that the resulting LMM 179 solution will best preserve the fundamental philosophies and 180 architectural principles of the Internet in practice today. 182 2.0 Terminology 184 See [2] for additional terminology. 186 Administrative Domain A collection of networks under the same 187 administrative control and grouped together 188 for administrative purposes. [2] 190 Local Mobility The movement of an IP device without requiring 191 a change to its routable IP address seen by 192 the CN or HA. Although its point of attachment 193 may change during the move, the IP addresses used 194 to reach the device (both its home and globally 195 visible routable IP address) do not change. 197 Local Mobility Agent A Mobile Node uses Local Mobility Agent as 198 (LMA) a local Home Agent while roaming within a Local 199 Mobility Domain. The LMA proxy Regional CoA, 200 receives all packets on behalf of the Mobile 201 Node and will encapsulate and forward them 202 directly to its current address. 204 Local Mobility Domain A Local Mobility Domain contains one or more 205 IP subnets, networks, or Administrative 206 Domains. Within the Local Mobility Domain, 207 the globally visible routable IP address assigned 208 to a Mobile Host or Mobile Router serving a Mobile 209 Network does not change. 211 Localized Mobility A method of moving an IP device without requiring 212 Management (LMM) a change to its routable IP address seen by 213 its peers, namely the MN's HA and its CNs, 214 in order to restrict the signaling area, thus 215 possibly reducing the amount of signaling. 217 Strong Authentication Techniques that permit entities to provide 218 evidence that they know a particular secret 219 without revealing the secret. [3] 221 3.0 LMM Requirements 223 This section describes the requirements of a LMM solution for 224 Mobile IPv6. Only Mobile IPv6 based requirements are described here. 226 3.1 Intra-domain mobility 228 LMM is introduced to minimize the signaling traffic to the Home Agent 229 and/or Correspondent Node(s) for intra-domain mobility (within an 230 Administrative Domain). This is the fundamental reason for 231 introducing localized mobility management extensions to core Mobile 232 IPv6. 234 In the LMM infrastructure a Correspondent Node or Home Agent outside 235 the administration domain MUST always be able to address the mobile 236 host by the same IP address, so that from the point of view of hosts 237 outside the administration domain, the IP address of the mobile host 238 remains fixed regardless of any changes in the Mobile Node's subnet. 240 It is not the intent or goal for LMM to enter the intra-subnet 241 (intra AR) mobility problem space. See [4] for more information 242 on this specific problem space. 244 3.2 Security 246 3.2.1 LMM protocol MUST provide for "security provisioning" within the 247 respective administration domain. 249 The security of exchanging LMM specific information and signaling MUST 250 be ensured. Security provisioning includes protecting the integrity, 251 confidentiality, and authenticity of the transfer of LMM specific 252 information within the administration domain. If applicable, replay 253 protection MUST exist mutually between the LMM agents. 255 3.2.2 LMM protocol MUST provide for the security provisioning to be 256 disabled. 258 In certain environments the security within the administration domain 259 may not be necessary, or it may be preferred to minimize the LMM protocol 260 overhead. This feature would be used at the network operator's own risk. 262 3.2.3 LMM protocol MUST NOT interfere with the security provisioning that 263 exists between the Home Agent and the Mobile Node. 265 3.2.4 LMM protocol MUST NOT interfere with the security provisioning that 266 exists between the Correspondent Node and the Mobile Node. 268 3.2.5 LMM protocol MUST NOT introduce new security holes or the possibility 269 for DOS-style attacks. 271 3.2.6 An LMM scheme MUST provide support for security at the 272 level associated with routing. LMM SHOULD also ensure 273 that the network be able to maintain topological confidentiality 274 from visiting mobile nodes. That is to say that the LMM 275 scheme in use SHOULD NOT reveal the visited network's 276 topology to the Mobile Node. 278 3.3 Induced LMM functional requirements 280 3.3.1 Any Localized Mobility Management protocol MUST NOT inject 281 any additional functionality over base IPv6 Mobility [6] at the 282 Home Agent or any of its peer CNs. Thus, the LMM framework 283 MUST NOT add any modifications or extensions to the Correspondent 284 Node(s) and Home Agent. It is essential to minimize 285 the involvement of the Mobile Node in routing beyond what is in 286 the basic MIPv6 protocol. Preferences, load balancing, and other 287 complex schemes requiring heavy mobile node involvement 288 in the mobility management task SHOULD BE avoided. 290 3.3.2 Non-LMM-aware routers, hosts, Home Agents, and Mobile Nodes 291 MUST be able to interoperate with LMM agents. 293 3.3.3 The LMM framework MUST NOT increase the number of messages between 294 the mobile host and the respective Correspondent Node(s) and Home 295 Agent. Indeed, the LMM framework MUST minimize the global 296 signaling between the MN and its peers. The amount 297 of regional signaling MUST NOT surpass the amount of global 298 signaling that would have otherwise occurred if LMM were not 299 present. 301 3.4 Scalability, Reliability, and Performance 303 3.4.1 The LMM complexity MUST increase at most linearly with the 304 size of the local domain and the number of Mobile Nodes. 306 3.4.2 Any Localized Mobility Management protocol MUST assure that 307 that LMM routing state scales at most linearly with the number 308 of Mobile Nodes registered, and that the increase in routing 309 state is confined to those ARs/ANRs involved in implementing 310 the LMM protocol at hand. This would involve MIP-specific 311 routing state as binding caches in addition to standard 312 routing table host routes. While host routes cannot be 313 eliminated by any mobility management protocol including 314 base IP mobility, any LMM protocol MUST keep the number of 315 host routes to a minimum. 317 3.4.3 The LMM framework MUST NOT create single points of failure in 318 the network. The current access router would be excluded from 319 this requirement. 321 3.4.4 The LMM framework MUST NOT interfere with the Mobile IPv6 322 performance of a mobile host communications with a Correspondent 323 Node(s). 325 3.4.5 Scalable expansion of the network 327 The LMM framework MUST allow for scalable expansion of the network 328 and provide for reasonable network configuration with regard 329 to peering, inter-administrative domain connectivity, and other 330 inter-administrative domain interoperability characteristics of 331 interest to wireless ISPs. The LMM framework MUST NOT introduce 332 any additional restrictions in how wireless ISPs configure their 333 network, nor how they interconnect with other networks beyond 334 those introduced by standard IP routing. In addition, the 335 amount of regional signaling MUST NOT increase as the Local 336 Domain expands in size. 338 3.4.6 Resilience to topological changes 340 The LMM protocols MUST be topology-independent. The LMM protocols 341 MUST be able to adapt to topological changes within the domain. The 342 topological changes may include the addition or removal/failure of 343 LMM agents or that of changes in the routing of the local domain 344 over which the LMM scheme is applied. 346 3.4.7 Header or Tunneling overhead 348 Any additional header or tunneling overhead caused by LMM MUST 349 be reduced on the radio link by compression. The transfer of 350 compressor state on movement SHOULD be possible so as not to 351 introduce any perceived service disruption. 353 Candidate LMM designs that require additional header overhead for 354 tunnels MUST be reviewed by the ROHC working group to determine 355 if the header compressor can be restarted from transferred compressor 356 context when handover occurs without requiring any full header packet 357 exchange on the new link. 359 3.4.8 Optimized signaling within the administrative domain 361 By its very nature, LMM reintroduces triangle routing into Mobile IPv6 362 in that all traffic must go through the LMM agent. There is no way 363 to avoid this. The LMM framework SHOULD be designed in such a way 364 as to reduce the length of the unwanted triangle leg. 366 The LMM design SHOULD not prohibit optimal placement of LMM agents to 367 reduce or eliminate additional triangle routing introduced by LMM. 369 3.5 Mobility Management Support 371 The following LMM requirements pertain to both inter-domain and 372 intra-domain hand-off. 374 3.5.1 The LMM framework MUST NOT increase the amount of latency or amount of 375 packet loss that exists with the core Mobile IPv6 specification [6]. 376 Indeed, the LMM framework SHOULD decrease the amount of latency or 377 amount of packet loss that exists with the core Mobile IPv6. 379 3.5.2 The LMM framework MUST NOT increase the amount of service disruption 380 that already exists with the core Mobile IPv6 specification. 381 Again, the LMM framework SHOULD decrease the amount of service 382 disruption that already exists with the core Mobile IPv6. 384 3.5.3 The LMM framework MUST NOT increase the number of messages between 385 the mobile host and the respective Correspondent Node(s) and Home 386 Agent as is in the core Mobile IPv6 specification. The LMM 387 framework SHOULD decrease the number of messages between the 388 mobile host and the respective Correspondent Node(s) and Home 389 Agent as is in the core Mobile IPv6 specification. 391 3.6 Auto-configuration capabilities for LMM constituents 393 It is desirable that in order to allow for simple incremental 394 deployment of an LMM scheme, the local mobility agents MUST 395 require minimal (if any) manual configuration. This plug-and-play 396 feature could make use of IPv6 auto-configuration mechanisms, even 397 though most likely other automatic configurations will be needed 398 (such as, for example, learning about adjacent LMM agents). 399 Auto-configuration also facilitates the network to dynamically 400 adapt to general topological changes (whether planned or due to 401 link or node failures). 403 3.7 LMM inter-working with IP routing infrastructure requirement 405 The LMM framework MUST NOT disrupt core IP routing outside 406 the local domain. 408 3.8 Sparse routing element population requirement 410 Any LMM protocol MUST be designed to be geared towards 411 incremental deployment capabilities; the latter implies 412 that the LMM scheme itself imposes minimum requirements 413 on the carriers network. Incremental deployment capabilities 414 for an LMM protocol signifies that an initial set of sparse 415 LMM agents can populate the administration domain of a network 416 provider and operate sufficiently. In addition, any LMM 417 scheme MUST be compatible with any additional deployment 418 of LMM agents in future infrastructure expansions; that is to 419 say, allow progressive LMM deployment capabilities. 421 It is for this reason that the LMM framework MUST NOT require 422 that all routing elements be assumed to be LMM-aware in the 423 signaling interactions of an LMM protocol. The LMM framework 424 MUST BE supported, at the very minimum, by a sparse (proper 425 subset) LMM agent population that is co-located within the 426 routing topology of a single administration domain. 428 INTERNET Draft Localized Mobility Management Requirements March 2002 430 3.9 Support for Mobile IPv6 Handover 432 Since one of the primary goals of LMM is to minimize 433 signaling during handover, an LMM solution MUST be 434 available for the standardized Mobile IPv6 handover 435 algorithms. LMM and the Mobile IPv6 handover algorithms 436 MUST maintain compatibility in their signaling interactions 437 for fulfilling complementary roles with respect to each 438 other. 440 This requirement SHOULD NOT be interpreted as ruling out 441 useful optimizations of LMM and Mobile IPv6 handoff schemes 442 that simplify the implementation or deployment of LMM or Mobile 443 IPv6 handoff. 445 3.10 Simple Network design requirement 447 LMM SHOULD simplify the network design and provisioning for enabling LMM 448 capability in a network and allow progressive LMM deployment capabilities. 450 3.11 Location privacy and tracking support 452 The LMM framework MUST allow for location privacy for the MN. The 453 LMM framework MAY provide efficient and scalable location tracking 454 on behalf of a MN. 456 3.12 Stability 458 LMM MUST avoid any routing loops. 460 3.13 Quality of Service requirements 462 3.13.1 The LMM MUST have the ability to interwork with the 463 QoS schemes to hide the mobility of the MN to its peer 464 by avoiding end-to-end QoS signaling. 466 3.13.2 The LMM MUST have the ability to interwork with the QoS 467 schemes to facilitate the new provisioning of both uplink 468 and downlink QoS after a handoff. 470 4.0 Acknowledgments 472 Thank you to all who participated in the LMM requirement discussion 473 on the Mobile IP working group alias. First, I want to recognize 474 Theo Pagtzis's (University College London) work on LMM requirement 475 analysis. Theo has contributed significantly to the LMM discussion 476 on the mailing list and at IETF working group meetings and has 477 provided text for various requirements and the text for the 478 introduction detailing motivation and basic LMM principles. Theo's 479 work on requirement analysis will be published soon (see [1] below). 480 Special thanks also to John Loughney (Nokia), Alper Yegin 481 (DoCoMo USA Labs) and Madjid Nakhjiri (Motorola) for providing input 482 to the draft in its preliminary stage. As editor of the draft a small 483 team was put together to work with me on LMM requirement analysis: 484 Hesham Soliman (Ericsson), Erik Nordmark (Sun), Theo Pagtzis (UCL), 485 James Kempf (DoCoMo USA Labs), and Jari Malinen (Nokia). 487 Many other working group members have participated in the requirement 488 analysis of LMM for IPv6. This included writing requirements listed 489 in this document as well as providing insight into requirement 490 analysis. This made my job as editor of this document quite easy. 491 Members who contributed are: 492 Charlie Perkins (Nokia), Theo Pagtzis (University College London), 493 Muhammad Jaseemuddin (Nortel), Tom Weckstr (Helsinki University), 494 Jim Bound (Compaq), Erik Nordmark (Sun), James Kempf (DoCoMo USA Labs), 495 Gopal Dommety (Cisco), Glenn Morrow (Nortel), Arthur Ross (IEEE), 496 Samita Chakrabarti (Sun), Hesham Soliman (Ericsson), 498 Karim El-Malki (Ericsson), Phil Neumiller (Telocity), Behcet Sarikaya 499 (Alcatel), Karann Chew (University of Surrey), Michael Thomas (Cisco), 500 Pat Calhoun (Black Storm Networking), Bill Gage (Nortel Networks), 501 Vinod Choyi (Alcatel), John Loughney (Nokia), Wolfgang Schoenfeld 502 (GMD IPSI), and David Martin (Nextel). Recent comments received 503 by Atsushi Takeshita (DoCoMo USA Labs), Daichi Funato (DoCoMo USA 504 Labs), Youngjune Gwon (DoCoMo USA Labs), Ichiro Okajima (NTT DoCoMo), 505 Jari Malinen (Nokia), and Koshimi Takashi (NTT DoCoMo). Thanks to 506 Cedric Westphal (Nokia) for a thorough reviewing of the draft. 508 In addition special thanks to the Mobile IP working group chairs 509 for their input as well as capturing and organizing the initial set 510 of requirements from the discussions, Phil Roberts (Magisto) and 511 Basavaraj Patil (Nokia). 513 5.0 References 515 [1] Theo Pagtzis, "Requirements for Localized Mobility 516 Management in IPv6 Networks"; Paper in Submission; 517 Work In Progress, November 2001. 519 [2] Manner, J. et al; "Mobility Related Terminology"; 520 draft-manner-seamoby-terms-02.txt; Work In 521 Progress; July 2001. 523 [3] J.J. Tardo and K. Alagappan, "SPX: Global Authentication 524 Using Public Key Certificates." In Proc IEEE Symp. 525 Research in Security and Privacy. IEEE CS Press, 1991. 527 [4] Roberts, P., "Local Subnet Mobility Problem Statement"; 528 draft-proberts-local-subnet-mobility-problem-01.txt; 529 Work In Progress; May 2001. 531 [5] Perkins, C., "IP Mobility Support". IETF, 532 Request for Comments (RFC) 2002, October 1996. 534 [6] David B. Johnson, Charles Perkins, "Mobility Support 535 in IPv6"; draft-ietf-mobileip-ipv6-14.txt; July 2001. 537 [7] Tsirtsis, G. (Editor), "Fast Handovers for Mobile 538 IPv6"; draft-ietf-mobileip-fast-mipv6-00.txt; a work 539 in progress; February 2001. 541 [8] Loughney, J. (Editor), "SeaMoby Micro Mobility Problem 542 Statement"; draft-ietf-seamoby-mm-problem-01.txt; a work 543 in progress; February 2001. 545 6.0 Authors' Addresses 547 The working group can be contacted via the current chairs: 549 Basavaraj Patil Phil Roberts 550 Nokia Corporation Megisto Systems 551 6000 Connection Drive 20251 Century Blvd 552 Irving, TX 75039 Suite 120 553 USA Germantown Maryland, 20874-1191 555 Phone: +1 972-894-6709 EMail: proberts@megisto.com 556 EMail: Raj.Patil@nokia.com 557 Fax : +1 972-894-5349 559 Questions about this memo can also be directed to: 561 Carl Williams 562 DoCoMo Communications Laboratories USA, Inc. 563 181 Metro Drive, Suite 300 564 San Jose, CA 95110 565 USA 566 phone: +1 408 451 4741 567 fax: +1 408 573 1090 568 email: carlw@docomolabs-usa.com 570 7.0 Full Copyright Statement 572 Copyright (C) The Internet Society (2000). All Rights Reserved. 574 This document and translations of it may be copied and furnished to 575 others, and derivative works that comment on or otherwise explain it 576 or assist in its implementation may be prepared, copied, published 577 and distributed, in whole or in part, without restriction of any 578 kind, provided that the above copyright notice and this paragraph 579 are included on all such copies and derivative works. However, this 580 document itself may not be modified in any way, such as by removing 581 the copyright notice or references to the Internet Society or other 582 Internet organizations, except as needed for the purpose of 583 developing Internet standards in which case the procedures for 584 copyrights defined in the Internet Standards process must be 585 followed, or as required to translate it into languages other than 586 English. 588 The limited permissions granted above are perpetual and will not be 589 revoked by the Internet Society or its successors or assigns. 590 This document and the information contained herein is provided on an 591 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 592 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 593 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 594 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 595 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.