Optimized Convergence of OSPFv3 in Large Scale
Hybrid IPv4-IPv6 Network
Zeeshan Ashraf
Department of CS & IT
University of Sargodha, Sub-Campus
Mandi Bahauddin, Pakistan
zeeshan.np@gmail.com
Abstract—The fast growth of the Internet has resulted in
IPv4 addresses depletion. Internet Service Providers (ISPs) are
trying to replace their IPv4 networks with IPv6 gradually. IPv6
was launched with new features like simpler header format,
larger address space, efficient routing and built-in security.
IPv4-IPv6 transition process has been slow therefore both
versions of IP are expected to co-exist for some time. As IPv4
and IPv6 are not compatible to each other, therefore packet
traversing and routing has to face challenges. Tunneling is a
temporary solution which is used to resolve packet traversing.
This research presents the behavioral analysis of Open Shortest
Path First (OSPFv3) through several IPv6 tunneling protocols
(6in4, 6to4, ISATAP & GRE) over large scale IPv4 network. The
performance of OSPFv3 is measured through route
summarization over hybrid IPv4-IPv6 network on the basis of
numerous parameters like convergence & re-convergence time,
round trip time, response time, tunnel overhead and protocol
traffic statistics.
Keywords—Routing, OSPFv3, Tunneling, Hybrid IPv4-IPv6,
Route Summarization
I. INTRODUCTION
The fast growth of the Internet has resulted IPv4 addresses
shattered in 2011. IPv6 protocol has been launched in 1990 by
“Internet Engineering Task Force” (IETF) with new features
such as small size of header, larger address space, built-in
security, efficient routing and better QoS [1]. After over
twenty five years, transition from IPv4 towards IPv6 has
completed approximately 10 - 15 % around the world [2].
Transition process is very slow because thousands of million
devices are using IPv4 addresses throughout the world; it is
not easy to transfer at once. The Internet Service Providers
(ISPs) are trying to replace their IPv4 networks with IPv6
gradually. In the result, both versions of IP protocols are
needed to co-exist for a long time and they are not compatible
to each other. The core issues between these two protocols are:
compatibility and interoperability. It means, both protocols
can’t communicate with each other directly. It creates many
challenges like packet traversing in hybrid network.
Tunneling is used to resolve packet traversing issue.
Tunneling method is considered as temporary solution until
all ISPs would support IPv6. There are several IPv6 tunneling
methods [3]. Some techniques are static while others are
dynamic.
Routing is also a challenging task for network
administrators in a large scale complex network. In
internetwork, multiple paths may exist from source to
destination. Routing refers to determine and select the best
route from source to destination [4]. RIP, IGRP, EIGRP &
OSPF are IPv4 supported interior gateway routing protocols
while RIPng, EIGRPv6 and OSPFv3 are IPv6 supported.
These protocols are different to each other in terms of
configuration technique, convergence speed, metrics,
administrative distance and performance [5]. In hybrid IPv4-
IPv6 network, network administrator is needed to configure
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
Muhammad Yousaf
Faculty of Computing
Riphah International University
Islamabad, Pakistan
muhammad.yousaf@riphah.edu.pk
both types of routing protocols in order to reach specific
requirement. Professionals use OSPF widely in corporate and
enterprise networks due to its hierarchical nature and open
standard [6].
In corporate network, a core router can store millions of
routes in its memory. Routers exchange routes with each other
during convergence. Larger size of the routing table needs
extra time. Route Summarization technique is adopted in
routing protocols. It reduces the size of the routing table and
to minimize the convergence time. Route summarization
optimizes routing process and sends similar routes as merged
during convergence [4]. Merged routes are displayed as a
summary route in the routing table.
This research focuses on the behavioral analysis of
OSPFv3 through several IPv6 tunneling protocols (6in4, 6to4,
ISATAP & GRE) over large scale IPv4 network. The
performance of OSPFv3 is tested through merged routes over
hybrid IPv4-IPv6 network on the basis of round trip time
(RTT), convergence & re-convergence time, tunnel overhead,
response time and protocol traffic statistics. To achieve these
goals, we configured and measured the performance of
OSPFv3 with different IPv6 tunneling protocols over large
scale IPv4 network with the help of GNS3 simulator and
concluded the results. The rest of the paper is structured as
follows. Related work is presented in Section II. In Section III,
OSPFv3 routing protocol is described. Section IV highlights a
brief description of IPv6 tunneling mechanisms. In section V,
performance analysis is done and experimental results are
displayed. Finally, section VI concludes the paper.
II. RELATED WORK
There is copious research on IPv6 tunneling protocols
related topics and their performance comparisons in different
small and medium size of networks. In [7-9], the researchers
analyzed and measured the most common tunneling protocols
(ISATAP, 6to4, 6RD & GRE) on mathematical basis and
deployed the same test-bed setup by using GNS3 simulator.
They measured the performance of tunneling protocols over
parameters like (RTT, jitter, data transmission, throughput,
end-to-end delay & tunneling overhead) in terms of TCP and
UDP without routing protocols. They have concluded that
ISATAP has shown better performance in most of the
parameters than the rest of other tunneling protocols while
6to4 shown the worst performance in most of the cases. In
[10], the authors compared and analyzed the performance of
6to4 relay implementations with different versions of Linux.
They measured packet loss, response time and CPU utilization
and memory consumption of the computers running the tested
6to4 relay implementation. They observed that sit under Linux
provided the best performance and average response time
under all investigated load conditions. In [11-12], the
researchers compared and evaluated the performance of IPv6
tunneling protocols (Tredo, ISATAP, 6to4 & 6in4) with two
different variants of Linux (Fedora & Ubuntu). They
measured the performance of TCP, UDP audio streaming,
video streaming and ICMP traffic on the basis of different
parameters (jitter, throughput, CPU usage tunneling overhead,
query delay & auxiliary device’s requirement). They observed
that ISATAP protocol has advantages over Teredo and 6to4
protocols in all the parameters except jitter. In all these studies,
the authors configured static routing and examined user
traffic. In contrast, we are comparing the performance and
behavioral analysis of most commonly used IPv6 tunneling
protocols with routing protocol (OSPF) in large scale and
complex heterogeneous network.
Other closely related work is presented in [13]. In this
study, the authors compared the performance of several IPv6
tunneling protocols (6to4, GRE & 6in4) with dual-stack and
native IPv6 over MPLS using an OPNET simulator. They
analyzed the performance of different types of user’s traffic
such as (email, file transfer, telnet, video over IP, VoIP & web
browsing) on different transition techniques on the basis of
numerous parameters like jitter, end-to-end delay and
throughput. They concluded that the performance of dual-
stack is better than other techniques.
In [14], the authors analyzed the performance of two
tunneling protocols (6to4 & 6in4) on the basis of bandwidth
occupied by routing traffic, network resources consumed
during cold start and convergence by using OPNET simulator.
The researchers configured RIP and RIPng protocols for
routing in their experiments. RIP is a distance vector routing
protocol and is applied on small and medium size networks
and it is not suitable for large network. In contrast, we are
measuring the performance of OSPF in large scale network.
In [15], the researchers compared the performance of two
routing protocols (OSPFv3 & EIGRPv6) on the basis of
different parameters like (convergence speed, tunneling
overhead, hello message exchange, RTT and CPU & memory
utilization) with IPv6 tunneling protocol (6in4) by using GNS
simulator. They examined that the recital of OSPFv3 is
superior than EIGRPv6 in most of the parameters. In addition,
we are measuring and comparing the performance of OSPFv3
in some additional tunneling protocols.
III. OSPFV3
In 1999, IETF released a new version of OSPF with some
changes for IPv6 and named it OSPFv3 [16]. Version 3 of the
OSPF was specified in RFC 2740. It is a link state routing
protocol. It uses Dijkstra algorithm to compute the best route.
Its metric is cost which is used to calculate the best path shown
in (1) below. It advertises only incremental change instead of
full routing table whenever the topological change occur in the
network. It detects any topological change in the network
quickly and re-calculates new loop-free routes after re-
convergence. It uses 32-bits router IDs and this ID is used to
identify the router within an AS.
= (1)
The basic mechanisms of OSPF remained same in new
version. However, some changes have been needed because
both IPv4 and IPv6 protocols are not inter-operable. These
changes were also necessary to handle the large size of IPv6
addresses. In OSPFv3, some fields have been removed from
packet header that’s why header size is short. The way of
Hello packet send has been changed. The interface ID is
copied into the Hello packet and then send it. New LSAs (link-
LSA & intra-area-prefix-LSA) have been introduced in new
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©2018 IEEE
version to carry IPv6 addresses and prefixes. Link-LSA has
link-local flooding scope. It is never flooded beyond the link
with which it is associated. Intra-area-prefix-LSA carries all
IPv6 prefix information. Now OSPFv3 runs per-link basis
instead of per-IP-subnet basis. Authentication has been
removed in new version of the OSPF protocol and it depends
upon built-in security features in IPv6. Neighbor routers are
now always identified by its router-id in new version and it is
still 32-bit IP address. In old version, it may be identified by
IP addresses.
IV. IPV6 TUNNELING
Both IPv4 and IPv6 protocols are different in nature and
are not compatible to each other. When both protocols co-exist
then users face packet traversing issue between heterogeneous
networks. In heterogeneous networks, users are mixed. Some
users are using IPv4 addresses while some others are using
IPv6. The connectivity will cross one or more IPv4-IPv6
network borders. To resolve this issue over heterogeneous
networks, an artificial inter-operability functionality
(tunneling) is used [17]. Tunneling is a temporary method
until all the network will move to IPv6. IPv6 tunnel is a virtual
connection between two endpoints (nodes) over the IPv4
network [18]. Tunnel carries the IPv6 traffic in order to
encapsulate the IPv6 packets inside IPv4 header then to route
it over IPv4 network as shown in Fig.1.
Fig. 1. IPv6 Encapsulation
One node encapsulates the original packet and forwards
this encapsulated packet through tunnel. The other node
receives encapsulated packet, decapsulates the packet and
forwards this original packet towards its destination. The
encapsulator node is called source of the tunnel’s packet and
the decapsulator node is called the destination of the tunnel’s
packet.
Several IPv6 tunneling methods have been proposed over
time [3]. Some techniques are static while others are
dynamic.
• Configured (6in4) Tunnel
• 6to4 Tunnel
• ISATAP Tunnel
• GRE Tunnel
A. Configured (6in4) Tunnel
Configured tunnel is a static tunnel. It is configured as
point-to-point [19]. It is one of the oldest tunneling
mechanism. In this mechanism, both endpoints are manually
configured. The IPv6 addresses of tunnel’s endpoints belong
to the same subnet. In this case, “2001:0:5::/64” subnet is used
for tunnel addresses. The tunnel source and destination (IPv4
addresses) are defined as it is displayed in Fig. 2.
A fixed virtual link is established between two IPv6
endpoints by using protocol 41 encapsulation over the IPv4
network. Protocol 41 is a communication protocol which
embeds IPv6 packets inside IPv4 packets. It is a simple
encapsulation method in which an IPv4 header is added in
front of the IPv6 header. That’s why, it is also known as “IPv6
in IPv4” tunnel [20]. In IPv4 header, 41 value is set to the
protocol field as it is highlighted in the Fig. 3 given below.
This tunnel is sometimes also called “manual tunnel” or “static
tunnel”. Due to static behavior, it observes any change in the
network quickly. It is not scalable because it must be
configured statically. Configured tunnel is commonly
implemented because its configuration is simple. It can be
configured in several methods like (Router-to-Router, Host-
to-Router & Host-to-Host). When the packet is de-capsulated
on receiving side, encapsulating IPv4 header is discarded and
the original IPv6 header is not modified.
Fig. 2. 6in4 Tunnel
Fig. 3. Protocol 41 Encapsulation
B. 6to4 Tunnel
The 6to4 is a dynamic and point-to-multipoint tunnel. It
allows endpoints to transfer data over IPv4 network without
pre-configuring tunnels. In automatic tunnels, tunnel’s
endpoints addresses are used by special IPv6 addresses. These
special addresses are determined by the IPv4-compatible
destination addresses [19]. The IANA has permanently
assigned IPv6 address “2002::/16” to 6to4 tunnel [21]. Both
endpoints are automatically configured with this global IPv6
address prefix. The addresses of tunnel endpoints always
belong to different subnets instead of same subnet as in 6in4
tunnel because 32-bit IPv4 address is embedded. In this
scenario, after embedded 32-bit IPv4 addresses the subnets
are: “2002:C0A8:101::/48” and “2002:C0A8:402::/48”
respectively as it is shown in the Fig. 4.
Fig. 4. 6to4 Tunnel
It uses to allocate a global IPv6 address. This tunnel was
introduced to remove the configuration complexity in the
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©2018 IEEE
configured tunnel. It is not a secure tunnel. It generates the
chance of DoS/DDoS threats in the network [22]. In this
tunnel, only tunnel source IPv4 address is defined while tunnel
destination address is unknown.
OSPFv3 uses the link-local addresses for peering in this
type of tunnel. The OSPFv3 sends multicast packets to
“FF02::5”. It manipulates for OSPFv3 process to send unicast
packets. Therefore, its network type changed to non-broadcast
and specify the neighbors with link-local addresses. It does not
perceive any change in the network quickly. It waits until the
dead timer expired. The encapsulation method is same as
mentioned in configured tunnel. The IPv4 header contains the
source and destination IPv4 addresses.
C. ISATAP Tunnel
Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP) is a point-to-multipoint and automatic tunnel. It is
similar to 6over4 tunnel but it uses a “Non-Broadcast Multi
Access” (NBMA) communication mode [23]. It does not
support multicast. ISATAP hosts use IPv6 “Stateless Address
Auto Configuration” (SLAAC). In order to obtain a EUI-64
prefix, host sends a unicast “Router Solicitation” (RS)
message to an ISATAP router. It works in two modes: server-
to-server and client-to-server. Like 6to4 tunnel, only tunnel
source address is defined and the tunnel destination is
unknown. In this state, “2001:0:5::/64” subnet is used for
tunnel. The interface address which is assigned to the ISATAP
host is the combination of the router’s prefix and IPv4 address
as shown in the Fig. 5.
Fig. 5. ISATAP Tunnel
It means that each IPv4 address provides only one ISATAP
address indeed [24]. For OSPFv3, its network type changed to
“point-to-multipoint non-broadcast” and specify the
neighbors with link-local addresses. It does not implement any
change in the network quickly and waits until the dead timer
expired. It also uses the same encapsulation method which is
used in configured tunnel. It is implemented almost in all the
operating systems of Microsoft, Linux and CISCO IOS.
D. GRE Tunnel
Generic Routing Encapsulation (GRE) is a generic and
point-to-point tunnel. It is developed by CISCO systems [25].
It is also a static tunnel. Generic means, it allows many other
protocols to be encapsulated in IP. The encapsulation method
of GRE is different from configured tunnel and it has shown
in the Fig. 6.
Fig. 6. GRE Encapsulation
 The GRE header causes an extra overhead of 8 to 16 byes.
