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

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

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

2009 International Conference on Computers and Devices for Communication

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

ACN

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

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

IPv6
NETWORK
IPv4 HOST

DSTM
TSP

IPv4 HOST

DSTM
TEP

Figure 2. DSTM Simulation Scenario

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

ACN

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
N

DE

i =1

Nr

(1)

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

2009 International Conference on Computers and Devices for Communication

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

MEAN END-TO-END DELAY FOR IPV4-ONLY NETWORK

Packet Size
(Bytes)
256

FTP
End-to-End
Delay(ms)
60

RA
End-to-End
Delay(ms)
140

CBR
End-to-End
Delay(ms)
50

512

70

142

65

1000

82

160

76

1256

107

235

98

TABLE II

MEAN END-TO-END DELAY FOR IPV4 AND IPV6 NETWORK (WITH DSTM)
Packet Size
(Bytes)

FTP
End-to-End
Delay(ms)

RA
End-to-End
Delay(ms)

CBR
End-to-End
Delay(ms)

256

100

180

80

512

110

180

95

1000

115

190

103

1256

140

310

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

ACN

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.