Linux Based Implementation and Performance Measurements of Dual Stack Mobile IPv6

Linux Based Implementation and Performance Measurements of Dual Stack Mobile IPv6 CHAMAN SINGH 1 K.L.BANSAL 2 1 Assistant Professor 2 Associate Professor chaman83mca@gmail.com kishorilalbansal@yahoo.co.in 1 Department of Computer Application, Govt. P.G.College, Chamba H.P. India 176310 2 Department of Computer Science, Himachal Pradesh University Shimla, India 171005 Abstract Today is age of mobiles. It is observed that current technology cannot provide the proper way of communication. Peoples are used mobile phones, other connected and wireless devices for communication. Whenever they go from one network to other packets are not transfer properly between home agents and mobile nodes so the solution is required for that. If we are calling to someone and if at the same time cross the home network, call ends so for the better network connection and continues flow of messages, problem should be executed. If any mobile node (MN) goes from Internet Protocol Version 4.0 (IPv4) Network to Internet Protocol Version 6.0 (IPv6) Network there is no problem for the communication with its home agent. What when an IPv6 MN goes from IPv6 network to IPv4 network there is problem for communication with home agent. So Network Address Translation is required at the link of IPv4 foreign Network so that there is no delay for the packets that are transmitting between MN and Home Agent (HA). There should be regular and uniform communications. Some firewalls block traffic based on the direction of their flow. They do not allow packets from outside the network to come inside, without any of the internal systems requesting for the same. But the very idea of IP Mobility is to allow anyone from outside to call anyone inside the network. So, in such cases Network Address Translation/Firewall traversal is required selectively. Keywords-Network Address Translation, Traversal, Detection, IP Security, Data Traffic, Linux Kernel, Mobility, DSMIPv6, Implementation. 1. Motivation Middleboxes [1], such as Firewalls (FW) and Network Address Translators (NAT) [2], are an important component for a majority of Internet Protocol (IP) [3] networks today. Current IP networks are predominantly based on IPv4 [3] technology, and hence various firewalls as well as NATs have been originally designed for these networks. NATs are necessary to overcome the IPv4 address space limitations of many network domains, firewalls are common to protect systems and networks against unsolicited traffic and attacks from the outside network, in particular the Internet. Middleboxes normally work on transport and higher layers and are not part of the traditional end-to-end Internet architecture. Deployment of IPv6 [4] networks is currently work in progress. However, some firewall products for IPv6 networks are already available [5]. It is foreseen that firewalls will become an indispensable device for protecting against unwanted traffic in operational IPv6 networks, especially in enterprise environments. Current trends observed worldwide with respect to Internet growth show that the number of connected users is growing very fast. And while the IPv6 deployment is slowly taking off, there can be a present need for advanced features promised by next generation protocols. Especially, in the same way as Network Address Translation (NAT) allows a host to provide global connectivity to a whole net- work albeit with restrictions, Network Mobility Basic Support (NEMO BS [6]) allows a router with a single address to provide mobility agnostic end-to-end access to all attached nodes. In NEMO BS, the mobility management operations are handled by the mobile network router known as the Mobile Router (MR). While moving from one access network to another, the MR maintains an IPv6- in-ipv6 tunnel with a remote fixed node called the Home Agent (HA). Both the MR and the HA maintain a relation between a permanent IPv6 address assigned to the MR (called the Home Address or HoA) and a temporary address (the Care-of Address or CoA) that the MR gets along with its movement in each foreign network. This relation is maintained through the usage of the Binding Update (BU) and Binding Acknowledgment (BAck) messages regularly exchanged between the MR and it s HA. All network movements are therefore transparent to the nodes located in the mobile network, the MR and the 240

