Design and Implementation of IPv6-IPv4 Protocol ... - Springer Link

Design and Implementation of IPv6-IPv4 Protocol Translation System Using Dynamic IP Address∗ In-Yeup Kong, Joong-Lyul Lee, and Jung-Tae Lee Department of Computer Engineering Pusan National University, Gumjeoung-gu, Pusan, Korea, 609-735 {leafgirl,blueirix,jtlee}@pusan.ac.kr

Abstract. With the development of IPv6, several IPv6-IPv4 protocol translation systems for communicating between IPv6 networks and IPv4 networks have been proposed. However, the existing IPv6-IPv4 protocol translation systems are impossible to deploy IPv6 networks using dynamic IP address because they necessarily require predefined IP address space for protocol translation. In this paper, we design and implement the IPv6-IPv4 protocol Translation System using Dynamic IP address (64TSD). In order to verify the feasibility of 64TSD, we present experimental results with variable applications and performance evaluation results.

1

Introduction

In the early 1990s, the IETF began an effort to develop a successor to the IPv4 protocol, called IPv6. A prime motivation for this effort was that the 32-bit IP address space began exhausted, with new networks and IP hosts being attached to the Internet rapidly. The IETF has expected, based on current trends, address allocations will be exhausted by 2008[1]. Because the IPv6 was designed with 128-bit IP address space, it can provide enough globally unique IP addresses for every networked device[2]. Second motivation is the security holes in IPv4. IPv6 adopts mandatory implementation of IPSec (IP Security) that offers IP-level authentication, integrity, and encryption[3]. In spite of such motivations, it is easily predictable that the transition from IPv4 to IPv6 will take rather long time, how to make the transition gradually with minimal cost and how to make IPv4 network and IPv6 network communicate seamlessly with each other will be a main problem. Many techniques have been proposed to solve the transition problem and especially, gateway-level translation system has implemented empirically on FreeBSD and Linux [4, 5, 6, 7]. However, the existing implementations allocate IP address from predefined IP address space. Therefore, they are not suitable for mobile networks and home networks, which allocate IP address dynamically by ISPs (Internet Service Providers). To solve this problem, we design and implement IPv6-IPv4 Translation System using dynamic ∗

This work was supported by Pusan National University Research Grant, Korea.

C.-W. Chung et al. (Eds.): HSI 2003, LNCS 2713, pp. 496-506, 2003.  Springer-Verlag Berlin Heidelberg 2003

Design and Implementation of IPv6-IPv4 Protocol Translation System

497

IP addresses (64TSD). The 64TSD provides seamless communication between IPv6 networks and IPv4 networks using dynamic IP address. This paper is organized as follows. In section 2, we summarize the existing IPv6IPv4 transition techniques. In section 3, we describe the detailed components and operations of 64TSD. In section 4, we verify evaluation results of function and the performance. In section 5, we conclude our work.

2

Related Works

We categorize techniques for transitioning from IPv4 to IPv6 into two methods: tunneling methods and translation methods[8]. The tunneling methods are techniques that enable separated IPv6 hosts to communicate over legacy IPv4 network infrastructure. The translation methods are techniques that enable dual-stack hosts using IPv4 application to communicate with IPv6 hosts (in section 2.2.1) or enable IPv4 network and IPv6 network to communicate with each other (in section 2.2.2) [8]. 2.1

Tunneling Methods

Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels (6TO4) [9] is an automatic tunneling mechanism because it does not require any explicit tunneling management. All hosts must update IPv6 protocol stack to generate the IPv6 address for 6TO4 because 6TO4 uses the special 16-bit IPv6 address prefix for 6TO4 defined by IANA (Internet Assigned Numbers Authority). Transmission of IPv6 packets over IPv4 (6OVER4) [10] is an automatic tunneling scheme like 6TO4 except for facilitating IPv6 connectivity between isolated IPv6 hosts within a same IPv4 network. 6OVER4 has performance degradation due to traffic overheads because 6OVER4enable hosts communicate with each other using IP multicast packets despite the communications within same IPv4 networks. Tunnel Broker (TB) [11] is a mechanism that can be applied to isolated IPv6 hosts on the IPv4 network by managing the tunneling requests automatically using TB. However the disadvantage is that the failure of TB potentially introduces the failure of network. Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [12] is an automatic tunneling method that allows dualstack hosts of separated IPv4 networks to communicate with each other through IPv6 network using ISATAP-enabled router. However, ISATAP requires implementation of additional auto-configuration in ISATAP-enabled router and dual-stack hosts because ISATAP uses any global IPv6 address prefix. The tunneling methods mentioned above have some limitations of deployment because encapsulation and decapsulation ability should be implemented in every host and router. 2.2

