idnits 2.17.1 draft-ernst-monet-terminology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 532: '... to be NEMO-enabled. However, MNNs MAY...' 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 (July 2002) is 7956 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Perkins98' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC2002' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'REQUIREMENTS-2' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'SCOPE' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC1726' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'REQUIREMENTS-3' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'Solomon98' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'WEB-MONET' is defined on line 729, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Perkins98' ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) -- Possible downref: Normative reference to a draft: ref. 'REQUIREMENTS-2' -- No information found for draft-soliman-monet-scope - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SCOPE' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'Ernst01' == Outdated reference: A later version (-07) exists of draft-ietf-multi6-multihoming-requirements-03 ** Downref: Normative reference to an Informational draft: draft-ietf-multi6-multihoming-requirements (ref. 'MULTI6') -- Possible downref: Normative reference to a draft: ref. 'OLD-draft' -- Possible downref: Non-RFC (?) normative reference: ref. 'Quinot98' ** Downref: Normative reference to an Informational RFC: RFC 1726 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Normative reference to a draft: ref. 'REQUIREMENTS-1' -- Possible downref: Normative reference to a draft: ref. 'REQUIREMENTS-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'Solomon98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tanenbaum96' -- Possible downref: Non-RFC (?) normative reference: ref. 'WEB-MONET' Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF INTERNET-DRAFT Thierry Ernst 3 WIDE Project and INRIA 4 Hong-Yon Lach 5 Motorola Labs 6 July 2002 8 Network Mobility Support Terminology 9 draft-ernst-monet-terminology-01.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 document proposes a terminology for defining the problem faced 34 by network mobility. Network mobility is concerned with situations 35 where an entire network changes its point of attachment to the 36 Internet and thus its reachability in the topology. We shall refer to 37 such a network as a mobile network. Network mobility support is to 38 maintain session continuity between nodes in the mobile network and 39 nodes in the global Internet. 41 Contents 43 Status of This Memo 45 Abstract 47 1. Introduction 49 2. Terminology 50 2.1. Architecture Components 51 2.2. Nested Mobility 52 2.3. Miscellaneous Terms 54 3. Characteristics / Observations 56 4. Changes since last version of the draft 58 Acknowledgments 60 References 62 Author's Addresses 64 1. Introduction 66 A mobile network is an entire network, moving as a unit, which 67 changes its point of attachment to the Internet and thus its 68 reachability in the topology. A mobile network may be composed by one 69 or more IP-subnets and is connected to the global Internet via one or 70 more Mobile Routers (MR). Nodes behind the MR primarily comprise 71 fixed nodes (nodes unable to change their point of attachment while 72 maintaining ongoing sessions), and additionally mobile nodes (nodes 73 able to change their point of attachment while maintaining ongoing 74 sessions). The internal configuration of the mobile network is 75 assumed to be relatively stable with respect to the MR. 77 If network mobility is not explicitly supported by some mechanisms 78 once a MR changes its point of attachment, existing sessions between 79 CNs and nodes behind the MR are broken, and connectivity to the 80 global Internet is lost. In addition, fixed nodes behind the MR may 81 experiment dog-leg routing, whereas multiple levels of mobility may 82 cause multiple dog-leg routing. Traditional work on mobility support 83 as conducted in the Mobile IP working group is to provide continuous 84 Internet connectivity to mobile hosts only (host mobility support) 85 and are unable to support network mobility. It is thus proposed to 86 create a NEMO working group that would specify solutions for network 87 mobility support (the proposed name for the working group was renamed 88 from MONET to NEMO). 90 Cases of mobile networks include networks attached to people 91 (Personal Area Network or PAN, i.e. a network composed by all 92 Internet appliances carried by people, like a PDA, a mobile phone, a 93 digital camera, a laptop, etc.) and networks of sensors deployed in 94 aircrafts, boats, busses, cars, trains, etc. An airline company that 95 provides permanent on-board Internet access is an example of a mobile 96 network. This allows passengers to use their laptops (this scenario 97 is mentioned in [Tanenbaum96] under section 1.2.4 and section 5.5.8; 98 [Perkins98] under section 5.12; [Solomon98] under section 11.2; and 99 [RFC2002] section 4.5), PDA, or mobile phone to connect to remote 100 hosts, download music or video, browse the web. Passengers could 101 themselves carry a network with them (a PAN). At the same time, air 102 control traffic could be exchanged between the aircraft and air 103 traffic control stations (this scenario has already been investigated 104 by Eurocontrol, the European Organization for the safety of air 105 navigation, [Quinot98]). During a transatlantic flight, the aircraft 106 changes its point of attachment to the Internet and may be reachable 107 by distinct Internet Service Providers (ISPs). Over the oceans, the 108 aircraft gets connected to the Internet through a geostationary 109 satellite; over the ground, it's through a radio link. Handoffs do 110 typically not occur very often (a radio link may cover 400-500 111 kilometers). Another similar scenario mentioning ships and aircrafts 112 can be found in [RFC1726, section 5.15]. Similarly, a bus, the 113 metropolitan public transport, or the taxi company could allow 114 passengers to connect their PAN to the Internet via the embarked 115 network, therefore ensuring, while on-board, an alternative to the 116 metropolitan cellular network, in terms of price or available 117 bandwidth, access control, etc. Meanwhile, a number of Internet 118 appliances deployed in the mobile network are used to collect traffic 119 and navigation data from the Internet while sensors within the mobile 120 network collect and transmit to the Internet live information, like 121 the current number of passengers, expected time to arrival, the 122 amount of petrol left in the tank, etc. For a number of reasons 123 (network management, security, performance,...), it is desirable to 124 interconnect the Internet appliances deployed in cars, trains, busses 125 by means of, for instance, an Ethernet cable, instead of connecting 126 them individually and directly to the Internet, therefore exhibiting 127 the need to displace an entire network. 129 To describe such kind of scenarios, we need to agree on a 130 terminology. However, there is presently no existing terminology to 131 define the issues, goals, architecture elements, problems and 132 requirements pertaining to the scenarios outlined here above, but one 133 is needed. It is therefore the object of this document to propose 134 such a new terminology and to highlight some characteristics of 135 mobile networks. 137 The material presented in this document is based on [Ernst01] and on 138 our former internet-draft that was submitted in July 2001 [OLD-draft] 139 for the consideration of the Mobile IP Working Group. In addition to 140 the present terminology, this former draft was also presenting a set 141 of requirements and issues as an attempt to clarify the problem 142 caused by network mobility. We decided to split this former document 143 in two because requirements are more subject to discussion and 144 disagreements than the terminology on which we must agree on to base 145 our discussion. Our proposed requirements can therefore now be found 146 in [REQUIREMENTS-1]. Additional requirements may be found in 147 [REQUIREMENTS-2] and [REQUIREMENTS-3]. A comprehensive description of 148 the problem and issues posed by network mobility is discussed in 149 [SCOPE]. More information may be found on the MONET web page [WEB- 150 MONET]. 152 2. Terminology 154 The new terms we introduce comply with the terminology already 155 defined in the IPv6 [RFC2460] and Mobile IPv6 [MIPv6] specifications. 156 Although our terminology is primarily targeted toward IPv6, it is not 157 necessarily limited to it. This list comprises terms that appeared on 158 the mailing list for the purpose of explaining the problem scope. 159 Some of them may only be useful for the purpose of defining the 160 problem scope and functional requirements of network mobility 161 support. Definitions will have to be refined once we agree on the 162 problem scope. 164 The first section introduces terms to define the architecture 165 components; the second introduces terms to discuss nested mobility; 166 the last section introduces a number of other terms useful to discuss 167 requirements. 169 2.1. Architecture Components 171 Mobile Network 173 An entire network, moving as a unit, which dynamically changes its 174 point of attachment to the Internet and thus its reachability in 175 the topology. The mobile network is connected to the global 176 Internet via one or more mobile router(s) (MR). The internal 177 configuration of the mobile network is assumed to be relatively 178 stable with respect to the MR and is not a matter of concern. 180 Mobile Network Node (MNN) 182 Any host or router located within the mobile network, either 183 permanently or temporarily. A MNN could be any of a MR, LFN, VMN, 184 or LMN. The distinction between LFN, LMN and VMN is necessary to 185 discuss issues related to mobility management and access control, 186 but does not preclude that mobility should be handled differently. 187 Nodes are classified according to their function and capabilities. 189 ____ 190 | | 191 | CN | 192 |____| 193 ___|____________________ 194 | | 195 | | 196 | Internet | 197 | | 198 |________________________| 199 __|_ __|_ 200 | | Access | | 201 | AR | Router | AR | 202 |____| |____| 203 ______|__ foreign __|_____________ home 204 link __|_ link 205 | | 206 | MR | Mobile Router 207 |____| 208 _________|_______ internal 209 __|__ __|__ link 210 | | | | 211 | MNN | | MNN | Mobile Network Nodes 212 |_____| |_____| 214 Figure 1: Terminology 216 Mobile Router (MR) 218 A router which changes its point of attachment to the Internet and 219 which acts as a gateway to route packets between the mobile 220 network and the rest of the Internet. The MR is NEMO-enabled and 221 maintains the Internet connectivity for the mobile network. It has 222 at least two interfaces, an egress interface, and an ingress 223 interface. When transmitting a packet to the Internet (i.e. 224 outside), it forwards it through the egress interface; when 225 transmitting it withing the mobile network (i.e. inside), it 226 forwards it through the ingress interface. 228 Local Fixed Node (LFN) 230 A standard IPv6 node, either a host (LFH) or a router (LFR), that 231 belongs to the mobile network and which has no mobility support 232 capabilities at all (i.e. it isn't NEMO-enabled nor 233 MIPv6-enabled). 235 ____ 236 | | 237 | CN | 238 |____| 239 ___|____________________ 240 | | 241 | | 242 | Internet | 243 | | 244 |________________________| 245 __|_ __|_ 246 | | Access | | 247 | AR | Router | AR | 248 |____| |____| 249 __|_ _____|_____________ home 250 | | _|__ link 251 | MN ] | | | 252 |____| |__| MR | Mobile Router 253 | |____| 254 | __|_____________ internal 255 | __|__ __|__ link 1 256 _____ | | | | | 257 | |__| | LFN | | LMN | 258 | LFN | | |_____| |_____| 259 |_____| | 260 | internal 261 link 2 263 Figure 2: Larger Mobile Network with 2 subnets 265 Local Mobile Node (LMN) 267 A mobile node, either a host (LMH) or a router (LMR), that belongs 268 to the mobile network (i.e. its home link is within the mobile 269 network). It is MIPv6-enabled and may be NEMO-enabled. 271 Visiting Mobile Node (VMN) 273 A mobile node, either a host (VMH) or a router (VMR), that doesn't 274 belong to the mobile network (i.e. its home link is not within the 275 mobile network), and which gets attached to a link within the 276 mobile network and obtains an address on that link. It is 277 MIPv6-enabled and may be NEMO-enabled. 279 ____ 280 | | 281 | CN | 282 |____| 283 ___|____________________ 284 | | 285 | | 286 | Internet | 287 | | 288 |________________________| 289 __|_ __|_ 290 | | Access | | 291 | AR | Router | AR | 292 |____| |____| 293 __|_ _____|_____________ home 294 | | _|__ link 295 | MN | | | | 296 |____| _____ |__| MR | Mobile Router 297 | |__| |____| 298 |--> | LMN | | __|_____________ internal 299 | |_____| | __|__ | link 1 300 | _____ | | | 301 | | |__| | LFN | 302 | | LFN | | |_____| | 303 | |_____| | | 304 | | internal | 305 | link 2 | 306 |------------------------------| 308 Figure 3: LMN changing subnet 310 Node behind the MR 312 Any MNN in a mobile network that is not a MR for this mobile 313 network. 315 Correspondent Node (CN) 317 Any node that is communicating with one or more MNNs located in 318 the same mobile network. A CN could itself be located within the 319 mobile network. 321 Access Router (AR) 323 Any subsequent point of attachment of the MR at the network layer. 324 Basically, a router on the home link or the foreign link. 326 Home subnet prefix 328 A bit string that consists of some number of initial bits of an IP 329 address which identifies the MR's home link within the Internet 330 topology (i.e. the IP subnet prefix corresponding to the mobile 331 node's home address, as defined in [MIPv6]). 333 Foreign subnet prefix 335 A bit string that consists of some number of initial bits of an IP 336 address which identifies the MR's foreign link within the Internet 337 topology. 339 Mobile Network Prefix 341 A bit string that consists of some number of initial bits of an IP 342 address which identifies the entire mobile network within the 343 Internet topology. All MNNs necessarily have an address named 344 after this prefix. 346 Egress Interface of a MR 348 The interface attached to the home link if the MR is at home, or 349 attached to a foreign link if the MR is in a foreign network. 351 Ingress Interface of a MR 353 The interface attached to a link inside the mobile network. This 354 interface is configured with the Mobile Network Prefix. 356 The terminology is summarized in fig.1 to 3. Fig.1 shows a single 357 mobile subnetwork. Fig.2. shows a larger mobile network comprising 358 several subnetworks. Fig.3 illustrates a LMN changing its point of 359 attachment within the mobile network. 361 2.2. Nested Mobility 363 We speak about nested mobility when there are more than one level of 364 mobility, i.e. when a VMN gets attached to the mobile network. A MNN 365 acts as an Access Router for this VMN. 367 If the VMN is actually a VMR with nodes behind it, this is a mobile 368 network which gets attached to a larger mobile network. The former is 369 a sub-MONET, and the latter the parent-MONET. It is generally 370 assumed that the sub-MONET and the parent-MONET become a single 371 aggregated mobile network, i.e. the sub-MONET is indeed a subservient 372 of the larger MONET in terms of getting address space. 374 The MR(s) used to directly connect the aggregated mobile network to 375 the fixed Internet is referred to as the Top-Level Mobile Router 376 (TLMR) The terms upstream-MONET, downstream-MONET, and root-MONET 377 have also been introduced. 379 ____ 380 | | 381 | CN | 382 |____| 383 ___|____________________ 384 | | 385 | | 386 | Internet | 387 | | 388 |________________________| 389 __|_ __|_ 390 | | Access | | 391 | AR | Router | AR | 392 |____| |____| 393 _____|_____________ home 394 | _|__ link 395 | | | | 396 | _____ |__| MR | Mobile Router 397 | | |__| |____| 398 ----------> | VMN | | __|_____________ internal 399 |_____| | __|__ __|__ link 1 400 _____ | | | | | 401 | |__| | LFN | | LMN | 402 | LFN | | |_____| |_____| 403 |_____| | 404 | internal 405 link 2 407 Figure 4: Nested Mobility: single VMN that attaches to a mobile network 409 As for an instance of nested mobility, when a passenger carrying a 410 mobile phone (VMN) or a PAN (sub-MONET) gets Internet access from 411 the public access network deployed in the bus (parent-MONET). 412 Fig.4 and 5. illustrate nested mobility. In fig.4, a single VMN 413 gets attached to the mobile network. In fig 5, a VMR carrying an 414 entire network, thus a sub-MONET. 416 ____ 417 | | 418 | CN | 419 |____| 420 ___|____________________ 421 | | 422 | | 423 | Internet | 424 | | 425 |________________________| 426 __|_ __|_ 427 | | Access | | 428 | AR | Router | AR | 429 |____| |____| 430 _____|_____________ home 431 _|__ link 432 | | | 433 | _____ |__| MR | Mobile Router (TLMR) 434 |_| |__| |____| 435 | | VMR | | __|_____________ internal 436 | |_____| | __|__ __|__ link 1 437 _____ | | | | | | 438 | | | | | LFN | | LMN | 439 | LFN |__| | |_____| |_____| 440 |_____| | | 441 | | internal 442 link 2 443 <------------------> <---------------------------> 444 sub-MONET parent-MONET 445 Figure 5: Nested Mobility: sub-MONET that attaches to a larger 446 mobile network 448 2.3. Miscellaneous Terms 450 NEMO-enabled node 452 a node that has been extended with NEtwork MObility support 453 capabilities and may take special actions based on that. (Details 454 of the capabilities are not known yet, but it will be based on 455 enhancements to Mobile IPv6 [MIPv6] and may be implementing some 456 sort of Route Optimization). 458 MIPv6-enabled node 460 A mobile node that implements the "MN Operation" of Mobile IPv6 462 [MIPv6]. I.e. A node that only implements the "CN Operation" of 463 Mobile IPv6 is NOT considered MIPv6-enabled. 465 Multihoming 467 Multihoming, as currently defined by the IETF, covers site- 468 multihoming [MULTI6] and host multihoming. Within host- 469 multihoming, a host may be either: 471 - multi-addressed: multiple source addresses to choose between 472 on a given interface; all IPv6 nodes are multi-addressed due to 473 the presence of link-local addresses on all interfaces. 475 - multi-interfaced: multiple interfaces according to [RFC2460] 476 definition. 478 - multi-linked: just like multi-interfaced but all interfaces 479 are NOT connected to the same link. 481 - multi-sited: when using IPv6 site-local address and attached 482 to different sites 484 What is meant by a multihomed-MONET is not clear and is left for 485 open discussion. It depends on the possible configurations covered 486 by the revised problem scope. Future discussion will assess if a 487 MR may fall in all the above described cases and if multiple MRs 488 may be used to connect the mobile network to the Internet. 490 Local-Area Mobility 492 Mobility within a single administrative domain, i.e. between 493 subnetworks topologically close in the IP hierarchy. In the 494 literature, and depending on the definition of ``closeness'', this 495 is also termed intra-site mobility, intra-domain mobility, local 496 mobility or micro-mobility. As an instance of Local-Area Mobility, 497 the displacement of a node within a limited vicinity of adjacent 498 subnetworks, like in a campus, that belong to the same 499 organization or between ARs that belong to the same ISP. 501 Wide-Area Mobility 503 Mobility across domain boundaries, i.e. between subnetworks 504 topologically distant in the IP hierarchy. In the literature, and 505 depending on the definition of ``remoteness'', this is also termed 506 inter-site mobility, inter-domain mobility, or global mobility, or 507 macro-mobility. As an instance of Wide-Area Mobility, displacement 508 of a node between distinct ISPs or organizations, or between 509 widely separated sites of a single organization. 511 Idle MNN 513 A MNN that does not engage in any communication. 515 Idle Mobile Network 517 A mobile network that does not engage in any communication outside 518 the network may be considered as idle from the point of view of 519 the Internet. This doesn't preclude that MNNs are themselves idle. 520 Internal traffic between any two MNNs located in the same mobile 521 network is not concerned by this statement. 523 3. Observations 525 Structure of the mobile network 527 A MR changing its point of attachment does not cause the MNNs 528 behind the MR to change their own physical point of attachment. 529 Thus, the internal structure of a mobile network is not modified 530 as a result of the mobile network changing its point of 531 attachment. MNNs may or may not notice such a displacement, but 532 they must not be required to be NEMO-enabled. However, MNNs MAY 533 appear to move from the point of view of an observer in the 534 Internet. In addition, the internal structure of the mobile 535 network is assumed to be relatively stable (no dynamic change of 536 the topology). 538 Mobile Router is a transit point 540 All packets sent from a CN to a MNN necessarily transit through a 541 MR. 543 Size of the mobile network 545 A mobile network may comprise one or more subnets. Its size could 546 scale from a sole subnet with a few IP devices, such as in the 547 case of a PAN, to a collection of subnets with hundreds of IP 548 devices, such as in a train. 550 Large number of CNs 552 A mobile network may have a very large number of CNs. For 553 instance, each passenger in a train may be considered a MNN. Each 554 of them may be communicating with a few CNs. As a result, the 555 total number of CNs could be several times as large as the number 556 of MNNs and scale up to a few thousands. 558 Sparseness of the CNs 560 CNs are typically sparsely distributed in the Internet and belong 561 to distinct administrative domains. 563 Handoff frequency 565 Mobile networks may not move with the same speed and frequency. 566 For instance, a PAN connected to the Internet via a 802.11b WLAN 567 (e.g. user in a shopping mall) is likely to change its point of 568 attachment very frequently, while an aircraft or a boat may be 569 connected to the Internet via the same satellite link for a couple 570 of hours. Obviously, mobile networks may not move at all for a 571 large amount of time. 573 Dog-leg Routing 575 As a result of mobility, routing between a CN in the global 576 Internet and a mobile node may not be optimal. Packets usually 577 transit via the home link of the mobile node if no routing 578 optimization is explicitly performed. In network mobility, 579 multiple dog-leg routing may be introduced by nested mobility. In 580 this case, packets intended to a VMN may first transit by the 581 VMN's home link, then being rerouted to the MR's home link. 583 Ad-Hoc Network 585 An Ad-hoc network as defined in the IETF MANET Working Group is 586 not to be confused with a mobile network. An ad-hoc network is an 587 autonomous system made of mobile nodes (i.e. routers) connected by 588 wireless links. The routers are free to move randomly and to 589 organize themselves arbitrary. Topologies are highly dynamic. In a 590 mobile network, some routers may effectively move arbitrary, but 591 this not a common case. However, an Ad-hoc network connected to 592 the Internet and that changes its point of attachment may be 593 considered as a special instance of a mobile network. 595 Network mobility support (NEMO) and Mobile Ad-hoc Networking 596 (MANET) have not the same objectives. Network mobility support 597 aims at providing Internet reachability to nodes in the mobile 598 network and at maintaining session continuity after the mobile 599 network has changed its point of attachment in the topology. On 600 the other hand, MANET aims at maintaining routes between highly 601 dynamic nodes. 603 Routers in the Mobile Network 605 All routers in the Internet are considered to run a number of 606 protocols such as a routing protocol, Neighbor Discovery, ICMP, 607 and others. This also applies to routers in the mobile network, 608 including the MR. 610 4. Changes from previous draft 612 - updated definition of LFN, LMN, VMN, mobile network, mobile network 613 prefix, CN 615 - added terms NEMO-enabled and MIPv6-enabled. 617 - added a section (2.2) for terminology specific to nested mobility: 618 root-MONET, parent-MONET, sub-MONET, upstream, downstream. 620 - added a paragraph about multihoming 622 - removed mobile IP-subnet. 624 - added comments about Ad-Hoc network in section 3 626 - added comments about multiple dog-leg routing in section 3 628 Acknowledgments 630 The first author would like to thank both Motorola Labs Paris and 631 INRIA Rh�ne-Alpes, for the opportunity to bring this topic to the 632 IETF, and particularly Claude Castelluccia (INRIA) for its advices, 633 suggestions, and direction. We also acknowledge Alexandru Petrescu 634 (Motorola), Christophe Janneteau (Motorola), Hesham Soliman 635 (Ericsson) and Mattias Petterson (Ericsson) for their comments on 636 this draft. We also thank people on the MONET mailing list for their 637 discussion which helped to improve this draft. 639 References 641 [Ernst01] Thierry Ernst 642 "Network Mobility Support in IPv6", PhD Thesis, 643 University Joseph Fourier Grenoble, France. October 644 2001. 646 [MIPv6] David B. Johnson and C. Perkins. 647 "Mobility Support in IPv6". 648 Internet Draft draft-ietf-mobileip-ipv6-14.txt, July 649 2001. 650 Work in progress. 652 [MULTI6] B. Black, V. Gill and J. Abley 653 "Requirements for IPv6 Site-Multihoming 654 Architectures" 655 draft-ietf-multi6-multihoming-requirements-03 656 May 2002. Work in progress 658 [OLD-draft] Thierry Ernst, Hong-Yon Lach, Claude Castelluccia 659 "Network Mobility Support in IPv6: Problem Statement 660 and 661 Requirements", 662 Internet-Draft draft-ernst-mobileip-monetv6-00.txt, 663 July 2001. 664 Expired. 666 [Perkins98] C. E. Perkins. 667 "Mobile IP, Design Principles and Practices." 668 Wireless Communications Series. Addison-Wesley, 669 1998. 670 ISBN 0-201-63469-4. 672 [Quinot98] Thomas Quinot. 673 "An IPv6 architecture for Aeronautical 674 Telecommunication Network" 675 Master's thesis, 676 Ecole Nationale Superieure des Telecommunications 677 Paris, 678 EUROCONTROL - European Organization for the Safety 679 of Air Navigation 680 ISA project (IPv6, Satellite communication and 681 ATMode for ATN), 682 1998. http://www.eurocontrol.fr/. 684 [RFC1726] C. Partridge 685 "Technical Criteria for Choosing IP the Next 686 Generation (IPng)", 687 IETF RFC 1726 section 5.15, December 1994. 689 [RFC2460] S. Deering and R. Hinden. 690 "Internet Protocol Version 6 (IPv6) Specification". 691 IETF RFC 2460, December 1998. 693 [RFC2002] C. Perkins (Editor). 694 "IP Mobility Support". 695 IETF RFC 2002,October 1996. 697 [REQUIREMENTS-1] Thierry Ernst, Hong Yon Lach 698 "Requirements for Network Mobility Support", 699 Internet-Draft draft-ernst-monet- 700 requirements-00.txt, 701 February 2001. Work in progress. 703 [REQUIREMENTS-2] Hong-Yon Lach, Christophe Janneteau, Alexandru 704 Petrescu 705 "Mobile Network Scenarios, Scope and Requirements", 706 Internet-Draft draft-lach-monet-requirements-00.txt, 707 February 2002. Work in progress. 709 [REQUIREMENTS-3] T.J. Kniveton 710 draft-kniveton-monet-requirements.txt, February 711 2002. 712 Work in progress. 714 [SCOPE] Hesham Soliman 715 "Problem Scope", 716 Internet-Draft draft-soliman-monet-scope-00.txt, 717 February 2002. Work in progress. 719 [Solomon98] J. D. Solomon. 720 "Mobile IP, The Internet Unplugged". 721 Prentice Hall Series in Computer Networking and 722 Distributed Systems. 723 Prentice Hall PTR, 1998. ISBN 0-13-856246-6. 725 [Tanenbaum96] Andrew Tanenbaum 726 "Computer Networks", 727 Prentice-Hall, Third Edition. 1996 729 [WEB-MONET] NEMO web page 730 http://www.nal.motlabs.com/monet 732 Author's Addresses 734 Questions about this document can be directed to the authors: 736 Thierry Ernst, 737 French National Institute for Research in Computer Science and Control 738 Visiting Researcher at WIDE Project 739 Jun Murai lab. Faculty of Environmental Information, 740 Keio University. 741 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. 742 Phone : +81-466-49-1100 743 Fax : +81-466-49-1395 744 E-mail: ernst@sfc.wide.ad.jp 745 Web: http://www.sfc.wide.ad.jp/~ernst/ 747 Hong-Yon Lach 748 Motorola Labs Paris, Lab Manager, 749 Networking and Applications Lab (NAL) 750 Espace Technologique - Saint Aubin 751 91193 Gif-sur-Yvette Cedex, France 752 Phone: +33-169-35-25-36 753 Email: Hong-Yon.Lach@crm.mot.com