HA performing the necessary operations to route packets destined to or originated from the mobile network. However, in its current state, NEMO Basic Support is restricted to pure IPv6 operation, whereas only few modifications would allow it to operate using an IPv4 CoA directly. This is under standardization at the IETF under the name Mobile IPv6 support for dual stack Hosts and Routers or DSMIPv6 [7]. Using an IPv4 CoA allows many pioneering scenarios like the rapid deployment of a whole network in emergency situations, with very few requirements apart from a basic IPv4 access, even using NAT, because DSMIPv6 specifies a NAT traversal mechanism. Mobile IPv6 (MIPv6) is a protocol developed as a subset of Internet Protocol version 6 (IPv6) [8] to support mobile connections. MIPv6 [9] allows a mobile node to transparently maintain connections while moving from one subnet to another. The Mobile IPv6 protocol takes care of binding addresses between Home Agent (HA) and Mobile Node (MN). It also ensures that the Mobile Node is always reachable through Home Agent. Each mobile node is always identified by its home address [10], regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagram s destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. Deploying both in a dual stack mobile node introduces a number of problems. This has been improved [11]. Mobile IPv6 uses IPSec (IP Security) to protect signaling between the home agent and the mobile node [12]. Generic Packet Tunneling [13] Specifies a method and generic mechanisms by which a packet is encapsulated and carried as payload within an IPv6 packet. The current Mobile IPv6 [14] and Network Mobility [15] specifications support IPv6 only. These extend those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the Home Agent. [7] Allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. Dual Stack Mobile IPv6 (DSMIPv6) is an extension of MIPv6 to support mobility of devices irrespective of IPv4 [9] and IPv6 [10] network. The impact to IPv4, which changes IP address semantics, provide ample evidence, since now coming time MIPv6 are in progress so need of network address translation traversal and detection on dual stack implementation of mobile IPv6. Unless NATs are aware of Mobile IPv6 protocol details, they will have to either block Mobile IPv6 communication traffic, or carefully deal with the traffic per-connection, or allow this traffic in general through manual pre-conjunction. This could be a major impediment to the successful deployment of Mobile IPv6 using linux platform on C.NEPL [16] (NEMO Platform for Linux) is a freely available implementation of DSMIPv6 for Linux platform. The original NEPL release was based on MIPL [17] (Mobile IPv6 for Linux). XFRM is a packet transformation framework residing in the Linux kernel. It performs operations on IP packets such as inserting, modifying headers, UDP encapsulation and Decapsulation. To overcome the problems, it requires the usage of a middlebox configuration solution. 2. Review of Literature The transition from IPv4 to IPv6 is a major event that touches all aspects of a corporation s information systems. As such, there has been much literature written identifying the best methodologies to transition systems to the new routing protocol. Additionally, much literature has also been written outlining issues that corporations will inevitably face in making the transition. The literature reviewed for this research provides the necessary background information, key concepts, and issues surrounding the transitioning from IPv4 to IPv6 to Mobile IPv6 and various techniques to the solution up to now. There are several underlying concepts that can be found in the majority of literature reviewed for this book. These concepts include, but are not limited to, Internet protocols, Mobile IPv6 benefits and transition methodologies. The Internet Protocol is the method of transporting data across the Internet. It specifies an addressing scheme as well as the format of data packets. This combined with the Transmission Control Protocol (TCP) provides a connectionless virtual connection between a source and destination. IPv4 is the current most widely used specification of the Internet Protocol used on the Internet today. It was developed by the Defense Advanced Research Projects Agency (DARPA) in 1981 under the Internet Engineering Task Force (IETF) Request for Comments (RFC) 791 (University of Southern California, 1981) [18]. The specification provides a 32-bit address format, which uniquely identifies 4.3 billion addresses. IPv6 is the next generation of the Internet Protocol specification based upon the IETF RFC 2460 [19]. The specification provides a 128-bit address format, which uniquely identifies 3.4 X 10 38 addresses. Due to the lack of mobility support, packets intended to such a moving Mobile Node (MN) would never reach the mobile node while it is away from the home network. The mobile node could change its IP address each time it moves to a new point-of-attachment. However, in this case the mobile node would not be able to maintain already 241

established transport-layer connections. Mobile IPv6 (MIPv6) developed by the IETF Mobility for IPv6 working group [MIP6], is a protocol developed in 2004 as an extension of IPv6 to support node mobility. Mobile IPv6 is an update of Mobile IP [12], which was designed for IPv4 node mobility, and adds roaming capabilities of mobile nodes into IPv6 networks. While the mobile node is away from its home network and attached to a foreign network, it maintains at least one Care-of Address (CoA). The care-of address is an IP address with the subnet prefix of the foreign network and addresses the mobile node in the foreign network. This care-of address can for example be derived through IPv6 auto-configuration. While the mobile node is staying in the foreign network, packets addressed to the care-of address will be routed to the mobile node. Figure 1 depicts how Mobile IPv6 works. To be able to forward packets to the mobile node while it is not in the home network, a so called Binding between the mobile node's home address and the careof address is created. While the mobile node is away from home, for example, if the mobile node moves to a foreign network (black line in Figure 1), a node on its home link is taking care of packets address to the mobile node's home address. This node is called Home Agent (HA). When the mobile node receives a new care-of address, it associates the care-of address with its home address by performing a binding registration with the home agent. This is done by sending a Binding Update (BU) message to the home agent. The home agent replies to the mobile node with a Binding Acknowledgement (BA) message, which finishes the binding registration. The home agent now intercepts packets addressed to the mobile node's home address and forwards them using an Internet Protocol Security (IPsec) [20] Encapsulation Security Protocol tunnel to the mobile node's care-of address. The mobile node could also send a Binding Update to a potential correspondent node to update the correspondent nodes binding cache. In this mode, packets from the correspondent node to the mobile node are routed to the home agent who tunnels them to the mobile node by performing IPv6 encapsulation [21]. Packets from the mobile node to the correspondent node are tunneled to the home agent, so called Reverse Tunneled, and than routed to the correspondent node. The lines in Figure 1 represent the packets being sent in this mode. The second mode, called Route Optimization, requires the correspondent node to support Mobile IPv6. Here, the mobile node registers its current binding also to the correspondent node, thus the correspondent node is able to address packets directly to the mobile node's care-of address. This direct communication between the mobile node and correspondent node allows using the shortest path and rapidly decreases the traffic at the home agent. Although several sources of literature were reviewed for this report, certain works are significant in that they are continuously referenced throughout the majority of other literature reviewed. IP Version 6 Addressing Architecture (Deering and Hinden, 1998a) [19]. This document, known as RFC 2373, defines the IPv6 addressing model. Figure-1: Basic Operation of DSMIPv6 It explains, in great detail, the components of the 128-bit IPv6 address and how to reference the textual representation of the address. Internet Protocol DARPA Internet Program Protocol Specification (University of Southern California, 1981)[41]. This document is formally known as RFC 791 and is the official specification of IPv4Internet Protocol, Version 6 (IPv6) Specification (Deering and Hinden, 1998b) [22]. This document is often referred to as RFC 2460 and contains the formal specification of the IPv6 protocol. It provides all the technical details of an IPv6 packet. In addition, it defines all the fields of the IPv6 header as well as their possible values and meanings Connection of IPv6 Domains via IPv4 Clouds (Carpenter and Moore, 2001) [23]. This document, known as RFC 3056, outlines the tunneling approach to the transition Methodology. It provides several network scenarios and guidance on how IPv6 packets can be tunneled across an IPv4 network. Carpenter and Moore (2001) make it clear that the approach is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6 Zao and Condell discuss the use of IPSec over Mobile IP for HA-MN, HA-FA, CN-HA, CN-FA, and MN-CN connections (HA: home agent, FA: foreign agent, CN: 242

