As per Relevance of the word mechanism, we have this rfc below:
Network Working Group H.
Request for Comments: 3089 NEC
Category: Informational April 2001
A SOCKS-based IPv6/IPv4 Gateway
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes a SOCKS-based IPv6/IPv4 gateway
that enables smooth heterogeneous communications between the IPv
nodes and IPv4 nodes
It is based on the SOCKS protocol [SOCKSv5]. By applying the
mechanism to the heterogeneous communications and relaying
"terminated" IPv4 and IPv6 connections at the "application layer
(the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism
accomplished
Since it is accomplished without introducing new protocols,
provides the same communication environment that is provided by
SOCKS mechanism. The same appearance is provided to
heterogeneous communications. No conveniences or functionalities
current communications are sacrificed
1.
The SOCKS-based IPv6/IPv4 gateway mechanism is based on a
that relays two "terminated" IPv4 and IPv6 connections at
"application layer" (the SOCKS server); its characteristics
inherited from those of the connection relay mechanism at
application layer and those of the native SOCKS mechanism
Kitamura Informational [Page 1]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
2. Basic SOCKS-based Gateway
Figure 1 shows the basic SOCKS-based gateway mechanism
Client C Gateway G Destination
+-----------+ (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
connection
(ctrl)+data data
Fig. 1 Basic SOCKS-based Gateway
In this figure, the Client C initiates the communication to
Destination D. Two new functional blocks are introduced and
compose the mechanism
One, *Socks Lib*, is introduced into the client side (Client C) (
procedure is called "socksifying"). The *Socks Lib* is
between the application layer and the socket layer, and can
applications' socket APIs and DNS name resolving APIs (e.g.,
gethostbyname(), getaddrinfo() etc.). There is a mapping table in
for a "DNS name resolving delegation" feature (described below).
Each socksified application has its own *Socks Lib*.
The other, *Gateway*, is installed on the IPv6 and IPv4 dual
node (Gateway G). It is an enhanced SOCKS server that enables
types of protocol combination relays between Client C (IPvX)
Destination D (IPvY). When the *Socks Lib* invokes a relay,
corresponding *Gateway* process (thread) is spawned from the
*Gateway* to take charge of the relay connection
The following four types of combinations of IPvX and IPvY
possible in the mechanism
Kitamura Informational [Page 2]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
type C ------ G ------
[IPvX] (IPvY
A IPv4 IPv4 homogeneous (normal SOCKS
B IPv4 IPv6 * heterogeneous *
C IPv6 IPv4 * heterogeneous *
D IPv6 IPv6
Type A is supported by the normal SOCKS mechanism. Type B and C
the main targets for the SOCKS-based IPv6/IPv4 gateway mechanism
They provide heterogeneous communications. Type D can be
by the natural extension of the SOCKS mechanism, because it is
homogeneous communication
Since the *Socks Lib* communicates with the *Gateway* by using
protocol [SOCKSv5], the connection between them (the Client C and
Gateway G) is a special connection and is called a "
connection". It can transfer not only data but also
information (e.g., the location information of Destination D).
The connection between the Gateway G and the Destination D is
normal connection. It is not modified (socksified). A
application that runs on Destination D does not notice the
of the Client C. It recognizes that the peer node of the
is the Gateway G (not Client C).
No new protocols are introduced to the SOCKS protocol [SOCKSv5]
accomplish the mechanism
* Packet Size
Since the length of the IPv6 header is different from that of
IPv4 header, it is necessary to consider the packet size
in heterogeneous communications. If this is not taken
consideration, the packet size may exceed the MTU of the network
In the SOCKS-based IPv6/IPv4 gateway mechanism, it never
the MTU, because the mechanism is based on relaying
"terminated" connections at the "application layer". The
data is a simple data stream for the application, and the
size is naturally adjusted at each relayed connection side
* Authenticated
Since the SOCKS is originally designed for firewall systems and
has various authentication methods, the relayed connections can
authenticated by the native SOCKS authentication methods
Kitamura Informational [Page 3]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
3. DNS Name Resolving
In all communication applications, it is a necessary to
destination IP address information to start a communication. It is
however, theoretically impossible for the
communications to obtain correct information, because an
IPv4 application can not deal with an IPv6 address. It prepares
a 4-byte address space to store an IP address information, and it
not store an IPv6 address information into there. This is a
problem caused by differences in address length
In order to solve the problem, a feature called "DNS name
delegation" is used in the SOCKS-based IPv6/IPv4 gateway mechanism
The feature involves the delegating of DNS name resolving actions
the source node (Client C) to the relay server (Gateway G).
the relay server is an IPv4 and IPv6 dual stack node, DNS
resolving queries for any address family types of destinations can
made without causing any problems. Therefore, it is not necessary
modify the existing DNS mechanism at all
The feature supports not only the case in which a destination
host name (FQDN) information is given but also the case in which
destination literal (numerical) IP address is given. The latter
is supported in almost the same way as the former case. Since
literal IPv6 address expression includes colons (":"), it
identified as an FQDN (not a literal IPv4 address) for the IPv
application
The SOCKS protocol specification [SOCKSv5] defines that IPv4 address
IPv6 address, and DOMAINNAME (FQDN) information can be used in
ATYP (address type) field of the SOCKS protocol format. In the "
name resolving delegation" feature, the DOMAINNAME (FQDN)
is used in the ATYP (address type) field. The FQDN information
transferred from the Client C to the Gateway G to indicate
Destination D
In order to solve the formerly explained critical problem,
appropriate "fake IP" address is introduced in the feature, and it
used as a virtual destination IP address for a
application. A mapping table is also introduced in the *Socks Lib
(at the Client C) to manage mappings between "fake IP" and "FQDN".
"fake IP" address is used as a key to look up the
"FQDN" information. The mapping table is local and independent
other applications or their *Socks Lib*s
Kitamura Informational [Page 4]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
The transparentness to applications is maintained in the feature
Nothing special is required to execute it except socksifying
applications. Since DNS name resolving APIs are replaced by
*Socks Lib*, the "DNS name resolving delegation" is
internally merely by calling the DNS name resolving APIs in
methods
The "DNS name resolving delegation" is accomplished only when
information is used in the ATYP (address type) field of the
command. Therefore, it is mandatory to do so for
communications. The method of using FQDN information in the
field depends on the configuration setting and implementation of
SOCKS protocol. In order to simplify the discussion, only the
in which the FQDN information is used in the ATYP field is
here
The detailed internal procedure of the "DNS name
delegation" and address mapping management related issues
described as follows
1. An application on the source node (Client C) tries to get
IP address information of the destination node (Destination D)
calling the DNS name resolving function (e.g., gethostbyname()).
At this time, the logical host name ("FQDN") information of
Destination D is passed to the application's *Socks Lib* as
argument of called APIs
2. Since the *Socks Lib* has replaced such DNS name resolving APIs
the real DNS name resolving APIs is not called here. The
"FQDN" information is merely registered into a mapping table
*Socks Lib*, and a "fake IP" address is selected as
that is replied to the application from a reserved special
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
suitable for requests called by the applications. Namely, it
belong to the same address family of the Client C, even if
address family of the Destination D is different from it.
the selected "fake IP" address is registered into the
table as a pair with the "FQDN", it is replied to the application
3. The application receives the "fake IP" address, and prepares
"socket". The "fake IP" address information is used as an
of the "socket". The application calls socket APIs (e.g.,
connect()) to start a communication. The "socket" is used as
argument of the APIs
Kitamura Informational [Page 5]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
4. Since the *Socks Lib* has replaced such socket APIs, the
socket function is not called. The IP address information of
argued socket is checked. If the address belongs to the
address space for the fake address, the matched registered "FQDN
information of the "fake IP" address is obtained from the
table
5. The "FQDN" information is transferred to the *Gateway* on
relay server (Gateway G) by using the SOCKS command that
matched to the called socket APIs. (e.g., for connect(),
CONNECT command is used.)
6. Finally, the real DNS name resolving API (e.g., getaddrinfo())
called at the *Gateway*. At this time, the received "FQDN
information via the SOCKS protocol is used as an argument of
called APIs
7. The *Gateway* obtains the "real IP" address from a DNS server
and creates a "socket". The "real IP" address information is
as an element of the "socket".
8. The *Gateway* calls socket APIs (e.g., connect()) to
with the Destination D. The "socket" is used as an argument of
APIs
The problem with the feature is that failures of the DNS
resolving process are detected incorrectly at the source node (
C). They are detected as connection-establishment failures
(Restrictions on applicability of "fake IP" address, etc.,
described in Section 5.)
* Operations for Address Management (reservation, mapping etc.)
The SOCKS-based gateway mechanism does not require the reserving of
wide global address space for the address mapping, and
address allocation and garbage-collection mechanisms are
necessary
Such address management operations are done at the *Socks Lib*
using the fake IP address and the mapping table for the DNS
resolving delegation. Since the mapping table is prepared in
application, it is locally closed and independent of
applications. Therefore, it is easy to manage the table, and it
not necessary to reserve a wide global address space
Kitamura Informational [Page 6]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
4. Multiple Chained Relay Mechanism (Advanced usage
The SOCKS-based gateway mechanism has the flexibility to
multiple chained relay topologies. With the mechanism, IPv4 and IPv
mixed various communication topologies are accomplished
Figure 2 shows the structure of the multiple chained relay mechanism
Client C Gateway G1 Gateway G2 Destination
+-----------+ (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
connection connection
(ctrl)+data (ctrl)+data data
Fig. 2 Multiple Chained Relay
In this figure, the source node (Client C) initiates
communication with the destination (Destination D). Underneath,
connection is replaced with three connections, and they are
at the two relay servers (Gateway G1 and G2). The *Gateway*
the same type of functions of *Socks Lib*. By enabling the *
Lib* functions at the *Gateway1* on the first relay server (
G1), the multiple chained relay topology is accomplished
There is no limitation on the number of relay operations between
source node and the final destination node. It is possible to
more than two intermediate relay servers. To simplify
explanation, a twice-relayed topology is shown here
Since the multiple chained relay is more complex than one-time
and causes complexity, it is recommended that the multiple
relay communication should be used only when it is necessary for
reason (e.g., usable protocols or topologies are limited by
etc.).
Kitamura Informational [Page 7]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
5. Applicability
The SOCKS-based gateway mechanism requests socksification
applications (install *Socks Lib*) to accomplish
communications. It is not necessary to modify (change source
and recompile them, etc.) the applications, because
socksification is done by changing the linking order of dynamic
libraries (specifically, by linking the SOCKS dynamic link
before the dynamic link libraries for normal socket and DNS
resolving APIs).
The mechanism does not request modification of the DNS system
because the DNS name resolving procedure at the Client C is
to the dual stack node Gateway G
Other than the socksification, the SOCKS-based gateway mechanism
the following three types of constraints
1. Essential constraints
Constraints are caused by the address length difference
IPv4 and IPv6.
Functions that request an IP address as one of the return
(e.g., getpeername() and getsockname() etc.) can not provide
correct IP address as a return value. However, a suitable
value can be provided, because IPv4 and IPv6 use the same
port space and an appropriate port information is transferred
the SOCKS protocol
2. Constraints of the SOCKS mechanism
Since the current SOCKS system can not socksify all of the
applications in which extraordinary manners are used to
connections, the SOCKS-based gateway mechanism can not be
to them
3. Constraints to deal with the fake address
The fake address must be dealt with as a temporary value at
application. It is used as a key value in the mapping table
the "DNS name resolving delegation" feature. When the
is finished and the mapping table disappears, the fake
information must be also released
Even if it is recorded permanently (e.g., recorded as a bookmark),
serious problems will not occur. The recorded fake
information will merely become useless, because fake
Kitamura Informational [Page 8]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
information is taken from a reserved special IP address space
is never used in real communications (e.g., 0.0.0.x) and such
information is useless for the normal communication applications
Furthermore, such cases will be rare because most
usually record FQDN information (not fake IP address information
to the bookmark, etc
5.1 Native SOCKS mechanism
The characteristics of the SOCKS-based IPv6/IPv4 gateway
are inherited from those of the native SOCKS mechanism. Therefore
consideration issues of the native SOCKS mechanism are discussed
this section
The SOCKSv5 protocol is composed of three commands (CONNECT, BIND
UDP ASSOCIATE). All of three commands can be applied in the SOCKS
based IPv6/IPv4 gateway mechanism
This document is described with assuming the usage of the
command mainly, because the CONNECT command is the main and
frequently used command in the SOCKS mechanism. Since the
command does not have clear week points, we can use it freely
considerations
The other (BIND and UDP ASSOCIATE) commands have the following
points. So, we have to consider these points when we use the BIND
UDP ASSOCIATE commands in the mechanism
The BIND command is basically designed to support reverse-
rendezvous of the FTP type applications. So, general usages of
BIND command may cause problems
The UDP ASSOCIATE command is basically designed for simple
applications (e.g., archie). It is not general enough to support
large class of applications that use both TCP and UDP
Kitamura Informational [Page 9]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
6. Security
Since the SOCKS-based IPv6/IPv4 gateway mechanism is based on SOCKSv
protocol, the security feature of the mechanism matches that
SOCKSv5. It is described in the Security Considerations section
the SOCKS Protocol Version 5 [SOCKSv5].
The mechanism is based on relaying two "terminated" connections
the "application layer". The end-to-end security is maintained
each of the relayed connections (i.e., between Client C and
G, and between Gateway G and Destination D). The mechanism does
provide total end-to-end security relay between the original
(Client C) and the final destination (Destination D).
Kitamura Informational [Page 10]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
Appendix A.
Currently, there are two independent implementations of the SOCKS
based IPv6/IPv4 gateway mechanism. Both of them are open to
public
One is NEC's implementation. Its source codes are available at
following URL
http://www.socks.nec.com
The other is Fujitsu Lab.'s implementation, which is
"SOCKS64". Its source codes are available at the following URL
ftp://ftp.kame.net/pub/kame/misc/socks64-...
[SOCKSv5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.
L. Jones, "SOCKS Protocol V5", RFC 1928, April 1996.
[TRANSMECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms
IPv6 Hosts and Routers", RFC 2893, August 2000.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[INET99] H. Kitamura, "Entering the IPv6 communication world
the SOCKS-based IPv6/IPv4 Translator", in Proceedings
INET99, July 1999.
Author's
Hiroshi
NEC
Development
(Igarashi Building 4F) 11-5, Shibaura 2-Chome
Minato-Ku, Tokyo 108-8557,
Phone: +81 (3) 5476-1071
Fax: +81 (3) 5476-1005
EMail: kitamura@da.jp.nec.
Kitamura Informational [Page 11]
RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Kitamura Informational [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
