[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


   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

                   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

   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.

           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

   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.

           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.

           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

   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

   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.


   [WIDEV6WG] WIDE Project IPv6 Working Group, "WIDE Project IPv6
         Working Group Home Page",

         RFC1034, November 1987.

         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",

   [SOCKS64URL] Fujitsu Laboratories LTD., "SOCKS64 package",

   [KAME] KAME Project, "KAME Project Home Page",

   [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",

Jinzaki                                                         [Page 6]

INTERNET-DRAFT                                             November 1998


   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]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/