correspondent node, MN: mobile node) [24]. IPSec is used to replace IP-IP-tunneling. Adaptations to Mobile IP messages are proposed for coping with IPSec tunnel establishment. Special IPSec tunnel extensions are added to advertisements and registration messages. Binkley and Richardson [25] describe how a secure firewall protected area may tolerate Mobile IP or mobile systems using DHCP only and remain secure. They propose to use bidirectional IPSec tunnels between the home agent as a classic bastion host and the mobile node [26]. A secure mobile networking concept has been proposed that is based on ad-hoc networking and secure bi-directional IPSec tunnels. The standard Mobile IP scenario is treated as a special ad-hoc routing case where home agent and mobile node build a secure ad-hoc network. Considering the IP mobility problem as a special case of the general ad-hoc networking problem is a nice idea, but may be too complex for the goal to secure a Mobile IP environment only. Gupta and Montenegro describe enhancements enabling Mobile IP operation in a network, which is protected by a combination of source-filtering routers, sophisticated firewalls, and private address space [27]. These enhancements should allow a mobile user in the public Internet to maintain a secure virtual presence within his firewall-protected office network. The authors propose to use SKIP [28] for key management, authentication and encryption. The reason why they chose SKIP instead of ISAKMP/Oakley [29], is SKIP s ability to look up the sender s public key based on alternate names, while this is done with source addresses in the case of ISAKMP/Oakley. The concept of a secured Mobile IP seems to be an easy and efficient way to solve Mobile IP security problems, but it requires introducing new protocols. Pahlke et al. propose the deployment of special gateways that include any security (e.g., firewall) and foreign agent functionality in the same node [30]. IPSec tunnels are established among those nodes in order to achieve security. The approach allows leaving mobile nodes unchanged but requires the presence of those nodes in any visited network. In addition, securing a wireless link requires link-level mechanisms leading to possibly duplication of encryption. When roaming in IPv4 networks, the Mobile IPv4 HoA is translated to a 6to4 address used as a CoA to register to the HA. All the IPv6 traffic originated from or destined to the MN then transits through the tunnel operated by Mobile IPv4. This solution results in a large header overhead due to the three encapsulations needed to transport the IPv6 packets from the node to the Mobile IPv6 HA. Furthermore, this solution does not consider the continuity of the IPv4 service when roaming in IPv6 networks. None of the solutions described so far considers the continuity of both IPv6 and IPv4 sessions whatever the IP version in the network where the MN roams in is operated. The Mobile IPv6 support for dual stack Hosts and Routers specification (DSMIPv6 [3]) presented in the next section is currently discussed at the IETF1 as a single protocol that ensures a very flexible management of both IPv4 and IPv6 mobility in either IPv4-only or IPv6-only or dual stack networks. 3. Problem Statement and Methodologies IPv4 private networks are behind NAT devices. So, to bypass the Binding Update and Binding Acknowledgment by NAT, we need to encapsulate it in UDP packets. So, the dual stack mobile IPv6 should support NAT traversal and Detection. Since Internet Protocol Version 6.0 (IPv6) deployments is slowly taking off and it is not properly deployed in all places where there is Internet Protocol Version 4.0 (IPv4) Network. There is a present need for advanced features promised by next generation protocols. During the transition towards Internet Protocol Version 6.0 (IPv6), Network Address Translation traversal for existing private Internet Protocol Version 4.0 (IPv4) networks needs to be considered. So Network Address Translation detection and traversal is necessary for that. Assume that Home Agent (HA) and mobile node (MN) are Internet Protocol Version 4.0 (IPv4) and Internet Protocol Version 6.0 (IPv6) enabled and that only MIPv6 is used between the mobile node (MN) and Home Agent (HA).When mobile node (MN) behind a Network Address Translation that means mobile node (MN) is in a private Internet Protocol Version 4.0 (IPv4) foreign Network that has a mobile device connecting to it to the internet. If the Home Agent (HA) is located outside the Network Address Translation device, the mobile node (MN) will need a Network Address Translation traversal mechanism to communicate with the Home Agent (HA). For the proper communication of house agent and mobile node so that uniformity maintained, network address translation detection is required. In Internet Protocol Version 4.0 (IPv4)-only foreign networks scenario, a mobile node is connected to an Internet Protocol Version 4.0 (IPv4)-only foreign networks. The mobile node can only configure an Internet Protocol Version 4.0 (IPv4) Care-of Address. In Mobile node behind a Network Address Translation scenario, the mobile node is in a private Internet Protocol Version 4.0 (IPv4) foreign networks that have a Network Address Translation device connecting it to the Internet. If the Home Agent is located outside the Network Address Translation device, the mobile node will need a Network Address Translation traversal mechanism to communicate with the Home Agent. IPv6 offers a number of improvements over today's IPv4, primarily due to its large address space. Mobile IPv6 offers a number of improvements over Mobile IPv4, mainly due to capabilities inherited from IPv6. For instance, route optimization and dynamic home agent discovery can only be achieved with Mobile IPv6. One of the advantages of the large address 243