Translation Methods

2.2.1 Host-Based Translation Bump-In-the-Stack (BIS) [13] is an IP-level translator, which translates IPv4 packets into IPv6 packets and vice versa at TCP/IP module and NIC (Network Interface Card)

498

In-Yeup Kong et al.

device driver. All hosts using BIS is able to translate packets between IPv4 and IPv6 internally without the need for specialized servers. Bump-In-the-API (BIA) [14] is similar to BIS except for an application-level translator. However, BIA removes the IP header translation because it translates socket APIs (Application Programming Interfaces). There are some disadvantages in BIS and BIA. They are limitedly useful for communicating with dual-stack hosts using the IPv4 applications only. Moreover, they increase maintenance costs on a larger scale network because it requires modification of TCP/IP protocol stack inside of all hosts. 2.2.2 Gateway-Level Translation Gateway-level translation is a technique that provides IPv4 hosts and IPv6 hosts to communicate with each other, and it is implemented in border router. NAT-PT/SIIT is an IP-level translator composed of NAT-PT (Network Address Translation-Protocol Translation) and SIIT (Stateless IP/ICMP Translation). SIIT[4] algorithm is a translation algorithm between IPv6 and IPv4 packet headers, as well as between ICMPv6 (Internet Control Message Protocol version 6) and ICMPv4 headers. NAT-PT[4] using the SIIT algorithm allocates a temporary IPv4 address to each IPv6 hosts and binds IPv4 address to IPv6 address. Transport Relay Translator (TRT) [15] provides a transport-level translator that relays TCP and UDP flows between IPv4 network and IPv6 network using a TRT gateway. The TRT gateway maintains two TCP/IP connections per a session. One is for a TCP/IPv6 connection between IPv6 host and the TRT gateway and the other is for a TCP/IPv4 connection between the TRT gateway and IPv4 host. However, because TRT manages many TCP/IP connections, it is slower than NAT-PT/SIIT. SOCKS-based IPv6/IPv4 Gateway (SOCKs64) [16] is an application-level translator that relays an application flow between IPv4 hosts and IPv6 hosts using a SOCKs64 library. The SOCKs64 library intercepts an initiation packet and responds with fake IP address for the flow. Next, it issues session control calls to the SOCKs64 router, which uses the real IP address to transmit the flow to the destination. However, the SOCKS64 provides low throughput because of application-level translator.

3

IPv6-IPv4 Translation System

3.1

System Architecture of 64TSD

The overall system architecture for 64TSD is shown in Fig.1. DNSv6 Server

DHCPv4 Server

Registration Agent (RA) DNSv4 Server

IPv6 Network

IPv6 Host

Native IPv6

IPv4 Network 64 Translator

IPv4/v6

Native IPv4

IPv4 Host

Fig. 1. The overall system architecture using 64TSD


499

Table 1. The functions of the 64 Translator

Function Address/port mapping Protocol translation DHCP client module

Description It allocates a port number for each outbound session. It also maintains the mapping entries. 1 It translates a protocol header between IPv6 and IPv4 as well as ICMPv6 and ICMPv4. It functions checksum recalculation and TCP/UDP port number translation by NAPT algorithm. It allocates IPv4 address dynamically from DHCP server instead of IPv6 servers. It registers RegInfo2 of each IPv6 hosts to the RA. Table 2. The functions of the RA

