idnits 2.17.1 draft-ietf-mobileip-lmm-requirements-00.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 == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 13) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 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 25 instances of too long lines in the document, the longest one being 6 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 239: '...istration domain MUST always be able t...' RFC 2119 keyword, line 250: '...2.1 LMM protocol MUST provide for "sec...' RFC 2119 keyword, line 253: '...pecific information and signaling MUST...' RFC 2119 keyword, line 257: '... protection MUST exist mutually betw...' RFC 2119 keyword, line 259: '...2.2 LMM protocol MUST provide for the ...' (54 more instances...) 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 (November 7, 2001) is 8203 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 579, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 589, 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 (~~), 9 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: November 7, 2001 5 Expires: May 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 listed are essential for 44 localized mobility management functionality. They are intended to 45 be used as 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 .................................................... 4 53 3.1 Intra-domain mobility ........................................ 5 54 3.2 Security ..................................................... 6 55 3.3 Induced LMM functional requirement ........................... 6 56 3.4 Scalability and Performance .................................. 7 57 3.5 Mobility Management Support .................................. 9 58 3.6 Auto-configuration capabilities for LMM constituents.......... 9 59 3.7 Interworking with IP routing infrastructure requirement....... 10 60 3.8 Sparse routing element population requirement ................ 10 61 3.9 Support of fast handoffs in LMMs ............................. 10 62 3.10 Simple network design requirement ........................... 11 63 3.11 Location privacy and tracking support ....................... 11 64 3.12 Reliability ................................................. 11 65 3.13 Stability ................................................... 11 66 3.14 Quality ..................................................... 11 67 4.0 Acknowledgments ................................................. 11 68 5.0 References ...................................................... 12 69 6.0 Author's Addresses .............................................. 13 70 7.0 Full Copyright Statement ........................................ 13 72 1.0 Introduction 74 In order to meet the demands of real-time applications and the 75 expectations of future wireless users for service level quality 76 similar to the one of wireline users, base mobility management in 77 IP networks, and in particular Mobile IPv6 is presented with 78 a number of technical challenges in terms of performance and 79 scalability. These manifest themselves as increased latencies in 80 the control signaling between a Mobile Node and its peer entities, 81 namely the Home Agent (HA) and its Corresponding Nodes (CNs). 83 1.1 Motivation 85 It is well-established that real-time applications impose stringent 86 requirements in terms of delay and packet loss. [1] From an IP 87 mobility perspective any induced latency would cause these 88 applications to experience noticeable degradation in quality as the 89 mobile user transits within the same or over different internet 90 (ISPs) or context (CSPs) service providers. This is further 91 exacerbated as the rate of transition of the MN (handoff) increases, 92 between different such service or content providers manifested in 93 form of provisioning (domains). 95 When a MN transits from its home domain to a foreign one, it 96 is required to provide its Home Agent with its current mobility 97 bindings that yields a reachable destination on the visiting domain. 98 The MN must send an inter-domain Binding Update signal to notify 99 both it's HA and it's communicating CN(s) about its movement that 100 has caused attachment to a new Access Router (AR). For large 101 round-trip times (RTT) between the MN and it?s HA or CNs (in the 102 order of 300-500 ms), the mobility management signaling is bound 103 to introduce delays as well as potential packet loss in the 104 forwarding of traffic through the HA tunnel (triangular routing) 105 or through direct communication between the MN and the CN. 107 Furthermore, for a high rate of handoff, the mobility binding 108 update of the MN is soon to be rendered invalid; that will 109 require new mobility bindings (BUs) to be generated at a much 110 higher frequency by the MN and thus result in a signaling 111 overhead for its peer communicating entities; this is bounded 112 by the RTT between the MN and its peers (HA and CNs). [1] 114 1.2 Principles of LMM 116 To alleviate the above mentioned mobility issues, extensions to 117 the Mobile IPv6 protocol are proposed to minimize or at best, 118 eliminate frequent mobility management signaling (BUs) to its 119 HA and its peer CNs, caused by frequent change of care-of address. 120 In contrast to base Mobile IPv6 signaling, LMM ensures that 121 the MN refrains from propagating frequently its mobility binding 122 all the way back to its home domain or its CNs. This is achieved 123 by introducing Localized Mobility Management Agents (LMM agents) 124 into the visited domain with functionality similar to a HA. Thus, 125 control messages are either localized (regional) or global signals. 126 Localized signals are those that are bound within a single 127 administrative domain and generally targeted towards the LMM agent(s) 128 whereas global signals are those that are communicated across 129 different administrative domains with their destination the true 130 peers of the MN. With the introduction of regional control messages 131 the signaling load of the MNs corresponding HA and CNs is reduced 132 as long as the MN stays within the administrative domain. [1] 134 As it has been pointed out, the main issues behind LMMs is to 135 eliminate frequent Binding Updates to both HA and CN entities. 136 This is done introducing a level of indirection by assigning 137 two care-of addresses to each MN: one on-link care-of address 138 (LCoA), and one regional care-of address (RCoA). The change of 139 the on-link CoA is visible (mobility-local) only within the visited 140 domain for the purpose of mobility. The regional care-of (RCoA) 141 address is visible to those peer entities outside the local 142 domain (mobility-global) and it changes when the MN moves between 143 different administrative domains. 145 1.3 Consideration points for LMM design 147 Having provided some motivation and brief summary of the underlying 148 principals of LMM, it is important to enumerate consideration 149 points (goals) when designing an LMM framework. 151 Consideration points for LMM Design: 153 - reducing the signaling induced by changes in the 154 point of attachment due to the movement of a host; 155 this is the fundamental reason for introducing 156 localized mobility management extensions to core 157 Mobile IPv6. 159 - provide a mechanism whereby the mobile nodes 160 location is hidden from observers outside the 161 administration domain. 163 - reducing the usage of air-interface and network 164 resources for mobility; 166 - avoid or minimize the changes of, or impact to the 167 Mobile Node, Home Agent or the Correspondent Node; 169 - avoid creating single points of failure; 171 - simplify the network design and provisioning 172 for enabling LMM capability in a network; 174 - allow progressive LMM deployment capabilities. 176 Identifying a solid set of requirements that will render the 177 protocol internals, for some LMM scheme, robust enough to 178 cater for the aforementioned considerations becomes essential 179 in designing a widely accepted solution. The remainder of this 180 document present a set of requirements that encompass essential 181 considerations for the design of an LMM scheme. It is with this 182 foundation that we can seek to ensure that the resulting LMM 183 solution will best preserve the fundamental philosophies and 184 architectural principles of the Internet in practice today. 186 2.0 Terminology 188 See [2] for additional terminology. 190 Administrative Domain A collection of networks under the same 191 administrative control and grouped together 192 for administrative purposes. [2] 194 Local Mobility The movement of an IP device without requiring 195 a change to its routable IP address seen by 196 the CN or HA. Although its point of attachment 197 may change during the move, the IP addresses used 198 to reach the device (both its home and globally 199 visible routable IP address) do not change. 201 Local Mobility Agent A Mobile Node uses Local Mobility Agent as 202 (LMA) a local Home Agent while roaming within a Local 203 Mobility Domain. The LMA proxy Regional CoA, 204 receives all packets on behalf of the Mobile 205 Node and will encapsulate and forward them 206 directly to its current address. 208 Local Mobility Domain A Local Mobility Domain contains one or more 209 IP subnets, networks, or Administrative 210 Domains. Within the Local Mobility Domain, 211 the globally visible routable IP address assigned 212 to a Mobile Host or Mobile Router serving a Mobile 213 Network does not change. 215 Localized Mobility A method of moving an IP device without requiring 216 Management (LMM) a change to its routable IP address seen by the 217 true peers entities, namely the MN's HA and it?s CNs, 218 in order to restrict the signaling area, thus 219 possibly reducing the amount of signaling. 221 Strong Authentication Techniques that permit entities to provide 222 evidence that they know a particular secret 223 without revealing the secret. [3] 225 3.0 LMM Requirements 227 This section describes the requirements of a LMM solution for 228 Mobile IPv6. Only Mobile IPv6 based requirements are described here. 230 3.1 Intra-domain mobility 232 LMM is introduced to minimize the signaling traffic to the Home Agent 233 and/or Correspondent Node(s) for intra-domain mobility (within an 234 Administrative Domain). This is the fundamental reason for 235 introducing localized mobility management extensions to core Mobile 236 IPv6. 238 In the LMM infrastructure a Correspondent Node or Home Agent outside 239 the administration domain MUST always be able to address the mobile 240 host by the same IP address, so that from the point of view of hosts 241 outside the administration domain, the IP address of the mobile host 242 remains fixed regardless of any changes in the Mobile Node's subnet. 244 It is not the intent or goal for LMM to enter the intra-subnet 245 (intra AR) mobility problem space. See [4] for more information 246 on this specific problem space. 248 3.2 Security 250 3.2.1 LMM protocol MUST provide for "security provisioning" within the 251 respective administration domain. 253 The security of exchanging LMM specific information and signaling MUST 254 be ensured. Security provisioning includes protecting the integrity, 255 confidentiality, and authenticity of the transfer of LMM specific 256 information within the administration domain. If applicable, replay 257 protection MUST exist mutually between the LMM agents. 259 3.2.2 LMM protocol MUST provide for the security provisioning to be 260 disabled. 262 In certain environments the security within the administration domain 263 may not be necessary, or it may be preferred to minimize the LMM protocol 264 overhead. This feature would be used at the network operator's own risk. 266 3.2.3 LMM protocol MUST NOT interfere with the security provisioning that 267 exists between the Home Agent and the Mobile Node. 269 3.2.4 LMM protocol MUST NOT interfere with the security provisioning that 270 exists between the Correspondent Node and the Mobile Node. 272 3.2.5 LMM protocol MUST NOT introduce new security holes or the possibility 273 for DOS-style attacks. 275 3.2.6 Any LMM scheme MUST make use of a strong authentication mechanism 276 to avoid a malicious MN from diverting traffic destined to a 277 legitimate MN. LMM SHOULD also ensure that the network be able 278 to maintain topological confidentiality from visiting mobile 279 nodes. That is to say that the LMM scheme in use SHOULD NOT 280 reveal the visited network's topology to the Mobile Node. 282 3.3 Induced LMM functional requirements 284 3.3.1 Any Localized Mobility Management protocol MUST NOT inject 285 any additional functionality over base IPv6 Mobility [6] at the 286 Home Agent or any of its peer CNs. It is essential to minimize 287 the involvement of the Mobile Node in routing beyond what is in 288 the basic MIPv6 protocol. Preferences, load balancing, and other 289 complex schemes requiring heavy mobile node involvement 290 in the mobility management task SHOULD BE avoided; this is 291 so since, experience with IP networks has shown that routing 292 decisions are best left to routers for the purpose of low 293 latency and fast convergence. 295 3.3.2 Any Localized Mobility Management protocol MUST assure that 296 that LMM routing state scales linearly with the number of 297 Mobile Nodes registered, and that the increase in routing 298 state is confined to those ARs/ANRs involved in implementing 299 the LMM protocol at hand. This would involve MIP-specific 300 routing state as binding caches in addition to standard 301 routing table host routes. While host routes cannot be 302 eliminated by any mobility management protocol including 303 base IP mobility, any LMM protocol MUST keep the number of 304 host routes to a minimum. 306 3.3.3 The LMM framework MUST NOT add any modifications or extensions 307 to the Correspondent Node(s) and Home Agent. Any LMM solution 308 MUST minimize any modifications or impact on the Mobile Node. 310 3.3.4 Non-LMM-aware routers, hosts, Home Agents, and Mobile Nodes 311 MUST be able to interoperate with LMM agents. 313 3.3.5 The LMM framework MUST NOT increase the number of messages between 314 the mobile host and the respective Correspondent Node(s) and Home 315 Agent. Indeed, the LMM framework MUST minimize the global 316 signaling between the MN and its true peer entities. The amount 317 of regional signaling MUST NOT surpass the amount of global 318 signaling that would have otherwise occurred if LMM were not 319 present. 321 3.4 Scalability and Performance 323 3.4.1 Scalability guarantees to support millions of nodes for 324 an administrative domain 326 The LMM framework MUST scale linearly with the increase in 327 the number of MNs. It is important for an LMM protocol to 328 scale over a constantly expanding infrastructure that is 329 expected to support millions of MNs. It is important to 330 avoid high concentration of Mobile Nodes under a single 331 LMM-aware routing entity since this would no doubt create 332 extraneous load for the individual LMM-aware router entity 333 (which could potentially increase significantly the probability 334 of failure). The LMM framework MUST support distribution 335 of the LMM functionality in the visited domain in order not to 336 concentrate all operations into one point and also to help 337 achieve linear scalability, whenever the topology of routing 338 entities physically makes such distribution possible. The 339 LMM agent functionality to distribute should include 340 signaling as well as transport. 342 3.4.2 The LMM framework MUST NOT create single points of failure in 343 the network. The current access router would be excluded from 344 this requirement. 346 3.4.3 The LMM framework MUST NOT interfere with the Mobile IPv6 347 performance of a mobile host communications with a Correspondent 348 Node(s). 350 3.4.4 Scalable expansion of the network 352 The LMM framework MUST allow for scalable expansion of the network 353 and provide for reasonable network configuration with regard 354 to peering, inter-administrative domain connectivity, and other 355 inter-administrative domain interoperability characteristics of 356 interest to wireless ISPs. The LMM framework MUST NOT introduce 357 any additional restrictions in how wireless ISPs configure their 358 network, nor how they interconnect with other networks beyond 359 those introduced by standard IP routing. In addition, the 360 amount of regional signaling MUST NOT increase as the Local 361 Domain expands in size. 363 3.4.5 Resilience to topological changes 365 The LMM protocols MUST be topology-independent. The LMM protocols 366 MUST be able to adapt to topological changes within the domain. The 367 topological changes may include the addition or removal/failure of 368 LMM agents or that of changes effected in the routing of the domain 369 over which the LMM scheme is applied. 371 3.4.6 Header or Tunneling overhead 373 Any additional header or tunneling overhead caused by LMM MUST 374 be reduced on the radio link by compression and transfer of 375 compressor state on movement SHOULD be possible so as not to 376 introduce any perceived service disruption. 378 Candidate LMM designs that require additional header overhead for 379 tunnels MUST be reviewed by the ROHC working group to determine 380 if the header compressor can be restarted from transferred compressor 381 context when handover occurs without requiring any full header packet 382 exchange on the new link. 384 3.4.7 Optimized signaling within the administrative domain 386 By its very nature, LMM reintroduces triangle routing into Mobile IPv6 387 in that all traffic must go through the LMM agent. There is no way 388 to avoid this. The LMM framework SHOULD be designed in such a way 389 as to reduce the length of the unwanted triangle leg. 391 The LMM framework SHOULD support optimal placement of LMM agents to 392 reduce or eliminate additional triangle routing introduced by LMM. 394 3.5 Mobility Management Support 396 The following LMM requirements pertain to both inter-domain and 397 intra-domain hand-off. 399 3.5.1 The LMM framework MUST NOT increase the amount of latency or amount of 400 packet loss that exists with the core Mobile IPv6 specification [6]. 402 3.5.2 The LMM framework MUST NOT increase the amount of service disruption 403 that already exists with the core Mobile IPv6 specification. 405 3.5.3 The LMM framework MUST NOT increase the number of messages between 406 the mobile host and the respective Correspondent Node(s) and Home 407 Agent as is in the core Mobile IPv6 specification. 409 3.5.4 Movement detection 411 Any LMM mechanism MUST contain or make use of a mechanism that provides 412 movement detection between separate visited domains. This mechanism 413 MUST provide a globally unique identity of a visited domain. The 414 reason for this requirement is that when performing LMM, there exists 415 a need for a domain movement detection for the mechanism to work in 416 the first place. This could be a non-LMM mechanism, such as 417 AAA-based. It is clear that movement detection is needed for basic 418 features to work and in order for that to happen there must exist 419 some kind of domain identity to be recognizable. A protocol should 420 have some minimal common denominator for essential functions like 421 movement detection in case there is no other fallback available. 422 If that is AAA, we should recognize it becomes mandatory for this 423 default to be around. This requirement also will weigh how 424 self-contained the LMM protocol is. 426 3.6 Auto-configuration capabilities for LMM constituents 428 It is desirable that in order to allow for simple incremental 429 deployment of an LMM scheme, the local mobility agents MUST 430 require minimal (if any) manual configuration. This plug-and-play 431 feature could make use of IPv6 auto-configuration mechanisms, even 432 though most likely other automatic configurations will be needed 433 (such as, for example, learning about adjacent LMM agents). 434 Auto-configuration also facilitates the network to dynamically 435 adapt to general topological changes (whether planned or due to 436 link or node failures). 438 INTERNET Draft Localized Mobility Management Requirements November 2001 440 3.7 LMM inter-working with IP routing infrastructure requirement 442 The LMM framework MUST NOT disrupt core IP routing anywhere 443 in the network. LMM and IP routing MUST work hand-in-hand. 445 3.8 Sparse routing element population requirement 447 Any LMM protocol MUST be designed to be geared towards 448 incremental deployment capabilities; the latter implies 449 that the LMM scheme itself imposes minimum requirements 450 on the carriers network. Incremental deployment capabilities 451 for an LMM protocol signifies that an initial set of sparse 453 LMM agents can populate the administration domain of a network 454 provider and operate sufficiently. In addition, any LMM 455 scheme MUST be compatible with any additional deployment 456 of LMM agents in future infrastructural expansions; that is to 457 say, allow progressive LMM deployment capabilities. 459 It is for this reason that the LMM framework MUST NOT require 460 that all routing elements be assumed to be LMM-aware in the 461 signaling interactions of an LMM protocol. The LMM framework 462 MUST BE supported, at the very minimum, by a sparse (proper 463 subset) LMM agent population that is co-located within the 464 routing topology of a single administration domain. 466 To avoid concentration of MN's around individual LMM-agents 467 during their mobility pattern within a domain, an LMM scheme 468 MUST be able to distribute the MN population over a number 469 of available LMM agents that populate the administrative 470 domain. 472 3.9 Support of Fast handoffs in LMMs 474 Mobility extensions have been proposed to quickly enable IP 475 connectivity of the MN at a new point of attachment; these 476 extensions are known as Fast Handoffs for Mobile IP(v6). [7] 478 These enhancements are intended to minimize handoff latency 479 and reduce packet loss. LMM and FMIP protocols MUST BE able 480 to be deployed independently of each other. However, when 481 the two classes of protocols co-exist, LMM and FMIP MUST 482 maintain compatibility in their signaling interactions for 483 fulfilling complementary roles with respect to each other. 485 3.10 Simple Network design requirement 487 LMM SHOULD simplify the network design and provisioning for enabling LMM 488 capability in a network and allow progressive LMM deployment capabilities. 490 3.11 Location privacy and tracking support 492 The LMM framework MUST allow for location privacy for the MN. The 493 LMM framework MAY provide efficient and scalable location tracking 494 on behalf of a MN. 496 3.12 Reliability 498 3.12.1 LMM framework MUST include recovery from failure of LMM agents. 500 3.12.2 LMM framework MUST include mechanisms for inclusion of the 501 indication of failure of LMM agents. 503 3.12.3 Connectivity to the Mobile Node MUST always be maintained in the 504 presence of failure of LMM agents (infrastructure). 506 3.13 Stability 508 LMM MUST avoid any routing loops. 510 3.14 Quality 512 3.14.1 LMM MUST minimize packet reordering. Continuous packet reordering 513 which makes the receiver's TCP generates duplicate acks causes 514 unnecessary packet retransmissions. 516 3.14.2 LMM MUST minimize packet duplication. Duplicated packets 517 consume scarce wireless link capacity. 519 4.0 Acknowledgments 521 Thank you to all who participated in the LMM requirement discussion 522 on the Mobile IP working group alias. First, I want to recognize 523 Theo Pagtzis's (University College London) work on LMM requirement 524 analysis. Theo has contributed significantly to the LMM discussion 525 on the mailing list and at IETF working group meetings and has 526 provided text for various requirements and the text for the 527 introduction detailing motivation and basic LMM principals. Theo's 528 work on requirement analysis will be published soon (see [1] below). 529 Special thanks also to John Loughney (Nokia), Alper Yegin 530 (DoCoMo USA Labs) and Madjid Nakhjiri (Motorola) for providing input 531 to the draft in its preliminary stage. As editor of the draft a small 532 team was put together to work with me on LMM requirement analysis: 533 Hesham Soliman (Ericsson), Erik Nordmark (Sun), Theo Pagtzis (UCL), 534 James Kempf (DoCoMo USA Labs), and Jari Malinen (Nokia). 536 Many other working group members have participated in the requirement 537 analysis of LMM for IPv6. This included writing requirements listed 538 in this document as well as providing insight into requirement 539 analysis. This made my job as editor of this document quite easy. 540 Members who contributed are: 541 Charlie Perkins (Nokia), Theo Pagtzis (University College London), 542 Muhammad Jaseemuddin (Nortel), Tom Weckstr (Helsinki University), 543 Jim Bound (Compaq), Erik Nordmark (Sun), James Kempf (DoCoMo USA Labs), 544 Gopal Dommety (Cisco), Glenn Morrow (Nortel), Arthur Ross (IEEE), 545 Samita Chakrabarti (Sun), Hesham Soliman (Ericsson), 547 Karim El-Malki (Ericsson), Phil Neumiller (Telocity), Behcet Sarikaya 548 (Alcatel), Karann Chew (University of Surrey), Michael Thomas (Cisco), 549 Pat Calhoun (Black Storm Networking), Bill Gage (Nortel Networks), 550 Vinod Choyi (Alcatel), John Loughney (Nokia), Wolfgang Schoenfeld 551 (GMD IPSI), and David Martin (Nextel). Recent comments received 552 by Atsushi Takeshita (DoCoMo USA Labs), Daichi Funato (DoCoMo USA 553 Labs), Youngjune Gwon (DoCoMo USA Labs), Ichiro Okajima (NTT DoCoMo), 554 Jari Malinen (Nokia), and Koshimi Takashi (NTT DoCoMo). 556 In addition special thanks to the Mobile IP working group chairs 557 for their input as well as capturing and organizing the initial set 558 of requirements from the discussions, Phil Roberts (Magisto) and 559 Basavaraj Patil (Nokia). 561 5.0 References 563 [1] Theo Pagtzis, "Requirements for Localised Mobility 564 Management in IPv6 Networks"; Paper in Submission; 565 Work In Progress, November 2001. 567 [2] Manner, J. et al; "Mobility Related Terminology"; 568 draft-manner-seamoby-terms-02.txt; Work In 569 Progress; July 2001. 571 [3] J.J. Tardo and K. Alagappan, ?SPX: Global Authentication 572 Using Public Key Certificates.? In Proc IEEE Symp. 573 Research in Security and Privacy. IEEE CS Press, 1991. 575 [4] Roberts, P., "Local Subnet Mobility Problem Statement"; 576 draft-proberts-local-subnet-mobility-problem-01.txt; 577 Work In Progress; May 2001. 579 [5] Perkins, C., "IP Mobility Support". IETF, 580 Request for Comments (RFC) 2002, October 1996. 582 [6] David B. Johnson, Charles Perkins, "Mobility Support 583 in IPv6"; draft-ietf-mobileip-ipv6-14.txt; July 2001. 585 [7] Tsirtsis, G. (Editor), "Fast Handovers for Mobile 586 IPv6"; draft-ietf-mobileip-fast-mipv6-00.txt; a work 587 in progress; February 2001. 589 [8] Loughney, J. (Editor), "SeaMoby Micro Mobility Problem 590 Statement"; draft-ietf-seamoby-mm-problem-01.txt; a work 591 in progress; February 2001. 593 6.0 Authors' Addresses 595 The working group can be contacted via the current chairs: 597 Basavaraj Patil Phil Roberts 598 Nokia Corporation Megisto Systems 599 6000 Connection Drive 20251 Century Blvd 600 Irving, TX 75039 Suite 120 601 USA Germantown Maryland, 20874-1191 603 Phone: +1 972-894-6709 EMail: proberts@megisto.com 604 EMail: Raj.Patil@nokia.com 605 Fax : +1 972-894-5349 607 Questions about this memo can also be directed to: 609 Carl Williams 610 DoCoMo Communications Laboratories USA, Inc. 611 181 Metro Drive, Suite 300 612 San Jose, CA 95110 613 USA 614 phone: +1 408 451 4741 615 fax: +1 408 573 1090 616 email: carlw@docomolabs-usa.com 618 7.0 Full Copyright Statement 620 Copyright (C) The Internet Society (2000). All Rights Reserved. 622 This document and translations of it may be copied and furnished to 623 others, and derivative works that comment on or otherwise explain it 624 or assist in its implementation may be prepared, copied, published 625 and distributed, in whole or in part, without restriction of any 626 kind, provided that the above copyright notice and this paragraph 627 are included on all such copies and derivative works. However, this 628 document itself may not be modified in any way, such as by removing 629 the copyright notice or references to the Internet Society or other 630 Internet organizations, except as needed for the purpose of 631 developing Internet standards in which case the procedures for 632 copyrights defined in the Internet Standards process must be 633 followed, or as required to translate it into languages other than 634 English. 636 The limited permissions granted above are perpetual and will not be 637 revoked by the Internet Society or its successors or assigns. 638 This document and the information contained herein is provided on an 639 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 640 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 641 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 642 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 643 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.