Internet Engineering Task Force Kazuhiro Okanoue INTERNET DRAFT Tomoki Ohsawa NEC Corp. 22 Feb. 1996 IP Mobility Support with IP-squared(IP2) draft-okanoue-mobileip-ipsquared-00.txt Status of This Memo This document is a submission by the Mobile-IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@tadpole.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document specifies an encapsulation method for mobile-IP which enables intermediate systems to initiate routing optimization process. Key mechanism is to concatenation IP header as an outer IP header instead of IP tunneling specified as protocol number 4 in [1]. This datagram is called IP2 (IP squared) datagram. In order to handle the datagram, it is required for every mobility supporting node to have two functionalities, which discriminate whether received datagram is IP or IP2 datagrams and decide which datagram format should be used as transmitting datagram IP or IP2. These functionalities enable an intermediate mobility support node to initiate routing optimization process in [2] and routing paths between mobile and conventional stationary nodes can be optimized in the result. Okanoue and Ohsawa Expires 22 August 1996 [Page i] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 1. Introduction There exists a serious difference between mobility supporting and conventional fixed networks, such that a mobility supporting host can access networks from different access points. In order to achieve the feature, a mobility support network needs to manage the mapping between host itself and its location for every mobile host. Let's call an ID for host itself as a logical ID (L-ID) and an ID for host location as a geographical ID (G-ID). Moreover, it is also required for a mobility supporting network to guarantee communications between mobility supporting hosts (MH) and conventional stationary hosts (SH) in fixed networks without any modifications to the conventional networks and nodes. It is considered to be important for a mobility support network to provide the following functionalities to manage MHs; 1) registration functionality of a MH's location and 2) tracking functionality of a MH's location. It is considered that the registration functionality can guarantees reliable datagram forwarding to a MH and the tracking functionality can realize efficient routing paths of datagrams destined to MHs. The base Mobile IP protocol [3] can completely manage a mapping between the L-ID and the G-ID of a MH by defining a home agent for each MH, foreign agents and registration protocols between each MH and its home agent. However, the base Mobile IP protocol can not always provide optimized routing path to MHs. On the other hand, [2] describes routing optimization mechanisms as an option of the base Mobile IP protocol. In the optimization mechanisms, datagrams sent from nodes which have a binding cache [2] can be transferred to a MH. However, datagrams from nodes without the binding cache such as SHs are not optimized but always transferred to a MH via its home agent. It is considered to be important in an IPv4 world to support routing optimization for SHs, because all IPv4 nodes will not always have the binding cache. In order to solve the route optimization issue, this document introduces to use IP2 (IP squared) datagrams as another kind of encapsulation method and new functionalities to handle the IP2 datagrams. Then this document describes routing optimization methods. It is considered that the methods can be implemented as an additional option to [2]. Okanoue and Ohsawa Expires 22 August 1996 [Page 1] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 1.1 Terminology Logical ID: IP address for a mobile host identification. L-ID does (L-ID) not change wherever the mobile host migrates. Geographical ID: IP address depending on a location of a mobile (G-ID) host. Each mobile host obtains a G-ID via a mechanism such as DHCP [4]. Mobility supporting node: a node which has functionalities to handle IP and IP2 datagrams. This node may have functionalities to optimize routing paths. 2. IP2 overview In a node handling IP2 datagrams, its network layer is divided into two sub-layers, i.e., one is upper sub-layer based on its L-ID and another is lower sub-layer based on its G-ID and each sub-layer uses IP header format as its header. Then we call upper and lower sub-layers as Logical and Geographical IP sub-layers (L-IP and G-IP), respectively. Figure 1 shows the layer architecture of a node handling IP2 datagrams. One of the merits to adopt this architecture is that conventional softwares above the Logical IP sub-layer can be used without modification. In this architecture, a MH can be realized only by adding the Geographical IP sub-layer to a SH. Transport Layer | TCP/UDP | ------------------+--------------------------+ | Logical IP sub-layer | Network(NW) Layer +--------------------------+ | Geographical IP sub-layer| ------------------+--------------------------+ Data link Layer | Ethernet, FDDI, ... | ------------------+--------------------------+ Figure 1. Architecture of IP2 When each node with the layer architecture in Figure 1 sends a datagram, L-IP sub-layer constitutes an IP datagram and an G-IP sub-layer adds another IP header to the IP datagram supplied from its L-IP sub-layer. Okanoue and Ohsawa Expires 22 August 1996 [Page 2] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 Figure 2 shows an IP2 datagram format. The IP2 datagram is considered to be an IP datagram which is encapsulated by another IP header. Though all of mobility supporting nodes must handle both the IP2 and IP datagrams correctly, conventional nodes can not handle the IP datagrams. Hence, all of mobility supporting nodes must have a functionality to discriminate IP2 and IP datagrams. Then mobility supporting nodes can grasp that nodes which send or receive the IP2 datagrams are mobility supporting nodes and initiate routing optimization processes. +------------------------+ | IP Header | | (Logical IP Header) | +-------------+ +------------------------+ | IP Header | | IP Header | | | |(Geographical IP Header)| +-------------+ +------------------------+ | | | | | IP Payload | | IP Payload | | | | | +-------------+ +------------------------+ IP datagram IP2 datagram Figure 2 IP2 datagram format Source and destination addresses in the outer IP header identify the geographical addresses of the sender and the receiver of the datagram. The logical addresses of the sender and the receiver are identified as source and destination addresses in the inner IP header. 3. Geographical IP header fields IP2 datagram is constructed by concatenating another IP header to IP datagram as shown in figure 2. RFC 791[1] describes the IP header format. Version 4 IHL The Internet Header Length measures the length (in bytes) of the outer IP header exclusive of its payload, but including any options which the encapsulation node may insert. Okanoue and Ohsawa Expires 22 August 1996 [Page 3] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 TOS The type of services is copied from inner IP header. Total Length The length measures the length of the outer IP header along with its payload, that is to say the inner IP header and the original datagram. Identification The identification is copied from inner IP header. Flags Fragment Offset These two fields are set in accordance with the procedures specified in [1]. The "Don't Fragment" bit in the outer IP header is copied from the corresponding flag in the inner IP header. Time to Live The Time To Live (TTL) field in the outer IP header is set to a value appropriate for delivery of the encapsulated datagram to the tunnel endpoint. Protocol The protocol is copied from inner IP header. Header Checksum The Header Checksum is computed over the length (in bytes) of the outer IP header exclusive of its payload, but including any options which the encapsulating endpoint may insert. Source Address The geographical IP address of the sender. Destination Address The geographical IP address of the receiver if the sender knows it, else the logical IP address of the receiver. Okanoue and Ohsawa Expires 22 August 1996 [Page 4] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 Options not copied from the inner IP header. However, new options particular to the path may be added. 4. Functionality in IP2 datagram reception Considering environments where both mobility supporting and conventional stationary nodes coexist, when a mobility supporting node receives a datagram, the node needs to discriminate whether the received datagram is an IP or an IP2 datagram. In order to do this, the mobility supporting node process the following algorithm whenever it receives a datagram. Step 1: Whenever a mobility supporting node receives a datagram, the node assumes that the received datagram is an IP2 datagram. Step 2: Detect the first header in network layer. The first header must be always IP header. If the mobility supporting node detects header errors in the received datagram, the datagram is discarded. Step 3: From the assumption in Step 1, the second header must be an Inner IP header, which is identical to an IP header. Step 4: Detect the second header as an IP header. In the second header detection, the mobile supporting node can use not only header error detection based on a header checksum but also checking known header filed values. If the mobility supporting node successfully detects the second header as an IP header, then the datagram is an IP2 datagram. Otherwise, the datagram is not an IP2 datagram. 5. Functionality in IP2 datagram transmission In order to keep a compatibility with conventional stationary nodes, we need to consider two kinds of nodes, one is an intermediate system such as a router and another is an end system such as a host. As for intermediate systems, conventional routers can handle IP2 datagrams correctly, because an IP2 datagram has the same structure as an IP datagram. However, a SH can handle only IP datagram. In order to communicate between MHs and SHs without any modifications in SHs, it is required for MHs to convert IP2 datagrams to IP datagrams whenever they send datagrams to SHs. If MHs know whether its correspondent node is an MH or an SH in advance, they can easily convert datagram format. Okanoue and Ohsawa Expires 22 August 1996 [Page 5] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 However, it is not realistic for each MH to know host types (MH or SH) for all of other hosts. Hence, the following mechanism is introduced. Step 1: When a MH sends a datagram to a host which the MH does not know its host type, the MH sends IP datagrams to the host. Simultaneously, the MH sends a special control message (mobility notification message, MNM) to the host, which contains that "I can handle IP2 datagrams". Moreover, the MH caches that "the correspondent host is SH". Step 2: If the host is an MH, the host can return an acknowledgment message corresponding to the MNM. Receiving the acknowledgment from the host, the MH can change the cache to "the correspondent host is a MH", then the MH begins to IP2 datagrams to the host. On the contrary, if the host is a SH, the MH can not receive any acknowledgment messages. Then the MH does not change the cache about the host. Hence, the MH will continue to send IP datagrams to the host. It is important not to use any location information such as a G-ID of the correspondent host in the mechanism. This mechanism needs only the information whether the correspondent host is a mobility supporting node or not. In the result, this mechanism does not any effects on routing information. If a sender knows that the correspondent node has mobility support functionality, the sender can send IP2 datagrams. The destination address in the outer IP header of this IP2 datagram is not always correct geographical address of the correspondent host. However, it can trigger routing optimization processes described in [2] between the correspondent host and the sender. 6. Routing Optimization Process As described in the previous sections, every mobility supporting node needs to judge whether it can use an IP or an IP2 datagram whenever it sends a datagram. This functionality can guarantee to send IP2 datagrams only to mobility supporting nodes. Okanoue and Ohsawa Expires 22 August 1996 [Page 6] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 Once a datagram destined to a mobility supporting node is encapsulated, even if the destination address in the outer IP header is a logical address of the destination, route optimization processes described in [2], which use Binding Warning, Request and Update messages, can be initiated. In the results, routing paths can be optimized for encapsulated datagrams. This section describes an authentication mechanism that a sender itself encapsulate datagrams based on a current geographical address of its destination. In the case where a mobility supporting node knows a geographical address of a correspondent node, a routing path between the node and the correspondence is optimized by using an outer IP header with the correspondents geographical address as a destination address. However, it is not realistic for a mobility supporting node to know geographical addresses of all of other nodes. Hence, a mobility supporting node which desires routing optimization needs to use authenticated mobility notification and its acknowledgment messages to know geographical addresses of other nodes. Moreover, a mobility supporting node which desires route optimization needs to have a cache to store mappings between logical and geographical addresses of other mobility supporting nodes. Let call this cache an address mapping cache. The address mapping cache has the same role as a binding cache described in [2]. 6.1 Consideration on Mobility supporting node In order to authenticate a geographical address of a correspondent node, a mobility supporting node must establish manually a mobility security association[3] with a home agent of the correspondent node in advance. A mobility supporting node can optimize routing paths to a correspondent node whose logical address implies that their home agents have established mobility security association with the mobility supporting node. 6.1.1 Address mapping cache A mobility supporting node which desires to optimize routing paths must have an address mapping cache. Any node may manage the space in its cache using any local cache replacement policy. A mobility supporting node can update address mapping entries based on only an authenticated MNM and its acknowledgment. A mobility supporting node must not change any cached entries even if the node receives IP2 datagrams which imply that there exist inconsistencies between a cached address mapping and an address mapping derived from the IP2 datagram. Okanoue and Ohsawa Expires 22 August 1996 [Page 7] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 Each address mapping includes following information for a node specified by its logical address; 1) logical address of the node, 2) its geographical address, 3) lifetime for the geographical address and 4) address of its home agent. A mobility supporting node can keep an address mapping of a node of which home agent has established a mobility security association with the mobility supporting node in its address mapping cache. A mobility supporting node must remove an address mapping entry in its address mapping cache of which lifetime has been expired. 6.1.2 Procedure for transmitting datagram Whenever a mobility supporting node sends a datagram, it must judge whether it uses an IP or an IP2 datagram. Then a mobility supporting node checks whether its address mapping cache includes an address mapping of a destination. When the mapping exists in the cache, the mobile node sends a datagram in IP2 datagram format. Otherwise, the mobility supporting node sends a datagram in IP datagram format. In the case where the address mapping cache does not have an address mapping of the destination node, the mobility supporting node checks whether the destination is managed by a home agent which has established a mobile security association with the node or not. If the mobility security association has been established between the mobility supporting node and the home agent, the mobility supporting node sends a MNM to the home agent to request the geographical address of the correspondent node. 6.1.3 Procedure for receiving datagrams A mobility supporting node has a possibility to receive both IP and IP2 datagrams. When a mobility supporting node receives IP2 datagrams, the mobility supporting node must derive an address mapping of the sender from the received datagram. Then the node searches an address mapping entry for the sender from its address mapping cache based on a logical address of the sender. There exist the following three cases according to relations between the address mappings in the cache and derived from the datagram; Okanoue and Ohsawa Expires 22 August 1996 [Page 8] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 case 1) a case where its address mapping cache has the same address mapping entry as the derived address mapping, case 2) a case where its address mapping cache has the different address mapping entry from the derived address mapping, case 3) a case where its address mapping cache has no entry for the derived address mapping. In the case 1, a mobility supporting node needs to do nothing to control its address mapping cache. In the case 2, a mobility supporting node must send a MNM to a home agent which manages the sender of the received datagram to update an address mapping for the sender. In the case 3, a mobility supporting node must check whether it has already established a mobility security association with a home agent of the sender or not. If a mobility security association has been established, the mobility supporting node sends a MNM to the home agent to request geographical address of the sender. Otherwise, the mobility supporting node must ignore a geographical address of the sender. When a mobility supporting node receives a IP datagram, the mobile node sends it to an upper layer after processing the IP datagram as usual. 6.1.4 Procedure for transmitting MNM When a mobility supporting node send a MNM to a home agent to request a geographical address of a particular node, the MNM needs to include its identifier and an authenticator based on a mobility security association established between the home agent and the node. The identifier is added to avoid a replay attack. As the identifier, it is considered to be able to apply a method using time stamp described in [3]. 6.1.5 Procedure for receiving MNM acknowledgment When a mobility supporting node receives a MNM acknowledgment from a home agent which has been established a mobile security association with, the node check its authenticator and identifier. If the mobility supporting node confirms the authenticator and identifier in the acknowledgment message, the node cache the geographical address of the correspondent host. In the case where the acknowledgment message implies that the correspondent host is a stationary host, the mobility supporting Okanoue and Ohsawa Expires 22 August 1996 [Page 9] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 node caches a information that the corresponding host is a stationary host. 6.2 Consideration on home agent 6.2.1 Procedure for receiving MNM When a home agent receives a MNM, it check whether a mobility security association has been established between the home agent and the source node of the MNM. A home agent accepts only a MNM satisfying following conditions; 1) a source node of the MNM is a node which have already established a mobility security association with the home agent, and 2) the home agent successes to authenticate the MNM. 6.2.2 Procedure for sending MNM acknowledgment When a home agent accepts a MNM, the home agent send a MNM acknowledgment message to the source node of the MNM with following information; 1) the same identifier in a corresponding MNM from the source node of the MNM, 2) a geographical address of the required node and 3) an authenticator. If the node of which the sender requests geographical address is not a mobility supporting node but a stationary node, the home agent send a MNM acknowledgment which shows the required host is a stationary node. 6.3 Routing optimization between a stationary node and mobility supporting node At the beginning of introducing mobility supporting nodes, it is considered that almost of their correspondent hosts are stationary nodes. Hence, it is important to optimize a routing path between a stationary and mobility supporting node. In order to do this, a router may have an address mapping cache as a proxy of stationary nodes in a routing domain directly connected to the router. In this case, the router with an address mapping cache can optimize routing paths between the stationary nodes and Okanoue and Ohsawa Expires 22 August 1996 [Page 10] Internet Draft IP Mobility Support with IP-squared(IP2) 22 Feb. 1996 mobile nodes of which home agents has established a mobility security association with the router. The router can judge whether a received datagram is a IP or a IP2 datagram whenever it receives a datagram. Hence, the router may try to optimize routing path of transferring IP datagrams, assuming that the sender of the IP datagram is a stationary node. As for IP2 datagrams, the router can not always optimize routing paths. When the router encapsulate IP datagrams from a stationary host to optimize routing paths, the router must use its IP address as a geographical address of the stationary nodes. On the other hand, when the router receives a IP2 datagram of which destination address in an outer header implies the router, the router must decapsulate the IP2 datagram and send it to the node specified the destination address in an inner header of the IP2 datagrams. 7. References [1] J. Postel. Internet Protocol. RFC 791, September 1981. [2] David B. Johnson, Charles Perkins. Route Optimization in Mobile- IP. Internet Draft, draft-ietf-mobileip-optim-03.txt, November 1995. Work in progress. [3] Charles Perkins, editor. IP mobility support. Internet Draft, draft-ietf-mobileip-protocol-12.txt, August 1995. Work in progress. [4] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, October 1993. Authors address Questions about this memo can also be directed to: Kazuhiro Okanoue Swedish Institute of Computer Science (Visiting Researcher from NEC Corp.) Box 1263, 164 28 Kista, Sweden Work: +46-8-752-1526 Fax: +46-8-751-7230 E-mail: okanoue@sics.se Tomoki Ohsawa C&C Research Labs., NEC Corp. 4-1-1, Miyazaki, Miyamae-ku, Kawasaki, 216 Japan Work: +81-44-856-2255 Fax: +81-44-856-2230 E-mail: ohsawa@nwk.CL.nec.co.jp Okanoue and Ohsawa Expires 22 August 1996 [Page 11]