idnits 2.17.1 draft-ietf-nemo-requirements-03.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 10) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 385: '...01: The solution MUST be implemented a...' RFC 2119 keyword, line 387: '...02: The solution MUST set up a bi-dire...' RFC 2119 keyword, line 391: '... Internet MUST transit through th...' RFC 2119 keyword, line 393: '... R04: MNNs MUST be reachable at a...' RFC 2119 keyword, line 395: '...05: The solution MUST maintain continu...' (21 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 [1]) == 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: R16: The solution MUST not impact on the routing fabric neither on the Internet addressing architecture. [ACCORDING TO IETF56 minutes, SHOULD BE REMOVED] -- 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 25, 2004) is 7122 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: '6' is defined on line 539, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 543, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-home-network-models-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '6') ** Obsolete normative reference: RFC 2460 (ref. '7') (Obsoleted by RFC 8200) Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group T. Ernst 2 Internet-Draft WIDE at Keio University 3 Expires: April 25, 2005 October 25, 2004 5 Network Mobility Support Goals and Requirements 6 draft-ietf-nemo-requirements-03 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-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 April 25, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 Network mobility arises when a router connecting an entire network to 42 the Internet dynamically changes its point of attachment to the 43 Internet therefrom causing the reachability of the entire network to 44 be changed in the topology. Such kind of network is referred to as a 45 mobile network. Without appropriate mechanisms, sessions established 46 between nodes in the mobile network and the global Internet cannot be 47 maintained while the mobile router changes its point of attachment. 48 The required support mechanisms will be provided in two phases. The 49 first phase, referred to as NEMO Basic Support is to provide session 50 continuity while the necessary optimizations mechanims referred to as 51 NEMO Extended Support might be provided later. This document 52 outlines the goals expected from network mobility support and defines 53 the requirements that must be met by NEMO Basic Support solutions. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. NEMO Working Group Objectives and Methodology . . . . . . . 4 61 3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 5 62 3.1 Migration Transparency . . . . . . . . . . . . . . . . . . 5 63 3.2 Performance Transparency and Seamless Mobility . . . . . . 5 64 3.3 Network Mobility Support Transparency . . . . . . . . . . 5 65 3.4 Operational Transparency . . . . . . . . . . . . . . . . . 6 66 3.5 Arbitrary Configurations . . . . . . . . . . . . . . . . . 6 67 3.6 Local Mobility and Global Mobility . . . . . . . . . . . . 7 68 3.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.8 Backward Compatibility . . . . . . . . . . . . . . . . . . 7 70 3.9 Secure Signaling . . . . . . . . . . . . . . . . . . . . . 8 71 3.10 Location Privacy . . . . . . . . . . . . . . . . . . . . 8 72 3.11 IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . 8 74 4. NEMO Basic Support One-Liner Requirements . . . . . . . . . 8 76 5. Changes Between Versions . . . . . . . . . . . . . . . . . . 10 77 5.1 Changes between version -02 and -03 . . . . . . . . . . . 10 78 5.2 Changes Between Version -01 and -02 . . . . . . . . . . . 10 79 5.3 Changes Between Version -00 and -01 . . . . . . . . . . . 11 81 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 87 Intellectual Property and Copyright Statements . . . . . . . 13 89 1. Introduction 91 Network mobility support is concerned with managing the mobility of 92 an entire network, viewed as a single unit, which changes its point 93 of attachment to the Internet and thus its reachability in the 94 Internet topology. Such kind of network is referred to as a mobile 95 network and includes one or more mobile routers (MRs) which connect 96 it to the global Internet. Nodes behind the MR(s) (MNNs) are both 97 fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal 98 structure of the mobile network will in effect be relatively stable 99 (no dynamic change of the topology), but this is not a general 100 assumption. 102 Cases of mobile networks include for instance: 104 o networks attached to people (Personal Area Networks or PANs): a 105 cell-phone with one cellular interface and one Bluetooth interface 106 together with a Bluetooth-enabled PDA constitute a very simple 107 instance of a mobile network. The cell-phone is the mobile router 108 while the PDA is used for web browsing or runs a personal web 109 server. 111 o networks of sensors and computers deployed in vehicles: vehicles 112 are more and more embedded with a number of processing units for 113 safety and ease of driving reasons, as advocated by ITS 114 (Intelligent Transportation Systems) applications. 116 o access networks deployed in public transportation (buses, trains, 117 taxis, aircrafts): they provide Internet access to IP devices 118 carried by passengers (laptop, camera, mobile phone: host mobility 119 within network mobility or PANs: network mobility within network 120 mobility, i.e. nested mobility). 122 o ad-hoc networks connected to the Internet via a MR: for instance 123 students in a train that both need to set up an ad-hoc network 124 among themselves and to get Internet connectivity through the MR 125 connecting the train to the Internet. 127 Mobility of networks does not cause MNNs to change their own physical 128 point of attachment, however they happen to change their topological 129 location with respect to the global Internet. If network mobility is 130 not explicitly supported by some mechanisms, the mobility of the MR 131 results into MNNs losing Internet access and breaking ongoing 132 sessions entertained between arbitrary correspondent node (CNs) in 133 the global Internet and those MNNs located within the mobile network. 134 In addition, the communication path between MNNs and arbitrary 135 correspondent nodes (CN) becomes sub-optimal, whereas multiple levels 136 of mobility will cause extremely sub-optimal routing. 138 The mechanisms required for handling such mobility issues are 139 currently lacking within the IETF standards. Traditional work 140 conducted on mobility support (particularly in the Mobile IP working 141 group) is to provide continuous Internet connectivity and optimal 142 routing to mobile hosts only (host mobility support) and are unable 143 to support network mobility. The NEMO working group has therefore 144 been set up to deal with issues specific to network mobility. The 145 purpose of this document is thus to detail the methodology that will 146 be followed by the NEMO working group, its goals, and to define 147 requirements for network mobility support. 149 Mobility-related terms used in this document are defined in [3] 150 whereas terms pertaining to network mobility specifically are defined 151 in [4]. This document is structured as follows: Section 2 defines 152 the rough objectives and methodology of the NEMO working group and we 153 emphasize the stepwise approach the working group has decided to 154 follow. A number of desirable design goals are listed in Section 3. 155 Those design goals serve as guidelines to edict the requirements 156 listed in Section 4 for basic network mobility support [2]. 158 2. NEMO Working Group Objectives and Methodology 160 The primary objective of the NEMO work is to specify a solution which 161 allows mobile network nodes (MNNs) to remain connected to the 162 Internet and continuously reachable at all times while the mobile 163 network they are attached to changes its point of attachment. 164 Secondary goals of the work is to investigate the effects of network 165 mobility on various aspects of internet communication such as routing 166 protocol changes, implications of realtime traffic and fast 167 handovers, optimizations. These should all support the primary goal 168 of reachability for mobile network nodes. Security is an important 169 consideration too, and efforts should be made to use existing 170 solutions if they are appropriate. Although a well-designed solution 171 may include security inherent in other protocols, mobile networks 172 also introduce new challenges. 174 For doing so, the NEMO working group has decided to take a stepwise 175 approach by standardizing a basic solution to preserve session 176 continuity (NEMO Basic Support), and at the same time study the 177 possible approaches and issues with providing more optimal routing 178 with potentially nested mobile networks (NEMO Extended Support). 179 However, the working group is not chartered to actually standardize a 180 solution to such route optimization at this point in time. 182 For NEMO Basic Support, the working group will assume that none of 183 the nodes behind the MR will be aware of the network's mobility, thus 184 the network's movement needs to be completely transparent to the 185 nodes inside the mobile network. This assumption will be made to 186 accommodate nodes inside the network that are not generally aware of 187 mobility. 189 The efforts of the Mobile IP working group have resulted in the 190 Mobile IPv4 and Mobile IPv6 protocols, which have already solved the 191 issue of host mobility support. Since challenges to enabling mobile 192 networks are vastly reduced by this work, basic network mobility 193 support will adopt the methods for host mobility support used in 194 Mobile IP, and extend them in the simplest way possible to achieve 195 its goals. The basic support solution is for each MR to have a Home 196 Agent, and use bidirectional tunneling between the MR and HA to 197 preserve session continuity while the MR moves. The MR will acquire 198 a Care-of-address from its attachment point much like what is done 199 for mobile nodes (MN) using Mobile IP. This approach allows nested 200 mobile networks, since each MR will appear to its attachment point as 201 a single node. 203 3. NEMO Support Design Goals 205 This section details the fundamental design goals the solutions will 206 tend to achieve. Those design goals will serve to edict and 207 understand the requirements defined for forthcoming solutions. 208 Actual requirements for NEMO Basic Support are in the next section, 209 whereas NEMO Extended Support has not yet been considered. 211 3.1 Migration Transparency 213 A permanent connectivity to the Internet has to be provided to all 214 MNNs while continuous sessions are expected to be maintained as the 215 mobile router changes its point of attachment. For doing so, MNNs 216 are expected to be reachable via their permanent IP addresses. 218 3.2 Performance Transparency and Seamless Mobility 220 NEMO support is expected to be provided with limited signaling 221 overhead and to minimize the impact of handover over applications, in 222 terms of packet loss or delay. However, although variable delays of 223 transmission and losses between MNNs and their respective CNs could 224 be perceived as the network is displaced, it would not be considered 225 a lack of performance transparency. 227 3.3 Network Mobility Support Transparency 229 MNNs behind the MR(s) don't change their own physical point of 230 attachment as a result of the mobile network's displacement in the 231 Internet topology. Consequently, NEMO support is expected to be 232 performed by the sole MR(s) and specific support functions on any 233 other node than the MR(s) would better be avoided. 235 3.4 Operational Transparency 237 NEMO support is to be implemented at the IP layer level. It is 238 expected to be transparent to upper layers so that any upper layer 239 protocol can run unchanged on top of an IP layer extended with NEMO 240 support. 242 3.5 Arbitrary Configurations 244 The formation of a mobile network can exist in various levels of 245 complexity. In the simplest case, a mobile network contains just a 246 mobile router and a host. In the most complicated case, a mobile 247 network is multihomed and is itself a multi-level aggregation of 248 mobile networks with collectively thousands of mobile routers and 249 hosts. While the list of potential configurations of mobile networks 250 cannot be limited, at least the following configurations are 251 desirable: 253 o mobile networks of any size, ranging from a sole subnet with a few 254 IP devices to a collection of subnets with a large number of IP 255 devices, 257 o nodes that change their point of attachment within the mobile 258 network, 260 o foreign mobile nodes that attach to the mobile network, 262 o multihomed mobile network either when a single MR has multiple 263 attachments to the internet, or when the mobile network is 264 attached to the Internet by means of multiple MRs (see definition 265 in [4] and the analys in [5]), 267 o nested mobile networks (mobile networks attaching to other mobile 268 networks (see definition in [4]). Although the complexity 269 requirements of those nested networks is not clear, it is 270 desirable to support arbitrary levels of recursive networks, and 271 only in the case where this is impractical and protocol concerns 272 preclude this support should the solution impose restrictions on 273 nesting (e.g. path MTU), 275 o distinct mobility frequencies (see mobility factor in [3]) 277 o distinct access medium. 279 In order to keep complexity minimal, transit networks are excluded 280 from this list. A transit network is one in which data would be 281 forwarded between two endpoints outside of the network, so that the 282 network itself simply serves as a transitional conduit for packet 283 forwarding. A stub network (leaf network), on the other hand, does 284 not serve as a data forwarding path. Data on a stub network is 285 either sent by or addressed to a node located within that network. 287 3.6 Local Mobility and Global Mobility 289 Mobile networks and mobile nodes owned by administratively different 290 entities are expected to be displaced within a domain boundary or 291 between domain boundaries. Multihoming, vertical and horizontal 292 handoffs, and access control mechanisms are desirable to achieve this 293 goal. Such mobility type is not expected to be limited for any 294 consideration other than administrative and security policies. 296 3.7 Scalability 298 NEMO support signaling and processing is expected to scale to a 299 potentially large number of mobile networks irrespective of their 300 configuration, mobility frequency, size and number of CNs. 302 3.8 Backward Compatibility 304 NEMO support will have to co-exist with existing IPv6 standards 305 without interfering with them. Standards defined in other IETF 306 working groups have to be reused as much as possible and extended 307 only if deemed necessary. For instance, the following mechanisms 308 defined by other working groups are expected to function without 309 modidications: 311 o Address allocation and configuration mechanisms 313 o Host mobility support: mobile nodes and correspondent nodes, 314 either located within or outside the mobile network are expected 315 to keep operating protocols defined by the Mobile IP working 316 group. This include mechanisms for host mobility support (Mobile 317 IPv6) and seamless mobility (FMIPv6). 319 o Multicast support entertained by MNNs are expected to be 320 maintained while the mobile router changes its point of 321 attachment. 323 o Access control protocols and mechanisms used by visiting mobile 324 hosts and routers to be authenticated and authorized to gain 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 both in 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 usual IETF security policies 337 and recommendations and is expected to have its specific security 338 issues fully addressed. In practice, all NEMO support control 339 messages transmitted in the network will have to ensure an acceptable 340 level of security to prevent intruders to usurp identities and forge 341 data. Specifically, the following issues have to be considered: 343 o Authentication of the sender to prevent identity usurpation. 345 o Authorization, to make sure the sender is granted permission to 346 perform the operation as indicated in the control message. 348 o Confidentiality of the data contained in the control message. 350 3.10 Location Privacy 352 Means to hide the actual location of MNNS to third parties other than 353 the HA are desired. In which extend this has to be enforced is not 354 clear since it is always possible to determine the topological 355 location by analysing IPv6 headers. It would thus require some kind 356 of encryption of the IPv6 header to prevent third parties to monitor 357 IPv6 addresses between the MR and the HA. On the other hand, it is 358 at the very least desirable to provide means for MNNs to hide their 359 real topological location to their CNs. 361 3.11 IPv4 and NAT Traversal 363 IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, 364 so it is desirable to ensure mechanisms developped for NEMO will be 365 able to traverse such clouds. 367 4. NEMO Basic Support One-Liner Requirements 369 The NEMO WG is to specify a unified and unique "Network Mobility 370 Basic Support" solution, hereafter referred to as "the solution". 371 This solution is to allow all nodes in the mobile network to be 372 reachable via permanent IP addresses, as well as maintain ongoing 373 sessions as the MR changes its point of attachment to the Internet 374 topology. This is to be done by maintaining a bidirectional tunnel 375 between a MR and its Home Agent. 377 For doing so, the NEMO Working Group has decided to investigate 378 reusing the existing Mobile IPv6 [1] mechanisms for the tunnel 379 management, or extend it if deemed necessary. 381 The list of requirements below have been placed on the NEMO Basic 382 Support solution. They have been mostly met by the resulting 383 specification which can now be found in [2]. 385 R01: The solution MUST be implemented at the IP layer level. 387 R02: The solution MUST set up a bi-directional tunnel between a 388 Mobile Router and its Home Agent (MRHA tunnel) 390 R03: All traffic exchanged between a MNN and a CN in the global 391 Internet MUST transit through the bidirectional MRHA tunnel. 393 R04: MNNs MUST be reachable at a permanent IP address and name. 395 R05: The solution MUST maintain continuous sessions (both unicast 396 and multicast) between MNNs and arbitrary CNs after IP handover of 397 (one of) the MR. 399 R06: The solution MUST not require modifications to any node other 400 than MRs and HAs. 402 R07: The solution MUST support fixed nodes, mobile hosts and 403 mobile routers in the mobile network. 405 R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile 406 network link as either a home link or a foreign link. 408 R09: The solution MUST ensure backward compatibility with other 409 standards defined by the IETF. This include particularly: 411 R09:1: The solution MUST not prevent the proper operation of 412 Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs 413 to operate either the CN, HA, or MN operations defined in [1]) 415 R10: The solution MUST treat all the potential configurations the 416 same way (whatever the number of subnets, MNNs, nested levels of 417 MRs, egress interfaces, ...) 419 R11: The solution MUST support at least 2 levels of nested mobile 420 networks, while, in principle, arbitrary levels of recursive 421 mobile networks SHOULD be supported. 423 R12: The solution MUST function for multihomed MR and multihomed 424 mobile networks as defined in [4]. 426 R13: NEMO Support signaling over the bidirectional MUST be 427 minimized 429 R14: Signaling messages between the HA and the MR MUST be secured: 431 R14.1: The receiver MUST be able to authenticate the sender 433 R14.2: The function performed by the sender MUST be authorized 434 for the content carried 436 R14.3: Anti-replay MUST be provided 438 R14.4: The signaling messages MAY be encrypted 440 R15: The solution MUST ensure transparent continuation of routing 441 and management operations over the bi-directional tunnel (this 442 includes e.g. unicast and multicast routing protocols, router 443 renumbering, DHCPv6, etc) 445 R16: The solution MUST not impact on the routing fabric neither on 446 the Internet addressing architecture. [ACCORDING TO IETF56 447 minutes, SHOULD BE REMOVED] 449 R18: The solution MAY preserve sessions established through 450 another egress interface when one fails 452 5. Changes Between Versions 454 5.1 Changes between version -02 and -03 456 - Mostly cosmetic changes 458 - Merged section Terminology into Introduction 460 - Cross-references with other NEMO WG docs 462 - Changed the introducion of section Section 4 and added reference to 463 NEMO Basic Support's resulting specification. 465 5.2 Changes Between Version -01 and -02 467 - removed sub-items in R12 (sub-cases are contained into the 468 definition of multihoming) 470 - minor typos 472 - R15: Added "multicast" 473 - R14.4: SHOULD softened to MAY according to discussion at IETF56th 474 meeting. 476 - R17 moved to R09 and contains former R09 as a sub-case. 478 - R18: relaxed from "SHOULD" to may based on Vijay Devarapalli 479 comment (030718) 481 5.3 Changes Between Version -00 and -01 483 - title of documents: included the word "goals" 485 - entire document: some rewording 487 - section 4: changed title of section to "NEMO Design Goals". 489 - section 4: removed "MUST" and "MAY" 491 - section 4: more text about location privacy 493 - section 4: changed "Administration" paragraph to "Local and Global 494 Mobility". Text enhanced. 496 - section 5: R02: replace "between MR and MR's HA" with "a MR and its 497 HA" R11: specified at least 2 levels R12: replaced "support" with 498 "function" and add "multihomed MR" R13.x renumbered to R12.x since 499 part of R12 (editing mistake) R13 and R18: new requirements proposed 500 by editor and minor changes in the formulation of other Requirements 502 6. Acknowledgments 504 The material presented in this document takes most of its text from 505 discussions and previous documents submitted to the NEMO working 506 group. This includes initial contributions from Motorola, INRIA, 507 Ericsson and Nokia. We are particularly grateful to Hesham Soliman 508 (Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who 509 highly helped to set up the NEMO working group. We are also grateful 510 to all the following people whose comments highly contributed to the 511 present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola), 512 Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon 513 Lach (Motorola), Mattias Petterson (Ericsson) and all the others 514 people who have expressed their opinions on the NEMO (formely MONET) 515 mailing list. Thierry Ernst wish to personally grant support to its 516 previous employers, INRIA, and Motorola for their support and 517 direction in bringing this topic up to the IETF, particularly Claude 518 Castelluccia (INRIA) and Hong-Yon Lach (Motorola). 520 7 References 522 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 523 IPv6", RFC 3775, June 2004. 525 [2] Devarapalli, V., "Network Mobility (NEMO) Basic Support 526 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 527 June 2004. 529 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 530 3753, June 2004. 532 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 533 draft-ietf-nemo-terminology-02 (work in progress), October 2004. 535 [5] Ng, C-W., Paik, E-K. and T. Ernst, "Analysis of Multihoming in 536 Network Mobility Support", draft-ietf-nemo-multihoming-issues-01 537 (work in progress), October 2004. 539 [6] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network 540 Models", draft-ietf-nemo-home-network-models-01 (work in 541 progress), October 2004. 543 [7] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", 544 IETF RFC 2460, December 1998. 546 Author's Address 548 Thierry Ernst 549 WIDE at Keio University 550 Jun Murai Lab., Keio University. 551 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 552 Kawasaki, Kanagawa 212-0054 553 Japan 555 Phone: +81-44-580-1600 556 Fax: +81-44-580-1437 557 EMail: ernst@sfc.wide.ad.jp 558 URI: http://www.sfc.wide.ad.jp/~ernst/ 560 Intellectual Property Statement 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Disclaimer of Validity 586 This document and the information contained herein are provided on an 587 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 588 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 589 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 590 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 591 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 592 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 594 Copyright Statement 596 Copyright (C) The Internet Society (2004). This document is subject 597 to the rights, licenses and restrictions contained in BCP 78, and 598 except as set forth therein, the authors retain all their rights. 600 Acknowledgment 602 Funding for the RFC Editor function is currently provided by the 603 Internet Society.