space provided by IPv6 is that it allows mobile nodes to obtain a globally unique care-of address wherever they are. Hence, there is no need for Network Address Translator (NAT) traversal techniques designed for Mobile IPv4. This allows Mobile IPv6 to be a significantly simpler and more bandwidth efficient mobility management protocol. At the same time, during the transition towards IPv6, NAT traversal for existing private IPv4 networks needs to be considered. This specification introduces NAT traversal for this purpose. The above benefits make the case for using Mobile IPv6-only for dual stack mobile nodes as it allows for a long lasting mobility solution. The use of Mobile IPv6 for dual stack mobility eliminates the need for changing the mobility solution due to the introduction of IPv6 within a deployed network. DSMIPv6 [7] extends the Mobile IPv6 [10] and NEMO [9] Basic Support standards to allow MNs to roam in both IPv6 and IPv4-only networks. For that purpose, it defines several interesting features: The MN can register an IPv4 CoA to its HA and thus roam in IPv4-only networks by the use of IPv6-in- IPv4 tunnels between the MN and its HA. The MN can use an IPv4 HoA to be used with its applications when communicating with IPv4-only correspondents. The MN can thus get free use of a translator, and benefit from end-to-end IPv4 communication. A NAT detection and traversal mechanism allows the MN to communicate with it s HA even though it uses an IPv4 private address as a CoA. When the MN is located behind a NAT, signaling and data are encapsulated in UDP and IPv4. In the case of network mobility, the MR can request an IPv4 prefix to be advertised in its mobile network, hence providing IPv4 connectivity to its MNNs, even though the mobile network is roaming in an IPv6-only network. 3.1 Scenarios consider by this Problem There are several scenarios that illustrate potential incompatibilities for mobile nodes using Mobile IPv6. Scenario 1: IPv4-only foreign network In this scenario, a mobile node is connected to an IPv4- only foreign network. The mobile node can only configure an IPv4 Care-of Address. Scenario 2: Mobile node behind a NAT In this scenario, the mobile node is in a private IPv4 foreign network that has a NAT device connecting it to the Internet. If the home agent is located outside the NAT device, the mobile node will need a NAT traversal mechanism to communicate with the home agent. Scenario 3: Home Agent behind a NAT In this scenario, the communication between the mobile node and the home agent is further complicated by the fact that the home agent is located within a private IPv4 network. However, in this scenario, we assume that the home agent is allocated a globally unique IPv4 address. The address might not be physically configured on the home agent interface. Instead, it is associated with the home agent on the NAPT device, which allows the home agent to be reachable through address or port mapping. Scenario 4: Use of IPv4-only applications In this scenario, the mobile node may be located in an IPv4, IPv6 or a dual network. However, the mobile node might be communicating with an IPv4-only node. In this case, the mobile node would need a stable IPv4 address for its application. The alternative to using an IPv4 address is the use of protocol translators; however, end-to-end communication with IPv4 is preferred to the use of protocol translators. The mobile node may also be communicating with an IPv4-only application that requires an IPv4 address. The cases above illustrate the need for the allocation of a stable IPv4 home address to the mobile node. This is done using an IPv4 home address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is problematic (as illustrated in [11]), this scenario adds a requirement on Mobile IPv6 to support IPv4 home addresses. Scenario 5: IPv6 and IPv4-enabled networks In this scenario, the mobile node should prefer the use of an IPv6 care-of address for either its IPv6 or IPv4 home address. Normal IP in IP tunneling should be used in this scenario as described in [10]. Under rare exceptions, where IP in IP tunneling for IPv6 does not allow the mobile node to reach the home agent, the mobile node follows the sending algorithm. UDP tunneling in IPv6 networks is proposed in this document as a last resort mechanism when reachability cannot be achieved through normal IP in IP tunneling. It should not be viewed as a normal mode of operation and should not be used as a first resort. Any solution that allows these messages to successfully traverse and Detect NAT between the Mobile IPv6 nodes is generally applicable for Mobile IPv6 traversal and Detection. Therefore, any proposed solution presented in this book handle these cases in detail and thus show it applicability to overcome the described problems. In order to allow Mobile IPv6 to be used by dual stack mobile nodes, the following needs to be done: Mobile nodes should be able to use an IPv4 and IPv6 home or care-of address simultaneously and update their home agents accordingly. Mobile nodes need to be able to know the IPv4 address of the home agent as well as its IPv6 address. There is no need for IPv4 prefix discovery however. Mobile nodes need to be able to detect the presence of a NAT device and traverse it in order to communicate with the home agent. 244

