IPv4-v6 Configured Tunnel and 6to4 Transition Mechanisms Network Performance Evaluation on Linux Operating Systems

Transcription

1 IPv4-v6 Configured Tunnel and 6to4 Transition Mechanisms Network Performance Evaluation on Linux Operating Systems Shaneel Narayan, Sotharith Tauch Unitec Institute of Technology, Department of Computing, Auckland, New Zealand Abstract Last few decades has brought many fundamental changes to data communications and the Internet. Internet has its roots in a networking project started by ARPA which consisted of four computers. Now the Internet spans the globe, and has become the default communication mechanism for businesses and individuals. IPv4 addresses will soon be exhausted, which has initiated development of IPv6. The new IP version provides solution to problems that were inherent in the earlier version, and also offers additional opportunities. However transition to the new version has been remarkably slow. Thus in the interim, various transition mechanisms can be employed. In this paper two such mechanisms, namely configured tunnel and 6to4 transition mechanism, have been empirically evaluated for performance. Both mechanisms are implemented on two different Linux distributions, and performance related metrics like throughput, delay, jitter and CPU usage of the transition end nodes are measured. The results obtained on the test-bed show that TCP/UDP throughput and jitter values of the two mechanisms are similar, but delay reading is significantly different depending on the choice of transition mechanism and operating system. Index Terms- IPv4, IPv6, transition mechanism, configured tunnel, 6to4, performance evaluation, Linux Fedora, Linux Ubuntu. I. INTRODUCTION Information technology continues to rapidly change in 21st century. Computers and networks are a prerequisite to almost all facades of human, business and societal activities. The Internet affects not only its users, but also computing technology itself. And communication links to Ver4 Time to live IHL Identification Type of service Protocol F l a g s Source address (32 bits) Total length Fragment offset Header checksum Ver6 Traffic class Payload Length Flow label Next header Source address (128 bits) Hop limit the Internet are a common feature to almost all computer systems. Information technology is a term that describes combination of computers and communication technologies. TCP/IP is the protocol suite that facilitates global Internet connectivity, and IPv4 is the current widely used version. However, depletion of IPv4 address has been a concern to users for a number of years now. This schema offers only 232 addresses. There are numerous predictions related to exhaustion of IPv4 addresses, all predictions indicate that this will happen soon rather than later. IPv6 fixes many shortages in IPv4, including the limited number of available IPv4 addresses. It also adds many improvements to IPv4 including: 340 undecillion IP addresses; plug and play configurations; better network bandwidth efficiency using multicast and anycast; better QOS support for all types of applications; native information security framework; and enhanced mobility with fast handover, better route optimization and hierarchical mobility. Migrating from IPv4 to IPv6 is complicated and cannot be done in a short period of time. The size and complexity of the Internet cause this migration task to become enormously difficult and time consuming undertaking. IETF took this migration issue into consideration and came up with transition mechanisms as interim solutions that allow IPv4 to be able to operate alongside IPv6 networks. These transition mechanisms are discussed in the next section, and performance of two such mechanism, configured tunnel and 6to4, is the subject of this research. In this paper, configured tunnel and 6to4 are implemented on two Linux based operating systems and performance related metrics have been measured on a test-bed setup. The rest of the paper is organized as follows: Section II contains a background on transition mechanisms, Section III discusses some of similar work undertaken by other researchers, and Section IV outlines the experimental setup used in this research. We present the results and discuss the findings in Section V. Finally, the research is concluded. II. BACKGROUND Destination address (32 bits) IP options Padding IPv4 Header Legend Fields kept Deleted fields Name and position change New field Destination address (128 bits) IPv6 Header Figure 1: IPv4 and IPv6 packet structure schematic Figure 2: IPv4-6 Configured Tunnel /$26.00 C 2010 IEEE V2-113

