Deployment and Performance Evaluation of Teredo and ISATAP over Real Test-bed Setup

Transcription

1 Deployment and Performance Evaluation of Teredo and ISATAP over Real Test-bed Setup Mohammad Aazam 1,2 1 Mohi-ud-Din Islamic University, Islamabad, Pakistan aazam@corenet.org.pk Syed Atif Hussain Shah Shaheed Zulfikar Ali Bhutto Institute of Science and Technology (SZABIST), a.shahgee@gmail.com Imran Khan 2 Center of Research in Networks and Telecom (CoReNeT), Mohammad Ali Jinnah University, imran@corenet.org.pk Amir Qayyum Center of Research in Networks and Telecom (CoReNeT), Mohammad Ali Jinnah University, aqayyum@ieee.org ABSTRACT Coexistence of IPv4 and IPv6 bears problem of incompatibility, as IPv6 and IPv4 headers are different from each other. To counter this problem, three solutions are possible: a) making every device dual stack, b) translation, c) tunneling. Tunneling stands out as the best possible solution. Among the IPv6 tunneling techniques, this paper evaluates the performance of two recent IPv6 tunneling techniques: Teredo, and ISATAP. These protocols were implemented on real test bed setup, on Microsoft Windows (MS Windows XP and MS Windows Server 2003) and Linux operating systems. Five to six devices were used to setup the whole test bed. Each protocol was then implemented on the setup using specific configuration commands. UDP audio streaming, video streaming and ICMPping traffic was run. Four different runs of traffic were routed over the setup for each protocol. The average of the data was taken to generate graphs and final results. The performance of these tunneling techniques has been evaluated through certain parameters, namely: throughput, end to end delay (E2ED), round trip time (RTT), and jitter. Categories and Subject Descriptors C.2.2 [Computer-Communication Networks]: Network Protocols-IP General Terms experimentation, measurement, performance Keywords IPv6 tunneling, Teredo, ISATAP, encapsulation 1. INTRODUCTION Transitioning towards IPv6 is inevitable. Very soon, IPv6 will be running on every IP device. Transitioning towards IPv6 won t be an overnight project. It would be incremental and step Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MEDES 10, October 26-29, 2010, Bangkok, Thailand. Copyright 2010 ACM /10/10...$ by step. IPv4 and IPv6 will coexist even after about a decade of IPv6 deployment [11]. Keeping in view the importance of IPv6, the transition from IPv4 to IPv6 has started [6]. To make this transition manageable and easy, a lot of research has been done. It is not practical to change the Internet, or any large network altogether into an IPv6 network at once. All the routers cannot be upgraded simultaneously [10]. Hence transition is only feasible in a gradual manner due to complexity of the Internet and huge number of devices accessing it. Migration towards IPv6 would be in such a manner that for certain time, both IPv4 and IPv6 capable devices will co-exist [2]. Also, there will be islands of both IPv4 and IPv6 networks. For example, two IPv6 devices want to communicate with each other but there is an IPv4 network between them, IPv6 packets has to be routed from that IPv4 network. As IPv4 and IPv6 headers are different from each other (fields, the address format and address size are different), so IPv6 packet has to be tunneled to route through the incompatible IPv4 network. For this purpose, three mechanisms are available in the literature [10]: (a). Dual Stack (b). Translation (c). Tunneling. In dual stack, routers and nodes can understand both IPv4 and IPv6 packets and translate between each other and make communication seamless. To achieve this, the router or node should be enhanced to a dual stack node, which may not be easily possible all the time. Translation refers to the direct conversion of protocols (e.g., between IPv4 and IPv6) and may include transformation of both the protocol headers and the protocol payload. Translation can occur at several layers in the protocol stack, including network, transport, and application layers. Protocol translation often results in feature loss, when there is no clear mapping between the features provided by translated protocols. For instance, translation of an IPv6 header into an IPv4 header will lead to the loss of IPv6 flow label field. Tunneling is a technique in which one protocol is encapsulated in another protocol [11], according to the network where the packet is to be routed [5]. As discussed, if an IPv6 source communicating with an IPv6 destination and an IPv4 network is between them, then IPv6 packets must be tunneled into the IPv4 header so that the IPv6 packet get routed through the IPv4 network and reaches its IPv6 destination. It won t be feasible to upgrade each and every device to make incompatible devices interoperate with each other. Similarly, data loss or feature loss won t also not appreciable at all. Thence tunneling comes up to be the most feasible way for transitioning towards IPv