3.2. Home Agent Discovery Dynamic home agent Address Discovery (DHAAD) was defined in [10] to allow mobile nodes to discover their home agents by appending a well-known any-cast interface identifier to their home link's prefix. 3.3. Mobile Prefix solicitation and Advertisement According to [RFC3775] [10], the mobile node can send a Mobile Prefix Solicitation and receive a Mobile Prefix Advertisement containing all prefixes advertised on the home link. 3.4. Binding Management A dual stack mobile node will need to update its home agent with its care-of address. If a mobile node has an IPv4 and an IPv6 home address, it will need to create a binding cache entry for each address. The format of the IP packet carrying the binding update and acknowledgement messages will vary depending on whether the mobile node has access to IPv6 in the visited network. There are three different scenarios to consider with respect to the visited network: The visited network has IPv6 connectivity and provides the mobile node with a care-of address (in a stateful or stateless manner).the mobile node can only configure a globally unique IPv4 address in the visited network. The mobile node can only configure a private IPv4 address in the visited network. 3.4.1. Foreign Network Supports IPv6 In this case, the mobile node is able to configure a globally unique IPv6 address. The mobile node will send a binding update to the IPv6 address of its home agent, as defined in [RFC3775] [10]. 3.4.2. Foreign Network Supports IPv4 Only If the mobile node is in a foreign network that only supports IPv4, it needs to detect whether a NAT is in its communication path to the home agent. This is done while exchanging the binding update and acknowledgement messages as shown later in this document. NAT detection is needed for the purposes of the signaling presented in this specification. 3.4.2.1. Foreign Network Supports IPv4 Only (Public Addresses) In this scenario the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. The mobile node uses the IPv4 address it gets from the foreign network as a source address in the outer header. 3.5. Research Methodologies The methodology followed in this book is a case study followed by selection. That is Dual Stack Mobile IP is first studied as a whole and focus is made on its implementation and NAT Detection & Traversal for proper data communication. In proposing the solution, different possible ways of solving the problem are investigated and the one which is straightforwardly to satisfy our objective is selected, designed and implemented. The Test Lab has been evaluated against the use case scenarios making sure that all the requirements specified have been met. To arrive at conclusion test cases are stated and tests are conducted with each scenario. The following main architectures are used for implementation:- 3.5.1 UMIP UMIP is a set of patches for the MIPL2 software suite developed by the USAGI Project [31]. MIPL2 (Mobile IPv6 for Linux) [17] is an open-source implementation of the Mobile IPv6 standard for the GNU/Linux operating systems. UMIP aims at providing the necessary changes to MIPL2 in order to run on the latest kernels while improving the software to respect the standards. DSMIPv6 implementation is based on UMIP with the NEPL extension that enables the operation of the NEMO BS protocol. It runs on a 2.6.28.2 Linux kernel, one of the latest stable kernels available on GNU/Linux. The figure 3.0 roughly presents the current design of our [17] DSMIPv6 extensions for UMIP. The implementation extends both the Kernel and Userland code, as detailed in the next chapters. 3.5.2 XFRM XFRM [32] is a packet transformation framework residing in the Linux kernel. It allows performing operations on IP packets such as inserting or modifying headers. This framework is for example used by UMIP to insert Destination Option and Routing Headers in the Mobile IPv6 signaling messages (BU, BAck, etc.) and add the necessary headers for IPsec. The DSMIPv6 specification defines a NAT detection and traversal mechanism based on UDP encapsulation of the signaling and data packets. The best way to perform the UDP encapsulation is to extend XFRM to serialize this operation after all other transformations. This is especially true because IPsec transformations are already defined as XFRM transformations, which would make a Userland implementation of UDP encapsulation more difficult. We thus defined an additional XFRM transformation that takes advantage of the existing framework and defines a simple UDP encapsulation scheme. For the transmission part, packets matching specific requirements (e.g. the BU or even data packets in case of NAT traversal) are handled by adding extra room in front of the packet. This room is then filled with necessary IPv4 and UDP headers so that the previous packet is really the payload of the new UDP packet. This new packet is then handled to the UDP network code that is going to perform destination lookup and proceed with the transmission. As for the reception part, packets received on the DSMIPv6 UDP port that is defined in the specification (currently to be assigned by IANA) get processed by the transformation input routine. The IPv4 and UDP headers are separated from the payload which turns into a new IPv6 packet. At that point, NAT detection is started by copying the outer IPv4 source 245

address of the packet to a dedicated field inside the packet buffer of the newly built IPv6 packet. This new IPv6 packet is then re-submitted to the network stack as a regular IPv6 packet, except that it has NAT detection information attached. From then on, the packet follows the same path as regular packets that would have come from a native IPv6 network. The NAT information is then available for processing within the Userland. It is going to be used for comparison with the contents of the IPv4 CoA option inside the BU message on the HA. If both addresses differ, it means that IPv4 source address has been rewritten on the path by a NAT device. 3.5.3 Userland Design The UMIP Userland takes care of the movement detection, the binding management, the signaling and error processing. It also interacts with the kernel to create IP tunnels, manage the routes towards those tunnels, and add the necessary XFRM policies and states for IPsec and signaling messages transformation. Details about the implementations are described below: The movement detection module has been extended to detect roaming in IPv4 networks on the MN. A light DHCP client based on DHCP6 and triggered by a DNA [92] module (or when booting in an IPv4-only network) allows to get an IPv4 CoA when located in an IPv4 access network. The movement decision algorithm has to take into account the fact that IPv6 CoAs always have the priority upon IPv4 ones. This could be made possible by a separation of DHCP states and interface configuration. Whenever a lease is obtained, the IPv4 CoA should not be set on the interface unless no IPv6 router has been found on the link. The IPv4 CoA is stored in an IPv6-mapped address format and thus requires minimum changes to the data structures (such as the Binding Update List or the Binding Cache entries). Upon an IPv4 movement event on the MN, the Userland installs XFRM policies and states in the kernel for UDP encapsulation of the BU. The HA has similar rules to Decapsulation the packet and perform NAT Detection. When the MN is roaming in an IPv4-only network, two encapsulation methods are considered. If no NAT was detected on the path, the MN creates with it s HA an IPv6-in-IPv4 SIT tunnel to encapsulate IPv6 data packets in IPv4, and maintain a default route towards this tunnel. If a NAT has been detected, new XFRM policies and states are installed by both the MN and the HA to encapsulate and Decapsulation the IPv6 data traffic in IPv4 UDP. Security being also one of our concerns, the implementation already supports the protection of the Mobile IPv6 signaling by installing the XFRM policies and states that perform IPsec operations on the BU and BAck messages. Performing NAT detection on UDPencapsulated BU protected by IPsec is quite challenging though. 3.5.4 Tool and Technologies Linux platform and other related technologies have the tremendous scope for implementing schemes for network protocol. At least LAN is required to implement the Network Address Translation. There should be various hardware and software to solve this problem. The hardware are like computer machine of at least 4 in number, switch at least 3 and various data cables are required to solve this problem. At the software level Linux 2.6.28.2 version are used to solve the various network protocol problems. Mip6d User Land DSMIP daemon and DHCP server which contained IPV4address are required to implement this problem. The router advertisement daemon server contain IPV6 are used. The router advertisement daemon (radvd) is run by Linux or BSD systems acting as Internet Protocol Version 6.0 (IPv6) routers. It sends Router Advertisement messages, specified by RFC 2461, to a local Ethernet LAN periodically and when requested by a node sending a Router Solicitation message. These messages are require for Internet Protocol Version 6.0 (IPv6) stateless auto configurations. DHCP (Dynamic Host Configuration Protocol) DNA module is use to obtain Internet Protocol Version 4.0 (IPv4) address from the DHCP server running on Internet Protocol Version 4.0 (IPv4) network. DHCP servers can be configuring to provide optional data that fully configures TCP/IP on a mobile node (MN). MIPL (Mobile Internet Protocol Version 6.0 (IPv6) for Linux) is an open-source implementation of the Mobile Internet Protocol Version 6.0 (IPv6) standard for the GNU/Linux operating system. Mobile Internet Protocol Version 6.0 (IPv6) is a user space for mobile node (MN) and Home Agent (HA) which aims at providing the necessary changes to MIPL in order to run on the latest kernels. The Advertisement daemon (radvd), IPSec daemon (strongswan) and Web Server (httpd) daemon can be configuring on Home Agent. 3.5.5 Solution Description The solution is an extension to the existing NEPL [17] solution provided by Nautilus [16]. I validated the DSMIPv6 functionality as per the requirements provided against the draft-ietf-mext-nemo-v4traversal-08.txt I-D, [7] along with other IETF standards. I took the baseline architecture implementation from the Nautilus6 [17] which uses Linux platform. The below mentioned steps were taken by me to achieve the requirements. Setup DSMIPv6 Test Lab using Kernel 2.6.28.2 and UMIP vemyon 0.4. In order to test the basic 246