2 There are multiple solutions that can be employed to interoperate IPv4 and IPv6 nodes/networks together in the transition path to pure IPv6 networks. The easiest of all solutions is to implement dual IP layer on all IPv6 nodes, enabling these nodes to interoperate with IPv4 nodes using IPv4 packets, and also directly interoperate with IPv6 nodes using IPv6 packets. The problem with this solution is that it does not solve IPv4 address shortage problem. Also dual IP stacks make nodes resource inefficient. Tunneling IPv6 traffic through IPv4 network by encapsulating IPv6 datagrams within IPv4 packets can route IPv6 traffic through IPv4 network. Tunneling can be used in a variety of ways [1]: Router-to-Router: IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes. Host-to-Router: IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path. Host-to-Host: IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path that the packet takes. Router-to-Host: IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 host. This tunnel spans only the last segment of the end-to-end path. The way a node determines the address of the node at the end of a tunnel usually classifies the tunneling technique. In some techniques, intermediary router is present which decapsulates the IPv6 packet and forwards it on to its final destination and while in others IPv6 packets are sent all the way to the final destination. Router-to-Router and Host-to-Router use the former technique while the Host-to-Host and Routerto-Host is based on the latter. Irrespective of the tunnel classification, the tunnel end address may be determined automatically or maybe manually configured. In manually configured tunnel, aka configured tunnel, IPv6 address is manually configured on a tunnel interface and IPv4 addresses are manually configured at the tunnel source and the tunnel destination facilitating a point to point connection. III. RELATED RESEARCH Research pertaining to IPv6 relevant to this research is discussed here. In [2] and [3], an overview of the transition mechanisms is presented, grouped into three categories dual stacks, tunneling and translation. Technical issues related to deployment of IPv6 are also mentioned. In [4], error cases taken by harmful specification, poor implementations and wrong operation of IPv6 dual stack are mentioned. Constraints of various transition mechanisms are discussed in [5] and the authors mention that choice of the actual mechanism is site specific. Merits of dual stack transition mechanism (DSTM) are discussed in [6] with empirical evaluation of latency and response time of DNS traffic type on such networks. A similar research, in which personal experiences with implementation of DSTM on a test-bed, is the subject in [7]. In [8] implementation of an IPv6 network on a gigabit network infrastructure is presented and the experiences discussed. A feature of IPv6 that automatically discovers network topology between two routers, namely network topology discovery, is featured in [9]. Two transition mechanisms, Bi-directional Mapping System (BDMS) and DSTM is compared using simulation and shown that different performance results are ascertained in the two scenarios [10] [11]. Another two mechanisms, 6to4 and tunneling are empirically compared on a test-bed setup with Windows 2000 operating system in [12]. Application Layer Gateway (ALG) for IPv6, which translates application layer data in Network Address Translation - Protocol Translation (NAT-PT) transition mechanism is performance analyzed in [13]. Teredo mechanism, which was introduced to enable the hosts located behind one or multiple IPv4 NATs to obtain IPv6 nodes connectivity by tunneling packets over UDP, has been evaluated using simulation is [14]. Multiple transition mechanisms have been tested for performance in [15] [16] and shown that although overheads are minimal, performance degradation does occur as data traverses transition border. In this research undertaking, two transition mechanisms, 6to4 and configured tunnel has been network performance tested on a two Linux based operating systems. Typical performance related metrics are empirically measured on a testbed setup, discussed next. IV. EXPERIMENTAL SETUP Four computers (Intel Core 2 Duo E6300, GHz: RAM 2GB) were connected using Cat5e cables as in figure 2. All computers had two network interfaces (Broadcom Figure 2: Experimental Setup NetXtreme Gigabit and Ethernet Intel 100s Fast Ethernet) with computers at the ends using faster NICs. Computers at the ends acted as the client nodes while computers in the middle were configured as routers. Keeping all hardware constant, operating system software on all computers was changes to Linux Fedora 9.10 or Linux Ubuntu 11.0 at a time. With each operating system, IPv4, IPv6 or IPv4/IPv6 configured tunnel and 6to4 transition mechanism was implemented and performance related metrics were measured. These metrics values were measured using D-ITG [17] which measures by using two components of D-ITG which include ITG-Send and ITG-Receive. D-ITG is capable of producing traffic at packet level for both IDT (Inter Departure Time) and PS (Packet Size). D-ITG can be used to measure throughput, packet loss, delay, and jitter analysis across heterogeneous network such as wired network, wireless network, GPRS, and Bluetooth. And in this research, we V2-114

