RFC3089 日本語訳
3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. H. Kitamura. April 2001. (Format: TXT=25193 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Kitamura Request for Comments: 3089 NEC Corporation Category: Informational April 2001
コメントを求めるワーキンググループH.喜田村要求をネットワークでつないでください: 3089年のNECカテゴリ: 情報の2001年4月
A SOCKS-based IPv6/IPv4 Gateway Mechanism
ソックスベースのIPv6/IPv4ゲートウェイメカニズム
Status of this Memo
この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.
Copyright(C)インターネット協会(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.
このドキュメントはIPv6ノードとIPv4ノードとの滑らかな異種のコミュニケーションを可能にするSOCKSベースの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メカニズムを異種のコミュニケーションに適用して、2の「終えられた」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メカニズムによって提供されるのと同じ通信環境を提供します。 同じ外観を異種のコミュニケーションに提供します。 現在のコミュニケーションのどんな利器も機能性も犠牲にされません。
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.
SOCKSベースのIPv6/IPv4ゲートウェイメカニズムは「応用層」(SOCKSサーバ)で2の「終えられた」IPv4とIPv6接続をリレーするメカニズムに基づいています。 特性は応用層の接続リレーメカニズムのものと固有のSOCKSメカニズムのものから引き継がれます。
Kitamura Informational [Page 1] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[1ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
2. Basic SOCKS-based Gateway Mechanism
2. 基本的なソックスベースのゲートウェイメカニズム
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
クライアントCゲートウェイG目的地D+-----------+ (サーバ)|アプリケーション| +-->+===========+ +-------------+ +-----------+ 同じ+|*ソックスリブ*| | *ゲートウェイ*| |アプリケーション| API+-->+===========+ +=====---=====+ +-----------+ | ソケットDNS| | ソケットDNS| | ソケットDNS| +-----------+ +-------------+ +-----------+ | [IPv X]| |[IPvX]|(IPvY)| | (IPv Y) | +-----------+ +-------------+ +-----------+ |ネットワークI/F| | ネットワークI/F| |ネットワークI/F| +-----+-----+ +---+-----+---+ +-----+-----+ | | | | +============+ +------------+ socksified正常な接続接続(ctrl)+データデータ専用
Fig. 1 Basic SOCKS-based Gateway Mechanism
図1 基本的なソックスベースのゲートウェイメカニズム
In this figure, the Client C initiates the communication to the Destination D. Two new functional blocks are introduced and they compose the mechanism.
この図では、Client CはDestination D.にコミュニケーションを開始します。Two新しい機能ブロックは紹介されます、そして、それらはメカニズムを構成します。
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*.
1(*ソックスLib*)はクライアント側(クライアントC)に取り入れられます(この手順は「socksifying」と呼ばれます)。 *ソックスLib*は、応用層とソケットレイヤーの間に位置していて、API(例えば、getaddrinfo()gethostbyname()など)を決議しながら、アプリケーションのソケットAPIとDNS名を置き換えることができます。 マッピングテーブルが「委譲を決議するDNS名」特徴(以下で、説明される)のためにそこにあります。 それぞれのsocksifiedアプリケーションには、それ自身の*ソックス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.
もう片方(*ゲートウェイ*)がIPv6とIPv4デュアルスタックノード(ゲートウェイG)にインストールされます。 それはClient C(IPvX)とDestination D(IPvY)の間のどんなタイプのプロトコル組み合わせリレーも可能にする高められたSOCKSサーバです。 *ソックスLib*がリレーを呼び出すとき、1つの対応する*ゲートウェイ*プロセス(スレッド)が、リレー接続を預かるために親*ゲートウェイ*から量産されます。
The following four types of combinations of IPvX and IPvY are possible in the mechanism.
以下の4つのタイプのIPvXとIPvYの組み合わせはメカニズムで可能です。
Kitamura Informational [Page 2] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[2ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
type C ------ G ------ D
[IPvX] (IPvY)
A IPv4 IPv4 homogeneous (normal SOCKS)
B IPv4 IPv6 * heterogeneous *
C IPv6 IPv4 * heterogeneous *
D IPv6 IPv6 homogeneous
Cをタイプしてください。------ G------ D[IPvX](IPvY)均質の(正常なSOCKS)B IPv4 IPv6*異種の*C*異種の*D A IPv4 IPv4IPv6 IPv4IPv6 IPv6均質です。
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ゲートウェイメカニズムのための主要目標です。 彼らは異種のコミュニケーションを提供します。 それが均質のコミュニケーションであるので、SOCKSメカニズムの自然な拡大でタイプDをサポートすることができます。
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).
*ソックスLib*が*ゲートウェイ*でSOCKSプロトコル[SOCKSv5]を使用することによって交信するので、彼ら(Client CとゲートウェイG)の間の接続は、特別な接続であり、「socksified接続」と呼ばれます。 それはデータだけではなく、制御情報(例えば、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).
ゲートウェイGとDestination Dとの接続は普通の接続です。 それは変更されていません(socksifiedされます)。 Destination Dの上で作業するサーバ・アプリケーションはClient C.の存在に気付きません。Itは、接続の同輩ノードがゲートウェイGである(Client 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を決して超えていません、メカニズムが「応用層」での2つの「終えられた」接続をリレーするのに基づいているので。 リレーされたデータはアプリケーションのための簡単なデータ・ストリームです、そして、パケットサイズはそれぞれのリレー接続側で自然に調整されます。
* 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認証方法でリレーされた接続を認証できます。
Kitamura Informational [Page 3] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[3ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
3. DNS Name Resolving Procedure
3. 手順を決議するDNS名
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アドレス情報を得るのに必要なaです。 しかしながら、異種のコミュニケーションが正確な情報を得るのは、理論的に不可能です、既存のIPv4アプリケーションがIPv6アドレスに対処できないので。 それはIPアドレス情報を保存するために4バイトのアドレスのスペースだけを準備します、そして、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.
問題を解決するために、「委譲を決議するDNS名」と呼ばれる特徴はSOCKSベースのIPv6/IPv4ゲートウェイメカニズムで使用されます。 特徴はソースノード(クライアントC)でリレーサーバ(ゲートウェイG)に動作を決議するDNS名を代表として派遣することにかかわります。 したがって、リレーサーバが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]はそのIPv4アドレスを定義します、IPv6アドレス、そして、SOCKSプロトコル形式のATYP(アドレスタイプ)分野でDOMAINNAME(FQDN)情報を使用できます。 「委譲を決議するDNS名」特徴では、DOMAINNAME(FQDN)情報はATYP(アドレスタイプ)分野で使用されます。 Destination Dを示すためにClient CからゲートウェイGまでFQDN情報を移します。
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アドレスとして使用されます。 また、マッピングテーブルは、「にせのIP」と"FQDN"の間のマッピングを管理するために*ソックスLib*(Client Cの)で紹介されます。 「にせのIP」というアドレスは、対応する"FQDN"情報を調べるのにキーとして使用されます。 マッピングテーブルは、他のアプリケーションかそれらの*ソックスLib*sから地方であって独立しています。
Kitamura Informational [Page 4] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[4ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
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.
アプリケーションへの透明は特徴で維持されます。 特別なものは何も、アプリケーションをsocksifyingする以外に、それを実行するのに必要ではありません。 APIが*ソックスLib*に取り替えられると決議するDNS名以来、単にDNS名を序数のメソッドでAPIを決議すると呼ぶことによって、「委譲を決議するDNS名」は内部的に実行されます。
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.
FQDN情報がSOCKSコマンドのATYP(アドレスタイプ)分野で使用されるときだけ、「委譲を決議するDNS名」は優れています。 したがって、異種のコミュニケーションのためにそうするのは義務的です。 ATYP分野でFQDN情報を使用するメソッドはSOCKSプロトコルの構成設定と実装に依存します。 議論を簡素化するために、ここでFQDN情報がATYP分野で使用される場合だけについて議論します。
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. DNS名を機能を決議すると呼ぶことによって、ソースノード(クライアントC)におけるアプリケーションは目的地ノード(目的地D)に関するIPアドレス情報を得ようとします。(例えば、gethostbyname())。 このとき、情報という目的地Dの論理的なホスト名("FQDN")は呼ばれたAPIの議論としてアプリケーションの*ソックスリブ*に通過されます。
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. *ソックスLib*がAPIを決議しながらDNSが命名するそのようなものを取り替えたので、APIを決議する本当のDNS名はここに呼ばれません。 論争された"FQDN"情報は*ソックスリブ*でマッピングテーブルに単に登録されます、そして、アプリケーションに関して決してそうでない予約された特別なIPアドレス空間から返答される情報が本当のコミュニケーションで(例えば、0.0.0.x)を使用したので、「にせのIP」というアドレスは選択されます。 「にせのIP」というアドレスのアドレスファミリータイプはアプリケーションで呼ばれる要求に適しているに違いありません。 すなわち、それはClient Cの同じアドレスファミリーのものでなければなりません、Destination 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と呼びます。(例えば、コミュニケーションを始める())を接続してください。 「ソケット」はAPIの議論として使用されます。
Kitamura Informational [Page 5] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[5ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
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. *ソックス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に合わせられているソックスコマンドを使用することによって、リレーサーバ(ゲートウェイG)の*ゲートウェイ*に"FQDN"情報を移します。 (例えば、接続、()、使用される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())は*ゲートウェイ*に呼ばれます。(このとき、ソックスを通した情報が議定書の中で述べる容認された"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と呼びます。例えば、())を接続します。(Destination 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.
特徴に関する問題はプロセスを決議するDNS名の失敗がソースノード(クライアントC)に不当に検出されるということです。 それらはコネクション確立失敗として検出されます。
(Restrictions on applicability of "fake IP" address, etc., are described in Section 5.)
(「にせのIP」というアドレスの適用性における制限などはセクション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.
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.
*ソックスLib*でDNS名に委譲を決議しながらにせのIPアドレスとマッピングテーブルを使用することによって、そのようなアドレス管理操作をします。 マッピングテーブルが各アプリケーションで準備されるので、それは、他のアプリケーションから局所的に閉じられて独立しています。 したがって、テーブルを管理するのが簡単であり、広いグローバルアドレススペースを予約するのは必要ではありません。
Kitamura Informational [Page 6] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[6ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
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.
SOCKSベースのゲートウェイメカニズムには、複数のチェーニングされたリレーtopologiesをサポートする柔軟性があります。 様々な状態で複雑であったメカニズム、IPv4、およびIPv6と共にコミュニケーションtopologiesは優れています。
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
クライアントCゲートウェイG1ゲートウェイG2目的地D+-----------+ (サーバ1)(サーバ2)|アプリケーション| +===========+ +-------------+ +-------------+ +-----------+ |*ソックスリブ*| | *Gateway1*| | *Gateway2*| |アプリケーション| +===========+ +=====---=====+ +=====---=====+ +-----------+ | ソケットDNS| | ソケットDNS| | ソケットDNS| | ソケットDNS| +-----------+ +-------------+ +-------------+ +-----------+ | [IPv X]| |[IPvX]|(IPvY)| |(IPvY)|IPvZ| | IPv Z| +-----------+ +-------------+ +-------------+ +-----------+ |ネットワークI/F| | ネットワークI/F| | ネットワークI/F| |ネットワークI/F| +-----+-----+ +---+-----+---+ +---+-----+---+ +-----+-----+ | | | | | | +============+ +==========+ +------------+ socksified socksified正常な接続接続接続(ctrl)+データ(ctrl)+データデータ専用
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)とのコミュニケーションを開始します。 下部では、接続を3つの接続に取り替えます、そして、2つのリレーサーバ(ゲートウェイG1とG2)で彼らをリレーします。 *ゲートウェイ*は同じタイプの*ソックスLib*の関数を含んでいます。最初のリレーサーバ(ゲートウェイG1)で*Gateway1*で*ソックス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.
ソースノードと最終的な目的地ノードの間には、制限が全くリレー操作の数にありません。 2つ以上の中間的リレーサーバを持っているのは可能です。 説明を簡素化するために、二度リレーされたトポロジーはここに示されます。
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.).
複数のチェーニングされたリレーが1回のリレーより複雑であり、複雑さを引き起こすので、それがある理由で必要であるときにだけ(例えば使用可能なプロトコルかtopologiesがルータなどによって制限されます)、複数のチェーニングされたリレーコミュニケーションが使用されるのは、お勧めです。
Kitamura Informational [Page 7] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[7ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
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*をインストールする)のsocksificationに要求します。 アプリケーションを変更するのは(ソースコードを変えて、それらなどを再コンパイルします)必要ではありません、ダイナミックリンクライブラリ(特にダイナミックリンクライブラリの前に正常なソケットとDNS名のためにAPIを決議しながらSOCKSダイナミックリンクライブラリをリンクするのによる)のリンク注文を変えることによって典型的なsocksificationをするので。
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システムの変更を要求しません、Client Cで手順を決議するDNS名をデュアルスタックノードゲートウェイGへ代表として派遣するので。
Other than the socksification, the SOCKS-based gateway mechanism has the following three types of constraints.
socksificationを除いて、SOCKSベースのゲートウェイメカニズムには、以下の3つのタイプの規制があります。
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.
リターンのひとりが(例えば、getpeername()、getsockname()など)を評価するときIPアドレスを要求する機能はリターン値として正しい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システムが並はずれたマナーが接続を創造するのに使用される油断のならないアプリケーションのすべてをsocksifyすることができないので、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
それが永久に(例えば、ブックマークとして、記録される)記録されても、深刻な問題は起こらないでしょう。 記録されたにせのアドレス情報がにせであるので単に役に立たなくなる、アドレス
Kitamura Informational [Page 8] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[8ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
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)で決して使用されない予約された特別なIPアドレス空間から情報を取ります、そして、通常のコミュニケーションアプリケーションに、そのような情報は役に立ちません。 その上、ほとんどのアプリケーションが通常、ブックマークへのFQDN情報(IPアドレス情報を見せかけない)などを記録するので、そのような場合はまれになるでしょう。
5.1 Native SOCKS mechanism considerations
5.1 固有のSOCKSメカニズム問題
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プロトコルは3つのコマンド(CONNECT、BIND、およびUDP ASSOCIATE)で構成されます。 SOCKSのベースのIPv6/IPv4ゲートウェイメカニズムで3つのコマンドのすべてを適用できます。
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コマンドの用法を主に仮定するのに説明されます、CONNECTコマンドがSOCKSメカニズムのメインとほとんどの頻繁に使用するコマンドであるので。 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)コマンドには、以下の弱点があります。 それで、私たちは、私たちがBINDを使用するときのこれらのポイントかUDP ASSOCIATEがメカニズムでコマンドであると考えなければなりません。
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の両方を使用する多人数のクラスのアプリケーションをサポートするくらいには一般的ではありません。
Kitamura Informational [Page 9] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[9ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
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].
SOCKSベースのIPv6/IPv4ゲートウェイメカニズムがSOCKSv5プロトコルに基づいているので、メカニズムのセキュリティ機能はSOCKSv5のものに合っています。 それはSOCKSプロトコルバージョン5[SOCKSv5]のSecurity Considerations部で説明されます。
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).
メカニズムは「応用層」での2つの「終えられた」接続をリレーするのに基づいています。 終わりから終わりへのセキュリティはリレーされた接続各人(すなわち、Client CとゲートウェイGと、ゲートウェイGとDestination Dの間の)のときに維持されます。 メカニズムは一次資料(クライアントC)と最終的な目的地(目的地D)の間に終わりから終わりへのセキュリティ総リレーを提供しません。
Kitamura Informational [Page 10] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[10ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
Appendix A. Implementations
付録A.実装
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ゲートウェイメカニズムの2つの独立している実装があります。 それらの両方が公開されています。
One is NEC's implementation. Its source codes are available at the following URL.
1つは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.
実装はそうですか?もう片方が富士通Labです。(それは、"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]のヒル、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはV5"について議定書の中で述べます、RFC1928、1996年4月。」
[TRANSMECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[TRANSMECH] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC2893、2000年8月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[INET99] H. Kitamura, "Entering the IPv6 communication world by
the SOCKS-based IPv6/IPv4 Translator", in Proceedings of
INET99, July 1999.
INET99のProceedingsの1999年7月に「SOCKSベースのIPv6/IPv4 TranslatorはIPv6コミュニケーション世界に入る」[INET99]H.喜田村。
Author's Address
作者のアドレス
Hiroshi Kitamura NEC Corporation Development Laboratories (Igarashi Building 4F) 11-5, Shibaura 2-Chome, Minato-Ku, Tokyo 108-8557, JAPAN
Hiroshi喜田村NEC開発研究所(4Fを建てる五十嵐)11-5、2丁目のShibaura港区、東京108-8557(日本)
Phone: +81 (3) 5476-1071 Fax: +81 (3) 5476-1005 EMail: kitamura@da.jp.nec.com
以下に電話をしてください。 +81 (3) 5476-1071Fax: +81 (3) 5476-1005 メールしてください: kitamura@da.jp.nec.com
Kitamura Informational [Page 11] RFC 3089 SOCKS-based IPv6/IPv4 Gateway Mechanism April 2001
ソックスベースの[11ページ]RFC3089IPv6/IPv4ゲートウェイメカニズム2001年4月の情報の喜田村
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Kitamura Informational [Page 12]
喜田村Informationalです。[12ページ]
一覧
スポンサーリンク
