Network Working Group T. Ernst Request for Comments: 4886 INRIA Category: Informational July 2007 Network Mobility Support Goals and Requirements Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractNetwork mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution.
1. Introduction ....................................................2 2. NEMO Working Group Objectives and Methodology ...................3 3. NEMO Support Design Goals .......................................5 3.1. Migration Transparency .....................................5 3.2. Performance Transparency and Seamless Mobility .............5 3.3. Network Mobility Support Transparency ......................5 3.4. Operational Transparency ...................................5 3.5. Arbitrary Configurations ...................................5 3.6. Local Mobility and Global Mobility .........................6 3.7. Scalability ................................................7 3.8. Backward Compatibility .....................................7 3.9. Secure Signaling ...........................................7 3.10. Location Privacy ..........................................8 3.11. IPv4 and NAT Traversal ....................................8 3.12. Minimal Impact on Internet Routing ........................8 4. NEMO Basic Support One-Liner Requirements .......................8 5. Security Considerations ........................................10 6. Acknowledgments ................................................11 7. References .....................................................11 7.1. Normative References ......................................11 7.2. Informative References ....................................11 1] for the related terminology) is concerned with managing the mobility of an entire network, viewed as a single unit that changes its point of attachment to the Internet and thus its reachability in the Internet topology. Such a 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 (LFNs) and mobile (VMNs or LMNs). In most cases, the internal structure of the mobile network will be relatively stable (no dynamic change of the topology), but this is not always true. Cases of mobile networks include, for instance: o 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.
o Networks of sensors and computers deployed in vehicles: vehicles are increasingly equipped with a number of processing units for safety and ease of driving reasons, as advocated by ITS (Intelligent Transportation Systems) applications (). o 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 (see  for the definition of nested mobility). o Ad-hoc networks connected to the Internet via an MR: for instance, students in a train who need to both set up an ad-hoc network among themselves and get Internet connectivity through the MR connecting the train to the Internet. Mobility of networks does not cause MNNs to change their own physical point of attachment; however, they do change their topological location with respect to the global Internet. If network mobility is not explicitly supported by some mechanisms, the mobility of the MR results in MNNs losing Internet access and breaking ongoing sessions between arbitrary correspondent nodes (CNs) in the global Internet and those MNNs located within the mobile network. In addition, the communication path between MNNs and correspondent nodes becomes sub- optimal, and multiple levels of mobility will cause extremely sub- optimal routing. Mobility-related terms used in this document are defined in , whereas terms specifically pertaining to network mobility are defined in . This document is structured as follows: in Section 2, we define the rough objectives and methodology of the NEMO working group to handle network mobility issues and we emphasize the stepwise approach the working group has decided to follow. A number of desirable design goals are listed in Section 3. Those design goals then serve as guidelines to define the requirements listed in Section 4 for basic network mobility support .
in Mobile IPv6  are unable to support network mobility. The NEMO working group has therefore been set up to deal with issues specific to network mobility. The primary objective of the NEMO work is to specify a solution that allows mobile network nodes (MNNs) to remain connected to the Internet and continuously reachable while the mobile router serving the mobile network changes its point of attachment. The secondary goal of the work is to investigate the effects of network mobility on various aspects of Internet communication such as routing protocol changes, implications of real-time traffic and fast handovers, and optimizations. This should support the primary goal of reachability for mobile network nodes. Security is an important consideration too, and efforts should be made to use existing security solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges. To complete these tasks, the NEMO working group has decided to take a stepwise approach. The steps in this approach include standardizing a basic solution to preserve session continuity (NEMO Basic Support, see ) and studying the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (NEMO Extended Support, see  and  for a discussion on routing optimization issues and  for a discussion on multihoming issues). However, the working group is not chartered to actually standardize a solution for Extended Support at this point in time. If deemed necessary, the working group will be rechartered based on the conclusions of the discussions. For NEMO Basic Support, the working group assumes that none of the nodes behind the MR is 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 accommodates 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 has adopted the methods for host mobility support used in Mobile IP and has extended them in the simplest way possible to achieve its goals. The Basic Support solution, now defined in  following the requirements stated in Section 4 of the present document, is for each MR to have a Home Agent (HA), and use bi- directional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR acquires a Care-of Address (CoA) at its attachment point much like what is done for mobile hosts
(MHs), using Mobile IP. This approach allows nested mobile networks, since each MR will appear to its attachment point as a single node. Section 4; NEMO Extended Support is not yet considered at the time of this writing.
network is multihomed 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 ones 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 Nodes that change their point of attachment within the mobile network. o Foreign mobile nodes that attach to the mobile network. o Multihomed mobile network: either when a single MR has multiple attachments to the internet, or when the mobile network is attached to the Internet by means of multiple MRs (see definition in  and the analysis in ). o Nested mobile networks (mobile networks attaching to other mobile networks (see definition in ). Although the complexity requirements of these nested networks are not clear, it is desirable to support arbitrary levels of recursive networks. The solution should only impose restrictions on nesting (e.g., path MTU) when this is impractical and protocol concerns preclude such support. o Distinct mobility frequencies (see mobility factor in ). o Distinct access media. 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.
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.
addresses, as well as maintain ongoing sessions as the MR changes its point of attachment to the Internet topology. This is to be done by maintaining a bi-directional tunnel between an MR and its Home Agent. The NEMO Working Group, after some investigation of alternatives, has decided to reuse and extend the existing Mobile IPv6  mechanisms for tunnel management. The list of requirements below has been imposed on the NEMO Basic Support solution. The requirements have mostly been met by the resulting specification, which can now be found in . Associated deployment issues are discussed in . R01: The solution must be implemented at the IP layer level. R02: The solution must set up a bi-directional tunnel between a mobile router and its Home Agent (MRHA tunnel). R03: All traffic exchanged between an MNN and a CN in the global Internet must transit through the bi-directional MRHA 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 MRs. 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 ensure backward compatibility with other standards defined by the IETF. In particular, this includes the following: 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 ).
R10: The solution must be agnostic to the internal configuration. This means the solution will behave the same way if NEMO is nested, comprises one or several subnets, or comprises MNNs that are LFNs, VMNs, LFNs or a mixture of them. R11: The solution must support at least 2 levels of nested mobile networks, while, in principle, arbitrary levels of recursive mobile networks should be supported. R12: The solution must function for multihomed MRs and multihomed mobile networks as defined in . R13: NEMO support signaling over the bi-directional must be minimized. 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 may be encrypted. R15: The solution must ensure transparent continuation of routing and management operations over the bi-directional tunnel (this includes, e.g., unicast and multicast routing protocols, router renumbering, Dynamic Host Configuration Protocol (DHCPv6)). R16: When one egress interface fails, the solution may preserve sessions established through another egress interface. R17: The solution should have a minimal impact on the global Internet routing system. RFC3963]. Section 3.9 of this document discusses the security goals for all forms of existing and forthcoming NEMO solutions.
 Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.  "CALM - Medium and Long Range, High Speed, Air Interfaces parameters and protocols for broadcast, point to point, vehicle to vehicle, and vehicle to point communication in the ITS sector - Networking Protocol - Complementary Element", ISO Draft ISO/WD 21210, February 2005.  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
 Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007.  Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", Work in Progress), February 2007.  Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility (NEMO) Home Network Models", RFC 4887, July 2007. http://www-rocq.inria.fr/imara
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.