Function Description Domain Its primary function is to gather the latest information of IPv6 name/ IP ad- servers (The RegInfo is issued whenever IPv4 address of IPv6 host changes). It dress also maintains the RegInfo entries. mapping Virtual It works as DNS server for IPv6 hosts. (When the DNS query of the DNSv6 IPv6 servers by IPv4 hosts is sent to the RA and it replies DNS anserver swer to IPv4 hosts.) The overall system architecture using 64TSD consists of IPv6 Network, IPv4 Network and the 64 Translator. 64TSD is composed of the 64 Translator and the Registration Agent (RA). The 64 Translator is a core IPv6-IPv4 protocol translator of 64TSD. The RA is an agent that helps IPv6 Hosts to use dynamic IP addresses and implemented in any IPv4-only host using a fixed IPv4 address. The IPv6 Network is a native IPv6 network composed with IPv6 Hosts and DNSv6 Server. IPv6 Hosts are IPv6-only hosts. DNSv6 Server provides DNS services for the IPv6 Network. The IPv4 Network is the legacy Internet composed of DHCPv4 Server, DNSv4 Server, RA, and IPv4 Hosts. DHCPv4 Server is a server that allocates IPv4 addresses. DNSv4 Server provides DNS services for the IPv4 Network. IPv4 Hosts are IPv4-only hosts. Next, detailed concept of the 64 Translator and the RA is as follows. 64 Translator uses NAPT-PT (Network Address Port Translation-Protocol Translation) [17] for the protocol translation. NAPT-PT translates IPv4 transport identifiers such as TCP and UDP port numbers, ICMP query identifiers into IPv6 transport identifiers to be multiplexed into single IPv4 address. By adopting NAPT-PT into 64TSD, it requires very small number of IP address compared with NAT-PT, because the total number of IPv4 addresses required is just bounded by the number of IPv6 servers, not the number of IPv6 hosts individually. However, the translation system using NAPT cannot 1

2

The mapping entry is a tuple of ,. where IPvXAddr and IPvXPort are IPvX address and port number of IPvX packet (X is 4 or 6.), and TCPTimer and UDPTimer are a lifetime of the mapping entry in case of TCP or UDP. One of IPvXPorts is an original port and the other of IPvXPorts is a new port by NAPT algorithm. The RegInfo entry is a tuple of , where IPv4Addr is the dynamic IPv4 address allocated by the 64 Translator, IPv6Addr and FQDN are IPv6 address and the full domain name of the IPv6 server, and Timestamp is the latest update time of the RegInfo entry.

500

In-Yeup Kong et al.

handle bi-directional communication[17]. For bi-directional communication between IPv6 network and IPv4 network, we adopt the DHCP client module to the 64 Translator and propose the RA. DHCP client module is a daemon to allocate an IPv4 address for IPv6 server from DHCPv4 server and to register the information about IPv6 Servers to the RA. After the registration, the RA can provide that information to IPv4 hosts using DNS query/reply mechanism. The functions of 64 Translator and the RA are summarized in Table 1 and Table 2. 3.2

Operation of 64TSD

We define the formal notation for the operation description of 64TSD in Table 3. 3.2.1 Outbound Session Outbound session means the session from IPv6 network to IPv4 networks. All outbound sessions share the IPv4 address of the 64 Translator and are distinguished by the port number. We illustrate the procedure to create outbound session in Fig.2 Table 3. Fomal notation for operation description

Notation X (or Y)

Definition It stands for the version of IP (It takes on a value in either of 4 or 6.). Z It stands for the information such as IP address (IP) or FQDN (Name). Category I: IP Packets [ConnectH]X It is a packet to connect to host H using IPvX. [ACKConnH]X It is a packet to acknowledge for connection to host H using IPvX. [RegInfoH]X It is a packet to register the information of host H using IPvX. [DNSQueryH]X It is a DNS packet to query the information of host H using IPvX. [DNSReplyH]X It is a DNS packet to reply for the DNS query of host H using IPvX. Category II: Internal operations DNS-ALGXY It stands for a DNS header translation of the packet from DNSvX to DNSvY. TranslateXY It stands for a translation of the packet from IPvX to IPvY using the mapping entry TransIt stands for the creation of the mapping entry and a translation lateNewXY of the packet from IPvX to IPvY using that mapping entry RecognizeH It stands for the recognition of IP address change for host H. AcquireZH It stands for the acquirement of information Z from host H. LookupRegInIt stands for the lookup the RegInfo entry for host H. foH


