NEMO Working Group Thierry Ernst, Editor Internet-Draft
INRIA andWIDE February,and INRIA May, 2003 "Network Mobility Support Goals and Requirements" <draft-ietf-nemo-requirements-00.txt><draft-ietf-nemo-requirements-01.txt> Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Network mobility arises when a router connecting an entire network to the Internet dynamically changes its point of attachment to the Internet and thus itstherefrom causing the reachability of the entire network to be changed in the topology. The mobileSuch kind of network is viewedreferred to as a unitmobile network. Without appropriate mechanisms, sessions established between nodes in the mobile network and is connected tothe global Internet by one or morecannot be maintained while the mobile routers. In contrast with host mobilityrouter changes its point of attachment. The required support which aims at providing continuous Internet connectivitymechanisms will be provided in two phases. The first phase, referred to mobile hosts only, network mobility supportas NEMO Basic Support is to provide continuous Internet sessions not only to the mobile router connecting the mobile network tosession continuity while the global Internet, but alsonecessary optimizations mechanims referred to nodes behind the mobile router. The purpose of thisas NEMO Extended Support might be provided later. This document is to listoutlines the goals expected from network mobility support and defines the requirements that must be met by network mobility support solutions in IPv6.NEMO Basic Support solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04 3. Network MobilityNEMO Working Group Goals and Methodology . . . . . . . . . . .04 4. General Purpose Guidelines for the SolutionsNEMO Support Design Goals . . . . . . . . . . . . . . . . . 05 5. NEMO Basic Support One-liner Requirements for Basic NEMO Support.. . . . . . . . . 09 6. Changes From Previous Version . . . . . . . . . . . . . . . 11 A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11 B. References . . . . . . . . . . . . . . . . . . . . . . . . . 1112 C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 1213 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction Network mobility support is concerned with managing the mobility of an entire network, viewed as a single unit, which changes its point of attachment to the Internet and thus its reachability in the Internet topology. Such kind of network is referred to as a mobile network and includes one or more mobile routers (MRs) which connect it to the global Internet. Nodes behind the MR(s) (MNNs) are both fixed (keeping the same address on the mobile network at all times), and mobile (entering(LFNs) and leaving themobile network as they roam with respect to it).(VMNs or LMNs). In most cases, the internal structure of the mobile network will in effect be relatively stable (no dynamic change of the topology), but this is not a general assumption. Cases of mobile networks include for instance: - networks attached to people (Personal Area Networks or PANs): a cell-phone with one cellular interface and one Bluetooth interface together with a Bluetooth-enabled PDA constitute a very simple instance of a mobile network. The cell-phone is the mobile router while the PDA is used for web browsing or runs a personal web server. - networks of sensors and computers deployed in vehicles: vehicles are more and more embedded with a number of processing units for safety and ease of driving reasons, as advocated by ITS (Intelligent Transportation Systems) applications. - access networks deployed in public transportation (buses, trains, taxis, aircrafts): they provide Internet access to IP devices carried by passengers (laptop, camera, mobile phone: host mobility within network mobility or PANs: network mobility within network mobility, i.e. nested mobility). - ad-hoc networks connected to the Internet via a MR: for instance students in a train that both need to set up an ad-hoc network among themselves and to get Internet connectivity through the MR connecting the train to the Internet. Traditional work conducted so far on mobility support wasMobility of networks does not cause MNNs to provide continuous Internet connectivitychange their own physical point of attachment, however they happen to mobile hosts only (host mobility support). In contrastchange their topological location with host mobility support,respect to the global Internet. If network mobility supportis to provide continuous Internet sessionsnot only to the mobile router connecting the mobile network to the global Internet, but also to nodes behindexplicitly supported by some mechanisms, the mobile router. Mobility of networks does not cause MNNs to change their own physical pointmobility of attachment, however they happen to change their topological location with respect tothe global Internet whichMR results in lack ofinto MNNs losing Internet access and brokenbreaking ongoing sessions if no supporting mechanisms are deployed.entertained between arbitrary correspondent node (CNs) in the global Internet and those MNNs located within the mobile network. In addition, the communication path between a MNNMNNs and anarbitrary Correspondent Nodecorrespondent nodes (CN) may result inbecomes sub-optimal, whereas multiple levels of mobility will cause extremely suboptimal paths, particularly when mobile networks are nested or when the CN is itself mobile.sub-optimal routing. The mechanisms required for handling such mobility issues are currently lacking within the IETF standards. Traditional work conducted on mobility support (particularly in the Mobile IP working group) is to provide continuous Internet connectivity and optimal routing to mobile hosts only (host mobility support) and are unable to support network mobility. The NEMO working group has therefore been set up to deal with those.issues specific to network mobility. The purpose of this document is thus to detail the methodology that will be followed by the NEMO working groupgroup, its goals, and to listdefine requirements for network mobility support. This document is structured as follows: first, section 2 introduces the terminology for network mobility. Inin section 3, we define the goals and methodology of the NEMO working group and we emphasize the stepwise approach the working group has decided to follow. A number of guidelinesdesirable design goals are listed in section 4 and are used in section 54. Those design goals serve as guidelines to edict the requirements for basic network mobility support. 2. Terminology TermsMobility-related terms used in this document are taken from [MIPv6] and [MOBILITY- TERMS]. Additionaldefined in [MOBILITY-TERMS] whereas terms pertaining to network mobility specifically are defined in [NEMO-TERMS]. [NOTE FROM THE EDITOR: parts from draft [NEMO-TERMS] will probably be moved to [MOBILITY-TERMS] whereas the remaining terms would then be pasted in this present document. THIS IS TO BE DISCUSSED]3. Network MobilityNEMO Working Group Goals and Methodology The primary goal of the NEMO work is to specify a solution which allows mobile network nodes (MNNs) to remain connected to the Internet and continuously reachable at all times while the mobile network they are attached to changes its point of attachment. Secondary goals of the work is to investigate the effects of network mobility on various aspects of internet communication such as routing protocol changes, implications of realtime traffic and fast handovers, optimizations. These should all support the primary goal of reachability for mobile network nodes. Security is an important consideration too, and efforts should be made to use existing solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges. For doing so, the NEMO working group has decided to take a stepwise approach by standardizing a basic solution to preserve session continuity (basic network mobility support),(NEMO Basic Support), and at the same time study the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (extended network mobility support).(NEMO Extended Support). However, the working group is not chartered to actually standardize a solution to such route optimization at this point in time. For basicNEMO support,Basic Support, the working group will assume that none of the nodes behind the MR will be aware of the network's mobility, thus the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption will be made to accommodate nodes inside the network that are not generally aware of mobility. The efforts of the Mobile IP working group have resulted in the Mobile IPv4 and Mobile IPv6 protocols, which have already solved the issue of host mobility support. Since challenges to enabling mobile networks are vastly reduced by this work, basic network mobility support will adopt the methods for host mobility support used in Mobile IP, and extend them in the simplest way possible to achieve its goals. The basic support solution is for each MR to have a Home Agent, and use bidirectional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR will acquire a Care-of-address from its attachment point much like what is done for mobile nodes (MN) using Mobile IP. This approach allows nested mobile networks, since each MR will appear to its attachment point as a single node. 4. General Purpose Guidelines for the SolutionsNEMO Suppport Design Goals This section lists a number of guidelines which are useddetails the fundamental design goals the solutions will tend to achieve. Those design goals will serve to edict and understand the requirements that MUST or SHOULD be met bydefined for forthcoming network mobility support solutions,solutions. Actual requirements for both basicNEMO support and extendedBasic Support are in the next section, whereas NEMO support.Extended Support has not yet been considered. - Migration Transparency: a permanent connectivity to the Internet MUSThas to be provided to all MNNs while continuous sessions MUSTare expected to be maintained as the mobile router changes its point of attachment. For doing so, MNNs willare expected to be reachable via their permanent IP addresses. - Performance Transparency (Seamless Mobility):and Seamless Mobility: NEMO support SHOULD provideis expected to be provided with limited signaling overhead and ideally SHOULDto minimize the impact of handover onover applications, in terms of packet loss or delay. VariableHowever, although variable delays of transmission and losses between MNNs and their respective CNs could be perceived as the network is moving aredisplaced, it would not be considered a lack of performance transparency. - Network Mobility Support Transparency: MNNs behind the MR(s) don't change their own physical point of attachment as a result of the mobile network's displacement in the Internet topology. Consequently, NEMO support is betterexpected to be performed by the sole MR(s) and specific support functions on any other nodesnode than the MR(s) SHOULDwould better be avoided. - Operational Transparency: NEMO support MUSTis to be implemented at the IP layer level. It MUSTis expected to be transparent to anyupper layerlayers so that any upper layer protocol can run unchanged on top of an IP layer extended with NEMO support. - Arbitrary Configurations: The formation of a mobile network can exist in various levels of complexity. In the simplest case, a mobile network contains just a mobile router and a host. In the most complicated case, a mobile network is multi-homed and is itself a multi-level aggregation of mobile networks with collectively thousands of mobile routers and hosts. While the list of potential configurations of mobile networks cannot be limited, at least the following configurations are desirable: o mobile networks of any size, ranging from a sole subnet with a few IP devices to a collection of subnets with a large number of IP devices, o multi-homednodes that change their point of attachment within the mobile network (see definition in [NEMO-TERMS].network, o foreign mobile nodes that attach to the mobile network.network, o nodes that change their point of attachment withinmulti-homed mobile network either when a single MR has multiple attachments to the internet, or when the mobile network.network is attached to the Internet by means of multiple MRs (see definition in [NEMO-TERMS]), o nested mobile networks (see(mobile networks attaching to other mobile networks, see definition in [NEMO-TERMS]. o mobileAlthough the complexity requirements of those nested networks displaced within a domain boundary (local mobility) or between domain boundaries (global mobility).is not clear, it is desirable to support arbitrary levels of recursive networks, and only in the case where this is impractical and protocol concerns preclude this support should the solution impose restrictions on nesting (e.g. path MTU), o distinct mobility frequencies.frequencies, o distinct access medium. In order to keep complexity minimal, transit networks are excluded from this list. A transit network is one in which data would be forwarded between two endpoints outside of the network, so that the network itself simply serves as a transitional conduit for packet forwarding. A stub network (leaf network), on the other hand, does not serve as a data forwarding path. Data on a stub network is either sent by or addressed to a node located within that network. - Administration: the solution MUST not preventLocal Mobility and Global Mobility: mobile networks and mobile nodes owned by administratively different entities are expected to attachbe displaced within a domain boundary or between domain boundaries. Multihoming, vertical and horizontal handoffs, and access control mechanisms are desirable to any part of the Internet topologyachieve this goal. Such mobility type is not expected to be limited for any consideration other considerationsthan administrative and security policies (both global mobility and local-mobility are desirable).policies. - Scalability: NEMO support signaling and processing MUSTis expected to scale to a potentially large number of mobile networks irrespective of their configuration, mobility frequency, size and number of CNs. - Backward Compatibility: NEMO support MUST be ablewill have to co-exist and not interferewith existing IPv6 standards. The solution MUST reusestandards without interfering with them. Standards defined in other IETF working groups have to be reused as much as possible and MAYextended only extend themif deemed necessary. For instance, the following mechanisms defined by other working groups MUST still function:are expected to function without modidications: o Address allocation and configuration mechanism.mechanisms o Host mobility support: the solution MUST not preventmobile nodes and correspondent nodes, either located within or outside the mobile network,network are expected to keep operating protocols defined by the Mobile IP working group. This include mechanisms for host mobility support (Mobile IPv6) and seamless mobility (FMIPv6). o Multicast support: the solution MUST maintain ongoing multicast sessions ofsupport entertained by MNNs asare expected to be maintained while the mobile router changes its point of attachment. Group membership is currently gathered by MLD.o Access control protocols and mechanisms: NEMO support MUST not disallow protocols andmechanisms used by visiting mobile hosts and routers to be authenticated and authorized to gain access to the Internet via the mobile network infrastructure (MRs). o Security protocols and mechanisms o Routing protocols and mechanisms:Mechanisms performed by routers deployed both in mobile networks may be routers likethe othersvisited networks and therefrom are expected to runin some situations a number of protocols such as a routing protocol,mobile networks (routing protocols, Neighbor Discovery, ICMP, Router Renumbering and others. NEMO support MUST thus not prevent usual routing protocols and mechanisms to keep working within the mobile network and to interact with the global Internet (home network only in the case of basic NEMO support) when necessary. o Seamless Mobility: the solutions MUST be compatible with FMIPv6Renumbering, ...). - Security:Secure Signaling: NEMO support MUSTwill have to comply with usual IETF security policies and recommendations and MUSTis expected to have its specific security issues fully addressed. In practice, all NEMO support control messages transmitted in the network MUSTwill have to ensure an acceptable level of security to prevent intruders to usurp identities.identities and forge data. Specifically, the following issues have to be addressed:considered: o Authentication of the sender to prevent identity usurpation. o Authorization, to make sure the sender is granted permission to perform the operation as indicated in the control message. o Confidentiality of the data contained in the control message. o- Location Privacy: means to hide the actual location of MNNS to third parties other than the HA if desired. 5. One-liner Requirementsthird parties other than the HA are desired. In which extend this has to be enforced is not clear since it is always possible to determine the topological location by analysing IPv6 headers. It would thus require some kind of encryption of the IPv6 header to prevent third parties to monitor IPv6 addresses between the MR and the HA. On the other hand, it is at the very least desirable to provide means for MNNs to hide their real topological location to their CNs. - IPv4 and NAT traversal: IPv4 clouds and NAT are likely to co- exist with IPv6 for a long time, so it is desirable to ensure mechanisms developped for BasicNEMO will be able to traverse such clouds. 5. NEMO Basic Support One-liner Requirements The NEMO WG will specify a unified and unique solution for "Basic Network Mobility Support". The solution will allow all nodes in the mobile network to be reachable via permanent IP addresses, as well as maintain ongoing sessions as the MR changes its point of attachment to the Internet topology. This will be done by maintaining a bidirectional tunnel between thea MR and its Home Agent. The Working Group will investigate reusing the existing Mobile IPv6 mechanisms for the tunnel management, or extend it if deemed necessary. The following requirements are placed on the BasicNEMO supportBasic Support solution, hereafter referred to as "the solution": R01: The solution MUST be implemented at the IP layer level. R02: The solution MUST set up a bi-directional tunnel between a MR and MR'sits Home Agent. R03: All traffic exchanged between a MNN and a CN in the global Internet MUST transit through the bidirectional tunnel. R04: MNNs MUST be reachable at a permanent IP address and name. R05: The solution MUST maintain continuous sessions (both unicast and multicast) between MNNs and arbitrary CNs after IP handover of (one of) the MR. R06: The solution MUST not require modifications to any node other than MRs and HAs. R07: The solution MUST support fixed nodes, mobile hosts and mobile routers in the mobile network. R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile network link as either a home link or a foreign link. R09: The solution MUST not prevent the proper operation of Mobile IPv6 (i.e. the solution MUST support MIPv6-enabled MNNs and MUST alsoallow MIPv6-enabled MNNs to receive and process Binding Updates from arbitrary Mobile Nodes.)operate either the CN, HA, or MN operations defined in [MIPv6]) [SHOULD BE MOVED UNDER R17] R10: The solution MUST treat all the potential configurations the same way (whatever the number of subnets, MNNs, nested levels of MRs, egress interfaces, ...) R11: The solution MUST support mobile networks attaching to other mobile networks (nested mobile networks). Although it is not fully clear how many layers of topology MUST be supported, or the complexity requirementsat least 2 levels of thosenested mobile networks, the goal is to supportwhile, in principle, arbitrary levels of recursive networks, and only in the case where this is impractical and protocol concerns preclude this support should the solution impose restrictions on nesting (e.g. path MTU).mobile networks SHOULD be supported. R12: The solution MUST function for multi-homedmultihomed MR and multihomed mobile networks. More precisely: R13.1:networks as defined in [NEMO-TERMS]). Particularly: R12.1: The solution MUST supportfunction for multi-MR mobile networks with multiple MRs, R13.2:R12.2: The solution MUST support MR with multiple interfaces, R13.3:function for multi-egress interfaces R12.3: The solution must supportMUST function for MR with multiple global addresses on an egress interface. [I PROPOSE TO REMOVE R12.1, 2 and 3 BECAUSE THIS IS CONTAINED IN THE DEFINITION IN [NEMO-TERMS]]. R13: NEMO Support signaling over the bidirectional MUST be minimized [NEW REQUIREMENT PROPOSED BY EDITOR] R14: Signaling messages between the HA and the MR MUST be secured: R14.1: The receiver MUST be able to authenticate the sender R14.2: The function performed by the sender MUST be authorized for the content carried R14.3: Anti-replay MUST be provided R14.4: The signaling messages SHOULD be encrypted [ACCORDING TO DISCUSSION AT IETF56, SHALL BE REMOVED or SOFTENED TO "MAY" (?)] R15: The solution MUST ensure transparent continuation of routing and management operations over the bi-directional tunnel when the MR is away from home. (this includes e.g. routing protocols, router renumbering, DHCPv6, etc) R16: The solution MUST not impact on the routing fabric neither on the Internet addressing architecturearchitecture. [ACCORDING TO IETF56 minutes, SHOULD BE REMOVED] R17: The solution MUST ensure backward compatibility with other standards defined by the IETF.IETF [SPECIFIC PROTOCOLS SHOULD BE EXPLICITLY LISTED: MLD, ... etc. PLEASE CONTRIBUTE THE NAMES OF PROTOCOLS TO BE INCLUDED ON THE MAILING LIST. MAYBE MIPV6 COULD BE INCLUDED HERE INSTEAD OF R09.] Particularly: R18: The solution SHOULD preserve sessions established through another egress interface when one fails [PROPOSED BY EDITOR OF THIS DOCUMENT AT THE IETF56 MEETING. TO BE DISCUSSED ON THE MAILING LIST] 6. Changes since last version - title of documents: included the word "goals" - entire document: some rewording - section 4: changed title of section to "NEMO Design Goals". - section 4: removed "MUST" and "MAY" - section 4: more text about location privacy - section 4: changed "Administration" paragraph to "Local and Global Mobility". Text enhanced. - section 5: R02: replace "between MR and MR's HA" with "a MR and its HA" R11: specified at least 2 levels R12: replaced "support" with "function" and add "multihomed MR" R13.x renumbered to R12.x since part of R12 (editing mistake) R13 and R18: new requirements proposed by editor and minor changes in the formulation of other Requirements A. Acknowledgments The material presented in this document takes most of its text from discussions and previous documents submitted to the NEMO working group. This includes initial contributions from Motorola, INRIA, Ericsson and Nokia. We are particularly grateful to Hesham Soliman (Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who highly helped to set up the NEMO working group. We are also grateful to all the following people whose comments highly contributed to the present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and all the others people who have expressed their opinions on the NEMO (formely MONET) mailing list. Thierry Ernst wish to personally grant support to its previous employers, INRIA, and Motorola for their support and direction in bringing this topic up to the IETF, particularly Claude Castelluccia (INRIA) and Hong-Yon Lach (Motorola). B. References [IPv6-NODE] John Loughney "IPv6 Node Requirements" draft-ietf-ipv6-node-requirements-01.txt July 2002,draft-ietf-ipv6-node-requirements.txt Work in progress. [MIPv6][MobileIPv4] Charles Perkins "IP Mobility Support" RFC 2002, IETF, October 1996. [MobileIPv6] David B. Johnson and C. Perkins. "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-20.txt, January 2002.draft-ietf-mobileip-ipv6.txt, Work in progress. [MOBILITY-TERMS] J. Manner "Mobility Related Terminology <draft-ietf-seamoby-mobility-terminology-00.txt> August 2002.<draft-ietf-seamoby-mobility-terminology.txt> Work in progressprogress. [NEMO-TERMS] Thierry Ernst and Hong-Yon Lach "Terminology for Network Mobility Support", draft-ernst-nemo-terminology.txt.draft-ietf-nemo-terminology.txt Work in progress. [RFC1122] R. Braden (editor). "Requirements for Internet Hosts - Communication Layers". IETF RFC 1122, October 1989. [RFC2119] S. Bradner "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, IETF, March 1997. [RFC2460] S. Deering and R. Hinden. "Internet Protocol Version 6 (IPv6) Specification" IETF RFC 2460, December 1998. C. Editors's Addresses Questions about this document can be directed to the NEMO working group chairs: Thierry Ernst, Keio University. 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. Phone : +81-466-49-1100 Fax : +81-466-49-1395 Email : firstname.lastname@example.org T. J. Kniveton Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043, USA Phone : +1 650 625-2025 Fax : +1 650 625-2502 EMail : Timothy.Kniveton@Nokia.com D. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society.