One document matched: draft-jinzaki-socks64-00.txt
INTERNET-DRAFT A. Jinzaki
Expires in six months S. Kobayashi
Fujitsu Laboratories LTD.
November 1998
SOCKS64: An IPv4-IPv6 intercommunication gateway using SOCKS5 protocol
<draft-jinzaki-socks64-00.txt>
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]
| PAFTECH AB 2003-2026 | 2026-04-23 16:04:21 |