IPv6 Host

64 Translator

DNSv4 Server

501

IPv4 Server

(1) [DNSQueryIPv4Server]6 (2) DNS-ALG64 (3) [DNSReplyIPv4Server]4 (4) DNS-ALG46

DNS Query/Reply Phase

Connection Establishment Phase (5) [ConnectIPv4Server] 6 (6) TranslateNew64

(7) [ConnectIPv4Server] 4 (8) [ACKConnIPv4Server] 4

(9) Translate 46 (10) [ACKConnIPv4Server]6

Fig. 2. The procedure of the outbound session

The operation of the outbound session is as follows. The outbound session consists of two phases: DNS Query/Reply Phase and Connection Establishment Phase. First, the step (1) through (4) in Fig.2 corresponds to the DNS Query/Reply Phase. (1) IPv6 Host sends the [DNSQueryIPv4Server]6 to know the IPv4 address of the IPv4 Server. (2) The 64 Translator receives the [DNSQueryIPv4Server]6, then translates it to the [DNSQueryIPv4Server]4. This is the DNS-ALG (DNS Application Level Gateway) function to translate ‘AAAA’ record type (for DNSv6) to ‘A’ record type (for DNSv4) and vice versa. In addition to the translation of the record type, DNS-ALG performs the translation of IP address in payload from IPv6 to IPv4. (3) DNSv4 Server receives the [DNSQueryIPv4Server]4, then responses the [DNSReplyIPv4Server]4 to IPv6 Host. (4) The 64 Translator receives the [DNSReplyIPv4Server]4, then translates it to the [DNSReplyIPv4Server]6. After the DNS Query/Reply Phase, IPv6 Host knows the IPv4 address of the IPv4 Server. Next, the step (5) through (10) in Fig.2 corresponds to the Connection Establishment Phase. (5) IPv6 Host sends the [ConnectIPv4Server]6 through the 64 Translator to the IPv4 Server. (6) The 64 Translator creates the mapping entry and translates the [ConnectIPv4Server]6 into the [ConnectIPv4Server]4 using the mapping entry. (7) The 64 Translator sends the translated packet to IPv4 Server. (8) IPv4 Server replies the [ACKConnIPv4Server]4 to the 64 Translator. When the 64 Translator receives the [ACKConnIPv4Server]4, it looks up the mapping entries with . (9) If the entry is found, it translates to the [ACKConnIPv4Server]6. Otherwise the 64 Translator drops the [ACKConnIPv4Server]4 and the connection fails to establish. (10) When the IPv6 Host receives the [ACKConnIPv4Server]6, the session between IPv6 Host and IPv4 Server is created. After the outbound session is created once, all outbound and inbound packets can translate using the mapping entries. 3.2.2 Inbound Session The procedure of the inbound session is relatively more complicated than that of outbound session because of the Registration Phase showed in Fig.3.

502

In-Yeup Kong et al. IPv6 Server

64 Translator

Registration Agent

IPv4 Host

(1) RecognizeIPv6Server (2) AcquireIPDHCPServer (3) AcquireNameDNSv6Server (4) [RegInfo IPv6Server] 4

Registration Phase

Connection Establishment Phase

(5) [DNSQueryIPv6Server]4 (6) LookupRegInfoIPv6Server (7) [DNSReplyIPv6Server] 4 (8) [ConnectIPv6Server] 4

(9) TranslateNew46 (10) [ConnectIPv6Server]6 (11) [ACKConnIPv6Server]6 (12) Translate64

(13) [ACKConnIPv6Server]4

Fig. 3. The procedure of the inbound session

