summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3089.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3089.txt')
-rw-r--r--doc/rfc/rfc3089.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3089.txt b/doc/rfc/rfc3089.txt
new file mode 100644
index 0000000..5be7799
--- /dev/null
+++ b/doc/rfc/rfc3089.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group H. Kitamura
+Request for Comments: 3089 NEC Corporation
+Category: Informational April 2001
+
+
+ A SOCKS-based IPv6/IPv4 Gateway Mechanism
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document describes a SOCKS-based IPv6/IPv4 gateway mechanism
+ that enables smooth heterogeneous communications between the IPv6
+ nodes and IPv4 nodes.
+
+ It is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS
+ mechanism to the heterogeneous communications and relaying two
+ "terminated" IPv4 and IPv6 connections at the "application layer"
+ (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.
+
+1. Introduction
+
+ The SOCKS-based IPv6/IPv4 gateway mechanism is based on a mechanism
+ that relays two "terminated" IPv4 and IPv6 connections at the
+ "application layer" (the SOCKS server); its characteristics are
+ inherited from those of the connection relay mechanism at the
+ 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 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 are introduced and they
+ compose the mechanism.
+
+ One, *Socks Lib*, is introduced into the client side (Client C) (this
+ procedure is called "socksifying"). The *Socks Lib* is located
+ between the application layer and the socket layer, and can replace
+ applications' socket APIs and DNS name resolving APIs (e.g.,
+ gethostbyname(), getaddrinfo() etc.). There is a mapping table in it
+ 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 stack
+ node (Gateway G). It is an enhanced SOCKS server that enables any
+ types of protocol combination relays between Client C (IPvX) and
+ Destination D (IPvY). When the *Socks Lib* invokes a relay, one
+ corresponding *Gateway* process (thread) is spawned from the parent
+ *Gateway* to take charge of the relay connection.
+
+ The following four types of combinations of IPvX and IPvY are
+ possible in the mechanism.
+
+
+
+
+
+
+Kitamura Informational [Page 2]
+
+RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
+
+
+ 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 IPv6/IPv4 gateway mechanism.
+ They provide heterogeneous communications. Type D can be supported
+ by the natural extension of the SOCKS mechanism, because it is a
+ homogeneous communication.
+
+ Since the *Socks Lib* communicates with the *Gateway* by using SOCKS
+ protocol [SOCKSv5], the connection between them (the Client C and the
+ Gateway G) is a special connection and is called a "socksified
+ connection". It can transfer not only data but also control
+ information (e.g., the location information of Destination D).
+
+ The connection between the Gateway G and the Destination D is a
+ normal connection. It is not modified (socksified). A server
+ application that runs on Destination D does not notice the existence
+ of the Client C. It recognizes that the peer node of the connection
+ is the Gateway G (not Client C).
+
+ No new protocols are introduced to the SOCKS protocol [SOCKSv5] to
+ accomplish the mechanism.
+
+ * Packet Size Adjustment
+
+ Since the length of the IPv6 header is different from that of the
+ IPv4 header, it is necessary to consider the packet size adjustment
+ in heterogeneous communications. If this is not taken into
+ consideration, the packet size may exceed the MTU of the network.
+
+ In the SOCKS-based IPv6/IPv4 gateway mechanism, it never exceeds
+ the MTU, because the mechanism is based on relaying two
+ "terminated" connections at the "application layer". The relayed
+ data is a simple data stream for the application, and the packet
+ size is naturally adjusted at each relayed connection side.
+
+ * Authenticated Relay
+
+ Since the SOCKS is originally designed for firewall systems and it
+ has various authentication methods, the relayed connections can be
+ 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 Procedure
+
+ In all communication applications, it is a necessary to obtain
+ destination IP address information to start a communication. It is,
+ however, theoretically impossible for the heterogeneous
+ communications to obtain correct information, because an existing
+ IPv4 application can not deal with an IPv6 address. It prepares only
+ a 4-byte address space to store an IP address information, and it can
+ not store an IPv6 address information into there. This is a critical
+ problem caused by differences in address length.
+
+ In order to solve the problem, a feature called "DNS name resolving
+ delegation" is used in the SOCKS-based IPv6/IPv4 gateway mechanism.
+ The feature involves the delegating of DNS name resolving actions at
+ the source node (Client C) to 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
+ made without causing any problems. Therefore, it is not necessary to
+ modify the existing DNS mechanism at all.
+
+ The feature supports not only the case in which a destination logical
+ host name (FQDN) information is given but also the case in which a
+ destination literal (numerical) IP address is given. The latter case
+ is supported in almost the same way as the former case. Since the
+ literal IPv6 address expression includes colons (":"), it is
+ identified as an FQDN (not a literal IPv4 address) for the IPv4
+ application.
+
+ The SOCKS protocol specification [SOCKSv5] defines that IPv4 address,
+ IPv6 address, and DOMAINNAME (FQDN) information can be used in the
+ ATYP (address type) field of the SOCKS protocol format. In the "DNS
+ name resolving delegation" feature, the DOMAINNAME (FQDN) information
+ is used in the ATYP (address type) field. The FQDN information is
+ transferred from the Client C to the Gateway G to indicate the
+ Destination D.
+
+ In order to solve the formerly explained critical problem, an
+ appropriate "fake IP" address is introduced in the feature, and it is
+ used as a virtual destination IP address for a socksified
+ application. A mapping table is also introduced in the *Socks Lib*
+ (at the Client C) to manage mappings between "fake IP" and "FQDN". A
+ "fake IP" address is used as a key to look up the corresponding
+ "FQDN" information. The mapping table is local and independent of
+ 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 the
+ applications. Since DNS name resolving APIs are replaced by the
+ *Socks Lib*, the "DNS name resolving delegation" is executed
+ internally merely by calling the DNS name resolving APIs in ordinal
+ methods.
+
+ 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 heterogeneous
+ communications. The method of using FQDN information in the ATYP
+ field depends on the 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" and address mapping management related issues are
+ described as follows.
+
+ 1. An application on the source node (Client C) tries to get the
+ IP address information of the destination node (Destination D) by
+ calling the DNS name resolving function (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 APIs is not called here. The argued
+ "FQDN" information is merely registered into a mapping table in
+ *Socks Lib*, and a "fake IP" address is selected as information
+ that is replied 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 mapping
+ table as a pair with the "FQDN", it is replied to the application.
+
+ 3. The application receives the "fake IP" address, 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 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 real
+ socket function is not called. 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 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., for connect(), the
+ CONNECT command is used.)
+
+ 6. Finally, the real DNS name resolving API (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 APIs.
+
+ 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 APIs (e.g., connect()) to communicate
+ with the Destination D. The "socket" is used as an argument of the
+ APIs.
+
+ The problem with the feature is that failures of the DNS name
+ resolving process are detected incorrectly at the source node (Client
+ C). They are detected as connection-establishment failures.
+
+ (Restrictions on applicability of "fake IP" address, etc., are
+ described in Section 5.)
+
+ * Operations for Address Management (reservation, mapping etc.)
+
+ The SOCKS-based gateway mechanism does not require the reserving of a
+ wide global address space for the address mapping, and complex
+ address allocation and garbage-collection mechanisms are not
+ necessary.
+
+ Such address management operations are done at the *Socks Lib* by
+ using the fake IP address and the mapping table for the DNS name
+ resolving delegation. Since the mapping table is prepared in 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 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 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
+
+ In this figure, the source node (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 node and the final destination node. It is possible to have
+ more than two intermediate relay servers. To simplify the
+ explanation, a twice-relayed topology is shown here.
+
+ Since the multiple chained relay is more complex than one-time relay
+ and causes complexity, it is recommended that the multiple chained
+ relay communication should be used only when it is necessary for some
+ reason (e.g., usable protocols or topologies are limited by routers
+ etc.).
+
+
+
+
+
+Kitamura Informational [Page 7]
+
+RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
+
+
+5. Applicability statement
+
+ The SOCKS-based gateway mechanism requests socksification of
+ applications (install *Socks Lib*) to accomplish heterogeneous
+ communications. It is not necessary to modify (change source codes
+ and recompile them, etc.) the applications, because typical
+ socksification is done by changing the linking order of dynamic link
+ libraries (specifically, by linking the SOCKS dynamic link library
+ before the dynamic link libraries for normal socket and DNS name
+ resolving APIs).
+
+ The mechanism does not request modification of the DNS system,
+ because the DNS name resolving procedure at the Client C is delegated
+ to the dual stack node Gateway G.
+
+ 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, a suitable port
+ value can be provided, because IPv4 and IPv6 use the same size
+ port space and an appropriate port information is transferred by
+ the SOCKS protocol.
+
+ 2. Constraints of the SOCKS mechanism:
+
+ Since the current SOCKS system can not socksify all of the tricky
+ applications in which extraordinary manners 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 is used as a key value in the mapping table for
+ the "DNS name resolving delegation" feature. When the application
+ is finished and the mapping table disappears, the fake address
+ 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 address
+ information will merely become useless, because fake address
+
+
+
+Kitamura Informational [Page 8]
+
+RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
+
+
+ information is taken from a reserved special IP address space that
+ is never used in real communications (e.g., 0.0.0.x) and such a
+ information is useless for the normal communication applications.
+ Furthermore, such cases will be rare because most applications
+ usually record FQDN information (not fake IP address information)
+ to the bookmark, etc.
+
+5.1 Native SOCKS mechanism considerations
+
+ The characteristics of the SOCKS-based IPv6/IPv4 gateway mechanism
+ are inherited from those of the native SOCKS mechanism. Therefore,
+ consideration issues of the native SOCKS mechanism are discussed in
+ this section.
+
+ The SOCKSv5 protocol is composed of three commands (CONNECT, BIND and
+ 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 CONNECT
+ command mainly, because the CONNECT command is the main and most
+ frequently used command in the SOCKS mechanism. Since the CONNECT
+ command does not have clear week points, we can use it freely without
+ considerations.
+
+ The other (BIND and UDP ASSOCIATE) commands have the following weak
+ points. So, we have to consider these points when we use the BIND or
+ UDP ASSOCIATE commands in the mechanism.
+
+ The BIND command is basically designed to support reverse-channel
+ rendezvous of the FTP type applications. So, general usages of the
+ BIND command may cause problems.
+
+ The UDP ASSOCIATE command is basically designed for simple UDP
+ applications (e.g., archie). It is not general enough to support a
+ 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 Considerations
+
+ Since the SOCKS-based IPv6/IPv4 gateway mechanism is based on SOCKSv5
+ protocol, the security feature of the mechanism matches that of
+ SOCKSv5. It is described in the Security Considerations section of
+ the SOCKS Protocol Version 5 [SOCKSv5].
+
+ The mechanism is based on relaying two "terminated" connections at
+ the "application layer". The end-to-end security is maintained at
+ each of the relayed connections (i.e., between Client C and Gateway
+ G, and between Gateway G and Destination D). The mechanism does not
+ provide total end-to-end security relay between the original source
+ (Client C) and the final destination (Destination D).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kitamura Informational [Page 10]
+
+RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
+
+
+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-...
+
+References
+
+ [SOCKSv5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and
+ L. Jones, "SOCKS Protocol V5", RFC 1928, April 1996.
+
+ [TRANSMECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+ 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 by
+ the SOCKS-based IPv6/IPv4 Translator", in Proceedings of
+ INET99, July 1999.
+
+Author's Address
+
+ Hiroshi Kitamura
+ NEC Corporation
+ Development Laboratories
+ (Igarashi Building 4F) 11-5, Shibaura 2-Chome,
+ Minato-Ku, Tokyo 108-8557, JAPAN
+
+ Phone: +81 (3) 5476-1071
+ Fax: +81 (3) 5476-1005
+ EMail: kitamura@da.jp.nec.com
+
+
+
+
+
+
+
+
+
+Kitamura Informational [Page 11]
+
+RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kitamura Informational [Page 12]
+