Network Working Group H. Kitamura
Request for Comments: 3089 NEC Corporation
Category: Informational April 2001
Network Working Group H. Kitamura
Request for Comments: 3089 NEC Corporation
Category: Informational April 2001
A SOCKS-based IPv6/IPv4 Gateway Mechanism
一种基于SOCKS的IPv6/IPv4网关机制
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.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes.
本文档描述了一种基于SOCKS的IPv6/IPv4网关机制，该机制支持IPv6节点和IPv4节点之间的平滑异构通信。
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.
它基于SOCKS协议[SOCKSv5]。通过将SOCKS机制应用于异构通信，并在“应用层”（SOCKS服务器）中继两个“终止的”IPv4和IPv6连接，实现了基于SOCKS的IPv6/IPv4网关机制。
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.
由于它是在不引入新协议的情况下实现的，因此它提供了与SOCKS机制相同的通信环境。异构通信也提供了相同的外观。没有牺牲当前通信的便利性或功能。
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.
基于SOCKS的IPv6/IPv4网关机制基于在“应用层”（SOCKS服务器）中继两个“终止”IPv4和IPv6连接的机制；它的特性继承了应用层的连接中继机制和本机SOCKS机制的特性。
Figure 1 shows the basic SOCKS-based gateway mechanism.
图1显示了基本的基于SOCKS的网关机制。
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
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
图1基于SOCKS的基本网关机制
In this figure, the Client C initiates the communication to the Destination D. Two new functional blocks are introduced and they compose the mechanism.
在该图中，客户端C发起与目标D的通信。引入了两个新的功能块，它们构成了该机制。
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*.
其中一个，*Socks-Lib*被引入客户端（客户端C）（此过程称为“socksifying”）。*Socks Lib*位于应用程序层和套接字层之间，可以替换应用程序的套接字API和DNS名称解析API（例如gethostbyname（）、getaddrinfo（）等）。其中有一个“DNS名称解析委派”功能的映射表（如下所述）。每个socksified应用程序都有自己的*Socks库*。
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.
另一个，*网关*，安装在IPv6和IPv4双栈节点（网关G）上。它是一个增强的SOCKS服务器，支持客户端C（IPvX）和目标D（IPvY）之间的任何类型的协议组合中继。当*Socks Lib*调用一个中继时，一个对应的*Gateway*进程（线程）将从父*Gateway*生成，以负责中继连接。
The following four types of combinations of IPvX and IPvY are possible in the mechanism.
以下四种类型的IPvX和IPvY组合在机构中是可能的。
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 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.
类型A由正常SOCKS机制支持。类型B和C是基于SOCKS的IPv6/IPv4网关机制的主要目标。它们提供异构通信。类型D可以由SOCKS机制的自然扩展来支持，因为它是一种同构通信。
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).
由于*Socks Lib*通过Socks协议[SOCKSv5]与*Gateway*通信，因此它们之间的连接（客户端C和网关G）是一种特殊连接，称为“socksified连接”。它不仅可以传输数据，还可以传输控制信息（例如，目的地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).
网关G和目的地D之间的连接是正常连接。它没有被修改（镶嵌）。在目标D上运行的服务器应用程序没有注意到客户端C的存在。它识别出连接的对等节点是网关G（而不是客户端C）。
No new protocols are introduced to the SOCKS protocol [SOCKSv5] to accomplish the mechanism.
SOCKS协议[SOCKSv5]没有引入新的协议来实现该机制。
* 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.
由于IPv6报头的长度不同于IPv4报头的长度，因此有必要考虑异构通信中的数据包大小调整。如果不考虑这一点，则分组大小可能超过网络的MTU。
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.
在基于SOCKS的IPv6/IPv4网关机制中，它从未超过MTU，因为该机制基于在“应用层”中继两个“终止”连接。中继数据是应用程序的简单数据流，并且在每个中继连接侧自然地调整分组大小。
* 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.
由于SOCKS最初是为防火墙系统设计的，并且具有各种身份验证方法，因此中继连接可以通过本机SOCKS身份验证方法进行身份验证。
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.
在所有通信应用中，必须获取目的地IP地址信息才能开始通信。然而，从理论上讲，异构通信不可能获得正确的信息，因为现有的IPv4应用程序无法处理IPv6地址。它只准备了一个4字节的地址空间来存储IP地址信息，不能在其中存储IPv6地址信息。这是由地址长度的差异引起的一个关键问题。
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.
为了解决这个问题，在基于SOCKS的IPv6/IPv4网关机制中使用了一种称为“DNS名称解析委派”的功能。该功能涉及将源节点（客户端C）上的DNS名称解析操作委托给中继服务器（网关G）。由于中继服务器是IPv4和IPv6双堆栈节点，因此可以对任何地址族类型的目的地进行DNS名称解析查询，而不会导致任何问题。因此，根本不需要修改现有的DNS机制。
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.
该功能不仅支持给定目标逻辑主机名（FQDN）信息的情况，还支持给定目标文字（数字）IP地址的情况。后一种情况的支持方式与前一种情况几乎相同。由于文字IPv6地址表达式包含冒号（：），因此它被标识为IPv4应用程序的FQDN（不是文字IPv4地址）。
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.
SOCKS协议规范[SOCKSv5]定义可以在SOCKS协议格式的ATYP（地址类型）字段中使用IPv4地址、IPv6地址和域名（FQDN）信息。在“DNS名称解析委派”功能中，在ATYP（地址类型）字段中使用域名（FQDN）信息。FQDN信息从客户端C传输到网关G，以指示目的地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.
为了解决之前解释的关键问题，在功能中引入了一个适当的“假IP”地址，并将其用作socksified应用程序的虚拟目标IP地址。*Socks Lib*（位于客户端C）中还引入了一个映射表来管理“假IP”和“FQDN”之间的映射。“假IP”地址用作密钥，用于查找相应的“FQDN”信息。映射表是本地的，独立于其他应用程序或它们的*Socks Lib*s。
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.
该特性保持了对应用程序的透明性。除了对应用程序进行socksify之外，执行它不需要任何特殊的操作。由于DNS名称解析API替换为*Socks Lib*，因此“DNS名称解析委派”仅通过依次调用DNS名称解析API在内部执行。
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.
只有在SOCKS命令的ATYP（地址类型）字段中使用FQDN信息时，才能完成“DNS名称解析委派”。因此，对于异构通信，必须这样做。在ATYP字段中使用FQDN信息的方法取决于SOCKS协议的配置设置和实现。为了简化讨论，这里只讨论在ATYP字段中使用FQDN信息的情况。
The detailed internal procedure of the "DNS name resolving delegation" and address mapping management related issues are described as follows.
“DNS名称解析委托”和地址映射管理相关问题的详细内部过程描述如下。
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.
1. 源节点（客户端C）上的应用程序通过调用DNS名称解析函数（例如gethostbyname（））尝试获取目标节点（目标D）的IP地址信息。此时，目标D的逻辑主机名（“FQDN”）信息作为被调用API的参数传递给应用程序的*Socks Lib*。
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.
2. 由于*Socks Lib*已取代此类DNS名称解析API，因此此处不调用真正的DNS名称解析API。争论的“FQDN”信息仅注册到*Socks Lib*中的映射表中，并且选择“假IP”地址作为信息，从保留的专用IP地址空间（在实际通信中从未使用过）回复到应用程序（例如，0.0.0.x）。“假IP”地址的地址族类型必须适合应用程序调用的请求。即，它必须属于客户机C的相同地址族，即使目的地D的地址族不同于它。选择的“假IP”地址与“FQDN”成对注册到映射表中后，会回复到应用程序。
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.
3. 应用程序接收“假IP”地址，并准备一个“套接字”。“假IP”地址信息用作“套接字”的一个元素。应用程序调用套接字API（例如connect（））来启动通信。“套接字”用作API的参数。
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.
4. 由于*Socks Lib*已经取代了此类套接字API，因此不会调用真正的套接字函数。已检查该套接字的IP地址信息。如果地址属于假地址的特殊地址空间，则从映射表中获取“假IP”地址的匹配注册“FQDN”信息。
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.)
5. 通过使用与被调用套接字API匹配的SOCKS命令，将“FQDN”信息传输到中继服务器（网关G）上的*网关*。（例如，对于connect（），使用connect命令。）
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.
6. 最后，在*网关*上调用真正的DNS名称解析API（例如getaddrinfo（））。此时，通过SOCKS协议接收的“FQDN”信息被用作被调用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".
7. *网关*从DNS服务器获取“真实IP”地址，并创建“套接字”。“真实IP”地址信息用作“套接字”的一个元素。
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.
8. *网关*调用套接字API（例如connect（））与目标D通信。“套接字”用作API的参数。
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.
该功能的问题在于，在源节点（客户端C）上错误地检测到DNS名称解析过程的故障。它们被检测为连接建立失败。
(Restrictions on applicability of "fake IP" address, etc., are described in Section 5.)
（第5节描述了对“假IP”地址等适用性的限制。）
* 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.
基于SOCKS的网关机制不需要为地址映射保留广泛的全局地址空间，并且不需要复杂的地址分配和垃圾收集机制。
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.
这种地址管理操作是在*Socks Lib*上通过使用假IP地址和DNS名称解析委派的映射表来完成的。由于映射表是在每个应用程序中准备的，因此它是局部封闭的，独立于其他应用程序。因此，很容易管理表，并且不需要保留很宽的全局地址空间。
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.
基于SOCKS的网关机制具有支持多链中继拓扑的灵活性。利用该机制，实现了IPv4和IPv6混合的多种通信拓扑。
Figure 2 shows the structure of the multiple chained relay mechanism.
图2显示了多链中继机制的结构。
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
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
图2多链中继机构
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.
在该图中，源节点（客户端C）发起与目的地（目的地D）的通信。在下面，连接被替换为三个连接，它们在两个中继服务器（网关G1和G2）上中继。*网关*包含与*Socks Lib*相同类型的函数。通过在第一个中继服务器（网关G1）的*Gateway1*上启用*Socks Lib*功能，实现了多链中继拓扑。
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.).
由于多链中继比一次性中继更复杂，并且会导致复杂性，因此建议仅当出于某种原因（例如，可用协议或拓扑受到路由器等的限制）需要时才使用多链中继通信。
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).
基于SOCKS的网关机制请求应用程序的socksification（安装*SOCKS Lib*），以完成异构通信。无需修改（更改源代码并重新编译它们等）应用程序，因为典型的socksification是通过更改动态链接库的链接顺序来完成的（具体而言，通过在正常套接字和DNS名称解析API的动态链接库之前链接SOCKS动态链接库）。
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.
该机制不请求修改DNS系统，因为客户端C处的DNS名称解析过程被委托给双堆栈节点网关G。
Other than the socksification, the SOCKS-based gateway mechanism has the following three types of constraints.
除了socksification之外，基于SOCKS的网关机制具有以下三种类型的约束。
1. Essential constraints:
1. 基本限制：
Constraints are caused by the address length difference between IPv4 and IPv6.
限制是由IPv4和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.
请求IP地址作为返回值之一的函数（例如getpeername（）和getsockname（）等）无法提供正确的IP地址作为返回值。但是，可以提供适当的端口值，因为IPv4和IPv6使用相同大小的端口空间，并且通过SOCKS协议传输适当的端口信息。
2. Constraints of the SOCKS mechanism:
2. SOCKS机制的约束条件：
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.
由于当前的SOCKS系统无法将所有使用特殊方式创建连接的棘手应用程序都SOCKS化，因此基于SOCKS的网关机制无法应用于这些应用程序。
3. Constraints to deal with the fake address:
3. 处理假地址的限制条件：
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.
假地址必须在应用程序中作为临时值处理。它用作“DNS名称解析委派”功能映射表中的键值。当应用程序完成且映射表消失时，还必须释放假地址信息。
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
即使是永久记录（例如，记录为书签），也不会出现严重问题。记录的假地址信息只会变得无用，因为假地址
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.
信息取自一个保留的特殊IP地址空间，该空间从未在实际通信中使用过（例如，0.0.0.x），这样的信息对于正常通信应用是无用的。此外，这种情况很少见，因为大多数应用程序通常会将FQDN信息（而不是伪造的IP地址信息）记录到书签中，等等。
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.
基于SOCKS的IPv6/IPv4网关机制的特性继承自本机SOCKS机制的特性。因此，本节将讨论本机SOCKS机制的考虑问题。
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.
SOCKSv5协议由三个命令（CONNECT、BIND和UDP ASSOCIATE）组成。这三个命令都可以应用于基于SOCKS的IPv6/IPv4网关机制。
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.
由于CONNECT命令是SOCKS机制中最主要和最常用的命令，因此本文主要假设CONNECT命令的用法。由于CONNECT命令没有明确的周点，因此我们可以自由使用它而不必考虑。
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.
其他（BIND和UDP ASSOCIATE）命令有以下弱点。因此，当我们在机制中使用BIN或UDP关联命令时，我们必须考虑这些点。
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.
BIND命令基本上是为支持FTP类型应用程序的反向通道会合而设计的。因此，BIND命令的一般用法可能会导致问题。
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.
UDP ASSOCIATE命令基本上是为简单的UDP应用程序（例如，archie）设计的。它不够通用，无法支持同时使用TCP和UDP的大型应用程序。
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].
由于基于SOCKS的IPv6/IPv4网关机制基于SOCKSv5协议，因此该机制的安全特性与SOCKSv5相匹配。SOCKS协议版本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).
该机制基于在“应用层”中继两个“终止”连接。在每个中继连接处（即，在客户端C和网关G之间，以及在网关G和目的地D之间）维护端到端安全性。该机制不提供原始源（客户端C）和最终目的地（目的地D）之间的总端到端安全中继。
Currently, there are two independent implementations of the SOCKS-based IPv6/IPv4 gateway mechanism. Both of them are open to the public.
目前，有两种基于SOCKS的IPv6/IPv4网关机制的独立实现。它们都对公众开放。
One is NEC's implementation. Its source codes are available at the following URL.
一是NEC的实施。其源代码可从以下URL获得。
http://www.socks.nec.com/
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.
另一个是富士通实验室的实现，称为“SOCKS64”。其源代码可从以下URL获得。
ftp://ftp.kame.net/pub/kame/misc/socks64-...
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.
[SOCKSv5]Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.和L.Jones，“袜子协议V5”，RFC 19281996年4月。
[TRANSMECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[TRANSMECH]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 2893，2000年8月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[INET99] H. Kitamura, "Entering the IPv6 communication world by the SOCKS-based IPv6/IPv4 Translator", in Proceedings of INET99, July 1999.
[INET99]H.Kitamura，“通过基于SOCKS的IPv6/IPv4转换器进入IPv6通信世界”，摘自INET99会议录，1999年7月。
Author's Address
作者地址
Hiroshi Kitamura NEC Corporation Development Laboratories (Igarashi Building 4F) 11-5, Shibaura 2-Chome, Minato-Ku, Tokyo 108-8557, JAPAN
北村弘NEC公司开发实验室（井垣祯大厦4F）11-5，Shibaura 2-Chome，Minato Ku，东京108-8557
Phone: +81 (3) 5476-1071
Fax: +81 (3) 5476-1005
EMail: kitamura@da.jp.nec.com
Phone: +81 (3) 5476-1071
Fax: +81 (3) 5476-1005
EMail: kitamura@da.jp.nec.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。