Demonstrating the Impact of 6to4 Tunneling on IPV4 and IPV6 Network Coexistence

— In this work the impact of the 6to4 tunnels is considered. In order for traffic to flow from an Internet Protocol version 4(IPv4) website to a native Internet Protocol version 6(IPv6) website, an additional configuration must be added to the network, as this cannot be done by default. The Riverbed Modeler Academic Version 17.5 is used to build and evaluate network efficiency with optimized 6to4 tunnels. The performance of the network is assessed based on the traffic received and sent by Internet Protocol (Version 6), Voice Called Traffic and the Sent and Received Traffic of the configured applications. The flow of traffic from servers to workstations in native IPv6 sites shows the effect of the tunnel configured.


I. INTRODUCTION
End devices and nodes in a network require an IP (Internet Protocol) address to communicate. The address range of IP version 4 currently in use is not enough to address the increasing IP address requests [1]. Some techniques have been developed to handle the problem of address depletion such as Network Address Translation (NAT), Classless Inter Domain Routing (CIDR), Variable Length Subnet Mask (VLSM), and Port Address Translation (PAT). Internet Protocol, Version 6 (IPv6) was conceived by the Internet Engineering Task Force (IETF) to resolve the expected IPv4 address exhaustion issue. IPv6 is meant to replace IPv4 in the long run [2]. The IPv6 was built to provide ample address space for the internet's increased growth to the present and future demand. IPv6 raises the size of the IP address scheme from 32 bits in Version 4 to128 bits [3]. However, IPv6 has a number of new features over IPv4. IPv6 is not backward compatible with IPv4 with these improved features. The implication is that IPv6 hosts cannot interact directly with IPv4 hosts normally, and vice versa. Many transfer techniques have been introduced to ensure a quick, gradual and autonomous transfer to IPv6 with existing IPv4 networks, each of which has its own method of operation. These techniques are usually categorized into three main groups namely: Dual-stack, Tunneling and Translation [4].

II. TUNNELING
In the Tunneling method, the header of the packet is altered as it traverses from one protocol to another. IPv6 packets can then convert to IPv4 packets so that IPv6 network hosts can Published on September 30, 2020. E. Osa, Department of Electrical and Electronic Engineering, Faculty of Engineering, University of Benin, Nigeria.
(corresponding e-mail: edosa.osa uniben.edu) be interconnected via IPv4 backbone using IPv6 tunnels. The two oldest tunnel mechanisms originally published in 1996 are the Manual and Automatic [5]. Automatic tunnels are designed by embedding IPv4 address information into the IPv6 address packet, the IPv6 address of the destination host provides the information on which IPv4 address packet should be tunneled to [6]. However, the latest specifications for tunnel mechanisms include the following: • • Subnetwork Encapsulation and Adaptation Layer (SEAL) [7].
In 6to4 tunneling, the aim is to help those devices that are IPv6-enabled and reside in an IPv4 network, connect to other devices of the same configuration and to the IPv6-enabled Internet. This involves a "simple tunnel" that encapsulates IPv6 packets into IPv4 packets (by utilizing the protocol number '41'). This represents the IPv6 configured tunnel over IPv4 [6]. The IPv6 capable system can be a single device with a 6to4 pseudo-interface that encapsulates IPv6 packets in IPv4 packets and decapsulates IPv6 packets in the opposite direction. In this case it is called a 6to4 device. It is also possible for multiple IPv6 devices to exist in an IPv6 network behind a 6to4 border router which performs the encapsulation of the IPv6 packets into IPv4 packets and the decapsulation in the opposite direction. These 6to4 IPv6 devices can communicate with other 6to4 IPv6 devices or IPv6 devices on a native IPv6 Internet connection. However, in the latter case, a 6to4 relay mechanism is required at the IPv4 Internet and IPv6 Internet borders. If a link exists between two IPv6enabled devices that both use 6to4 tunneling, the path of travel for the encapsulated packet in the IPv4 network is set by the public IPv4 addresses of the two 6to4 hosts and routers. If a communication node resides in the native IPv6 internet, the packet must go through a 6to4 relay [8]. A simple way to identify an IPv6 6to4 address is that the first 16 bits are always 2002 (in hexadecimal as defined in RFC 3056). The next 32 bits will be the IPv4 address, following the RFC specification. Thereafter, a special IPv6 subnet [9] will be defined for the next 16 bits.

