idnits 2.17.1 draft-ietf-nemo-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 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 392: '...01: The solution MUST be implemented a...' RFC 2119 keyword, line 394: '...02: The solution MUST set up a bi-dire...' RFC 2119 keyword, line 398: '... Internet MUST transit through th...' RFC 2119 keyword, line 400: '... R04: MNNs MUST be reachable at a...' RFC 2119 keyword, line 402: '...05: The solution MUST maintain continu...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R06: The solution MUST not require modifications to any node other than MRs and HAs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R09:1: The solution MUST not prevent the proper operation of Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to operate either the CN, HA, or MN operations defined in [6]) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2005) is 6759 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: '9' is defined on line 521, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 525, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-ietf-nemo-ro-problem-statement-01 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-04 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-05 -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '10') (Obsoleted by RFC 8200) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group T. Ernst 3 Internet-Draft Keio University / WIDE 4 Expires: April 27, 2006 October 24, 2005 6 Network Mobility Support Goals and Requirements 7 draft-ietf-nemo-requirements-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Network mobility arises when a router connecting a network to the 41 Internet dynamically changes its point of attachment to the Internet 42 thereby causing the reachability of the said network to be changed in 43 relation to the fixed Internet topology. Such kind of network is 44 referred to as a mobile network. With appropriate mechanisms, 45 sessions established between nodes in the mobile network and the 46 global Internet can be maintained after the mobile router changes its 47 point of attachment. This document outlines the goals expected from 48 network mobility support and defines the requirements that must be 49 met by the NEMO Basic Support solution. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. NEMO Working Group Objectives and Methodology . . . . . . . . 4 57 3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . . 5 58 3.1. Migration Transparency . . . . . . . . . . . . . . . . . . 5 59 3.2. Performance Transparency and Seamless Mobility . . . . . . 5 60 3.3. Network Mobility Support Transparency . . . . . . . . . . 6 61 3.4. Operational Transparency . . . . . . . . . . . . . . . . . 6 62 3.5. Arbitrary Configurations . . . . . . . . . . . . . . . . . 6 63 3.6. Local Mobility and Global Mobility . . . . . . . . . . . . 7 64 3.7. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 7 66 3.9. Secure Signaling . . . . . . . . . . . . . . . . . . . . . 8 67 3.10. Location Privacy . . . . . . . . . . . . . . . . . . . . . 8 68 3.11. IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . . 8 70 4. NEMO Basic Support One-Liner Requirements . . . . . . . . . . 8 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Appendix A. Change Log From Earlier Versions . . . . . . . . . . 13 83 A.1. Changes between version -04 and -05 . . . . . . . . . . . 13 84 A.2. Changes between version -03 and -04 . . . . . . . . . . . 13 85 A.3. Changes between version -02 and -03 . . . . . . . . . . . 13 86 A.4. Changes Between Version -01 and -02 . . . . . . . . . . . 14 87 A.5. Changes Between Version -00 and -01 . . . . . . . . . . . 14 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 Intellectual Property and Copyright Statements . . . . . . . . . . 16 92 1. Introduction 94 Network mobility support (see [1] for the related terminology) is 95 concerned with managing the mobility of an entire network, viewed as 96 a single unit, which changes its point of attachment to the Internet 97 and thus its reachability in the Internet topology. Such a network 98 is referred to as a mobile network and includes one or more mobile 99 routers (MRs) which connect it to the global Internet. Nodes behind 100 the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In 101 most cases, the internal structure of the mobile network will be 102 relatively stable (no dynamic change of the topology), but this is 103 not always true. 105 Cases of mobile networks include, for instance: 107 o Networks attached to people (Personal Area Networks or PANs): a 108 cell-phone with one cellular interface and one Bluetooth interface 109 together with a Bluetooth-enabled PDA constitute a very simple 110 instance of a mobile network. The cell-phone is the mobile router 111 while the PDA is used for web browsing or runs a personal web 112 server. 114 o Networks of sensors and computers deployed in vehicles: vehicles 115 are increasingly embedded with a number of processing units for 116 safety and ease of driving reasons, as advocated by ITS 117 (Intelligent Transportation Systems) applications ([4], [5]). 119 o Access networks deployed in public transportation (buses, trains, 120 taxis, aircrafts): they provide Internet access to IP devices 121 carried by passengers: laptop, camera, mobile phone: host mobility 122 within network mobility or PANs: network mobility within network 123 mobility, i.e. nested mobility (see [1] for the definition of 124 nested mobility). 126 o Ad-hoc networks connected to the Internet via an MR: for instance 127 students in a train that need both to set up an ad-hoc network 128 among themselves, and get Internet connectivity through the MR 129 connecting the train to the Internet. 131 Mobility of networks does not cause MNNs to change their own physical 132 point of attachment; however they do change their topological 133 location with respect to the global Internet. If network mobility is 134 not explicitly supported by some mechanisms, the mobility of the MR 135 results in MNNs losing Internet access and breaking ongoing sessions 136 between arbitrary correspondent node (CNs) in the global Internet and 137 those MNNs located within the mobile network. In addition, the 138 communication path between MNNs and correspondent nodes becomes sub- 139 optimal, and multiple levels of mobility will cause extremely sub- 140 optimal routing. 142 Mobility-related terms used in this document are defined in [2], 143 whereas terms specifically pertaining to network mobility are defined 144 in [1]. This document is structured as follows: in Section 2 we 145 define the rough objectives and methodology of the NEMO working group 146 to handle network mobility issues and we emphasize the stepwise 147 approach the working group has decided to follow. A number of 148 desirable design goals are listed in Section 3. Those design goals 149 then serve as guidelines to define the requirements listed in 150 Section 4 for basic network mobility support [3]. 152 2. NEMO Working Group Objectives and Methodology 154 The mechanisms required for handling network mobility issues were 155 lacking within the IETF standards when the NEMO working group was set 156 up at the IETF. At that time, work conducted on mobility support 157 (particularly in the Mobile IP working group) was to provide 158 continuous Internet connectivity and optimal routing to mobile hosts 159 only (host mobility support). Such mechanisms speficied in Mobile 160 IPv6 [6] are unable to support network mobility. The NEMO working 161 group has therefore been set up to deal with issues specific to 162 network mobility. 164 The primary objective of the NEMO work is to specify a solution which 165 allows mobile network nodes (MNNs) to remain connected to the 166 Internet and continuously reachable at all times while the mobile 167 router seving the mobile network changes its point of attachment. 168 The secondary goals of the work is to investigate the effects of 169 network mobility on various aspects of internet communication such as 170 routing protocol changes, implications of real-time traffic and fast 171 handovers, and optimizations. This should support the primary goal 172 of reachability for mobile network nodes. Security is an important 173 consideration too, and efforts should be made to use existing 174 security solutions if they are appropriate. Although a well-designed 175 solution may include security inherent in other protocols, mobile 176 networks also introduce new challenges. 178 To complete these tasks, the NEMO working group has decided to take a 179 stepwise approach. The steps in this approach include standardizing 180 a basic solution to preserve session continuity (NEMO Basic Support) 181 (see [3]), and studying the possible approaches and issues with 182 providing more optimal routing with potentially nested mobile 183 networks (NEMO Extended Support) (see [7]). However, the working 184 group is not chartered to actually standardize a solution for 185 extgended support at this point in time. If deemed necessary, the 186 working group will be rechartered based on the conclusions of the 187 discussions. 189 For NEMO Basic Support, the working group will assume that none of 190 the nodes behind the MR will be aware of the network's mobility; 191 thus, the network's movement needs to be completely transparent to 192 the nodes inside the mobile network. This assumption accommodates 193 nodes inside the network that are not generally aware of mobility. 195 The efforts of the Mobile IP working group have resulted in the 196 Mobile IPv4 and Mobile IPv6 protocols, which have already solved the 197 issue of host mobility support. Since challenges to enabling mobile 198 networks are vastly reduced by this work, basic network mobility 199 support will adopt the methods for host mobility support used in 200 Mobile IP, and extend them in the simplest way possible to achieve 201 its goals. The basic support solution, now defined in [3] following 202 the requirements stated in Section 4 of the present document, is for 203 each MR to have a Home Agent, and use bi-directional tunneling 204 between the MR and HA to preserve session continuity while the MR 205 moves. The MR will acquire a care-of address at its attachment point 206 much like what is done for mobile nodes (MN), using Mobile IP. This 207 approach allows nested mobile networks, since each MR will appear to 208 its attachment point as a single node. 210 3. NEMO Support Design Goals 212 This section details the fundamental design goals the solutions will 213 intend to achieve. Those design goals serve to define the issues and 214 to impose a list of requirements for forthcoming solutions. Actual 215 requirements for NEMO Basic Support are in Section 4; NEMO Extended 216 Support is not yet considered at the time of this writing. 218 3.1. Migration Transparency 220 Permanent connectivity to the Internet has to be provided to all 221 MNNs, since continuous sessions are expected to be maintained as the 222 mobile router changes its point of attachment. For maintaining those 223 sessions, MNNs are expected to be reachable via their permanent IP 224 addresses. 226 3.2. Performance Transparency and Seamless Mobility 228 NEMO support is expected to be provided with limited signaling 229 overhead and to minimize the impact of handovers on applications, in 230 terms of packet loss or delay. However, although variable delays of 231 transmission and losses between MNNs and their respective CNs could 232 be perceived as the network is displaced, it would not be considered 233 a lack of performance transparency. 235 3.3. Network Mobility Support Transparency 237 MNNs behind the MR(s) do not change their own physical point of 238 attachment as a result of the mobile network's displacement in the 239 Internet topology. Consequently, NEMO support is expected to be 240 performed only be the MR(s). Specific support functions on any other 241 node than the MR(s) would better be avoided. 243 3.4. Operational Transparency 245 NEMO support is to be implemented at the level of IP layer. It is 246 expected to be transparent to upper layers so that any upper layer 247 protocol can run unchanged on top of an IP layer extended with NEMO 248 support. 250 3.5. Arbitrary Configurations 252 The formation of a mobile network can occur in various levels of 253 complexity. In the simplest case, a mobile network contains just a 254 mobile router and a host. In the most complicated case, a mobile 255 network is multihomed and is itself a multi-level aggregation of 256 mobile networks with collectively thousands of mobile routers and 257 hosts. While the list of potential configurations of mobile networks 258 cannot be limited, at least the following ones are desirable: 260 o Mobile networks of any size, ranging from a sole subnet with a few 261 IP devices to a collection of subnets with a large number of IP 262 devices. 264 o Nodes that change their point of attachment within the mobile 265 network. 267 o Foreign mobile nodes that attach to the mobile network. 269 o Multihomed mobile network: either when a single MR has multiple 270 attachments to the internet, or when the mobile network is 271 attached to the Internet by means of multiple MRs (see definition 272 in [1] and the analysis in [8]). 274 o Nested mobile networks (mobile networks attaching to other mobile 275 networks (see definition in [1]). Although the complexity 276 requirements of those nested networks is not clear, it is 277 desirable to support arbitrary levels of recursive networks. The 278 solution should only impose restrictions on nesting (e.g. path 279 MTU) when this is impractical and protocol concerns preclude such 280 support. 282 o Distinct mobility frequencies (see mobility factor in [2]). 284 o Distinct access media. 286 In order to keep complexity minimal, transit networks are excluded 287 from this list. A transit network is one in which data would be 288 forwarded between two endpoints outside of the network, so that the 289 network itself simply serves as a transitional conduit for packet 290 forwarding. A stub network (leaf network), on the other hand, does 291 not serve as a data forwarding path. Data on a stub network is 292 either sent by or addressed to a node located within that network. 294 3.6. Local Mobility and Global Mobility 296 Mobile networks and mobile nodes owned by different administrative 297 entities are expected to be displaced within a domain boundary or 298 between domain boundaries. Multihoming, vertical and horizontal 299 handoffs, and access control mechanisms are desirable to achieve this 300 goal. Such mobility is not expected to be limited for any 301 consideration other than administrative and security policies. 303 3.7. Scalability 305 NEMO support signaling and processing is expected to scale to a 306 potentially large number of mobile networks irrespective of their 307 configuration, mobility frequency, size and number of CNs. 309 3.8. Backward Compatibility 311 NEMO support will have to co-exist with established IPv6 standards 312 and not interfer with them. Standards defined in other IETF working 313 groups have to be reused as much as possible and extended only if 314 deemed necessary. For instance, the following mechanisms defined by 315 other working groups are expected to function without modidication: 317 o Address allocation and configuration mechanisms. 319 o Host mobility support: mobile nodes and correspondent nodes, 320 either located within or outside the mobile network, are expected 321 to continue operating protocols defined by the Mobile IP working 322 group. This include mechanisms for host mobility support (Mobile 323 IPv6) and seamless mobility (FMIPv6). 325 o Multicast support intended for MNNs is expected to be maintained 326 while the mobile router changes its point of attachment. 328 o Access control protocols and mechanisms used by visiting mobile 329 hosts and routers to be authenticated and authorized, gaining 330 access to the Internet via the mobile network infrastructure 331 (MRs). 333 o Security protocols and mechanisms. 335 o Mechanisms performed by routers deployed in both the visited 336 networks and in mobile networks (routing protocols, Neighbor 337 Discovery, ICMP, Router Renumbering). 339 3.9. Secure Signaling 341 NEMO support will have to comply with the usual IETF security 342 policies and recommendations and is expected to have its specific 343 security issues fully addressed. In practice, all NEMO support 344 control messages transmitted in the network will have to be protected 345 with an acceptable level of security to prevent intruders to usurp 346 identities and forge data. Specifically, the following issues have 347 to be considered: 349 o Authentication of the sender to prevent identity usurpation. 351 o Authorization, to make sure the sender is granted permission to 352 perform the operation as indicated in the control message. 354 o Confidentiality of the data contained in the control message. 356 3.10. Location Privacy 358 Location privacy means to hide the actual location of MNNS to third 359 parties other than the HA are desired. It is not clear to which 360 extend this has to be enforced, since it is always possible to 361 determine the topological location by analysing IPv6 headers. It 362 would thus require some kind of encryption of the IPv6 header to 363 prevent third parties from monitoring IPv6 addresses between the MR 364 and the HA. On the other hand, it is at the very least desirable to 365 provide a means for MNNs to hide their real topological location to 366 their CNs. 368 3.11. IPv4 and NAT Traversal 370 IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, 371 so it is desirable to ensure mechanisms developed for NEMO will be 372 able to traverse such clouds. 374 4. NEMO Basic Support One-Liner Requirements 376 The NEMO WG is to specify a unified and unique "Network Mobility 377 Basic Support" solution, hereafter referred to as "the solution". 378 This solution is to allow all nodes in the mobile network to be 379 reachable via permanent IP addresses, as well as maintain ongoing 380 sessions as the MR changes its point of attachment to the Internet 381 topology. This is to be done by maintaining a bi-directional tunnel 382 between an MR and its Home Agent. 384 The NEMO Working Group, after some investigation of alternatives, has 385 decided to reuse the existing Mobile IPv6 [6] mechanisms for tunnel 386 management, or extend it if deemed necessary. 388 The list of requirements below has been imposed on the NEMO Basic 389 Support solution. The requirements have mostly been met by the 390 resulting specification which can now be found in [3]. 392 R01: The solution MUST be implemented at the IP layer level. 394 R02: The solution MUST set up a bi-directional tunnel between a 395 Mobile Router and its Home Agent (MRHA tunnel) 397 R03: All traffic exchanged between an MNN and a CN in the global 398 Internet MUST transit through the bi-directional MRHA tunnel. 400 R04: MNNs MUST be reachable at a permanent IP address and name. 402 R05: The solution MUST maintain continuous sessions (both unicast 403 and multicast) between MNNs and arbitrary CNs after IP handover of 404 (one of) the MR. 406 R06: The solution MUST not require modifications to any node other 407 than MRs and HAs. 409 R07: The solution MUST support fixed nodes, mobile hosts and 410 mobile routers in the mobile network. 412 R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile 413 network link as either a home link or a foreign link. 415 R09: The solution MUST ensure backward compatibility with other 416 standards defined by the IETF. In particular, this includes: 418 R09:1: The solution MUST not prevent the proper operation of 419 Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to 420 operate either the CN, HA, or MN operations defined in [6]) 422 R10: The solution MUST treat all the potential configurations the 423 same way (whatever the number of subnets, MNNs, nested levels of 424 MRs, egress interfaces) 425 R11: The solution MUST support at least 2 levels of nested mobile 426 networks, while, in principle, arbitrary levels of recursive 427 mobile networks SHOULD be supported. 429 R12: The solution MUST function for multihomed MRs and multihomed 430 mobile networks as defined in [1]. 432 R13: NEMO Support signaling over the bi-directional MUST be 433 minimized 435 R14: Signaling messages between the HA and the MR MUST be secured: 437 R14.1: The receiver MUST be able to authenticate the sender. 439 R14.2: The function performed by the sender MUST be authorized 440 for the content carried. 442 R14.3: Anti-replay MUST be provided. 444 R14.4: The signaling messages MAY be encrypted. 446 R15: The solution MUST ensure transparent continuation of routing 447 and management operations over the bi-directional tunnel (this 448 includes e.g. unicast and multicast routing protocols, router 449 renumbering, DHCPv6) 451 R16: When one egress interface fails, the solution MAY preserve 452 sessions established through another egress interface. 454 5. Security Considerations 456 As this document only provides a discussion about design goals and 457 describes neither a protocol nor an implementation or a procedure, 458 there are no security considerations associated with it. 460 6. IANA Considerations 462 This document requires no IANA actions. 464 7. Acknowledgments 466 The material presented in this document takes most of its text from 467 discussions and previous documents submitted to the NEMO working 468 group. This includes initial contributions from Motorola, INRIA, 469 Ericsson and Nokia. We are particularly grateful to Hesham Soliman 470 (Ericsson) and the IETF ADs at the time (Erik Nordmark and Thomas 471 Narten) who greatly helped to set up the NEMO working group. We are 472 also grateful to all the following people whose comments highly 473 contributed to the present document: T.J. Kniveton (Nokia), Alexandru 474 Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert 475 (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and 476 all the others people who have expressed their opinions on the NEMO 477 mailing lists (formely known as MONET). Thierry Ernst wishes to 478 personally acknowledge his previous employers, INRIA, and Motorola 479 for their support and direction in bringing this topic up to the IETF 480 -- particularly Claude Castelluccia (INRIA) and Hong-Yon Lach 481 (Motorola). 483 8. References 485 8.1. Normative References 487 [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 488 draft-ietf-nemo-terminology-04 (work in progress), October 2005. 490 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 491 RFC 3753, June 2004. 493 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 494 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 495 January 2005. 497 8.2. Informative References 499 [4] "CALM - Medium and Long Range, High Speed, Air Interfaces 500 parameters and protocols for broadcast, point to point, vehicle 501 to vehicle, and vehicle to point communication in the ITS 502 sector - Networking Protocol - Complementary Element", ISO 503 Draft ISO/WD 21210, February 2005. 505 [5] Ernst, T. and K. Uehara, "Connecting Automobiles to the 506 Internet", Proceedings 3rd International Workshop on ITS 507 Telecommunications (ITST), November 2002. 509 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 510 IPv6", RFC 3775, June 2004. 512 [7] Ng, C., "Network Mobility Route Optimization Problem 513 Statement", draft-ietf-nemo-ro-problem-statement-01 (work in 514 progress), October 2005. 516 [8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 517 Multihoming in Network Mobility Support", 518 draft-ietf-nemo-multihoming-issues-04 (work in progress), 519 October 2005. 521 [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 522 Network Models", draft-ietf-nemo-home-network-models-05 (work 523 in progress), June 2005. 525 [10] Deering, S. and R. Hinden, "Internet Protocol Version 6 526 (IPv6)", IETF RFC 2460, December 1998. 528 Appendix A. Change Log From Earlier Versions 530 The discussions behind the changes in the lattest versions of this 531 documents are reflected in the "issue" web page: 532 http://www.sfc.wide.ad.jp/~ernst/nemo/ 534 A.1. Changes between version -04 and -05 536 Added a reference to [7] 538 Split references into Normative and Informational 540 Cosmetics changes 542 A.2. Changes between version -03 and -04 544 - Issue B1: English brush up 546 - Issue B2: Added a reference to [4] and [5] when speaking about 547 usages. 549 - Issue B3: The following paragraph from section 1 was partly 550 removed; the remaining part was moved to section 2 and rephrased: 551 "The mechanisms required for handling such mobility issues are 552 currently lacking within the IETF standards. Traditional work 553 conducted on mobility support (particularly in the Mobile IP working 554 group) is to provide continuous Internet connectivity and optimal 555 routing to mobile hosts only (host mobility support) and are unable 556 to support network mobility. The NEMO working group has therefore 557 been set up to deal with issues specific to network mobility. The 558 purpose of this document is thus to detail the methodology that will 559 be followed by the NEMO working group, its goals, and to define 560 requirements for network mobility support." 562 - Issue B4: Effectively removed former requirements about "impact on 563 the routing fabric". 565 A.3. Changes between version -02 and -03 567 - Mostly cosmetic changes 569 - Merged section Terminology into Introduction 571 - Cross-references with other NEMO WG docs 573 - Changed the introducion of section Section 4 and added reference to 574 NEMO Basic Support's resulting specification. 576 A.4. Changes Between Version -01 and -02 578 - removed sub-items in R12 (sub-cases are contained into the 579 definition of multihoming) 581 - minor typos 583 - R15: Added "multicast" 585 - R14.4: SHOULD softened to MAY according to discussion at IETF56th 586 meeting. 588 - R17 moved to R09 and contains former R09 as a sub-case. 590 - R18: relaxed from "SHOULD" to may based on Vijay Devarapalli 591 comment (030718) 593 A.5. Changes Between Version -00 and -01 595 - title of documents: included the word "goals" 597 - entire document: some rewording 599 - section 4: changed title of section to "NEMO Design Goals". 601 - section 4: removed "MUST" and "MAY" 603 - section 4: more text about location privacy 605 - section 4: changed "Administration" paragraph to "Local and Global 606 Mobility". Text enhanced. 608 - section 5: R02: replace "between MR and MR's HA" with "an MR and 609 its HA" R11: specified at least 2 levels R12: replaced "support" with 610 "function" and add "multihomed MR" R13.x renumbered to R12.x since 611 part of R12 (editing mistake) R13 and R18: new requirements proposed 612 by editor and minor changes in the formulation of other Requirements 614 Author's Address 616 Thierry Ernst 617 Keio University / WIDE 618 Jun Murai Lab., Keio University. 619 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 620 Kawasaki, Kanagawa 212-0054 621 Japan 623 Phone: +81-44-580-1600 624 Fax: +81-44-580-1437 625 Email: ernst@sfc.wide.ad.jp 626 URI: http://www.sfc.wide.ad.jp/~ernst/ 628 Intellectual Property Statement 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org. 652 Disclaimer of Validity 654 This document and the information contained herein are provided on an 655 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 656 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 657 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 658 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 659 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 660 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 662 Copyright Statement 664 Copyright (C) The Internet Society (2005). This document is subject 665 to the rights, licenses and restrictions contained in BCP 78, and 666 except as set forth therein, the authors retain all their rights. 668 Acknowledgment 670 Funding for the RFC Editor function is currently provided by the 671 Internet Society.