functionality between HA and MN according to RFC [3775] the Test Bed has been setup. Code changes has done in MIP6D daemon and Linux kernel and also applied the open source patches/packages on Test Lab to meet the requirements The Routing Advertisement Daemon (radvd), IPSec Daemon (strongswan) and Web Server (httpd) Daemon has been configured on Home Agent. The Mobile Node is configured with IPSec Daemon (strongswan). MN gets IPv6 address whenever it is moved to any IPv6 foreign network through the radvd server running on the router. When MN is moved to IPv4 network, it gets configured with IPv4 CoA from the DHCP server running on IPv4 Router. In IPv4 network, DHCP is configured on the private network behind router. The network behind IPv4 router can be public or private. 4. Architectural Representation of DSMIPv6 This section covers overview of NEPL and DSMIPv6 implementation and briefly describes the features supported by DSMIPv6 architecture. It also focuses on the MY Solution Approach and explains the high level view of modules used in DSMIPv6 using a block diagram schematic. MIPL (Mobile IPv6 for Linux) is an open-source implementation of the Mobile IPv6 standard for the GNU/Linux operating system. MIPv6 is a user space for MN and HA which aims at providing the necessary changes to MIPL in order to run on the latest kernels. Figure-3: Block Diagram of MIPv6 shows the internal data flow between two major components i.e. HA and MN. Both of these two components consist of several helper modules which are also shown in figure. 4.1 Module Description Section covers major helper modules used inside UMIP. 4.1.1 DNA/DHCP Module DHCP DNA module is used to obtain IPv4 address from the DHCP server running on IPv4 network. Figure-2: DNA/DHCP When MN moves to IPv4 FL and its egress interface becomes enabled, Mip6d code in MN listens for Router Advertisement message, and since it does not receives Router Advertisement message in IPv4 FL, it gets timeout and sends Router Solicitation message (that will request the router to generate the Router Advertisement message immediately rather than at there next scheduled time), and MN wait for some time interval for Router Advertisement message before repeating the same procedure of sending Router Solicitation message figure 2. Meanwhile after sending Router Solicitation message, mip6d daemon will check the presence of DHCP server on the Egress interface link of MN by sending the DHCP discover message and wait for DHCP offer packet. Since the DHCP server is running on the IPv4 FL, it gets the IPv4 address from DHCP server and then mip6d code maps IPv4 address to IPv6 address, which is further used as CoA. Mip6d daemon sets the default route on MN. When MN moves to IPv4 only network or dual stack network then only this DHCP DNA module comes into the picture. MN first tries to acquire IPv6 CoA and failure in IPv6 address configuration triggers the DHCP DNA code which sends dhcp discover messages on the network to acquire the IPv4 CoA. 4.2 Movement Detection Module The movement of a mobile node away from its home link is transparent to transport and higher-layer protocols and applications. The Movement detection uses Neighbor Unreachablility Detection to detect when the default router is no longer bi-directionally reachable, in which case the mobile node must discover a new default router (usually on a new link). However, this detection only occurs when the mobile node has packets to send. When the mobile node detects handover, it expires the previous routers and Care-of-Address (es) and selects a new default router as a consequence of Router Discovery, and then performs Prefix Discovery with that new router to 247

