[INET'99] [ Up ][Prev]

Entering the IPv6 Communication World by the SOCKS-Based IPv6/IPv4 Translator

Hiroshi KITAMURA <kitamura@ccm.cl.nec.co.jp>
NEC Corporation
Japan

Abstract

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.

Contents

Introduction

With a trigger to solve the IPv4 address space exhaustion problem, the research of next-generation Internet protocol (IP) IPv6 [1] 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 [2]. 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.

Requirements to transit to the IPv6 environment

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:

  1. Keep conveniences of current IPv4 communication methods and frameworks of existing communication networks.
  2. Utilize existing user applications that are designed only for IPv4 communications to heterogeneous communications without modifying them.
  3. Be scalable and able to support the translations for all services.

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. [3][4][5][6]. 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 [7].

Necessary functions for translator mechanisms

In this section, necessary functions for translator mechanisms are analyzed from three viewpoints: protocol translations, user applications, and assumed applied environments.

Protocol translation viewpoints

Basically, two types of protocol translations are necessary for translator mechanisms:

IP protocol translation

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-related protocol translation.

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.

User application viewpoints

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 [2].

Viewpoints of assumed applied environments

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.

  1. Support both IPv4 - IPv6 and IPv6 - IPv4 heterogeneous communications.

    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 [8].

  2. Make existing IPv4 applications be recognized as if IPv6 applications had run by using a translator at a source terminal locally.
  3. Support complex communication topologies such as multiple chained relay translations of any protocol combinations, because available protocols and topologies for communications are often restricted by routers' security filters.
  4. Can introduce new features of IPv6 (e.g., IPSEC) without losing their functions.
  5. Be independent of OS (operating system) and physical NIC (network interface card) types.

Categorization of translator mechanisms

In order to clarify characteristics of translator mechanisms, translator methods are categorized. The categorization issue is also being discussed at IETF [8]. In this paper, translator mechanisms are categorized by using two viewpoints: an implemented protocol layer viewpoint and an installed node position viewpoint.

By implemented protocol layer

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.

Implemented at IP layer

In most cases, the NAT (network address translation) [9] 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 [3][4] and [5] describe typical examples of this method. This method is called transparent model.

Implemented at application layer

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 [10]).

By installed node position

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.

Installed at source terminal

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' [5] 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.

Installed at intermediate node

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.

Installed at destination terminal

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.

Characteristics of translator mechanism models

In this section, characteristics of translator mechanism models are analyzed and clarified.

Transparent model

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.

Full-termination model

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.

Semi-termination model

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.

SOCKS-based translator mechanism

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 [10] 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.

Basic Translator mechanism

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 IPvX IPvY  
A IPv4 IPv4 Homogeneous (normal)
B IPv4 IPv6 Heterogeneous
C IPv6 IPv4 Heterogeneous
D IPv6 IPv6 Homogeneous

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 [10]. 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.

DNS name-resolving procedure

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.

  1. An application on the source terminal (Client C) tries to get IP the address information of the destination terminal (Destination D) by calling the DNS name-resolving function (e.g., gethostbyname2() ). At this time, the logical host name (FQDN) information of Destination D is passed to the Socks Lib as an argument of called APIs.
  2. Since the Socks Lib has replaced such DNS name-resolving APIs, the real DNS name-resolving APIs is not called here. The argued FQDN information is merely registered into a mapping management table of Socks Lib, and a fake IP address is selected as a reply value from a reserved special IP address space that is never used in real communications. The fake IP address must be suitable for requests called by the applications. Namely, it must belong to the same address family of Client C, even if the address family of Destination D is different from it. After selected fake IP address is registered into the mapping management table as a pair of the FQDN, it is replied to the application.
  3. The application receives the fake IP address and prepares a socket. The fake IP address information is used as an element of the socket. The application calls socket APIs (e.g., connect() ) to start a communication. The socket is used as an argument of them.
  4. Since the Socks Lib has replaced such socket APIs, the real socket function is not called. The IP address information of the argued socket is checked. If the address belongs to the special address space for the fake address, the matched registered FQDN information of the fake IP address is obtained from the mapping management table.
  5. The FQDN information is transferred to the Translator on the relay server (Translator T) by using the SOCKS command that is matched to the called socket APIs. (In case of connect(), the CONNECT command is used.)
  6. Finally, the Translator calls the real DNS name-resolving APIs (e.g., gethostbyname2() ). At this time, received FQDN information is used as an argument of the called APIs.
  7. The Translator receives the real IP address from a DNS server, and creates a socket. The real IP address information is used as an element of the socket.
  8. The Translator calls socket APIs (e.g., connect() ) to communicate with Destination D. The socket is used as an argument of them.

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.

