idnits 2.17.1 draft-ietf-nemo-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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: 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 [MIPv6]) [SHOULD BE MOVED UNDER R17] == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 520 looks like a reference -- Missing reference section? 'MOBILITY-TERMS' on line 506 looks like a reference -- Missing reference section? 'NEMO-TERMS' on line 511 looks like a reference -- Missing reference section? 'MIPv6' on line 382 looks like a reference -- Missing reference section? 'IPv6-NODE' on line 492 looks like a reference -- Missing reference section? 'MobileIPv4' on line 497 looks like a reference -- Missing reference section? 'MobileIPv6' on line 501 looks like a reference -- Missing reference section? 'RFC1122' on line 516 looks like a reference -- Missing reference section? 'RFC2460' on line 524 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group Thierry Ernst, Editor 3 Internet-Draft WIDE and INRIA 4 May, 2003 6 "Network Mobility Support Goals and Requirements" 7 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Network mobility arises when a router connecting an entire network to 32 the Internet dynamically changes its point of attachment to the 33 Internet therefrom causing the reachability of the entire network to 34 be changed in the topology. Such kind of network is referred to as a 35 mobile network. Without appropriate mechanisms, sessions established 36 between nodes in the mobile network and the global Internet cannot be 37 maintained while the mobile router changes its point of attachment. 38 The required support mechanisms will be provided in two phases. The 39 first phase, referred to as NEMO Basic Support is to provide session 40 continuity while the necessary optimizations mechanims referred to as 41 NEMO Extended Support might be provided later. This document outlines 42 the goals expected from network mobility support and defines the 43 requirements that must be met by NEMO Basic Support solutions. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03 49 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04 51 3. NEMO Working Group Goals and Methodology . . . . . . . . . . 04 53 4. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 05 55 5. NEMO Basic Support One-liner Requirements . . . . . . . . . 09 57 6. Changes From Previous Version . . . . . . . . . . . . . . . 11 59 A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11 61 B. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 65 D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 1. Introduction 75 Network mobility support is concerned with managing the mobility of 76 an entire network, viewed as a single unit, which changes its point 77 of attachment to the Internet and thus its reachability in the 78 Internet topology. Such kind of network is referred to as a mobile 79 network and includes one or more mobile routers (MRs) which connect 80 it to the global Internet. Nodes behind the MR(s) (MNNs) are both 81 fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal 82 structure of the mobile network will in effect be relatively stable 83 (no dynamic change of the topology), but this is not a general 84 assumption. 86 Cases of mobile networks include for instance: 88 - networks attached to people (Personal Area Networks or PANs): a 89 cell-phone with one cellular interface and one Bluetooth interface 90 together with a Bluetooth-enabled PDA constitute a very simple 91 instance of a mobile network. The cell-phone is the mobile router 92 while the PDA is used for web browsing or runs a personal web 93 server. 95 - networks of sensors and computers deployed in vehicles: vehicles 96 are more and more embedded with a number of processing units for 97 safety and ease of driving reasons, as advocated by ITS 98 (Intelligent Transportation Systems) applications. 100 - access networks deployed in public transportation (buses, 101 trains, taxis, aircrafts): they provide Internet access to IP 102 devices carried by passengers (laptop, camera, mobile phone: host 103 mobility within network mobility or PANs: network mobility within 104 network mobility, i.e. nested mobility). 106 - ad-hoc networks connected to the Internet via a MR: for instance 107 students in a train that both need to set up an ad-hoc network 108 among themselves and to get Internet connectivity through the MR 109 connecting the train to the Internet. 111 Mobility of networks does not cause MNNs to change their own physical 112 point of attachment, however they happen to change their topological 113 location with respect to the global Internet. If network mobility is 114 not explicitly supported by some mechanisms, the mobility of the MR 115 results into MNNs losing Internet access and breaking ongoing 116 sessions entertained between arbitrary correspondent node (CNs) in 117 the global Internet and those MNNs located within the mobile network. 118 In addition, the communication path between MNNs and arbitrary 119 correspondent nodes (CN) becomes sub-optimal, whereas multiple levels 120 of mobility will cause extremely sub-optimal routing. 122 The mechanisms required for handling such mobility issues are 123 currently lacking within the IETF standards. Traditional work 124 conducted on mobility support (particularly in the Mobile IP working 125 group) is to provide continuous Internet connectivity and optimal 126 routing to mobile hosts only (host mobility support) and are unable 127 to support network mobility. The NEMO working group has therefore 128 been set up to deal with issues specific to network mobility. The 129 purpose of this document is thus to detail the methodology that will 130 be followed by the NEMO working group, its goals, and to define 131 requirements for network mobility support. 133 This document is structured as follows: in section 3, we define the 134 goals and methodology of the NEMO working group and we emphasize the 135 stepwise approach the working group has decided to follow. A number 136 of desirable design goals are listed in section 4. Those design goals 137 serve as guidelines to edict the requirements for basic network 138 mobility support. 140 2. Terminology 142 Mobility-related terms used in this document are defined in 143 [MOBILITY-TERMS] whereas terms pertaining to network mobility 144 specifically are defined in [NEMO-TERMS]. 146 3. NEMO Working Group Goals and Methodology 148 The primary goal of the NEMO work is to specify a solution which 149 allows mobile network nodes (MNNs) to remain connected to the 150 Internet and continuously reachable at all times while the mobile 151 network they are attached to changes its point of attachment. 152 Secondary goals of the work is to investigate the effects of network 153 mobility on various aspects of internet communication such as routing 154 protocol changes, implications of realtime traffic and fast 155 handovers, optimizations. These should all support the primary goal 156 of reachability for mobile network nodes. Security is an important 157 consideration too, and efforts should be made to use existing 158 solutions if they are appropriate. Although a well-designed solution 159 may include security inherent in other protocols, mobile networks 160 also introduce new challenges. 162 For doing so, the NEMO working group has decided to take a stepwise 163 approach by standardizing a basic solution to preserve session 164 continuity (NEMO Basic Support), and at the same time study the 165 possible approaches and issues with providing more optimal routing 166 with potentially nested mobile networks (NEMO Extended Support). 167 However, the working group is not chartered to actually standardize a 168 solution to such route optimization at this point in time. 170 For NEMO Basic Support, the working group will assume that none of 171 the nodes behind the MR will be aware of the network's mobility, thus 172 the network's movement needs to be completely transparent to the 173 nodes inside the mobile network. This assumption will be made to 174 accommodate nodes inside the network that are not generally aware of 175 mobility. 177 The efforts of the Mobile IP working group have resulted in the 178 Mobile IPv4 and Mobile IPv6 protocols, which have already solved the 179 issue of host mobility support. Since challenges to enabling mobile 180 networks are vastly reduced by this work, basic network mobility 181 support will adopt the methods for host mobility support used in 182 Mobile IP, and extend them in the simplest way possible to achieve 183 its goals. The basic support solution is for each MR to have a Home 184 Agent, and use bidirectional tunneling between the MR and HA to 185 preserve session continuity while the MR moves. The MR will acquire a 186 Care-of-address from its attachment point much like what is done for 187 mobile nodes (MN) using Mobile IP. This approach allows nested mobile 188 networks, since each MR will appear to its attachment point as a 189 single node. 191 4. NEMO Suppport Design Goals 193 This section details the fundamental design goals the solutions will 194 tend to achieve. Those design goals will serve to edict and 195 understand the requirements defined for forthcoming solutions. Actual 196 requirements for NEMO Basic Support are in the next section, whereas 197 NEMO Extended Support has not yet been considered. 199 - Migration Transparency: a permanent connectivity to the Internet 200 has to be provided to all MNNs while continuous sessions are 201 expected to be maintained as the mobile router changes its point 202 of attachment. For doing so, MNNs are expected to be reachable via 203 their permanent IP addresses. 205 - Performance Transparency and Seamless Mobility: NEMO support is 206 expected to be provided with limited signaling overhead and to 207 minimize the impact of handover over applications, in terms of 208 packet loss or delay. However, although variable delays of 209 transmission and losses between MNNs and their respective CNs 210 could be perceived as the network is displaced, it would not be 211 considered a lack of performance transparency. 213 - Network Mobility Support Transparency: MNNs behind the MR(s) 214 don't change their own physical point of attachment as a result of 215 the mobile network's displacement in the Internet topology. 216 Consequently, NEMO support is expected to be performed by the sole 217 MR(s) and specific support functions on any other node than the 218 MR(s) would better be avoided. 220 - Operational Transparency: NEMO support is to be implemented at 221 the IP layer level. It is expected to be transparent to upper 222 layers so that any upper layer protocol can run unchanged on top 223 of an IP layer extended with NEMO support. 225 - Arbitrary Configurations: The formation of a mobile network can 226 exist in various levels of complexity. In the simplest case, a 227 mobile network contains just a mobile router and a host. In the 228 most complicated case, a mobile network is multi-homed and is 229 itself a multi-level aggregation of mobile networks with 230 collectively thousands of mobile routers and hosts. While the list 231 of potential configurations of mobile networks cannot be limited, 232 at least the following configurations are desirable: 234 o mobile networks of any size, ranging from a sole subnet with 235 a few IP devices to a collection of subnets with a large 236 number of IP devices, 238 o nodes that change their point of attachment within the mobile 239 network, 241 o foreign mobile nodes that attach to the mobile network, 243 o multi-homed mobile network either when a single MR has 244 multiple attachments to the internet, or when the mobile 245 network is attached to the Internet by means of multiple 246 MRs (see definition in [NEMO-TERMS]), 248 o nested mobile networks (mobile networks attaching to other 249 mobile networks, see definition in [NEMO-TERMS]. Although the 250 complexity requirements of those nested networks is not 251 clear, it is desirable to support arbitrary levels of 252 recursive networks, and only in the case where this is 253 impractical and protocol concerns preclude this support 254 should the solution impose restrictions on nesting 255 (e.g. path MTU), 257 o distinct mobility frequencies, 259 o distinct access medium. 261 In order to keep complexity minimal, transit networks are excluded 262 from this list. A transit network is one in which data would be 263 forwarded between two endpoints outside of the network, so that 264 the network itself simply serves as a transitional conduit for 265 packet forwarding. A stub network (leaf network), on the other 266 hand, does not serve as a data forwarding path. Data on a stub 267 network is either sent by or addressed to a node located within 268 that network. 270 - Local Mobility and Global Mobility: mobile networks and mobile 271 nodes owned by administratively different entities are expected to 272 be displaced within a domain boundary or between domain 273 boundaries. Multihoming, vertical and horizontal handoffs, and 274 access control mechanisms are desirable to achieve this goal. Such 275 mobility type is not expected to be limited for any consideration 276 other than administrative and security policies. 278 - Scalability: NEMO support signaling and processing is expected 279 to scale to a potentially large number of mobile networks 280 irrespective of their configuration, mobility frequency, size and 281 number of CNs. 283 - Backward Compatibility: NEMO support will have to co-exist with 284 existing IPv6 standards without interfering with them. Standards 285 defined in other IETF working groups have to be reused as much as 286 possible and extended only if deemed necessary. For instance, the 287 following mechanisms defined by other working groups are expected 288 to function without modidications: 290 o Address allocation and configuration mechanisms 292 o Host mobility support: mobile nodes and correspondent nodes, 293 either located within or outside the mobile network are 294 expected to keep operating protocols defined by the Mobile IP 295 working group. This include mechanisms for host mobility 296 support (Mobile IPv6) and seamless mobility (FMIPv6). 298 o Multicast support entertained by MNNs are expected to be 299 maintained while the mobile router changes its point of 300 attachment. 302 o Access control protocols and mechanisms used by visiting 303 mobile hosts and routers to be authenticated and authorized 304 to gain access to the Internet via the mobile network 305 infrastructure (MRs). 307 o Security protocols and mechanisms 309 o Mechanisms performed by routers deployed both in the visited 310 networks and in mobile networks (routing protocols, Neighbor 311 Discovery, ICMP, Router Renumbering, ...). 313 - Secure Signaling: NEMO support will have to comply with usual 314 IETF security policies and recommendations and is expected to have 315 its specific security issues fully addressed. In practice, all 316 NEMO support control messages transmitted in the network will have 317 to ensure an acceptable level of security to prevent intruders to 318 usurp identities and forge data. Specifically, the following 319 issues have to be considered: 321 o Authentication of the sender to prevent identity usurpation. 323 o Authorization, to make sure the sender is granted permission 324 to perform the operation as indicated in the control message. 326 o Confidentiality of the data contained in the control message. 328 - Location Privacy: means to hide the actual location of MNNS to 329 third parties other than the HA are desired. In which extend this 330 has to be enforced is not clear since it is always possible to 331 determine the topological location by analysing IPv6 headers. It 332 would thus require some kind of encryption of the IPv6 header to 333 prevent third parties to monitor IPv6 addresses between the MR and 334 the HA. On the other hand, it is at the very least desirable to 335 provide means for MNNs to hide their real topological location to 336 their CNs. 338 - IPv4 and NAT traversal: IPv4 clouds and NAT are likely to co- 339 exist with IPv6 for a long time, so it is desirable to ensure 340 mechanisms developped for NEMO will be able to traverse such 341 clouds. 343 5. NEMO Basic Support One-liner Requirements 345 The NEMO WG will specify a unified and unique solution for "Basic 346 Network Mobility Support". The solution will allow all nodes in the 347 mobile network to be reachable via permanent IP addresses, as well as 348 maintain ongoing sessions as the MR changes its point of attachment 349 to the Internet topology. This will be done by maintaining a 350 bidirectional tunnel between a MR and its Home Agent. The Working 351 Group will investigate reusing the existing Mobile IPv6 mechanisms 352 for the tunnel management, or extend it if deemed necessary. 354 The following requirements are placed on the NEMO Basic Support 355 solution, hereafter referred to as "the solution": 357 R01: The solution MUST be implemented at the IP layer level. 359 R02: The solution MUST set up a bi-directional tunnel between a 360 MR and its Home Agent. 362 R03: All traffic exchanged between a MNN and a CN in the global 363 Internet MUST transit through the bidirectional tunnel. 365 R04: MNNs MUST be reachable at a permanent IP address and name. 367 R05: The solution MUST maintain continuous sessions (both unicast 368 and multicast) between MNNs and arbitrary CNs after IP 369 handover of (one of) the MR. 371 R06: The solution MUST not require modifications to any node other 372 than MRs and HAs. 374 R07: The solution MUST support fixed nodes, mobile hosts and mobile 375 routers in the mobile network. 377 R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile 378 network link as either a home link or a foreign link. 380 R09: The solution MUST not prevent the proper operation of Mobile 381 IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to operate 382 either the CN, HA, or MN operations defined in [MIPv6]) 383 [SHOULD BE MOVED UNDER R17] 385 R10: The solution MUST treat all the potential configurations the 386 same way (whatever the number of subnets, MNNs, nested levels 387 of MRs, egress interfaces, ...) 389 R11: The solution MUST support at least 2 levels of nested mobile 390 networks, while, in principle, arbitrary levels of recursive 391 mobile networks SHOULD be supported. 393 R12: The solution MUST function for multihomed MR and multihomed 394 mobile networks as defined in [NEMO-TERMS]). Particularly: 396 R12.1: The solution MUST function for multi-MR mobile networks 398 R12.2: The solution MUST function for multi-egress 399 interfaces 401 R12.3: The solution MUST function for MR with multiple global 402 addresses on an egress interface. 404 [I PROPOSE TO REMOVE R12.1, 2 and 3 BECAUSE THIS IS 405 CONTAINED IN THE DEFINITION IN [NEMO-TERMS]]. 407 R13: NEMO Support signaling over the bidirectional MUST be minimized 408 [NEW REQUIREMENT PROPOSED BY EDITOR] 410 R14: Signaling messages between the HA and the MR MUST be secured: 412 R14.1: The receiver MUST be able to authenticate the sender 414 R14.2: The function performed by the sender MUST be authorized 415 for the content carried 417 R14.3: Anti-replay MUST be provided 419 R14.4: The signaling messages SHOULD be encrypted [ACCORDING TO 420 DISCUSSION AT IETF56, SHALL BE REMOVED or SOFTENED TO 421 "MAY" (?)] 423 R15: The solution MUST ensure transparent continuation of routing and 424 management operations over the bi-directional tunnel when the MR 425 is away from home. (this includes e.g. routing protocols, router 426 renumbering, DHCPv6, etc) 428 R16: The solution MUST not impact on the routing fabric neither on 429 the Internet addressing architecture. [ACCORDING TO IETF56 430 minutes, SHOULD BE REMOVED] 432 R17: The solution MUST ensure backward compatibility with other 433 standards defined by the IETF [SPECIFIC PROTOCOLS SHOULD BE 434 EXPLICITLY LISTED: MLD, ... etc. PLEASE CONTRIBUTE THE NAMES OF 435 PROTOCOLS TO BE INCLUDED ON THE MAILING LIST. MAYBE MIPV6 COULD 436 BE INCLUDED HERE INSTEAD OF R09.] Particularly: 438 R18: The solution SHOULD preserve sessions established through 439 another egress interface when one fails [PROPOSED BY EDITOR OF 440 THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE 441 MAILING LIST] 443 6. Changes since last version 445 - title of documents: included the word "goals" 447 - entire document: some rewording 449 - section 4: changed title of section to "NEMO Design Goals". 451 - section 4: removed "MUST" and "MAY" 453 - section 4: more text about location privacy 455 - section 4: changed "Administration" paragraph to "Local and 456 Global Mobility". Text enhanced. 458 - section 5: 460 R02: replace "between MR and MR's HA" with "a MR and its HA" 462 R11: specified at least 2 levels 464 R12: replaced "support" with "function" and add "multihomed MR" 466 R13.x renumbered to R12.x since part of R12 (editing mistake) 468 R13 and R18: new requirements proposed by editor 470 and minor changes in the formulation of other Requirements 472 A. Acknowledgments 474 The material presented in this document takes most of its text from 475 discussions and previous documents submitted to the NEMO working 476 group. This includes initial contributions from Motorola, INRIA, 477 Ericsson and Nokia. We are particularly grateful to Hesham Soliman 478 (Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who 479 highly helped to set up the NEMO working group. We are also grateful 480 to all the following people whose comments highly contributed to the 481 present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola), 482 Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon 483 Lach (Motorola), Mattias Petterson (Ericsson) and all the others 484 people who have expressed their opinions on the NEMO (formely MONET) 485 mailing list. Thierry Ernst wish to personally grant support to its 486 previous employers, INRIA, and Motorola for their support and 487 direction in bringing this topic up to the IETF, particularly Claude 488 Castelluccia (INRIA) and Hong-Yon Lach (Motorola). 490 B. References 492 [IPv6-NODE] John Loughney 493 "IPv6 Node Requirements" 494 draft-ietf-ipv6-node-requirements.txt 495 Work in progress. 497 [MobileIPv4] Charles Perkins 498 "IP Mobility Support" 499 RFC 2002, IETF, October 1996. 501 [MobileIPv6] David B. Johnson and C. Perkins. 502 "Mobility Support in IPv6" 503 draft-ietf-mobileip-ipv6.txt, 504 Work in progress. 506 [MOBILITY-TERMS] J. Manner 507 "Mobility Related Terminology 508 509 Work in progress. 511 [NEMO-TERMS] Thierry Ernst and Hong-Yon Lach 512 "Terminology for Network Mobility Support", 513 draft-ietf-nemo-terminology.txt 514 Work in progress. 516 [RFC1122] R. Braden (editor). 517 "Requirements for Internet Hosts - Communication 518 Layers". IETF RFC 1122, October 1989. 520 [RFC2119] S. Bradner 521 "Key words for use in RFCs to Indicate Requirement 522 Levels", BCP 14, RFC 2119, IETF, March 1997. 524 [RFC2460] S. Deering and R. Hinden. 525 "Internet Protocol Version 6 (IPv6) Specification" 526 IETF RFC 2460, December 1998. 528 C. Editors's Addresses 530 Questions about this document can be directed to the NEMO working 531 group chairs: 533 Thierry Ernst, 534 Keio University. 535 5322 Endo, Fujisawa-shi, 536 Kanagawa 252-8520, Japan. 537 Phone : +81-466-49-1100 538 Fax : +81-466-49-1395 539 Email : ernst@sfc.wide.ad.jp 541 T. J. Kniveton 542 Communications Systems Lab 543 Nokia Research Center 544 313 Fairchild Drive 545 Mountain View, California 94043, USA 546 Phone : +1 650 625-2025 547 Fax : +1 650 625-2502 548 EMail : Timothy.Kniveton@Nokia.com 550 D. Full Copyright Statement 552 Copyright (C) The Internet Society (2002). All Rights Reserved. 554 This document and translations of it may be copied and furnished to 555 others, and derivative works that comment on or otherwise explain it 556 or assist in its implementation may be prepared, copied, published and 557 distributed, in whole or in part, without restriction of any kind, 558 provided that the above copyright notice and this paragraph are 559 included on all such copies and derivative works. However, this 560 document itself may not be modified in any way, such as by removing 561 the copyright notice or references to the Internet Society or other 562 Internet organizations, except as needed for the purpose of developing 563 Internet standards in which case the procedures for copyrights defined 564 in the Internet Standards process must be followed, or as required to 565 translate it into languages other than English. 567 The limited permissions granted above are perpetual and will not be 568 revoked by the Internet Society or its successors or assigns. 570 This document and the information contained herein is provided on an 571 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 572 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 573 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 574 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 575 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 577 Funding for the RFC editor function is currently provided by the 578 Internet Society.