IETF INTERNET-DRAFT Thierry Ernst WIDE Project / INRIA Hong-Yon Lach Motorola Labs February 2002 "Network Mobility Support Requirements" draft-ernst-monet-requirements-00.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 The purpose of traditional mobility support is to provide continuous Internet connectivity to mobile hosts (host mobility support). In contrast, network mobility support is concerned with situations where an entire network changes its point of attachment to the Internet and thus its reachability in the topology. We shall refer to such a network as a mobile network (MONET). This document tries to identify what constraints limit the implementation and the deployment of a potentially and ideally good solution, and what requirements solutions must comply to. Our main aim is to raise the discussion on the mailing list. Ernst and Lach Expires August 2002 [Page 1] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Contents Status of This Memo Abstract 1. Introduction 2. Important Disclaimer 3. Design Requirements 3.1. Migration Transparency (Permanent Connectivity) 3.2. Operational Transparency 3.3. Performance Transparency (Seamless Mobility) 3.4. Layers Independence 3.5. Mobility Management Transparency for MNNs 3.6. Scalability 3.7. Minimum Signaling Overload 3.8. Routing Optimization in 6 3.9. Nested Mobility 3.10. Backward Compatibility 3.11. Minimum Impact on Existing Protocols and Infrastructure 3.12. No impact on CNs or Internet routing 3.13. Security 3.13.1. Confidentiality 3.13.2. Authentication 3.13.3. Authorization 3.13.4. Location Privacy 3.14. Access Control 3.14.1. Access Control for VMNs 3.14.2. Access Control Architecture 3.14.3. Access Control in the Fixed Network 3.15. Wide-Area Mobility 3.16. Unified Solution 3.17. Mobile CNs 3.18. Addressing Constraints Acknowledgments References Author's Addresses Ernst and Lach Expires August 2002 [Page 2] INTERNET-DRAFT Network Mobility Support Requirements February 2002 1. Introduction This document assumes that the reader is familiar with the terminology defined in [TERMINOLOGY] while reading [SCOPE] for a description of the problems is recommended. The purpose of traditional mobility support is to provide continuous Internet connectivity to mobile hosts (host mobility support). In contrast, network mobility support is concerned with situations where an entire network changes its point of attachment to the Internet and thus its reachability in the topology. We shall refer to such a network as a mobile network (MONET). Cases of mobile networks include networks attached to people (Personal Area Networks or PAN), and networks of sensors deployed in aircrafts, boats, busses, cars, train, etc that need a permanent Internet connection. Those mobile networks may also provide Internet access to devices carried by people (laptop, camera, mobile phone, etc, and PAN). As exhibited by the scenarios depicted in [TERMINOLOGY] and [SCOPE], there is a desire to achieve two levels of mobility: node mobility and network mobility. A passenger is a mobile node which visits a mobile network (VMN in a MONET), and passengers may themselves be mobile IP-subnets (MONET in a MONET), for example when carrying a PAN. Since people move from a MONET to another, and since instances of MONETs like trains, car, aircrafts cross country boundaries, both VMNs and MONETs are also most likely to cross ISP boundaries and therefore to move between topologically distant parts of the Internet. This means we must allow VMNs belonging to potentially different administrative domains to visit the MONET. The instances highlighted above also justify the need to consider potentially large MONETs containing hundreds of hosts and several routers. The train example highlights that the number of correspondent nodes could also be very large, and that these may be sparsely distributed in the Internet. It also justifies the need for true worldwide mobility in the Internet. A MONET may attach to very distant parts of the Internet topology, provided it is granted access to it, therefore requiring both Local-Area Mobility support and Wide-Area Mobility support. The problems that need to be addressed are illustrated in [SCOPE] while the purpose of this document is to raise discussion in order to identify what constraints limit the implementation and the deployment of a potentially and ideally good solution, and what requirements solutions must comply to. Most constraints and requirements that we have listed are equally applicable to host mobility support and network mobility support. Some of them have been debated in the literature as far as host mobility support was concerned; we have extended this list to include those related to network mobility Ernst and Lach Expires August 2002 [Page 3] INTERNET-DRAFT Network Mobility Support Requirements February 2002 support. The material presented in this document is based on [Ernst01] and on our former internet-draft that was submitted in July 2001 [OLD-draft] for the consideration of the Mobile IP Working Group. This former draft was defining the terminology that is now found in [TERMINOLOGY] and a list of requirements and issues as an attempt to clarify the problem caused by networks in motion and now found in this present document. It was also mentioning a number of issues (impact on addressing, routing, and existing network protocols). We have decided to split this former document in two because requirements are more subject to discussion and disagreements that the terminology on which we must agree on to base our discussions. More information may be found on the MONET web page [WEB-MONET]. Note that this list of requirements is primarily targeted to IPv6 [RFC2460], but is not limited to it, and that the already existing network mobility support proposals [MONET-PSBU], [HMIPv6], and [MOBRTR] don't necessarily meet these requirements. 2. Important Disclaimer The stated opinions in this draft come from various sources and are not necessarily the opinions of the authors. The purpose of this draft is for open discussions. 3. Design Requirements This section details what requirements MUST or SHOULD be fulfilled by solutions, and what constraints may limit the deployment of a potentially good solution. Most requirements discussed for host mobility support, like for instance [Bhagwat96], [Myles93], [Castelluccia97] or [Caceres96], are equally applicable to network mobility support. However, they must be extended and refined to comply with the specific characteristics. All requirements we have listed may not be satisfied by a single solution. For the sake of modularity, we may decide to use separate solutions for different aspects of the problem space. Moreover, some of them are controversial and are subject to discussions on the mailing list [WEB-MONET]. It is assumed that the reader has read [TERMINOLOGY]. 3.1. Migration Transparency (Permanent Connectivity) Network mobility support MUST provide permanent and continuous Internet connectivity to all MNNs without disruption of service for MNNs. This means that all MNNs MUST always be reachable regardless of the point of attachment of the MONET. Ernst and Lach Expires August 2002 [Page 4] INTERNET-DRAFT Network Mobility Support Requirements February 2002 3.2. Operational Transparency The network layer MUST be able of supporting connectivity of the MONET in an absolute transparent manner to the application or the user. 3.3. Performance Transparency (Seamless Mobility) Network mobility support SHOULD exhibit low latency, incur little or no data loss, minimum delays, minimum signaling load, and minimum bandwidth consumption for packet delivery. In other words, network mobility support SHOULD be as seamless as host mobility is supported (no abrupt degradation of service). 3.4. Layers Independence Handover of IP sessions is performed at the network layer. With respect to the layer separation of the Internet protocol suite, handover MUST be managed at the network layer only and transparently to upper layers, despite the migration of the MONET in the network topology. Therefore, a change of topological location MUST not have an impact on layers above the network layer other than a transient loss of performance, as depicted in the above paragraph. If this is respected, compatibility with existing transport and application layers is maintained. In practice, the identifiers used at the transport layer should be independent from the physical IP addresses used at the network layer for routing. If upper layer protocols require a location independent and invariant identifier, the network layer MUST provide it with an identifier irrespective of the actual topological location. 3.5. Mobility Management Transparency for MNNs We have seen in [TERMINOLOGY] that MNNs don't change their own point of attachment as a result of the MONET's displacement in the Internet topology. Mobility management of a MONET SHOULD therefore be performed transparently to MNNs, at least to LFNs. LFNs SHOULD (MUST ?) better have no responsibility in network mobility management, whereas LMNs and VMNs SHOULD only be concerned about managing their own mobility if they themselves appear to change their point of attachment. However, MNNs may encounter variable delays of transmission and loss with their respective CNs as the network is moving. [WE WANT TO DISCUSS THIS REQUIREMENT IN THE MAILING LIST] 3.6. Scalability Scalability has always been an important concern in the design of Ernst and Lach Expires August 2002 [Page 5] INTERNET-DRAFT Network Mobility Support Requirements February 2002 new protocols. As far as host mobility is concerned, mobility support has to take into consideration a growing number of mobile hosts and should even assume that a major part of the nodes composing the Internet are mobile in the near future. This means that signaling load and memory consumption should scale to an important number of mobile nodes. However, network mobility support is concerned by scalability differently, and in three ways: o large number of MONETs (e.g. PAN comprising a few devices and carried by every human being). o large MONETs comprising several subnetworks and a large number of MNNs on each subnetwork (e.g. a train) o the number of CNs is somewhat a function of the size of the MONET; the more MNNs a MONET has, the more CNs the MONET is most likely to have. (e.g. each MNN in a train communicating with a few CNs) Network mobility support MUST thus be able to support large MONETs, a very large number of small MONETs, and a large number of CNs. Scaling to a large number of CNs may indeed deserves more consideration than scaling to a large number of MONETs. This has never been considered in host mobility support, to the contrary of the ability to support a large number of mobile nodes. 3.7. Minimum Signaling Overload Mobility management is usually performed at the cost of control traffic. Network mobility support MUST minimize this control traffic, all the more for the reasons outlined in section "scalability". 3.8. Routing Optimization Network mobility support SHOULD optimize routing. Non-optimal routing increases bandwidth consumption and transmission delays. The amount of traffic intended for the MONET is understandably more significant than in the case of a single mobile node (see section "scalability"), then non-optimal routing SHOULD be considered with more care than for host mobility support. However, efficient routing is usually performed at the expense of increased signaling. Thus, the gain of optimal routing MUST be balanced against the incurred signaling cost. 3.9. Nested Mobility Ernst and Lach Expires August 2002 [Page 6] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Network mobility support MUST support nested mobility. It MUST at least allow single VMNs to enter the MONET, single LMNs to leave the MONET, and single mobile IP-subnet attach the MONET (instance of a PAN in a train). Network mobility support must therefore consider both MONETs and mobile nodes, otherwise it may hardly interact with host mobility support. In practice, it should handle VMNs as optimally as if networks were fixed. The working group needs to agree if it MUST support any number of levels or be limited to only two levels. 3.10. Backward Compatibility Network mobility support is constrained by backward compatibility with existing and forthcoming IPv6 standards. As such, it MUST not prevent MNNs to operate any standardized protocol. This particularly includes but is not limited to Mobile IPv6 (host mobility) and IGMP (multicast group membership): o Host Mobility Support Constraints: host mobility support in IPv6 is achieved by Mobile IPv6 which is a compulsory component of any IPv6 implementation. This means that network mobility support MUST not prevent LMNs and VMNs from operating Mobile IPv6 once located in a MONET. o Multicast Constraints: any IPv6 router is supposed to allow hosts on its attached subnetworks to participate in multicast sessions. Group membership is gathered by the IGMP protocol. Network mobility support MUST not prevent this. In both cases, the network mobility support MUST provide the necessary extensions to maintain backward compatibility with existing protocols. 3.11. Minimum Impact on Existing Protocols and Infrastructure Minimum impact on the already deployed infrastructure was an important issue as far as IPv4 was concerned since it was not possible to require all hosts to implement new features. On the other hand, the emergence of IPv6 is an opportunity for making changes, if necessary. An important number of specifications has already been defined, but there is still scope for adding new capabilities if needed since IPv6 deployment is only dawning. However, in order to provide a quickly deployable solution, network mobility support SHOULD better make use of the existing protocols whenever possible and impose minimum changes or extensions on the existing ones. It is also desirable to minimize infrastructure installation costs and complexity. Ernst and Lach Expires August 2002 [Page 7] INTERNET-DRAFT Network Mobility Support Requirements February 2002 3.12. No impact on CN or Internet routing To be able successfully deploy the final solution, session continuity between a MNN and a CN anywhere in the Internet SHOULD NOT assume any changes to existing CNs or the Internet routing architecture. On the other hand, optimizations for performance enhancement MAY involve some changes to CNs, provided that such optimizations would not cause any disruption to ongoing sessions, if not supported by CNs (i.e. backward compatible). [THIS REQUIREMENT IS TO BE DISCUSSED (in light of the observation made in section "Minimum Impact on the Existing Protocols and Infrastructure" here above) BECAUSE IT WOULD PREVENT POTENTIALLY INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED]. 3.13. Security Network mobility support must comply with usual IPv6 security policies and standardized protocols. In addition, and unlike fixed nodes, MNNs are more exposed to security threats, particularly identity usurpation. Network mobility support must provide MNNs and their CNs with at least as good security as for fixed nodes and mobile hosts. It particularly shouldn't leave more room for intruders to usurp an identify nor to perpetrate any kind of attack against the MNNs nor the CNs. In practice, all control messages required by network mobility support must be exchanged in a secure manner and must ensure the following: 3.13.1. Confidentiality All control messages transmitted in the network MUST ensure MNNs' confidentiality. Only the recipient of the control message may be able to decrypt the content of the datagram. 3.13.2. Authentication All control messages MUST be authenticated by recipients in order to prevent intruders to usurp the identity of a MNN. 3.13.3. Authorization The recipient of a control message MUST ensure that the sender is effectively authorized to perform the mobility support operation indicated in the control message. 3.13.4. Location Privacy Network mobility support may provide means for MNNs to hide their location to any third party. It shouldn't be possible to Ernst and Lach Expires August 2002 [Page 8] INTERNET-DRAFT Network Mobility Support Requirements February 2002 determine the succession of topological location of a MONET or a particular MNN by monitoring the exchange of control messages. In practice, MNNs may wish to hide their location to some or all of their CNs, or anyone else but the CNs. It may also be desirable to hide the location of the entire MONET to all CNs without discrimination between MNNs. 3.14. Access Control 3.14.1. Access Control for VMNs Mobile Networks MUST be able to authenticate and authorize VMNs to gain access to the Internet via the mobile network infrastructure (MRs). 3.14.2. Access Control Architecture To be able to comply with the current access control mechanisms and achieve a scalable solution, the final solution MUST NOT assume that the fixed network would authenticate VMNs. VMN authentication and authorization MUST be the responsibility of the mobile network. 3.14.3. Access Control in the Fixed Network AAA solutions MUST allow for authenticating an entire network. This MAY simply be done by ensuring that the Authentication and Authorization is not necessarily performed for a single IP address. This is particularly important for IPv6 as each node may configure multiple addresses. [THIS MAY BE SUGGESTING A SOLUTION BUT WE WANT IT TO BE DISCUSSED ON THE MAILING LIST]. 3.15. Wide-Area Mobility Network mobility support MUST provide means for a MONET to move between heterogeneous networks, i.e. Wide-Area Mobility. This is required in order to ensure permanent and uninterrupted world-wide mobility. Nothing but administrative and security policies should prevent a MONET to attach anywhere in the Internet topology. In practice, a given MONET MUST be able to roam between administratively distinct access networks (between Internet Service Providers and corporate networks) and via any available access technology (802.11b WLAN, Bluetooth, satellite link, GSM, ...). In addition, network mobility support must also accommodate to CNs deployed in distinct administrative domains. 3.16. Unified Solution Ernst and Lach Expires August 2002 [Page 9] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Should different schemes be proposed, a unified mobility support scheme is required. We must avoid a situation where distinct network mobility support schemes are deployed and unable to inter- operate with each other. 3.17. Mobile CNs Network mobility support MUST be optimized to handle the case where the CN is itself a MN (as defined by [MIPv6]) or located in a MONET (particularly if it is a VMN). It must perform efficiently in both cases. 3.18. Addressing Constraints The IP address is used for routing and to identify the subnetwork where an interface is attached to. Each interface on a subnetwork must therefore be configured with the network prefix of that subnetwork. Ernst and Lach Expires August 2002 [Page 10] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Acknowledgments The first author would like to thank both Motorola Labs Paris and INRIA Rhône-Alpes, for the opportunity to bring this topic to the IETF and more particularly Claude Castelluccia (INRIA) for its advices, suggestions, and direction. In addition, we acknowledge Alexandru Petrescu (Motorola), Mattias Petterson (Ericsson), Hesham Soliman (Ericsson) and the NACM people from WIDE (Keio University) for their comments and suggestions on this draft. References [Bhagwat96] Pravin Bhagwat, Satish Tripathi, and Charles Perkins. Network Layer Mobility: an Architecture and Survey. IEEE Personal Communications, 3(3):54, June 1996. [Caceres96] Ramon Caceres and Venkata N. Padmanabhan. "fast and scalable handoffs for wireles internetworks". In Proc. of the Second ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom), Rye, New York, USA, November 1996. Bell Laboratories and University of California at Berkeley. [Castelluccia98] Claude Castelluccia. A Hierarchical Mobility Management Scheme for IPv6. Third Symposium on Computers and Communications (ISCC'98), Athens, Greece, June 1998. http://www.inrialpes.fr/planete [Ernst01] Thierry Ernst "Network Mobility Support in IPv6", PhD Thesis, University Joseph Fourier Grenoble, France. October 2001. [HMIPv6] H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier, "Hierarchical MIPv6 mobility management", draft-ietf-mobileip- hmipv6-05.txt. Work in progress [MIPv6] David B. Johnson and C. Perkins. Mobility Support in IPv6. draft-ietf-mobileip-ipv6-14.txt, July 2001. Work in progress. [MOBRTR] T.J. Kniveton, J. J. Malinen, V. Devarapalli and C. E. Perkins, "Mobile router support in Mobile IP", draft-kniveton- mobrtr-00.txt. Work in progress. [Myles93] Andrew Myles and David Skellern. Comparing Four IP Based Mobile Host Protocols. In Joint- European Networking Conference. Macquarie University, Sydney, Australia, May 1993. [OLD-draft] Thierry Ernst, Hong-Yon Lach, Claude Castelluccia "Network Mobility Support in IPv6: Problem Statement and Requirements", draft-ernst-mobileip-monetv6-00.txt, July 2001. Ernst and Lach Expires August 2002 [Page 11] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Expiration pending. [MONET-PSBU] T. Ernst, L. Bellier, A. Olivereau, C. Castelluccia, H.-Y. Lach, "Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)" draft-ernst-mobileip-v6-network-02.txt, June 2001. Work in progress [RFC1122] R. Braden (editor). Requirements for Internet Hosts - Communication Layers. Request For Comments 1122, Internet Engineering Task Force (IETF), October 1989. [RFC2460] S. Deering and R. Hinden. Internet Protocol Version 6 (IPv6) Specification. Request For Comments 2460, Internet Engineering Task Force (IETF), December 1998. [SCOPE] Hesham Soliman "Problem Scope" IETF internet-draft draft- soliman-monet-scope-00.txt, Work in progress. [TERMINOLOGY] Thierry Ernst "Terminology for Network Mobility Support", draft-ernst-monet-terminology-00.txt, February 2002. Work in progress. [WEB-MONET] MONET web page http://www.nal.motlabs.com/monet Ernst and Lach Expires August 2002 [Page 12] INTERNET-DRAFT Network Mobility Support Requirements February 2002 Author's Addresses Questions about this document can be directed to the authors: Thierry Ernst, WIDE Project Jun Murai lab. Faculty of Environmental Information, Keio University. 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. Phone : +81-466-49-1100 Fax : +81-466-49-1395 E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ Hong-Yon Lach Motorola Labs Paris, Lab Manager, Networking and Applications Lab (NAL) Espace Technologique - Saint Aubin 91193 Gif-sur-Yvette Cedex, France Phone: +33-169-35-25-36 Email: Hong-Yon.Lach@crm.mot.com Ernst and Lach Expires August 2002 [Page 13]