2009 International Conference on Computers and Devices for Communication

ACN

Simulation of IPv4-to-IPv6 Dual Stack Transition Mechanism (DSTM) between IPv4 Hosts in Integrated IPv6/IPv4 Network
Krishna Chakraborty, Nitul Dutta, S R Biradar
Abstract-IPv6 offers variety of enhancements including increased addressing capacity, Quality of Service (QoS) provisioning, built in security through IPSec and improved routing efficiency, over IPv4. But moving from the current version of IPv4 to the future version of IPv6 is not a straightforward process due to their incompatibility and will consume significant amount of time. So for the coming years both the protocols need to coexist. For the smooth interoperation of the two protocols, various well defined transition mechanisms have been proposed so far. In this paper a comparative study of the behavior of IPv4-only network with that of Dual Stack Transition Mechanism (DSTM) under various types of traffic patterns is carried out. In the proposed DSTM enabled network architecture, the hosts in IPv4 network initiates connection with hosts in the IPv4 network over an integrated IPv4/IPv6 network. The performance metric considered in this work is mean end-to-end delay for both the scenarios. Assessment of the mean end-to-end delay is performed on various applications like Real Audio (RA) and CBR over UDP and FTP over TCP. All the simulations are performed using Network Simulator 2 (ns-2).

I. INTRODUCTION

HE present version of the Internet Protocol, IP version 4

(IPv4), has various limitations that are being focused as the Internet continues its phenomenal growth and expansion of services. The most familiar problem with IPv4 is its limited address space, which is based on a 32-bit address and an inefficient address allocation mechanism. However there are several other shortcomings such as its best-effort delivery mechanism, lack of support for Quality of Service (QoS) and mobility issues, and the manner in which security is handled. All of them have contributed towards the requirement for an improved Internet protocol. Besides, most applications today support IPv4; thus there is a need for these applications to be accessible on IPv6 network. All these issues have been resolved in IPv6 by expanding the address space, which is based on a 128-bit address, introducing Quality of Service (QoS), and also improving built-in security using IP Security (IPSec) [1]. Rapid mushrooming of the Internet and of the number of
Sikkim Manipal Institute of Technology, Computer Sc. & Engg. Deptt., East Sikkim, Sikkim, India. Email: kc.cs.smit@gmail.com

IPv4 users contributes to the fact that the transition from IPv4 to IPv6 is expected to be a long process. The key to a successful transition to IPv6 is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 during the exploitation of IPv6 will rationalize the job of transitioning the Internet to IPv6. This specification defines a set of mechanisms that IPv6 hosts and routers may implement in order to be compatible with IPv4 hosts and routers. But IPv6 lacks backward compatibility with IPv4, leading to the fact that IPv6 hosts and routers will not be able to deal directly with IPv4 traffic and vice-versa. Also, it is impractical to invest in a fully new IPv6 infrastructure. This is due to the fact that most of the applications that exist today were written for IPv4 network and moreover the large infrastructures where a huge amount has been invested in setting the IPv4 network totally refute from converting to IPv6. A huge cost will be incurred to re-setup the network. Moreover, movement from IPv4 to IPv6 is not a straightaway process and so cannot take place within a fortnight; it requires developing mechanisms so that IPv4 and IPv6 may exist together for at least many coming years and during this transition period IPv4 network will totally disappear [2]. The aim of this paper is to examine the behavior of a transition mechanism that will involve the communication between two IPv4 hosts over an IPv6 network under various traffic conditions. This will make possible the exchange of information between IPv4-only network hosts through an integrated IPv6/IPv4 network. And hence we call it Dual Stack Transition Mechanism (DSTM) as the integrated IPv6/IPv4 network maintains a dual stack of both IPv4 and IPv6. The necessity of reexamining the problem arises as the research in this area has not very widely been explored. The rest of the paper is organized as follows. Section II discusses the related work in this area along with our motivation for this research. Section III illustrates the network architecture used in the work. The simulation scenario is discussed in section IV and section V shows the results and discussions. The paper is concluded in section VI. II. RELATED WORK AND MOTIVATION Many transition mechanisms have been proposed so far and research work has been carried as well in all these mechanisms. Although the research in various transition mechanisms has not been conducted much, but still many