The inbound session consists of two phases: Registration Phase and Connection Establishment Phase. First, the step (1) through (4) in Fig.3 corresponds to the Registration Phase. (1) The 64 Translator immediately recognizes that IPv6 Server joins to the network or updates the configuration by the Router Solicitation message for automatic discovery of the local router [18]. It extracts a hardware address from the Router Solicitation message. (2) It obtains an IPv4 address of IPv6 Server from DHCP Server and (3) the domain name of IPv6 Server from DNSv6 Server. (4) The information of IPv6 Server such as FQDN, dynamic IPv4 address and IPv6 address is registered to the RA using [RegInfoIPv6Server]4. Next, the step (5) through (12) corresponds to the Connection Establishment Phase. (5) All DNS queries for IPv6 servers are sent to the RA because it works as DNSv6 Server. (6 and 7) The RA sends [DNSReplyIPv6Server]4 according to updated information from the 64 Translator. (8) After DNS transactions, IPv4 Host gets current IPv4 address to connect to IPv6 Server and it sends [ConnectIPv6Server]4 to the 64 Translator. (9) 64 Translator translates the [ConnectIPv6Server]4 to [ConnectIPv6Server]6 using the IPv6 address that is created by the concatenation of dummy prefix and IPv4 address. Then the mapping entry about this session is created. (10) The 64 Translator sends the translated [ConnectIPv6Server]6 to IPv6 Server. (11) IPv6 Server receives the [ConnectIPv6Server]6 and sends the [ACKConnIPv6Server]6 to IPv4 Host. (12 and 13) The [ACKConnIPv6Server]6 is translated by the 64 Translator as same rule and sent to IPv4 Host. After the inbound session is created once, all outbound and inbound packets can translate with the address/port number using the mapping entries.

4

Function and Performance Tests

In this section, we explain the function and performance evaluation results of the 64 Translator itself, because the RA does not affect the translation performance directly.


503

64 Translator

IPv6 Host

IPv4 Host

Native IPv6

IPv4/v6

Native IPv4

Fig. 4. Experimental environment for the 64 Translator

4.1

Experimental Environment

In order to verify the function of the 64 Translator and measure its performance, we set up the experimental environment as shown in Fig.4. IPv6 Host works on a 500MHz Pentium PC running FreeBSD. IPv4 Host works on an 866MHz Mobile Pentium III with Windows XP. IPv6 Host and IPv4 Host connect to 100Mbps Ethernet respectively and communicate with each other via the 64 Translator. Finally, the 64 Translator is implemented on a 333MHz Pentium PC running Linux by our algorithm, and it is based on NAT-PT code[7]. 4.2

Experimental Results

4.2.1 Functional Results First of all, we examine the functions of the 64 Translator: ICMP packet translation and TCP/IP packet translation. In order to verify the functions of the ICMP packet translation, we first call the ping program that sends the ICMP echo requests from the IPv6 Host to the IPv4 host. Ping output is shown in Fig.5. From the results, we know that the ICMP echo request/reply packet can translate seamlessly by the 64 Translator. Next, we experiment on the functions of the TCP/IP packet translation using the HTTP and the FTP. In case of HTTP test, the IPv4 Host sends HTTP request to the web server of IPv6 Host and downloads the flash movie of 468Kbytes (see.swf) showed in Fig.6. In case of FTP test, we download a text file from IPv6 Host and IPv4 Host. Fig.7 shows the test results using FTP. PING6(56 bytes) 3ffe:2e01:24:5:250:8bff:fe73:2718 --> aaaa:bbbb:cccc:dddd:eeee:ffff:a47d:c87a 16 bytes from aaaa:bbbb:cccc:dddd:eeee:ffff:a47d:c87a, icmp_seq=0 hlim=254 time=1.738 ms 16 bytes from aaaa:bbbb:cccc:dddd:eeee:ffff:a47d:c87a, icmp_seq=1 hlim=254 time=1.792 ms 16 bytes from aaaa:bbbb:cccc:dddd:eeee:ffff:a47d:c87a, icmp_seq=2 hlim=254 time=1.801 ms 16 bytes from aaaa:bbbb:cccc:dddd:eeee:ffff:a47d:c87a, icmp_seq=4 hlim=254 time=1.805 ms ^? Type interrupt key to stop --- www.oo0oo.pe.kr ping6 statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1.738/1.777/1.805 ms

Fig. 5. Ping6 outputs3 3

The IPv6 address of IPv6 Host is 3ffe:2e01:24:5:250:8bff:fe73:2718 and the IPv6 address of IPv4 Host is aaaa:bbbb:cccc:dddd:eeee:ffff:a47d:c87a.