In first phase, payload is encapsulated in a GRE header. In
second phase, the resulting GRE packet once again
encapsulated in some other protocol (IPv4) header and then it
is forwarded [26]. The outer protocol header is called delivery
protocol. GRE sets 47 value in the protocol field of IPv4
header.
In GRE, both endpoints are pre-configured manually such
that in configured tunnel. The source and destination IPv4
addresses of the tunnel are defined. The IPv6 addresses of
tunnel endpoints belong to the same subnet. In this scenario,
“2001:0:5::/64” subnet is used for tunnel interfaces as it is
highlighted in the Fig. 7. It also perceives any network change
quickly. It can encapsulate a wide variety of protocol’s
packets, not only IPv6 packets. When GRE traffic is passed
through a firewall then firewall will block this type of traffic
by default. Network administrator is needed to open protocol
type 47 datagrams which are moving both sides of the remote
tunnel endpoint [22].
Fig. 7. GRE Tunnel
V. EXPERIMENTS AND RESULTS
Experimental setup for this study is described as in Fig. 8.
In this experimental topology, five “CISCO 7200” series
routers are directly linked with each other through serial links
in IPv4 network.
Fig. 8. Experimental Setup
In this test-bed, two routers (R-1 & R-5) are dual-stack
routers and these two routers are also called endpoints of the
tunnel. Two IPv6 supported virtual client machines (PC-1 &
PC-2) are also attached with endpoints over fastEthernet links.
All the experiments are tested on GNS3 network
simulator. It is an easy, inexpensive and more convenient to
work with simulator instead of real devices. Some simulators
do not support all type of IPv6 tunneling protocols with
OSPFv3. GNS3 is used to simulate complex and large
networks. The dynamips emulation software is used in it to
simulate CISCO and other brands of IOSs. The dynamips is a
computer program which is used to emulate the hardware of
several brands and load an actual IOS directly. That’s why we
can say that the results we obtained through GNS simulator
are very close to the results obtained by real routers.
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©2018 IEEE
The description of the devices are shown in Table-I.
Router-to-Router tunneling layout is used for all IPv6 tuning
protocols in this topology over IPv4 network which is most
common.
TABLE I DEVICES AND DETAILS OF THE EXPERIMENTAL SETUP
No Device Description
01 Router CISCO 7200 series
IOS “c7200-adventerprisek9-mz.124-11.T1.bin”
Total = 5
02 PC IPv6 Supported Virtual Machines
Total = 2
For IPv4 network, OSPFv2 is selected as routing protocol
while OSPFv3 for IPv6. IPv4 network is divided into multiple
areas. Router-3 is in backbone area with its one interface is
connected to Router-2 and one interface is connected with
Router-4. Area 10 exists between Rotuer-1 and Router-2. And
area 20 exists between Router-4 and Router-5. Both areas are
directly connected with backbone area. So, there is no need of
virtual link in this topology. There are fifteen loopback
interfaces on Router-1 with IPv6 addresses. There are also
fifty static routes with IPv6 addresses on Router-1 which are
assumed to redirect from other networks. During all these
experiments, all the IPv6 routes of Router-1 are advertised as
a calculated summary address “2001::/32” through different
types of IPv6 tunnels over IPv4 network as shown in Fig. 9
and then results are collected. It can be observed that a single
external route is in routing table instead of multiple routes.
The summary increases the performance of routing protocols
[14].
Fig. 9. Routing Table of Router-5
Data is captured through whireshark tool as well as
different router’s commands during experiments. The
whireshark is a most popular network protocol analyzer. It
captures the packet and display its detail for analysis. All tests
are repeated several times (5 times) during different times of
the different days. And then it took mean of these results. The
experimental setup and time duration remained same for all
tunneling protocols. Performance evaluation of OSPFv3
through different IPv6 tunneling protocols is measured based
upon convergence time, delay, response time, hello packets
send/receive, tunneling overhead and CPU utilization in large
scale hybrid IPv4-IPv6 network.
A. Convergence Time through Tunnels
A router is said to be in a convergence state when it is
sharing its routing & topological information between other
routers in the network. In convergence period, routers are only
sharing topological information and routes. After
convergence, its routing table is completed. It is measured as
how fast a router completes its routing table and becomes TABLE II RTT
ready for user traffic [13]. It is an important parameter for S# Protocol Mean S. Deviation CV
routing protocols in complex and large scale network. The (ms) (ms) (ms)
number of routes and the network complexity also play an 1 6in4 216.12 17.79 8.23
important role in convergence time. In this study, network is 2 6to4 277.86 40.46 14.56
hybrid. Both versions of OSPF must be configured. 3 ISATAP 271.50 35.41 13.04
4 GRE 198.82 25.63 12.89
Convergence and re-convergence times of OSPFv3 are
calculated over different tunneling protocols with route Table-II describes the CV results of different tunneling
optimization technique and shown in the Fig. 10 below. protocols to determine the validity. S is represented as
standard deviation and is symbolized the mean. It is viewed
The convergence times of OSPFv3 over different that RTT of 6in4 protocol is much better than all others
tunneling protocols are calculated on “Router-5” from “up protocols while the RTT of 6to4 is comparatively bad.
state of the serial interface” to “adjacent state of tunnel
interface”. It is perceived that OSPFv3 with 6in4 provides fast C. Response Time through Tunnels
convergence while convergence of 6to4 is very slow. It is due It is a measure of the amount of time required for a packet
to that the 6in4 tunnel is static and pre-configured while 6to4 to travel across a network path from a sender to a receiver. It
tunnel is dynamic. is also measured in milliseconds for different echo request
from PC-2 to loopback-1 interface over different tunneling
protocols. Fig. 12 highlights average response time.