978-81-8465-152-2/09/$26.002009 CODEC

2009 International Conference on Computers and Devices for Communication

ACN

papers discuss the Dual Stack Transition Mechanism (DSTM) in various ways. In paper [3], the authors have adopted the DSTM to study network performance with few types of traffic sources: Voice-over-IPv4, FTP-over-IPv6, and MPEG-4-overIPv6. The performance is evaluated considering bandwidth, throughput, percentage of dropped packets, and mean end-toend delay of each traffic flow for both IPv4 and IPv6. Through the simulations performed by using the Network Simulator 2 (ns-2), it is shown that when the traffic density of IPv6 session increases, the bandwidth of IPv6 session increases at the expense of the decrement of the bandwidth of IPv4 session. On the other hand, the increment of the traffic density of IPv4 session does not increase its bandwidth due to its lower priority. In addition, the increment of packet size of IPv6 traffic results in the increment of a little bit of the mean end-to-end delay, but it is not the case for IPv4 traffic. In [4], the impact of IPv6 transition mechanisms on user application is discussed. The experimental results show that though performance overheads are minimal, but translation packets degrade some performance. The work compares IPv4 versus IPv6 header overhead and header overhead between transition mechanisms and also computes CPU utilization of all these mechanisms and certain other performance aspects like throughput and round-trip time for several types of traffic. It was intended to empirically analyze impacts on transition mechanisms compared with IPv4-only and IPv6-only network performance. The work in [5] reviews the implementation of DSTM over IPv6 test-bed (6iNet) in University Utara Malaysia (UUM). It clearly shows how DSTM works over the test-bed. Their findings could also be applied to other organizational settings which intend to implement IPv6 in the network interconnection. In [6], the authors have analyzed more than 600 end-to-end IPv6 paths between about 26 test boxes of RIPE NCC over the past two years, and compared the delay and loss performance evolution in IPv6 with their IPv4 counterparts. They have presented and discussed the measurement methodology, and provided evidence that IPv6 network has a higher delay and loss evolution than IPv4. Finally, based upon their measurements, they have assessed the perceived quality of three real-life applications: VoIP, Video-over-IP and data communication services based upon TCP. They have found that for VoIP and Video-over-IP, the differences in delay and packet loss between IPv4 and IPv6 do not translate to the perceived quality domain but for applications based upon TCP, the differences in delay and packet loss between IPv4 and IPv6 have a strong impact on the realized throughput. In [7], they have remarked that most of the transition mechanisms proposed by IETF Next Generation Transition Working Group provide only the mechanism to initiate sessions from hosts within the IPv6 network to those within the IPv4 network, but do not support the initiation from IPv4 hosts to IPv6 ones. In their paper, they have proposed the IPv4-to-IPv6 DSTM (4to6 DSTM) which can operate even in the case that hosts in the IPv4 network initiate connections within hosts in the IPv6 network. The work shows the performance of the proposed mechanism in terms of the transmission delay of IPv4 packets from IPv4 hosts to a DSTM host, and the response time of DNS queries with varying the session initiation interval and the connection duration. In all of these papers discussed, not much emphasis has been given to the hosts that are in IPv4 network and want to
978-81-8465-152-2/09/$26.002009 CODEC