form new care-of address (es). It then registers its new primary care-of address with its home agent. After updating its home registration, the mobile node then updates associated mobility bindings in correspondent nodes. It triggers a movement event and then detects that MN is in foreign network. Route is modified and Home Address which was previously assigned to the physical interface are now moved to the tunnels. When MN moves to IPv4 FL, Mip6d code in MN listens for Router Advertisement message, and since it does not receives Router Advertisement message in IPv4 FL, it gets timeout.. It sends Router Solicitation message, and MN wait for some time interval for Router Advertisement message before repeating the same procedure of sending Router Solicitation message. Meanwhile after sending Router Solicitation message, mip6d daemon will check the presence of DHCP server on the egress interface link of MN by sending the DHCP discover message and wait for DHCP offer packet. Since the DHCP server is running on the IPv4 FL, it gets the IPv4 address from DHCP server. And then mip6d code maps IPv4 address to IPv6 address, which is further used as CoA. Mip6d daemon sets the default route on MN. When MN moves to IPv4 FL, it gets the IPv4 Care-of-Address from DHCP server. And then mip6d code maps IPv4 address to IPv6 address, which is further used as CoA on egress interface of MN. 248

Figure-3: Block Diagram of UMIP 249

4.3 Binding Management Module 4.5 XFRM and IPSec Module XFRM [32] is a packet transformation framework residing in the Linux kernel. It performs operations on IP packets such as inserting, modifying headers, UDP encapsulation and de-capsulation. DSMIPv6 XFRM module will take the advantage of existing IPSEC transformation and defines a simple UDP encapsulation scheme. IPSEC module is responsible for interaction with IKEV2 through MIGRATE messages. IPSec will be used to protect the following traffic between Home Agent and Mobile Node. Figure-4: Movement Detection This section is discussed in paper [35]. Figure-7: XFRM/Packet Security Figure-5: Binding Management 4.4 Route and Tunnel Management Module Section discussed in [36].When mip6d daemon starts in MN, tunnelctl_init routine gets trigger from main routine of code. After then when MN moves to any FL or boots directly in any FL, mn_tnl_state_add routine triggers every time to update end points to tunnels, just when mn_send_home_bu routine sends binding update to HA. Figure-6: Tunnel & Route Management 1. BU/BA messages. 2. Mobile prefix sollicitation and advertisement messages. 3. Normal traffic between Mobile Node and Home Agent. 4. All tunneled normal traffic between Mobile Node and correspondent Node. In Mip6d, the Mobile Node (MN) and the Home Agent (HA) uses IPsec Security Associations (SAs) in transport mode to protect BU/BA messages, since the MN may change its attachment point to the Internet, it is necessary to update its endpoint address of the IPsec SAs. This indicates that corresponding entry in IPsec databases (Security Policy (SPD) and SA (SAD) databases) should be updated when Mobile Node performs movements. IPSec is used to protect the following traffic between Home Agent and Mobile Node. 4.6 NAT Detection and Traversal Module This section is discussed in paper [34]. 4.7 Mobility Listener Module This section is discussed in paper [35]. 5. Performance Evaluation The performance of the Network Address Translation Traversal on Dual Stack implementation [34] has been evaluated in order to prove the effectiveness of the proposed approach for Mobile IP communication in Dual Networks [36]. In order to validate the implementation we led some handover test following the scenarios that is equivalent to the personal area network. In this 250

paper we show the result of such an experiment where a mobile node moves from an IPv6 to IPv4 access network and conversely. The network topology build for this experiment is given in figure 8. The performance is taken as according to testbed created as given below figure 9. The analysis is done on computers in I.T.Laboratory. The change occurs in the patches according to the problem. During the experiment, a mobile node located inside the mobile network continuously sends an UDP flow to an IPv6 correspondent node located in the internet. The analysis is done on the packets with some average size of 200 byte and is sending every 4ms.We have thus analyzed the mobile network node disconnection time experienced at the correspondent node. Also network traces for all the active interfaces are available on the Mobile Router. These allow scaling DSMIPv6 operations and sketch the effectiveness of the various modules given in [35]. first experiment was conducted using a Mobile Router with a single egress interface, moving from an IPv6-only to an IPv4-only network, and conversely. As a comparison, a handover between two IPv6 networks is also performed. The handover performed between two IPv6 networks and depicted on the top graph gives approximately the same result as the one conducted during the NEPL (NEMO Platform for Linux) [17] evaluation exposed in [33]. The table 1 show sample from IPv6-IPv4 and table 2 shows the relation between Sequence Number of Packets, Reception time and signaling type to Correspondent Node in Seconds when a mobile node moves from home agent in IPv6 to another network in IPv4. MN 1 MN 2 Home (MIP6d) MN 3 Internet IPv6 Network Link HOME AGENT MN 1 FL IPv4 Network Figure 8:-Network Topology for Moveable Device Table 1. Sample of Handover from IPv6 to IPv4 Sample for IPv6 to IPv4 Handover Link up IPv4 config (DHCP) MIPv6 1.618 sec. 888 ms (330 ms) 179 ms NAT Device Linux-2.6.28.2 Source MIP6Daemon Patches MIP6Daemon IPSec\IKev2 Clients ( FTP.HTTP etc) Kernel for Mobile Node Home Link HOME LINK SWITCH Linux-2.6.28.2 Kernel Source Kernel Patches for 2.6.28.2 Routing Advertisement Daemon1.2 MIP6Daemon Patches for MIP6Daemon Servers (HTTP Daemons) IPSec\IKev2 Routing Advertisement Daemon 1.2 HOME AGENT DHCP Server NAT Device Access Router -2 Foreign Network IPv6 SWITCH Access Router Foreign Network Dual Stack Access Router -1 Foreign Network IPv4 Routing Advertisement Daemon 1.2 DHCP Server Figure 9:- Test bed Setup 251