2 1.1. IPv6 Tunneling Techniques Teredo Teredo provides a service that enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. With Teredo, the current IPv4 network is treated as the link layer, and the existing IPv4 routing mechanism is utilized to forward IPv6-in-UDP-in-IPv4 encapsulated packets. Teredo host first gets an IPv6 prefix from the Teredo Server, then an IPv6 address is formed with special format (Prefix : Server IPv4 : Flags :Port : Client IPv4) [3]. The communication between Teredo hosts can be made directly with an IPv6-in-UDP-in-IPv4 tunnel. The connectivity to IPv6 native network will be achieved with the Teredo relay gateway. The automatic tunnels between Teredo hosts distribute the traffic between them and share the burden of Teredo relay gateway Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) ISATAP is designed for the intra-site scope. ISATAP connects isolated nodes within IPv4 sites via automatic IPv6-in-IPv4 tunnels. That is why it is called intra-site [4]. With ISATAP, the intra-site IPv4 network is viewed as a link layer for IPv6, and other nodes in the intra-site network are viewed as potential IPv6 hosts/routers. An automatic tunneling abstraction is supported, which is similar to the Non-Broadcast Multiple Access (NBMA) model. An ISATAP host gets a 64-bit prefix from the ISATAP Server. Then an ISATAP address is formed with its own interface identifier (::0:5EFE:IPv4Address). After that, the ISATAP hosts can connect with each other via the IPv6-in-IPv4 tunnel with ISATAP addresses. Furthermore, ISATAP can be used to provide connectivity to the outside IPv6 network together with other transition mechanisms. For example, if the site gateway is supported with 6to4 and holds the 6to4 prefix as an ISATAP Server and the IPv6 hosts among this site can use ISATAP to get intra/inter-site IPv6 connectivity. node, then an ISATAP setup was in such a way that Host 1 (H1), as shown in the figure 1, is a dual stack node, residing in an IPv4 network. This node has to communicate to another dual stack node, residing in an IPv6 network. Now, the traffic of and from both, H1 and H2, has to go through IPv4 network. Those IPv6 packets have to be tunneled through IPv4 network. By default, the IPv6 protocol for Windows XP Professional with SP2 and Windows Server 2003 with SP1, Standard Edition, configures a link-local ISATAP address on the Automatic Tunneling Pseudo-Interface for each IPv4 address assigned to a computer. To configure global ISATAP addresses, or to communicate beyond the logical subnet defined by the IPv4 intranet, an ISATAP router is needed [12]. ISATAP router performs two functions: a). advertises its presence and address prefixes, enabling global ISATAP addresses to be configured. b). optionally forwards IPv6 packets between ISATAP hosts on the IPv4 intranet and IPv6 hosts beyond it [14]. An ISATAP router is typically configured to perform both functions, but can perform either individually. Most often, an ISATAP router acts as the forwarder between ISATAP hosts on an IPv4 intranet and IPv6 hosts on an IPv6-enabled portion of an intranet. To demonstrate the use of an ISATAP router between IPv6 and IPv4 intranets, first the test lab was separated into a portion that has IPv4 and IPv6 connectivity and another that has IPv4 connectivity only [11]. Then, router1 is configured as an ISATAP router so that hosts on the IPv4-only portion of the intranet can communicate with hosts on the IPv6-enabled portion of the intranet. To do this, IPv6 forwarding and advertising was disabled on the Subnet 2 Connection interface of router1 and both interfaces of router2. This emulates an intranet in which a portion is IPv6-enabled (Subnet 1) and a portion is not (Subnet 2 and Subnet 3). Teredo setup was more or less in the same way except a couple of additions. One is the addition of NAT boxes, behind which both the clients reside and the other is Teredo Server with Linux running on it. In this setup, Fedora Core 10 was used. For the complete configuration of Teredo, the Miredo package [12] was used. 2. PERFORMANCE EVALUATION USING TEST BED SETUP There were no simulation patches available for these techniques. To evaluate the performance, the other option was to deploy these techniques practically on a test lab and then run the traffic using each technique Test-bed Setup Description IPv6 test-bed setup was needed to evaluate the performance of these protocols. Using minimum possible nodes required to setup the test bed, IPv6 was configured and tested. It required 5 nodes to setup the test-bed, which was first configured for IPv6 and later on each protocol was deployed on it. These five nodes are: two hosts, one DNS server, two routers. Cables and hubs/switches were used to connect them. The following figure depicts the setup more comprehensively. ISATAP works where one node (dual stack ISATAP node) is residing inside an IPv4 network and it has to communicate to an IPv6-only node, sitting inside an IPv6 network [4]. When ISATAP node wants to communicate to the other end IPv6-only Figure 1. Test bed setup 2.2. Performance Evaluation The performance was evaluated based on certain parameters. The parameters were selected keeping in view the attributes related to tunneling and network layer or routing, like: throughput, round trip time, jitter, and end to end delay, were used to evaluate the performance

