INTERNET-DRAFT A. Jinzaki Expires in six months S. Kobayashi Fujitsu Laboratories LTD. November 1998 SOCKS64: An IPv4-IPv6 intercommunication gateway using SOCKS5 protocol 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 memo describes an IPv4-IPv6 intercommunication method based on the SOCKS5 protocol. The method is called SOCKS64, and was first announced in the 40th IETF meeting at Washington DC in December 1997 as one of three translators being developed in the WIDE Project. SOCKS64 is a gateway system that accepts SOCKS5 connections from IPv4 hosts and relays it to IPv4/IPv6 hosts using proper protocols. We have designed and implemented a prototype SOCKS64 system and have been testing the prototype in many environments. Also we are distributing the prototype as a KAME distribution package. This article describes the SOCKS64; its principle, implementation, experimental results and comparison to other IPv4-IPv6 intercommunication methods. Jinzaki [Page 1] INTERNET-DRAFT November 1998 1. Principle In this section, we describe the SOCKS system briefly and figure out a basic idea to use it as an intercommunication gateway system for different protocols. The SOCKS protocol has been developed as a firewall gateway protocol that provides hosts in a firewall with a relay service of transport layer (TCP) data to outside of the firewall. A SOCKS server, placed in a border of the firewall, accepts a SOCKS connection from a host inside the firewall, makes a new connection to a host outside the firewall, and relays the transport layer data between these two connections. inside firewall | outside firewall IPv4 host --SOCKS/IPv4-- SOCKS server --IPv4-- IPv4 host Once the SOCKS scheme is understood, it is easy to imagine to connect different protocols in the similar way. First, a host with a protocol-1 (P1) connects to a SOCKS server using the SOCKS protocol over P1. Next the SOCKS server makes a connection to the destination host with a protocol-2 (P2) using P2. Once the connections are established, the SOCKS server starts to relay the transport layer data between these connections. P1 host --SOCKS/P1-- SOCKS server --P2-- P2 host It seems to be a simple way to connect two protocols, though there is an big problem to complete such a scheme, an addressing system problem. Any protocol has its own addressing system. The P1 host should know an address of the P2 host, when it wants to connect to. Generally, the P1 host has no way to get the P2 address because it does not know the P2 addressing system. To solve this problem, there should be an addressing system that is recognized by both protocols. Fortunately, in the world of Internet Protocol, we have the Domain Name System[DNS1,DNS2] and the Fully Qualified Domain Name (FQDN) as a rigid solution. Using DNS, the P1 host can address the P2 host using FQDN2, and the P2 host can address the P1 host using FQDN1. In this case, the story goes like the following. First, the P1 host asks the SOCKS server to connect to the P2 host specifying FQDN2 as the address. Then the SOCKS server asks the DNS server for the actual address of FQDN2 and gets the P2 address. So the SOCKS server can make a connection with the P2 host, and relay Jinzaki [Page 2] INTERNET-DRAFT November 1998 the transport layer data between two connections. FQDN2 P1 host --SOCKS/P1-- SOCKS server ---P2--- P2 host | resolve FQDN2 | | DNS server Using this scheme, a SOCKS server that is constructed on an IPv4-IPv6 dual stack host can act as such a transport relay gateway, if the SOCKS protocol has a capability to specify connecting hosts by FQDN addresses. Originally, SOCKS was for IPv4 and was not made to handle other protocols than IPv4. The SOCKS protocol versions before SOCKS5 could treat only the IPv4 address, so it could not relay connections between hosts with different protocols. But when the SOCKS5 protocol[SOCKS5] has introduced the FQDN address type, it became possible to use the SOCKS protocol for an intercommunication gateway of different network layer protocols, IPv4 and IPv6. FQDN2 IPv4 host --SOCKS/IPv4-- SOCKS server --IPv6-- IPv6 host | resolve FQDN2 | IPv6 (AAAA) address | DNS server In the case an IPv6 host wants to connect to an IPv4 host, a completely symmetric scheme can be used. FQDN1 IPv6 host --SOCKS/IPv6-- SOCKS server --IPv4-- IPv4 host | resolve FQDN1 | IPv4 (A) address | DNS server 2. Implementation Based on the principle described above, we have implemented a prototype SOCKS64 server based on the SOCKS5 reference code[SOCKS5URL]. The SOCKS64 prototype is distributed freely[SOCKS64URL]. In this section, we describe an implementation of the SOCKS64 server based on our experiences. Current implementation of the SOCKS64 Jinzaki [Page 3] INTERNET-DRAFT November 1998 prototype runs on BSD/OS 3.1 with the KAME IPv6 protocol stack[KAME]. There is no modification in the client library for the IPv4 hosts. As for the client library for the IPv6 hosts, the new functions such as getaddrinfo() should be provided. However, our current implementation does not provide such new functions. Implementing the SOCKS64 server, there is no fundamental problem. Our implementation of the SOCKS64 server consists of two major modifications to the SOCKS5 reference code. One is to make the SOCKS5 server IPv6 capable, and the other is to add a framework which enables the SOCKS5 server to do application specific processings. The former modification includes the changes in "struct sockaddr", and making the configuration file parser to be able to read IPv6 addresses as specified in RFC2373[IPV6ADDR]. The other modification is needed because some applications use IP addresses in their protocols. For example, FTP protocol[FTP] specifies that an FTP server and an FTP client exchange the IP addresses in text format. So it is required to realize a processing for FTP, converting the PORT command into the LPRT command, the PASV command into LPSV command, and translating between the IPv4 address and the IPv6 address. The LPRT command and the LPSV command are described in RFC1639[FOOBAR]. 3. Experiments We have been testing the SOCKS64 server 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 only 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 attend. A temporary network called "camp-net" is constructed at the camp for a variety of experiments and provides services to the attendees. More than 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 much complicated interconnection of IPv4 and IPv6. At the WIDE camp held in September 1998, we constructed a IPv4 Jinzaki [Page 4] INTERNET-DRAFT November 1998 over IPv6 tunnel using the SOCKS64 and the NAT based translator. In this system, the SOCKS5 clients could connect to the IPv4 hosts with no problem through the IPv6 networks. IPv4 host --SOCKS-- SOCKS64 --IPv6-- IPv6-IPv4 -- IPv4 host /IPv4 server translator Concluding, SOCKS64 provides an easy and sure way to let IPv4 hosts connect to IPv6 hosts. 4. Considerations In this section, we compare the SOCKS64 method to other IPv4-IPv6 interconnection methods. The common way being developed is the "translator" based on the Network Address Translation (NAT) technology. The translator translates IPv4 packets and IPv6 packets one by one. To solve the addressing system problem, the translator has an association table of IPv4 and IPv6 addresses, and uses these addresses to translate packets. This approach requires an extension of DNS to manage the address association table. SOCKS64 does not need such changes. A shortcoming of the translator is a transport layer data processing. Because the translator works in the network layer, it has some difficulties when the transport layer data is required to be changed. The FTP addresses embedded in the transport layer data is an obvious example. The application-level gateways can change the transport layer data naturally. FAITH, distributed in the KAME distribution package, is an example of such approach. FAITH does not require client hosts to change their software. But it requires special DNS treatment as same as the NAT based translator. On the other hand, the biggest shortcoming of SOCKS64 is that every clients should be "socksified". It should be a bothering work for network managers to support SOCKS users. Here is the summary of comparison described above. +--------+----------------+------------+------------+------------+ | | Implementation | DNS | Address | Client | | | Layer | Change | Table | Library | +--------+----------------+------------+------------+------------+ |NAT | Network | needed | needed | not needed | |FAITH | Application | needed | needed | not needed | |SOCKS64 | Application | not needed | not needed | needed | +--------+----------------+------------+------------+------------+ Jinzaki [Page 5] INTERNET-DRAFT November 1998 5. Conclusion The SOCKS approach provides a reasonable way to construct an IPv4-IPv6 intercommunication gateway. Especially, many firewall users who are already "SOCKS ready" can communicate with IPv6 hosts with no special care. Firewall managers also need no extra care adopting SOCKS64, because SOCKS64 preserves all security features the original SOCKS has. References [WIDEV6WG] WIDE Project IPv6 Working Group, "WIDE Project IPv6 Working Group Home Page", http://www.v6.wide.ad.jp/. [DNS1] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC1034, November 1987. [DNS2] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC1035, November 1987. [SOCKS5] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and L. Jones, "SOCKS Protocol Version 5", RFC1928, March 1996. [SOCKS5URL] NEC, "SOCKS Home Page", http://www.socks.nec.com/. [SOCKS64URL] Fujitsu Laboratories LTD., "SOCKS64 package", ftp://ftp.kame.net/pub/kame/misc/socks64-v10r3-980623.tgz. [KAME] KAME Project, "KAME Project Home Page", http://www.kame.net/. [FTP] J. Postel and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", RFC959, October 1985. [FOOBAR] D. Piscitello, "FTP Operation Over Big Address Records (FOOBAR)", RFC1639, June 1994. [IPV6ADDR] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC2373, July 1998. [SOCKSCAP] NEC, "SocksCap Home Page", http://www.socks.nec.com/sockscap.html. Jinzaki [Page 6] INTERNET-DRAFT November 1998 Acknowledgements The authors would like to thank the members of the WIDE Project for many suggestions and cooperations in carrying out our experiments. Authors' Addresses: Akira Jinzaki Fujitsu Laboratories LTD. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki, 211-8588 Japan Phone: +81-44-777-1111 ex. 2-6331 Fax: +81-44-754-2771 Email: zinzin@flab.fujitsu.co.jp Shinji Kobayashi Fujitsu Laboratories LTD. 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki, 211-8588 Japan Phone: +81-44-754-2627 Fax: +81-44-754-2771 Email: koba@flab.fujitsu.co.jp Jinzaki [Page 7]