(IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 4, No. 9, 2013 Performance Analysis and Comparison of 6to4 Relay Implementations Gábor Lencse Sándor Répás Department of Telecommunications Department of Telecommunications Széchenyi István University Széchenyi István University Győr, Hungary Győr, Hungary Abstract—the depletion of the public IPv4 address pool may delegated the last five “/8” IPv4 address blocks to the five speed up the deployment of IPv6. The coexistence of the two Regional Internet Registries in 2011 [3]. Therefore an versions of IP requires some transition mechanisms. One of them important upcoming coexistence issue is the problem of an is 6to4 which provides a solution for the problem of an IPv6 IPv6 only client and an IPv4 only server, because internet capable device in an IPv4 only environment. From among the service providers (ISPs) can still supply the relatively small several 6to4 relay implementations, the following ones were number of new servers with IPv4 addresses from their own selected for testing: sit under Linux, stf under FreeBSD and stf pool but the huge number of new clients can get IPv6 addresses under NetBSD. Their stability and performance were investigat- only. DNS64 [4] and NAT64 [5] are the best available ed in a test network. The increasing measure of the load of the techniques that make it possible for an IPv6 only client to 6to4 relay implementations was set by incrementing the number communicate with an IPv4 only server. Another very important of the client computers that provided the traffic. The packet loss and the response time of the 6to4 relay as well as the CPU coexistence issue comes from the case when the ISP does not utilization and the memory consumption of the computer support IPv6 but the clients do and they would like to running the tested 6to4 relay implementations were measured. communicate with IPv6 servers. The most matured solution for The implementations were tested also under very heavy load this problem is called 6to4 [6]. The stability and performance conditions to see if they are safe to be used in production systems. analysis of different 6to4 implementations is the topic of this paper. Keywords—IPv6 deployment; IPv6 transition solutions; 6to4; The remainder of this paper is organized as follows: first, a performance analysis short survey of the results of the most current publications is I. INTRODUCTION given, second, 6to4 is introduced, third, the selection of the 6to4 relay implementations is discussed, fourth, our test The majority of the current Internet still uses the Internet environment is described, fifth, the performance measurement Protocol version 4 (IPv4) for forwarding the packets of the method of the 6to4 relay implementations is detailed, sixth, the communication of the applications. Even though IPv6 was results are presented and discussed, seventh, the validity of our defined in 1998 [1], it has not replaced IPv4 yet. As of Aug. 31, results is considered and our plans for the future research are 2013, only 1.88% of the Internet traffic reaching Google used presented, finally, our conclusions are given. IPv6 [2]. The coexistence of the two versions of IP results in different issues (e.g. the two endpoints of the communication This topic was identified as being of high importance for use different IP versions, or the endpoints use the same IP network administrators. version but the communication path between the endpoints supports the other version only). Several transition mechan- II. A SHORT SURVEY OF CURRENT RESEARCH RESULTS isms were developed to solve the different issues of the A. The Problem of an IPv6 Only Client and an IPv4 Only coexistence of the two versions of the Internet Protocol. These Server theoretical solutions are defined in different RFCs. There are a number of implementations for each solutions. When a network Several papers were published in the topic of the operator decides to support some of the IPv6 transition performance of DNS64 and NAT64 in 2012 and 2013. The mechanisms, it can be a difficult task to choose the right performance of the TAYGA NAT64 implementation (and implementations because there can be security, reliability and implicitly of the TOTD DNS64 implementation) is compared performance issues. Several papers were published in the topic to the performance of NAT44 in [7]. The performance of the of performance analysis of different IPv6 transition implemen- Ecdysis NAT64 implementation (that has its own DNS64 tations. implementation) is compared to the performance of the authors‟ own HTTP ALG in [8]. The performance of the One of the most important driving forces of the deployment Ecdysis NAT64 implementation is compared to the perfor- of IPv6 is the depletion of the global IPv4 address pool. IANA mance of both the NAT-PT and an HTTP ALG in [9]. All of these papers deal with the common performance of a given This research was supported by the TÁMOP-4.2.2.C-11/1/KONV-2012- DNS64 implementation with a given NAT64 implementation. 0012: “Smarter Transport” – IT for co-operative transport system – The The performance of the BIND DNS64 implementation and Project is supported by the Hungarian Government and co-financed by the European Social Fund. performance of the TAYGA NAT64 implementation are 13 | P a g e www.ijacsa.thesai.org (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 4, No. 9, 2013 analyzed separately and also their stability is tested in [10]. A are multiple 6to4 relays having the same 192.88.99.1 anycast good survey of the most recent DNS64 and NAT64 research address and the network will use the nearest one. results is given in [11]. They also demonstrated that the The forthcoming example scenario can be followed in DNS64+NAT64 system is a viable solution for an internet service provider. Our results about the stability and Fig. 1. Let our client having the 2002:c000:208::2 6to4 IPv6 address communicate with the server having the 2001:db8::2 performance of different DNS64 and NAT64 implementations were published in [12] and [13], respectively. global IPv6 address. The client sends out its IPv6 packet containing its own IPv6 address as the source address and the B. The Problem of an IPv6 Capable Client in an IPv4 Only IPv6 address of the server as the destination address. The Environment packet arrives to the 6to4 router as the default gateway. The A good survey of IPv6 transition mechanisms including 6to4 router encapsulates the IPv6 packet in an IPv4 packet both translation and tunneling solutions can be found in [14]. It using its own IP address, 192.0.2.8 as the source address and discusses 6to4 among the tunneling mechanisms. Ref. [15] the 192.88.99.1 anycast address as the destination address. The named 6to4 and Teredo [16] the two most widely used protocol type is set to 41, which indicates that an IPv6 packet transition solutions on the bases of the IPv6 prefixes in use. was embedded. The packet arrives to the nearest 6to4 relay at The performance of 6to4 is addressed in [17]. They prepared a the 192.88.99.1 anycast address. The relay recognizes the 41 controlled environment and compared the performance protocol type and thus it decapsulates the IPv6 packet and characteristics (round trip time and throughput) of 6to4 to the sends towards its destination. The server receives the packet native IPv4 and IPv6 using both TCP and UDP between the and replies in the normal way addressing its reply packet to the endpoints. They used Cisco routers in the test network. In client. In the global public IPv6 internet, the 2002::/16 prefix is contrast, we have chosen different free software [18] (also routed (using anycast addressing) towards the nearest 6to4 called open source [19]) implementations for stability testing relay, which may be different from the one that was used by the and performance comparison. packet travelling from the client to the server (asymmetric routing). The 6to4 relay receives the IPv6 packet and III. INTODUCTION TO 6TO4 IN A NUTSHELL encapsulates it in an IPv4 packet. It determines the target IPv4 address from the destination IPv6 address as it contains the The aim of 6to4 is to help those IPv6 capable devices that 192.0.2.8 IPv4 address of the 6to4 router next to its 2002::/16 are residing in an IPv4 environment to connect to other devices prefix: 2002:c000:208::2. When the 6to4 router receives the being in the same situation and to the native IPv6 internet. The packet it simply decapsulates the embedded IPv6 packet and solution is an “automatic tunnel” that encapsulates the IPv6 sends it to the client. packets into IPv4 packets (using protocol number 41, as the configured IPv6 over IPv4 tunnel [20]). The IPv6 capable device can be a single host having a 6to4 pseudo-interface that performs the encapsulation of the IPv6 IPv4 Internet 6to4 Host packets into IPv4 packets and also the decapsulation in the 198.51.100.12 opposite direction. This is called 6to4 host. It is also possible 2002:c633:640c::2 that there are multiple IPv6 devices in an IPv6 network behind 192.0.2.8 a so-called 6to4 (border) router that performs the encapsulation IPv6 Island of the IPv6 packets into IPv4 packets and the decapsulation in 6to4 Router 6to4 Relay the opposite direction. These 6to4 IPv6 devices can communi- 2002:c000:208::1 192.88.99.1 cate with other 6to4 IPv6 devices or with IPv6 devices on the 6to4 Relay native IPv6 internet. In the latter case, they need a 6to4 relay at Client 192.88.99.1 the border of the IPv4 internet and the IPv6 internet, see Fig.