原文：ftp://ftp.rfc-editor.org/in-notes/rfc1928.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況とについては "Internet Official Protocol Standards" (STD 1)の最新版を参照してほしい。この文書の配布に制限はない。
This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. The key contributors are: Marcus Leech: Bell-Northern Research, David Koblas: Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt Ganis: International Business Machines. この文書は SOCKS の以前のバージョン(バージョン 4 [1])の改訂版を記述する。この新しいプロトコルは活発な議論とプロトタイプ実装とから生まれたものである。主な貢献者を以下に記す： Marcus Leech: Bell-Northern Research, David Koblas: Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt Ganis: International Business Machines。
The use of network firewalls, systems that effectively isolate an organizations internal network structure from an exterior network, such as the INTERNET is becoming increasingly popular. These firewall systems typically act as application-layer gateways between networks, usually offering controlled TELNET, FTP, and SMTP access. With the emergence of more sophisticated application layer protocols designed to facilitate global information discovery, there exists a need to provide a general framework for these protocols to transparently and securely traverse a firewall. インターネットなどの外部ネットワークから組織内のネットワークを効率的に分離させるシステムであるネットワークファイアウォールは、近年ますます一般的になっている。このようなファイアウォールシステムは一般にネットワーク間のアプリケーションゲートウェイとして動作し、通常は TELNET や FTP、SMTP による管理されたアクセスを提供する。グローバルな情報検索を促進するために設計された、より複雑なアプリケーションレイヤプロトコルの出現にともない、それらのプロトコルが透過的かつ安全にファイアウォールを通過するための一般的な枠組みを提供する必要性が生まれた。
There exists, also, a need for strong authentication of such traversal in as fine-grained a manner as is practical. This requirement stems from the realization that client-server relationships emerge between the networks of various organizations, and that such relationships need to be controlled and often strongly authenticated. またこのような通過に対し、実用に耐えうるほどきめ細かい方法による強力な認証の必要性も存在する。この要求事項は、さまざまな組織同士のネットワーク間にもクライアント・サーバー関係が出現し、そのような関係は制御され、たいてい厳しく認証される必要があるという現実問題から生まれた。
The protocol described here is designed to provide a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall. The protocol is conceptually a "shim-layer" between the application layer and the transport layer, and as such does not provide network- layer gateway services, such as forwarding of ICMP messages. ここで説明されているプロトコルは、クライアント・サーバー型アプリケーションが TCP と UDP とにおいて、便利にかつ安全にネットワークファイアウォールのサービスを使用するための枠組みを提供するように設計されている。概念的には、このプロトコルはアプリケーション層とトランスポート層との間の "くさび(shim-layer)" であり、例えば ICMP メッセージの転送のような、ネットワーク層のゲートウェイサービスは提供しない。
There currently exists a protocol, SOCKS Version 4, that provides for unsecured firewall traversal for TCP-based client-server applications, including TELNET, FTP and the popular information- discovery protocols such as HTTP, WAIS and GOPHER. 現在、SOCKS バージョン 4 が存在し、TCP ベースのクライアント・サーバー型アプリケーション(TELNET や FTP、また HTTP・WAIS・GOPHER などの良く知られている情報検索プロトコルが含まれる)のための、安全でないファイアウォールの通過を提供している。
This new protocol extends the SOCKS Version 4 model to include UDP, and extends the framework to include provisions for generalized strong authentication schemes, and extends the addressing scheme to encompass domain-name and V6 IP addresses. この新しいプロトコルは、UDP を含むために SOCKS バージョン 4 のモデルを拡張し、汎用的で強力な認証方法を提供するためにそのフレームワークを拡張し、ドメイン名と V6 IP アドレスに対応するためにそのアドレス指定方法を拡張する。
The implementation of the SOCKS protocol typically involves the recompilation or relinking of TCP-based client applications to use the appropriate encapsulation routines in the SOCKS library. 一般に SOCKS プロトコルの実装が SOCKS ライブラリ内の適切なカプセル化ルーチンを使用するためには、TCP ベースのクライアントアプリケーションの再コンパイルまたは再リンクを必要とする。
Unless otherwise noted, the decimal numbers appearing in packet- format diagrams represent the length of the corresponding field, in octets. Where a given octet must take on a specific value, the syntax X'hh' is used to denote the value of the single octet in that field. When the word 'Variable' is used, it indicates that the corresponding field has a variable length defined either by an associated (one or two octet) length field, or by a data type field. 特に注記がない限り、以降のパケットフォーマット図に書かれている十進数値は、そのフィールドの長さをオクテット単位で表したものである。あるオクテットが特別な値を持たなければならない場合、フィールド内の単一オクテットの値を表すために X'hh' という記法が使用されている。'可変' はそのフィールドが可変長であることを表し、その長さは対応する(1 または 2 オクテットの)レングスフィールド、またはデータタイプフィールドで決定される。
When a TCP-based client wishes to establish a connection to an object that is reachable only via a firewall (such determination is left up to the implementation), it must open a TCP connection to the appropriate SOCKS port on the SOCKS server system. The SOCKS service is conventionally located on TCP port 1080. If the connection request succeeds, the client enters a negotiation for the authentication method to be used, authenticates with the chosen method, then sends a relay request. The SOCKS server evaluates the request, and either establishes the appropriate connection or denies it. TCP ベースのクライアントが、ファイアウォールを通してのみ到達可能な目標との接続を確立したい場合、SOCKS サーバーシステム上の適切な SOCKS ポートへの TCP 接続を開かなければならない(到達可能かどうかの判断は実装に任される)。通常 SOCKS サービスは TCP ポート 1080 を使用する。この接続要求に成功すると、クライアントは使用されるべき認証メソッドの交渉に入り、選択されたメソッドで認証を行い、その後リレー要求を送信する。SOCKS サーバーはその要求を評価し、適切な接続を確立するか、さもなければ拒否する。
Unless otherwise noted, the decimal numbers appearing in packet- format diagrams represent the length of the corresponding field, in octets. Where a given octet must take on a specific value, the syntax X'hh' is used to denote the value of the single octet in that field. When the word 'Variable' is used, it indicates that the corresponding field has a variable length defined either by an associated (one or two octet) length field, or by a data type field. 特に注記がない限り、以降のパケットフォーマット図に書かれている十進数値は、そのフィールドの長さをオクテット単位で表したものである。あるオクテットが特別な値を持たなければならない場合、フィールド内の単一オクテットの値を表すために X'hh' という記法が使用されている。'可変' はそのフィールドが可変長であることを表し、その長さは対応する(1 または 2 オクテットの)レングスフィールド、またはデータタイプフィールドで決定される。
The client connects to the server, and sends a version identifier/method selection message: サーバーに接続したクライアントは、バージョン識別子/メソッド選択メッセージを送信する。
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 〜 255 |
+----+----------+----------+
The VER field is set to X'05' for this version of the protocol. The NMETHODS field contains the number of method identifier octets that appear in the METHODS field. このバージョンでは VER フィールドに X'05' がセットされる。NMETHODS フィールドには、METHODS フィールドに現れるメソッド識別子オクテットの数が含まれる。
The server selects from one of the methods given in METHODS, and sends a METHOD selection message: サーバーは METHODS で提示されたメソッドからひとつを選択し、METHOD 選択メッセージを送信する。
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
If the selected METHOD is X'FF', none of the methods listed by the client are acceptable, and the client MUST close the connection. METHOD が X'FF' の場合、クライアントの提示したメソッドがすべて受け入れられなかったことを表しており、クライアントは接続を閉じなければならない(MUST)。
The values currently defined for METHOD are: 現在のところ METHOD のために定義されている値は以下の通り：
o X'00' NO AUTHENTICATION REQUIRED
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD
o X'03' to X'7F' IANA ASSIGNED
o X'80' to X'FE' RESERVED FOR PRIVATE METHODS
o X'FF' NO ACCEPTABLE METHODS
o X'00' 認証不要
o X'01' GSSAPI
o X'02' ユーザ名/パスワード
o X'03' 〜 X'7F' IANA 割り当て済み
o X'80' 〜 X'FE' 非公開メソッド用に予約
o X'FF' 受け入れられるメソッドがない
The client and server then enter a method-specific sub-negotiation. この後クライアントとサーバーはメソッド固有の下位交渉に入る。
Descriptions of the method-dependent sub-negotiations appear in separate memos. メソッド固有の下位交渉はそれぞれ個別の文書に記述される。
Developers of new METHOD support for this protocol should contact IANA for a METHOD number. The ASSIGNED NUMBERS document should be referred to for a current list of METHOD numbers and their corresponding protocols. このプロトコルをサポートする新しい METHOD の開発者は、METHOD 番号のために IANA に連絡を取るべきである。現在の METHOD の一覧とそれらに対応するプロトコルについては、ASSIGNED NUMBERS 文書を参照するべきである。
Compliant implementations MUST support GSSAPI and SHOULD support USERNAME/PASSWORD authentication methods. 標準に適合する実装は GSSAPI をサポートしなければならず(MUST)、ユーザ名/パスワード認証をサポートするべきである(SHOULD)。
Once the method-dependent subnegotiation has completed, the client sends the request details. If the negotiated method includes encapsulation for purposes of integrity checking and/or confidentiality, these requests MUST be encapsulated in the method- dependent encapsulation. メソッド固有の下位交渉が完了すると、クライアントはリクエストの詳細を送信する。交渉されたメソッドが完全性や信頼性を目的としたカプセル化を含む場合、これらのリクエストはメソッド固有の方法でカプセル化されなければならない(MUST)。
The SOCKS request is formed as follows: SOCKS リクエストのフォーマットは以下の通り：
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | 可変 | 2 |
+----+-----+-------+------+----------+----------+
Where: ここで：
o VER protocol version: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet
order
o VER プロトコルバージョン： X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP アドレスタイプ
o IP V4 アドレス： X'01'
o ドメイン名： X'03'
o IP V6 アドレス： X'04'
o DST.ADDR 宛先アドレス
o DST.PORT ネットワークオクテットオーダーで表された
宛先ポート
The SOCKS server will typically evaluate the request based on source and destination addresses, and return one or more reply messages, as appropriate for the request type. 一般に SOCKS サーバーは送信元アドレスと宛先アドレスとに基づいてリクエストを評価し、リクエストタイプに応じて適切なリプライメッセージをひとつまたは複数返す。
In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies the type of address contained within the field: アドレスフィールド(DST.ADDR、BND.ADDR)に含まれるアドレスの種類は ATYP フィールドによって決定される。ATYP フィールドの値の意味は以下の通り：
o X'01'
the address is a version-4 IP address, with a length of 4 octets アドレスは IPv4 のアドレスであり、長さは 4 オクテットである。
o X'03'
the address field contains a fully-qualified domain name. The first octet of the address field contains the number of octets of name that follow, there is no terminating NUL octet. アドレスフィールドには完全修飾ドメイン名が含まれる。アドレスフィールドの第一オクテットは、その後に続くドメイン名のオクテット数を表す。終端を表す NUL オクテットはない。
o X'04'
the address is a version-6 IP address, with a length of 16 octets. アドレスは IPv6 のアドレスであり、長さは 16 オクテットである。
The SOCKS request information is sent by the client as soon as it has established a connection to the SOCKS server, and completed the authentication negotiations. The server evaluates the request, and returns a reply formed as follows: SOCKS サーバーへの接続が確立され認証の交渉が完了するとすぐに、クライアントから SOCKS のリクエスト情報が送信される。サーバーはそのリクエストを評価し、以下のフォーマットのリプライを返す：
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
+----+-----+-------+------+----------+----------+
|VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | 可変 | 2 |
+----+-----+-------+------+----------+----------+
Where: ここで
o VER protocol version: X'05'
o REP Reply field:
o X'00' succeeded
o X'01' general SOCKS server failure
o X'02' connection not allowed by ruleset
o X'03' Network unreachable
o X'04' Host unreachable
o X'05' Connection refused
o X'06' TTL expired
o X'07' Command not supported
o X'08' Address type not supported
o X'09' to X'FF' unassigned
o RSV RESERVED
o ATYP address type of following address
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o BND.ADDR server bound address
o BND.PORT server bound port in network octet order
o VER プロトコルバージョン： X'05'
o REP リプライフィールド：
o X'00' 成功
o X'01' 一般的な SOCKS サーバー障害
o X'02' ルールセットによって許可されていない接続
o X'03' ネットワーク到達不能
o X'04' ホスト到達不能
o X'05' 接続拒否
o X'06' TTL 超過
o X'07' コマンドがサポートされていない
o X'08' アドレスタイプがサポートされていない
o X'09' 〜 X'FF' 見割当て
o RSV RESERVED
o ATYP アドレスタイプ
o IP V4 アドレス： X'01'
o ドメイン名： X'03'
o IP V6 アドレス： X'04'
o BND.ADDR サーバーのバウンドアドレス
o BND.PORT ネットワークオクテットオーダーで表された
サーバーのバウンドポート
Fields marked RESERVED (RSV) must be set to X'00'. RESERVED(RSV) フィールドには X'00' がセットされなければならない。
If the chosen method includes encapsulation for purposes of authentication, integrity and/or confidentiality, the replies are encapsulated in the method-dependent encapsulation. 選択されたメソッドが認証や完全性、信頼性を目的としたカプセル化を含む場合、リプライはメソッド固有の方法でカプセル化される。
In the reply to a CONNECT, BND.PORT contains the port number that the server assigned to connect to the target host, while BND.ADDR contains the associated IP address. The supplied BND.ADDR is often different from the IP address that the client uses to reach the SOCKS server, since such servers are often multi-homed. It is expected that the SOCKS server will use DST.ADDR and DST.PORT, and the client-side source address and port in evaluating the CONNECT request. CONNECT へのリプライにおいて、BND.PORT は目的のホストへの接続のためにサーバーが割り当てたポート番号を含み、BND.ADDR は対応する IP アドレスを含む。SOCKS サーバーはたいていマルチホーム化されているため、ここで提供される BND.ADDR は、クライアントが SOCKS サーバーに接続するために使用する IP アドレスとはしばしば異なる。CONNECT リクエストの評価において SOCKS サーバーは、DST.ADDR と DST.PORT、及び、クライアント側の送信元アドレスとポートとを使用することが期待される。
The BIND request is used in protocols which require the client to accept connections from the server. FTP is a well-known example, which uses the primary client-to-server connection for commands and status reports, but may use a server-to-client connection for transferring data on demand (e.g. LS, GET, PUT). クライアントがサーバーからの接続を受け入れなければならないプロトコルの場合に、この BIND リクエストが使用される。FTP が良く知られた例である。FTP はコマンドとステータスレポートとのためにクライアントからサーバーへの主接続を使用するが、(例えば LS、GET、PUT など)必要に応じてデータ転送のためにサーバーからクライアントへの接続を使用する。
It is expected that the client side of an application protocol will use the BIND request only to establish secondary connections after a primary connection is established using CONNECT. In is expected that a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND request. アプリケーションプロトコルのクライアント側は、CONNECT を使用して主接続を確立した後に補助接続を確立するためにのみ、BIND リクエストを使用することを期待される。BIND リクエストの評価において SOCKS サーバーは、DST.ADDR と DST.PORT とを使用することを期待される。
Two replies are sent from the SOCKS server to the client during a BIND operation. The first is sent after the server creates and binds a new socket. The BND.PORT field contains the port number that the SOCKS server assigned to listen for an incoming connection. The BND.ADDR field contains the associated IP address. The client will typically use these pieces of information to notify (via the primary or control connection) the application server of the rendezvous address. The second reply occurs only after the anticipated incoming connection succeeds or fails. BIND 操作の間に、 SOCKS サーバーからクライアントへ二つのリプライが送信される。ひとつ目のリプライは、サーバーが新しいソケットを生成し、バインドした後に送信される。このリプライの BND.PORT フィールドには SOCKS サーバーが接続を受け入れるためにリッスンポートに割り当てたポート番号が含まれ、BND.ADDR フィールドには対応する IP アドレスが含まれる。一般にクライアントは、(主接続またはコントロール接続を通して)アプリケーションサーバーにランデブーアドレスを通知する際にこれらの情報を使用する。二つ目のリプライは、後続の入力接続が成功または失敗した後にのみ発生する。
In the second reply, the BND.PORT and BND.ADDR fields contain the address and port number of the connecting host. 二つ目のリプライの BND.PORT フィールド及び BND.ADDR フィールドには、中継ホストのアドレスとポート番号とが含まれる。
The UDP ASSOCIATE request is used to establish an association within the UDP relay process to handle UDP datagrams. The DST.ADDR and DST.PORT fields contain the address and port that the client expects to use to send UDP datagrams on for the association. The server MAY use this information to limit access to the association. If the client is not in possesion of the information at the time of the UDP ASSOCIATE, the client MUST use a port number and address of all zeros. UDP ASSOCIATE リクエストは UDP リプライ処理内部で関連付けを確立するために使用される。DST.ADDR フィールド及び DST.PORT フィールドにはアドレスとポートとが含まれ、クライアントは UDP データグラムを送信するためにこのアドレスとポートとを使用することを期待する。サーバーは関連付けへのアクセス制限にこの情報を使用してもよい(MAY)。クライアントが UDP ASSOCIATE リクエスト時にこの情報を持っていなかった場合、ポート番号とアドレスとにすべてゼロを使用しなければならない(MUST)。
A UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates. UDP ASSOCIATE リクエストを送信した TCP 接続が閉じられたとき、その UDP の関連付けは削除される。
In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR fields indicate the port number/address where the client MUST send UDP request messages to be relayed. UDP ASSOCIATE リクエストへのリプライにおいて、BND.PORT フィールド及び BND.ADDR フィールドはそれぞれアドレスとポート番号とを表し、クライアントはリレーされるべき UDP リクエストメッセージをそこに送信しなければならない(MUST)。
When a reply (REP value other than X'00') indicates a failure, the SOCKS server MUST terminate the TCP connection shortly after sending the reply. This must be no more than 10 seconds after detecting the condition that caused a failure. リプライが失敗(REP の値が X'00' 以外)を示していた場合、SOCKS サーバーはリプライを送信した後すぐに TCP 接続を終了しなければならない(MUST)。この動作は、失敗の原因を検出した後 10 秒以内に行われなければならない。
If the reply code (REP value of X'00') indicates a success, and the request was either a BIND or a CONNECT, the client may now start passing data. If the selected authentication method supports encapsulation for the purposes of integrity, authentication and/or confidentiality, the data are encapsulated using the method-dependent encapsulation. Similarly, when data arrives at the SOCKS server for the client, the server MUST encapsulate the data as appropriate for the authentication method in use. リプライコードが成功(REP の値が X'00')を示しており、リクエストが BIND または CONNECT だった場合、クライアントはデータ送信を開始することができる。選択された認証メソッドが完全性や認証、信頼性を目的としてカプセル化をサポートしている場合、データはメソッド固有の方法でカプセル化される。同じように、そのクライアント宛てのデータが SOCKS サーバーに到着したとき、サーバーは使用中の認証メソッドに応じて適切な方法でデータをカプセル化しなければならない(MUST)。
A UDP-based client MUST send its datagrams to the UDP relay server at the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE request. If the selected authentication method provides encapsulation for the purposes of authenticity, integrity, and/or confidentiality, the datagram MUST be encapsulated using the appropriate encapsulation. Each UDP datagram carries a UDP request header with it: UDP ベースのクライアントは、UDP ASSOCIATE リクエストに対するリプライの BND.PORT で示された UDP リレーサーバーの UDP ポートにデータグラムを送信しなければならない(MUST)。選択された認証メソッドが完全性や認証、信頼性を目的としてカプセル化を提供している場合、データグラムは適切な方法でカプセル化されなければならない(MUST)。各 UDP データグラムは以下の UDP リクエストヘッダを伴なって送信される：
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | 可変 | 2 | 可変 |
+----+------+------+----------+----------+----------+
The fields in the UDP request header are: 各フィールドは以下の通り：
o RSV Reserved X'0000'
o FRAG Current fragment number
o ATYP address type of following addresses:
o IP V4 address: X'01'
o DOMAINNAME: X'03'
o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port
o DATA user data
o RSV 予約済み X'0000'
o FRAG 現在のフラグメント番号
o ATYP アドレスタイプ：
o IP V4 アドレス： X'01'
o ドメイン名： X'03'
o IP V6 アドレス： X'04'
o DST.ADDR 宛先アドレス
o DST.PORT 宛先ポート
o DATA ユーザーデータ
When a UDP relay server decides to relay a UDP datagram, it does so silently, without any notification to the requesting client. Similarly, it will drop datagrams it cannot or will not relay. When a UDP relay server receives a reply datagram from a remote host, it MUST encapsulate that datagram using the above UDP request header, and any authentication-method-dependent encapsulation. UDP リレーサーバーが UDP データグラムをリレーすることを決定した場合、その動作はリクエストを送信したクライアントに何も通知されることなく暗黙的に行われる。UDP リレーサーバーは、リレーできない、またはリレーされないデータグラムを同じように暗黙的に破棄する。リモートホストから返信のデータグラムを受信した UDP リレーサーバーは、上記の UDP リクエストヘッダと認証メソッド固有のカプセル化方法とを使用してデータグラムをカプセル化しなければならない(MUST)。
The UDP relay server MUST acquire from the SOCKS server the expected IP address of the client that will send datagrams to the BND.PORT given in the reply to UDP ASSOCIATE. It MUST drop any datagrams arriving from any source IP address other than the one recorded for the particular association. UDP リレーサーバーは、UDP ASSOCIATE への応答で示した BND.PORT にデータグラムを送信するであろうクライアントの IP アドレスを、SOCKS サーバーから取得しなければならない(MUST)。UDP リレーサーバーは、どの関連付けにも記録されていない送信元 IP アドレスからのデータグラムを破棄しなければならない(MUST)。
The FRAG field indicates whether or not this datagram is one of a number of fragments. If implemented, the high-order bit indicates end-of-fragment sequence, while a value of X'00' indicates that this datagram is standalone. Values between 1 and 127 indicate the fragment position within a fragment sequence. Each receiver will have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these fragments. The reassembly queue must be reinitialized and the associated fragments abandoned whenever the REASSEMBLY TIMER expires, or a new datagram arrives carrying a FRAG field whose value is less than the highest FRAG value processed for this fragment sequence. The reassembly timer MUST be no less than 5 seconds. It is recommended that fragmentation be avoided by applications wherever possible. FRAG フィールドは、そのデータグラムがフラグメントのひとつであるかどうかを表す。フラグメント処理が実装されていれば、上位ビットはフラグメントシーケンスの終了を表し、値 X'00' はそれがフラグメント化されていない単独のデータグラムであることを表す。1 〜 127 の値はフラグメントシーケンスの中でのそのフラグメントの位置を表す。各受信者は、これらのフラグメントに対応する再構築キュー(REASSEMBLY QUEUE)と再構築タイマー(REASSEMBLY TIMER)とを持つだろう。再構築タイマーが時間切れになるか、そのフラグメントシーケンスのために処理された最大の FRAG 値より小さい値の FRAG フィールドを持つデータグラムが到着した場合にはいつでも、再構築キューは初期化され、関連するフラグメントは破棄されなければならない。再構築タイマーは 5 秒以上でなければならない(MUST)。可能であれば常に、アプリケーションはフラグメント化を避けることが推量される。
Implementation of fragmentation is optional; an implementation that does not support fragmentation MUST drop any datagram whose FRAG field is other than X'00'. フラグメント処理の実装は任意である。フラグメント処理をサポートしない実装は、FRAG フィールドが X'00' ではないデータグラムを破棄しなければならない(MUST)。
The programming interface for a SOCKS-aware UDP MUST report an available buffer space for UDP datagrams that is smaller than the actual space provided by the operating system: SOCKS を認識する UDP のためのプログラミングインターフェイスは、UDP データグラムのために利用可能なバッファ領域を通知しなければならない(MUST)。このサイズはオペレーティングシステムが提供する実際の領域より小さくなる。
o if ATYP is X'01' - 10+method_dependent octets smaller
o if ATYP is X'03' - 262+method_dependent octets smaller
o if ATYP is X'04' - 20+method_dependent octets smaller
o ATYP が X'01' の場合 - 10+メソッド固有のオクテット 未満
o ATYP が X'03' の場合 - 262+メソッド固有のオクテット 未満
o ATYP が X'04' の場合 - 20+メソッド固有のオクテット 未満
This document describes a protocol for the application-layer traversal of IP network firewalls. The security of such traversal is highly dependent on the particular authentication and encapsulation methods provided in a particular implementation, and selected during negotiation between SOCKS client and SOCKS server. この文書は IP ネットワークのファイアウォールをアプリケーション層で通過するためのプロトコルを説明している。このような通過のセキュリティは、特定の実装が提供する特定の認証方法とカプセル化方法とに大きく依存し、それらは SOCKS クライアントと SOCKS サーバーとの間での交渉中に選択される。
Careful consideration should be given by the administrator to the selection of authentication methods. 認証メソッドの選択には、管理者による慎重な考察がなされるべきである。
[1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Stn. C,
Ottawa, ON
CANADA K1Y 4H7
Phone: (613) 763-9145
EMail: mleech@bnr.ca