INTERNET-DRAFT Subrata Goswami Expires August 06, 2005 February 7,2005 IPv4 Mobility through Peer Signaling Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 monthsand may be updated, replaced, or obsoleted by other documents at anytime. 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. Copyright Notice 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." "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." Abstract This document describes a way to perform mobility in IPv4 (potentially IPv6) without requiring any new entity in networks Goswami 1 IPv4 Mobility through Peer Signaling February 2005 infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of using infrastructure entities this method delegates all the mobility function to the end nodes. The method relies on source and destination address translation at the end nodes, and signaling between end nodes to perform hand offs - all these function can be encapsulated in an entity called Mobility Agent (MA) in the end nodes. 1. Overview and Rationale Mobile IPv4 [MIP4] protocol makes use of 2 new entities per subnet, Home Agent (HA) and Foreign Agent (FA). In addition, the mobile end node (MN) needs to be instrumented. HA and FA, by being routers requires substantial resources [Mipv4Ana]. Moreover the legacy end nodes need to upgraded for Mobile IPv4. In this draft a new method is proposed that involves a single agent, called Mobility Agent (MA), in each end node that performs the functions of routing and signaling for mobility. The end nodes in IP networks tend to be computers with fair amount of resources ( probably an effect of the end-to-end principle of IP). In recent years for security reasons the end nodes have been forced to be upgraded rapidly - which has resulted in streamlined process and delivery infrastructure for software upgrades. Hence upgrades of endnode is no longer a daunting task that once it used to be. Most end nodes permit some software based approaches to modify traffic between the IP stack and the interface (e.g NDIS in Windows, Netfilter in Linux , etc). Hence inserting a Mobility Agent below the IP stack is straight forward process. 2. Network Architecture A hypothetical IP network is shown in the following figure. The mobile client MN can move from subnet X1 to X2 while connected to CN ( for sake of brevity it is considered to be static). [MN/MA] -----[X1]----------- | | [Internet]----[CN/MA] v | ----[X2]----------- Goswami 2 IPv4 Mobility through Peer Signaling February 2005 [MN] - Mobile Node [CN] - Correspondent Node [MA] - Mobility Agent [X] - IP Router Figure 1: IP Network When the MN moves from X1 to X2, its IP address will change, from say ipx1 to ipx2, which would result in the following. The CN would still use ipx1 as destination address for all outgoing packets, which would result in all packets sent to subnet X2. CN also will look for ipx1 at source address for any previously setup transport protocol sessions (e.g TCP or UDP, as SCTP accommodates multi- homing there might be ways to handle such changes). On the MN side,it now has a new IP address, ipx2, but transport protocols are still using ipx1, hence no packet will go out of MN. The MA, hides these address changes from transport protocols and does an on the fly translation of src and dst IP addresses of similar to NAT. 3. Signaling Message Sequence The following figure shows the what happens when MN move from X1 to X2. After detecting subnet change, MN (though the resident MA ) sends a Subnet Change request message to CN. How subnet changes are detected is beyond the scope of this document. The CN ( again through the resident MA) sends a Change Challenge Request message to both old and new addresses. On receiving this challenge request, the MN send a response message. Now, if the CN receives two responses from the old and the new IP addresses, then it considers the request as spoofed and sends a Request Denied response to X1 subnet. MN(X1) MN(X2) CN <----------------- data --------------------> ---- (move) --- (detect sunbet change) ----- Subnet Change Request -->--- ----- Subnet Change Chlg. Req -<-- AND Goswami 3 IPv4 Mobility through Peer Signaling February 2005 ------------------ Subnet Change Chlg. Req -<-- ----- Subnet Change Chlg. Rsp.->-- ------------------ Subnet Change Chlg. Rsp.->-- (implies spoofing) ----- Subnet Change Response --<-- (Request Allowed) OR ------------------ Subnet Change Response --<-- (Request Denied, spoofed) <---- data --------------------> Figure 2. Signaling Message Sequence 4. Signaling Message Format The signaling messages have the following format as described in detail below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CN Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... | | ( variable length ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Signaling Message Format 4.1 Subnet Change Request Goswami 4 IPv4 Mobility through Peer Signaling February 2005 This message is sent from MN to a CN after detection of subnet change has been made. The Type field contains 1. The Initial IP Address is the IP address seen by the transport layer. The New IP Address is the new IP address obtained by the MN interface. The CN address field is copied from the Destination Address of the IP header. The New IP address should match the IP address of the interface through which the message is going out. The identification field is a 64 bit field supplied by the CN to the MN. This should be set to 0 when the MN does not have one. 4.2 Subnet Change Allowed This message is sent from CN to an MN after a Subnet Change Request has been made. The Type field is 2. The Initial and New Address fields contain the corresponding IP addresses of the MN as in the request message. The CN address field is the address of the CN interface through which the Subnet Change Request message came in. The identification field is a 64 bit field supplied by the CN to the MN. This should be a new number generated by CN when the Subnet Change Request Identification field is 0. The MA in CN should check for if it has all ready provided an identification to the Initial IP address of the MN. This message is sent to the New IP address. 4.3 Subnet Change Denied This message is sent from CN to an MN after detection of Subnet Change Request has been made. The Type field is 10. The Old and New Address fields contain the corresponding IP addresses of the request message. The CN address field is the address of the CN interface through which the Subnet Change Request message came in. The identification field is a 64 bit field supplied by the CN to the MN. This should be a new number generated by CN when the Subnet Change Request Identification field is 0. The MA in CN should check for if it has all ready provided an identification to the Old IP address of the MN. This message is sent to the New IP Address stored in the CN for the corresponding Initial IP Address 4.4 Subnet Change Challenge Request (To be described.) 4.5 Subnet Change Challenge Response (To be described.) The transport protocol for signaling messages for the Peer Mobility method can be UDP based or ICMP based (To be described). 5. Mobility Agent in IP End Nodes Goswami 5 IPv4 Mobility through Peer Signaling February 2005 A Mobility Agent (MA) is resident in both the mobile node and the correspondent node that participates in IPv4 mobility. 5.1 Location of the Mobility Agent. The MA could be resident between the Transport Layer and the Network Layer or between the Network Layer and the Link Layer. It is more popular and there exists well known interfaces to place extensions between the Network Layer and the Link Layer of an IP end node. Hence we will consider implementation implication for this approach. The following figure shows a logical view of such an MA. Transport Layer (TCP/UDP) | IP Stack --- (Routing Table) | Mobility Agent --- (Translation Table) | Interface --- (ARP Cache) | MAC | PHY 5.2 Mobility Agent State Machines CN Signal Handling [Start]<------------------------------------------| | | | (Subnet Change Request Message) | | | [Challenge Request ]--error ->-----------------------| | | | (Subnet Change Challenge Resp) | | | [Update Translation Table]---------------------------| MN Signal Handling Goswami 6 IPv4 Mobility through Peer Signaling February 2005 [Start]<------------------------------------------| | | | (Movement Detection) | | | [Update Translation Table ]--error ->----------------| | | | (Subnet Change Challenge Request) | | | [Challenge Response ]--error ->----------------------| | | | (Subnet Change Allowed) | | | [Update Translation Table]---------------------------| CN/MN Packet Handling [Start]<------------------------------------------| | | | ( Receive IP packet) | | | [Translate IP addresses] --error ->[Error Msg. toTransport]-| | | | | | | [Send IP Packet to Layer 2 Interface]------------------| 5.3 Mobility Agent Translation Table The MA maintains a logical table that supports IP address translations. The following figures shows the essence of such a table. Trans IP | New IP | Identification | Interface| --------------------------------------------------- ip1 | ipn1 | xxxxxx | if0 The Translation Table contains the following IP addresses: i. The Tranport Layer IP Address. ii. The Transport Layer Gateway IP Address. iii. The Transport Layer DNS Server IP Address. ii) and iii) are required because the transport layer is unaware of any change in the IP subnet. The Routing Table willl contain the Transport IP Addresses, whereas the ARP Cache will contain the New IP addresses. Goswami 7 IPv4 Mobility through Peer Signaling February 2005 6. Security Considerations Spoofing of Subnet Change Request has been handled by sending Subnet Change Challenge request Message to both Old and New subnets. 7. IANA Considerations This method specifies several new number spaces for values to be used in various message fields. These number spaces include the following: 8. Acknowledgments 9. References [MIPv4] Perkins, C., "IP Mobility Support IPv4, revised", RFC 3344bis, June 2004. [MIpv4Ana] IETF, draft-goswami-mobileip-analysis-v4-00.txt, September 2002. 10. Author's Address Subrata Goswami, Ph.D. Fremont, CA 94539 sgoswami@umich.edu This document expires August 07, 2005. Goswami 8