communicate over an IPv6 network. Moreover, they have also not detailed much on the performance comparison of the traffic with DSTM with the traffic with only either IPv4 or IPv6 network. The motivating force behind this work is that there is very little exposure given by researchers to the mean end-to-end delay and its impact on applications of IPv4 to IPv6 transition mechanisms and also to such related work. So exploring this area with a wide variety of real time and other applications on different types of traffic was significant. Besides, we also want to show a comparative performance evaluation of these applications considering both the transition mechanism as well as only with either of the IPv4 or IPv6 network. III. PROPOSED NETWORK ARCHITECTURE In this section, we present the description of the architecture of the simulation environment for our work. The scenario given in the Figure 1 depicts a conversation between two IPv4 based nodes over an IPv6 based Network. Assumption is made that the data exchange is realized by means of Dual Stack Transition Mechanism (DSTM). The packet flows from a source node N0 using IPv4 address, encapsulated in an IPv6 capable packet header through a DSTM server (node N1), which is the begin point of a tunnel, Tunnel Start Point (TSP). This packet, whose destination address is an IPv4 compatible IPv6 address, travels through an IPv6 enabled network. The IPv6 network is realized as an integrated IPv6/IPv4 network where the border nodes maintain a dual stack of IPv4 and IPv6. All the other nodes in the network through which IPv4 packets are tunneled are IPv6-only enabled nodes. The node N4 is another DSTM server which can be considered as the Tunnel End Point (TEP), and this is the point where the destination node's IPv4 address is maintained. These begin and end points of the tunnel are the border routers which maintain both IPv4 and IPv6 stacks.

Figure 1. Proposed Network Architecture

This is the reason for having the tunneling of packets through the integrated network so that the utilities of dualstack are adopted along with tunneling transition mechanism. This will avoid the drawbacks of dual-stack approach and add the advantages of tunneling as mentioned in [5]. The problem with dual-stack approach is that in this mechanism, IPv6 datagram can be copied into the data field of the IPv4 datagram and appropriate address mapping is done [8]. But some fields in IPv6 have no counterpart in IPv4 when the IPv6 datagram is mapped into IPv4 datagram. When it travels through network and arrive in IPv6 host, the datagram do not contain all the fields that were in the original IPv6 datagram

2009 International Conference on Computers and Devices for Communication

ACN

sent from source. This will result in dropping the information in these fields. As an alternative to the dual-stack approach, tunneling as discussed in RFC 2893 was suggested to overcome the drawback in dual-stack approach [5]. Finally, the DSTM server forwards the packet with this IPv4 address to the IPv4 enabled destination node, N5. Node N5 (destination node) sends Hello packet to the DSTM server to broadcast its own address. To realize the DSTM, ns-2.26 [9] with MobiWan patch pack [10] is used to create IPv6 based scenario. The utility of the patch pack is that it provides some implemented protocols through which IPv6 based network simulations can be performed. The DSTM scenario will include an IPv4 source node which will send its node ID to a DSTM server, which converts it into a hexadecimal address that is the tunnel end point address and tunnels it in an IPv6 network. When it reaches the tunnel end point, it is again converted to a corresponding IPv4 address. This node also maintains the destination node's IPv4 address. It forwards the packet with the decapsulated IPv4 address to the destination IPv4 node. The IPv4 to IPv6 DSTM network architecture consists of two DSTM servers, the DSTM TSP and TEP, and IPv4 hosts. The DSTM TSP encapsulates the IPv4 address of the host and also maintains the permanent IPv6 address of DSTM TEP. The DSTM TEP is located on the boundary of IPv6 networks and IPv4 hosts, and it tunnels IPv4 packets to destination IPv4 hosts. The IPv4 host (i.e. the host within the IPv4 network) attempts to initiate a session with another IPv4 host by sending a DNS query message to the IPv4 DNS server. The IPv4 DNS server replies with the IPv6 address of the DSTM TEP. With this information, the IPv4 packet is directed to the DSTM TEP on the boundary of IPv6 network and IPv4 network. The tunneled packet is directed to the DSTM TEP and the DSTM TEP decapsulates the IPv6 header and forwards it to the IPv4 network. The DSTM server holds the mapping between the allocated IPv4 address and the IPv6 address of the DSTM TEP in its mapping table and sets the lifetime timer with the value of the amount of the time during which the allocated IPv4 address is considered to be valid. IV. SIMULATION SCENARIO The proposed transition mechanism, DSTM is evaluated through simulation using the Network Simulator ns-2 [11]. In the Figure 2, the network topology for the DSTM transition

