INTERNET-DRAFT Thierry Ernst Hong-Yon Lach Claude Castelluccia Motorola Labs and INRIA Planete, France 13 July 2001 "Network Mobility Support in IPv6: Problem Statement and Requirements" draft-ernst-mobileip-monetv6-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 This draft addresses the problems of routing datagrams to nodes located in an IPv6 mobile network. A mobile network is one or more IP-subnets attached to a mobile router and mobile as a unit. The mobile router dynamically changes its point of attachment. Applications of mobile networks include networks attached to people (PANs) and networks of sensors deployed in an aircraft, a boat, or a car. This draft defines a terminology and presents a number of specific issues faced by mobility of an entire network. An explicit mobility support scheme is required, what we call "network mobility support" in contrast with "host mobility support". We have listed a number of requirements that need to be addressed by network mobility support. Ernst & Lach Expires 13 January 2001 [Page 1] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 Contents Status of This Memo Abstract Introduction 1. Definitions and Problem Statement 1.1. Motivations 1.2. Terminology 1.3. Characteristics 1.4. Aim of Network Mobility Support 1.5. Assumption 1.6. Issues 1.6.1. Routing Issues 1.6.2. Addressing Issues 1.6.3. Network Protocols Issues 1.6.4. Security Issues 2. Constraints and Requirements 2.1. Constraints 2.1.1. Host Mobility Support Constraints 2.1.2. Addressing Constraints 2.1.3. IPv6 Constraints 2.1.4. Security Constraints 2.2. Requirements 2.2.2. Wide-Area Mobility Support 2.2.3. Security 2.2.4. Transparency 2.2.5. Optimal Routing 2.2.6. Minimum Signalling Overload 2.2.7. Scalability 2.2.8. Nested Mobility 2.2.9. Backward Compatibility 2.2.10. Minimum Impact on Existing Protocols References Author's Addresses Ernst & Lach Expires 13 January 2001 [Page 2] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 Introduction This document addresses the question of routing datagrams to nodes located in an IPv6 mobile network, i.e. network mobility support. We define a mobile network as an entire network that dynamically changes its point of attachment in the Internet and thus its reachability in the Internet. The first section gives the motivations for network mobility support. We then describe mobile networks and we define a new terminology used throughout this study (section 1.2). There may exist various kind of mobile networks and they obviously have specific characteristics as depicted in section 1.3. Section 1.4 explains what this study tries to achieve. Section 1.6 concludes this section with a number of issues faced by network mobility support. Network mobility support in wide-area IPv6 networks has to comply with a number of constraints and requirements. Constraints limit the implementation and the deployment of a potentially and ideally good solution, and solutions need to fulfill a number of requirements. Some requirements must be solved whereas other should be solved whenever possible. Constraints and requirements for network mobility support are discussed in the second section. 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 mobile networks. 1. Definitions and Problem Statement 1.1. Motivations The purpose of traditional mobility support is to provide continuous Internet connectivity to mobile hosts (host mobility support). There are situations where an entire network might move and attach to different locations in the Internet topology. In this paper, we refer to a network as a set of nodes that share the same IP prefix and that are attached to the Internet through a border router. We refer to a mobile network as a network whose border router is a mobile router which dynamically changes its point of attachment to the Internet and thus its reachability in the Internet. Cases of mobile networks include networks attached to people (Personal Area Network or PAN) and networks deployed in aircrafts, boats, cars, trains, etc. An Ad-hoc network as defined in manet is not to be confused with a mobile network; however it may become a mobile network when its border router changes its point of attachment Ernst & Lach Expires 13 January 2001 [Page 3] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 to the Internet. As an example of a mobile network, we could think of an airline company that provides permanent on-board Internet connectivity. This allows all passengers to use their laptops to connect to remote hosts, download music or video from any provider, or browse the web. The Internet could also be used to exchange information between the aircraft and air traffic control stations. This scenario has already been investigated by Eurocontrol (European Organization for the Safety of Air Navigation [8]). During the flight, the aircraft changes its point of attachment to the Internet and is reachable by different care-of addresses over time, most likely owned by distinct Internet service providers. This scenario justifies that mobile networks may be of a big size, containing hundreds of hosts and several routers and may attach to very distant parts of the Internet topology. Moreover, it shows that we face two distinct levels of mobility, node mobility and network mobility, since laptops owned by passengers are themselves mobile nodes visiting the aircraft mobile network. However, this paper does not address the specific issues involved when mobile nodes visit the mobile network. We are focusing on the general case. 1.2. Terminology We mostly adopt the terminology already defined in the IPv6 [5] and Mobile IPv6 [6] specifications. We also introduce the following new terms relevant to mobile networks. A mobile network attaches to the rest of the Internet through its border routers which we refer to as the mobile routers (MRs). A mobile router has at least two interfaces, the first attached to the home link or the foreign link, and the other attached to an internal link of the mobile network. We call mobile network node (MNN) any host or router located within the mobile network, either permanently or temporarily. All MNNs located in the same mobile network share a common and permanent IP prefix that we call the Mobile Network Prefix. The Mobile Network Prefix is a bit string that consists of some number of initial bits which identifies the set of subnetworks that compose the mobile network. It also identifies the topological location of the mobile network when the mobile router is attached to its home link. In addition, we call correspondent node (CN) any node external to the mobile network that is communicating with one or more MNNs. The terminology is summarized in fig.1. Mobile Network A set of nodes which are mobile, as a unit, with respect to the rest of the Internet, i.e. a mobile router and all its attached nodes. The mobile router changes dynamically its point of attachment to the Internet and thus its reachability in the Internet. All nodes in the mobile network share the same IP Ernst & Lach Expires 13 January 2001 [Page 4] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 prefix: the Mobile Network Prefix. Note that a mobile network may be composed by one or more IP-subnets. ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ | | Access | | | AR | Router | AR | |____| |____| ______|__ foreign __|_____________ home link __|_ link | | | MR | Mobile Router |____| _________|_______ internal __|__ __|__ link | | | | | LFN | | LFN | Local Fixed Nodes |_____| |_____| Figure 1: Terminology Mobile IP-subnet A mobile network that is composed of a single IP-subnet. Mobile Router (MR) The border router of a mobile network which attaches the mobile network to the rest of the Internet. The mobile router has at least two interfaces, an external interface, and an internal interface. The mobile router maintains the Internet connectivity for the mobile network. It is used as a gateway to route packets between the mobile network and the fixed Internet. External Interface of a Mobile Router The external interface of a mobile router is attached to the home link if the mobile network is at home, or is attached to a foreign link if the mobile network is in a foreign network. Ernst & Lach Expires 13 January 2001 [Page 5] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 Internal Interface of a Mobile Router The internal interface of a mobile router is attached to an internal link within the mobile network. This interface is configured with the Mobile Network Prefix (see definition below) for all the MNNs inside the mobile network. Local Fixed Node (LFN) Any host or router permanently located within the mobile network and that does not change its point of attachment. Local Mobile Node (LMN) A mobile node that belongs to the mobile network and that changes it's point of attachment. The home link of the LMN is a link within the mobile network. The LMN may attach to any link within the mobile network, or to any link outside the mobile network. Visiting Mobile Node (VMN) A mobile node that does not belong to the mobile network and that changes it's point of attachment. The home link of the VMN is not a link within the mobile network. A VMN may attach to a link within the mobile network and obtain a careof address on this link. Mobile Network Node (MNN) Any host or router located within the mobile network, either permanently or temporarily. A MNN could be any of a MR, LFN, VMN, or LMN. Node behind the MR A synonym for a mobile network node (MNN). See corresponding definition. Correspondent Node (CN) Any node located outside the mobile network that corresponds with any of the MNNs. By extension, we say that CNs corresponding with MNNs of a mobile network are CNs of this mobile network. Access Router Any subsequent point of attachment of the mobile network at the network layer. Basically, a router on the home link or the foreign Ernst & Lach Expires 13 January 2001 [Page 6] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 link. Home subnet prefix A bit string that consists of some number of initial bits of an IP address which identifies the home link within the Internet topology. (i.e. the IP subnet prefix corresponding to the mobile node's home address, as defined in [6]). Foreign subnet prefix A bit string that consists of some number of initial bits of an IP address which identifies a foreign link within the Internet topology. Mobile Network Prefix The network prefix that is common to all IP addresses in the mobile network when the mobile router is attached to the home link. For a mobile network containing only one subnet, the Mobile Network Prefix is the prefix of this subnet ("home subnet prefix" as defined in [6]). Note that the Mobile Network Prefix may not be the home prefix. 1.3. Characteristics Structure of the mobile network The internal structure of a mobile network is preserved while it is moving. As a result of the mobility of the mobile network, MNNs do not change their point of attachment; however, MNNs move from the point of view of their CNs. From a routing perspective, a mobile network may therefore be virtually perceived as a single node (the MR) with a topologically correct address or prefix. The topological location of a MNN being dependent of the location of the MR, the knowledge of the topological location of the MR is sufficient for routing datagrams from a CN towards a MNN. Mobile Router is a transit point All packets sent from any CN to a MNN necessarily transit through the MR. As a result, providing the CN with the current location of the MR in the Internet topology may be sufficient for optimally routing packets intended to a MNN. Size of the mobile network A mobile network may comprise one or more subnetworks. Its size Ernst & Lach Expires 13 January 2001 [Page 7] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 could scale from a sole subnetwork with a few IP devices, such as in the case of a PAN, to a collection of subnets with hundreds of IP devices, such as in a train. Large number of CNs A mobile network may have a very large number of CNs. For instance, each passenger in a train may be considered a MNN. Each of them may be communicating with a few CNs. As a result, the total number of CNs would be several times as large as the number of MNNs and could scale up to a few thousands. Nested mobility A mobile network may comprise mobile nodes (local mobile nodes or visiting mobile nodes) and even other mobile networks. For instance, a bus is a mobile network whereas passengers are mobile nodes or even mobile networks themselves if they carry a PAN. Various mobility frequencies Mobile networks may not move with the same speed and frequency. For instance, a PAN connected to the Internet via a WLAN, or a car connected to the Internet via GSM are likely to change their point of attachment very quickly, while an aircraft or a boat may be connected to the Internet via the same satellite link for a couple of hours. Obviously, mobile networks may not move at all for a large amount of time. Multi-homing A mobile network may be multi-homed. By multi-homing, we mean that the MR may have two or more active interfaces connected to distinct parts of the Internet, or the mobile network may be connected to the Internet via tow or more MRs. In the first case, we could think of a unique device used to connect a car both to the cellular phone network and to a navigation satellite. In the second case, we may think of a PAN where the GSM is used to connect the PAN to the cellular phone network whereas a PDA is used to collect bus timetables from the city bus network. Routers in the mobile network All routers in the Internet are considered to run a number of protocols such as a routing protocol, Neighbor Discovery, ICMP, and others. This also applies to any router in the mobile network, including the mobile router. Ernst & Lach Expires 13 January 2001 [Page 8] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 Ad-hoc network An ad-hoc network that changes its point of attachment to the Internet may be seen as a mobile network. Idle Mobile Network A mobile network that does not engage in any communication outside the network may be considered as idle from the point of view of the fixed Internet, although there may be internal traffic between any two MNNs. Idle Mobile Network Node A MNN that does not engage in any communication. 1.4. Aim of network mobility support The purpose of network mobility support is to provide MNNs with an uninterrupt Internet connectivity and to route datagrams between CNs and MNNs by the most optimal path in both directions. 1.5. Assumption We limit the scope of our study to mobile networks that are stub networks, i.e. the mobile network does not forward traffic not intended to itself. 1.6 Issues Mobility of networks has an impact on routing, addressing, and a number of network protocols. 1.6.1. Routing Issues All packets sent to a MNN must transit through the current AR of the mobile network and the MR itself. As a result of mobility, the path to the mobile network is varying according to the AR to which the MR is currently attached. We have to investigate how this path could be determined in order to route packets via the most optimal path. Particularly, we need to examine if this is best solved by routing protocols or by some transient means as this is done for mobile hosts. We need to investigate: o if there is a need for a CN to determine that the node it is corresponding with is in a mobile network. o if there is a need to determine the topological location of Ernst & Lach Expires 13 January 2001 [Page 9] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 the mobile network or the mobile network node. o if there is a need to determine the AR where the mobile network is currently attached. o if correspondent nodes should be aware of the topological location of the mobile network or the mobile network node or if this should this be transparent to them o if forwarding should be established from a former AR to a latter one. 1.6.2. Addressing Issues o Impact on MR Following existing IPv6 specifications, any host is in theory required to obtain a topologically correct address on the link on which it is currently attached to. We must investigate if this can alternatively be done for a single host or for a router and for a mobile network. If yes, this means that the external interface of the mobile network is configured with the foreign prefix. We also have to investigate if the configuration of the MR's interface with a new address has an impact on the MNNs. o Impact on MNNs As for MNNs, they don't actually change their own point of attachment, then it is very questionable whether MNNs should also get a topologically correct address that actually reflects their topological [and hierarchical] location in the Internet. If we conclude that mobile network nodes should get a topologically correct address, we have to determine how this could be performed internally in the mobile network. If we renumber, we have to investigate how to maintain connections and how and where to advertise the new address; if we do not renumber, we have to investigate how to perform optimal routing between CNs and MNNs. 1.6.3. Network Protocols Issues As seen in section 1.3, all routers in a mobile network are routers like the others and have to run a number of protocols. Following the existing IPv6 specifications, they particularly should run at least an instance of a routing protocol, and other protocols like Neighbor Discovery, etc. We therefore have to investigate how the network protocols running in the mobile Ernst & Lach Expires 13 January 2001 [Page 10] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 network must interact with the network protocols running in each subsequent visited network and how the mobile router is going to interact with the ARs it attaches to. This raises a number of issues for each network protocol, as listed in the following sections. o Impact on Neighbor Discovery One task of Neighbor Discovery is to send Router Advertisements and Router Solicitations. When the mobile router is attached to some AR in a visited network, it should receive such Router Advertisements from its current AR. We have to investigate how those Router Advertisements should be processed by the mobile router and how the mobile router should interact with this instance of the protocol running at the AR. We also have to investigate what is the impact on this protocol when the mobile network leaves its point of attachment. o Impact on the Visited Network We have to investigate if the subsequent ARs and the other routers in the visited network should be aware that the visiting mobile node is a router and not a host. In addition, we have to examine if it is necessary to let them know that there is an entire network behind the mobile router. In such a case, a network route may have to be propagated in the visited network and this raises an additional number of issues as discussed in the section about routing protocols. o Impact on Routing Protocols We have to investigate how the mobile router interacts with the routing protocols running at each of its subsequent ARs. The impact may not be the same whether the mobile network is limited to a single IP-subnet or a number of IP-subnets. Indeed, a single mobile IP-subnet may not need to run an instance of a routing protocol whereas a mobile network comprising more than one router may. We have to evaluate what kind of routing protocols may run in a mobile network and how it interacts with the routing protocol running at each of its subsequent ARs. oo In case the mobile network is running the same routing protocol as its ARs, it is questionable whether the mobile network should participate or not in the routing protocol running in the visited network. If it does, the mobile network can be seen as a partition of the local network. The topology computed by the routing protocol becomes more Ernst & Lach Expires 13 January 2001 [Page 11] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 dynamic and we have to evaluate how existing protocols are able to handle this case. Moreover, mobility may cause a routing table partition. oo In case the mobile network doesn't participate in the routing protocol running in the visited network, the mobile network can be seen as a kind of Autonomous System that is running an instance of an Internal Gateway Protocol. routing protocol running in the mobile network and the routing protocol running in the visited network. In addition, we must determine what routing protocol is suitable within the mobile network. We also have to evaluate the impact on routing protocols when the mobile router is multi-homed, when the mobile network comprises more than one mobile router, and when the mobile network itself receives another mobile network. 1.6.4. Security Issues All security concerns that usually apply to host mobility support also apply to network mobility support. We may face a number of additional ones that complement the addressing issues, network protocols issues, and routing issues depicted in the previous sections. Ernst & Lach Expires 13 January 2001 [Page 12] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 2. Constraints and Requirements 2.1. Constraints 2.1.1. Host Mobility Support constraints LMNs and VMNs that operate Mobile IPv6 must still be able to use the same protocol once located in a mobile network. If needed, the solution to support mobile networks has to provide the necessary Mobile IPv6 extensions. 2.1.2. Addressing constraints The network part of IP addresses is used for routing and identifying the subnetwork in the topology. Every interface attached to a subnetwork must have a unique address with the network part identifying the subnetwork. 2.1.3. IPv6 constraints In order not to re-invent the wheel, any solution has to be based on IPv6 protocols. It is also desirable that it becomes an integral part of the existing protocol suite. It is desirable to introduce new features as extensions to the existing protocols with minimum modifications. 2.1.4. Security constraints Any solution must comply with IPv6 security policies. Ernst & Lach Expires 13 January 2001 [Page 13] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 2.2. Requirements Requirements relative to mobility of hosts are discussed in most published papers in the field of mobile networking as found in [1] and also [7, 4]. [OTHERS]. Most of them are equally applicable to network mobility support, with some additions. 2.2.2. Wide-Area mobility support A truly worldwide mobility support requires international standards in order to move between heterogeneous networks, i.e. wide-area mobility. A lack of international standardization would prevent from this. We must avoid a situation where distinct Internet Service Provider would develop distinct network mobility support schemes which are unable to inter-operate with each other. Not only standard between countries and organizations is required, but also between networks in which different policies may apply. Indeed, nothing but administrative and security policies should prevent a mobile network to attach anywhere in the Internet. For doing so, we need a mobility support scheme that fits well into the existing standards, that is easy to deploy and that does not require too much additional services in the network. 2.2.3. Security Unlike fixed nodes, MNNs are more exposed to security issues and identity usurpation. Mobility support must provide MNNs and their CNs with at least as good security as for fixed nodes and single mobile nodes. In practice, network mobility support signalling must be exchanged in a secure manner and must ensure the following: o Confidentiality Mobility support must ensure confidentiality of all control datagrams transmitted between MNNs and CNs in any direction to insure MNNs' confidentiality. If requested, only the recipient must be able to decrypt the content of the datagram. o Authentication All control messages must be authenticated by recipients in order to prevent intruders to usurp the identity of a MNN. Mobility support shouldn't leave more room for intruders to usurp an identify nor to perpetrate any kind of attack against MNNs or CNs. o Authorization Ernst & Lach Expires 13 January 2001 [Page 14] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 Mobility support must ensure that a node which performs a mobility management operation is effectively authorized to perform such an operation. o Location Privacy Mobility support has to provide means for to keep the location of MNNs secret to any third party. It shouldn't be possible to determine the topological location of a mobile network and its MNNs by monitoring control messages exchanged between any two nodes. In practice, MNNs may wish to hide their location to some or all of their CNs. The network administrator may also wish to hide the location of the mobile network to all CNs without discrimination between MNNs. 2.2.4. Transparency o Mobility Transparency With respect to the layer separation of the Internet protocol suite, handover of IP sessions should be transparent at layers above the network layer. At least, there shouldn't be an abrupt interruption of the IP sessions. This means that a mobile network is always reachable regardless of its point of attachment. Particularly, mechanism have to be added so that transiting datagrams are forwarded to the current location of the mobile network. o Operational Transparency From an application's point of view, continuous access to the Internet must be maintained regardless of the location of the mobile network. Moreover, it is required that the application does not need to perform any action to remain connected. This means that mobility support should be performed at the network layer. It is the responsibility of the network protocols to support connectivity of the network in an absolute transparent manner to the applications. o Mobility management transparency for MNNs We have seen that MNNs appear to move from the point of view of their CNs although do not change their point of attachment within the mobile network. Mobility management of a mobile network is therefore better seen as MR's responsibility and should be transparent to MNNs. MNNs should have no responsibility in network mobility management. They should only be concerned about managing their own mobility if they Ernst & Lach Expires 13 January 2001 [Page 15] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 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. o Performance Transparency Network mobility support should exhibit low latency, incur little or no data loss, minimum delays, scale to a large internetwork, incur minimum signalling load, bandwidth consumption for datagrams delivery and memory requirements, as seen in [3]. The solution is termed "efficient" provided mobility is supported without performance degradation of the Internet. Loss and delays should indeed range into those experimented for communication flows between two fixed nodes. Moreover, both local-area mobility and wide-area mobility need to be handled as efficiently. At last, the addition of network mobility support shouldn't impact the performance of upper layers. In order to limit losses during hand-offs and to avoid degradation of performance at the upper layers, it may be necessary to perform seamless handovers. o Layers Independence Support of mobility is best managed at the network layer. A change of topological location therefore shouldn't have any repercussion at other layers of the TCP/IP reference model. If this is respected, compatibility with existing transport and application layers is maintained. Support of mobility in transport and application protocols is not the focus of this study. 2.2.5. Optimal routing The amount of traffic intended for the mobile network is understandably more significant than in the case of a single mobile node. Non-optimal routing therefore becomes an even more important issue that it was already for mobile nodes. Avoiding triangle routing reduces bandwidth consumption and transmission delays. 2.2.6. Minimum signalling overload Routing packets efficiently from a CN to the current location of the mobile network may be performed at the cost of control traffic. The cost of this control traffic has to be balanced against the expected gain of optimal routing. Minimizing the amount of control traffic has always been an important concern for host mobility support. Due to a potentially large number of CNs, Ernst & Lach Expires 13 January 2001 [Page 16] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 this becomes an even more important concern for network mobility support. 2.2.7. Scalability Scalability has always been an important concern in the design of 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 signalling load and memory consumption should scale to an important number of mobile nodes. Network mobility support has to address scalability in two ways: o Large number of mobile networks Scaling to a large number of mobile networks as hosts mobility support is required to scale to a large number of mobile nodes. o Large number of correspondent nodes Scaling to the size of large mobile networks comprising hundreds of MNNs communicating with an important number of CNs. In other words, mobile network support must be able to support large mobile networks containing hundreds of nodes like a train and corresponding with thousands of CNs, and a very large number of small mobile networks such as PANs comprising a few IP devices. Scaling to a large number of CNs indeed deserves more consideration than scaling to a large number of mobile networks. 2.2.8. Nested mobility Network mobility support must allow VMNs to visit the mobile network and LMNs to leave it. Basically, a VMN should be able to operate Mobile IPv6 or any forthcoming standard. Network mobility support should therefore consider both mobile networks and mobile nodes, otherwise it may hardly interact with host mobility support. In practice, it should handle visiting mobile nodes as optimally as if networks where fixed. It is also advisable to consider the special case where the correspondent node is itself mobile or located in a mobile network. 2.2.9. Backward compatibility Backward compatibility corresponds to the ability to leave the actual protocol suite unchanged. This was an important issue for IPv4 since it is not possible to require all hosts to implement new features in order to manage mobility. On the other hand, the emergence of IPv6 is an opportunity for making the necessary Ernst & Lach Expires 13 January 2001 [Page 17] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 changes. Backward compatibility is not an issue at the time being although IPv6 itself has to interwork with IPv4. Indeed, IPv6 offers the possibility to add new features until the IPv6 specification is fully ratified. There is still scope for adding new capabilities if needed. 2.2.10. Minimum Impact on Existing Protocols In order to provide a deployable solution and to allow wide-area mobility, a good solution should better make use of the existing protocols whenever possible and impose minimum changes or extensions on the existing ones. Ernst & Lach Expires 13 January 2001 [Page 18] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 References [1] Pravin Bhagwat, Satish Tripathi, and Charles Perkins. Network Layer Mobility: an Architecture and Survey. IEEE Personal Communications, 3(3):54, June 1996. [2] Editor R. Braden. Requirements for Internet Hosts - Communication Layers. Request For Comments 1122, Internet Engineering Task Force (IETF), October 1989. [3] 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. [4] Claude Castelluccia. A Hierarchical Mobility Management Scheme for IPv6. Third Symposium on Computers and Communications (ISCC'98), Athens, Greece, June 1998. http://sirac.inrialpes.fr/planete [5] S. Deering and R. Hinden. Internet Protocol Version 6 (IPv6) Specification. Request For Comments 2460, Internet Engineering Task Force (IETF), December 1998. [6] David B. Johnson and C. Perkins. Mobility Support in IPv6. Internet Draft draft-ietf-mobileip-ipv6-14.txt, Internet Engineering Task Force (IETF), July 2001. Work in progress. [7] Andrew Myles and David Skellern. Comparing Four IP Based Mobile Host Protocols. In Joint- European Networking Conference. Macquarie University, Sydney, Australia, May 1993. [8] Thomas Quinot. An IPv6 architecture for Aeronautical Telecommunication Network. Master's thesis, Ecole Nationale Sup'erieure des T'el'ecommunications Paris, EUROCONTROL - European Organization for the Safety of Air Navigation - ISA project (IPv6, Satellite communication and ATMode for ATN), 1998. http://www.eurocontrol.fr/. Ernst & Lach Expires 13 January 2001 [Page 19] INTERNET-DRAFT Network Mobility Support in IPv6 13 July 2001 Author's Addresses Questions about this document can be directed to the authors: Thierry Ernst Motorola Labs Paris and INRIA - PLANETE team Grenoble ZIRST - 655 avenue de l'Europe 38330 Montbonnot Saint Martin, France http://www.inrialpes.fr/planete/ Phone: +33 4 76 61 52 69 Email: Thierry.Ernst@inrialpes.fr 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 1 69 35 25 36 Email: Hong-Yon.Lach@crm.mot.com Claude Castelluccia INRIA - PLANETE team Grenoble ZIRST - 655 avenue de l'Europe 38330 Montbonnot Saint Martin, France Phone: +33 4 76 61 52 15 Email: Claude.Castelluccia@inrialpes.fr Ernst & Lach Expires 13 January 2001 [Page 20]