3 Throughput It describes the overall throughput of the protocols. i.e. number of packets received per second. Formula to calculate throughput is: Throughput pps = No_of_pkts_rcvd / timestamp sec pps (1) Where pps is packets per second. UDP audio streaming traffic was run end to end to calculate the throughput. There were basically four runs of traffic, whose average was calculated and the final graph, shown below, was generated. Figure 2 shows that ISATAP has got relatively better throughput as compared to Teredo. The packet size remained 1500 bytes. Traffic was run for about five minutes over the test bed setup, which was sniffed using the most widely used packet sniffing tool, called Wireshark. The graph shows that ISATAP performs better in respect of throughput. Its throughput remained packets per second. As Teredo performs two-level encapsulation, in which it encapsulates every IPv6 packet inside UDP and then that UDP packet, containing IPv6 in its payload, is encapsulated in the IPv4 packet, so its performance is degraded. Its throughput remained packets per second. But Teredo is still acceptable because it was meant to traverse IPv6 through NAT boxes, so in such scenarios, where a dual stack end-user is sitting in a private IPv4 network, behind NAT, and wants to communicate to an IPv6 node, then Teredo will be the solution for tunneling. The ultimate, average throughput in Kbps comes out as: Throughput = ((No_of_pkts_rcvd / timestamp sec ) X 1500 X 8) / 1000 Kbps (2) As the network conditions were more or less stable, because it was a test bed setup, so there is apparently not a huge difference among the protocols. But when deployed over the Internet, this difference will surely increase. The average throughput was calculated to make things more comprehensive. As shown in the table 1, in relatively stable conditions, ISATAP has the edge of around 20 Kbps on Teredo. End to End Delay (E2ED) It describes delay in milliseconds the traffic incurs. The formula for end to end delay is: E2ED = timestamp msg_rcvd - timestamp msg_sent (3) Figure 3. Teredo-ISATAP end to end delay milliseconds Delay was also calculated on UDP audio streams. It was calculated by subtracting the timestamp of packet received at the receive end with the timestamp of packet sent by the sender. Again, in terms of delay, ISATAP has got the edge. Its performance is better than Teredo. Teredo traffic incurs more delay. This is because Teredo has more overhead due to dual encapsulation (IPv6 encapsulated in UDP-IPv4). This extra encapsulation, which is for a good reason of traversing NATs, adds extra overhead of encapsulation and decapsulation. On the other hand, ISATAP is most recent among its contenders and involve least number of intermediate devices to route traffic. Average delay is shown in the following table: Table 2. Average end to end delay in milliseconds Figure 2. Teredo-ISATAP throughput (in Kbps) Average throughput is shown in the following table: Table 1. Average throughput in Kbps Average Delay (ms) Table 2 shows that ISATAP incurs least amount of delay in comparison with Teredo. When these techniques are deployed over the Internet, there would be lot more devices each packet has to travel through. This difference would be lot more then. Average Throughput (Kbps) Jitter

