idnits 2.17.1 draft-ietf-nemo-requirements-06.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 578. ** 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 issues found here. 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 388: '...01: The solution MUST be implemented a...' RFC 2119 keyword, line 390: '...02: The solution MUST set up a bi-dire...' RFC 2119 keyword, line 394: '... Internet MUST transit through th...' RFC 2119 keyword, line 396: '... R04: MNNs MUST be reachable at a...' RFC 2119 keyword, line 398: '...05: The solution MUST maintain continu...' (18 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 [5]) -- 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 (November 8, 2006) is 6351 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group T. Ernst 3 Internet-Draft INRIA 4 Intended status: Informational November 8, 2006 5 Expires: May 12, 2007 7 Network Mobility Support Goals and Requirements 8 draft-ietf-nemo-requirements-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 12, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Network mobility arises when a router connecting a network to the 42 Internet dynamically changes its point of attachment to the Internet 43 thereby causing the reachability of the said network to be changed in 44 relation to the fixed Internet topology. Such kind of network is 45 referred to as a mobile network. With appropriate mechanisms, 46 sessions established between nodes in the mobile network and the 47 global Internet can be maintained after the mobile router changes its 48 point of attachment. This document outlines the goals expected from 49 network mobility support and defines the requirements that must be 50 met by the NEMO Basic Support solution. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. NEMO Working Group Objectives and Methodology . . . . . . . . 5 58 3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . . 7 59 3.1. Migration Transparency . . . . . . . . . . . . . . . . . . 7 60 3.2. Performance Transparency and Seamless Mobility . . . . . . 7 61 3.3. Network Mobility Support Transparency . . . . . . . . . . 7 62 3.4. Operational Transparency . . . . . . . . . . . . . . . . . 7 63 3.5. Arbitrary Configurations . . . . . . . . . . . . . . . . . 7 64 3.6. Local Mobility and Global Mobility . . . . . . . . . . . . 8 65 3.7. Scalability . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.8. Backward Compatibility . . . . . . . . . . . . . . . . . . 9 67 3.9. Secure Signaling . . . . . . . . . . . . . . . . . . . . . 9 68 3.10. Location Privacy . . . . . . . . . . . . . . . . . . . . . 10 69 3.11. IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . . 10 71 4. NEMO Basic Support One-Liner Requirements . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Intellectual Property and Copyright Statements . . . . . . . . . . 18 86 1. Introduction 88 Network mobility support (see [1] for the related terminology) is 89 concerned with managing the mobility of an entire network, viewed as 90 a single unit, which changes its point of attachment to the Internet 91 and thus its reachability in the Internet topology. Such a network 92 is referred to as a mobile network and includes one or more mobile 93 routers (MRs) which connect it to the global Internet. Nodes behind 94 the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In 95 most cases, the internal structure of the mobile network will be 96 relatively stable (no dynamic change of the topology), but this is 97 not always true. 99 Cases of mobile networks include, for instance: 101 o Networks attached to people (Personal Area Networks or PANs): a 102 cell-phone with one cellular interface and one Bluetooth interface 103 together with a Bluetooth-enabled PDA constitute a very simple 104 instance of a mobile network. The cell-phone is the mobile router 105 while the PDA is used for web browsing or runs a personal web 106 server. 108 o Networks of sensors and computers deployed in vehicles: vehicles 109 are increasingly embedded with a number of processing units for 110 safety and ease of driving reasons, as advocated by ITS 111 (Intelligent Transportation Systems) applications ([4]). 113 o Access networks deployed in public transportation (buses, trains, 114 taxis, aircrafts): they provide Internet access to IP devices 115 carried by passengers: laptop, camera, mobile phone: host mobility 116 within network mobility or PANs: network mobility within network 117 mobility, i.e. nested mobility (see [1] for the definition of 118 nested mobility). 120 o Ad-hoc networks connected to the Internet via an MR: for instance 121 students in a train that need both to set up an ad-hoc network 122 among themselves, and get Internet connectivity through the MR 123 connecting the train to the Internet. 125 Mobility of networks does not cause MNNs to change their own physical 126 point of attachment; however they do change their topological 127 location with respect to the global Internet. If network mobility is 128 not explicitly supported by some mechanisms, the mobility of the MR 129 results in MNNs losing Internet access and breaking ongoing sessions 130 between arbitrary correspondent node (CNs) in the global Internet and 131 those MNNs located within the mobile network. In addition, the 132 communication path between MNNs and correspondent nodes becomes sub- 133 optimal, and multiple levels of mobility will cause extremely sub- 134 optimal routing. 136 Mobility-related terms used in this document are defined in [2], 137 whereas terms specifically pertaining to network mobility are defined 138 in [1]. This document is structured as follows: in Section 2 we 139 define the rough objectives and methodology of the NEMO working group 140 to handle network mobility issues and we emphasize the stepwise 141 approach the working group has decided to follow. A number of 142 desirable design goals are listed in Section 3. Those design goals 143 then serve as guidelines to define the requirements listed in 144 Section 4 for basic network mobility support [3]. 146 2. NEMO Working Group Objectives and Methodology 148 The mechanisms required for handling network mobility issues were 149 lacking within the IETF standards when the NEMO working group was set 150 up at the IETF in 2002. At that time, work conducted on mobility 151 support (particularly in the Mobile IP working group) was to provide 152 continuous Internet connectivity and optimal routing to mobile hosts 153 only (host mobility support). Such mechanisms speficied in Mobile 154 IPv6 [5] are unable to support network mobility. The NEMO working 155 group has therefore been set up to deal with issues specific to 156 network mobility. 158 The primary objective of the NEMO work is to specify a solution which 159 allows mobile network nodes (MNNs) to remain connected to the 160 Internet and continuously reachable at all times while the mobile 161 router seving the mobile network changes its point of attachment. 162 The secondary goals of the work is to investigate the effects of 163 network mobility on various aspects of internet communication such as 164 routing protocol changes, implications of real-time traffic and fast 165 handovers, and optimizations. This should support the primary goal 166 of reachability for mobile network nodes. Security is an important 167 consideration too, and efforts should be made to use existing 168 security solutions if they are appropriate. Although a well-designed 169 solution may include security inherent in other protocols, mobile 170 networks also introduce new challenges. 172 To complete these tasks, the NEMO working group has decided to take a 173 stepwise approach. The steps in this approach include standardizing 174 a basic solution to preserve session continuity (NEMO Basic Support, 175 see [3]), and studying the possible approaches and issues with 176 providing more optimal routing with potentially nested mobile 177 networks (NEMO Extended Support, see [6] and [7] for a discussion on 178 routing optimization issues and [8] multihoming issues). However, 179 the working group is not chartered to actually standardize a solution 180 for extgended support at this point in time. If deemed necessary, 181 the working group will be rechartered based on the conclusions of the 182 discussions. 184 For NEMO Basic Support, the working group assumes that none of the 185 nodes behind the MR is aware of the network's mobility; thus, the 186 network's movement needs to be completely transparent to the nodes 187 inside the mobile network. This assumption accommodates nodes inside 188 the network that are not generally aware of mobility. 190 The efforts of the Mobile IP working group have resulted in the 191 Mobile IPv4 and Mobile IPv6 protocols, which have already solved the 192 issue of host mobility support. Since challenges to enabling mobile 193 networks are vastly reduced by this work, basic network mobility 194 support has adopted the methods for host mobility support used in 195 Mobile IP, and has extended them in the simplest way possible to 196 achieve its goals. The basic support solution, now defined in [3] 197 following the requirements stated in Section 4 of the present 198 document, is for each MR to have a Home Agent, and use bi-directional 199 tunneling between the MR and HA to preserve session continuity while 200 the MR moves. The MR acquires a Care-of address (CoA) at its 201 attachment point much like what is done for mobile hosts (MH), using 202 Mobile IP. This approach allows nested mobile networks, since each 203 MR will appear to its attachment point as a single node. 205 3. NEMO Support Design Goals 207 This section details the fundamental design goals the solutions will 208 intend to achieve. Those design goals serve to define the issues and 209 to impose a list of requirements for forthcoming solutions. Actual 210 requirements for NEMO Basic Support are in Section 4; NEMO Extended 211 Support is not yet considered at the time of this writing. 213 3.1. Migration Transparency 215 Permanent connectivity to the Internet has to be provided to all 216 MNNs, since continuous sessions are expected to be maintained as the 217 mobile router changes its point of attachment. For maintaining those 218 sessions, MNNs are expected to be reachable via their permanent IP 219 addresses. 221 3.2. Performance Transparency and Seamless Mobility 223 NEMO support is expected to be provided with limited signaling 224 overhead and to minimize the impact of handovers on applications, in 225 terms of packet loss or delay. However, although variable delays of 226 transmission and losses between MNNs and their respective CNs could 227 be perceived as the network is displaced, it would not be considered 228 a lack of performance transparency. 230 3.3. Network Mobility Support Transparency 232 MNNs behind the MR(s) do not change their own physical point of 233 attachment as a result of the mobile network's displacement in the 234 Internet topology. Consequently, NEMO support is expected to be 235 performed only by the MR(s). Specific support functions on any other 236 node than the MR(s) would better be avoided. 238 3.4. Operational Transparency 240 NEMO support is to be implemented at the level of IP layer. It is 241 expected to be transparent to upper layers so that any upper layer 242 protocol can run unchanged on top of an IP layer extended with NEMO 243 support. 245 3.5. Arbitrary Configurations 247 The formation of a mobile network can occur in various levels of 248 complexity. In the simplest case, a mobile network contains just a 249 mobile router and a host. In the most complicated case, a mobile 250 network is multihomed and is itself a multi-level aggregation of 251 mobile networks with collectively thousands of mobile routers and 252 hosts. While the list of potential configurations of mobile networks 253 cannot be limited, at least the following ones are desirable: 255 o Mobile networks of any size, ranging from a sole subnet with a few 256 IP devices to a collection of subnets with a large number of IP 257 devices. 259 o Nodes that change their point of attachment within the mobile 260 network. 262 o Foreign mobile nodes that attach to the mobile network. 264 o Multihomed mobile network: either when a single MR has multiple 265 attachments to the internet, or when the mobile network is 266 attached to the Internet by means of multiple MRs (see definition 267 in [1] and the analysis in [8]). 269 o Nested mobile networks (mobile networks attaching to other mobile 270 networks (see definition in [1]). Although the complexity 271 requirements of those nested networks is not clear, it is 272 desirable to support arbitrary levels of recursive networks. The 273 solution should only impose restrictions on nesting (e.g. path 274 MTU) when this is impractical and protocol concerns preclude such 275 support. 277 o Distinct mobility frequencies (see mobility factor in [2]). 279 o Distinct access media. 281 In order to keep complexity minimal, transit networks are excluded 282 from this list. A transit network is one in which data would be 283 forwarded between two endpoints outside of the network, so that the 284 network itself simply serves as a transitional conduit for packet 285 forwarding. A stub network (leaf network), on the other hand, does 286 not serve as a data forwarding path. Data on a stub network is 287 either sent by or addressed to a node located within that network. 289 3.6. Local Mobility and Global Mobility 291 Mobile networks and mobile nodes owned by different administrative 292 entities are expected to be displaced within a domain boundary or 293 between domain boundaries. Multihoming, vertical and horizontal 294 handoffs, and access control mechanisms are desirable to achieve this 295 goal. Such mobility is not expected to be limited for any 296 consideration other than administrative and security policies. 298 3.7. Scalability 300 NEMO support signaling and processing is expected to scale to a 301 potentially large number of mobile networks irrespective of their 302 configuration, mobility frequency, size and number of CNs. 304 3.8. Backward Compatibility 306 NEMO support will have to co-exist with established IPv6 standards 307 and not interfer with them. Standards defined in other IETF working 308 groups have to be reused as much as possible and extended only if 309 deemed necessary. For instance, the following mechanisms defined by 310 other working groups are expected to function without modidication: 312 o Address allocation and configuration mechanisms. 314 o Host mobility support: mobile nodes and correspondent nodes, 315 either located within or outside the mobile network, are expected 316 to continue operating protocols defined by the Mobile IP working 317 group. This include mechanisms for host mobility support (Mobile 318 IPv6) and seamless mobility (FMIPv6). 320 o Multicast support intended for MNNs is expected to be maintained 321 while the mobile router changes its point of attachment. 323 o Access control protocols and mechanisms used by visiting mobile 324 hosts and routers to be authenticated and authorized, gaining 325 access to the Internet via the mobile network infrastructure 326 (MRs). 328 o Security protocols and mechanisms. 330 o Mechanisms performed by routers deployed in both the visited 331 networks and in mobile networks (routing protocols, Neighbor 332 Discovery, ICMP, Router Renumbering). 334 3.9. Secure Signaling 336 NEMO support will have to comply with the usual IETF security 337 policies and recommendations and is expected to have its specific 338 security issues fully addressed. In practice, all NEMO support 339 control messages transmitted in the network will have to be protected 340 with an acceptable level of security to prevent intruders to usurp 341 identities and forge data. Specifically, the following issues have 342 to be considered: 344 o Authentication of the sender to prevent identity usurpation. 346 o Authorization, to make sure the sender is granted permission to 347 perform the operation as indicated in the control message. 349 o Confidentiality of the data contained in the control message. 351 3.10. Location Privacy 353 Location privacy means to hide the actual location of MNNS to third 354 parties other than the HA are desired. It is not clear to which 355 extend this has to be enforced, since it is always possible to 356 determine the topological location by analysing IPv6 headers. It 357 would thus require some kind of encryption of the IPv6 header to 358 prevent third parties from monitoring IPv6 addresses between the MR 359 and the HA. On the other hand, it is at the very least desirable to 360 provide a means for MNNs to hide their real topological location to 361 their CNs. 363 3.11. IPv4 and NAT Traversal 365 IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, 366 so it is desirable to ensure mechanisms developed for NEMO will be 367 able to traverse such clouds. 369 4. NEMO Basic Support One-Liner Requirements 371 For basic network mobility support, the NEMO WG is to specify a 372 unified and unique "Network Mobility (NEMO) Basic Support" solution, 373 hereafter referred to as "the solution". This solution is to allow 374 all nodes in the mobile network to be reachable via permanent IP 375 addresses, as well as maintain ongoing sessions as the MR changes its 376 point of attachment to the Internet topology. This is to be done by 377 maintaining a bi-directional tunnel between an MR and its Home Agent. 379 The NEMO Working Group, after some investigation of alternatives, has 380 decided to reuse and extend the existing Mobile IPv6 [5] mechanisms 381 for tunnel management. 383 The list of requirements below has been imposed on the NEMO Basic 384 Support solution. The requirements have mostly been met by the 385 resulting specification which can now be found in [3]. Associated 386 deployment issues are discussed in [9] 388 R01: The solution MUST be implemented at the IP layer level. 390 R02: The solution MUST set up a bi-directional tunnel between a 391 Mobile Router and its Home Agent (MRHA tunnel) 393 R03: All traffic exchanged between an MNN and a CN in the global 394 Internet MUST transit through the bi-directional MRHA tunnel. 396 R04: MNNs MUST be reachable at a permanent IP address and name. 398 R05: The solution MUST maintain continuous sessions (both unicast 399 and multicast) between MNNs and arbitrary CNs after IP handover of 400 (one of) the MR. 402 R06: The solution MUST not require modifications to any node other 403 than MRs and HAs. 405 R07: The solution MUST support fixed nodes, mobile hosts and 406 mobile routers in the mobile network. 408 R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile 409 network link as either a home link or a foreign link. 411 R09: The solution MUST ensure backward compatibility with other 412 standards defined by the IETF. In particular, this includes: 414 R09:1: The solution MUST not prevent the proper operation of 415 Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to 416 operate either the CN, HA, or MN operations defined in [5]) 418 R10: The solution MUST treat all the potential configurations the 419 same way (whatever the number of subnets, MNNs, nested levels of 420 MRs, egress interfaces) 422 R11: The solution MUST support at least 2 levels of nested mobile 423 networks, while, in principle, arbitrary levels of recursive 424 mobile networks SHOULD be supported. 426 R12: The solution MUST function for multihomed MRs and multihomed 427 mobile networks as defined in [1]. 429 R13: NEMO Support signaling over the bi-directional MUST be 430 minimized 432 R14: Signaling messages between the HA and the MR MUST be secured: 434 R14.1: The receiver MUST be able to authenticate the sender. 436 R14.2: The function performed by the sender MUST be authorized 437 for the content carried. 439 R14.3: Anti-replay MUST be provided. 441 R14.4: The signaling messages MAY be encrypted. 443 R15: The solution MUST ensure transparent continuation of routing 444 and management operations over the bi-directional tunnel (this 445 includes e.g. unicast and multicast routing protocols, router 446 renumbering, DHCPv6) 448 R16: When one egress interface fails, the solution MAY preserve 449 sessions established through another egress interface. 451 5. Security Considerations 453 As this document only provides a discussion about design goals and 454 describes neither a protocol nor an implementation or a procedure, 455 there are no security considerations associated with it. 457 6. IANA Considerations 459 This document requires no IANA actions. 461 7. Acknowledgments 463 The material presented in this document takes most of its text from 464 discussions and previous documents submitted to the NEMO working 465 group. This includes initial contributions from Motorola, INRIA, 466 Ericsson and Nokia. We are particularly grateful to Hesham Soliman 467 (Ericsson) and the IETF ADs at the time (Erik Nordmark and Thomas 468 Narten) who greatly helped to set up the NEMO working group. We are 469 also grateful to all the following people whose comments highly 470 contributed to the present document: T.J. Kniveton (Nokia), Alexandru 471 Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert 472 (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and 473 all the others people who have expressed their opinions on the NEMO 474 mailing lists (formely known as MONET). Thierry Ernst wishes to 475 personally acknowledge INRIA Rhone-Alpes and Motorola Labs Paris for 476 their support and direction in bringing this topic up to the IETF 477 back in year 2001 -- particularly Claude Castelluccia (INRIA) and 478 Hong-Yon Lach (Motorola) -- and his past employer, Keio University, 479 Japan which supported most of the costs associated with the IETF 480 during the timelife of previous versions of this document. 482 8. References 484 8.1. Normative References 486 [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 487 draft-ietf-nemo-terminology-06 (work in progress), 488 November 2006. 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 sector 502 - Networking Protocol - Complementary Element", ISO Draft ISO/WD 503 21210, February 2005. 505 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 506 IPv6", RFC 3775, June 2004. 508 [6] Ng, C., Pascal, P., Masafumi, M., and F. Fan, "Network Mobility 509 Route Optimization Problem Statement", 510 draft-ietf-nemo-ro-problem-statement-03 (work in progress), 511 September 2006. 513 [7] Ng, C., Fan, F., Masafumi, M., and P. Pascal, "Network Mobility 514 Route Optimization Solution Space Analysis", 515 draft-ietf-nemo-ro-space-analysis-03 (work in progress), 516 September 2006. 518 [8] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in 519 Network Mobility Support", draft-ietf-nemo-multihoming-issues-06 520 (work in progress), June 2006. 522 [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home 523 Network Models", draft-ietf-nemo-home-network-models-06 (work in 524 progress), February 2006. 526 Author's Address 528 Thierry Ernst 529 INRIA 530 INRIA Rocquencourt 531 Domaine de Voluceau B.P. 105 532 Le Chesnay, 78153 533 France 535 Phone: +33 1 39 63 59 30 536 Fax: +33 1 39 63 54 91 537 Email: thierry.ernst@inria.fr 538 URI: http://www-rocq.inria.fr/imara 540 Full Copyright Statement 542 Copyright (C) The Internet Society (2006). 544 This document is subject to the rights, licenses and restrictions 545 contained in BCP 78, and except as set forth therein, the authors 546 retain all their rights. 548 This document and the information contained herein are provided on an 549 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 550 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 551 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 552 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 553 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 554 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 556 Intellectual Property 558 The IETF takes no position regarding the validity or scope of any 559 Intellectual Property Rights or other rights that might be claimed to 560 pertain to the implementation or use of the technology described in 561 this document or the extent to which any license under such rights 562 might or might not be available; nor does it represent that it has 563 made any independent effort to identify any such rights. Information 564 on the procedures with respect to rights in RFC documents can be 565 found in BCP 78 and BCP 79. 567 Copies of IPR disclosures made to the IETF Secretariat and any 568 assurances of licenses to be made available, or the result of an 569 attempt made to obtain a general license or permission for the use of 570 such proprietary rights by implementers or users of this 571 specification can be obtained from the IETF on-line IPR repository at 572 http://www.ietf.org/ipr. 574 The IETF invites any interested party to bring to its attention any 575 copyrights, patents or patent applications, or other proprietary 576 rights that may cover technology that may be required to implement 577 this standard. Please address the information to the IETF at 578 ietf-ipr@ietf.org. 580 Acknowledgment 582 Funding for the RFC Editor function is provided by the IETF 583 Administrative Support Activity (IASA).