3 measured throughput, jitter and delay for both TCP and UDP traffic types. To ensure high data accuracy, all tests were executed 20 times, and to get the maximum throughput for a given packet size, each run had duration of 30 seconds. The results are presented and discussed next. V. RESULTS AND DISCUSSION We now present and discuss the results of this research. In Graph 1, TCP throughput values of the two operating systems with the two tunnel types are presented. Here is it seen that for most packet sizes, throughput values are almost identical. There is a dramatic difference in throughput values for packet size 64Bytes and the rest, with most values averaging approximately 85Mbps. It is noted that for packets 128 and 256Bytes, Ubuntu with configured tunnel values are approximately 5% lower than the rest of the throughput values. Theoretically, the maximum achievable throughput value is 100Mbps (due to the type of cable and network interface card used), however it is seen that TCP throughput values are almost 10-15% lower. TCP jitter values (Graph 2) show that there is consistency between the operating systems. For most packet sizes, jitter averages approximately 0.4ms with variations of approximately 0.2ms. Highest jitter values for all four scenarios are for the smallest packet size (64Bytes). Comparing delays experienced by the tunnels on the two operating systems (Graph 3), it is seen that there is a clear distinction between Fedora with configured tunnel and the other three scenarios (almost 10 fold). The former has average delay of approximately 1100ms and that for the other three operating systems is less than 200ms. Fedora with 6to4 as the transition mechanism has values marginally higher (200ms) than with that of Ubuntu with the two tunnel types. For both Ubuntu operating systems, delay is almost zero milliseconds. Finally CPU usage values on Router 1 and Router 2 are presented in graphs 4 and 5 respectively. In all scenarios, CPU usage is between 9 & 25% of total availability. There Graph 4: TCP CPU Usage Router 1 Graph 1: TCP Throughput Graph 5: TCP CPU Usage Router 2 Graph 2: TCP Jitter Graph 3: TCP Delay Graph 6: UDP Throughput V2-115

4 does not appear to be any distinct pattern between the operating systems or the tunnel types, however Fedora with configured tunnel registers lower CPU usage consistently on Router 1. Performance related metric values pertaining to UDP traffic type are presented next. UDP throughput values are shown in Graph 6 and it is seen that there is hardly any difference between the operating systems or the tunnel types for most packet sizes. Fedora with configured tunnel, with packet size of 128Bytes registers the lowest of all values, and for the others, the values gradually increase as packet sizes increase. For larger packets, most throughput values are between 80 and 90Mbps, with all operating systems reporting almost identical values. configured tunnel values almost close to 1200ms for all packet sizes. Fedora with 6to4 as the transition mechanism has values averaging 200ms for most packets sizes. Both Graph 9: UDP CPU Usage Router 1 Graph 7: UDP Jitter UDP jitter values show an interesting pattern (Graph 7). For almost all packet sizes, the operating systems and the two tunnel types give jitter values with hardly any variation. For packet sizes less than 1024Bytes, most values average around 0.25ms and for all packets larger than 1024Bytes, there is a steep incline in values with increased packet sizes. The highest jitter values for all four scenarios are evidently for the largest packet size of 1536Bytes. Graph 8: UDP Delay Delay values for the operating systems with the transition mechanisms are shown in Graph 8. A huge difference between the operating systems is shown, with Fedora with Graph 10: UDP CPU Usage Router 2 Ubuntu operating systems delay values are in close proximity to zero. It is seen that average delay values in all scenarios are constant for all packet sizes for each operating system and transition mechanism. Finally, UDP CPU values for both the routers are shown in Graphs 9 and 10. Most values are in the range 9 to 20% CPU usage. On router 1, it is seen that Fedora operating system with the both the transition mechanisms register lower values than the two Ubuntu scenarios. And for Router 2, there is no distinct pattern between the operating systems or the transition mechanisms. On comparing TCP and UDP performance metrics, throughput values show that for larger packets, the values for both traffic types are almost similar, but for some of the smaller packets (128 and 256Bytes) TCP values are significantly higher (almost 35%). This is true for both operating systems with both the transition mechanisms. Theoretically, UDP values should be higher (due to lack of error-checking, resending and similar), however this research results show that practically this is not the case. TCP and UDP jitter values, opposite trends exist for TCP largest jitter values are V2-116