504

In-Yeup Kong et al.

9 2.124828 IPv4_Host > IPv6_Host 2008 > http [SYN] Seq=3836052879 Ack=0 10 2.128216 IPv6_Host > IPv4_Host http > 2008 [SYN, ACK] Seq=1931106867 Ack=3836052880 11 2.128250 IPv4_Host > IPv6_Host 2008 > http [ACK] Seq=3836052880 Ack=1931106868 12 2.128692 IPv4_Host > IPv6_Host GET /see.swf HTTP/1.1 13 2.143007 IPv6_Host > IPv4_Host HTTP/1.1 200 OK … 61 3.308981 IPv6_Host > IPv4_Host HTTP/1.1 206 Partial Content 62 3.313207 IPv6_Host > IPv4_Host Continuation 610 19.984111 IPv6_Host > IPv4_Host http > 2009 [FIN, ACK] Seq=930308900 Ack=3836387755 611 19.984207 IPv4_Host > IPv6_Host 2009 > http [ACK] Seq=3836387755 Ack=930308901

Fig. 6. HTTP test results 1 0.000000 IPv4_Host > DNS_Server : Standard query A IPv6_Host.lab.oo0oo.pe.kr 3 0.008027 DNS_Server > IPv4_Host : Standard query response A 164.125.200.68 4 0.023870 IPv4_Host > IPv6_Host : 2055 > ftp [SYN] Seq=4268101438 Ack=0 7 0.030020 IPv6_Host > IPv4_Host : 2055 [SYN, ACK] Seq=119100030 Ack=4268101439 8 0.030064 IPv4_Host > IPv6_Host : 2055 > ftp [ACK] Seq=4268101439 Ack=119100031 … 81 4.217924 IPv4_Host > IPv6_Host : Request: RETR 1m.txt … 495 4.878227 IPv6_Host > IPv4_Host : FTP-DATA FTP Data: 262 bytes … 3744 14.975001 IPv4_Host > IPv6_Host : Request: QUIT 3747 14.981423 IPv6_Host > IPv4_Host : Response: 221 Goodbye. … 3752 14.985055 IPv4_Host > IPv6_Host : 2055 > ftp [ACK] Seq=4268101544 Ack=119100358 3755 14.989264 IPv6_Host > IPv4_Host : 2055 [FIN, ACK] Seq=119100357 Ack=4268101544

Fig. 7. FTP test results

In Fig.6, lines 9 - 11 in Fig.6 are packets for 3-way TCP connection establishment. Next, lines 12 and 13 are command packets for loading of the web page and lines 14 609 are data packets for continuous loading of the web page. Finally, lines 610 and 611 are packets for connection termination. From the results, we know that the 64 Translator can translate HTTP packets using TCP/IP transparently. In Fig.7, lines 1 and 2 are DNS query/reply packets. Lines 4, 7 and 8 are packets for 3-way TCP connection establishment. Next, lines 81 - 3743 are data packets for continuous loading of the text file. Finally, lines 3744 - 3755 are packets for connection termination using the QUIT request. Especially, packets for DNS (lines 1 and 2) and FTP (lines 4 - 3755) need ALGs, because applications such as DNS and FTP carry IP addresses in payload[20]. From the results, we know that the 64 Translator can translate DNS and FTP packets correctly. 4.2.2 Performance Results In section 4.2.1, we verify functions of the 64 Translator. Moreover, in order to examine the performance of the 64 Translator, we measure the throughput of the 64 Translator as increasing the offered load. We use the Multi-Generator (MGEN)[21] for the IPv4 Host and MGEN6[21] for the IPv6 Host to generate traffic pattern. Since the current implementation of MGEN and MGEN6 supports the UDP only, we conduct the experiment using the UDP.


505

7.00 Throughput (Mbps)

6.00 5.00 4.00 3.00 2.00 1.00 0.00 1

3

5

7

9

15

25

35

45

55

65

75

85

95

Offered load (Mbps)

Fig. 8. Throughput of 64TSD. For accurate view of the increasing throughput, the offered load from 1Mbps to 10Mbps increases by 1Mbps, while the offered load from 10Mbps to 95Mbps increases by 5Mbps