III. OPNET (RIVERBED MODELER)
OPNET (Optimized Network Engineering Tool) was introduced to the public in 1987 as the premier commercial communications network simulation tool [10], [11]. OPNET is considered to be highly useful due to its potential to simulate a wide variety of networking technologies. It allows an entire network to be modelled, including devices such as routers, switches, protocols, servers, and the specific applications that these devices support. OPNET models consist of three primary layers namely; process layer, node layer, and network layer. Generally, OPNET can perform three main functions such as modelling, simulating and analysis of networks. It provides a very simple but comprehensive graphical environment [12].

IV. RELATED WORKS
Different researches have considered the efficiency of transformation methods for IPv6. In [13] the 6to4 transition process and tunneling were empirically compared with the Windows 2000 operating system on a testbed setup. [14] demonstrated the ease of transmission of TCP data using 6to4 tunneling as opposed to native IPv4 and IPv6 networks. [8] experimented with the 6to4 form of transformation IPv6. For performance and stability testing Linux sit, FreeBSD stf, and NetBSD stf 6to4 relay implementations were selected. It defined the test environment and the measurement process. In [15] 6to4 tunneling is implemented over OpenSSH with more than one device. In this paper the routing of traffic from a 6to4 site via an ISP relay to a native IPv6 site is shown.

V. EXPERIMENT SETUP
In this experiment the OPNET (Riverbed) Modeler Academic Edition version 17.5 was used to run the network simulations with a specific tunnel configured as Tunnel 0. The network testbed containing the following objects was implemented as displayed in Figure 1: • Application Config. node: This module specified the applications supported by the network. The specified application name was used when constructing user profiles on the Profile Config object.
• Profile Config. node: The profile module described how the users implement the applications described in the Application configuration module.
• Four ethernet4_slip8_gtwy routers: Routers A, B, C and D.
• Four ethernet workstations: Workstations A, B, C and D.
• Two IP_32 Cloud objects: For the IPv4 and IPv6 backbones respectively.
• Two ppp_server_adv: For the Email and File Transfer Protocol (FTP) applications.
• One ethernet_server: For the Hyper Text Transfer Protocol (HTTP) application.
• One ethernet_server_adv: For the Database application.
• IP Attribute Config. Node. This sets the Ping Parameters for the network.

A. Traffic Description
There are two 6to4 sites in the network above namely, sites W and X respectively. The 6to4 tunneling is configured on routers A and C so that they can communicate with each other. However, in order to communicate with the native IPv6 site, Z, the traffic needs to be routed through an ISP relay (site Y). Packets traversing from site W or X to the native IPv6 site will first go to router B (Relay router) before they reach their eventual destination and vice versa. Tables 1 through 6 show the configuration for the various nodes in the network.

VII. DISCUSSION
For the nodes linked to the IPv4 cloud backbone as well as the IPv6 cloud backbone, there is IPv6 traffic flow across all locations within the network. This proves that there is some additional process, as IPv4 traffic cannot flow to a native IPv6 location, and vice versa by default. In this experiment the mechanism responsible is the 6to4 tunnel configured in the routers (i.e. Tunnel 0). Figure 4 shows that Workstation D sends and receives Email traffic, whereas the email server is located outside the native IPv6 site and Figure 5 shows that Workstation D sends and receives FTP traffic while the FTP server is located outside the native IPv6 network. This is because of design of the tunnel.

VIII. CONCLUSION
This simulation experiment was performed to demonstrate the impact of configuring 6to4 tunnel in a network that is made up of both IPv4 and IPv6 sites. It was shown that due to the configuration of tunnels it was possible for traffic to flow from non-native IPv6 sites to native IPv6 sites. Hence as the IPv4 depletion process is almost complete, Internet active organizations should consider the option of implementing 6to4 tunneling, as they migrate to an IPv4-IPv6 coexistence scenario.