4 Jitter, variation in delay, was calculated on the basis of the end to end delay. The formula is given below; Jitter = Absolute (delay current_pkt delay prev_pkt ) milliseconds (4) The first packet won t be having any previous packet, so its jitter is 0. received by the sender. To get this, TCP based ICMP-ping traffic was used. Formula is given below: RTT = timestamp pkt_rcvd - timestamp pkt_sent milliseconds (5) Figure 4. Teredo-ISATAP jitter Jitter is the only parameter in which ISATAP s performance is inferior from Teredo. This is because in ISATAP, tunnel refresh packets; which are meant to refresh the tunnels; are send more frequently. They are sent after every 13 data packets. When the tunnel is being refreshed and maintained, the data traffic is halted for that while. In Teredo, tunnel refresh packets are sent after every 21 data packets. This is the reason for Teredo being less jittery. When real time streaming traffic has to be tunneled through IPv4 network, then Teredo is the best option. Average jitter is shown in the following table: Figure 5. Teredo-ISATAP round trip time The difference between E2ED and RTT is that different traffics were used to calculate each. For E2ED, UDP audio/video streams were used, while for RTT, TCP based ICMP-ping traffic was used. Average RTT is shown in the following table: Table 4. Average round trip time in milliseconds Average RTT (ms) Table 3. Average jitter in milliseconds Average Jitter (ms) The difference revealed from the above mentioned table 3 shows that when these techniques would be deployed over the Internet, ISATAP tunneled traffic would be containing even more jitter, because when there would be lot more devise involved and the network conditions would also be unpredictable, then those refresh packets would take more time to travel through the network between the client and the ISATAP server. Thence, incurring more jitter and also, affecting the bandwidth as well. Round Trip Time (RTT) Round trip time is also regarded as one of the key parameter when talking about networks and network layer protocols. RTT is the time taken in total starting from the moment packet left the sending machine till the reply packet In terms of RTT, ISATAP is again the better choice, because of the very reason of lesser encapsulation overhead. 3. CONCLUSION For the performance evaluation of recent IPv6 tunneling techniques: ISATAP and Teredo; UDP audio streams, video streams, and ICMP-ping traffic were used. Traffic was run end to end and sniffed at every node for better analysis. Four separate runs of traffic were routed over the most common and recommended setup for each protocol. At the end, the average of those four runs of traffic was calculated to generate final results. After all this research activity, it is concluded that based on the most common parameters: throughput, end to end delay (E2ED), round trip time (RTT), and jitter, ISATAP has got the edge on Teredo in every parameter, except jitter. ISATAP server sends tunnel refresh packets most frequently, in comparison to Teredo, so for that span of time, when the tunnel is refreshed, the data traffic is halted. It makes ISATAP more jittery. Teredo remains the best choice for real time traffic

5 4. FUTURE WORK In future, a further deeper study is required in this regard to evaluate these protocols. The test-bed used in this research work was just to evaluate the techniques in stable network conditions, which give an idea that how much different both these protocols are, with respect to performance, from each other. In future, relatively complex scenarios would be created and also, conditions more close to the Internet environment would tried to be incorporated, to get even more extended evaluation of these recent IPv6 tunneling techniques. 5. REFERENCES [1] B. Carpenter, K. Moore, Connection of IPv6 Domains via IPv4 Clouds, RFC 3056, February 2001 [2] C. Huitema, et al, Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks, RFC 3904, September 2004 [3] C. Huitema, Teredo: Tunneling IPv6 over UDP through Network Address Translators (NATs), RFC 4380, February 2006 [4] F. Templin, et al, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), RFC 5214, March 2008 [5] Jivika Govil, Jivesh Govil, Navkeerat Kaur, and Harkeerat Kaur, "An Examination of IPv4 and IPv6 Networks: Constraints and Various Transition Mechanisms", IEEE Region 3 Huntsville Section (IEEE SoutheastCon 2008), April 3-6, 2008, Huntsville, Alabama, USA [6] Jun Bi, Jianping Wu, and Xiaoxiang Leng, IPv4/IPv6 Transition Technologies and Univer6 Architecture, International Journal of Computer Science and Network Security (IJCSNS), VOL.7 No.1, Beijing, China, January 2007 [7] Manageable Transition to IPv6 using ISATAP, IPv6 Integration Paper Series, Cisco Systems, May 2006 [8] Miredo: Teredo for Linux and BSD, available online at [9] Pete Loshin, IPv6 Theory Protocol & Practice 2nd edition, Elsevier, Morgan Kaufmann Publishers, 2004 [10] Ra ed AlJa afreh, John Mellor, and Irfan Awan, A Comparison between the Tunneling process and Mapping schemes for IPv4/IPv6 Transition, in the proceedings of 2009 International Conference on Advanced Information Networking and Applications Workshops, Bradford, UK, 2009 [11] R. Gilligan, E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, RFC 1933, April 1996 [12] Sang-Do Lee, Myung-Ki Shin, and Hyoung-Jun Kim, Implementation of ISATAP Router, In the proceedings of The 8th International Conference of Advanced Communication Technology (ICACT 2006), Phoenix Park, Korea, February, 2006 [13] Shiang-Ming Huang, Quincy Wu, and Yi-Bing Lin, Enhancing Teredo IPv6 Tunneling to Traverse the Symmetric NAT, IEEE Communication Letters, Vol. 10, No. 05, May 2006 [14] Shubhangi Kharche and B D Biranale, IPv4 to IPv6 Transition Using Windows OS, Proceedings of the SPIT-IEEE Colloquium and International Conference, Mumbai, India, February 2008 [15] Vasaka Visoottiviseth and Niwat Bureenok, Performance Comparison of ISATAP Implementations on FreeBSD, RedHat, and Windows 2003, Proceedings of the IEEE 22nd International Conference on Advanced Information Networking and Applications, Okinawa, Japan,