この文書はRFC3089の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
それはＳＯＣＫＳプロトコル[SOCKSv5]に基づいています。異種間通信にＳＯ
ＣＫＳメカニズムを用いて、「アプリケーションレイヤ」（ＳＯＣＫＳサー
バー）で２つの「終端した」ＩＰｖ４とＩＰｖ６接続を中継することによっ
て、ＳＯＣＫＳを基にしたＩＰｖ６／ＩＰｖ４ゲートウェイ機構は達成され
ています。
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
1. はじめに
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.
ＳＯＣＫＳを基にしたＩＰｖ６／ＩＰｖ４ゲートウェイ機構は「アプリケー
ションレイヤ」での２つの「終端した」ＩＰｖ４とＩＰｖ６接続を中継す
るメカニズム（ＳＯＣＫＳサーバー）に基づいています；その特徴はアプ
リケーションレイヤでの接続リレーメカニズムとネイティブＳＯＣＫＳ機
構から継承されます。
2. Basic SOCKS-based Gateway Mechanism
2. 基本的なＳＯＣＫＳを基にしたゲートウェイメカニズム
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|
|ソケットDNS| | ソケットDNS | |ソケット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*.
クライアント側（クライアントＣ）に１つの*Socks Lib*が導入されます（こ
の手順は"socksifying"と呼ばれます）。*Socks Lib*はアプリケーションレ
イヤとソケットレイヤの間に位置し、アプリケーションソケットＡＰＩとＤ
ＮＳ名前解決ＡＰＩを置き換えます（例えば、gethostbyname()、
getaddrinfo()など）。その中に「ＤＮＳ名解決委任」機能のためのマッピン
グテーブルがあります（下で記述）。各ソケット化アプリケーションがそれ
自身の*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.
もう１つ、*Gateway*はＩＰｖ６とＩＰｖ４デュアルスタックノード（ゲート
ウェイＧ）上に設置されます。これはクライアントＣ（IPvX）と宛先Ｄ間の
どんな種類のプロトコルの組合せのリレーも可能にする拡張ＳＯＣＫＳサー
バー（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 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).
*Socks Lib*がＳＯＣＫＳプロトコル[SOCKSv5]を使って*Gateway*と通信する
ので、それら（クライアントＣとゲートウェイＧ）の間の接続は特別な接続
で、「ソケット化接続」と呼ばれます。これはデータだけではなく制御情報
（例えば、宛先Ｄの場所情報）も転送できます。
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.
メカニズムを達成するために新しいプロトコルがＳＯＣＫＳプロトコル
[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.
ＩＰｖ６ヘッダ長さがＩＰｖ４ヘッダと異なっているので、異種間通信で
パケットサイズ調整があると思うことが必要です。もしこれを考慮に入れ
られないなら、パケットサイズはネットワークＭＴＵを超えるかもしれま
せん。
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.
ＳＯＣＫＳが元来ファイアウォールシステムのために設計され、ファイア
ウォールが種々な認証方法を持っているので、中継接続はネイティブのＳ
ＯＣＫＳ認証方法で認証できます。
3. DNS Name Resolving Procedure
3. ＤＮＳ名解決処理
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.
ＳＯＣＫＳプロトコル仕様書[SOCKSv5]はＩＰｖ４アドレスとＩＰｖ６アドレ
スとドメイン名（ＦＱＤＮ）情報を定義し、ＳＯＣＫＳプロトコルフォーマッ
トのATYP（アドレスタイプ）フィールドで使うことができます。「ＤＮＳ名
解決委任」機能で、ドメイン名（ＦＤＱＮ）情報はATYP（アドレスタイプ）
フィールドで使われます。ＦＱＤＮ情報は宛先Ｄを示すためにクライアント
ＣからゲートウェイＧまで転送されます。
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.
前に説明した重大な問題を解くために、適切な「偽ＩＰ」アドレスをこの機
能で導入し、これは仮想の宛先ＩＰアドレスとしてソケット化アプリケーショ
ンのために使われます。「偽ＩＰ」と「ＦＱＤＮ」の対応を管理するために
*Socks Lib*（クライアントＣ）でマップテーブルを導入します。「偽ＩＰ」
アドレスが対応する「ＦＱＤＮ」情報を調べる鍵として用いられます。マッ
プテーブルはローカルで他のアプリケーションやその*Socks Lib*と独立です。
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.
アプリケーションへの透過性は機能で持続されます。アプリケーションをソ
ケット化する以外、特別な事を実行するように要求されません。ＤＮＳ名変
換ＡＰＩが*Socks Lib*で置き換えられるので、「ＤＮＳ名解決委任」は単に
内部的に元々のＤＮＳ名解決ＡＰＩを呼出す事で実行されます。
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.
「ＤＮＳ名解決委任」はＦＱＤＮ情報がＳＯＣＫＳコマンドのATYP（アドレ
スタイプ）フィールドで使われる時だけ実行されています。それ故、異種間
接続でこうすることは必須です。ATYPフィールドでＦＱＤＮ情報を使う方法
は設定とＳＯＣＫＳプロトコルの実装に頼ります。論議を単純化するため、
ＦＱＤＮ情報がATYP フィールドで使われる場合だけがここで論じられます。
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.
1. ソースノード（クライアントＣ）上のアプリケーションがＤＮＳ名解決機
能を呼出して宛先ノード（宛先Ｄ）のＩＰアドレス情報を得ようとします
（例えば、gethostbyname()）。この時、宛先Ｄの論理ホスト名（「ＦＱ
ＤＮ」）情報ががＡＰＩの引数としてアプリケーションの*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*がＤＮＳ名解決ＡＰＩを置き換えるので、本当のＤＮＳ名解
決ＡＰＩはここで呼び出されません。引数の「ＦＱＤＮ」情報はただ
*Socks Lib*のマッピング表に登録され、アプリケーションに返すために
「偽ＩＰ」アドレスが特別なＩＰアドレス空間から選択されます、この
ＩＰアドレスは実際の通信で使われることのないものです（例えば
0.0.0.x）。「偽ＩＰ」アドレスのアドレスファミリータイプはアプリケー
ションの呼出しに適合しているに違いありません。すなわち、宛先Ｄの
アドレスファミリーと異なっていても、クライアントＣと同じアドレス
ファミリーに属さなくてはなりません。選択された「偽ＩＰ」アドレス
がマッピング表の中で「ＦＱＤＮ」とペアで登録され、それがアプリケー
ションに返されます。
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. アプリケーションは「偽ＩＰ」アドレスを受信し、「ソケット」を準備し
ます。「偽ＩＰ」アドレス情報は「ソケット」の要素として用いられます。
アプリケーションはソケットＡＰＩ（例えば、connect()）を呼出し、接
続を始めます。「ソケット」はＡＰＩの引数として用いられます。
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*がこのようなソケットＡＰＩを置き換えたので、真のソケッ
ト機能は呼び出されません。引数ソケットのＩＰアドレス情報はチェック
されます。もしアドレスが偽アドレスのための特別なアドレス空間に属す
るなら、「偽ＩＰ」アドレスと対応する登録された「ＦＱＤＮ」情報がマッ
ピング表から得られます。
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. 「ＦＱＤＮ」情報はリレーサーバ（ゲートウェイＧ）の*Gateway*に、呼
び出したＡＰＩに対応するＳＯＣＫＳコマンドを使って送られます（例え
ば、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. 最終的に、本当のＤＮＳ名解決ＡＰＩ（例えば、getaddrinfo() ）は
*Gateway*で呼び出されます。今、ＳＯＣＫＳプロトコルによって得た
「ＦＱＤＮ」情報が呼出すＡＰＩの引数に用いられます。
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. *Gateway*はＤＮＳサーバーから「本当のＩＰ」アドレスを得て、「ソ
ケット」を作ります。「本当のＩＰ」アドレス情報は「ソケット」の要
素として用いられます。
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. *Gateway*は宛先Ｄと通信するためソケットＡＰＩ（例えば、connect()）
を呼出します。「ソケット」はＡＰＩの引数として用いられます。
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.
このようなアドレス管理オペレーションはＤＮＳ名解決委任のための偽ＩＰ
アドレスマッピング表を使うことによって*Socks Lib*で行われます。マッ
ピング表が各アプリケーションで準備されるので、他のアプリケーションと
区別され、他と独立です。それ故に、テーブル管理は容易で、広いグローバ
ルなアドレス空間を予約する必要はありません。
4. Multiple Chained Relay Mechanism (Advanced usage)
4. 多数連鎖リレーメカニズム（拡張使用法）
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|
|ライブラリ | |ゲートウェイ1| |ゲートウェイ2| | アプリ |
+===========+ +=====---=====+ +=====---=====+ +-----------+
| Socket DNS| | Socket DNS | | Socket DNS | | Socket DNS|
|ソケットDNS| | ソケットDNS | | ソケットDNS | |ソケット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.
この図で、ソースノード（クライアントＣ）は宛先（宛先Ｄ）と通信を始め
ます。下で接続は３つの接続で置き換えられ、２つのリレーサーバー（ゲー
トウェイG１とG２）で中継されます。*Gateway*は*Socks Lib*の機能と同じ
種類の機能を含みます。最初のリレーサーバー（ゲートウェイＧ１）上の
*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.).
多数連鎖リレーが１段リレーより複雑で、複雑になるため多数連鎖リレー通
信が、何らかの理由で必要な時だけ使われることが勧められます（例えば、
利用したプロトコルかトポロジーがルータに制限される場合）。
5. Applicability statement
5. 適用性声明
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 Lib*のインストール）を要請しま
す。典型的なソケット化がダイナミックリンクのリンク順序を変えることで
行えるので（特に、ソケットとＤＮＳ名解決ＡＰＩの標準ダイナミックライ
ブラリより前にＳＯＣＫＳダイナミックリンク・ライブラリをリンクするこ
とで）、アプリケーションの変更（ソースコードの変更と再コンパイルなど）
が必要ありません。
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:
1. 不可欠な制約：
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.
ＩＰアドレスを返り値として要求する関数（例えば、getpeername()と
getsockname()など）が正しいＩＰアドレスを供給できません。しかしな
がら、ＩＰｖ４とＩＰｖ６は同じサイズのポート空間を使い、適切なポー
ト情報がＳＯＣＫＳプロトコルによって転送されすので、適当なポート
値は供給できます。
2. Constraints of the SOCKS mechanism:
2. ＳＯＣＫＳメカニズムの制約：
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:
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.
偽アドレスはアプリケーションで一時的な値と扱われなくてはなりません。
これは「ＤＮＳ名解決委任」機能のマッピング表のキー値として用いられ
ます。アプリケーションが終了し、マッピング表が消える時、偽アドレス
情報も開放されなくてはなりません。
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.
たとえそれが永久に記録されるとしても（例えば、ブックマークとして記
録される）、問題が起こらないことは重要です。偽アドレス情報が本物の
通信で決して使われない予約の特別なＩＰアドレス空間からとられ（例え
ば、0.0.0.x）、この情報が標準通信アプリケーションの役に立たないた
め、記録された偽アドレス情報はただ無効になるでしょう。さらに、たい
ていのアプリケーションが通常ブックマークなどに（偽ＩＰアドレス情報
ではなく）ＦＱＤＮ情報を記録するから、このような場合は稀でしょう。
5.1 Native SOCKS mechanism considerations
5.1 ネイティブのＳＯＣＫＳメカニズムの考察
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.
SOCKSv5プロトコルは３つのコマンド（接続、結びつけ、ＵＤＰ連携）で構成
されています。３つのコマンドのすべてはＳＯＣＫＳベースのＩＰｖ６／Ｉ
Ｐｖ４ゲートウェイメカニズムで適用されます。
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.
ＵＤＰ連携コマンドは基本的に単純なＵＤＰアプリケーションのために設計
されます（例えば、archie）。これはＴＣＰとＵＤＰの両方を使うアプリケー
ションの大きいクラスをサポートするのに十分一般的ではありません。
6. Security Considerations
6. セキュリティの考察。
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].
ＳＯＣＫＳを基にしたＩＰｖ６／ＩＰｖ４ゲートウェイ機構がSOCKSv5プロト
コルに基づいているので、メカニズムのセキュリティの特徴はSOCKSv5と一致
します。それはＳＯＣＫＳプロトコルバージョン５［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).
このメカニズムは「アプリケーション層」で２つの「終端」接続を中継する
ことを基本にします。エンドエンドセキュリティは各リレー接続で維持され
ます（すなわち、クライアントＣとゲートウェーＧ間と、ゲートウェイＧと
宛先Ｄ間）。このメカニズムは本来のソース（クライアントＣ）と最終宛先
（宛先Ｄ）の間の完全なエンドエンドセキュリティを供給しません。
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.
他は富士通研究所の実装で、それは"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.
[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
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。