idnits 2.17.1 draft-ernst-nemo-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 == 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: ' 2. Overview' ) ** 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], [TERMINOLOGY], [Caceres96], [Myles93], [RFC2460], [Ernst01], [Bhagwat96], [PSBU], [IPv6-NODE], [MIPv6], [RFC1122], [REQUIREMENTS-1], [REQUIREMENTS-2], [REQUIREMENTS-3], [REQUIREMENTS-4]), 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 220: '... MNNs MAY appear to move from the...' RFC 2119 keyword, line 331: '...v6. NEMO support MUST not prevent the ...' RFC 2119 keyword, line 376: '... NEMO support SHOULD exhibit low la...' RFC 2119 keyword, line 386: '... handover MUST be managed at the ...' RFC 2119 keyword, line 389: '...logical location MUST not have an impa...' (36 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: o Mobile IPv6: host mobility support in IPv6 is achieved by Mobile IPv6. NEMO support MUST not prevent the proper operation of Mobile IPv6. == 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 mobile network 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: R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7862 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? 'REQUIREMENTS-1' on line 698 looks like a reference -- Missing reference section? 'REQUIREMENTS-3' on line 708 looks like a reference -- Missing reference section? 'REQUIREMENTS-4' on line 714 looks like a reference -- Missing reference section? 'Bhagwat96' on line 647 looks like a reference -- Missing reference section? 'Myles93' on line 679 looks like a reference -- Missing reference section? 'Castelluccia97' on line 116 looks like a reference -- Missing reference section? 'Caceres96' on line 651 looks like a reference -- Missing reference section? 'TERMINOLOGY' on line 720 looks like a reference -- Missing reference section? 'IPv6-NODE' on line 669 looks like a reference -- Missing reference section? 'Ernst01' on line 664 looks like a reference -- Missing reference section? 'Castelluccia98' on line 657 looks like a reference -- Missing reference section? 'MIPv6' on line 674 looks like a reference -- Missing reference section? 'PSBU' on line 684 looks like a reference -- Missing reference section? 'RFC1122' on line 690 looks like a reference -- Missing reference section? 'RFC2460' on line 694 looks like a reference -- Missing reference section? 'REQUIREMENTS-2' on line 703 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF INTERNET-DRAFT Thierry Ernst, WIDE and INRIA 3 October 2002 5 "Network Mobility Support Requirements" 6 draft-ernst-nemo-requirements-00.txt 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The purpose of traditional mobility support is to provide continuous 31 Internet connectivity to mobile hosts only (host mobility support). 32 In contrast, network mobility support (NEMO support) deals with 33 situations where an entire network changes its point of attachment to 34 the Internet and thus its reachability in the topology. In this 35 situation, mobility support is to provide continuous Internet 36 sessions not only to the router connecting the mobile network to the 37 global Internet, but also to nodes behind the mobile router. This 38 document tries to identify what constraints limit the implementation 39 and the deployment of a potentially and ideally good solution, and 40 what requirements solutions must comply with. Our main aim is to 41 raise the discussion on the mailing list. 43 Contents 45 Status of This Memo 47 Abstract 49 1. Introduction 50 2. Overview 51 2.1. Potential Configurations 52 2.2. Observations and Constraints 53 O1: Structure of the mobile network 54 O2: Mobile Router is a transit point 55 O3: Dog-leg Routing 56 O4: Ad-Hoc Network 57 O5: Scalability 58 O6: Deployment and Backward Compatibility 59 O7: Routers in the Mobile Network 60 O8: Addressing Constraints 61 3. High-Level Requirements 62 3.1. Migration Transparency 63 3.2. Operational Transparency 64 3.3. Performance Transparency (Seamless Mobility) 65 3.4. Layers Independence 66 3.5. NEMO Support Transparency for MNNs 67 3.7. Minimum Signaling Overload 68 3.12. No impact on CNs or Internet routing 69 3.13. Security 70 3.13.1. Confidentiality 71 3.13.2. Authentication 72 3.13.3. Authorization 73 3.13.4. Location Privacy 74 3.14. Access Control 75 3.14.1. Access Control for VMNs 76 3.14.2. Access Control Architecture 77 3.14.3. Access Control in the Fixed Network 78 3.15. Internet-wide Mobility 79 3.16. Unified Solution 80 3.17. Mobile CNs 81 3.18. Addressing Constraints 82 4. Basic Support Requirements 83 5. Extended Support Requirements 85 Acknowledgments 87 References 89 Author's Addresses 91 1. Introduction 93 Traditional work on mobility support is to provide continuous 94 Internet connectivity to mobile hosts only (host mobility support). 95 In contrast, network mobility support (NEMO support) deals with 96 situations where an entire network changes its point of attachment to 97 the Internet and thus its reachability in the topology. In this 98 situation, mobility support is to provide continuous Internet 99 sessions not only to the router connecting the mobile network to the 100 global Internet, but also to nodes behind the mobile router. 102 The purpose of the present document is to raise discussion in order 103 to identify what constraints limit the implementation and the 104 deployment of a potentially and ideally good solution, and what 105 requirements solutions must comply to. Most constraints and 106 requirements that we have listed are equally applicable to host 107 mobility support and network mobility support. Some of them have been 108 debated in the literature as far as host mobility support was 109 concerned; we have extended this list to include those related to 110 network mobility support. Other requirements are discussed in 111 [REQUIREMENTS-1], [REQUIREMENTS-2}, [REQUIREMENTS-3] and 112 [REQUIREMENTS-4]. All requirements may not be satisfied by a single 113 solution. For the sake of modularity, we may decide to use separate 114 solutions for different aspects of the problem space. Note that most 115 requirements discussed for host mobility support, like for instance 116 in [Bhagwat96], [Myles93], [Castelluccia97], [Caceres96] or many 117 other papers, are equally applicable to NEMO support. However, they 118 must be extended and refined to meet the needs of NEMO support. 120 We assume that the reader is familiar with the terminology defined in 121 [TERMINOLOGY]. In order to understand the rationale that drives to 122 the requirements, in section 2, we describe potential network 123 mobility configurations and we make a number of observations that may 124 constraint the forthcoming solutions. In section 3, we list some high 125 level requirements. In section 4 and 5, the high-level requirements 126 are refined in a more explicit manner for basic support and extended 127 support. This list is not exhaustive and should be combined with the 128 requirements found in the other drafts. 130 2. Overview 132 2.1 Potential Configurations 134 Network mobility support deals with entire networks of computers 135 that change their point of attachment to the global Internet and 136 need to maintain continuous Internet connectivity. 138 Cases of mobile networks include networks attached to people 139 (Personal Area Networks or PAN), and networks of sensors and 140 access networks deployed in vehicles (aircrafts, boats, cars, 141 trains, etc). 143 A PAN may be connected to the Internet via a 802.11b WLAN (e.g. 144 user in a shopping mall) and is likely to change its point of 145 attachment very frequently, while an aircraft or a boat may be 146 connected to the Internet via the same satellite link for a couple 147 of hours. Some mobile networks may not move at all or may be kept 148 in some sort of home network for a large amount of time 150 In case mobile networks are access networks providing Internet 151 access, IP devices carried by people (laptop, camera, mobile 152 phone, etc) would get access to the Internet via the mobile 153 network they are located in. In some cases, PANs may also be 154 carried in the mobile network, in which case there are mobile 155 networks visiting a larger mobile network. There is thus a need to 156 achieve two levels of mobility: node mobility and network 157 mobility. 159 As people would by definition move from bus to train, thus from a 160 mobile network to another, mobile nodes and mobile networks 161 belonging to potentially different administrative domains would 162 get attached to a mobile network. 164 Since cases of mobile networks suck like trains, cars, aircrafts 165 are themselves most likely to cross country boundaries, they are 166 to move between topologically distant parts of the Internet thus 167 between ISP boundaries. A mobile network may attach to very 168 distant parts of the Internet topology, provided it is granted 169 access to it. In this situation, an Internet-wide mobility scheme, 170 providing both intra-domain and inter-domain mobility, would be 171 requested. 173 The train example is particularly interesting because it shows we 174 need to consider potentially large mobile networks containing 175 hundreds of hosts and several routers. Since each mobile network 176 node (MNN) may be communicating with a few correspondent nodes 177 (CNs), the total number of CNs could be several times as large as 178 the number of MNNs and scale up to a few thousands. Not to say, a 179 single server deployed in a vehicle may itself have thousands of 180 CNs, or even more. Moreover, whatever the situation, CNs are also 181 most likely to be sparsely distributed in the Internet. 183 From the above scenarios, at least the following configurations of 184 mobile networks seem to be desirable: 186 - mobile networks of any size, ranging from a sole subnet with a 187 few IP devices to a collection of subnets with hundreds of IP 188 devices. 190 - mobile networks with a potentially large number of correspondent 191 nodes, sparsely distributed in different administrative domains, 193 - simultaneous access to the Internet provided via distinct 194 (likely wireless), 196 - distinct cases of mobile networks moving with distinct mobility 197 frequencies, 199 - mobile networks displaced within a domain boundary (intra-domain 200 mobility) or between domain boundaries (inter-domain mobility), 202 - foreign mobile nodes that attach to the mobile network, 204 - nodes that change their point of attachment within the mobile 205 network, 207 - nested mobile networks 209 2.2. Observations and Constraints 211 In order to drive the discussion on the requirements, this section 212 lists a number of observations that may constraint or limit the 213 deployment of a solution which looks potentially good on the 214 paper. 216 O1: Structure of the mobile network 218 A MR changing its point of attachment does not **cause** the MNNs 219 behind the MR to change their own physical point of attachment. 220 MNNs MAY appear to move from the point of view of an observer in 221 the Internet, but their point of attachment in the mobile network 222 is not modified as a **result** of the mobile network changing its 223 own point of attachment. In most cases, the internal structure of 224 the mobile network will in effect be relatively stable (no dynamic 225 change of the topology), but this is not a general assumption (see 226 section "Ad-hoc networks") 228 O2: Mobile Router is a transit point 230 All packets sent between MNNs and a CN outside the mobile network 231 necessarily transit through one of the MRs of the mobile network. 232 In the case of nested mobility, packets transit through the root- 233 NEMO, thus through one of the TLMRs. 235 O3: Dog-leg Routing 237 As a result of mobility, routing between a CN in the global 238 Internet and a mobile node may not be optimal. Packets usually 239 transit via the home link of the mobile node if no routing 240 optimization is explicitly performed. In network mobility, 241 multiple dog-leg routing may be introduced by nested mobility. In 242 this case, packets intended to a VMN may first transit by the 243 VMN's home link, then being rerouted to the MR's home link. 245 Non-optimal routing increases bandwidth consumption and 246 transmission delays. The amount of traffic intended for the mobile 247 network is understandably more significant than in the case of a 248 single mobile node (see section "scalability"), then non-optimal 249 routing is to be considered with more care than for host mobility 250 support. However, efficient routing is usually performed at the 251 expense of increased signaling. Thus, the gain of optimal routing 252 has to be balanced against the incurred signaling cost. 254 O4: Ad-Hoc Network 256 A mobile network as defined in the IETF NEMO Working Group is not 257 to be confused with an Ad-hoc network as defined in the IETF MANET 258 Working Group. 260 In the MANET WG, an ad-hoc network is an autonomous system made of 261 mobile nodes (i.e. routers) connected by wireless links. The 262 routers are free to move randomly and to organize themselves 263 arbitrary. Topologies are highly dynamic and there is no fixed 264 infrastructure. Solutions produced by the MANET WG aim at 265 maintaining routes between highly dynamic nodes. The MANET WG is 266 also considering how to provide Internet access to the mobile 267 nodes in the ad-hoc network, but the gateway between the ad-hoc 268 network and the Internet does not change its point of attachment, 269 so the MANET WG is not concerned with the mobility management of 270 an entire network changing its point of attachment. 272 In the NEMO WG, some routers may effectively move arbitrary, but 273 this is not a common case. NEMO aims at providing Internet 274 reachability to nodes in the mobile network and at maintaining 275 session continuity after the mobile network has changed its point 276 of attachment in the topology. 278 Thus, the NEMO WG and the MANET WG do not have the same 279 objectives. However, an Ad-hoc network which gateways to the 280 Internet would change their point of attachment is likely to be 281 considered as a special instance of a mobile network and would 282 thus rely on NEMO solutions to manage the change of the point of 283 attachment, while routing within the mobile network is only to be 284 considered by MANET. 286 O5: Scalability 288 Scalability has always been considered in the design of new 289 protocols. This particularly includes signaling load and memory 290 consumption which must thus be minimized. 292 For single hosts, host mobility support had to take into 293 consideration a growing number of mobile hosts and should even 294 assume that a major part of the nodes composing the Internet would 295 be mobile in the near future. Thus, it has to scale to an 296 important number of mobile nodes. 298 The scalability parameters in NEMO support differ from host 299 mobility. NEMO support has to scale to: 301 o a large number of mobile networks (e.g. each vehicle, each 302 person carrying a PAN) 304 o a large mobile networks comprising several subnetworks and a 305 large number of MNNs on each subnetwork (e.g. a train) 307 o the number of CNs, which is somewhat a function of the size 308 of the mobile network; the more MNNs a mobile network has, the 309 more CNs the mobile network is most likely to have. (e.g. each 310 MNN in a train communicating with a few CNs) 312 O6: Deployment and Backward Compatibility 314 In IPv4, minimizing the impact on the already deployed 315 infrastructure was an important issue since it was not possible to 316 require all hosts to implement new features. On the other hand, in 317 IPv6, an important number of specifications has for sure already 318 been defined, but IPv6 deployment is only dawning, so, it's 319 theoretically still possible to impose new capabilities on all 320 hosts. However, it is not desirable. The rule of thumb for any 321 new protocol is to make use of the existing ones whenever 322 possible, to require no changes on them, and to impose extensions 323 only when necessary. 325 The solution for NEMO support must thus be backward compatible 326 with all existing IPv6 standards. If necessary, it will have to 327 provide the necessary extensions to maintain backward 328 compatibility with existing protocols. So, for instance: 330 o Mobile IPv6: host mobility support in IPv6 is achieved by 331 Mobile IPv6. NEMO support MUST not prevent the proper operation 332 of Mobile IPv6. 334 o IGMP (Mutlticast group membership): any IPv6 router is 335 supposed to allow hosts on its attached subnetworks to 336 participate in multicast sessions. Group membership is gathered 337 by the IGMP protocol. 339 It is also desirable to minimize infrastructure installation costs 340 and complexity. So, the solution cannot be orthogonally different. 342 O7: Routers in the Mobile Network 344 All routers in the Internet are considered to run a number of 345 protocols such as a routing protocol, Neighbor Discovery, ICMP, 346 and others. This seems also to apply to routers deployed in mobile 347 networks, but we have to figure out to what extend, and how. 349 O8: Addressing Constraints 351 The IP address is used for routing and to identify the subnetwork 352 where an interface is attached to. Each interface on a subnetwork 353 must therefore be configured with the network prefix of that 354 subnetwork. 356 3. High Level Requirements 358 This section details a number of high level requirements that should 359 be met by the solutions. 361 3.1. Migration Transparency 363 In order to provide migration transparency, a permanent and 364 continuous Internet connectivity must be provided to all MNNs, 365 without disruption of service. MNNs must always be reachable 366 regardless of the point of attachment of the MR, and sessions must 367 be maintained after the MR has changed its point of attachment. 369 3.2. Operational Transparency 371 In order to be transparent to the applications and the users, NEMO 372 support must be performed at the network layer. 374 3.3. Performance Transparency (Seamless Mobility) 376 NEMO support SHOULD exhibit low latency, incur little or no data 377 loss, minimum delays, minimum signaling load, and minimum 378 bandwidth consumption for packet delivery. It should be performed 379 as seamlessly as host mobility is supported (no abrupt degradation 380 of service). 382 3.4. Layers Independence 384 Handover of IP sessions is performed at the network layer. With 385 respect to the layer separation of the Internet protocol suite, 386 handover MUST be managed at the network layer only and 387 transparently to upper layers, despite the migration of the mobile 388 network in the network topology. Therefore, a change of 389 topological location MUST not have an impact on layers above the 390 network layer other than a transient loss of performance, as 391 depicted in the above paragraph. If this is respected, 392 compatibility with existing transport and application layers is 393 maintained. In practice, the identifiers used at the transport 394 layer should be independent from the physical IP addresses used at 395 the network layer for routing. If upper layer protocols require a 396 location independent and invariant identifier, the network layer 397 MUST provide it with an identifier irrespective of the actual 398 topological location. 400 3.5. NEMO Support Transparency for MNNs 402 In section "observation O1", we have seen that "MNNs don't change 403 their own point of attachment as a result of the mobile network's 404 displacement in the Internet topology. NEMO support SHOULD 405 therefore be performed transparently to MNNs and keep them away 406 from participating in NEMO support. Although MNNs may encounter 407 variable delays of transmission and loss with their respective CNs 408 as the network is moving. This is not considered a lack of 409 transparency. However, receiving movement information may be 410 useful to hosts able to understand it, so this could be allowed as 411 an option, and LMNs and VMNs, which are able to change their own 412 point of attachment must manage their own mobility. 414 3.7. Minimum Signaling Overload 416 Mobility management is usually performed at the cost of control 417 traffic. In order to be scalable, NEMO support MUST minimize this 418 control traffic. 420 3.12. No impact on CN or Internet routing 422 Session continuity between a MNN and arbitrary CNs anywhere in the 423 Internet SHOULD NOT assume any changes to existing CNs or the 424 Internet routing architecture. On the other hand, optimizations 425 for performance enhancement MAY involve some changes to CNs, 426 provided that such optimizations would not cause any disruption to 427 ongoing sessions, if not supported by CNs (i.e. backward 428 compatible). [THIS IS TO BE DISCUSSED (in light of the 429 observation made in section "Minimum Impact on the Existing 430 Protocols and Infrastructure" here above) BECAUSE IT WOULD PREVENT 431 POTENTIALLY INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED]. 433 3.13. Security 435 NEMO support must comply with usual IPv6 security policies and 436 standardized protocols. In addition, and unlike fixed nodes, MNNs 437 are more exposed to security threats, particularly identity 438 usurpation. NEMO support must provide MNNs and their CNs with at 439 least as good security as for fixed nodes and mobile hosts. It 440 particularly shouldn't leave more room for intruders to usurp an 441 identify nor to perpetrate any kind of attack against the MNNs nor 442 the CNs. In practice, all control messages required by NEMO 443 support must be exchanged in a secure manner and must ensure the 444 following: 446 3.13.1. Confidentiality 448 All control messages transmitted in the network MUST ensure 449 MNNs' confidentiality. Only the recipient of the control 450 message may be able to decrypt the content of the datagram. 452 3.13.2. Authentication 454 All control messages MUST be authenticated by recipients in 455 order to prevent intruders to usurp the identity of a MNN. 457 3.13.3. Authorization 459 The recipient of a control message MUST ensure that the sender 460 is effectively authorized to perform the mobility support 461 operation indicated in the control message. 463 3.13.4. Location Privacy 464 NEMO support may provide means for MNNs to hide their location 465 to any third party. It shouldn't be possible to determine the 466 succession of topological location of a mobile network or a 467 particular MNN by monitoring the exchange of control messages. 468 In practice, MNNs may wish to hide their location to some or 469 all of their CNs, or anyone else but the CNs. It may also be 470 desirable to hide the location of the entire mobile network to 471 all CNs without discrimination between MNNs. 473 3.14. Access Control 475 3.14.1. Access Control for VMNs 477 Mobile Networks MUST be able to authenticate and authorize VMNs to 478 gain access to the Internet via the mobile network infrastructure 479 (MRs). 481 3.14.2. Access Control Architecture 483 To be able to comply with the current access control mechanisms 484 and achieve a scalable solution, the final solution MUST NOT 485 assume that the fixed network would authenticate VMNs. VMN 486 authentication and authorization MUST be the responsibility of the 487 mobile network. 489 3.14.3. Access Control in the Fixed Network 491 AAA solutions MUST allow for authenticating an entire network. 492 This MAY simply be done by ensuring that the Authentication and 493 Authorization is not necessarily performed for a single IP 494 address. This is particularly important for IPv6 as each node may 495 configure multiple addresses. 497 3.15. Internet-wide mobility 499 In order to ensure permanent and uninterrupted Internet-wide 500 mobility, mobile network should be able to roam between access 501 networks belonging to distinct ISPs and corporate networks 502 (distinct administrative domains, i.e. inter-domain mobility) and 503 via any available access technology (distinct technologies:802.11b 504 WLAN, Bluetooth, satellite link, GSM, i.e. heterogeneous 505 mobility). Indeed, nothing but administrative and security 506 policies should prevent a mobile network to attach anywhere in the 507 Internet topology. So, the solution must technically allow this 508 kind of scenario. In addition, NEMO support must also accommodate 509 to CNs deployed in distinct administrative domains. 511 3.16. Unified Solution 512 Should different schemes be proposed, a unified mobility support 513 scheme is required. A situation where distinct NEMO support 514 schemes are deployed and unable to inter-operate with each other 515 must be avoided. 517 3.17. Mobile CNs 519 NEMO support MUST be optimized to handle the case where the CN is 520 MIPv6-enabled and/or itself located in a mobile network 521 (particularly if it is a VMN). It must perform efficiently in both 522 cases. 524 4. Requirements for Basic Support 526 In this section, the high-level requirements are refined in a more 527 explicit manner for basic support. This list is not exhaustive and 528 should be combined with the requirements found in the other drafts. 529 Requirements follow from our observations and high-level requirements 530 in section 2 and 3. 532 Basic support is to maintain session continuity between nodes in the 533 mobile network and nodes in the global Internet. The solution will 534 have to meet the following requirements [TO BE DISCUSSED ON THE LIST 535 - THIS IS A PROPOSITION - AT THAT POINT DON'T TAKE THINGS FOR 536 GRANTED]: 538 R1: The solution MUST provide permanent Internet connectivity and 539 reachability to all nodes behind the MR 541 R2: The solution MUST maintain continuous sessions between nodes 542 behind the MR and arbitrary CNs after IP handover of the MR 544 R3: All the potential configurations MUST be treated the same way 545 (any number of subnets and MNN, nested mobile networks, 546 multihomed 547 mobile networks) 549 R4: The solution MUST support LFNs, VMNs, and LMNs. 551 R5: CNs and MNNs must comply with the requirements for IPv6 nodes 552 defined in [IPv6-NODE] 554 R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to 555 MNNs) 557 R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs) 559 R8: A VMN that gets attached to a link within the mobile network 560 obtains an address on that link. 562 R9: The solution MUST support nested mobile networks with any number 563 of mobility levels 565 R10: The solution MUST support multi-homed mobile network 566 R10.1 : The solution MUST support mobile networks with multiple 567 MRs 569 R10.2: The solution MUST support MR with multiple interfaces 571 R11: The solution MUST NOT prevent the use of existing protocols 573 R11.1: The solution MUST allow MNNs to operate the "CN 574 functionality" of Mobile IPv6 576 R11.2: The solution MUST support MIPv6-enabled VMNs and LMNs 578 R11:3: The solution will ensure that mechanisms related to 579 multi-homing 580 (defined within other WGs in IETF) will be useful for 581 NEMO" 583 R12: The solution MUST support a large number of mobile networks 585 R12: The solution MUST support a large number of CNs 587 R13: The solution MUST support vertical handoff 589 R14: The solution MUST support horizontal handoff 591 R15: The solution SHOULD support fast handoff 593 R16: The solution MUST support inter-domain mobility 595 R17: The solution MUST support heterogeneous mobility 597 R18: The solution MUST minimize control traffic 599 5. Requirements for Extended Support 601 In this section, the high-level requirements are refined in a more 602 explicit manner for extended support. This list is not exhaustive and 603 should be combined with the requirements found in the other drafts. 605 Extended support is to optimize routing between CNs and arbitrary 606 MNNs and must support the following requirements (non exhaustive 607 list, to be completed later) 609 R1: The solution for Extended support must seat on top of Basic 610 support. 611 This means it must comply with the requirements defined under 612 "Basic support" and co-exist with it without disturbing it or any 613 of the nodes that do not need/understand it. 615 R2: MNNs and CNs MAY be NEMO-enabled as a means to improve routing. 616 As 617 such be notified and take action upon the change of point of 618 attachment of the MR. 620 R3: The solution must preserve route aggregation in the Internet 622 R4: The solution must minimize control traffic. 624 RXXXX: To be continued. Many more to be added later. 626 Acknowledgments 628 The material presented in this document takes most of the text from 629 our former internet-drafts submitted to MobileIP WG and to the former 630 MONET BOF, co-authored with Hong-Yon Lach, which where themselves 631 based on original text from [Ernst01]. The author would therefore 632 like to thank both Motorola Labs Paris and INRIA (PLANETE team, 633 Grenoble, France), for the opportunity to bring this topic to the 634 IETF since 2000, and particularly Hong-Yon Lach (Motorola) and Claude 635 Castelluccia (INRIA) for their advices, suggestions, and direction. 636 We also acknowledge the contribution from Alexandru Petrescu 637 (Motorola), Christophe Janneteau (Motorola), Hesham Soliman 638 (Ericsson), Mattias Petterson (Ericsson) and Keisuke Uehara (Keio 639 University). We are grateful to people in the InternetCAR team (Keio 640 University) and all the people on the NEMO (formerly MONET) mailing 641 list for their comments and suggestions on the NEMO ML which helped 642 to improve this draft (Greg Daley, Pascal Thubert, James Kempf, TJ 643 Kniveton, and other we may have forgot to include here) 645 References 647 [Bhagwat96] P. Bhagwat, S. Tripathi, and C. Perkins. 648 "Network Layer Mobility: an Architecture and Survey" 649 IEEE Personal Communications, 3(3):54, June 1996. 651 [Caceres96] R. Caceres and V.N. Padmanabhan. 652 "Fast and scalable handoffs for wireles 653 internetworks" 654 In Proc. of the Second ACM/IEEE MOBICOM, 655 New-York, USA, November 1996. 657 [Castelluccia98] Claude Castelluccia. 658 "A Hierarchical Mobility Management Scheme for IPv6. 659 Third Symposium on Computers and Communications 660 (ISCC'98), 661 Athens, Greece, June 1998. 662 http://www.inrialpes.fr/planete 664 [Ernst01] Thierry Ernst 665 "Network Mobility Support in IPv6", PhD Thesis, 666 University Joseph Fourier Grenoble, France. 667 October 2001. http://www.inria.fr/rrrt/tu-0714.html 669 [IPv6-NODE] John Loughney 670 "IPv6 Node Requirements" 671 draft-ietf-ipv6-node-requirements-01.txt 672 July 2002, Work in progress. 674 [MIPv6] David B. Johnson and C. Perkins. 675 "Mobility Support in IPv6" 676 draft-ietf-mobileip-ipv6-18.txt, 677 July 2002. Work in progress. 679 [Myles93] Andrew Myles and David Skellern. 680 "Comparing Four IP Based Mobile Host Protocols" 681 In Joint- European Networking Conference. 682 Macquarie University, Sydney, Australia, May 1993. 684 [PSBU] T. Ernst et al. 685 "Mobile Networks Support in Mobile IPv6 686 (Prefix Scope Binding Updates)" 687 draft-ernst-mobileip-v6-network-03.txt, 688 March 2002. Work in progress 690 [RFC1122] R. Braden (editor). 691 "Requirements for Internet Hosts - Communication 692 Layers". IETF RFC 1122, October 1989. 694 [RFC2460] S. Deering and R. Hinden. 695 "Internet Protocol Version 6 (IPv6) Specification" 696 IETF RFC 2460, December 1998. 698 [REQUIREMENTS-1] Hesham Soliman 699 "Problem Scope", 700 Internet-Draft draft-soliman-monet-scope-00.txt, 701 February 2002. Expired 703 [REQUIREMENTS-2] H.-Y. Lach, C. Janneteau, A. Petrescu 704 "Mobile Network Scenarios, Scope and Requirements", 705 draft-lach-nemo-requirements-00.txt, 706 October 2002. 708 [REQUIREMENTS-3] T.J. Kniveton, A. Yegin 709 "Problem Scope and Requirements for Mobile Networks 710 Working Group" 711 draft-kniveton-monet-requirements.txt, 712 February 2002. Expired 714 [REQUIREMENTS-4] C. W. Ng, and T. Tanaka 715 "Usage Scenario and Requirements for AAA in Network 716 Mobility Support" 717 draft-ng-nemo-aaa-use-00.txt October 718 2002. Work in progress 720 [TERMINOLOGY] Thierry Ernst and Hong-Yon Lach 721 "Terminology for Network Mobility Support", 722 draft-ernst-nemo-terminology-00.txt, 723 October 2002. Work in progress. 725 Author's Addresses 727 Questions about this document can be directed to the authors: 729 Thierry Ernst, 730 WIDE Project and INRIA 731 Jun Murai lab. Faculty of Environmental Information, 732 Keio University. 733 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. 734 Phone : +81-466-49-1100 735 Fax : +81-466-49-1395 736 E-mail: ernst@sfc.wide.ad.jp 737 Web: http://www.sfc.wide.ad.jp/~ernst/