Hiroshi KITAMURA <email@example.com>
As we move toward the transition to the IPv6 next-generation network environment, it is necessary to realize heterogeneous communications between IPv6 and IPv4 terminals without sacrificing any conveniences or frameworks of current communication methods. Mechanisms that satisfy such requirements are called translators. This paper categorizes various translator mechanisms and clarifies their characteristics. As a solution of analyses, this paper proposes a SOCKS-based IPv6/IPv4 Translator, and describes its design and implementation. Compared with other translator mechanisms, the SOCKS-based Translator has small constraints and good characteristics. For example, it can integrate DNS (domain naming system) name-resolving procedures, which is an important mechanism for the transition. The Translator has already been implemented and has been proven to support typical communication services such as telnet, FTP, HTTP, and mail without any problems.
With a trigger to solve the IPv4 address space exhaustion problem, the research of next-generation Internet protocol (IP) IPv6  has started. IPv6 also aims to fix the current problems and to introduce enhanced new features (e.g., IPSEC). Now we are facing a historical transition time to the IPv6 communication world.
On the way to the transition to the IPv6 world, various transition scenarios and methods have been proposed . They are classified into three types of transition approaches.
The first approach is to transit by introducing terminals that have both IPv6 and IPv4 protocol stacks. With this approach, however, the IPv4 address space exhaustion problem can never be solved, and it cannot realize real transition. So, this approach is not considered in this paper.
The second approach is to transit by applying a tunneling technique that can capsule IPv6 packets into IPv4 packets. IPv6 lands on the IPv4 ocean can be connected by this technique. This is a temporal approach. With this approach, however, only IPv6 homogeneous communications are realized; IPv4 nodes cannot communicate with IPv6 nodes. So this approach is also not considered in this paper.
The third approach is transit by introducing a translator mechanism that can translate packets and protocols and enables heterogeneous communications between IPv4 and IPv6 terminals. This approach is the target of this paper and is discussed in the following sections. This is a long-term approach; it is used from the initial stage until the final stage of the transition by changing applied communication topologies.
In order to transit to the IPv6 new network environment smoothly and realize heterogeneous communications between existing IPv4 and new IPv6 terminals, the following requirements are imposed on the translator mechanisms:
Translator mechanisms need to either satisfy these requirements or require minimal modification that will enable them to do so. Currently, various translation mechanisms have been researched and proposed at the Internet Engineering Task Force (IETF) next-generation transition (NGTRANS) working group. . Each of these proposed mechanisms has its own unique characteristics. These characteristics are clarified and compared in the following section. Finally, this paper proposes a SOCKS-based Translator that satisfies given requirements and has the best characteristics that have been proposed to IETF to date .
In this section, necessary functions for translator mechanisms are analyzed from three viewpoints: protocol translations, user applications, and assumed applied environments.
Basically, two types of protocol translations are necessary for translator mechanisms:
IP header of each packet must be replaced with some mapping rules because IPv4 and IPv6 are different protocols.
Most translation mechanisms must reserve IP address space for mapping, and complex address management functions must be provided.
IP address translation effect to other IP-related protocols (e.g., Internet control message protocol [ICMP]). These protocols must also be translated. Since ICMP is closely related to IP, complex management and translation functions must be implemented.
In addition, some applications exchange IP address information at the application layer (e.g., file transfer protocol [FTP] PORT command.). Translator mechanisms must support them.
The importance of minimizing influence on user applications is implicit in the requirements to transit. By analyzing the communication procedures of a user application, needed functions of translator mechanisms are clarified.
At first, the applications must specify a destination terminal to start communication. Usually, the logical hostname FQDN (Full Qualified Domain Name) of the destination is used to specify this; numerical IP address expression is not used. (In case of IPv6 communication, specifying by logical hostname is dominant because the IPv6 address is too long to remember.)
The user applications resolve the specified FQDN to the IP address by using domain naming system (DNS) name-resolving application programming interfaces (APIs). The resolved IP address is used to create connections.
Logical hostname (FQDN) information is important for transition mechanisms because it is unique, independent information on IPv4 and IPv6 and a beginning key of the communications. By using this information effectively, smooth transition can be realized.
In other words, the DNS name-resolving mechanism must be integrated into translator mechanisms to realize smooth transition. The same type of issue is described in transition scenarios that are currently being discussed at IETF .
It is assumed that translators will be applied on various communication environments. In order to support the following applied environments, translator mechanisms must have widely applicable flexibility.
IPv4 terminals want to communicate with IPv6 terminals and vice versa. There are also many occasions in which IPv6 terminals must utilize existing IPv4 network services. Most transition scenarios assume such cases .
In order to clarify characteristics of translator mechanisms, translator methods are categorized. The categorization issue is also being discussed at IETF . In this paper, translator mechanisms are categorized by using two viewpoints: an implemented protocol layer viewpoint and an installed node position viewpoint.
The implemented protocol layer characterizes most of the basic functions of translator mechanisms where a translator is implemented, and behaviors of translated connections depend on each translator model. So, this paper names translator models after the method in which the connection is treated.
In most cases, the NAT (network address translation)  technique is applied to realize this mechanism. IP headers of packets are replaced at the IP layer from/to IPv4 to/from IPv6 when they pass through a translator. The translated connections are treated transparently. Articles  and  describe typical examples of this method. This method is called transparent model.
Proxy server mechanisms belong to this type. However, we do not consider the proxy servers here, because they are designed for limited services (e.g., hypertext transfer protocol [HTTP]) and cannot translate all services. In most cases that can provide universal translation, firewall techniques are applied to realize this mechanism. Two connections (one is IPv4, the other is IPv6) are first terminated and then relayed at a translator application. This method can be categorized further into two models. One is called the full-termination model. In this model, users must understand internal relay structure and topology, and input necessary information to translate when they start communications. The other is called the semi-termination model. In this model, users do not have to understand the internal relay structure, and necessary information is transferred automatically by using a special protocol (e.g., SOCKS ).
A translator mechanism must be installed somewhere on the communication path. All of the above-mentioned translator models can be installed in any type of communication nodes. Functional differences cannot be seen by this viewpoint categorization, but restrictions of usage and apparent behavior differences are clarified.
With this method, it becomes possible to translate IPv4 applications locally at the source terminal and to show them as IPv6 applications to external nodes. Tsuchiya and colleagues'  proposal concentrates on this type of usage. This method is advantageous in that it can integrate the DNS name-resolving mechanism because the translator is installed at the source terminal. It is disadvantageous, however, because only local applications on the source terminals are supported, and a translator must be installed at each terminal.
This is generic usage. All the terminals on the network can utilize translation functions.
In IP layer implementation, a translator is installed at a router on the communication path. This method causes a restriction on the source terminal to configure the default route path to the router.
In application layer implementation, a translator works as a server and provides translation service to user applications. It is necessary to set the server location on the source terminal.
The problem with this method, however, is that the DNS name-resolving mechanism cannot be integrated.
Though this method does not cause any restrictions to the source terminals, we do not consider it because its conditions are similar to those of the dual stack approach, and it cannot solve the IP address space-exhaustion problem.
In this section, characteristics of translator mechanism models are analyzed and clarified.
This method concentrates on IP header translation. When packets come from a source terminal, they are translated. At first glance, this method appears to be good because it requires no modification to the source terminal. However, no modification means that the DNS name-resolving mechanism cannot be integrated into it. This is a fatal problem because the existing applications on the source terminal cannot start communication or transmit packets easily.
In order to solve this problem, it is proposed that the method must be used in combination with DNS query packet replacement mechanism that has been proposed. This mechanism is somewhat inconvenient because it makes the well-designed distributed DNS mechanism less scalable, thus imposing many constraints.
What is worse, this method must implement ICMP translation as well, because the translated connection is not terminated. ICMP packet translation is complex and difficult to implement because ICMPv6 has many different features from current ICMP and it is impossible to map them completely.
There are additional disadvantages. For example, this method may cause packet fragmentation, because the packet lengths are changed by the header translation, and they may exceed maximum transmission unit (MTU). Furthermore, it is difficult to introduce the new features of IPv6 (e.g., IPSEC) without losing their functions.
Thus it can be concluded that this method is not suitable for a translator because the mechanism has many problems and results in the loss of the flexibility of current network frameworks.
This method does not have problems such as the transparent model has, because the method terminates connections and relays them at the application layer. It is not necessary to translate ICMP, because ICMP messages are also terminated and relayed. There is no fragmentation vulnerability because packet size is adjusted at the application layer. New features of IPv6 can be introduced easily.
The restriction of the method is that the user must understand the internal network configuration and input necessary information for translation manually. This restriction sacrifices the convenience of current communication methods. For applications that do not have capability to transfer necessary information, the method does not work properly.
This is an improved version of the full-termination model. All problems are fixed, and necessary information for translation is transferred automatically between the source terminal and the translator.
A new protocol and structure are introduced to realize this mechanism. This makes it necessary to install new function in the source terminal. Since this function installation means modification of the terminal, it appears to be a weak point. This is not the case, however. As was pointed out earlier, a DNS name-resolving mechanism must be integrated into the translator mechanism. This is the only model that can satisfy this requirement by installing new functions to the terminal. So this fact becomes a benefit of this model if the new function installation is easy.
On the basis of the above discussions, the author has concluded that the most effective method to satisfy requirements for transition and realize heterogeneous communications is the semi-termination model.
In the following sections, this paper proposes and describes a concrete implementation of the semi-termination mode that is called the SOCKS-based IPv6/IPv4 Translator.
This implementation is based on the SOCKS  system that is designed for a firewall system. In order to exchange information between a source client terminal and a translator server, the SOCKS protocol is used in this system.
The following figure shows the basic Translator mechanism.
In this figure, Client C initiates the communication to Destination D. Two new functional blocks that compose the system are introduced.
One, Socks Lib, is introduced into the client side (Client C) (this procedure is called "socksify"). It is located between application layer and socket layer, and can replace applications' socket APIs and DNS name-resolving APIs (e.g., gethostbyname(), getaddrinfo() ) dynamically. A mapping management table exists in it for "DNS name-resolving delegation" mechanism (described below). Each socksified application has its own Socks Lib.
The other, Translator, is an extended SOCKS server. It is installed on the IPv6 and IPv4 dual stack node (Translator T). All types of protocol combinations are relayed there between Client C (IPvX) and Destination D (IPvY). The Socks Lib invokes it. Each Translator takes charge of one socksified connection.
The following four types of combinations of IPvX and IPvY are possible in this mechanism.
Type A is supported by the normal SOCKS mechanism. Types B and C are the main targets for the translator mechanism. They provide heterogeneous communication topologies. Type D can be supported by the natural extension of the SOCKS mechanism, because it is a homogeneous communication.
The Socks Lib communicates with the Translator by using SOCKS protocol . The connection between Client C and Translator T is called a "socksified connection." It can transfer not only data but also control information (e.g., location information of the Destination).
In order to provide appropriate destination information to the application on the Client C, the Socks Lib also replaces other types of socket APIs (e.g., getpeername() ) that provide information about the destination, and necessary information for this replacement is transferred via the socksified connection.
This mechanism provides the same usability of current communication methods to the applications on Client C, and it is not necessary to modify the applications at all to utilize this mechanism.
The connection between Translator T and Destination D is an ordinary connection. Server applications on Destination D understand that the source of the connection is Translator T (not Client C). It is not necessary to modify (socksify) them.
As was previously pointed out, it is essential to integrate a DNS name-resolving mechanism into the translator mechanisms. The SOCKS-based Translator mechanism has the capability to integrate it without modifying the DNS system. This function is one of the big advantages of the SOCKS-based Translator mechanism.
The following figure shows the procedure of how to integrate the DNS name-resolving mechanism.
By using this mechanism, DNS name-resolving actions are delegated from the source terminal (Client C) to the relay server (Translator T). Thus the mechanism is called DNS name-resolving delegation.
The advantages of the DNS name-resolving delegation mechanism come from the fact that the DNS name-resolving actions are taken at the relay server (Translator T). Since the relay server is an IPv4 and IPv6 dual stack node, DNS name-resolving queries for any types of destinations can be done without causing problems. It is not necessary to modify the existing DNS mechanism at all.
Without this mechanism, an IPv4 application cannot resolve the host name of an IPv6 destination. Even if it can get IPv6 address by some method, it is impossible for the IPv4 application to deal with such an IPv6 address. It is impossible because the IPv6 address is four times longer than the IPv4 address, and the IPv4 application does not have any long address space in which to store it.
Using this mechanism brings forth an additional advantage: An IPv4 application can use a numerical IPv6 address expression also to specify an IPv6 destination terminal. Since the IPv6 address expression includes colons (":"), it is identified as an FQDN expression (not a numerical IP expression) for the IPv4 application. Thus the numerical IPv6 address expression is treated the same as the DNS expression in the DNS name-resolving delegation mechanism.
The problem with the mechanism is that a failure of the DNS name-resolving process is detected incorrectly at the source terminal (Client C). It is detected as a failure of the connection creation. In order to fix this problem, the author has proposed extensions of the current SOCKS protocol .
One of the good characteristics of the SOCKS-based Translator mechanism is its ability to manage address translation and mapping wisely.
In the case of the NAT-based transparent model translator mechanism (e.g., ), it is necessary to reserve global and wide address space for the address mapping. Also, complex address allocation and management mechanisms (by introducing address mappers, etc.) are needed.
In the case of the SOCKS-based semi-termination model Translator mechanism, such complex mechanisms are not necessary, because corresponding address mapping is done at the Socks Lib by using the fake IP address and mapping management table. The mapping management table is prepared on each application. It is locally closed and independent from others. Therefore, it is easy to manage the table, and it is not necessary to reserve global and wide address space.
The SOCKS-based Translator mechanism has the flexibility to support multiple chained relay topologies. With the mechanism, IPv4 and IPv6 mixed various communication topologies are realized.
The following figure shows the structure of the multiple chained relay mechanism.
In this figure, the source terminal (Client C) initiates the communication with the destination (Destination D). Underneath, the connection is replaced with three connections, and they are relayed at the two relay servers (Translator T1 and T2).
The Translator includes the same type of functions of Socks Lib. By enabling the Socks Lib functions at the Translator1 on the first relay server (Translator T1), the multiple chained relay topology is realized.
There is no limitation on the number of relay (translation) operations between the source terminal and the destination terminal. It is possible to have more than two intermediate relay servers. To simplify the explanation, twice-relayed topology is shown here. All types of protocol relay combinations are possible. In the case of twice-relayed topology, the following eight types of combinations of IPvX, IPvY, and IPvZ are possible:
Type E is supported by the normal SOCKS mechanism. The types from F to K are the main targets for the translator mechanisms. They provide heterogeneous communication topologies. Type L can be supported by the natural extension of the SOCKS mechanism, because it is a homogeneous communication.
Type G and type J can provide interesting topology cases. They are similar to the topologies that the tunneling techniques can provide. Compared with the tunneling techniques, the SOCKS-based Translator is advantageous, because it is composed of relays of real socket connections. This mechanism does not have to suffer from the following problems that are caused by tunneling techniques:
As an added advantage, well-authenticated connections are provided. This is because the SOCKS mechanism was originally designed for firewall systems and has various authentication methods.
In this section, the characteristics of the implemented SOCKS-based Translator mechanism are summarized.
The SOCKS-based Translator mechanism has three types of constraints.
It is verified that the implemented SOCKS-based Translator realizes heterogeneous communications of typical TCP and UDP services such as telnet, HTTP, POP (post office protocol), FTP, and TFTP (Trivial FTP). In the case of FTP, special implementation is needed. Some FTP commands (PORT, LPRT, and replies of PASV, LPSV) transfer IP address information as an argument to indicate the destination for on-demand data connection. By providing special routines to replace such IP addresses and to exchange such FTP commands (PORT <- LPRT, PASV <- LPSV), heterogeneous FTP communications are realized.
Since the SOCKS-based Translator works as an application, it basically does not depend on the IPv6 protocol stack implementations. However, an exception exists because there are some not-standardized specifications for IPv6 implementations. Specifically, there is no standardized method of getting IP address and prefix length information of each interface from the logical name of the interface. So the dependency exists as an exception. Accepting the constraint of not using logical interface names at configuration files eliminates dependence on IPv6 implementations.
The SOCKS-based Translator is evaluated. As a typical example, the following configuration is used for the performance: evaluation.
|IPv6 Implementation||KAME, etc.|
|Source, Translator Server(s), Destination||PCs (CPU: Pentium II 400 MHz, Memory 128MB)|
|Network||100BASE-TX (Full Duplex)
PCs are connected by a switching hub
It was observed that the Translator mechanism supported up to 100 heterogeneous communications simultaneously and achieved 60 Mbps throughput as a sum of the connections' throughput. (The throughput does not closely depend on the number of the simultaneous connections.)
The author concluded that the result (100 simultaneous communications, 60 Mbps total throughput per a translator server) has enough capability to support a normal-scale network environment. Since the Translator relays connections at the application layer, there was vulnerability to degrade the performance. However, no performance problems have been observed.
Since the Translator's performance has not been completely fine-tuned, it can be expected to improve.
This paper clarified the requirements to transit to IPv6 network environments and categorized various translator mechanisms that can realize heterogeneous communications between IPv4 and IPv6 terminals. After comparing the characteristics of various translation models, the semi-termination model was selected as the best solution.
The semi-termination model was implemented as the SOCKS-based Translator. Its DNS name-resolving delegation mechanism is one of the Translator's good characteristics. Its functions, characteristics, and constraints were summarized.
The implementation has already been evaluated and verified. It has demonstrated that the Translator supports typical communication services such as telnet, FTP, HTTP, and TFTP without any problems and that no performance problems exist.
Currently, the Translator is still in the developing stage; its functions are continuing to be enhanced and optimized. The author will report on an improved SOCKS-based Translator in a future paper.
The source codes of the reported SOCKS-based initial implementation are currently open to the public at http://www.socks.nec.com/.