idnits 2.17.1 draft-ernst-monet-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There is 1 instance 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. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3.13. Security' ) ** 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 abstract seems to contain references ([Castelluccia97], [Castelluccia98], [Caceres96], [Myles93], [WEB-MONET], [TERMINOLOGY], [Bhagwat96], [RFC2460], [Ernst01], [MOBRTR], [MIPv6], [OLD-draft], [RFC1122], [MONET-PSBU], [HMIPv6], [SCOPE]), 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 158: '...hat requirements MUST or SHOULD be ful...' RFC 2119 keyword, line 173: '...mobility support MUST provide permanen...' RFC 2119 keyword, line 175: '...ns that all MNNs MUST always be reacha...' RFC 2119 keyword, line 180: '...he network layer MUST be able of suppo...' RFC 2119 keyword, line 186: '...mobility support SHOULD exhibit low la...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: Handover of IP sessions is performed at the network layer. With respect to the layer separation of the Internet protocol suite, handover MUST be managed at the network layer only and transparently to upper layers, despite the migration of the MONET in the network topology. Therefore, a change of topological location MUST not have an impact on layers above the network layer other than a transient loss of performance, as depicted in the above paragraph. If this is respected, compatibility with existing transport and application layers is maintained. In practice, the identifiers used at the transport layer should be independent from the physical IP addresses used at the network layer for routing. If upper layer protocols require a location independent and invariant identifier, the network layer MUST provide it with an identifier irrespective of the actual topological location. == 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: Network mobility support is constrained by backward compatibility with existing and forthcoming IPv6 standards. As such, it MUST not prevent MNNs to operate any standardized protocol. This particularly includes but is not limited to Mobile IPv6 (host mobility) and IGMP (multicast group membership): == 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: o Host Mobility Support Constraints: host mobility support in IPv6 is achieved by Mobile IPv6 which is a compulsory component of any IPv6 implementation. This means that network mobility support MUST not prevent LMNs and VMNs from operating Mobile IPv6 once located in a MONET. == 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: o Multicast Constraints: any IPv6 router is supposed to allow hosts on its attached subnetworks to participate in multicast sessions. Group membership is gathered by the IGMP protocol. Network mobility support MUST not prevent this. -- 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 (February 2002) is 8106 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? 'TERMINOLOGY' on line 502 looks like a reference -- Missing reference section? 'SCOPE' on line 499 looks like a reference -- Missing reference section? 'Ernst01' on line 462 looks like a reference -- Missing reference section? 'OLD-draft' on line 480 looks like a reference -- Missing reference section? 'WEB-MONET' on line 506 looks like a reference -- Missing reference section? 'RFC2460' on line 495 looks like a reference -- Missing reference section? 'MONET-PSBU' on line 486 looks like a reference -- Missing reference section? 'HMIPv6' on line 465 looks like a reference -- Missing reference section? 'MOBRTR' on line 472 looks like a reference -- Missing reference section? 'Bhagwat96' on line 447 looks like a reference -- Missing reference section? 'Myles93' on line 476 looks like a reference -- Missing reference section? 'Castelluccia97' on line 162 looks like a reference -- Missing reference section? 'Caceres96' on line 451 looks like a reference -- Missing reference section? 'MIPv6' on line 469 looks like a reference -- Missing reference section? 'Castelluccia98' on line 457 looks like a reference -- Missing reference section? 'RFC1122' on line 491 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF INTERNET-DRAFT Thierry Ernst 3 WIDE Project / INRIA 4 Hong-Yon Lach 5 Motorola Labs 6 February 2002 8 "Network Mobility Support Requirements" 9 draft-ernst-monet-requirements-00.txt 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 RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 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 The purpose of traditional mobility support is to provide continuous 34 Internet connectivity to mobile hosts (host mobility support). In 35 contrast, network mobility support is concerned with situations where 36 an entire network changes its point of attachment to the Internet and 37 thus its reachability in the topology. We shall refer to such a 38 network as a mobile network (MONET). This document tries to identify 39 what constraints limit the implementation and the deployment of a 40 potentially and ideally good solution, and what requirements 41 solutions must comply to. Our main aim is to raise the discussion on 42 the mailing list. 44 Contents 46 Status of This Memo 48 Abstract 50 1. Introduction 51 2. Important Disclaimer 52 3. Design Requirements 53 3.1. Migration Transparency (Permanent Connectivity) 54 3.2. Operational Transparency 55 3.3. Performance Transparency (Seamless Mobility) 56 3.4. Layers Independence 57 3.5. Mobility Management Transparency for MNNs 58 3.6. Scalability 59 3.7. Minimum Signaling Overload 60 3.8. Routing Optimization in 6 3.9. Nested Mobility 61 3.10. Backward Compatibility 62 3.11. Minimum Impact on Existing Protocols and Infrastructure 63 3.12. No impact on CNs or Internet routing 64 3.13. Security 65 3.13.1. Confidentiality 66 3.13.2. Authentication 67 3.13.3. Authorization 68 3.13.4. Location Privacy 69 3.14. Access Control 70 3.14.1. Access Control for VMNs 71 3.14.2. Access Control Architecture 72 3.14.3. Access Control in the Fixed Network 73 3.15. Wide-Area Mobility 74 3.16. Unified Solution 75 3.17. Mobile CNs 76 3.18. Addressing Constraints 78 Acknowledgments 80 References 82 Author's Addresses 83 1. Introduction 85 This document assumes that the reader is familiar with the 86 terminology defined in [TERMINOLOGY] while reading [SCOPE] for a 87 description of the problems is recommended. 89 The purpose of traditional mobility support is to provide continuous 90 Internet connectivity to mobile hosts (host mobility support). In 91 contrast, network mobility support is concerned with situations where 92 an entire network changes its point of attachment to the Internet and 93 thus its reachability in the topology. We shall refer to such a 94 network as a mobile network (MONET). Cases of mobile networks include 95 networks attached to people (Personal Area Networks or PAN), and 96 networks of sensors deployed in aircrafts, boats, busses, cars, 97 train, etc that need a permanent Internet connection. Those mobile 98 networks may also provide Internet access to devices carried by 99 people (laptop, camera, mobile phone, etc, and PAN). 101 As exhibited by the scenarios depicted in [TERMINOLOGY] and [SCOPE], 102 there is a desire to achieve two levels of mobility: node mobility 103 and network mobility. A passenger is a mobile node which visits a 104 mobile network (VMN in a MONET), and passengers may themselves be 105 mobile IP-subnets (MONET in a MONET), for example when carrying a 106 PAN. Since people move from a MONET to another, and since instances 107 of MONETs like trains, car, aircrafts cross country boundaries, both 108 VMNs and MONETs are also most likely to cross ISP boundaries and 109 therefore to move between topologically distant parts of the 110 Internet. This means we must allow VMNs belonging to potentially 111 different administrative domains to visit the MONET. The instances 112 highlighted above also justify the need to consider potentially large 113 MONETs containing hundreds of hosts and several routers. The train 114 example highlights that the number of correspondent nodes could also 115 be very large, and that these may be sparsely distributed in the 116 Internet. It also justifies the need for true worldwide mobility in 117 the Internet. A MONET may attach to very distant parts of the 118 Internet topology, provided it is granted access to it, therefore 119 requiring both Local-Area Mobility support and Wide-Area Mobility 120 support. 122 The problems that need to be addressed are illustrated in [SCOPE] 123 while the purpose of this document is to raise discussion in order to 124 identify what constraints limit the implementation and the deployment 125 of a potentially and ideally good solution, and what requirements 126 solutions must comply to. Most constraints and requirements that we 127 have listed are equally applicable to host mobility support and 128 network mobility support. Some of them have been debated in the 129 literature as far as host mobility support was concerned; we have 130 extended this list to include those related to network mobility 131 support. 133 The material presented in this document is based on [Ernst01] and on 134 our former internet-draft that was submitted in July 2001 [OLD-draft] 135 for the consideration of the Mobile IP Working Group. This former 136 draft was defining the terminology that is now found in [TERMINOLOGY] 137 and a list of requirements and issues as an attempt to clarify the 138 problem caused by networks in motion and now found in this present 139 document. It was also mentioning a number of issues (impact on 140 addressing, routing, and existing network protocols). We have decided 141 to split this former document in two because requirements are more 142 subject to discussion and disagreements that the terminology on which 143 we must agree on to base our discussions. More information may be 144 found on the MONET web page [WEB-MONET]. Note that this list of 145 requirements is primarily targeted to IPv6 [RFC2460], but is not 146 limited to it, and that the already existing network mobility support 147 proposals [MONET-PSBU], [HMIPv6], and [MOBRTR] don't necessarily meet 148 these requirements. 150 2. Important Disclaimer 152 The stated opinions in this draft come from various sources and are 153 not necessarily the opinions of the authors. The purpose of this 154 draft is for open discussions. 156 3. Design Requirements 158 This section details what requirements MUST or SHOULD be fulfilled by 159 solutions, and what constraints may limit the deployment of a 160 potentially good solution. Most requirements discussed for host 161 mobility support, like for instance [Bhagwat96], [Myles93], 162 [Castelluccia97] or [Caceres96], are equally applicable to network 163 mobility support. However, they must be extended and refined to 164 comply with the specific characteristics. All requirements we have 165 listed may not be satisfied by a single solution. For the sake of 166 modularity, we may decide to use separate solutions for different 167 aspects of the problem space. Moreover, some of them are 168 controversial and are subject to discussions on the mailing list 169 [WEB-MONET]. It is assumed that the reader has read [TERMINOLOGY]. 171 3.1. Migration Transparency (Permanent Connectivity) 173 Network mobility support MUST provide permanent and continuous 174 Internet connectivity to all MNNs without disruption of service 175 for MNNs. This means that all MNNs MUST always be reachable 176 regardless of the point of attachment of the MONET. 178 3.2. Operational Transparency 180 The network layer MUST be able of supporting connectivity of the 181 MONET in an absolute transparent manner to the application or the 182 user. 184 3.3. Performance Transparency (Seamless Mobility) 186 Network mobility support SHOULD exhibit low latency, incur little 187 or no data loss, minimum delays, minimum signaling load, and 188 minimum bandwidth consumption for packet delivery. In other words, 189 network mobility support SHOULD be as seamless as host mobility is 190 supported (no abrupt degradation of service). 192 3.4. Layers Independence 194 Handover of IP sessions is performed at the network layer. With 195 respect to the layer separation of the Internet protocol suite, 196 handover MUST be managed at the network layer only and 197 transparently to upper layers, despite the migration of the MONET 198 in the network topology. Therefore, a change of topological 199 location MUST not have an impact on layers above the network layer 200 other than a transient loss of performance, as depicted in the 201 above paragraph. If this is respected, compatibility with existing 202 transport and application layers is maintained. In practice, the 203 identifiers used at the transport layer should be independent from 204 the physical IP addresses used at the network layer for routing. 205 If upper layer protocols require a location independent and 206 invariant identifier, the network layer MUST provide it with an 207 identifier irrespective of the actual topological location. 209 3.5. Mobility Management Transparency for MNNs 211 We have seen in [TERMINOLOGY] that MNNs don't change their own 212 point of attachment as a result of the MONET's displacement in the 213 Internet topology. Mobility management of a MONET SHOULD therefore 214 be performed transparently to MNNs, at least to LFNs. LFNs SHOULD 215 (MUST ?) better have no responsibility in network mobility 216 management, whereas LMNs and VMNs SHOULD only be concerned about 217 managing their own mobility if they themselves appear to change 218 their point of attachment. However, MNNs may encounter variable 219 delays of transmission and loss with their respective CNs as the 220 network is moving. [WE WANT TO DISCUSS THIS REQUIREMENT IN THE 221 MAILING LIST] 223 3.6. Scalability 225 Scalability has always been an important concern in the design of 226 new protocols. As far as host mobility is concerned, mobility 227 support has to take into consideration a growing number of mobile 228 hosts and should even assume that a major part of the nodes 229 composing the Internet are mobile in the near future. This means 230 that signaling load and memory consumption should scale to an 231 important number of mobile nodes. However, network mobility 232 support is concerned by scalability differently, and in three 233 ways: 235 o large number of MONETs (e.g. PAN comprising a few devices and 236 carried by every human being). 238 o large MONETs comprising several subnetworks and a large 239 number of MNNs on each subnetwork (e.g. a train) 241 o the number of CNs is somewhat a function of the size of the 242 MONET; the more MNNs a MONET has, the more CNs the MONET is 243 most likely to have. (e.g. each MNN in a train communicating 244 with a few CNs) 246 Network mobility support MUST thus be able to support large 247 MONETs, a very large number of small MONETs, and a large number of 248 CNs. Scaling to a large number of CNs may indeed deserves more 249 consideration than scaling to a large number of MONETs. This has 250 never been considered in host mobility support, to the contrary of 251 the ability to support a large number of mobile nodes. 253 3.7. Minimum Signaling Overload 255 Mobility management is usually performed at the cost of control 256 traffic. Network mobility support MUST minimize this control 257 traffic, all the more for the reasons outlined in section 258 "scalability". 260 3.8. Routing Optimization 262 Network mobility support SHOULD optimize routing. Non-optimal 263 routing increases bandwidth consumption and transmission delays. 264 The amount of traffic intended for the MONET is understandably 265 more significant than in the case of a single mobile node (see 266 section "scalability"), then non-optimal routing SHOULD be 267 considered with more care than for host mobility support. However, 268 efficient routing is usually performed at the expense of increased 269 signaling. Thus, the gain of optimal routing MUST be balanced 270 against the incurred signaling cost. 272 3.9. Nested Mobility 273 Network mobility support MUST support nested mobility. It MUST at 274 least allow single VMNs to enter the MONET, single LMNs to leave 275 the MONET, and single mobile IP-subnet attach the MONET (instance 276 of a PAN in a train). Network mobility support must therefore 277 consider both MONETs and mobile nodes, otherwise it may hardly 278 interact with host mobility support. In practice, it should handle 279 VMNs as optimally as if networks were fixed. The working group 280 needs to agree if it MUST support any number of levels or be 281 limited to only two levels. 283 3.10. Backward Compatibility 285 Network mobility support is constrained by backward compatibility 286 with existing and forthcoming IPv6 standards. As such, it MUST not 287 prevent MNNs to operate any standardized protocol. This 288 particularly includes but is not limited to Mobile IPv6 (host 289 mobility) and IGMP (multicast group membership): 291 o Host Mobility Support Constraints: host mobility support in 292 IPv6 is achieved by Mobile IPv6 which is a compulsory component 293 of any IPv6 implementation. This means that network mobility 294 support MUST not prevent LMNs and VMNs from operating Mobile 295 IPv6 once located in a MONET. 297 o Multicast Constraints: any IPv6 router is supposed to allow 298 hosts on its attached subnetworks to participate in multicast 299 sessions. Group membership is gathered by the IGMP protocol. 300 Network mobility support MUST not prevent this. 302 In both cases, the network mobility support MUST provide the 303 necessary extensions to maintain backward compatibility with 304 existing protocols. 306 3.11. Minimum Impact on Existing Protocols and Infrastructure 308 Minimum impact on the already deployed infrastructure was an 309 important issue as far as IPv4 was concerned since it was not 310 possible to require all hosts to implement new features. On the 311 other hand, the emergence of IPv6 is an opportunity for making 312 changes, if necessary. An important number of specifications has 313 already been defined, but there is still scope for adding new 314 capabilities if needed since IPv6 deployment is only dawning. 315 However, in order to provide a quickly deployable solution, 316 network mobility support SHOULD better make use of the existing 317 protocols whenever possible and impose minimum changes or 318 extensions on the existing ones. It is also desirable to minimize 319 infrastructure installation costs and complexity. 321 3.12. No impact on CN or Internet routing 323 To be able successfully deploy the final solution, session 324 continuity between a MNN and a CN anywhere in the Internet SHOULD 325 NOT assume any changes to existing CNs or the Internet routing 326 architecture. On the other hand, optimizations for performance 327 enhancement MAY involve some changes to CNs, provided that such 328 optimizations would not cause any disruption to ongoing sessions, 329 if not supported by CNs (i.e. backward compatible). [THIS 330 REQUIREMENT IS TO BE DISCUSSED (in light of the observation made 331 in section "Minimum Impact on the Existing Protocols and 332 Infrastructure" here above) BECAUSE IT WOULD PREVENT POTENTIALLY 333 INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED]. 335 3.13. Security 337 Network mobility support must comply with usual IPv6 security 338 policies and standardized protocols. In addition, and unlike fixed 339 nodes, MNNs are more exposed to security threats, particularly 340 identity usurpation. Network mobility support must provide MNNs 341 and their CNs with at least as good security as for fixed nodes 342 and mobile hosts. It particularly shouldn't leave more room for 343 intruders to usurp an identify nor to perpetrate any kind of 344 attack against the MNNs nor the CNs. In practice, all control 345 messages required by network mobility support must be exchanged in 346 a secure manner and must ensure the following: 348 3.13.1. Confidentiality 350 All control messages transmitted in the network MUST ensure 351 MNNs' confidentiality. Only the recipient of the control 352 message may be able to decrypt the content of the datagram. 354 3.13.2. Authentication 356 All control messages MUST be authenticated by recipients in 357 order to prevent intruders to usurp the identity of a MNN. 359 3.13.3. Authorization 361 The recipient of a control message MUST ensure that the sender 362 is effectively authorized to perform the mobility support 363 operation indicated in the control message. 365 3.13.4. Location Privacy 367 Network mobility support may provide means for MNNs to hide 368 their location to any third party. It shouldn't be possible to 369 determine the succession of topological location of a MONET or 370 a particular MNN by monitoring the exchange of control 371 messages. In practice, MNNs may wish to hide their location to 372 some or all of their CNs, or anyone else but the CNs. It may 373 also be desirable to hide the location of the entire MONET to 374 all CNs without discrimination between MNNs. 376 3.14. Access Control 378 3.14.1. Access Control for VMNs 380 Mobile Networks MUST be able to authenticate and authorize VMNs to 381 gain access to the Internet via the mobile network infrastructure 382 (MRs). 384 3.14.2. Access Control Architecture 386 To be able to comply with the current access control mechanisms 387 and achieve a scalable solution, the final solution MUST NOT 388 assume that the fixed network would authenticate VMNs. VMN 389 authentication and authorization MUST be the responsibility of the 390 mobile network. 392 3.14.3. Access Control in the Fixed Network 394 AAA solutions MUST allow for authenticating an entire network. 395 This MAY simply be done by ensuring that the Authentication and 396 Authorization is not necessarily performed for a single IP 397 address. This is particularly important for IPv6 as each node may 398 configure multiple addresses. [THIS MAY BE SUGGESTING A SOLUTION 399 BUT WE WANT IT TO BE DISCUSSED ON THE MAILING LIST]. 401 3.15. Wide-Area Mobility 403 Network mobility support MUST provide means for a MONET to move 404 between heterogeneous networks, i.e. Wide-Area Mobility. This is 405 required in order to ensure permanent and uninterrupted world-wide 406 mobility. Nothing but administrative and security policies should 407 prevent a MONET to attach anywhere in the Internet topology. In 408 practice, a given MONET MUST be able to roam between 409 administratively distinct access networks (between Internet 410 Service Providers and corporate networks) and via any available 411 access technology (802.11b WLAN, Bluetooth, satellite link, GSM, 412 ...). In addition, network mobility support must also accommodate 413 to CNs deployed in distinct administrative domains. 415 3.16. Unified Solution 416 Should different schemes be proposed, a unified mobility support 417 scheme is required. We must avoid a situation where distinct 418 network mobility support schemes are deployed and unable to inter- 419 operate with each other. 421 3.17. Mobile CNs 423 Network mobility support MUST be optimized to handle the case 424 where the CN is itself a MN (as defined by [MIPv6]) or located in 425 a MONET (particularly if it is a VMN). It must perform efficiently 426 in both cases. 428 3.18. Addressing Constraints 430 The IP address is used for routing and to identify the subnetwork 431 where an interface is attached to. Each interface on a subnetwork 432 must therefore be configured with the network prefix of that 433 subnetwork. 435 Acknowledgments 437 The first author would like to thank both Motorola Labs Paris and 438 INRIA Rh�ne-Alpes, for the opportunity to bring this topic to the 439 IETF and more particularly Claude Castelluccia (INRIA) for its 440 advices, suggestions, and direction. In addition, we acknowledge 441 Alexandru Petrescu (Motorola), Mattias Petterson (Ericsson), Hesham 442 Soliman (Ericsson) and the NACM people from WIDE (Keio University) 443 for their comments and suggestions on this draft. 445 References 447 [Bhagwat96] Pravin Bhagwat, Satish Tripathi, and Charles Perkins. 448 Network Layer Mobility: an Architecture and Survey. IEEE Personal 449 Communications, 3(3):54, June 1996. 451 [Caceres96] Ramon Caceres and Venkata N. Padmanabhan. "fast and 452 scalable handoffs for wireles internetworks". In Proc. of the Second 453 ACM/IEEE International Conference on Mobile Computing and Networking 454 (MobiCom), Rye, New York, USA, November 1996. Bell Laboratories and 455 University of California at Berkeley. 457 [Castelluccia98] Claude Castelluccia. A Hierarchical Mobility 458 Management Scheme for IPv6. Third Symposium on Computers and 459 Communications (ISCC'98), Athens, Greece, June 1998. 460 http://www.inrialpes.fr/planete 462 [Ernst01] Thierry Ernst "Network Mobility Support in IPv6", PhD 463 Thesis, University Joseph Fourier Grenoble, France. October 2001. 465 [HMIPv6] H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier, 466 "Hierarchical MIPv6 mobility management", draft-ietf-mobileip- 467 hmipv6-05.txt. Work in progress 469 [MIPv6] David B. Johnson and C. Perkins. Mobility Support in IPv6. 470 draft-ietf-mobileip-ipv6-14.txt, July 2001. Work in progress. 472 [MOBRTR] T.J. Kniveton, J. J. Malinen, V. Devarapalli and C. E. 473 Perkins, "Mobile router support in Mobile IP", draft-kniveton- 474 mobrtr-00.txt. Work in progress. 476 [Myles93] Andrew Myles and David Skellern. Comparing Four IP Based 477 Mobile Host Protocols. In Joint- European Networking Conference. 478 Macquarie University, Sydney, Australia, May 1993. 480 [OLD-draft] Thierry Ernst, Hong-Yon Lach, Claude Castelluccia 481 "Network Mobility Support in IPv6: Problem Statement and 482 Requirements", draft-ernst-mobileip-monetv6-00.txt, July 2001. 484 Expiration pending. 486 [MONET-PSBU] T. Ernst, L. Bellier, A. Olivereau, C. Castelluccia, 487 H.-Y. Lach, "Mobile Networks Support in Mobile IPv6 (Prefix Scope 488 Binding Updates)" draft-ernst-mobileip-v6-network-02.txt, June 2001. 489 Work in progress 491 [RFC1122] R. Braden (editor). Requirements for Internet Hosts - 492 Communication Layers. Request For Comments 1122, Internet 493 Engineering Task Force (IETF), October 1989. 495 [RFC2460] S. Deering and R. Hinden. Internet Protocol Version 6 496 (IPv6) Specification. Request For Comments 2460, Internet 497 Engineering Task Force (IETF), December 1998. 499 [SCOPE] Hesham Soliman "Problem Scope" IETF internet-draft draft- 500 soliman-monet-scope-00.txt, Work in progress. 502 [TERMINOLOGY] Thierry Ernst "Terminology for Network Mobility 503 Support", draft-ernst-monet-terminology-00.txt, February 2002. Work 504 in progress. 506 [WEB-MONET] MONET web page http://www.nal.motlabs.com/monet 508 Author's Addresses 510 Questions about this document can be directed to the authors: 512 Thierry Ernst, 513 WIDE Project 514 Jun Murai lab. Faculty of Environmental Information, 515 Keio University. 516 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. 517 Phone : +81-466-49-1100 518 Fax : +81-466-49-1395 519 E-mail: ernst@sfc.wide.ad.jp 520 Web: http://www.sfc.wide.ad.jp/~ernst/ 522 Hong-Yon Lach 523 Motorola Labs Paris, Lab Manager, 524 Networking and Applications Lab (NAL) 525 Espace Technologique - Saint Aubin 526 91193 Gif-sur-Yvette Cedex, France 527 Phone: +33-169-35-25-36 528 Email: Hong-Yon.Lach@crm.mot.com