mechanism is shown. This topology is designed for the simulation in ns-2.26 with MobiWan patch pack. The topology consists of two IPv4 hosts who want to communicate with each other over an IPv6 network. IPv4 host (node N0) initiates packet transmission by sending request to the DSTM TSP (node N0). At this DSTM server, the IPv4 packet is encapsulated inside an IPv6 header of DSTM TSP (node N1). This IPv4 packet is carried inside the IPv6 header as the IPv6 payload. The packet is forwarded inside the IPv6 network and finally it arrives at the DSTM TEP (node N8). The DSTM TEP decapsulates the IPv6 packet and generates the IPv4 address of the destination IPv4 Host (node N9). This is because instead of the destination nodes IPv4 address, the DSTM TSP forwards the packet in IPv6 network with the DSTM TEPs IPv6 address. This IPv6 address is an IPv4compatible-IPv6 address and it carries the corresponding destination IPv4 address in the last 32-bits. Finally DSTM TEP delivers the packet to the destination IPv4 Host with this IPv4 address. The link capacity between DSTM TSP server (node N1) and the IPv4 source (node N0) is 10Mbps and transmission delay is 20ms. Similarly the link capacity between the DSTM TEP server (node N8) and the IPv4 destination node (node N9) is 15Mbps and transmission delay is 15ms. All other links are of equal capacity with 10Mbps and a 12ms transmission delay. With these parameters, mean end-to-end delay is computed for these different applications: RA (Real Audio), FTP and CBR. V. RESULTS AND DISCUSSIONS We compute the mean end-to-end delay for IPv4-only network as well as for IPv4 and IPv6 network with the DSTM enabled. The end-to-end delay has been calculated for varying packet sizes for the same network architecture. The traffic flow is also varied for FTP, RA and CBR. The mean end-toend delay is calculated by taking into consideration of the time at which a packet starts at the source and the time at which the packet reaches the destination, and also the number of packets received as given in (1). This information is extracted from the trace file obtained for the corresponding tcl script used for the simulation, with the help of a perl script. Mean end-to-end delay: DEm
DE =

D
i =1

Nr

(1)

IPv6 NETWORK IPv4 HOST DSTM TSP

Di = end-to-end delay of packet i = Tdi - Tsi (second) Tsi = Time of packet i en-queued at source Tdi = Time of packet i received at destination Nr = Number of packets received at destination The data obtained is shown in Table I and Table II. These tables show the data for IPv4-only network and IPv4 versus IPv6 network with DSTM, respectively. It is observed that when packet size increases, more time will be consumed for delivering the packet to the destination node due to the higher payload and hence increases the queuing delay for each packet. The RA (Real Audio) traffic consumes maximum time as it is real-time application and hence also the payload will be more. The CBR gives the shortest delay as the bit rate is constant and it uses UDP for transmission. Since UDP is a connectionless protocol, it takes lesser delivery time than TCP. The delay for FTP traffic is more than CBR but less than

IPv4 HOST

DSTM TEP

Figure 2. DSTM Simulation Scenario

978-81-8465-152-2/09/$26.002009 CODEC

2009 International Conference on Computers and Devices for Communication

ACN

RA since it uses TCP for transmission. As TCP is a connection oriented protocol, it takes higher delivery time than UDP. It is also seen that there is significant increase in the delay for CBR and RA traffic when the packet size is 1256 bytes. The reason behind this is that the maximum limit of the packet size that can be transmitted for CBR and RA traffic is 1000 bytes. Therefore whenever the traffic with packet size more than 1000 bytes is encountered, it is split and transmitted and hence increases the delay. When the mean end-to-end delay for IPv4-only network and IPv4 versus IPv6 network with DSTM is compared, it is found that IPv4 versus IPv6 network consumes more time to deliver a packet. This happens because when the IPv4 node forwards a packet to another IPv4 host through IPv6 network, the encapsulation and decapsulation of the packet at the DSTM server, TSP (when the packet enters the IPv6 network) and the other DSTM server, TEP (when the packet leaves the IPv6 network), respectively, takes considerable amount of time and so increases the queuing delay. So the communication between IPv4 hosts over an integrated IPv6/IPv4 network using DSTM will always take longer than the communication between the hosts in IPv4-only network or in IPv6-only network.
TABLE I