5 for smaller packet sizes, but for UDP larger packet have comparatively higher jitter. Average jitter values for both traffic types is almost the same and in both cases Fedora with configured tunnel as the transition mechanism has substantially higher values for all packet sizes. Both graphs have lines similar in appearance, indicating that operating systems and the transition mechanisms behave similarly for the two traffic types. Comparing CPU usage of the two traffic types for the four scenarios, no distinct patterns are obvious the only consistency is that on Router 1, variation in values for on given scenario is significantly lower than that on Router 2. On Router1, Fedora operating system with the two transition mechanism generally is registering lower CPU usage for most packet sizes. VI. CONCLUSION In this research, we empirically evaluated performance of two transition mechanisms (configured tunnel and 6to4) on two Linux distributions (Fedora and Ubuntu) by measuring four performance metrics (throughput, jitter, delay and CPU usage). TCP and UDP traffic types were simulated using D- ITG on a test-bed setup. From this empirical test-bed evaluation, the following specific conclusions can be drawn: 1. Throughput values for both operating systems with the two transition mechanisms are comparable. There is hardly any difference in values in the four scenarios. 2. Jitter values all follow a similar pattern for both TCP and UDP traffic type in all four scenarios. Again there is hardly any significant difference between the operating systems or the two transition mechanisms. 3. Delay experienced in the four scenarios show that Fedora with configured tunnel has significantly higher delays than the other three scenarios. For both TCP and UDP, Windows Server 1200ms with configured tunnel has delay values approximately 1100ms and the rest has less than 200ms. 4. CPU usage of the two routers show hardly any difference in values, however on Router 1, Fedora with the two transition mechanisms CPU usage is lower than that of Ubuntu. This research has shown that the performance of transition mechanisms is generally consistent on the two operating systems tested, however one metrics in particular, average delay, is different depending on the operating system and the transition mechanism. The research team aims to extend this study to incorporate more operating systems including Windows operating systems. REFERENCES [1] R. Gilligan and E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers Internet Engineering Task Force RFC 2893, Aug 2000; [2] D. G. Waddington and F. Chang, Realizing the Transition to IPv6, IEEE Communications Magazine, vol. 40, issue 6, pp , June [3] I.Hsieh and S. Kao, Managing the co-existing network of IPv6 and IPv4 under various transition mechanisms, Proceedings of the Third International Conference on Information Technology and Applications (ICITA), pp , July [4] R. Hiromi and H. Yoshifuji, Problems on IPv4-IPv6 network transition, Proceedings of the International Symposium on Applications and the Internet Workshops (SAINT), pp , January [5] J. Govil, J. Govil, N. Kaur and H. Kaur, An examination of IPv4 and IPv6 networks: Constraints and various transition mechanisms, Proceedings of IEEE Sounteastcon, pp , April [6] E. Park, J. Lee and B. Choe, An IPv4-to-IPv6 dual stack transition mechanism supporting transparent connections between IPv6 hosts and IPv4 hosts in integrated IPv6/IPv4 network, Proceedings of the IEEE International Conference on Communications, vol. 2, pp , June [7] H. M. Tahir, A. Taa, N. B. Nasir, Implementation of IPv4 Over IPv6 using Dual Stack Transition Mechanism (DSTM) on 6iNet, Proceedings of the International Conference on Information & Communication Technologies: From Theory to Applications (ICTTA), vol. 2, pp , [8] K. Kobayashi, S. Katsuno, K. Nakamura, Y. Mikamo, H. Hayashi, A. Machizawa, Y. Kitatsuji and H. Esaki, JGN IPv6 network, Proceedings of the Symposium on Applications and the Internet Workshops, pp , January [9] K. Xiaorui and W. Qingxian, Discovering IPv6 network topology, Proceedings of the IEEE International Symposium on Communications and Information Technology (ISCIT), pp , October [10] R. AlJa'afreh, J. Mellor and I. Awan, Comparison Between the Tunneling Process and Mapping Schemes for IPv4/IPv6 Transition Proceedings of the International Conference on Advanced Information Networking and Applications Workshops (WAINA), pp , May [11] R. AlJa'afreh, J. Mellor and I. Awan, Evaluating BDMS and DSTM Transition Mechanisms Proceedings of the Second UKSIM European Symposium on Computer Modeling and Simulation (EMS), pp , September [12] I. Raicu and S. Zeadally, Evaluating IPv4 to IPv6 transition mechanisms, Proceedings of the 10th International Conference on Telecommunications (ICT), vol. 2, pp , February [13] Y. Hong, M. Shin and H. Kim, Application translation for IPv6 at NAT-PT, Proceedings of the 9th Asia-Pacific Conference on Communications (APCC), vol.1, pp , September [14] B. N. A. Al-tamimi, A. M. Taib and R. Budiarto, Protecting teredo clients from source routing exploits, Proceedings of the First International Conference on Distributed Framework and Applications (DFmA), pp , October [15] M. Shin, H. Kim, D. Santay and D. Montgomery, An empirical analysis of IPv6 transition mechanisms, Proceedings of the 8th International Conference on Advanced Communication Technology (ICACT), vol. 3, pp , February [16] E. Chen, T. Teo, B. Issac and N. Ting, Analysis of IPv6 Network Communication Using Simulation, Proceedings of the 4th Student Conference on Research and Development (SCOReD), pp , June [17] A. Botta, A Dainotti, A Pescapè, "Multi-protocol and multi-platform traffic generation and measurement", INFOCOM 2007 DEMO Session, May 2007, Anchorage (Alaska, USA). V2-117