idnits 2.17.1 draft-ernst-mobileip-monetv6-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: ---------------------------------------------------------------------------- == 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2.2.3. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (13 July 2001) is 8323 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) -- Looks like a reference, but probably isn't: 'OTHERS' on line 579 == Unused Reference: '2' is defined on line 784, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thierry Ernst 3 Hong-Yon Lach 4 Claude Castelluccia 5 Motorola Labs and INRIA Planete, France 6 13 July 2001 7 "Network Mobility Support in IPv6: 8 Problem Statement and Requirements" 9 draft-ernst-mobileip-monetv6-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 This draft addresses the problems of routing datagrams to nodes 34 located in an IPv6 mobile network. A mobile network is one or more 35 IP-subnets attached to a mobile router and mobile as a unit. The 36 mobile router dynamically changes its point of attachment. 37 Applications of mobile networks include networks attached to people 38 (PANs) and networks of sensors deployed in an aircraft, a boat, or a 39 car. 41 This draft defines a terminology and presents a number of specific 42 issues faced by mobility of an entire network. An explicit mobility 43 support scheme is required, what we call "network mobility support" 44 in contrast with "host mobility support". We have listed a number of 45 requirements that need to be addressed by network mobility support. 47 Contents 49 Status of This Memo 51 Abstract 53 Introduction 55 1. Definitions and Problem Statement 56 1.1. Motivations 57 1.2. Terminology 58 1.3. Characteristics 59 1.4. Aim of Network Mobility Support 60 1.5. Assumption 61 1.6. Issues 62 1.6.1. Routing Issues 63 1.6.2. Addressing Issues 64 1.6.3. Network Protocols Issues 65 1.6.4. Security Issues 67 2. Constraints and Requirements 68 2.1. Constraints 69 2.1.1. Host Mobility Support Constraints 70 2.1.2. Addressing Constraints 71 2.1.3. IPv6 Constraints 72 2.1.4. Security Constraints 73 2.2. Requirements 74 2.2.2. Wide-Area Mobility Support 75 2.2.3. Security 76 2.2.4. Transparency 77 2.2.5. Optimal Routing 78 2.2.6. Minimum Signalling Overload 79 2.2.7. Scalability 80 2.2.8. Nested Mobility 81 2.2.9. Backward Compatibility 82 2.2.10. Minimum Impact on Existing Protocols 84 References 86 Author's Addresses 87 Introduction 89 This document addresses the question of routing datagrams to nodes 90 located in an IPv6 mobile network, i.e. network mobility support. We 91 define a mobile network as an entire network that dynamically changes 92 its point of attachment in the Internet and thus its reachability in 93 the Internet. 95 The first section gives the motivations for network mobility support. 96 We then describe mobile networks and we define a new terminology used 97 throughout this study (section 1.2). There may exist various kind of 98 mobile networks and they obviously have specific characteristics as 99 depicted in section 1.3. Section 1.4 explains what this study tries 100 to achieve. Section 1.6 concludes this section with a number of 101 issues faced by network mobility support. 103 Network mobility support in wide-area IPv6 networks has to comply 104 with a number of constraints and requirements. Constraints limit the 105 implementation and the deployment of a potentially and ideally good 106 solution, and solutions need to fulfill a number of requirements. 107 Some requirements must be solved whereas other should be solved 108 whenever possible. Constraints and requirements for network mobility 109 support are discussed in the second section. Most constraints and 110 requirements that we have listed are equally applicable to host 111 mobility support and network mobility support. Some of them have 112 been debated in the literature as far as host mobility support was 113 concerned; we have extended this list to include those related to 114 mobile networks. 116 1. Definitions and Problem Statement 118 1.1. Motivations 120 The purpose of traditional mobility support is to provide continuous 121 Internet connectivity to mobile hosts (host mobility support). There 122 are situations where an entire network might move and attach to 123 different locations in the Internet topology. In this paper, we refer 124 to a network as a set of nodes that share the same IP prefix and that 125 are attached to the Internet through a border router. We refer to a 126 mobile network as a network whose border router is a mobile router 127 which dynamically changes its point of attachment to the Internet and 128 thus its reachability in the Internet. 130 Cases of mobile networks include networks attached to people 131 (Personal Area Network or PAN) and networks deployed in aircrafts, 132 boats, cars, trains, etc. An Ad-hoc network as defined in manet is 133 not to be confused with a mobile network; however it may become a 134 mobile network when its border router changes its point of attachment 135 to the Internet. As an example of a mobile network, we could think of 136 an airline company that provides permanent on-board Internet 137 connectivity. This allows all passengers to use their laptops to 138 connect to remote hosts, download music or video from any provider, 139 or browse the web. The Internet could also be used to exchange 140 information between the aircraft and air traffic control stations. 141 This scenario has already been investigated by Eurocontrol (European 142 Organization for the Safety of Air Navigation [8]). During the 143 flight, the aircraft changes its point of attachment to the Internet 144 and is reachable by different care-of addresses over time, most 145 likely owned by distinct Internet service providers. This scenario 146 justifies that mobile networks may be of a big size, containing 147 hundreds of hosts and several routers and may attach to very distant 148 parts of the Internet topology. Moreover, it shows that we face two 149 distinct levels of mobility, node mobility and network mobility, 150 since laptops owned by passengers are themselves mobile nodes 151 visiting the aircraft mobile network. However, this paper does not 152 address the specific issues involved when mobile nodes visit the 153 mobile network. We are focusing on the general case. 155 1.2. Terminology 157 We mostly adopt the terminology already defined in the IPv6 [5] and 158 Mobile IPv6 [6] specifications. We also introduce the following new 159 terms relevant to mobile networks. A mobile network attaches to the 160 rest of the Internet through its border routers which we refer to as 161 the mobile routers (MRs). A mobile router has at least two 162 interfaces, the first attached to the home link or the foreign link, 163 and the other attached to an internal link of the mobile network. We 164 call mobile network node (MNN) any host or router located within the 165 mobile network, either permanently or temporarily. 167 All MNNs located in the same mobile network share a common and 168 permanent IP prefix that we call the Mobile Network Prefix. The 169 Mobile Network Prefix is a bit string that consists of some number of 170 initial bits which identifies the set of subnetworks that compose the 171 mobile network. It also identifies the topological location of the 172 mobile network when the mobile router is attached to its home link. 173 In addition, we call correspondent node (CN) any node external to the 174 mobile network that is communicating with one or more MNNs. The 175 terminology is summarized in fig.1. 177 Mobile Network 178 A set of nodes which are mobile, as a unit, with respect to the 179 rest of the Internet, i.e. a mobile router and all its attached 180 nodes. The mobile router changes dynamically its point of 181 attachment to the Internet and thus its reachability in the 182 Internet. All nodes in the mobile network share the same IP 183 prefix: the Mobile Network Prefix. Note that a mobile network may 184 be composed by one or more IP-subnets. 186 ____ 187 | | 188 | CN | 189 |____| 190 ___|____________________ 191 | | 192 | | 193 | Internet | 194 | | 195 |________________________| 196 __|_ __|_ 197 | | Access | | 198 | AR | Router | AR | 199 |____| |____| 200 ______|__ foreign __|_____________ home 201 link __|_ link 202 | | 203 | MR | Mobile Router 204 |____| 205 _________|_______ internal 206 __|__ __|__ link 207 | | | | 208 | LFN | | LFN | Local Fixed Nodes 209 |_____| |_____| 211 Figure 1: Terminology 213 Mobile IP-subnet 215 A mobile network that is composed of a single IP-subnet. 217 Mobile Router (MR) 219 The border router of a mobile network which attaches the mobile 220 network to the rest of the Internet. The mobile router has at 221 least two interfaces, an external interface, and an internal 222 interface. The mobile router maintains the Internet connectivity 223 for the mobile network. It is used as a gateway to route packets 224 between the mobile network and the fixed Internet. 226 External Interface of a Mobile Router 228 The external interface of a mobile router is attached to the home 229 link if the mobile network is at home, or is attached to a foreign 230 link if the mobile network is in a foreign network. 232 Internal Interface of a Mobile Router 234 The internal interface of a mobile router is attached to an 235 internal link within the mobile network. This interface is 236 configured with the Mobile Network Prefix (see definition below) 237 for all the MNNs inside the mobile network. 239 Local Fixed Node (LFN) 241 Any host or router permanently located within the mobile network 242 and that does not change its point of attachment. 244 Local Mobile Node (LMN) 246 A mobile node that belongs to the mobile network and that changes 247 it's point of attachment. The home link of the LMN is a link 248 within the mobile network. The LMN may attach to any link within 249 the mobile network, or to any link outside the mobile network. 251 Visiting Mobile Node (VMN) 253 A mobile node that does not belong to the mobile network and that 254 changes it's point of attachment. The home link of the VMN is not 255 a link within the mobile network. A VMN may attach to a link 256 within the mobile network and obtain a careof address on this 257 link. 259 Mobile Network Node (MNN) 261 Any host or router located within the mobile network, either 262 permanently or temporarily. A MNN could be any of a MR, LFN, VMN, 263 or LMN. 265 Node behind the MR 267 A synonym for a mobile network node (MNN). See corresponding 268 definition. 270 Correspondent Node (CN) 272 Any node located outside the mobile network that corresponds with 273 any of the MNNs. By extension, we say that CNs corresponding with 274 MNNs of a mobile network are CNs of this mobile network. 276 Access Router 278 Any subsequent point of attachment of the mobile network at the 279 network layer. Basically, a router on the home link or the foreign 280 link. 282 Home subnet prefix 284 A bit string that consists of some number of initial bits of an IP 285 address which identifies the home link within the Internet 286 topology. (i.e. the IP subnet prefix corresponding to the mobile 287 node's home address, as defined in [6]). 289 Foreign subnet prefix 291 A bit string that consists of some number of initial bits of an IP 292 address which identifies a foreign link within the Internet 293 topology. 295 Mobile Network Prefix 297 The network prefix that is common to all IP addresses in the 298 mobile network when the mobile router is attached to the home 299 link. For a mobile network containing only one subnet, the Mobile 300 Network Prefix is the prefix of this subnet ("home subnet prefix" 301 as defined in [6]). Note that the Mobile Network Prefix may not be 302 the home prefix. 304 1.3. Characteristics 306 Structure of the mobile network 308 The internal structure of a mobile network is preserved while it 309 is moving. As a result of the mobility of the mobile network, MNNs 310 do not change their point of attachment; however, MNNs move from 311 the point of view of their CNs. From a routing perspective, a 312 mobile network may therefore be virtually perceived as a single 313 node (the MR) with a topologically correct address or prefix. The 314 topological location of a MNN being dependent of the location of 315 the MR, the knowledge of the topological location of the MR is 316 sufficient for routing datagrams from a CN towards a MNN. 318 Mobile Router is a transit point 320 All packets sent from any CN to a MNN necessarily transit through 321 the MR. As a result, providing the CN with the current location of 322 the MR in the Internet topology may be sufficient for optimally 323 routing packets intended to a MNN. 325 Size of the mobile network 327 A mobile network may comprise one or more subnetworks. Its size 328 could scale from a sole subnetwork with a few IP devices, such as 329 in the case of a PAN, to a collection of subnets with hundreds of 330 IP devices, such as in a train. 332 Large number of CNs 334 A mobile network may have a very large number of CNs. For 335 instance, each passenger in a train may be considered a MNN. Each 336 of them may be communicating with a few CNs. As a result, the 337 total number of CNs would be several times as large as the number 338 of MNNs and could scale up to a few thousands. 340 Nested mobility 342 A mobile network may comprise mobile nodes (local mobile nodes or 343 visiting mobile nodes) and even other mobile networks. For 344 instance, a bus is a mobile network whereas passengers are mobile 345 nodes or even mobile networks themselves if they carry a PAN. 347 Various mobility frequencies 349 Mobile networks may not move with the same speed and frequency. 350 For instance, a PAN connected to the Internet via a WLAN, or a car 351 connected to the Internet via GSM are likely to change their point 352 of attachment very quickly, while an aircraft or a boat may be 353 connected to the Internet via the same satellite link for a couple 354 of hours. Obviously, mobile networks may not move at all for a 355 large amount of time. 357 Multi-homing 359 A mobile network may be multi-homed. By multi-homing, we mean that 360 the MR may have two or more active interfaces connected to 361 distinct parts of the Internet, or the mobile network may be 362 connected to the Internet via tow or more MRs. In the first case, 363 we could think of a unique device used to connect a car both to 364 the cellular phone network and to a navigation satellite. In the 365 second case, we may think of a PAN where the GSM is used to 366 connect the PAN to the cellular phone network whereas a PDA is 367 used to collect bus timetables from the city bus network. 369 Routers in the mobile network 371 All routers in the Internet are considered to run a number of 372 protocols such as a routing protocol, Neighbor Discovery, ICMP, 373 and others. This also applies to any router in the mobile network, 374 including the mobile router. 376 Ad-hoc network 378 An ad-hoc network that changes its point of attachment to the 379 Internet may be seen as a mobile network. 381 Idle Mobile Network 383 A mobile network that does not engage in any communication outside 384 the network may be considered as idle from the point of view of 385 the fixed Internet, although there may be internal traffic between 386 any two MNNs. 388 Idle Mobile Network Node 390 A MNN that does not engage in any communication. 392 1.4. Aim of network mobility support 394 The purpose of network mobility support is to provide MNNs with an 395 uninterrupt Internet connectivity and to route datagrams between CNs 396 and MNNs by the most optimal path in both directions. 398 1.5. Assumption 400 We limit the scope of our study to mobile networks that are stub 401 networks, i.e. the mobile network does not forward traffic not 402 intended to itself. 404 1.6 Issues 406 Mobility of networks has an impact on routing, addressing, and a 407 number of network protocols. 409 1.6.1. Routing Issues 411 All packets sent to a MNN must transit through the current AR of 412 the mobile network and the MR itself. As a result of mobility, the 413 path to the mobile network is varying according to the AR to which 414 the MR is currently attached. We have to investigate how this path 415 could be determined in order to route packets via the most optimal 416 path. Particularly, we need to examine if this is best solved by 417 routing protocols or by some transient means as this is done for 418 mobile hosts. We need to investigate: 420 o if there is a need for a CN to determine that the node it is 421 corresponding with is in a mobile network. 423 o if there is a need to determine the topological location of 424 the mobile network or the mobile network node. 426 o if there is a need to determine the AR where the mobile 427 network is currently attached. 429 o if correspondent nodes should be aware of the topological 430 location of the mobile network or the mobile network node or if 431 this should this be transparent to them 433 o if forwarding should be established from a former AR to a 434 latter one. 436 1.6.2. Addressing Issues 438 o Impact on MR 440 Following existing IPv6 specifications, any host is in theory 441 required to obtain a topologically correct address on the link 442 on which it is currently attached to. We must investigate if 443 this can alternatively be done for a single host or for a 444 router and for a mobile network. If yes, this means that the 445 external interface of the mobile network is configured with the 446 foreign prefix. We also have to investigate if the 447 configuration of the MR's interface with a new address has an 448 impact on the MNNs. 450 o Impact on MNNs 452 As for MNNs, they don't actually change their own point of 453 attachment, then it is very questionable whether MNNs should 454 also get a topologically correct address that actually reflects 455 their topological [and hierarchical] location in the Internet. 456 If we conclude that mobile network nodes should get a 457 topologically correct address, we have to determine how this 458 could be performed internally in the mobile network. If we 459 renumber, we have to investigate how to maintain connections 460 and how and where to advertise the new address; if we do not 461 renumber, we have to investigate how to perform optimal routing 462 between CNs and MNNs. 464 1.6.3. Network Protocols Issues 466 As seen in section 1.3, all routers in a mobile network are 467 routers like the others and have to run a number of protocols. 468 Following the existing IPv6 specifications, they particularly 469 should run at least an instance of a routing protocol, and other 470 protocols like Neighbor Discovery, etc. We therefore have to 471 investigate how the network protocols running in the mobile 472 network must interact with the network protocols running in each 473 subsequent visited network and how the mobile router is going to 474 interact with the ARs it attaches to. This raises a number of 475 issues for each network protocol, as listed in the following 476 sections. 478 o Impact on Neighbor Discovery 480 One task of Neighbor Discovery is to send Router Advertisements 481 and Router Solicitations. When the mobile router is attached to 482 some AR in a visited network, it should receive such Router 483 Advertisements from its current AR. We have to investigate how 484 those Router Advertisements should be processed by the mobile 485 router and how the mobile router should interact with this 486 instance of the protocol running at the AR. We also have to 487 investigate what is the impact on this protocol when the mobile 488 network leaves its point of attachment. 490 o Impact on the Visited Network 492 We have to investigate if the subsequent ARs and the other 493 routers in the visited network should be aware that the 494 visiting mobile node is a router and not a host. In addition, 495 we have to examine if it is necessary to let them know that 496 there is an entire network behind the mobile router. In such a 497 case, a network route may have to be propagated in the visited 498 network and this raises an additional number of issues as 499 discussed in the section about routing protocols. 501 o Impact on Routing Protocols 503 We have to investigate how the mobile router interacts with the 504 routing protocols running at each of its subsequent ARs. The 505 impact may not be the same whether the mobile network is 506 limited to a single IP-subnet or a number of IP-subnets. 507 Indeed, a single mobile IP-subnet may not need to run an 508 instance of a routing protocol whereas a mobile network 509 comprising more than one router may. We have to evaluate what 510 kind of routing protocols may run in a mobile network and how 511 it interacts with the routing protocol running at each of its 512 subsequent ARs. 514 oo In case the mobile network is running the same routing 515 protocol as its ARs, it is questionable whether the mobile 516 network should participate or not in the routing protocol 517 running in the visited network. If it does, the mobile 518 network can be seen as a partition of the local network. The 519 topology computed by the routing protocol becomes more 520 dynamic and we have to evaluate how existing protocols are 521 able to handle this case. Moreover, mobility may cause a 522 routing table partition. 524 oo In case the mobile network doesn't participate in the 525 routing protocol running in the visited network, the mobile 526 network can be seen as a kind of Autonomous System that is 527 running an instance of an Internal Gateway Protocol. 529 routing protocol running in the mobile network and the routing 530 protocol running in the visited network. In addition, we must 531 determine what routing protocol is suitable within the mobile 532 network. We also have to evaluate the impact on routing 533 protocols when the mobile router is multi-homed, when the 534 mobile network comprises more than one mobile router, and when 535 the mobile network itself receives another mobile network. 537 1.6.4. Security Issues 539 All security concerns that usually apply to host mobility support 540 also apply to network mobility support. We may face a number of 541 additional ones that complement the addressing issues, network 542 protocols issues, and routing issues depicted in the previous 543 sections. 545 2. Constraints and Requirements 547 2.1. Constraints 549 2.1.1. Host Mobility Support constraints 551 LMNs and VMNs that operate Mobile IPv6 must still be able to use 552 the same protocol once located in a mobile network. If needed, 553 the solution to support mobile networks has to provide the 554 necessary Mobile IPv6 extensions. 556 2.1.2. Addressing constraints 558 The network part of IP addresses is used for routing and 559 identifying the subnetwork in the topology. Every interface 560 attached to a subnetwork must have a unique address with the 561 network part identifying the subnetwork. 563 2.1.3. IPv6 constraints 565 In order not to re-invent the wheel, any solution has to be based 566 on IPv6 protocols. It is also desirable that it becomes an 567 integral part of the existing protocol suite. It is desirable to 568 introduce new features as extensions to the existing protocols 569 with minimum modifications. 571 2.1.4. Security constraints 573 Any solution must comply with IPv6 security policies. 575 2.2. Requirements 577 Requirements relative to mobility of hosts are discussed in most 578 published papers in the field of mobile networking as found in [1] 579 and also [7, 4]. [OTHERS]. Most of them are equally applicable to 580 network mobility support, with some additions. 582 2.2.2. Wide-Area mobility support 584 A truly worldwide mobility support requires international 585 standards in order to move between heterogeneous networks, i.e. 586 wide-area mobility. A lack of international standardization would 587 prevent from this. We must avoid a situation where distinct 588 Internet Service Provider would develop distinct network mobility 589 support schemes which are unable to inter-operate with each other. 590 Not only standard between countries and organizations is required, 591 but also between networks in which different policies may apply. 592 Indeed, nothing but administrative and security policies should 593 prevent a mobile network to attach anywhere in the Internet. For 594 doing so, we need a mobility support scheme that fits well into 595 the existing standards, that is easy to deploy and that does not 596 require too much additional services in the network. 598 2.2.3. Security 600 Unlike fixed nodes, MNNs are more exposed to security issues and 601 identity usurpation. Mobility support must provide MNNs and their 602 CNs with at least as good security as for fixed nodes and single 603 mobile nodes. In practice, network mobility support signalling 604 must be exchanged in a secure manner and must ensure the 605 following: 607 o Confidentiality 609 Mobility support must ensure confidentiality of all control 610 datagrams transmitted between MNNs and CNs in any direction to 611 insure MNNs' confidentiality. If requested, only the recipient 612 must be able to decrypt the content of the datagram. 614 o Authentication All control messages must be 615 authenticated by recipients in order to prevent intruders to 616 usurp the identity of a MNN. Mobility support shouldn't leave 617 more room for intruders to usurp an identify nor to perpetrate 618 any kind of attack against MNNs or CNs. 620 o Authorization 621 Mobility support must ensure that a node which performs a 622 mobility management operation is effectively authorized to 623 perform such an operation. 625 o Location Privacy 627 Mobility support has to provide means for to keep the location 628 of MNNs secret to any third party. It shouldn't be possible to 629 determine the topological location of a mobile network and its 630 MNNs by monitoring control messages exchanged between any two 631 nodes. In practice, MNNs may wish to hide their location to 632 some or all of their CNs. The network administrator may also 633 wish to hide the location of the mobile network to all CNs 634 without discrimination between MNNs. 636 2.2.4. Transparency 638 o Mobility Transparency 640 With respect to the layer separation of the Internet protocol 641 suite, handover of IP sessions should be transparent at layers 642 above the network layer. At least, there shouldn't be an abrupt 643 interruption of the IP sessions. This means that a mobile 644 network is always reachable regardless of its point of 645 attachment. Particularly, mechanism have to be added so that 646 transiting datagrams are forwarded to the current location of 647 the mobile network. 649 o Operational Transparency 651 From an application's point of view, continuous access to the 652 Internet must be maintained regardless of the location of the 653 mobile network. Moreover, it is required that the application 654 does not need to perform any action to remain connected. This 655 means that mobility support should be performed at the network 656 layer. It is the responsibility of the network protocols to 657 support connectivity of the network in an absolute transparent 658 manner to the applications. 660 o Mobility management transparency for MNNs 662 We have seen that MNNs appear to move from the point of view of 663 their CNs although do not change their point of attachment 664 within the mobile network. Mobility management of a mobile 665 network is therefore better seen as MR's responsibility and 666 should be transparent to MNNs. MNNs should have no 667 responsibility in network mobility management. They should only 668 be concerned about managing their own mobility if they 669 themselves appear to change their point of attachment. However, 670 MNNs may encounter variable delays of transmission and loss 671 with their respective CNs as the network is moving. 673 o Performance Transparency 675 Network mobility support should exhibit low latency, incur 676 little or no data loss, minimum delays, scale to a large 677 internetwork, incur minimum signalling load, bandwidth 678 consumption for datagrams delivery and memory requirements, as 679 seen in [3]. The solution is termed "efficient" provided 680 mobility is supported without performance degradation of the 681 Internet. Loss and delays should indeed range into those 682 experimented for communication flows between two fixed nodes. 683 Moreover, both local-area mobility and wide-area mobility need 684 to be handled as efficiently. At last, the addition of network 685 mobility support shouldn't impact the performance of upper 686 layers. In order to limit losses during hand-offs and to avoid 687 degradation of performance at the upper layers, it may be 688 necessary to perform seamless handovers. 690 o Layers Independence 692 Support of mobility is best managed at the network layer. A 693 change of topological location therefore shouldn't have any 694 repercussion at other layers of the TCP/IP reference model. If 695 this is respected, compatibility with existing transport and 696 application layers is maintained. Support of mobility in 697 transport and application protocols is not the focus of this 698 study. 700 2.2.5. Optimal routing 702 The amount of traffic intended for the mobile network is 703 understandably more significant than in the case of a single 704 mobile node. Non-optimal routing therefore becomes an even more 705 important issue that it was already for mobile nodes. Avoiding 706 triangle routing reduces bandwidth consumption and transmission 707 delays. 709 2.2.6. Minimum signalling overload 711 Routing packets efficiently from a CN to the current location of 712 the mobile network may be performed at the cost of control 713 traffic. The cost of this control traffic has to be balanced 714 against the expected gain of optimal routing. Minimizing the 715 amount of control traffic has always been an important concern for 716 host mobility support. Due to a potentially large number of CNs, 717 this becomes an even more important concern for network mobility 718 support. 720 2.2.7. Scalability 722 Scalability has always been an important concern in the design of 723 new protocols. As far as host mobility is concerned, mobility 724 support has to take into consideration a growing number of mobile 725 hosts and should even assume that a major part of the nodes 726 composing the Internet are mobile in the near future. This means 727 that signalling load and memory consumption should scale to an 728 important number of mobile nodes. Network mobility support has to 729 address scalability in two ways: 731 o Large number of mobile networks Scaling to a large 732 number of mobile networks as hosts mobility support is required 733 to scale to a large number of mobile nodes. 735 o Large number of correspondent nodes Scaling to the size 736 of large mobile networks comprising hundreds of MNNs 737 communicating with an important number of CNs. 739 In other words, mobile network support must be able to support 740 large mobile networks containing hundreds of nodes like a train 741 and corresponding with thousands of CNs, and a very large number 742 of small mobile networks such as PANs comprising a few IP devices. 743 Scaling to a large number of CNs indeed deserves more 744 consideration than scaling to a large number of mobile networks. 746 2.2.8. Nested mobility 748 Network mobility support must allow VMNs to visit the mobile 749 network and LMNs to leave it. Basically, a VMN should be able to 750 operate Mobile IPv6 or any forthcoming standard. Network mobility 751 support should therefore consider both mobile networks and mobile 752 nodes, otherwise it may hardly interact with host mobility 753 support. In practice, it should handle visiting mobile nodes as 754 optimally as if networks where fixed. It is also advisable to 755 consider the special case where the correspondent node is itself 756 mobile or located in a mobile network. 758 2.2.9. Backward compatibility 760 Backward compatibility corresponds to the ability to leave the 761 actual protocol suite unchanged. This was an important issue for 762 IPv4 since it is not possible to require all hosts to implement 763 new features in order to manage mobility. On the other hand, the 764 emergence of IPv6 is an opportunity for making the necessary 765 changes. Backward compatibility is not an issue at the time being 766 although IPv6 itself has to interwork with IPv4. Indeed, IPv6 767 offers the possibility to add new features until the IPv6 768 specification is fully ratified. There is still scope for adding 769 new capabilities if needed. 771 2.2.10. Minimum Impact on Existing Protocols 773 In order to provide a deployable solution and to allow wide-area 774 mobility, a good solution should better make use of the existing 775 protocols whenever possible and impose minimum changes or 776 extensions on the existing ones. 778 References 780 [1] Pravin Bhagwat, Satish Tripathi, and Charles Perkins. Network 781 Layer Mobility: an Architecture and Survey. IEEE Personal 782 Communications, 3(3):54, June 1996. 784 [2] Editor R. Braden. Requirements for Internet Hosts - Communication 785 Layers. Request For Comments 1122, Internet Engineering Task Force 786 (IETF), October 1989. 788 [3] Ramon Caceres and Venkata N. Padmanabhan. "fast and scalable 789 handoffs for wireles internetworks". In Proc. of the Second ACM/IEEE 790 International Conference on Mobile Computing and Networking 791 (MobiCom), Rye, New York, USA, November 1996. Bell Laboratories and 792 University of California at Berkeley. 794 [4] Claude Castelluccia. A Hierarchical Mobility Management Scheme 795 for IPv6. Third Symposium on Computers and Communications (ISCC'98), 796 Athens, Greece, June 1998. http://sirac.inrialpes.fr/planete 798 [5] S. Deering and R. Hinden. Internet Protocol Version 6 (IPv6) 799 Specification. Request For Comments 2460, Internet Engineering Task 800 Force (IETF), December 1998. 802 [6] David B. Johnson and C. Perkins. Mobility Support in IPv6. 803 Internet Draft draft-ietf-mobileip-ipv6-14.txt, Internet Engineering 804 Task Force (IETF), July 2001. Work in progress. 806 [7] Andrew Myles and David Skellern. Comparing Four IP Based Mobile 807 Host Protocols. In Joint- European Networking Conference. Macquarie 808 University, Sydney, Australia, May 1993. 810 [8] Thomas Quinot. An IPv6 architecture for Aeronautical 811 Telecommunication Network. Master's thesis, Ecole Nationale 812 Sup'erieure des T'el'ecommunications Paris, EUROCONTROL - European 813 Organization for the Safety of Air Navigation - ISA project (IPv6, 814 Satellite communication and ATMode for ATN), 1998. 815 http://www.eurocontrol.fr/. 817 Author's Addresses 819 Questions about this document can be directed to the authors: 821 Thierry Ernst 822 Motorola Labs Paris and INRIA - PLANETE team Grenoble 823 ZIRST - 655 avenue de l'Europe 824 38330 Montbonnot Saint Martin, France 825 http://www.inrialpes.fr/planete/ 826 Phone: +33 4 76 61 52 69 827 Email: Thierry.Ernst@inrialpes.fr 829 Hong-Yon Lach 830 Motorola Labs Paris, Lab Manager, 831 Networking and Applications Lab (NAL) 832 Espace Technologique - Saint Aubin 833 91193 Gif-sur-Yvette Cedex, France 834 Phone: +33 1 69 35 25 36 835 Email: Hong-Yon.Lach@crm.mot.com 837 Claude Castelluccia 838 INRIA - PLANETE team Grenoble 839 ZIRST - 655 avenue de l'Europe 840 38330 Montbonnot Saint Martin, France 841 Phone: +33 4 76 61 52 15 842 Email: Claude.Castelluccia@inrialpes.fr