parameters to perform a comparative study of the various transition mechanisms. REFERENCES

[1] G. C. Kessler, IPv6: The Next Generation Internet Protocol, the Handbook on Local Area Networks, pub. Auerbach in August 1997. [2] Jivesh Govil, Jivika Govil, et al, On the Investigation of Transactional and Interoperability Issues between IPv4 and IPv6, IEEE EIT 2007 Proceedings, 2007, vol-2,200-203p. [3] T. Sanguankotchakorn et al., Performance Evaluation of IPv6/IPv4 Deployment over Dedicated Data Links, Fifth International Conference on Information, Communications and Signal Processing, 2005. [4] Myung-Ki Shin et al., An Empirical Analysis of IPv6 Transition Mechanisms, Feb. 20-22, 2006 ICACT2006. [5] Hatim Mohamad Tahir, Azman Taa, Norshakinah Bt Md. Nasir, Implementation of IPv4 Over IPv6 Using Dual Stack Transition Mechanism (DSTM) on 6iNet, Second International Conference on Information and Communication Technologies, 2006, ICTTA '06, vol. 2, pp. 3156-316, ISBN: 0-7803-9521-2 [6] Xiaoming Zhou et al., Estimation of Perceived Quality of Service for Applications on IPv6 Network, Proceedings of the ACM international workshop on Performance monitoring, measurement, and evaluation of heterogeneous wireless and wired networks 2006, pp. 7481, ISBN:159593-502-9 [7] Eun-Young Park et al., An IPv4-to-IPv6 Dual Stack Transition Mechanism Supporting Transparent Connections between IPv6 Hosts and IPv4 Hosts in Integrated IPv6/IPv4 Network, IEEE Communication Society 2004. [8] Tian, J. and Li, Z., The next generation Internet protocol and its test, IEEE Communication Magazine, 210-215, 2001. [9] Francisco J. Ros, Pedro M. Ruiz. Implementing a New Manet Unicast Routing Protocol in NS2, December 2004. [10] http://www.inrialpes.fr/planete/mobiwan. [11] The VINT Project. The ns Manual, December 2003, http:// www.isi.edu/ nsnam/ns/ns-documentation.html.

MEAN END-TO-END DELAY FOR IPV4-ONLY NETWORK Packet Size (Bytes) 256 512 1000 1256 FTP End-to-End Delay(ms) 60 70 82 107
TABLE II

RA End-to-End Delay(ms) 140 142 160 235

CBR End-to-End Delay(ms) 50 65 76 98

MEAN END-TO-END DELAY FOR IPV4 AND IPV6 NETWORK (WITH DSTM) Packet Size (Bytes) 256 512 1000 1256 FTP End-to-End Delay(ms) 100 110 115 140 RA End-to-End Delay(ms) 180 180 190 310 CBR End-to-End Delay(ms) 80 95 103 132

VI. CONCLUSION This research is just an attempt to show the current scenario of the impact of transition mechanisms over a network. It reflects the performance overhead incurred by DSTM as compared to an IPv4-only network. This work also concludes that in spite of imposing extra delay to the network, the DSTM is significant as a transition mechanism due to two facts. Firstly, a transition mechanism is required for the smooth interoperation of both the protocols and secondly, DSTM has proved to have several features of tunneling and dual-stack approach which can be considered as an intermediate of these two transition mechanisms. This way DSTM provides better reliability and low data loss by combining the features of the two transition mechanisms. This research will encourage the scientists across the globe to explore more on many other
978-81-8465-152-2/09/$26.002009 CODEC