INTERNET-DRAFT H. Kitamura NEC Corporation Expires in six months 6 April 2000 A SOCKS-based IPv6/IPv4 Gateway Mechanism Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an IPv6/IPv4 gateway mechanism that is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to support the heterogeneous communications relays between IPv6 and IPv4 at the SOCKS server, the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished. Since it is accomplished without introducing new protocols, it provides the same communication environment that is provided by the SOCKS mechanism. The same appearance is provided to the heterogeneous communications. No conveniences or functionalities of current communications are sacrificed. The SOCKS-based gateway mechanism enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. H. Kitamura [Page 1] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 1. Introduction This document describes an IPv6/IPv4 gateway mechanism that is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to support heterogeneous communications, the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished. The SOCKS-based gateway mechanism is designed to satisfy the following requirements. 1. Maintain the conveniences of current IPv4 communication methods and frameworks (infrastructure) of existing communication networks (e.g., DNS). 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 various IPv4 and IPv6 communication services. 4. Can easily introduce IPv6 new features (e.g., IPSec). Since the SOCKS-based IPv6/IPv4 gateway mechanism is based on a mechanism that relays two "terminated" IPv4 and IPv6 connections at the "application layer", its characteristics are inherited from those of the connection relay mechanism at the application layer and those of the native SOCKS mechanism. The SOCKS-based IPv6/IPv4 gateway mechanism does not require any modifications to the DNS system, because it has a feature that enables the DNS name resolving actions of SOCKS clients to be delegated to an enhanced SOCKS server that has both IPv6 and IPv4 stacks. This DNS name resolving delegation is enabled by socksifying applications. Socksifying is a constraint of the mechanism. However, it is necessary to socksify applications to eliminate the need to modify the DNS system. Thus, there is a dilemma in that either socksification or DNS modification is necessary. Since the SOCKS is originally designed for firewall security systems, it supports various connections relay topologies and provides sufficient authentication methods for the connection relays. Since the SOCKS-based gateway mechanism inherits the characteristics, it has much flexibility in supporting various relay topologies that mix IPv4 and IPv6 communications, and the relayed connections can be authenticated by the native SOCKS authentication methods. H. Kitamura [Page 2] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 2. Basic SOCKS-based Gateway Mechanism Figure 1 shows the basic SOCKS-based gateway mechanism. Client C Gateway G Destination D +-----------+ (Server) |Application| +-->+===========+ +-------------+ +-----------+ same-+ |*SOCKS Lib*| | *Gateway* | |Application| API +-->+===========+ +=====---=====+ +-----------+ | Socket DNS| | Socket DNS | | Socket DNS| +-----------+ +-------------+ +-----------+ | [ IPv X ] | |[IPvX]|(IPvY)| | ( IPv Y ) | +-----------+ +-------------+ +-----------+ |Network I/F| | Network I/F | |Network I/F| +-----+-----+ +---+-----+---+ +-----+-----+ | | | | +============+ +------------+ socksified normal connection connection (ctrl)+data data only Fig. 1 Basic SOCKS-based Gateway Mechanism In this figure, the Client C initiates the communication to the 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 "socksifying"). It is located between application layer and socket layer, and can replace applications' socket APIs and DNS name resolving APIs (e.g., gethostbyname(), getaddrinfo() etc.) dynamically. A delegation mapping table exists in it for a "DNS name resolving delegation" feature (described below). Each socksified application has its own *Socks Lib*. The other, *Gateway*, is an enhanced SOCKS server. It is installed on the IPv6 and IPv4 dual stack node (Gateway G). All types of protocol combinations are relayed there between Client C (IPvX) and Destination D (IPvY). The *Socks Lib* invokes it. Each *Gateway* takes charge of one socksified connection. The following four types of combinations of IPvX and IPvY are possible in this mechanism. H. Kitamura [Page 3] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 type C ------ G ------ D [IPvX] (IPvY) A IPv4 IPv4 homogeneous (normal SOCKS) B IPv4 IPv6 * heterogeneous * C IPv6 IPv4 * heterogeneous * D IPv6 IPv6 homogeneous Type A is supported by the normal SOCKS mechanism. Type B and C are the main targets for the SOCKS-based gateway 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 *Gateway* by using SOCKS protocol [SOCKSv5]. The connection between the Client C and the Gateway G is called a "socksified connection." It can transfer not only data but also control information (e.g. location information of the Destination, etc.). 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(), etc.) 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 the Client C, and it is not necessary to modify the applications at all to utilize this mechanism. The connection between the Gateway G and the Destination D is an ordinary connection. Server applications on Destination D understand that the source of the connection is the Gateway G (not Client C). It is not necessary to modify (socksify) them. Since no new special SOCKS protocols are introduced in the mechanism, there is no difference in appearance among these four combinations. The address family information of the Destination D mainly decides a communication type from these combinations. 3. DNS Name Resolving Procedure As [TRANSMECH] mentioned, it is essential for the transition mechanisms to cooperate with the DNS name resolving mechanism. The SOCKS-based gateway mechanism has the capability to cooperate with it without modifying the DNS system. H. Kitamura [Page 4] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 In this section, the procedure of how the SOCKS-based gateway mechanism cooperates with the DNS name resolving mechanism is described. In the SOCKS protocol specification [SOCKSv5], it is defined that IPv4 address, IPv6 address, and DOMAINNAME (FQDN) information can be used in the ATYP (address type) field of the SOCKS protocol format. Since DOMAINNAME (FQDN) information can be used in the ATYP (address type) field, it becomes possible to delegate the DNS name resolving action at the SOCKS clients to the DNS name resolving action at the SOCKS server. This feature is called "DNS name resolving delegation". Effective use of "DNS name resolving delegation" enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes without modifying applications. Typical "socksification" is accomplished by dynamically changing the linking order of dynamic link libraries (specifically, by linking the SOCKS dynamic link library before the dynamic link libraries for normal socket and DNS name resolving APIs). So, it is not necessary to modify applications (change their source codes and recompile them, etc.) in typical "socksification". In order to accomplish the "DNS name resolving delegation", a delegation mapping table is prepared in *Socks Lib* (at the client). This is an internal table between a socksified application and its *Socks Lib*. It is local and independent of other applications or their *Socks Lib*s. In the delegation mapping table, a "fake IP" address is used as a key to look up the corresponding FQDN information, and it is information that is replied to the application. The transparentness to applications is maintained in the "DNS name resolving delegation", because it is accomplished by dynamically replacing DNS name resolving APIs with the *Socks Lib*. It is not necessary to modify applications on the client. By calling a DNS name resolving API, a "DNS name resolving delegation" is internally executed. Socksified applications can run as usual, and there is no need to be concerned about the existence of the "DNS name resolving delegation". The "DNS name resolving delegation" is accomplished only when FQDN information is used in the ATYP (address type) field of the SOCKS command. Therefore, it is mandatory to do so for the heterogeneous communications between the IPv6 nodes and IPv4 nodes. H. Kitamura [Page 5] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 The method of using FQDN information in the ATYP field depends on the configuration setting and implementation of the SOCKS protocol. In order to simplify the discussion, only the case in which the FQDN information is used in the ATYP field is discussed here. The detailed internal procedure of the "DNS name resolving delegation" is as follows. 1. An application on the source terminal (Client C) tries to get the IP address information of the destination terminal (Destination D) by calling the DNS name resolving function (e.g., gethostbyname()). At this time, the logical host name ("FQDN") information of the Destination D is passed to the application's *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 delegation mapping table in *Socks Lib*, and a "fake IP" address is selected as information that is replied to the application from a reserved special IP address space that is never used in real communications (e.g., 0.0.0.x). The address family type of the "fake IP" address must be suitable for requests called by the applications. Namely, it must belong to the same address family of the Client C, even if the address family of the Destination D is different from it. After the selected "fake IP" address is registered into the delegation mapping table as a pair with 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 delegation mapping table. 5. The "FQDN" information is transferred to the *Gateway* on the relay server (Gateway G) by using the SOCKS command that is matched to the called socket APIs. (e.g., in case of connect(), the CONNECT command is used.) H. Kitamura [Page 6] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 6. Finally, the real DNS name resolving API (e.g., getaddrinfo()) is called at the *Gateway*. At this time, the received "FQDN" information via the SOCKS protocol is used as an argument of the called APIs. 7. The *Gateway* obtains 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 *Gateway* calls socket APIs (e.g., connect()) to communicate with the 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 (Gateway G). (Restrictions on applicability of "fake IP" address, etc. are described in Section 6.) * DNS Name Resolving Delegation and Address Mapping In the "DNS name resolving delegation", the real DNS name resolving actions are taken at the relay server (Gateway G). Since the relay server is an IPv4 and IPv6 dual stack node, DNS name resolving queries for any address family types of destinations can be done without causing problems. Therefore, it is not necessary to modify the existing DNS mechanism at all. Without this feature, an IPv4 application can not resolve the host name of an IPv6 destination. Even if it can get the 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 feature brings forth an additional feature: an IPv4 application can also use a numerical IPv6 address expression 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" feature. The problem with the feature 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. H. Kitamura [Page 7] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 * Address Mapping-like Operations The SOCKS-based gateway mechanism has the ability to manage address translation and mapping wisely. It does not require the reserving of a wide global address space for the address mapping, and complex address allocation and management mechanisms are not necessary, because address mapping-like operations are done at the *Socks Lib* by using the fake IP address and the delegation mapping table. Since the delegation mapping table is prepared for each application, it is locally closed and independent of other applications. Therefore, it is easy to manage the table, and it is not necessary to reserve a wide global address space. 4. Multiple Chained Relay Mechanism (Advanced usage) The SOCKS-based gateway mechanism has the flexibility to support multiple chained relay topologies. With the mechanism, IPv4 and IPv6 mixed various communication topologies are accomplished. Figure 2 shows the structure of the multiple chained relay mechanism. Client C Gateway G1 Gateway G2 Destination D +-----------+ (Server 1) (Server 2) |Application| +===========+ +-------------+ +-------------+ +-----------+ |*SOCKS Lib*| | *Gateway1* | | *Gateway2* | |Application| +===========+ +=====---=====+ +=====---=====+ +-----------+ | Socket DNS| | Socket DNS | | Socket DNS | | Socket DNS| +-----------+ +-------------+ +-------------+ +-----------+ | [ IPv X ] | |[IPvX]|(IPvY)| |(IPvY)|{IPvZ}| | { IPv Z } | +-----------+ +-------------+ +-------------+ +-----------+ |Network I/F| | Network I/F | | Network I/F | |Network I/F| +-----+-----+ +---+-----+---+ +---+-----+---+ +-----+-----+ | | | | | | +============+ +==========+ +------------+ socksified socksified normal connection connection connection (ctrl)+data (ctrl)+data data only Fig. 2 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 (Gateway G1 and G2). The *Gateway* includes the same type of functions of *Socks Lib*. By enabling the *Socks Lib* functions at the *Gateway1* on the first relay server (Gateway G1), the multiple chained relay topology is accomplished. H. Kitamura [Page 8] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 There is no limitation on the number of relay operations between the source terminal and the destination terminal. It is possible to have more than two intermediate relay servers. To simplify the explanation, a twice-relayed topology is shown here. All types of the protocol relay combinations are possible. In case of twice-relayed topology, the following eight types of combinations of IPvX, IPvY, and IPvZ are possible. type C ------ G1 ------ G2 ------ D [IPvX] (IPvY) {IPvZ} E IPv4 IPv4 IPv4 homogeneous (normal SOCKS) 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 gateway 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. However, their characteristics are different. * Packet Size Adjustment Since the length of the IPv6 header is different from the length of the IPv4 header, it is necessary to consider the packet size adjustment in heterogeneous communications. If this is not taken into consideration, the packet size may exceed the MTU of the network. Since the SOCKS-based IPv6/IPv4 gateway mechanism is based on an "application layer" connection relay mechanism, the packet size is naturally adjusted at the application layer and it never exceeds the MTU of the network. * Authenticated Relay Since the SOCKS is originally designed for firewall systems and it has various authentication methods, the relayed connections can be authenticated by the native SOCKS authentication methods. H. Kitamura [Page 9] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 5. Characteristics of the SOCKS-based gateway mechanism In this section, the characteristics of the SOCKS-based gateway mechanism are summarized. 1. DNS modification is not necessary: It is not necessary to reserve a wide global address space for address mapping. Also, address map servers are not necessary, because there is a "DNS Name Resolving Delegation" mechanism. 2. Application independent: If the applications use socket APIs and DNS name resolving APIs, the gateway mechanism is applied to them, since the mechanism is accomplished by replacing these APIs that at the *Socks Lib*. As most communication programs use these APIs, there is no application dependency. (Applications that exchange IP address information with peers are exceptions) 3. Independent of OS and NIC types: Since the *Socks Lib* and the *Gateway* run at the application layer, the SOCKS-base gateway mechanism runs on any of the platforms of either UNIX or Windows OSs, and there is no dependency on the type of physical NIC. 4. Only an easy socksification 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 *Gateway*, it is easy to enable IPv6 new features on the IPv6 side. 6. Current existing client SOCKSv5 library can be used: For the IPv4 -> IPv6 relay, the current existing client SOCKSv5 library that is designed for IPv4 -> IPv4 communication can be used without modification. H. Kitamura [Page 10] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 7. Both TCP and UDP relays are possible: Since the SOCKS protocol supports both TCP and UDP relays, this mechanism can also relay both TCP and UDP connections. 8. Both IPv4 -> IPv6 and IPv6 -> IPv4 relays are possible: This mechanism can accomplish not only the IPv4 -> IPv6 relay but also the IPv6 -> IPv4 relay 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. Exceptional applications are supported that exchange IP address information at the application level: It is easy for the SOCKS-based gateway mechanism to introduce special management routines. If such protocols as ftp are known, the SOCKS-based gateway mechanism can support them by introducing special protocol translation routines. (Implementations of the SOCKS-based gateway mechanism have supported the ftp protocol translation [see Appendix A]) 11. Easy load balancing: Since the *Gateway* is installed as a server, it is easy to balance the load by supplying multiple servers. 6. Applicability statement The SOCKS-based gateway mechanism requests socksification of applications (install *Socks Lib*) to accomplish heterogeneous communications. Since typical socksification is done by changing the linking order of dynamic link libraries, it is not difficult. However, it is one of the constraints for users. In order to eliminate the need to modify the DNS system, the socksification is necessary in the mechanism. Thus, there is a dilemma in that either socksification or DNS modification is necessary. Other than the socksification, the SOCKS-based gateway mechanism has the following three types of constraints. H. Kitamura [Page 11] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 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() etc.) can not 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 mainly called in order to get port information (not IP address information). 2. Constraints of the SOCKS mechanism: Since the current SOCKS system can not socksify all of the tricky applications in which extraordinary manners are used to create connections, the SOCKS-based gateway mechanism can not 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, etc. After the application is finished, the fake address information must be released. Otherwise, problems will occur. From a realistic viewpoint, this is also a minor constraint, because most applications record FQDN information instead of (fake) IP addresses. 7. Security Considerations Since the SOCKS-based IPv6/IPv4 gateway mechanism is based on SOCKSv5 protocol, the security feature of the mechanism matches that of SOCKSv5. It is described in the Security Considerations section of the SOCKS Protocol Version 5 [SOCKSv5]. H. Kitamura [Page 12] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 Appendix A. Implementations Currently, there are two independent implementations of the SOCKS- based IPv6/IPv4 gateway mechanism. Both of them are open to the public. One is NEC's implementation. Its source codes are available at the following URL. http://www.socks.nec.com/ The other is Fujitsu Lab.'s implementation, which is called "SOCKS64." Its source codes are available at the following URL. ftp://ftp.kame.net/pub/kame/misc/socks64-... Appendix B. Experiments We have been testing SOCKS64, one of the SOCKS-based gateway implementations in many environments. Since July 1998, we have been running the SOCKS64 server in between the 6bone and the internal network of Fujitsu Ltd., Japan. Computers in Fujitsu's internal network already have been "socksified", so users can connect to 6bone hosts merely by selecting our SOCKS64 server as their SOCKS gateway. For an interoperability test, we have been providing a SOCKS64 server in the WIDE Project[WIDEV6WG] Camp, where about 200 Internet researchers are participating. A temporary network called "camp-net" is constructed at the camp for a variety of experiments and provides services to the attendees. More than a hundred hosts are connected to the camp-net. In these environments, we have tested many types of SOCKS5 clients, including the SocksCap32[SOCKSCAP] on Windows and a variety of UNIX based SOCKS libraries, and confirmed any clients successfully connected to the IPv6 hosts using telnet, ftp, http, ssh. Also we have tested a very complicated interconnection of IPv4 and IPv6. At the WIDE camp held in September 1998, we constructed an IPv4 over IPv6 tunnel using the SOCKS64 and the FAITH translator. In this system, the SOCKS5 clients had no problems connecting to the IPv4 hosts through the IPv6 networks. IPv4 host --SOCKS-- SOCKS64 --IPv6-- IPv6-IPv4 -- IPv4 host /IPv4 server translator In conclusion, SOCKS64 provides an easy and sure way to let IPv4 hosts connect to IPv6 hosts. H. Kitamura [Page 13] INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway April 2000 References [SOCKSv5] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & Jones, L., "SOCKS Protocol V5," RFC1928, April 1996. [TRANSMECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC2460, December 1998. [INET99] H. Kitamura, "Entering the IPv6 communication world by the SOCKS-based IPv6/IPv4 Translator," in Proceedings of INET99, July 1999. [WIDEV6WG] WIDE Project IPv6 Working Group, "WIDE Project IPv6 Working Group Home Page", http://www.v6.wide.ad.jp/. [SOCKSCAP] NEC, "SocksCap Web Page", http://www.socks.nec.com/sockscap.html. Authors' Addresses: Hiroshi Kitamura NEC Corporation NEC NETWORKS, Networks Development Labratories (Igarashi Building) 11-5, Shibaura 2-Chome, Minato-Ku, Tokyo 108-8557, JAPAN Phone: +81 (3) 5476-1071 Fax: +81 (3) 5476-1005 Email: kitamura@da.jp.nec.com H. Kitamura [Page 14]