DNS name-resolving delegation and address mapping

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 [11].

Address translation and mapping

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., [4][5]), 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.

Multiple chained relay mechanism (advanced usage)

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 IPvX IPvY IPvZ  
E IPv4 IPv4 IPv4 Homogeneous (normal)
F IPv4 IPv4 IPv6 Heterogeneous
G IPv4 IPv6 IPv4 Heterogeneous (tunnel-like)
H IPv4 IPv6 IPv6 Heterogeneous
I IPv6 IPv4 IPv4 Heterogeneous
J IPv6 IPv4 IPv6 Heterogeneous (tunnel-like)
K IPv6 IPv6 IPv4 Heterogeneous
L IPv6 IPv6 IPv6 Homogeneous

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:

  1. Fragmentation vulnerability
  2. Hop limit (metric number) problem

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.

Characteristics of the SOCKS-based Translator mechanism

In this section, the characteristics of the implemented SOCKS-based Translator mechanism are summarized.

  1. DNS modification is not necessary: It is not necessary to reserve global and wide address space for address mapping. Also, address map servers are not necessary, because of the DNS Name Resolving Delegation mechanism.
  2. Application-independent: The mechanism is realized by replacing the socket APIs, and DNS name-resolving APIs are replaced at the Socks Lib. If the applications use these APIs, the translator mechanism is applied to them. As most communication programs use these APIs, there is no application dependency. (Applications that exchange IP address information with peers are exceptions.)
  3. OS and NIC types independent: Since the Socks Lib and the Translator run as applications, the SOCKS-based Translator mechanism runs on any platforms of either UNIX or Windows OSs, and there is no dependency on the types of physical NICs.
  4. Only an easy socksify procedure is necessary: It is easy to install the Socks lib (socksify) to the source terminal because the dynamic link library technique helps this procedure.
  5. IPv6 new features (e.g., IPSEC) can be utilized easily: Since connections are first terminated and then relayed at the translator, it is easy to enable IPv6 new features on the IPv6 side. In the case of NAT-based translators, it is impossible to do the same thing.
  6. Current existing client SOCKSv5 library can be used: In case of the IPv4 - IPv6 translation, the current existing client SOCKSv5 library that is designed for IPv4 - IPv4 communication can be used without modification.
  7. Both transmission control protocol (TCP) and user datagram protocol (UDP) relay translations are possible: Since the SOCKS protocol supports both TCP and UDP relays, this mechanism can also translate both TCP and UDP connections.
  8. Both IPv4 - IPv6 and IPv6 - IPv4 translations are possible: This mechanism can realize not only IPv4 - IPv4 translation but also IPv6 - IPv4 translation with the same method.
  9. Multiple chained relays are possible: Since the mechanism has flexibility, all types of protocol combinations of multiple chained relays are possible.
  10. Can support exceptional applications that exchange IP address information at the application level: It is easy for the translator to introduce special management routines. If such protocols as FTP are known, the Translator can support them by introducing special protocol translation routines. (The implemented SOCKS-based translator has supported FTP protocol translation.)
  11. Easy load balancing: Since the translator is implemented as a server, it is easy to balance the load by supplying multiple servers.

Constraints of the SOCKS-based Translator mechanism

The SOCKS-based Translator mechanism has three types of constraints.

  1. Essential constraints: Constraints are caused by the address length difference between IPv4 and IPv6. Functions that request an IP address as one of the return values (e.g., getpeername() and getsockname() ) cannot provide the correct IP address as a return value. However, an appropriate port value can be provided, because IPv4 and IPv6 use the same size port space and necessary port information is transferred by the SOCKS protocol. From a realistic viewpoint, this is a minor constraint, because such functions are called in order to get port information (not IP address information).
  2. Limitation of the SOCKS mechanism: Since the current SOCKS system cannot socksify all of the tricky applications in which extraordinary means are used to create connections, the SOCKS-based Translator mechanism cannot be applied to them.
  3. Constraints to deal with the fake address: The fake address must be dealt with as a temporary value at the application; it must not be recorded permanently as a bookmark. After the application is finished, the fake address information must be released. Otherwise, problems will occur. From a realistic viewpoint, this is also constraint, because most applications record FQDN information instead of fake addresses.

Evaluation of the implemented SOCKS-based Translator

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.

Performance evaluation

The SOCKS-based Translator is evaluated. As a typical example, the following configuration is used for the performance: evaluation.

OS FreeBSD 2.2.7R
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.

Conclusion

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/.

References

[INET'99] [ Up ][Prev]