idnits 2.17.00 (12 Aug 2021) /tmp/idnits52389/draft-ietf-nemo-terminology-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. ** 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 an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2002], [RFC1726], [MULTI6], [RFC2460], [IPv6-NODE], [Requirements], [Mobility], [MIPv6], [Perkins]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 6946 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? 'RFC2460' on line 693 looks like a reference -- Missing reference section? 'Mobility' on line 668 looks like a reference -- Missing reference section? 'MIPv6' on line 663 looks like a reference -- Missing reference section? 'MULTI6' on line 673 looks like a reference -- Missing reference section? 'Requirements' on line 658 looks like a reference -- Missing reference section? 'IPv6-NODE' on line 678 looks like a reference -- Missing reference section? 'Perkins' on line 683 looks like a reference -- Missing reference section? 'RFC1726' on line 688 looks like a reference -- Missing reference section? 'RFC2002' on line 697 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF NEMO Working Group Thierry Ernst, WIDE and INRIA 3 Internet-Draft Hong-Yon Lach, Motorola Labs Paris 4 May 2003 6 Network Mobility Support Terminology 7 draft-ietf-nemo-terminology-00.txt 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document defines a terminology for discussing network mobility 32 problems and solution requirements. Network mobility arises when a 33 router connecting an entire network to the Internet dynamically 34 changes its point of attachment to the Internet therefrom causing the 35 reachability of the entire network to be changed in the topology. 36 Such kind of network is referred to as a mobile network. Without 37 appropriate mechanisms, sessions established between nodes in the 38 mobile network and the global Internet cannot be maintained while the 39 mobile router changes its point of attachment. 41 Table of Contents 43 Status of This Memo 45 Abstract 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 04 49 2. Architecture Components . . . . . . . . . . . . . . . . . . . . 05 51 3. Functional Terms . . . . . . . . . . . . . . . . . . . . . . . . 07 53 Local Fixed Node (LFN) . . . . . . . . . . . . . . . . . . . . . 07 54 Local Mobile Node (LMN). . . . . . . . . . . . . . . . . . . . . 07 55 Visiting Mobile Node (VMN) . . . . . . . . . . . . . . . . . . . 07 56 NEMO-enabled (NEMO-node) . . . . . . . . . . . . . . . . . . . . 07 57 MIPv6-enabled (MIPv6-node) . . . . . . . . . . . . . . . . . . . 07 59 4. Nested Mobility. . . . . . . . . . . . . . . . . . . . . . . . . 09 61 Nested Mobile Network. . . . . . . . . . . . . . . . . . . . . . 09 62 root-NEMO. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 parent-NEMO. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 sub-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 root-MR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 parent-MR. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 sub-MR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 Multihomed Host. . . . . . . . . . . . . . . . . . . . . . . . . 12 72 multi-addressed host . . . . . . . . . . . . . . . . . . . . . . 12 73 multi-interfaced host. . . . . . . . . . . . . . . . . . . . . . 12 74 mutli-linked host. . . . . . . . . . . . . . . . . . . . . . . . 12 75 multi-sited host . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Multihomed Mobile Router . . . . . . . . . . . . . . . . . . . . 12 77 multi-egress-addressed MR . . . . . . . . . . . . . . . . . . . 12 78 multi-egress-interfaced MR . . . . . . . . . . . . . . . . . . . 12 79 mutli-egress-linked MR . . . . . . . . . . . . . . . . . . . . . 12 80 multi-egress-sited MR . . . . . . . . . . . . . . . . . . . . . 12 81 Multihomed Mobile Network . . . . . . . . . . . . . . . . . . . 12 82 multi-MR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 Multihomed Nested Mobile Network . . . . . . . . . . . . . . . . 14 84 multi-root . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 Multihoming Illustration . . . . . . . . . . . . . . . . . . . . 14 87 6. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . . . . 16 88 Host Mobility Support . . . . . . . . . . . . . . . . . . . . . 16 89 Network Mobility Support (NEMO Support). . . . . . . . . . . . . 16 90 NEMO Basic Support . . . . . . . . . . . . . . . . . . . . . . 16 91 NEMO Extended Support . . . . . . . . . . . . . . . . . . . . . 16 92 Node behind the MR . . . . . . . . . . . . . . . . . . . . . . . 16 93 Correspondent Node (CN). . . . . . . . . . . . . . . . . . . . . 16 94 MNP . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 16 95 Idle MNN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 Idle Mobile Network . . . . . . . . . . . . . . . . . . . . . . 16 98 7. Changes Since Previous Draft . . . . . . . . . . . . . . . . . . 17 100 A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 17 102 B. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 C. Contact Address . . . . . . . . . . . . . . . . . . . . . . . . 18 106 D. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 19 107 1. Introduction 109 Network mobility support is concerned with managing the mobility of 110 an entire network which changes its point of attachment to the 111 Internet and thus its reachability in the Internet topology. If 112 network mobility is not explicitly supported by some mechanisms, 113 existing sessions break and connectivity to the global Internet is 114 lost. 116 This document defines the specific terminology needed to describe the 117 problem space we face with network mobility and to edict the 118 solutions and the requirements they must comply with. This 119 terminology complies with the usual IPv6 terminology [RFC2460] and 120 the generic mobility-related terms already defined in [Mobility] and 121 in the Mobile IPv6 [MIPv6] specifications. Some terms introduced in 122 the present version of the draft may only be useful for the purpose 123 of defining the problem scope and functional requirements of network 124 mobility support and shall be removed or refined once we agree on the 125 requirements. 127 The first section introduces terms to define the architecture 128 components; the second introduces terms to discuss the requirements, 129 the third, terms to discuss nested mobility; the forth defines 130 multihoming, and the last, miscellaneous terms which do not fit in 131 either sections. The overall terminology is summarized in fig.1 to 5. 132 Fig.1 shows a single mobile subnetwork. Fig.2. shows a larger mobile 133 network comprising several subnetworks, attached on a foreign link. 134 Fig.3 illustrates a node changing its point of attachment within the 135 mobile network. Fig.4 and 5 illustrate nested mobility whereas Fig.6 136 to Fig.8 illustrate multihoming. 138 2. Architecture Components 140 Fig.1 and 2 illustrate the architecture components involved in 141 network mobility. The terms "Fixed Node (FN)", "Mobile Node (MN)", 142 "Mobile Network", "Mobile Router (MR)", "Mobile Network Node (MNN)", 143 "home link", "foreign link", "ingress interface", "egress interface", 144 access router (AR), home link, foreign link are defined in 145 [Mobility]. 147 A mobile network is composed by one or more IP-subnet and is viewed 148 as a single unit. It is connected to the Internet by means of mobile 149 routers (MRs). Nodes behind the MR primarily comprise fixed nodes 150 (nodes unable to change their point of attachment while maintaining 151 ongoing sessions), and additionally mobile nodes (nodes able to 152 change their point of attachment while maintaining ongoing sessions). 153 In most cases, the internal structure of the mobile network will in 154 effect be relatively stable (no dynamic change of the topology), but 155 this is not a general assumption. 157 ____ 158 | | 159 | CN | 160 |____| 161 ___|____________________ 162 | | 163 | | 164 | Internet | 165 | | 166 |________________________| 167 __|_ __|_ 168 | | Access | | 169 | AR | Router | AR | 170 |____| |____| 171 ______|__ foreign __|_____________ home 172 link __|_ link 173 | | 174 | MR | Mobile Router 175 |____| 176 _________|_______ internal 177 __|__ __|__ link 178 | | | | 179 | MNN | | MNN | Mobile Network Nodes 180 |_____| |_____| 182 Fig.1: Architecture Components 184 At the network layer, MRs get access to the global Internet from 185 the Access Routers (ARs) on the visited link. The MR maintains the 186 Internet connectivity for the entire mobile network. It has one or 187 more egress interface(s) and one or more ingress interface(s). 188 When forwarding a packet to the Internet the packet is transmitted 189 upstream through one of the MR's egress interfaces to the AR; when 190 forwarding a packet from the AR down to the mobile network, the 191 packet is transmitted downstream through one of the MR's ingress 192 interfaces. 194 ________________________ 195 | | 196 | | 197 | Internet | 198 | | 199 |________________________| 200 __|_ 201 Access | | 202 Router | AR | 203 |____| 204 foreign _____|_____________ 205 link | 206 | 'e' 207 __|__ 208 | 'i'| | 209 |____| MR | Mobile Router 210 | |_____| 211 | |'i' 212 | | 213 | ____|________________ internal 214 | __|__ __|__ link 1 215 _____ | | | | | 216 | |__| | MNN | | MNN | 217 | MNN | | |_____| |_____| 218 |_____| | 219 | internal 'i': MR ingress interface 220 link 2 'e': MR egress interface 222 Fig.2: Larger Mobile Network with 2 subnets 224 3. Functional Terms 226 Within the term Mobile Network Node (MNN), we can distinguish between 227 LFN, VMN and LMN. The distinction is a property of how different 228 types of nodes can move in the topology and is necessary to discuss 229 issues related to mobility management and access control, but does 230 not preclude that mobility should be handled differently. Nodes are 231 classified according to their function and capabilities with the 232 rationale that nodes with different properties (may) have different 233 requirements. 235 Local Fixed Node (LFN) 237 A fixed node (FN), either a host or a router, that belongs to the 238 mobile network and which doesn't move topologically with respect 239 to the MR. 241 Local Mobile Node (LMN) 243 A mobile node (MN), either a host or a router who can move 244 topologically with respect to the MR and whose home link belongs 245 to the mobile network. 247 Visiting Mobile Node (VMN) 249 A mobile node (MN), either a host or a router who can move 250 topologically with respect to the MR and whose home link doesn't 251 belong to the mobile network. A VMN that gets attached to a 252 foreign link within the mobile network obtains an address on that 253 link. 255 NEMO-enabled (NEMO-node) 257 A node that has been extended with network mobility support 258 capabilities and that may take special actions based on that 259 (details of the capabilities are not known yet, but it may be 260 implementing some sort of Route Optimization). 262 MIPv6-enabled (MIPv6-node) 264 A node which has been extended with host mobility support 265 capabilities as defined in [MIPv6] and that may take special 266 actions based on that 267 ________________________ 268 | | 269 | | 270 | Internet | 271 | | 272 |________________________| 273 __|_ __|_ 274 | | Access | | 275 | AR | Router | AR | 276 |____| |____| 277 __|_ _____|_____________ foreign 278 | | _|__ link 279 | MN | | | | 280 |____| _____ |__| MR | Mobile Router 281 | |__| |____| 282 |--> | LMN | | __|_____________ internal 283 | |_____| | __|__ | link 1 284 | _____ | | | 285 | | |__| | LFN | 286 | | LFN | | |_____| | 287 | |_____| | | 288 | | internal | 289 | link 2 | 290 |------------------------------| 292 Fig.3: LFN and LMN: LMN changing subnet 294 4. Nested Mobility 296 Nested mobility occurs when there are more than one level of 297 mobility. A MNN acts as an Access Router (AR) and allows visiting 298 nodes to get attached to it. There are two cases of nested mobility: 300 - when the attaching node is a single node: VMN (see figure 4). 301 For instance, when a passenger carrying a mobile phone gets 302 Internet access from the public access network deployed into a 303 bus. 305 - when the attaching node is a router with nodes behind it, i.e. a 306 mobile network (see figure 5). For instance, when a passenger 307 carrying a PAN gets Internet access from the public access network 308 deployed in the bus. 310 For the second case, we introduce the following terms: 312 Nested Mobile Network 314 A mobile network is said to be nested when a mobile network is 315 getting attached to a larger mobile network. The aggregated 316 hierarchy of mobile networks becomes a single nested mobile 317 network. 319 ________________________ 320 | | 321 | | 322 | Internet | 323 | | 324 |________________________| 325 __|_ __|_ 326 | | Access | | 327 | AR | Router | AR | 328 |____| |____| 329 _____|_____________ home 330 | _|__ link 331 | | | | 332 | _____ |__| MR | Mobile Router 333 | | |__| |____| 334 ----------> | VMN | | __|_____________ internal 335 |_____| | __|__ __|__ link 1 336 _____ | | | | | 337 | |__| | LFN | | LMN | 338 | LFN | | |_____| |_____| 339 |_____| | 340 | internal link 2 342 Fig.4: Nested Mobility: single VMN attached to a mobile network 344 root-NEMO 346 The mobile network at the top of the hierarchy connecting the 347 aggregated nested mobile network to the Internet. 349 parent-NEMO 351 The upstream mobile network providing Internet access to a mobile 352 network down the hierarchy. 354 sub-NEMO 356 The downstream mobile network attached to a mobile network up the 357 hierarchy. It becomes a subservient of the parent-NEMO. The sub- 358 NEMO is getting Internet access through the parent-NEMO and does 359 not provide Internet access to the parent-NEMO. 361 ________________________ 362 | | 363 | | 364 | Internet | 365 | | 366 |________________________| 367 __|__ __|__ 368 | | | | 369 | AR1 | | AR2 | 370 |_____| |_____| 371 _____|_____________ foreign 372 __|__ link 373 | | 374 | _____ |__| MR1 | root-MR 375 |__| |__| |_____| 376 | | MR2 | | __|_____________ internal 377 | |_____| | __|__ __|__ link 1 378 _____ | | | | | | 379 | | | sub-MR | | LFN | | LMN | 380 | LFN |__| | |_____| |_____| 381 |_____| | | 382 | | internal 383 link 2 384 <-------------------> <---------------------------> 385 sub-NEMO root-NEMO 387 Fig.5: Nested Mobility: sub-NEMO attached to a larger mobile network 389 root-MR 391 The MR(s) of the root-NEMO used to connect the nested mobile 392 network to the fixed Internet. 394 parent-MR 396 The MR(s) of the parent-NEMO. 398 sub-MR 400 The MR(s) of the sub-NEMO connected to a parent-NEMO 402 5. Multihoming 404 Multihoming, as currently defined by the IETF, covers site- 405 multihoming [MULTI6] and host multihoming. 407 Multihomed Host 409 Within host-multihoming, a host may either be: 411 - multi-addressed: multiple source addresses to choose between 412 on a given interface; all IPv6 nodes are multi-addressed due to 413 the presence of link-local addresses on all interfaces. 415 - multi-interfaced: multiple interfaces to choose between, on 416 the same link or not. 418 - multi-linked: multiple links to choose between (just like 419 multi-interfaced but all interfaces are NOT connected to the 420 same link) 422 - multi-sited: when using IPv6 site-local address and attached 423 to different sites 425 Multihomed Mobile Router 427 A MR is multihomed when it has simultaneously more than one active 428 connection to the Internet, that is when it is either: 430 - multi-egress-addressed MR: the MR has simultaneously multiple 431 active addresses to choose between on a given egress interface 433 - multi-egress-interfaced MR: the MR has simultaneously 434 multiple active egress intefaces on the same link or not 436 - multi-egress-linked MR: the MR has simultaneously multiple 437 active egress interfaces on distinct links 439 - multi-egress-sited MR: the MR is simultaneously attached to 440 different sites (possible distinct ISPs). 442 Multihomed Mobile Network 444 A mobile network is multihomed when there more than one active 445 interface connected to the global Internet, that is when either: 447 - a MR is multihomed, or 449 - mutlti-MR: the mobile network has more than one MR to choose 450 between 452 ________________________ 453 | | 454 | | 455 | Internet | 456 | | 457 |________________________| 458 __|__ __|__ 459 | | | | 460 | AR1 | | AR2 | 461 |_____| |_____| 462 foreign ______|_____ _____|______ foreign 463 link 1 | ____ | link 2 464 | | | | 465 |___| MR |___| 466 |____| 467 ______|_____ internal 468 __|__ link 1 469 | | 470 | LFN | 471 |_____| 473 Fig.6: Multihomed Mobile Network: multi-interfaced MR 475 ________________________ 476 | | 477 | | 478 | Internet | 479 | | 480 |________________________| 481 __|__ __|__ 482 | | | | 483 | AR1 | | AR2 | 484 |_____| |_____| 485 foreign ______|_____ _____|______ foreign 486 link 1 __|__ __|__ link 2 487 | | | | 488 | MR1 | | MR2 | 489 |_____| |_____| 490 _____|__________|_____ internal 491 __|__ link 1 492 | | 493 | LFN | 494 |_____| 496 Fig.7: Multihomed Mobile Network: multi-MR 498 Multihomed Nested Mobile Network 500 A nested mobile network is multihomed when there more than one 501 active interface connected to the global Internet, that is when 502 either: 504 - a root-MR is multihomed, or 506 - multi-root: there are more than one root-MR to choose between 508 Illustration 510 Fig.6 and 7 show two examples of multihomed mobile networks. 511 Fig.8. shows two independent mobile networks. mobile_network_1 is 512 single-homed to the Internet through MR1. mobile_network_2 is 513 multihomed to the Internet through MR2a and MR2b. 515 Let's consider the two following nested scenarios: 517 Scenario 1: what happens when MR2a attaches to AR1 ? 519 - mobile_network_2 becomes a subservient of mobile_network_1 521 - mobile_network_1 is the parent-NEMO (and also the root- 522 NEMO) 524 - mobile_network_2 is the sub-NEMO 526 - MR1 is the root-MR for the aggregated nested mobile 527 network 529 - MR2a is a sub-MR in the aggregated nested mobile network 531 - mobile_network_2 is still multihomed to the Internet, but 532 to AR1 and ARz 534 - the aggregated nested mobile network is not multihomed 536 Scenario 2: what happens when MR1 attaches to AR2 ? 538 - mobile_network_1 becomes a subservient of mobile_network_2 540 - mobile_network_1 is the sub-NEMO 542 - mobile_network_2 is the parent_NEMO (and also the root- 543 NEMO) 544 - MR2a and MR2b are both root_MRs for the aggregated nested 545 mobile network 547 - MR1 is a sub-MR in the aggregated nested mobile network 549 - mobile_network_1 is not multihomed 551 - the aggregated nested mobile network is multihomed 553 _____________________________ 554 | | 555 | | 556 | Internet | 557 | | 558 |_____________________________| 559 __|__ __|__ __|__ 560 | | | | | | 561 | ARx | | ARy | | ARz | 562 |_____| |_____| |_____| 563 ______|__ ____|____ ___|____ 564 __|__ __|___ __|___ 565 | | | | | | 566 | MR1 | | MR2a | | MR2b | 567 |_____| |______| |______| 568 mobile _____|____ ___|__________|___ mobile 569 network1 __|__ __|__ network2 570 | | | | 571 | LFN | AR1 | LFN | AR2 572 |_____| |_____| 574 Fig.8: Multihomed Nested Mobile Network 576 6. Miscellaneous Terms 578 Host mobility support 580 Host Mobility Support is a mechanmism which maintains session 581 continuity between mobile nodes and their correspondents upon the 582 mobile host's change of point of attachment. It could be achieved 583 by Mobile IPv6. 585 Network Mobility support (NEMO Support) 586 Network Mobility Support is a mechanism which maintains session 587 continuity between mobile network nodes and their correspondent 588 upon a mobile router's change of point of attachment. Solutions 589 for this problem are classified into NEMO Basic Support, and NEMO 590 Extended Support. 592 NEMO Basic Support 593 NEMO Basic support is to preserve session continuity by means of 594 bidirectional tunneling much like what is done using [MIPv6] for 595 mobile nodes. 597 NEMO Extended Support 598 NEMO Extended support is to provide the necessary optimization, 599 including routing optimization between arbitrary MNNs and CNs. 601 Node behind the MR 602 Any MNN in a mobile network, beside the MRs connecting the mobile 603 network to the Internet. 605 Correspondent Node (CN) 606 Any node that is communicating with one or more MNNs. A CN could 607 either be located in the fixed network or within the mobile 608 network, and could be either fixed or mobile. 610 MNP 611 An acronym for Mobile Network Prefix (defined in [Mobility]) 613 Idle MNN 614 A MNN that does not engage in any communication. 616 Idle Mobile Network 618 A mobile network that does not engage in any communication outside 619 the network may be considered idle from the global Internet. This 620 doesn't preclude that MNNs are themselves idle. Internal traffic 621 between any two MNNs located in the same mobile network is not 622 concerned by this statement. 624 7. Changes since draft-ernst-nemo-terminology-01.txt 626 - removed terms "inter-domain mobility" and "intra-domain mobility". 627 Those are replaced with terms "Global mobility" and "Local mobility" 628 from [Mobility] 630 - removed terms "access router", "mobile network prefix", "home 631 subnet prefix", "foreign subnet prefix", "fixed node", "mobile node", 632 "mobile network", "mobile network node". "ingress interface", "egress 633 interface" to avoid redundancy with [Mobility] where those terms are 634 defined. 636 - MIPv6-enabled not anymore restricted to the MN Operation 638 - removed section "applications" to avoid redundancy with 639 [Requirements] 641 - more text for multi-homing 643 A. Acknowledgments 645 The material presented in this document takes most of the text from 646 our former internet-drafts submitted to MobileIP WG and to the former 647 MONET BOF. Authors would therefore like to thank both Motorola Labs 648 Paris and INRIA (PLANETE team, Grenoble, France), for the opportunity 649 to bring this terminology to the IETF, and particularly Claude 650 Castelluccia (INRIA) for his advices, suggestions, and direction, 651 Alexandru Petrescu (Motorola) and Christophe Janneteau (Motorola). We 652 also acknowledge the input from Hesham Soliman (Ericsson), Mattias 653 Petterson (Ericsson), and numerous other people on the NEMO mailing 654 list. 656 B. References 658 [Requirements] Thierry Ernst 659 "Network Mobility Support Requirements" 660 draft-ietf-nemo-requirements.txt 661 Work in progress. 663 [MIPv6] David B. Johnson and C. Perkins. 664 "Mobility Support in IPv6". 665 Internet Draft draft-ietf-mobileip-ipv6.txt, 666 Work in progress. 668 [Mobility] J. Manner and M. Kojo 669 "Mobility Related Terminology 670 draft-ietf-seamoby-mobility-terminology.txt 671 Work in progress 673 [MULTI6] B. Black, V. Gill and J. Abley 674 "Requirements for IPv6 Site-Multihoming Architectures" 675 draft-ietf-multi6-multihoming-requirements.txt 676 Work in progress 678 [IPv6-NODE] John Loughney 679 "IPv6 Node Requirements" 680 draft-ietf-ipv6-node-requirements.txt 681 Work in progress. 683 [Perkins] C. E. Perkins. 684 "Mobile IP, Design Principles and Practices." 685 Wireless Communications Series. 686 Addison-Wesley, 1998. ISBN 0-201-63469-4. 688 [RFC1726] C. Partridge 689 "Technical Criteria for Choosing IP the Next 690 Generation", 691 IETF RFC 1726 section 5.15, December 1994. 693 [RFC2460] S. Deering and R. Hinden. 694 "Internet Protocol Version 6 (IPv6) Specification". 695 IETF RFC 2460, December 1998. 697 [RFC2002] C. Perkins (Editor). 698 "IP Mobility Support". 699 IETF RFC 2002,October 1996. 701 C. Contact Address 703 Questions about this document can be directed to the authors: 705 Thierry Ernst, 706 Keio University. 707 5322 Endo, Fujisawa-shi, 708 Kanagawa 252-8520, Japan. 709 Phone : +81-466-49-1100 710 Fax : +81-466-49-1395 711 Email : ernst@sfc.wide.ad.jp 713 Hong-Yon Lach 714 Motorola Labs Paris, Lab Manager, 715 Networking and Applications Lab (NAL) 716 Espace Technologique - Saint Aubin 717 91193 Gif-sur-Yvette Cedex, France 718 Phone: +33-169-35-25-36 719 Email: Hong-Yon.Lach@crm.mot.com 721 D. Full Copyright Statement 723 Copyright (C) The Internet Society (2002). All Rights Reserved. 725 This document and translations of it may be copied and furnished to 726 others, and derivative works that comment on or otherwise explain it 727 or assist in its implementation may be prepared, copied, published and 728 distributed, in whole or in part, without restriction of any kind, 729 provided that the above copyright notice and this paragraph are 730 included on all such copies and derivative works. However, this 731 document itself may not be modified in any way, such as by removing 732 the copyright notice or references to the Internet Society or other 733 Internet organizations, except as needed for the purpose of developing 734 Internet standards in which case the procedures for copyrights defined 735 in the Internet Standards process must be followed, or as required to 736 translate it into languages other than English. 738 The limited permissions granted above are perpetual and will not be 739 revoked by the Internet Society or its successors or assigns. 741 This document and the information contained herein is provided on an 742 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 743 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 744 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 745 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 746 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Funding for the RFC editor function is currently provided by the 749 Internet Society.