One document matched: draft-ietf-ngtrans-socks-gateway-03.txt
Differences from draft-ietf-ngtrans-socks-gateway-02.txt
INTERNET-DRAFT H. Kitamura
<draft-ietf-ngtrans-socks-gateway-03.txt> NEC Corporation
Expires in six months 9 March 2000
A SOCKS-based IPv6/IPv4 Gateway Mechanism
<draft-ietf-ngtrans-socks-gateway-03.txt>
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 July 1999
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", it eliminates problems of the NAT-based
translator mechanisms that translate packets at the "network layer"
(e.g., packet fragmentation vulnerability).
Another advantage of the mechanism is that there is no need to modify
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 client
applications. This is a constraint. To eliminate the need to modify
the DNS system, it is necessary to socksify the applications. Thus,
there is a dilemma in that either socksification or DNS modification
is necessary.
Also, the mechanism has the following additional by-product benefits.
Since the SOCKS-based gateway mechanism has much flexibility, it can
support various topologies that mix IPv4 and IPv6 communications. In
case of multiple chained relay topologies, the SOCKS-based gateway
mechanism can accomplish similar topologies that are supported by
packet tunneling techniques. Compared with other translator
mechanisms, the SOCKS-based gateway mechanism has the following
benefits. There is no packet fragmentation vulnerability, and the
H. Kitamura [Page 2]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
connection can be authenticated by the native SOCKS authentication
methods.
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.
H. Kitamura [Page 3]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
The following four types of combinations of IPvX and IPvY are
possible in this mechanism.
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
H. Kitamura [Page 4]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
SOCKS-based gateway mechanism has the capability to cooperate with it
without modifying the DNS system. This function is one of the big
advantages of the SOCKS-based gateway mechanism.
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".
This is one of the important key features for the SOCKS-based
IPv6/IPv4 gateway mechanism. Effective use of it enables smooth
heterogeneous communications between the IPv6 nodes and IPv4 nodes
without modifying applications.
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 introduced as a replied information to the application,
and it becomes a key to look up the corresponding FQDN information in
the table.
The transparentness to applications is maintained in the "DNS name
resolving delegation", because the delegation is accomplished by
replacing DNS name resolving APIs dynamically with the *Socks Lib*.
It is not necessary to modify applications on the client. By calling
a DNS name resolving API, "DNS name resolving delegation" is
internally executed. Socksified applications can run as usual, and
there is no need to be concerned 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 July 1999
The method of using FQDN information in the ATYP field depends on
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 via its API (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 function 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 a replied information 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 as a return value
of the DNS name resolving API 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 here. 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., the CONNECT command is
used in case of connect().)
H. Kitamura [Page 6]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
6. Finally, the real DNS name resolving function (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 API.
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 function (e.g., connect()) to
communicate with the Destination D. The "socket" is used as an
argument of its API.
By using this mechanism, DNS name resolving actions are delegated
from the source terminal (Client C) to the relay server (Gateway G).
* DNS Name Resolving Delegation and address mapping
The advantages of the "DNS name resolving delegation" feature come
from the fact that the 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. The IPv6 address is four times longer than the
IPv4 address, and the IPv4 application does not prepare any long
address space in which to store it.
Using this feature brings forth an additional advantage: 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 July 1999
* Address Translation and Mapping
One of the good characteristics of the SOCKS-based gateway mechanism
is its ability to manage address translation and mapping wisely.
In case of the NAT-based translator mechanism (e.g., [NATPT]), it is
necessary to reserve global and wide address space for the address
mapping. Also, complex address allocation and management mechanisms
(by introducing address mappers, etc.) are needed.
In case of the SOCKS-based gateway mechanism, such complex mechanisms
are not necessary, because corresponding address mapping is done at
the *Socks Lib* by using the fake IP address and the delegation
mapping table. The delegation mapping table is prepared on 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 global and wide address space.
As [CATTRANS] mentioned, the SOCKS-based gateway mechanism is free
from the address mapping problem.
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
H. Kitamura [Page 8]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
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.
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.
Compared with the tunneling techniques, the SOCKS-based gateway is
advantageous, because it is composed of relays of real socket
connections. This mechanism is thus free from the following problems
that are caused by tunneling techniques.
* Fragmentation vulnerability
The tunneling technique uses a packet encapsulation mechanism. In
the encapsulation mechanism, the packet length is changed because
of the additional header, and it may exceed the MTU of the network.
Thus, the tunneling technique is vulnerable in that the packet
might be fragmented. With the SOCKS-based gateway mechanism, there
H. Kitamura [Page 9]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
is no fragmentation vulnerability because the packet size is
adjusted at the application layer.
As an added advantage, well-authenticated connections are provided.
This is because the SOCKS mechanism was originally designed for
firewall systems, and it has various authentication methods.
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 global and wide 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 as data with
peers (e.g., ftp PORT command) 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.
H. Kitamura [Page 10]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
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.
With NAT-based translators, it is impossible to do the same thing.
6. Current existing client SOCKSv5 library can be used:
In case of the IPv4 -> IPv6 relay, the current existing client
SOCKSv5 library that is designed for IPv4 -> IPv4 communication
can be used without modification.
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. Can support exceptional applications that exchange IP address
information as data at the application level:
It is easy for the SOCKS-based gateway mechanism to introduce
special management routines. If such protocols (e.g., ftp PORT)
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.
H. Kitamura [Page 11]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
6. Applicability statement
The SOCKS-based gateway mechanism requests socksification of
applications (install *Socks Lib*) to accomplish heterogeneous
communications. Though the socksification is not difficult, it is one
of the constraints for users.
The socksification mechanism provides the advantage that the SOCKS-
based gateway mechanism does not require modification of the DNS
system. 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.
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 called in order to get port information (not IP
address information).
2. Limitation of the SOCKS mechanism:
Since the current SOCKS system can not socksify all of the tricky
applications in which extraordinary means 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 happen.
From a realistic viewpoint, this is also a minor constraint,
because most applications record FQDN information instead of fake
addresses.
H. Kitamura [Page 12]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
It is theoretically possible for the SOCKS mechanism to support ICMP
relays, but the current SOCKS mechanism does not. So, the SOCKS-based
gateway mechanism does not support ICMP relays.
However, the reference implementation of the current SOCKS mechanism
support typical ICMP applications (ping and traceroute) by using
different methods. So, the SOCKS-based gateway mechanism can support
ping and traceroute.
(Implementations of the SOCKS-based gateway mechanism have supported
ping and traceroute [see Appendix A])
7. Conclusion
As described above, the SOCKS-based IPv6/IPv4 gateway mechanism has
many advantages. From a realistic viewpoint, its constraints are
negligible.
Only two things are necessary to utilize this gateway mechanism.
1. Prepare an enhanced SOCKS sever on the dual stack node.
[see Appendix A. two implementations are available]
2. Socksify applications when you execute them.
This is a very easy procedure.
You don't have to modify the DNS system at all.
You don't have to reserve any addresses.
You don't have to prepare address mapping servers. etc.
Since the mechanism is based on relaying two "terminated"
connections, most problems of the NAT-based translator mechanisms are
eliminated.
Also, the "DNS name resolving delegation" feature works effectively.
It enables smooth heterogeneous communications between IPv6 and IPv4
nodes without modifying the DNS system.
8. Security Considerations
Since the SOCKS-based IPv6/IPv4 gateway mechanism is based on SOCKSv5
protocol, the security feature of the mechanism follows that of
SOCKSv5. It is described in the Security Considerations section of
the SOCKS Protocol Version 5 [SOCKSv5].
H. Kitamura [Page 13]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
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 14]
INTERNET-DRAFT A SOCKS-based IPv6/IPv4 Gateway July 1999
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.
[INET] H. Kitamura, "Entering the IPv6 communication world by
the SOCKS-based IPv6/IPv4 Translator,"
in Proceedings of INET99, 1999.
[NATPT] G. Tsirtsis and P. Srishuresh, "Network Address
Translation - Protocol Translation (NAT-PT)",
RFC2766, February 2000.
[CATTRANS] K. Yamamoto, M. Sumikawa, "Categorizing Translators
between IPv4 and IPv6,"
<draft-ietf-ngtrans-translator-02.txt> work in progress
[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
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 15]
| PAFTECH AB 2003-2026 | 2026-04-23 22:33:24 |