Internet Engineering Task Force Riaz Inayat Internet Draft Pakistan Telecommunication Company Limited Expires: January 31, 2006 Reiji Aibara Hiroshima University Kouji Nishimura Hiroshima University Kaori Maeda Hiroshima City University Yasunori Sugimoto Net One Systems Co., Ltd. August 1, 2005 MAT: A Network Architecture for Supporting Node Mobility in Wireless IP Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. This Internet-Draft will expire on January 31, 2006. Copyright Notice Copyright (C) The Internet Society (2005). IPR Disclosure Acknowledgement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Inayat, et al Expires January 31, 2006 [Page 1] draft-inayat-mat-00.txt August 2005 Abstract This document describes MAT, a mobile network architecture that allows smooth node mobility in wireless IP networks without using any packet intercepter/forwarder. The mobility solution is specifically designed for time-sensitive real-time applications, particularly the applications where payload tends to be short and packet header overhead is very significant. Connections are established as per permanent addresses of the nodes but are carried on by the IP layer according to the temporary addresses by address translation at the end nodes. The mapping information is maintained by database servers, which can be placed in the Internet in a distributed manner. TCP connections and security associations can be preserved even if the node moves to another subnet or the node changes its active interface in a multi-homed environment without modifying TCP or IPsec. In comparison with Mobile IPv4 and IPv6, MAT has several advantages in terms of header overhead and fault tolerance. 1. Introduction This document describes the protocol specification of MAT [IEICE04,SAINT04,IJWOC03]. We propose MAT (Mobile Network Architecture with Address Translation) to solve several problems such as mobility, handoff management and multihoming particularly for time-sensitive real-time applications. MAT supports mobility in IPv4 as well as in IPv6[RFC2460] environments. From mobility support viewpoint, MAT has several advantages in comparison with Mobile IPv6[MIPv6] and IPv4[MIP] as follows: o MAT has no header overhead because it generally does not use any extension headers of IPv6 while Mobile IPv6 uses the Destination Options Header for the Home Address Option and the Routing Header for optimal routing. o MAT is more fault tolerant than Mobile IPv6. In Mobile IPv6, the Home Agent cannot be replicated to the subnet other than the home link of the mobile node. MAT introduces MIS (Mapping Information Server) which can be replicated anywhere in the Internet. o MAT keeps end-to-end communication model, that is, MAT does not use any packet intercepter/forwarder such as the Home Agent of Mobile IPv6. There is no tunneling in MAT. MAT has several advantages from viewpoint of IP diversity support. For multi-interfaced mobile devices, IP addresses of the interfaces are stored in MIS with priorities against the home address. This helps to achieve smooth handoff without requiring direct update of IP addresses between the end nodes. Assume that Node-A starts communication with Node-B, a multihoming node with two network interfaces. Inayat, et al Expires January 31, 2006 [Page 2] draft-inayat-mat-00.txt August 2005 o Node-A will always communicate with the home address of Node-B no matter which network interface of Node-B is used. o Packets from node-A to node-B are routed to the highest priority interface of node-B by translating home address to the IP address of that interface. o Node-B keeps the priority of the interfaces updated at the MIS. At the overlapping area between subnets packets can be received through both interfaces. o There is no need to send the change of address update to the node-A directly. This update is made effective with the help of MIS. Similarly in MAT Security Association (SA) does not have to be changed if the node changes its point of attachment during a session. Assume that Node-A starts TCP communication with Node-B, a multihoming node with two network interfaces, by using Ipsec [RFC2401]. o Node-A can recognize the identity of Node-B by the home address of Node-B no matter which network interface of Node-B is used. o The same security association (SA) can be used between Node-A and Node-B no matter which network interface of Node-B is used. o The TCP connection and the SA are still available even after the used network interface of Node-B is switched to another during communication. 2. Terminology This document uses the following terms. MAT: Mobile network Architecture with address Translation, the network architecture described in this document. node: The node is the general term to specify the equipment that understands IP in the Internet. The node includes hosts, mobile terminals, routers, and so on. mobile node (MN): A node that can change its point of attachment from one link to another. A mobile node is assumed to have implemented MAT features unless explicitly stated otherwise. correspondent node (CN): A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. Inayat, et al Expires January 31, 2006 [Page 3] draft-inayat-mat-00.txt August 2005 MAT node: A node that has implemented MAT features. non-MAT node: A traditional node that does not have MAT capabilities. home address (HAdr): An IP address assigned to a node within its home link. It also represents node's identity. mobile address (MAdr): An IP address associated with an interface of a node while visiting a foreign link. For a non-mobile node, mobile address is same as HAdr. home network: The network on which a node's home subnet prefix is defined. foreign network: Any network other than the node's home network. mapping informtion: The association of the home address of a mobile node with mobile addresses (mobile node can have more than one address depending upon number of interfaces) of that mobile node, along with the remaining lifetime of that association. mapping information server (MIS): A location directory, which maintains the location database of the MN corresponding to the home address. A secure communication must be supported among mobile node and corresponding MISs. mapping information table (MIT): A table maintained by every MAT-node caching the mapping informations and the addresses of the corresponding MISs of the mobile nodes with which the MAT-node is communicating. 3. Architecture Overview 3.1. Addressing For MAT, we remain consistent with the current mobile internet, MIP[RFC3344] and MIPv6[RFC3375] addressing schemes i.e., to use two addresses for a mobile node; the permanent address specifies the node's identity and the temporary address represents the current location. As a matter of fact any Internet addressing scheme which employs separation of node identifier and node locator, either using a single address or two separate addresses, can be used to describe end points. However, in this document, for simplicity of exposition, HAdr represents the node identity and MAdr represents the current location of the node. Inayat, et al Expires January 31, 2006 [Page 4] draft-inayat-mat-00.txt August 2005 transport layer | ---------------------------------------|-------------------------------- V +----------------------+ | source address: HAdr | | target address: HAdr | +----------------------+ source address translation | target address translation +------------------+-------------------+ (a)| | (c) | (b) V | V +---------+-----------+ | +---------------------+ |source address: MAdr | | |target address: MAdr | +-------------------- + | +---------------------+ | | | +------------------+-------------------+ V +----------------------+ | source address: MAdr | | target address: MAdr | network +----------------------+ MAT sublayer layer ------------------------------|---------------------------- V delivery sublayer +----------------------+ | source address: MAdr | | target address: MAdr | +----------------------+ ---------------------------------------|-------------------------------- V Figure 1: Basic Communication Model 3.2. Basic Communication Model Figure 1 depicts the basic communication model of MAT. The network layer is divided into two sub-layers: the MAT sub-layer and delivery sub-layer. The MAT sub-layer performs the following functions. o it identifies whether the target node is MAT node or non-MAT node. o it determines the IP address of the MIS corresponding to the target MAT node. o it finds out the mobile address corresponding to the target home address. o it performs the address translations. The delivery sub-layer delivers the packet as per target address. As Inayat, et al Expires January 31, 2006 [Page 5] draft-inayat-mat-00.txt August 2005 shown in the Figure 1, while sending a packet, application specifies the destination with the home address for the target node. MAT sub-layer receives the packet from transport layer. It identifies that whether the target node is a MAT node or non MAT node. Now depending upon the type of the target node as well as mobility status of the source and destination nodes, the MAT layer performs address translations: o If end-hosts are MAT nodes then both address translations, source address translation and destination address translation are performed. As shown is Figure 1, both (a) and (b) operations are performed. o if the target node is a non-MAT node and the source node itself is at home network, it simply hand over the packet to the delivery sub-layer for further transmission without any translation (see Figure 1 operation (c)). o If the target node is a non-MAT node and the source node itself is at foreign network, it only performs the source address translation. As shown is Figure 1, only (a) operation is performed. o If both end nodes are MAT nodes but only target node is mobile then only operation (b), as shown in the Figure 1, is performed. After address translation, the packet is passed to the delivery sub-layer, which transmits the packet as usual. While receiving, the same operations are performed depending upon the type and mobility status of the source and destination nodes. 3.3. Basic Mobility Support in MAT subnet 1 +----+ +----+ | | <=======> | MN | -----+ | | A +----+ V | | | +----+ subnet 2 | CN | <===========|======>| MN |-------+ | | | B +----+ V | | | | +----+ | | <===========|==========|======>| MN | subnet 3 +----+ | | C +----+ ^ | | | | | | | V | | | +------+ | | | | | <----------+ | | | MIS | <---------------------+ | | | <--------------------------------+ +------+ Figure 2: Mobility Support in MAT Inayat, et al Expires January 31, 2006 [Page 6] draft-inayat-mat-00.txt August 2005 The mobility support in MAT is depicted in the Figure 2. The single lines show the control information messaging and double lines show the actual user data transmission. Suppose that the correspondent node is communicating with the mobile node, which is at its home network and has been assigned IP address A. As it is a MAT node, so from the start of communication the correspondent node has a mapping information entry of MN in its Mapping Information Table (MIT). MIT is maintained by every MAT node. When CN starts communicating with a mobile node, it fetches the mapping information of the mobile node from MIS by querying it with the home address A as the key. Mobile node keeps the MIS updated with its location by sending mapping information updates. So when the mobile node moves to the foreign networks, the mapping information entry (mobile addresses B and C) in the MIS corresponding to the mobile node home address A is updated. CN updates the MIT by periodically querying the MIS depending upon the lifetime of the mapping information entry or whenever MN alerts CN about change of address or address priorities. The user data always flows directly between CN and MN. 3.4. Mapping Information Server (MIS) When a node performs address translation, the node needs to associate the HAdr with MAdr. Thus a database system having the mapping information about the nodes is required. In the Internet, the Domain Name System (DNS) maintains a similar sort of database. DNS is a distributed database that maps Fully Qualified Domain Name (FQDN) to IP address and vice versa, and provides other type of information related to an IP address and a FQDN. For example, consider the case in which one wants to know a FQDN associated with a particular IP address. In this case, one sends a query with the IP address as a key to DNS, and obtains the FQDN associated with the requested IP address. This feature of DNS, called reverse lookup, works fine in the Internet. DNS can be used to store the mapping information of a mobile node. However, as DNS is meant for "static" data, it is not feasible to use DNS for maintaining the mapping information regarding the location of a mobile node, which changes its location very frequently. DNS is a very large scale distributed database and so for load balancing it caches the data for a reasonable long time. And thus it takes a very long time for a change to be affective. We use a dedicated location database server, MIS, for maintaining the mapping information. A node registers its mapping information periodically to its corresponding MIS. It also registers a new mapping information when the node changes its location on the network. If a mobile node has more than one network interfaces, the mapping information record will have more than one MAdrs corresponding to the HAdr and these MAdrs will be with priorities. CN will communicate with the MAdr having highest priority. MIS only maintains the mapping information of mobiles nodes. It does not perform any kind of interception or forwarding of packets. Inayat, et al Expires January 31, 2006 [Page 7] draft-inayat-mat-00.txt August 2005 In MAT, to make the network architecture more fault-tolerant i.e., immune to a single point of failure and to reduce mapping information registration latencies, MIS can be replicated and placed at multiple locations in the Internet. The main purpose of having multiple MISs is to make the system more fault tolerant however this feature of MAT can also help to improve the quality of the handoff by reducing the mapping information update and mapping information acquisition times. It is obvious that if the location of MIS is near to the MN and CN then the mapping information update and acquisition time will be less. However having multiple MISs can give rise to two issues. One is how to synchronize MN's mapping information between multiple MISs so that the database of corresponding MISs about the MN should be same and the second is how to find the nearest MIS corresponding to the mobile nodes. We deal with these issues in the following ways. 3.4.1. Synchronizing Multiple MIS's Database For synchronizing the mapping information between multiple MISs, as we assume very few MISs corresponding to a certain MN, the MN updates its mapping information by itself to all its corresponding MIS. By this, mapping information remains updated and synchronized automatically between multiple MISs. However in case of a large number of MISs, more refine procedures are required. These procedures are beyond the scope of this document. 3.4.2. Finding the Nearest MIS To address the second problem we could use a mechanism like global load balancing, which is used in web-access to select the nearest web server from the clients. However, the appropriate MIS is that which is near to both MN and CN, so the MIS selected by the global load balancing method may not be the optimal one because it does not take into consideration proximity from both CN and MN. MAT assumes a simple method to select the appropriate MIS. The MIS record in DNS contains the IP addresses of all the MISs corresponding to a certain MN. At first the CN selects any MIS from the MISs specified by the MIS record and after obtaining MN's mapping information starts communication with the MN. It then sends special packet forcing it to take the route to the MN through the MIS by using source routing option in IPv4 and routing header in IPv6. CN repeats this for all the corresponding MISs and select the one that offers minimum path delay. The addresses of all the MISs are cached in the order of increasing path delays. From then onward CN always fetches the MN's mapping information from the MIS that offer minimum delay. However in case of a large number of MISs, more refine procedures are required. These procedures are beyond the scope of this document. 3.5. Identifying the Type of Target Node and Finding the Corresponding MIS In MAT, in order to provide the backward compatibility with the existing Inayat, et al Expires January 31, 2006 [Page 8] draft-inayat-mat-00.txt August 2005 Internet infrastructure, we need to identify the type of the target node from the address specified by the transport layers protocols. By type we mean that whether it is a MAT enabled node or otherwise? If the target node is a MAT node then we also need mapping information to perform address translation. As mentioned in section 3.4, mapping information is stored in MIS. Therefore, we need to know the IP address of the MIS (MIS record) to fetch the mapping information corresponding to the HAdr. As the MIS record is almost static and does not change as frequently as mapping information of a mobile node, DNS can be used for maintaining MIS record. The MIS record is a reverse record stored like a pointer (PTR) record in DNS but it points to the IP address of the MIS instead of the fully qualified domain name (FQDN). It associates IP address (HAdr) with the IP address (MIS). To implement this, MIS record is added in DNS database at the home network, which is managing the PTR record of the HAdr. No modification is required at the root and intermediate DNSs, since intermediate servers are only interested in query name and query name is the reverse domain name (like PTR) corresponding to the target IP address which is compatible with the existing query names allowed in the DNS. In MAT the authoritative server for the MIS record is the server that is managing other resource records corresponding to the HAdr. In order to identify the target node type, a MAT node sends a query to DNS to obtain the MIS record. If the answer section of the response does not contain the MIS record, it means the target node is not a MAT enabled node otherwise if the response has the MIS record it then obtains the mapping information from the MIS pointed by the MIS record and caches it to the MIT for the life time specified in the mapping information. The address of the MIS is also cached. 3.6. Communication Mechanism of MAT Communication mechanism of MAT is summarized in Figure 3. For Simplicity of exposition, it is assumed that Node-1 and Node-2 are associated with only a single Mapping Information Server. MIS11 maintains the mapping information of Node-1 and MIS22 of Node-2. Both nodes are updating their mapping information to their respective MIS. The following functions are performed when a packet transverses from node-1 to node-2. 1. Node-1 and node-2 are updating their current locations to MIS11 and MIS22 respectively. 2. From the upper layer the packet is handed over to the network layer with permanent home addresses in the packet header. 3. As there is no cache entry in the MIT corresponding to the home address, the node-1 through DNS1 finds that the target node is a MAT node and its corresponding location directory is MIS22. Inayat, et al Expires January 31, 2006 [Page 9] draft-inayat-mat-00.txt August 2005 +-------+ 1 | MIS22 | <--------------+ +-------+ | ^ | 4| | 2,5 V V 9,10 +------+ 3 +------+ 6 +------+ 7 +------+ | DNS1 | <---------> |Node-1| <=========> |Node-2| <---------> | DNS2 | +------+ +------+ +------+ +------+ ^ 8 ^ DNS: Domain Name Server | 8| MIS: Mapping Information | V Server | 1 +-------+ +--------------->| MIS11 | +-------+ Figure 3: Communication Mechanism 4. Mapping information for node-2 is fetched from MIS22 and cached in MIT. 5. As both nodes are mobile so both address translations (source and destination) are performed. 6. The packet is routed according to the destination mobile addresses. 7. The packet reached the node-2. As there is no cache entry in MIT corresponding to the source home address, the node-2 through DNS2 finds that the source node is a MAT node and its corresponding location directory is MIS11. 8. Mapping information for node-1 is fetched from MIS11 and cached. 9. Destination as well as source translations are performed at the network layer. 10. The packet is handed over to the upper layers with home addresses. 3.6.1. Start of Communication as a Sender There is slight difference in messaging sequence when communication is started at sending and receiving node. A CN, when starts communication as a sender, follows the following sequence of messages (see Figure 4). 1. With target node's home address as a key, the CN sends the request to the DNS server for the MIS record. If it gets the MIS record in the answer section of the response, it means that the target node is a MAT node. Inayat, et al Expires January 31, 2006 [Page 10] draft-inayat-mat-00.txt August 2005 +-----+ +----------------> | MIS | | +-----+ 2 | ^ | | V V +-----+ 1 +-----+ 3 +-----+ | DNS | <----------> | CN | ===========> | MN | +-----+ +-----+ +-----+ Figure 4: Messaging Sequence When CN starts Communication as a Sender 2. From the MIS record, it gets the IP address of the MIS of the target mobile node. It then queries that MIS for the mapping information of the mobile node. The response contains the mapping information of the mobile node. 3. It then starts sending the data packets to the mobile node after translating the target home address to the respective mobile address. If the CN node itself is a mobile node it must sends the first data packet with its home address in IP header option, we called it Home Address Option, HAO (IP header option in IPv4, destination option header in IPv6). Its use is explained in section 3.6.2. 3.6.2. Start of Communication as a Receiver +-----+ +----------------> | MIS | | +-----+ 3 | ^ | | V V +-----+ 2 +-----+ 1 +-----+ | DNS | <----------> | CN | <=========== | MN | +-----+ +-----+ +-----+ Figure 5: Messaging Sequence When CN starts Communication as a Receiver When a CN starts communication as a receiver, the messaging sequence is as follows, Figure 5. 1. In MAT, the first packet received from the mobile node must have home address information. Home address information is required to find out the IP address of the MIS and consequently the mapping information of the mobile node. 2. The CN then finds the MIS record from the DNS server. Inayat, et al Expires January 31, 2006 [Page 11] draft-inayat-mat-00.txt August 2005 3. From the MIS record, the CN gets the IP address of the MIS of the mobile node and consequently finds the mapping information corresponding to the mobile node. IP addresses of MIS as well as mobile nodes are then cached in the mapping information table for further communication until the CN receives the next alert message from a mobile node 3.7. DNS Entries As described in section 3.4 and section 3.5 the relation between the MAT node and its MIS is almost static in contrast to the mapping informations of the MAT node. MAT makes use of the Domain Name System (DNS) to maintain the relation between the mobile node and its MISs. The MAT node has an MIS record entry in DNS. An MIS record is a PTR like record which maps a (reversed) node identity (home address) to the IP addresses (addresses of MIS corresponding to the node) instead of FQDN. When a MAT node (receiver node) received a packet from another MAT node then the first few packets must have the home address of the MN. This home address is used to fetch the MIS record of MN through the DNS. The subsequent mapping information fetched from the MIS also confirms the current location of the MN which avoid impersonation. Thus, no modifications to DNS are required. 3.8. IPsec Operation In the sending node, IPsec is processed as follows. When the packet is passed from the transport layer, the source and the destination address fields in the IP header contain home addresses representing the node identities. The security association is decided by using the destination home address, and then IPsec calculation is executed. After that, the source and the destination addresses are converted to mobile addresses. In the receiving node, IPsec is processed as follows. Upon packet reception, the source and the destination address fields of IP header contain mobile addresses. First, these mobile addresses are converted to home addresses. The security association is decided by using the destination home address, and then IPsec calculation is executed. 3.9. Handoff Support for multi-interfaced Devices In MAT, a source node is capable of changing the destination address to the current MAdr without affecting the communication. And also the feature of MAT of having more than one MAdrs at MIS corresponding to a HAdr when MN has dual interface, can help to reduce handoff latency if these addresses are stored with priorities. In MAT, for seamless Inayat, et al Expires January 31, 2006 [Page 12] draft-inayat-mat-00.txt August 2005 handoff with dual interface, overlapping area between subnets is required. Within this overlapping area if we control the timings of link layer handoffs, either at link layer by having different handoff threshold values for two interfaces or at upper layer by forcing the interfaces to connect to new subnet at different times, we can create a overlapping time that may be exploited with the above feature of MAT to reduce handoff latency. In that case interface-2 will connect to the new subnet as soon as it receives signal from new subnet, whereas interface-1 will remain connected to the previous subnet as long as the signal is receivable from previous subnet. With the assumption that a MN can force wireless network adapter to keep association with a specific Access Point (AP), it is possible that in the overlapping coverage area, one wireless adapter keeps its association with the existing AP and the other makes its association with the new AP by providing IP diversity. If the MN is within the coverage area of a single AP then only one network interface will be active. When it reaches within the coverage area of the new AP, its second interface gets the mobile IP address MAdr2 from the subnet-2 and mobile node sends the mapping information updates to the MIS having both mobile addresses with respective priorities and also alerts the CN by sending a packet with home address option (HAO). In the overlapping area the mobile node has two mobile addresses with first priority to the mobile address with subnet-1. But in the middle of the overlapping area, the priority of the mobiles addresses may be interchanged. The CN is informed by sending a packet with HAO. So CN will fetch the new mapping information from the MIS and keep communication continued. Before fetching the mapping information from MIS, CN knows the authenticated priority-2 address. So if the source address of the packets from MN is the priority-2 address, the CN does not have to authenticate the packet's source, as it already knows the tentative address. This also reduces the handoff latency When the primary direction of packets transmission is from CN to MN, handoff in MAT involves the following sequence of events: o MN having interface-1 connected to subnet-1 enters the overlapping area between subnet-1 and subnet-2. o After some time the interface-2 obtains a mobile address MAdr2 from subnet-2. o MN registers this mobile address with the MIS as standby (priority-2) address. o MN alerts the CN about this change. o CN fetches the mobile addresses from the MIS and keep the communication through priority-1 MAdr1. o When the signal strength from the subnet-2 becomes more than that of Inayat, et al Expires January 31, 2006 [Page 13] draft-inayat-mat-00.txt August 2005 subnet-1, MN gets the priorities of mobile addresses interchanged at MIS. o MN alerts the CN about this change. o CN gets the mobile addresses with new priorities from the MIS and starts sending the packets to the new MAdr2. o MN loses the connection with the subnet-A1 and updates the MIS accordingly. So during the overlapping time the MN is capable of receiving packets from both interfaces. With dual-interface handoff packets will only be lost when the overlapping time is insufficient to acquire the MAdr and to alert the CN. Whereas when the direction of transmission is from MN to CN, we can even avoid this loss by buffering the packets until the interface-2 is ready for transmission. For transmission from MN to CN, as soon as the MN changes the priority of addresses it starts sending the packets through MAdr2. So if CN receives the packet having source address MAdr2, it accepts the packet as it already has this as priority-2 address in its MIT. If it does not have MAdr2 in MIT it buffers the packet until confirming the source address from MIS because this packet must be with HAO. So CN fetches the new priorities from the MIS. With this scheme it is easy to provide constant QoS by maintaining the old reservation until the successful completion of the new one. 3.11. Communication with non-MAT nodes MAT nodes are compatible with the traditional IP nodes. When a MAT node starts communication with the traditional node, then after identifying that the target node is not a MAT node it does not perform any further MAT specific operation. When MAT node communicates with traditional nodes, it uses its current location address in the IP header (i.e., HAdr when at home network and MAdr when at foreign network). However in this case mobility is not supported. When the MAT node receives communication from a traditional node, it identifies the type of the sender node from the option with the header of first packet (IP header option in IPv4, destination option header in IPv6). If there is no home address in the IP option, it means the node is a traditional one and so MAT node behaves as a traditional node. In this case, it communicates with source address equals to its current location address and thus mobility is not supported. While communicating among MAT nodes, mobility is supported irrespective of the location of the nodes when the communication started i.e., whether they are at their home network or at a foreign network. Inayat, et al Expires January 31, 2006 [Page 14] draft-inayat-mat-00.txt August 2005 4. Packet Formats MAT can be implemented in IPv4 and IPv6 environments. For this document we describe the IPv6 packets formats only. The subsequent subsections describe the following messages of MAT and their packet formats. Mapping Information Update Request Message UDP MN -> MIS Mapping Information Update Reply Message UDP MIS -> MN Mapping Information Request Message UDP CN/MN -> MIS Mapping Information Reply Message UDP MIS -> CN/MN Mapping Information Change Alert Message IP MN -> CN Any Message between MISs (if needed) UDP MIS -> MIS 4.1. Data Packet MAT uses the normal IP header in which the home addresses are used, as node identity for the layers above the network layer, in the source and destination address fields. However for the lower layers i.e., for the routing purposes, home addresses are translated to mobile addresses depending on the node type as describe in section 3.2. Figure 6 shows the format of the normal IPv6 header. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |version| Traffic Class | Flow Label | +-------+---------------+-------+---------------+---------------+ | Payload Length | Next Header | Hop Limit | +-------------------------------+---------------+---------------+ | | + + | Source Address | + (Home Address for upper layers) + | (Mobile Address for lower layers) | + + | | +---------------------------------------------------------------+ | | + + | Destination Address | + (Home Address for upper layers) + | (Mobile Address for lower layers) | + + | | +---------------------------------------------------------------+ Figure 6: IPv6 header format 4.2. Mapping Information Update Request and Reply Messages When a mobile node moves to another subnet, i.e., when the current Inayat, et al Expires January 31, 2006 [Page 15] draft-inayat-mat-00.txt August 2005 0 0 1 2 3 0 8 6 4 1 +-->+--------+--------+--------+--------+ | | Type | code | Flags | Length | | +--------+--------+--------+--------+ | | Sequence Number | | +-----------------------------------+ | | | | + Home Address + | | | | +-----------------------------------+ | | | | + Priority-1 Mobile Address + | | | | +-----------------------------------+ | | | | + Priority-2 Mobile Address + | | | +----------------------+ | +-----------------------------------+ | IPv6 Base Header | | | | +----------------------+ | /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |Authentication Header | | | | +----------------------+ | +-----------------------------------+ | UDP Header | | | Timestamp | +----------------------+--+ +-----------------------------------+ |Mapping Update Request| | Lifetime | +----------------------+----->+-----------------------------------+ (a) Mapping Information Update Request Message +----------------------+ | IPv6 Base Header | +----------------------+ 0 0 1 2 3 |Authentication Header | 0 8 6 4 1 +----------------------+ +-->+--------+--------+--------+--------+ | UDP Header | | | Type | Code | Flags | Length | +----------------------+--+ +--------+--------+--------+--------+ | Mapping Update Reply | | Sequence Number | +----------------------+----->+-----------------------------------+ (b) Mapping Information Update Reply Message Figure 7. Mapping Information Update Request/Reply formats location of the mobile node changes, the mobile node sends the Mapping Information Update Request Message to the MIS. Upon receiving the Mapping Information Update Request Message, the MIS returns the Mapping Information Update Reply Message to the mobile node. The Mapping Information Update Request and Reply Messages are UDP packets. The Inayat, et al Expires January 31, 2006 [Page 16] draft-inayat-mat-00.txt August 2005 Authentication Header of IPv6 must be included in the Mapping Information Update Request Message to avoid illegal mapping information update. Figure 7 shows the formats of the Mapping Information Update Request and Reply Messages. Source Address: the mobile address of the source node. Destination Address: the mobile address of the destination node. Source Port: TBD. Destination Port: TBD. Type: 0x01: mapping information update request 0x02: mapping information update reply Code: 0x00: succeeded 0x01: authentication failed 0x02: ... Flags: TBD Length: specifies the length of the mapping information update request/reply message in 32 bits word Sequence Number: the source node of the Mapping Information Update Request Message assigns this field a sequence number. The same value is copied to the sequence number field of the Mapping Information Update Reply Message. Home Address: the node ID of the source node. Mobile Address: the current mobile addresses of the source node. Timestamp: the current time. Lifetime: the period of time for which this mapping information is valid. 4.3. Mapping Information Request and Reply Messages When a node tries to send a packet to a mobile node, the node sends the Mapping information Request Message to the MIS to obtain the current address of the mobile node. When the MIS receives the Mapping Information Request Message, it returns the Reply Message to the node to notify the Current addresses of the mobile node. Figure 8 shows the Inayat, et al Expires January 31, 2006 [Page 17] draft-inayat-mat-00.txt August 2005 0 0 1 2 3 0 8 6 4 1 +-->+--------+--------+--------+--------+ | | Type | code | Flags | Length | | +--------+--------+--------+--------+ | | Sequence Number | +----------------------+ | +-----------------------------------+ | IPv6 Base Header | | | | +----------------------+ | + Home Address + | UDP Header | | | | +----------------------+--+ +-----------------------------------+ | Mapping Request | | Timestamp | +----------------------+----->+-----------------------------------+ (a) Mapping Information Request Message 0 0 1 2 3 0 8 6 4 1 +-->+--------+--------+--------+--------+ | | Type | code | Flags | Length | | +--------+--------+--------+--------+ | | Sequence Number | | +-----------------------------------+ | | | | + Home Address + | | | | +-----------------------------------+ | | | | + Priority-1 Mobile Address + | | | | +-----------------------------------+ | | | | + Priority-2 Mobile Address + | | | | +-----------------------------------+ | | | +----------------------+ | /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ | IPv6 Base Header | | | | +----------------------+ | +-----------------------------------+ | UDP Header | | | Timestamp | +----------------------+--+ +-----------------------------------+ | Mapping Reply | | Lifetime | +----------------------+----->+-----------------------------------+ (b) Mapping Information Reply Message Figure 8. Mapping Information request/Reply Message format Inayat, et al Expires January 31, 2006 [Page 18] draft-inayat-mat-00.txt August 2005 format of the Mapping Information Request and Reply Messages. Source Address: the mobile address of the source node. Destination Address: the mobile address of the destination node. Source Port: TBD. Destination Port: TBD. Type: 0x03: Mapping Information request 0x04: Mapping Information reply Code: 0x00: succeeded 0x01: authentication failed 0x02: ... Flags: TBD Length: specifies the length of the mapping Information request/reply message in 32 bits word Sequence Number: the source node of the Mapping Information Request Message assigns this field a sequence number. The same value is copied to the sequence number field of the Mapping Information Reply Message. Home Address: the node ID of the mobile node. Mobile Address: the current mobile addresses of the mobile node. Timestamp: the timestamp of this mapping information. Lifetime: the period of time for which this mapping information is valid. 4.4. Mapping Information Change Alert Message We call this message as Home Address Option (HAO). This message is sent at the start of communication or whenever the mobile node changes its point of attachment. For IPv6 we use the destination option header containing the Home Address of the mobile node. This destination option header is added with the normal data packet. Upon receiving this alert, the receiving node sends the Mapping Information Request Message to obtain the new mobile addresses of the node sending the Mapping Information Change Alert message. Inayat, et al Expires January 31, 2006 [Page 19] draft-inayat-mat-00.txt August 2005 5. Processing on a Mobile Node 5.1. Bootstrap When the mobile node is powered on, it obtains the mobile addresses against its interfaces from the subnet to which it is connected after sending the Router Solicitation Message[RFC2461] and receiving the Router Advertisement Message. Next, the mobile node sends a DNS query packet to obtain the addresses of the MISs that maintain the mapping information of the mobile node. Next, the mobile node establishes a security association of IPsec[RFC2401] with the MIS. Next, the mobile node sends the Mapping Information Update Request Message to the MISs to register the current mobile addresses and receives the Mapping Information Update Reply Message. 5.2. Processing on Movement The mobile node detects the change of the point of attachment to the Internet at one of its interfaces by some mechanisms, for example, 1) interrupt by hardware, 2) upcall from the link layer, and 3) router advertisement message. When the mobile node detects a location change, first, it sends the Router Solicitation Message and receives the Router Advertisement Message. Then it obtains the mobile address from the subnet against the interface to which the mobile node is connected. Next, the mobile node sends the Mapping Information Update Request Message to the MIS to notify the current change in mobile addresses. The Mapping Information Update Request Message must follow some security procedure like including the Authentication Header. The mobile node sends the Mapping Information Change Alert Message to the correspondent nodes with which it is communicating. 6. Processing on a MIS Upon receiving the Mapping Information Update Request Message from the mobile node, first, the MIS makes it sure that the Authentication Header is correct. If authentication fails, the MIS returns the Mapping Information Update Reply Message with the error code Authentication Failed. If authentication succeeds, the MIS updates the mapping Information of the mobile node and returns the Mapping Information Update Reply Message to the mobile node. If the mobile node is associated with two or more MISs, consistency among the databases on the MISs must be kept by some procedures. One of the procedures is described in section 3.4.1. However, if a MN is associated with a large number of MISs, more refined mechanisms are required to synchronize the databases. These mechanisms are beyond the scope of this document. Inayat, et al Expires January 31, 2006 [Page 20] draft-inayat-mat-00.txt August 2005 7. Packet Transmission and Reception 7.1. Packet Transmission When the network layer receives a packet transmission request from the transport layer, the addresses passed from the TCP/UDP are always home addresses. Network layer then searches the Mapping Information Table for the mobile addresses by using the home address of the destination node as the key. If the mobile addresses are found then the network layer changes the home address to the highest priority mobile address. After that the network layer executes the normal IP transmission procedure. If the mobile addresses of the destination node is not found in the Mapping Information Table, the node keeps the packet waiting for transmission, and then sends the Mapping Information Request Message to the MIS to obtain the mobile addresses. If the source node does not know the addresses of the MISs, it obtains the MIS's address from the name server by indicating the home address of the destination node. Upon receiving the Mapping Information Reply Message, the node translate the home address to the mobile address of the destination node, and then executes the normal IP transmission procedure. This mapping information is also cached in the MIT. For the non-MAT node a dummy entry is created in MIT with home address is all the address fields. 7.2. Packet Reception When the network layer receives a packet from the link layer, first the network layer searches the MIT for the home address by using the mobile address of the source node as key. If an entry is found, the network layer translates the source address to the home address and handovers the packet to the TCP/UDP layer. If no entry is found, then the network layer checks whether the packet has home address in the destination option header. With that home address as key, first the node finds out the addresses of the MISs through DNS and then fetches the mapping information from the MIS. It then translates the source address to the home address and handovers the packet to the TCP/UDP layer. For the non-MAT node a dummy entry is created in MIT with home address is all the address fields. 7.3. Mapping Information Change Alert Message Reception When a node receives the Mapping Information Change Alert Message, it sends the Mapping Information Request Message to the MIS of the node sending the Message. If the node does not know the address of the MIS, it obtains the MIS's address from the name server by indicating the home address of the node sending the Mapping Information Change Alert message. Inayat, et al Expires January 31, 2006 [Page 21] draft-inayat-mat-00.txt August 2005 8. Scalability and Security Considerations In MAT, as there is no restriction about the numbers as well as locations of the MIS, the mapping information database system is quite flexible without any major scalability problem. Moreover MAT does not require any modification in the DNS and addressing systems. After acquiring new MAdr, MN needs to update its mapping information to the respective MISs. This potentially leaves the door open for a malicious node to hijack the network connection or to spoof the MIS database. This scenario is very similar to the security problem with the DNS. Actually in the context of security, the implementation of MIS is similar to that of DNS in the Internet. To address the problems of hijacking and spoofing, MAT suggests to use some mechanism to protect the communication as well as MIS database with shared secret key authentication between a MN and its respective MISs, when the Ipsec procedure become time costly due to high movement of the mobile node. We could use symmetric or asymmetric key algorithms, but being substantially fast, symmetric key algorithms are more suitable to MAT architecture. As MN only has to update its mapping information with a very few already known MISs, so there is no problem for key distribution. The scenario of secure relationship between CN and MIS is similar to that of CN and DNS. MAT does not provide any enhancement of security between CN and MIS more than what is provided traditionally between CN and DNS in the Internet. Thus, the vulnerability of MIS database to the malicious attacks and hijacking of communication is alleviated by making secured communication between mobile nodes and their respective MISs a must and by not allowing direct transfer of mapping information between MN and CN. The direct transfer of mapping information from MN to the CN makes the system insecure. 9. MAT and Real-time Applications MAT is specifically designed for real-time applications, particularly the applications where payload tend to be very short and thus packet header overhead becomes very significant. The mobility architectures requiring encapsulation or additional headers are not so efficient for real-time applications. Particularly in stable state i.e., a mobility scenario involving very few handoffs, these extension headers and encapsulation overheads are not required. MAT network architecture does not induce significant packet header overhead. Only at the start of communication or at the change of mapping information, the node sends the home address in the extension header. In the normal operation there is absolutely no encapsulation or additional header requirement. Inayat, et al Expires January 31, 2006 [Page 22] draft-inayat-mat-00.txt August 2005 10. Acknowledgements The authors would like to thank Mr. Takahiro Fujita of Graduate School of Engineering of Hiroshima University Japan for his invaluable input to this draft. References [IEICE04] R. Inayat, R, Aibara, K. Nishimura, T. Fujita, and K. Maeda. An End-to-End Network Architecture for Supporting Mobility in Wide Area Wireless Networks. IEICE Transactions on Communications, Vol. E87-B, No.6, pp. 1584-1593, June 2004. [IJWOC03] R. Inayat, R. Aibara, K. Nishimura, T. Fujita, Y. Nomura, and K. Maeda. Realizing fast Mobility and Multi-homing Support in Wireless access Networks. International Journal on Wireless and Optical Communication, Vol. 1, No.2, pp. 123-146, December 2003. [SAINT04] Riaz Inayat, Reiji Aibara, Kouji Nishimura, Takahiro Fujita, and Kaori Maeda. Realizing High Mobility through an End-to-End Network Architecture with IP Diversity Support for Real Time Internet Applications. Proceeding of 2004 Symposium on Applications and the Internet (SAINT 2004): Tokyo, Japan, pp. 243-249, January 26-30, 2004. [RFC2401] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401, November 1998. [RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, IETF, December 1998. [RFC3344] Charles E. Perkins. IP mobility support for IPv4. RFC 3344, IETF, August 2002. [RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775, IETF, June 2004. Inayat, et al Expires January 31, 2006 [Page 23] draft-inayat-mat-00.txt August 2005 Author's Address o Riaz Inayat Pakistan Telecommunication Company Limited (PTCL), Technologies and Standards Wing, CDDT Building, PTCL H/Qs, H-9/1, Islamabad, Pakistan. Phone: +92-51-443-1191 Email: riaz.inayat@ptcl.net.pk o Reiji Aibara Information Media center, Hiroshima University, 1-4-2 Kagamiyama, Higashi-Hiroshima, Hiroshima, 739-8511, Japan. Phone: +81-82-424-6258 Email: ray@hiroshima-u.ac.jp o Kouji Nishimura Information Media center, Hiroshima University, 1-4-2 Kagamiyama, Higashi-Hiroshima, Hiroshima, 739-8511, Japan. Phone: +81-82-424-6252 Email: kouji@hiroshima-u.ac.jp o Kaori Maeda Information Processing Center, Hiroshima City University, 3-4-1 Ozuka-Higashi, Asa-Minami-Ku, Hiroshima, 731-3194, Japan. Phone: +81-82-830-1655 Email: kaori@ipc.hiroshima-cu.ac.jp o Yasunori Sugimoto Network Technology & Product Operations, Net One Systems Co., Ltd., IS BLDG., 3-32-42 Higashi-Sinagawa, Shinagawa-Ku, Tokyo, 140-002, Japan. Phone: +81-3-5462-0821 Email: y-sugimoto@netone.co.jp Inayat, et al Expires January 31, 2006 [Page 24] draft-inayat-mat-00.txt August 2005 Intellectual Property Statement 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 ietf-ipr@ietf.org. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Inayat, et al Expires January 31, 2006 [Page 25]