Content uploaded by John Mellor
Author content
All content in this area was uploaded by John Mellor on Mar 02, 2019
Content may be subject to copyright.
A Comparison between the Tunneling process and Mapping schemes for IPv4/IPv6
Transition
Ra’ed AlJa’afreh, John Mellor, and Irfan Awan
Department of Computing, Informatics School, University of Bradford, Bradford, UK
{R.A.K.Aljaafreh, J.E.Mellor, I.U.Awan}@Bradford.ac.uk
Abstract
A number of transition mechanisms have been
developed to support the interoperability between IPv4 and
IPv6 during the time of migration from the existing IP
version (IPv4) to the new IP version (IPv6). BDMS is one
of the IPv4/IPv6 transition mechanisms that has been
designed to enable IPv4-only hosts to communicate with
IPv6-only hosts and vice versa. DSTM has been designed
to enable IPv6 hosts to communicate with IPv4-only hosts.
In this paper, we present the impact of the mapping and
translation processes of the BDMS transition mechanism
compared with the tunneling process of the DSTM when a
variety of traffic loads are used. Our simulation results
show that the EED and throughput results of the BDMS are
close to the results of the DSTM and direct v4-to-v4 and
v6-to-v6 (Direct-link) connections when the number of
connected nodes is small. This paper shows that the
tunneling process in the DSTM has a significant impact on
the performance compared with the BDMS and Direct-link
connections when large traffic loads are used. All the
simulation scenarios in this paper are performed using the
OMNeT++ simulator platform.
Keywords: IPv6, IPv4, BDMS, DSTM.
1. Introduction
A. IPv4 and IPv6 Specifications
IPv4 [1] was the first version of the Internet protocol that
was widely deployed in order to provide unique global
computer addressing to make sure that two computers (or
any two network devices) can uniquely identify one
another. Due to the fast growth of the network as well as
Internet devices, a huge amount of unique addresses are
needed. To overcome the limitations of the existing IP
(IPv4) in terms of addresses, routing, and security a new
version of Internet protocol was designed by the Internet
Engineering Task Force (IETF) known as IPv6 [2]. IPv6 -
originally known as IPng- has been selected from several
proposed alternatives as a suitable successor of the existing
Internet Protocol (IPv4) [3].
The main goal for designing the new Internet Protocol
(IPv6) is to increase the number of IP addresses (address
spaces) [4]. The IPv6 address has been designed with a
128-bit (16-bytes) address scheme instead of the 32-bit (4-
bytes) address scheme in IPv4, which means IPv6 can
express over 3.4x1038 possible unique addresses compared
with 4.3x109 possible unique addresses in IPv4 [1] [4].
IPv6 will have enough to give every device (e.g. telephone,
cell phone, mp3 player, automobile, etc) on the surface of
earth its own IP address, which alleviates the need for the
Network Address Translators (NATs) [5] that has been
used to overcome the shortage of the IPv4 unique addresses
[6] [7]. In addition, IPv6 is designed to support security
(IPSec), scalability, and multimedia transmissions. Overall,
IPv6 was carefully thought out and was designed with
future applications in mind.
On the other hand, several organizations (such as the
Department of Defense (DoD) in USA) [8] have prepared a
schedule for implementing the new Internet Protocol (IPv6)
to meet their future deployment needs. Due to that, and
because the IPv4 and IPv6 protocols are incompatible; the
next generation transition Working Group (ngtrans WG)
[9] in IETF as well as the other researchers have designed
several IPv4/IPv6 transition mechanisms to ensure smooth
interactions between those IP versions. On the other hand,
there is still a need for more research to be done on the
IPv4/IPv6 transition in order to solve many problems that
are not yet resolved [10].
This paper is organized as follows. The rest of this section
gives a brief description for the transition mechanisms.
Section 2 illustrates three simulation scenarios that have
been used in this paper. Section 3 outlines the performance
evaluation metrics such as EED and Throughput that have
been used in this paper. Section 4 presents the simulation
results. Finally, section 5 concludes this paper.
B. Transition Mechanisms
It is envisioned that the transition from IPv4 to universal
IPv6 will not happen in the near future. So, both Internet
protocols (IPv4 and IPv6) need to coexist during the
migration period. A number of mechanisms have been
developed for managing the transition from IPv4 to IPv6
and vice versa. These mechanisms can be grouped into the
following three categories [11] [12] [13]:
(1) Dual-Stack: Each network device supports a dual
protocol stack; this means both Internet Protocols (IPv4
and IPv6) are enabled on that network device. Therefore,
the dual stack node has the ability to work in one of the
following three styles [14]: as IPv4 only node when IPv6 is
switched off and IPv4 is switched on; as IPv6 only node
when IPv4 is switched off and IPv6 is switched on, or as
IPv4/IPv6 dual stack node when both IPv4 and IPv6 are
active.
(2) Tunneling: Encapsulating IPv6 packets within the IPv4
packets and passing them through the native IPv4 domains.
Additionally, each tunnel can be established between two
endpoints manually or automatically depending on the
selection mechanism.
(3) Translation: There is a need for a border device
(translator) to be added between the two different IP
networks to give the ability for the native IPv6 hosts in the
IPv6-only network to communicate with the native IPv4
hosts in the IPv4-only network and vice versa. So, in the
translation mechanisms, one protocol must be translated
into the other.
2. Simulation models
The Bi-Directional Mapping System (BDMS) [15] has
been designed in order to support bi-directional
communication sessions to be initiated by either an IPv6
host in an IPv6-only network or an IPv4 host in IPv4-only
network. BDMS is based on two key components that are
the V4-V6/V6-V4 Domain Name Server (DNS46/DNS64)
and the V4-V6/V6-V4 Enabled Gateway.
On the other hand, the Dual Stack Transition Mechanism
(DSTM) [16] has been submitted as a draft RFC in the
IETF. DSTM is applicable for the IPv4/IPv6 hosts that are
located in IPv6 dominant networks to initiate their
communications with IPv4-only hosts that fall in the IPv4
native network. Also, DSTM is based on the tunneling
(IPv4-over-IPv6) method that encapsulates the IPv4
packets in the IPv6 packets then carries them through the
IPv6 network to the DSTM Tunnel End Point (DSTM
TEP) that falls at the border between IPv6 and IPv4
networks. DSTM includes three key components that are
DSTM server, DSTM TEP, and DSTM client (IPv4/IPv6
host in the IPv6 dominant network).
Therefore, in this paper, we encountered a need to simulate
real network traffic in a realistic way in order to study the
behavior of the BDMS translator that falls in the middle
between the generated (source) hosts and the received
(destination) host, while the communicated hosts are
located in two different IP networks. We then compare the
BDMS with the behavior of the DSTM gateway and V4/V6
router in the other communication sessions. Each traffic
value is represented by a sequence of data packets
generated according to a Poisson process.
The simulation process in this paper can be divided into
three main scenarios:
Scenario 1: V4-to-V4 and V6-to-V6 Direct-link
connections via a router.
Scenario 2: V4-to-V6 and V6-to-V4 connections via the
BDMS translator (as shown in Figures 1 & 2).
Scenario 3: V6-to-V4 connection via the DSTM gateway
(as shown in Figure 3).
The simulation process for Scenario one can be done by
conducting the required communication between either
IPv4-to-IPv4 hosts that are located in an IPv4-only network
or IPv6-to-IPv6 hosts that are located in an IPv6-only
network. Also, the two types of communication sessions in
this scenario can be performed using a router as an
intermediate device.
Figure 1: v4-to-v6 BDMS connection via BDMS translator.
In Scenario two, the simulation process can be done by
conducting a connection between either IPv4-only to
IPv6-only hosts or IPv6-only to IPv4-only hosts using a
BDMS translator as an intermediate device (see Figures 1
& 2).
Figure 2: v6-to-v4 BDMS connection via BDMS translator.
The simulation process for Scenario three can be done by
conducting a connection between DSTM hosts that are
located in the IPv6 dominant network and IPv4 host that is
located in an IPv4-only network using a DSTM gateway as
an intermediate device (see Figure 3).
Figure 3: v6-to-v4 DSTM connection via DSTM Gateway.
3. Performance Evaluation Metrics and
Simulation Parameters
In this paper, two performance evaluation metrics are used:
End-to-End Delay (EED)
We considered the EED as one of the key performance
metrics that need to be computed to find out the time
required for each transmitted packet in the
communication session. While the mean EED for a
sequence of packets of specific size in each
communication session is calculated as follows (Eq. 1
and 2):
where EEDi is the End-to-End Delay of packet "i", Tsi is
the generated time of packet "i" at the source host, Tdi is
the received time of packet "i" at the destination host,
Nrec is the total number of received packets at the
destination host, and MeanEED is the EED mean value
for each communication session.
Throughput
We measured the throughput performance metric in order
to find out the rate of received and processed data at the
intermediate device (i.e. Router or Gateway) during the
simulation time period. While the mean Throughput for a
sequence of packets of specific size in each
communication session is calculated as follows (Eq. 3
and 4):
where Thri is the throughput value when packet "i" is
received at the intermediate device (v4/v6 Router, BDMS
Gateway, or DSTM Gateway), N is the total number of
received packets at the intermediate device, Prec is the
number of received packets at the intermediate device,
Pgen is the number of generated packets by the source
hosts, and the MeanThr is the throughput mean value for
each communication session.
The following table (Table 1) shows the simulation
parameters that are used to calculate the performance
measurements using the OMNeT++ simulation platform
[17] when each packet arrival follows a Poisson process
with rate λ=2.
TABLE 1: SIMULATION PARAMETERS
Vary Traffic Loads 6 ~ 240 Nodes
Payload Size 200 bytes
Buffer Size 500 packets
Propagation delay 10 ms
Queue Management Scheme Drop Tail
4. Simulation Results and Discussion.
In this section, we present the simulation results that have
been obtained by scenarios 1, 2, and 3 followed by a
discussion for these results. The EED and Throughput
performance evaluation metrics are used.
A. Scenario one simulation results
The simulation results for scenario one present the EED
and Throughput results when a direct-link connection
between either IPv4 hosts in IPv4-only network or IPv6
hosts in IPv6-only network is conducted through a V4/V6
router. The results are illustrated in Fig. 4 and Fig. 5.
EED vs. Connected Nodes
0.000
0.200
0.400
0.600
0.800
1.000
1.200
6 20 50 80 120 150 180 210 240
No. of Connected Nodes
EED (s )
v4-to-v4
v6-to-v6
Figure 4: A comparison between the EED of V4-to-V4 and V6-to-V6
communication sessions.
rec
N
ii
N
EED
MeanEED
rec
∑
=
=1
whereas,
iii TsTdEED −=
(1)
(2)
N
Thr
MeanThr
N
ii
∑
=
=1
whereas,
%100∗=
gen
rec
P
P
Thr
(3)
(4)
From Figure 4, the simulation results show that the v4-to-
v4 EED is less than v6-to-v6 EED. In fact, there may be
several reasons that explain why this happens. First, the
difference between the IPv6 header (40 bytes) and the IPv4
header (20 bytes) which causes more traffic overhead
especially when the IP packet payload is small (payload
size = 200 bytes in our simulation). Second, the size of IP
packet payload is fixed (i.e. 200 bytes) in all
communication sessions, this means no fragmentation
process is needed which leads to reduce the benefit from
the IPv6 feature that allows the fragmentation and de-
fragmentation processes to be performed by only the source
and destination hosts compared with the IPv4 that allows
these processes to be performed by all the intermediate
devices that fall between the source and destination hosts.
Therefore, the benefit from the IPv6 design becomes more
significant when the communicating hosts are routing their
packets through several intermediate devices (more
complicated route).
In addition, Figure 4 shows that the difference between the
v4-to-v4 EED and v6-to-v6 EED results is very small and
this difference increases when the number of connected
nodes increases as well. Also, the v6-to-v6 EED is
suddenly increases due to the network congestion that
occurs when the number of connected nodes becomes large
(i.e. > 150 nodes).
On the other hand, the following figure (Fig. 5) shows a
comparison between the v4-to-v4 and v6-to-v6 throughput
results. It is obvious that the throughput results in both
communication sessions are close up to 120 nodes and the
difference in the throughput result increases when the
number of connected nodes becomes large (i.e. > 120
nodes) due to the impact of the IPv6 header size that causes
more traffic overhead compared to the IPv4 header size.
Throughput vs. Connected Nodes
0
20
40
60
80
100
120
6 20 50 80 120 150 180 210 240
No. of Connected Nodes
Throughput (%
)
v4-to-v4
v6-to-v6
Figure 5: A comparison between the Throughput of the Direct-link
(V4-to-V4 and V6-to-V6) communication sessions.
B. Scenario two simulation results
The simulation results for scenario two present the EED
and Throughput performance metrics when either the v4-
to-v6 or v6-to-v4 communication session has been
conducted through the intermediate BDMS translator
device that falls in the middle between the two different
networks (as shown in Figures 1 & 2). The results are
illustrated in Fig. 6 and Fig. 7.
EED vs. Connected Nodes
0.000
0.500
1.000
1.500
2.000
2.500
6 20 50 80 120 150 180 210 240
No. of Connected Nodes
EED (sec.
)
BDMS-v4-to-v6
BDMS-v6-to-v4
Figure 6: A comparison between the EED of the v4-to-v6 BDMS and
v6-to-v4 BDMS communication sessions.
From Figure 6, the simulation results show that the EED of
v6-to-v4 BDMS is greater than the EED of v4-to-v6
BDMS. In fact, there may be two reasons that explain why
this happens. First, the delay of the incoming packets at the
BDMS translator in the v6-to-v4 BDMS communication
session is more than the delay of the incoming packets at
the BDMS translator in v4-to-v6 BDMS communication
session due to the difference between the IPv6 header size
(40 bytes) and IPv4 header size (20 bytes). Second, the
need to recalculate the checksum field value for the
outgoing packets causes more delay in the v6-to-v4 BDMS
communication session than the v4-to-v6 BDMS
communication session during the time of header
conversion.
Additionally, Figure 6 show that the EED results in both
BDMS communication sessions are increased gradually
with no significant difference between them when the
number of connected nodes is 120 or less.
On the other hand, the following figure (Fig. 7) shows a
comparison between the throughput results of the two types
of BDMS (v4-to-v6 and v6-to-v4) communication sessions.
BDMS Throughput vs. Connected Nodes
0
20
40
60
80
100
120
6 20 50 80 120 150 180 210 240
No. of Connecte d Nodes
Throughput (% )
BDMS-v4-to-v6
BDMS-v6-to-v4
Figure 7: A comparison between the Throughput results of the v4-to-
v6 BDMS and v6-to-v4 BDMS communication sessions.
It is obvious in Figure 7 that the throughput result in both
BDMS communication sessions is close to each other when
the number of connected nodes is 120 or less. In addition,
the difference in throughput results between the two types
of BDMS communication sessions suddenly increases
when the number of connected nodes becomes more than
120 due to the impact of the IPv6 header (40 bytes) size
compared to IPv4 header (20 bytes) size that causes more
traffic overhead which may lead to network congestion to
be occurred and effects on the transmitted packets through
the BDMS translator.
C. Scenario three simulation results
The simulation results for scenario three present the EED
and Throughput performance metrics results when v6-to-v4
communication session has been conducted through the
intermediate DSTM gateway that falls in the middle
between the two different networks (as shown in Fig. 3).
The simulation results of this scenario are illustrated in Fig.
8 and Fig. 9.
EED vs. Conne cted Node s
0.000
0.500
1.000
1.500
2.000
2.500
6 20 50 80 120 150 180 210 240
No. of Connected Nodes
EED (sec.
)
DSTM-v6-to-v4
Figure 8: EED of the DSTM communication session.
Figure 8 shows that the EED increases gradually when the
number of connected nodes increases. But the DSTM EED
result suddenly becomes very large when the number of
connected nodes becomes more than 120 due to the impact
of the tunneling (encapsulation and decapsulation) process
that may lead to network congestion at the DSTM TEP
which causes more delay for the transmitted packets.
DSTM Throughput vs. Connected Nodes
0
20
40
60
80
100
120
6 20 50 80 120 150 180 210 240
No. of Connecte d Nodes
Throughput ( %
)
DSTM-v6-to-v4
Figure 9: Throughput result of the DSTM communication session.
Figure 9 shows the impact of the tunneling process in the
DSTM mechanism that leads the throughput result to be
decreased when the number of connected nodes becomes
large (i.e. > 80 nodes).
D. Simulation Results Discussion
In this section, we discuss the simulation results (EED and
Throughput) for all scenarios that have been used in this
paper.
The following figure (Fig. 10) shows a comparison
between the EED results for the five types of
communication sessions.
EED vs. Connected Nodes
0.000
0.300
0.600
0.900
1.200
1.500
1.800
2.100
2.400
6 20 50 80 120 150 180 210 240
No. of Connect ied Nodes
EED(sec.)
BDMS-v4-to-v6 v4-to-v4
v6-to-v6 BDMS-v6-to-v4
DSTM-v6-to-v4
Figure 10: A comparison between the EED results of the DSTM,
BDMS and Direct-link connections.
The EED of v4-to-v4 communication sessions is less than
the EED of the other types of communication sessions (v6-
to-v6, v4-to-v6 BDMS, v6-to-v4 BDMS, and v6-to-v4
DSTM). Also, the EED of DSTM becomes larger than the
EED of the other types of communication sessions in
scenarios one and two especially when the number of
connected nodes becomes greater than 80. In addition, the
impact of the mapping and translation processes in the
BDMS mechanism is minimal compared with the tunneling
(IPv4-over-IPv6) process in the DSTM mechanism
especially when the number of connected nodes becomes
large (i.e. > 80).
On the other hand, Fig. 11 shows that the v6-to-v4 DSTM
throughput result is less than the throughput result of the
BDMS and direct-link communication sessions.
Throughput vs. Connected Nodes
30
40
50
60
70
80
90
100
110
6 20 50 80 120 150 180 210 240
No. of Connected Nodes
Throughput (%)
BDMS-v4-to-v6 v4-to-v4
v6-to-v6 BDMS-v6-to-v4
DSTM-v6-to-v4
Figure 11: A comparison between the Throughput results of the
DSTM, BDMS and Direct-link connections.
In addition, it is obvious in Figure 11 that the impact of the
mapping and translation processes in the BDMS
mechanism is smaller than the impact of tunneling process
in the DSTM mechanism especially when the number of
connected nodes is large (i.e. > 80 nodes). Therefore, the
throughput results of v6-to-v4 DSTM communication
session is small compared with the other types of
communication sessions (in scenarios 1 and 2) due to the
impact of the tunneling (encapsulation and decapsulation)
process that may lead to network congestion which reduces
its throughput.
5. Conclusions
In this paper, three scenarios have been conducted in order
to study the behavior of the BDMS transition mechanism
compared to the DSTM and direct-link (v4-to-v4 and v6-
to-v6) connections when a variety of traffic loads are used.
In fact, we chose to model direct-link (i.e. no conversion
and no tunneling) as a base line performance measure
against which to compare candidate translation/mapping
mechanism.
The simulation results in this paper have shown the impact
of the translation process that includes performing of
address mapping as well as the header conversion process
which are needed to be conducted for each incoming and
outgoing packet to and from the BDMS translator as well
as the impact of the tunneling process in the DSTM
mechanism. Therefore, the EED of the v6-to-v4 DSTM
communication session is large compared with the EED of
the other types of communication sessions due to impact of
the tunneling process that causes more delay. In addition,
the throughput of v6-to-v4 DSTM communication session
is small compared with the throughput of the other types of
communication sessions in scenarios one and two due to
the impact of the tunneling process that may lead to
network congestion which causes more reducing in the
throughput.
The OMNeT++ simulator platform is used in this paper
with a variety of traffic loads.
References
[1] J. Postel, “Internet Protocol”, RFC 791, September
1981. http://www.ietf.org/rfc/rfc791.txt
[2] H. Afifi, L. Toutain, ”Methods for IPv4-IPv6
Transition”, IEEE, pp. 478 – 484, July 1999.
[3] H. Lee, M. Shin, H. Kim, and K. Park, “Design and
Implementation of Windows based DSTM Client”,
IEEEICACT, Vol. 2, pp. 809-812, 2004.
[4] S. Deering and R. Hinden, “Internet Protocol, Version 6
(IPv6) Specification”, RFC 2460, December 1998.
http://www.ietf.org/rfc/rfc2460.txt
[5] K. Egevang, and P. Francis, “The IP Network Address
Translator (NAT)”, RFC 1631, May, 1994.
http://www.faqs.org/rfcs/rfc1631.html
[6] S. Rowe and M. Schuh, “Computer Networking”,
International Edition, Pearson Education, 2005.
[7] X. Zhou, M. Jacobsson, H. Uijterwaal, and P. Mieghem,
“IPv6 delay and loss performance evolution”, International
Journal of Communication Systems, Wiley InterScience,
pp. 1099-1131, 2007. http://www.interscience.wiley.com
[8] D. Green, M. Fiuczynski, and E. Jankiewicz, “IPv6
Translation for IPv4 Embedded Systems”, IEEE MILCOM
Conference, Vol.4, pp. 2519-2525, 17-20 October 2005.
[9] IETF Next Generation Transition (ngtrans) Working
Group, http://www.ietf.org/html.charters/ngtrans-charter.html
[10] J. Bi, J. Wu, and X. Leng, “IPv4/IPv6 Transition
Technologies and Univer6 Architecture”, IJCSNS, Vol. 7,
No. 1, pp. 232-242, January 2007.
[11] N. Oliver and V. Oliver, “Computer Networks
Principle, Technologies and Protocols for Network
Design”, John Wiley and Sons, England 2006.
[12] J. Kurose and K. Ross, “Computer Networking A Top-
Down Approach Featuring the Internet”, Pearson
Education, New York 2003.
[13] J. Wiljakka, “Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks”, RFC
4215, October 2005.
[14] A.H. Arifin, et al., “An Economical IPv4-to-IPv6
Transition Model: -A case study for University Network-”,
IJCSNS, Vol. 6, Issue 11, November 2006.
[15] R. AlJa'afreh, J. Mellor, M. Kamala, and B. Kasasbeh,
“Bi-directional Mapping System as a New IPv4/IPv6
Translation Mechanism,” UKSim, pp. 40-45, Tenth
International Conference on Computer Modeling and
Simulation (UKSim 2008), UK, April, 2008.
[16] J. Bound, “Dual Stack Transition Mechanism
(DSTM)“, IETF Internet Draft, April, 2004. [Online].
Available:http://www.ietf.org/Proceedings/04aug/I-D/draft-
bound-dstm-exp-01.txt
[17] “OMNeT++ Discrete Event Simulation System”,
http://www.omnetpp.org