Fig. 10. Convergence Time

Fig. 12. Response Time

B. Round Trip Time (RTT) through Tunnels
It is the total time required for a packet to travel from a Table-III shows the calculated CV of response time over
specific source to a specific destination. It is said to be very different tunneling protocols.
important parameter in the network layer. The “Internet
Control Message Protocol” (ICMP) is used behind the ping TABLE III RESPONSE TIME
command to get the RTT results [7]. General formula for
S# Protocol Mean S. Deviation CV
calculating RTT is given below (2). (ms) (ms) (ms)
1 6in4 28.90 8.71 30.15
2 6to4 50.53 18.31 36.23
3 ISATAP 50.78 16.11 31.73
4 GRE 32.65 11.28 34.54
Once again the results show that the performance of 6in4
is faster than other tunneling protocols while the response time
of 6to4 is worst. But keep in mind that 6in4 is only point-to-
point and static tunnel while 6to4 is a point-to-multipoint,
automatic and scalable tunnel.
D. Tunnel Overhead
Fig. 11. Round Trip Time
The tunneling overhead is the combination of several
T = TimestampPacketXSent + TimestampAckXRecv (2) overheads that participate in tunnel creating, tunnel deleting,
encapsulation, decapsulation and tunnel maintaining [9]. The
An average RTT for N number echo requests is calculated tunneling overhead can be found through subtraction of each
as: protocol’s round trip time against the round trip time of native
∑ traffic as:
∆ = (3)
Tunnel Overhead = RTTtunnel – RTT native (5)
It measures in milliseconds. Fig. 11 shows the average
RTT results over different tunnels from source (PC-2) to Fig. 13 displays the status of tunnels. Results are acquired
destination (Loopback-1) interface. If the endpoint address with equal time frame (9 mints). Tunnel status is measured on
does not exist in router, then the router will discard the request. R-1 by using “show interface tunnel 0 status” command.
Numbers show that R-1 sent 24 packets to its neighbor and
These results are not clear. It shows variation in the results. received only 34 through ISATAP tunnel. It can be observed
It needs to calculate discrete value. The precise results can be that performance of static tunnels is the worst as compared to
calculated through “Coefficient of Variation” (CV) for such automatic tunnels.
kind of variation (4).
= ∗ 100 (4)