We send the test flow of the 1440bytes packets from IPv4 Host to IPv6 Host for 5 seconds as increasing the offered load from 1Mbps through 100Mbps. The throughput for the offered load is shown in Fig.8. As shown in Fig.8, the throughput begins to saturate at about 9Mbps offered load. Consequently, we know that host-based 64TSD has performance degradation under heavy load over 10Mbps. Therefore, we study about other implementation methods to enhance the performance of 64TSD. We consider that the hardware implementation will be better than the host-based implementation, because it manipulates the packets from NIC directly without the overhead of the kernel-aided packet filer such as BPF.

5

Conclusion

For the deployment of IPv6, it is essential to develop the protocol translation systems that enable newly-deployed IPv6 networks to communicate with legacy IPv4 networks. Many IPv6-IPv4 protocol translation systems have been proposed to solve this problem. However, the existing systems cannot use dynamic IP addresses because they can only operate using IP address defined manually. In order to solve this problem, we propose 64TSD, which provides bi-directional communication between the IPv6 networks and the IPv4 networks using dynamic IP addresses. We also implement host-based 64TSD and evaluate the functions and the performance of 64TSD. From the test results using variable applications, we know that 64TSD provides the seamless communication, and it is more realistic solution than others to transit from IPv4 to IPv6. In the future, we plan to implement the hard-wired 64TSD for high performance.

506

In-Yeup Kong et al.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21]

F. Solensky, IPv4 Address Lifetime Expectations in IPng, Addison Wesley (1996) K.P. Worrall, “The impact of IPv6 on Wireless Networks”, IEEE Conference Publication NO.477 (2001) 323-329 Marcin Dobrucki, “The Effects of the transition to IPv6 on Internet Security”, (1999) 1-18 E. Nordmark, “Stateless IP/ICMP Translation Algorithm (SIIT)”, IETF RFC 2765 (2000) G. Tsirtsis and P. Srisuresh, “Network Address Translation - Protocol Translation (NAT-PT)", IETF RFC 2766 (2000) Marc E. Fiuczynski, Vincent K. Lam, and Brian N. Bershad, “The Design and Implementation of an IPv6/IPv4 Network Address and Protocol Translator”, Proceedings of the USENIX Conference (1998) IPv6 Forum Korea, “Linux-based Userspace NAT-PT”, http://www.ipv6.or.kr/ Michael Mackay and Christopher Edwards, “Transitioning from IPv4 to IPv6 A Technical Overview”, Proceedings of the PgNet Symposium (2001) B. Carpenter and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels”, IETF RFC 3056 (2001) B. Carpenter and C. Jung, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”, IETF RFC2529 (1999) A. Durand, P. Fasano, I. Guardini, and D. Lento, “IPv6 Tunnel Broker”, IETF RFC 3053 (2001) F. Templin, T. Gleeson, M. Talwar, and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”, (2002) K. Tsuchiya, H. Higuchi, and Y. Atarashi, “Dual Stack Hosts using the BumpIn-the-Stack Technique (BIS)”, IETF RFC 2767 (2000) S. Lee, M-K. Shin,Y-J. Kim, E. Nordmark, and A. Durand, “Dual Stack Hosts using the Bump-In-the-API Technique (BIA)”, IETF RFC 3338 (2000) J. Hagino and K. Yamamoto, “An IPv6-to-IPv4 Transport Relay Translator”, IETF RFC 3142 (2001) H. Kitamura, “A SOCKS-based IPv6/IPv4 Gateway Mechanism”, IETF RFC 3089 (2001) P. Srisuresh, and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT)”, IETF RFC 3022 (2001) IPv6 Forum Korea, Next Generation Internet Protocol IPv6, Dasung Pub. Co (2002) Network Associates, “Ethereal: A Protocol Analyzer”, http://www.ethereal.com/ Vasudev Navelkar, “IPv6 Transition Mechanisms”, Indian Institute of Technology (1999) Naval Research Laboratory, “Multi-Generator”, http://manimac.itd.nrl.navy.mil/MGEN/