INTERNET-DRAFT H. Kitamura NEC Corporation Expires in six months 16 November 1998 A SOCKS-based IPv6/IPv4 Translator Architecture Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes an IPv6/IPv4 Translator architecture that is based on the SOCKSv5 [RFC1928] mechanism. In this architecture, the SOCKS mechanism is extended by adding adaptive address family distinguish functions for supporting heterogeneous communications. By applying the mechanism together with protocol conversion functions, the IPv6/IPv4 Translator architecture is accomplished. This Translator provides communications between IPv6 and IPv4 nodes without sacrificing any convenience and functionalities of current communication methods. It is NOT necessary to modify the current DNS system at all. Only socksify environment is needed to communicate between IPv6 and IPv4 nodes. By using multiple chained Translators, a tunneling-like communication topology can be realized. With the architecture, there is no vulnerability of the packet fragmentation, and the connection can be authenticated by the native SOCKS authentication methods. H. Kitamura [Page 1] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 1. Introduction This document describes an IPv6/IPv4 Translator architecture that is based on the SOCKSv5 [RFC1928] mechanism. By extending the SOCKS mechanism for supporting heterogeneous communications, the IPv6/IPv4 Translator architecture is accomplished. The SOCKSv5 protocol is originally designed for an application level firewall system. With the SOCKS, a connection initiated by the client to the desired destination is replaced with two connections, and the SOCKS server relays these two connections internally. The SOCKS library is provided to the client node. Since the SOCKS library can replace the socket APIs and DNS name resolving APIs dynamically, the application on the client just feels that there is one normal direct connection to the desired destination. With this mechanism, the client application can keep the convenience and usage of current communication methods. The current SOCKS implementation relays connections between IPv4 nodes only. By applying to relay connections between IPv6 and IPv4 nodes, the IPv6/IPv4 Translator architecture is established. Since the SOCKS mechanism has capabilities to replace the client's socket APIs and DNS name resolving APIs (e.g., gethostbyname() etc.), this Translator architecture can provides good characteristics (e.g., no DNS modification, no address mapper etc.). With this architecture, IPv6 nodes and IPv4 nodes can communicate each other smoothly without difficulties. 2. Basic Translator Mechanism Fig. 1 shows the basic translator mechanism. In this figure, the Client C initiates the communication to the Destination D. Two new functional blocks are introduced as the normal SOCKS mechanism does, and they compose the Translator architecture. One is *SOCKS Lib*. The other is *Translator*. *SOCKS Lib* is introduced into the client side (Client C) (this procedure is called "socksify"). It replaces the client's socket APIs and DNS name resolving APIs (e.g., gethostbyname(), getaddrinfo() etc.). *Translator* is an extended SOCKS server. It must be run on the IPv6 and IPv4 dual stack node (Translator T). It relays connections between various combinations of IPvX and IPvY nodes (Client C and Destination D). H. Kitamura [Page 2] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 Client C Translator T Destination D +-----------+ (Server) |Application| +-->+===========+ +-------------+ +-----------+ same-+ |*SOCKS Lib*| |*Translator* | |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 Translator Mechanism The following 4 types of combinations of IPvX and IPvY are possible. type C ------ T ------ 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 current SOCKS mechanism. Type B and C provide heterogeneous communication topologies. They are main targets for the Translator architecture. Type D can be supported by the natural extension of the SOCKS mechanism, because it is a homogeneous communication topology. *SOCKS Lib* communicates with *Translator* by the SOCKSv5 protocol [SOCKS5] and the SOCKSv5 extended protocol [SOCKS5EXT]. The connection between the Client C and the Translator T is a socksified connection. It can transfer not only data but also control information (e.g. location information of the Destination etc.). The connection between the Translator T and the Destination D is a normal connection. It is not necessary to modify (socksify) the application on Destination D. H. Kitamura [Page 3] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 3. DNS Name Resolving Procedure As [TRANSMECH] mentioned, the DNS is important for a translator mechanism. Because information which address family (IPv4 only, IPv6 only, or both IPv6 and IPv4) is used at a destination node is provided by the DNS. NAT-based translator mechanisms (e.g., [NATPT]) are struggling to deal with DNS issues. Their approaches require to modify the DNS mechanism. The SOCKS-based Translator architecture can deal with the DNS information effectively, and it does NOT require to modify the DNS mechanism. In this section, a DNS name resolving procedure in the Translator architecture is described. As a typical example, type B combination case (Client is IPv4 node, Destination is IPv6 node) is explained. This procedure explains how the DNS name resolving problem (DNS query of AAAA record for IPv4 node) is solved and how the address mapping is created. 1. An application in the Client C calls DNS name resolving function (e.g., gethostbyname2()). The logical host name FQDN of the Destination D exist in the argument of the function. 2. Since the *SOCKS Lib* has replaced gethostbyname2(), the real gethostbyname2() function is not called. The argument information which includes FQDN is recorded and saved at the *SOCKS Lib*. 3. The *SOCKS Lib* selects a fake address from reserved fake address space, and replies it to the application. The fake address must be suitable. Namely, it belongs to the same address family of the Client node. (In this case, it is an IPv4 fake address.) 4. The *SOCKS Lib* creates an entry of the argued FQDN and the selected fake address in the mapping table. 5. The application receives the fake address from the *SOCKS Lib* as a reply. 6. The application calls a socket function (e.g., connect()). The received fake address information is used as an element of the argued socket. 7. Since the *SOCKS Lib* has replaced such a socket function, the real socket function is not called. H. Kitamura [Page 4] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 8. The address information of the argued socket is checked. If the address belongs to the fake address space, the matched FQDN information of the fake address is picked up from the mapping table. 9. The matched FQDN information is transferred to the *Translator* by using the SOCKS command that is matched to the called socket function. (In case of connect(), the CONNECT command is used.) 10. Finally, the *Translator* receives FQDN information of the destination from the *SOCKS Lib* and calls the real DNS name resolving function (e.g., gethostbyname2()). * DNS Name Resolving Delegation The above mechanism resolves the DNS name resolving problems, because the real DNS name resolving function is called at the IPv6 and IPv4 dual stack node (Translator T). Also, an implementation of the IPv4-mapped IPv6 address is NOT indispensable at the Translator T, because the IPv4-mapped IPv6 address is not necessary in this mechanism. This mechanism is called "DNS name resolving delegation". It has already implemented in the SOCKSv5 implementation. With this mechanism, smooth communications between IPv6 and IPv4 nodes are realized. If the Destination D has both AAAA record and A record, the procedure becomes a little bit complex. The Client C has to show the preference which address family must be use between the Translator T and the Destination D. [SOCKS5EXT] has considered this case, and extensions of the SOCKSv5 protocol are proposed. * Address Mapping Compulsory to say, an address mapping is occurred at the *SOCKS Lib* by creating a mapping table entry of the combination of the selected fake address and the FQDN of the Destination D. Since the mapping table is created on each application, it is local and independent from others. This means that is not necessary to reserve global and wide address space for the address mapping. Only local and small fake address space is needed. This prevents the scalability problem. H. Kitamura [Page 5] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 4. Multiple Chained Relay Mechanism The SOCKS mechanism can provide more advanced communication topologies. It is called "Multiple Chained Relay". Fig. 2 shows the multiple chained relay mechanism. Client C Translator T1 Translator T2 Destination D +-----------+ (Server 1) (Server 2) |Application| +===========+ +-------------+ +-------------+ +-----------+ |*SOCKS Lib*| |*Translator1*| |*Translator2*| |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 Client C initiates the communication with the Destination D. Underneath, the connection is replaced by 3 connections, and they are relayed via the Translator T1 and T2. The *Translator* includes the same *SOCKS Lib* functionalities inside. By enabling the *SOCKS Lib* functionalities at the *Translator1*, this topology is realized. When the Translator T1 communicate with the Translator T2 by the SOCKS protocol, *SOCKS Lib* functionalities is used. There is no limitation of the times to relay. More than twice of internal relays are possible. To simplify to explain, twice relayed mechanism is explained in this section. There is no limitation on the number of relay (translation) operations between the Client C and the Destination D. It is possible to have more than two intermediate Translators. To simplify the discussion, a two-stage relayed mechanism is explained in this section. H. Kitamura [Page 6] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 The connection between the Client C and the Translator T1 and the connection between the Translator T1 and the Translator T2 are socksified connections. They can transfer not only data but also control information (e.g. location information of the Translator T2 and the Destination etc.). The connection between the Translator T2 and the Destination D is a normal connection. It is not necessary to modify (socksify) the application on the Destination D. In this twice relayed topology, the following 8 types of combinations of IPvX, IPvY, and IPvZ are possible. type C ------ T1 ------ T2 ------ D [IPvX] (IPvY) {IPvZ} E IPv4 IPv4 IPv4 homogeneous (normal SOCKS) F IPv4 IPv4 IPv6 * heterogeneous * G IPv4 IPv6 IPv4 * heterogeneous * (tunnel) H IPv4 IPv6 IPv6 * heterogeneous * I IPv6 IPv4 IPv4 * heterogeneous * J IPv6 IPv4 IPv6 * heterogeneous * (tunnel) K IPv6 IPv6 IPv4 * heterogeneous * L IPv6 IPv6 IPv6 homogeneous Type A is supported by the current SOCKS mechanism. From type F to type K are heterogeneous communication topologies. They are main targets for the Translator architecture. Type L can be supported by the natural extension of the SOCKS mechanism, because it is a homogeneous communication topology. Type G and type J combinations are the most interesting cases. They provide similar topologies as the tunneling techniques. Since they are composed of real socket connections, they are efficient and do NOT suffer from the following problems that caused by tunneling techniques * Fragmentation vulnerability The tunneling technique uses the packet encapsulation mechanism. In the encapsulation mechanism, the length of the packet is increased because of the additional header. It may exceed the MTU of the network. So, the tunneling technique has the vulnerability that the packet might be fragmented. In case of the SOCKS-based architecture, the size of the each relayed TCP packet is not changed, because the connections (sockets) are relayed at the application level. So, there is no fragmentation vulnerability. H. Kitamura [Page 7] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 * Hop limit (metric number) problem The tunneling technique creates one virtual connection over the dynamically routed and configured real networks. In spite of the hop limit (or metric number) of the based real networks is changed dynamically, the hop limit (or metric number) of the virtual connection can not reflect the appropriate value. This fact causes the effective problem. In case of the SOCKS-based architecture, all of the relayed connections are real. So, this type of the problem is never happened. In addition, the well-authenticated connections are provided. Because the SOCKS mechanism is originally designed for the firewall system, and it has various authentication methods. 5. Characteristics In this section, characteristics of the SOCKS-based Translator architecture are summarized. 1. DNS modification is NOT necessary Address map servers are NOT necessary Global and wide reserved address space is NOT necessary Section "3. DNS Name Resolving Procedure", has explained these issues. 2. Application independent If applications use the socket APIs and DNS name resolving APIs, they work properly in the SOCKS-based Translator architecture. There are exceptions, if applications exchange IP address information with peer applications (e.g., ftp PORT command), they do not work properly without special modification. 3. OS and NIC types independent Since the *SOCKS Lib* and the *Translator* run as applications, the SOCKS-base Translator architecture runs on both UNIX and Windows OSs, and it dose not depend on types of physical NICs. H. Kitamura [Page 8] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 4. Only easy socksify procedure is necessary The socksification is not difficult, because the dynamic link library technique helps the socksification. 5. IPv6 new features (e.g., IPSec) can be used Since two terminated connections are relayed internally, it is easy to enable new features that are introduced by IPv6 on one side IPv6 connection. In case of NAT-based translators, it is very difficult to realize this issue. 6. Current existing client SOCKSv5 library can be used In case of the IPv4 -> IPv6 direction translation, the current existing client SOCKSv5 library that are basically designed for IPv4 -> IPv4 can be used without modification. 7. Both TCP and UDP relay translations are possible. Since the SOCKSv5 protocol support both TCP and UDP relays, this architecture can translate not only TCP but also UDP relays. 8. Both direction IPv6 <-/-> IPv4 translations are possible This architecture can realize not only IPv6 <- IPv4 translation but also IPv6 -> IPv4 translation with the same mechanism. 9. Multiple chained relay is possible. Section "4. Multiple Chained Relay Mechanism", has explained this issues. 10. Can support the applications that exchange IP address information at the application level. Basically, such applications can not be support by the Translator architecture. However, if such protocols are known like ftp, the Translator architecture can support them by introducing special protocol translation routines into the *Translator*. The *Translator* has the capability to introduce such protocol translation routines. H. Kitamura [Page 9] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 6. Constraints The translation mechanism can not become almighty, because IPv6 and IPv4 are different protocols. The SOCKS-based Translator architecture has following constraints. 1. Essential constraint getpeername() and getsockname() functions can not provide correct IP address information. This is caused by the fact IPv6 and IPv4 are different protocols. However, appropriate port information can be provided by the SOCKSv5 protocol. Because IPv6 and IPv4 deal with the same size port space. 2. Limitation of the SOCKS mechanism Current SOCKSv5 can not socksify all of tricky applications. This limitation also can be applied for the SOCKS-based Translator architecture. 3. Fake address dealing constraint The fake address must be dealt as a temporary value in the application. It must not be recorded permanently. After the application finished, the fake address information must be vanished. Otherwise, problems will happen. Most of applications records FQDN and does not record DNS name resolved fake addresses. So, from the realistic viewpoint, this constraint is small. H. Kitamura [Page 10] INTERNET-DRAFT IPv6/IPv4 Translator Architecture November 1998 References [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & Jones, L., "SOCKS Protocol V5," RFC1928, April 1996. [SOCKS5] VanHeyningen, M, "SOCKS Protocol Version 5," June 1998 currently draft-ietf-aft-socks-pro-v5-03.txt [SOCKS5EXT] H. Kitamura, "SOCKSv5 Protocol Extension for IPv6/IPv4 Communication Environment", currently draft-kitamura-socks-ipv6-00.txt [TRANSMECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [NATPT] G. Tsirtsis and P. Srishuresh, "Network Address Translation - Protocol Translation (NAT-PT)", currently draft-ietf-ngtrans-natpt-02.txt [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", currently draft-ietf-ipngwg-ipv6-spec-v2-01.txt Author's Address Hiroshi Kitamura NEC Corporation C&C Media Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81 (44) 856-2123 Fax: +81 (44) 856-2230 EMail: kitamura@ccm.cl.nec.co.jp H. Kitamura [Page 11]