Signaling Type Table 2. Data Packets and reception Time Sequence Number (Data Packet) Reception Time at CN (Seconds) Reception Time at CN (Seconds) 200 11 2400 12 2600 13 2800 14 33.62 16.81 3500 17.5 4000 20 Send at Sequence BINDING UPDATE 16.6 2350 BINDING ACKNOWLEDGE 16.8 2850 MENT DHCP DISCOVER 16.2 3100 DHCP OFFER 16.4 3400 DHCP REQUEST 16.4 3850 DHCP ACKNOWLEDGE MENT 16.4 4200 Table 3. Reception Time and Signaling packets Signalimg Types Sequence Number of Data Packets 5000 4000 3000 2000 1000 0 4500 4000 3500 3000 2500 2000 1500 1000 500 0 Movement from IPv6 25 to IPv4 1 2 3 4 5 6 7 20 15 10 Reception Time at Correspodent Node in Seconds Signaling Type Occure with Sequence Number 5 0 Sequen ce Number (Data Packet) Recepti on Time at CN (Second s) Send at Time 16 16.2 16.4 16.6 16.8 17 Reception Time at Correspondent Node Combining both above graphs we find the following graph before NAT Detection and Traversal. The handover from an IPv6 to an IPv4 network depicted in the graph figure 10 depends on various parameters as shown in table 1. The overall length of the gap is 2.61 seconds. Here is the explanation of each field in the table: Figure 10: Transmission of Packets from IPv6 to IPv4 Networks The first postponement in this table corresponds to the time required by the Userland UMIP daemon to receive a link status change notification. It includes the device driver overseer timeout, and to a greater extent, the delay before a new linklocal IPv6 address is added on the interface. It is computed as the time elapsed between the last successfully transmitted data packet on the interface and the first IPv6 Router Solicitation message. 252

UMIP time = Last Data Packet Dent First RS Message. In implementation, IPv4 configuration is started in parallel with the IPv6 one (i.e. when the first Router Solicitation is sent) with the help of DHCP. This delay is computed as the time elapsed between the first Router Solicitation message and the first BU message using IPv4 UDP encapsulation. Among this delay, the time elapsed between the first DHCP Discover and the DHCP Ack (acknowledgement) is quoted separately for reference, but it is included in the IPv4 configuration delay. Finally, regular Mobile IPv6 operation is taking place using the new XFRM [37] transformation for UDP encapsulation. This last delay is computed as the time elapsed between the first BU message and the first successfully received data packet at the correspondent node. One can notice that the BAck is received on the MR after data packets are sent on the new link. We use a mechanism called optimistic handovers, which al-lows the MN to send data packets right after sending a BU, even though it has not been acknowledged yet by the HA. Performing the IPv4 configuration at the same time as the IPv6 one allows to greatly reduce the handover time. We consider at the moment that the IPv4 configuration takes more time than the IPv6 one. Thus, if no IPv6 CoA has been configured at the end of the IPv4 configuration, the IPv4 CoA is registered to the HA. This does not prevent though to register later an IPv6 CoA if one is available to replace the IPv4 one. Another behavior could be to wait at least one Router Solicitation interval (4 seconds as defined in [32]) before sending a BU, but this would increase the handover time. Handover from IPv6 to IPv4 Network while NAT Detection and Traversal Table 4. Data Packets and reception Time while NAT Sequence Number (Data Packet) Sequence Number (data Packet) Reception Time at CN (Seconds) 1175 6 1300 7.5 1390 8.2 1420 9 1422 9.05 1500 10 1520 11 1600 12 1800 13 2000 1000 0 Sequence Number (Data Packet) 1 2 3 4 5 6 7 8 9 Reception Time at CN (Seconds) Reception time at Corrospodent Node Send Sequence Number (Data Packet 2000 1800 1600 1400 1200 1000 800 600 400 200 0 Signaling Type BINDING UPDATE (UDP) BINDING ACKNOWLEDGE MENT (UDP) Reception Time at CN (Seconds) Send at Sequence 9.01 1120 9.05 1280 DHCP DISCOVER 9.8 1400 DHCP OFFER 10.1 1590 DHCP REQUEST 10.1 1680 DHCP ACKNOWLEDGE MENT 10.1 1820 1 2 3 4 5 6 7 8 9 Reception Time to CN 10.2 9.8 9.6 9.4 9.2 8.8 Combining these graphs we conclude the following graph 7.6 Figure 11 having very less delay reception time and negligible packets lost when they moves from Home agent to Correspondent Node. The tests have been performed in order to investigate the performance impact of the various NAT traversals and Detection processes. In graph figure 11 we see that the reception time is very low small and negligible packets are lost. The delay time is very-very small. So there is uniform data communication between home agent and moveable device whether device moves from one network or other. The Dual Stack implementation of Mobile IPv6 as software modules has to be paid by a performance impact of up to 94 %.A hardware IPSec device at the home network would be a solution to minimize performance degradation by encryption [12]. The handover from one foreign network to another takes currently up to 0.5 seconds. Most of this delay comes from the FreeS/Wan IPSec module, because the generated IPSec device has to be shut down and restarted after learning a new IP address. This restart of the IPSec module takes about 0.5 seconds on the test PCs. Using a more dynamic IPSec module could decrease this handover delay to max. 0.4 seconds. That delay is caused by DHCP to configure the network interface to work in the new network environment. 10 9 Table 5. Reception Time and Signaling Type while NAT 253