XXX-X-XXXX-XXXX-X/XX/$XX.00 ©2018 IEEE


Fig. 13. Tunnel Overhead
E. OSPFv3 Traffic Statistics through Tunnel
Fig. 14 highlights the statistics of Hello packets
send/receive with same time quantum (6 mints) in idle state
through different tunneling protocols.
Researchers took data from different tunneling protocols
by using “show ipv6 ospf 1 traffic” command on Router-1.
Results indicate that during this time interim, OSPFv3 has sent
11 Hello packets to its neighbor and received only 10 Hello
packets though ISATAP tunnel.
Fig. 14. Hello Packet Statistics
It can also be viewed that the performance of static tunnels
in this setup, is also the worst while the performance of
automatic tunnels is better.
VI. CONCLUSION
This research focused on transition mechanisms from IPv4
to IPv6 in large scale complex network. This is important for
those ISPs which want to implement IPv6 over IPv4 and are
concerned about which method is more suitable according to
network performance requirement. In this study, we examined
route summarization in OSPFv3 over different static and
dynamic IPv6 tunneling protocols (6in4, 6to4, ISATAP &
GRE) over large scale IPv4 network. Experimental results
indicated that the performance of OSPFv3 with static (6in4)
tunneling protocol is better than all others for most of the
parameters like convergence & re-convergence time, response
time, RTT, tunnel overhead and traffic statistics. We therefore
recommend it as the most appropriate tunneling mechanism
for site-to-site tunneling on the basis of network performance
measurement.
REFERENCES
[1] S. E. Deering and R. Hinden, "Internet protocol, version 6 (IPv6)
specification," RFC 2460, 1998.
[2] I. v. Beijnum, “IPv6 celebrates its 20th birthday by reaching 10 percent
deployment”, 2016, Available:
http://arstechnica.com/business/2016/01/ipv6-celebrates-its-20th-
birthday-by-reaching-10-percent-deployment/
[3] S. Steffann, I. van Beijnum, and R. van Rein, "A comparison of IPv6-
over-IPv4 tunnel mechanisms", RFC 7059, 2013.
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©2018 IEEE
[4] C. Carthern, W. Wilson, R. Bedwell, and N. Rivera, "Advanced
Routing," in Cisco Networks, ed: Springer, 2015, pp. 425-479.
[5] D. Chauhan and S. Sharma, "Performance Evaluation of Different
Routing Protocols in IPv4 and IPv6 Networks on the Basis of Packet
Sizes," Procedia computer science, vol. 46, 2015, pp. 1072-1078.
[6] R. J. Whitfield and S. Y. Zhu, "A Comparison of OSPFv3 and
EIGRPv6 in a Small IPv6 Enterprise Network," Editorial Preface, vol.
6, 2015.
[7] T. Saraj, A. Hanan, M. S. Akbar, M. Yousaf, A. Qayyum, and M.
Tufail, "IPv6 tunneling protocols: Mathematical and testbed setup
performance analysis," in Information Assurance and Cyber Security
(CIACS), 2015 Conference on, 2015, pp. 62-68.
[8] M. Aazam, A. M. Syed, S. A. H. Shah, I. Khan, and M. Alam,
"Evaluation of 6to4 and ISATAP on a Test LAN," in Computers &
Informatics (ISCI), 2011 IEEE Symposium on, 2011, pp. 46-50.
[9] N. Bahaman, E. Hamid, and A. S. Prabuwono, "Network performance
evaluation of 6to4 tunneling," in Innovation Management and
Technology Research (ICIMTR), 2012 International Conference on,
2012, pp. 263-268.
[10] G. Lencse and S. Répás, "Performance analysis and comparison of 6to4
relay implementations," International Journal of Advanced Computer
Science and Applications, vol. 4, 2013, pp. 13-21.
[11] S. Narayan and S. Tauch, "IPv4-v6 configured tunnel and 6to4
transition mechanisms network performance evaluation on Linux
operating systems," in Signal Processing Systems (ICSPS), 2010 2nd
International Conference on, 2010, pp. V2-113-V2-117.
[12] M. Aazam and E.-N. Huh, "Impact of ipv4-ipv6 coexistence in cloud
virtualization environment," Annals of Telecommunications-annales
des Télécommunications, vol. 69, 2014, pp. 485-496.
[13] P. Grayeli, S. Sarkani, and T. Mazzuchi, "Performance analysis of IPv6
transition mechanisms over MPLS," International Journal of
Communication Networks and Information Security (IJCNIS), vol. 4,
2012.
[14] P. Amr and N. Abdelbaki, "Convergence study of IPv6 tunneling
techniques," in Communications (COMM), 2014 10th International
Conference on, 2014, pp. 1-6.
[15] Z. Ashraf and M. Yousaf, "Optimized routing information exchange in
hybrid IPv4-IPv6 network using OSPFV3 & EIGRPv6", vol. 8, 2017,
pp. 220-229.
[16] R. Coltun, D. Ferguson, and J. Moy, "OSPF for IPv6," RFC 2740,
1999.
[17] P. Wu, Y. Cui, J. Wu, J. Liu, and C. Metz, "Transition from IPv4 to
IPv6: A state-of-the-art survey," IEEE Communications Surveys &
Tutorials, vol. 15, 2013, pp. 1407-1424.
[18] A. Conta, S. E. Deering, "Generic packet tunneling in IPv6
specification", RFC 2473, 1998.
[19] E. Nordmark and R. Gilligan, "Basic transition mechanisms for IPv6
hosts and routers", RFC 4213, 2005.
[20] Tariq Saraj, Muhammad Yousaf, Sajjad Akbar, Amir Qayyum,
Mudassir Tufail, "ISP Independent Architecture (IIA) for IPv6 Packet
Traversing and Inter-Connectivity over Hybrid (IPv4/IPv6) Internet",
Elsevier Procedia Computer Science, Volume 32, 2014, pp 973-978.
[21] B. Carpenter and K. Moore, "Connection of IPv6 domains via IPv4
clouds", RFC 3556, 2001.
[22] J. S. Sansa-Otim and A. Mile, "IPv4 to IPv6 Transition Strategies for
Enterprise Networks in Developing Countries", in International
Conference on e-Infrastructure and e-Services for Developing
Countries, 2012, pp. 94-104.
[23] F. Templin, T. Gleeson, M. Talwar and D. Thaler, "Intra-site automatic
tunnel addressing protocol (ISATAP)", RFC 5214, 2008.
[24] M. Aazam, I. Khan, M. Alam, and A. Qayyum, "Comparison of IPv6
tunneled traffic of teredo and ISATAP over test-bed setup," in
Information and Emerging Technologies (ICIET), 2010 International
Conference on, 2010, pp. 1-4.
[25] Z. Ashraf, "Virtual private networks theory & practice", 2018.
[26] S. Hanks, D. Meyer, D. Farinacci, and P. Traina, "Generic routing
encapsulation (GRE)", RFC 2784, 2000.