[要約] RFC 2428は、IPv6とNATに対応するためのFTP拡張機能を提供しています。その目的は、IPv6ネットワークとNAT環境でのFTP通信の問題を解決し、効果的なデータ転送を可能にすることです。
Network Working Group M. Allman
Request for Comments: 2428 NASA Lewis/Sterling Software
Category: Standards Track S. Ostermann
Ohio University
C. Metz
The Inner Net
September 1998
FTP Extensions for IPv6 and NATs
IPv6およびNATのFTP拡張
Status of this Memo
本文書の状態
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address (specifically IP version 4). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.
ファイル転送プロトコルの仕様は、基盤となるネットワークプロトコルが32ビットのネットワークアドレス（特にIPバージョン4）を使用することを前提としています。バージョン6のインターネットプロトコルの展開により、ネットワークアドレスは32ビットではなくなります。このホワイトペーパーでは、プロトコルがIPv4およびIPv6で機能することを可能にするFTPの拡張機能について説明します。さらに、定義されたフレームワークは、将来的に追加のネットワークプロトコルをサポートできるようになります。
The keywords, such as MUST and SHOULD, found in this document are used as defined in RFC 2119 [Bra97].
このドキュメントにあるMUSTやSHOULDなどのキーワードは、RFC 2119 [Bra97]で定義されているとおりに使用されます。
The File Transfer Protocol [PR85] only provides the ability to communicate information about IPv4 data connections. FTP assumes network addresses will be 32 bits in length. However, with the deployment of version 6 of the Internet Protocol [DH96] addresses will no longer be 32 bits long. RFC 1639 [Pis94] specifies extensions to FTP to enable its use over various network protocols. Unfortunately, the mechanism can fail in a multi-protocol environment. During the transition between IPv4 and IPv6, FTP needs the ability to negotiate the network protocol that will be used for data transfer.
ファイル転送プロトコル[PR85]は、IPv4データ接続に関する情報を通信する機能のみを提供します。 FTPは、ネットワークアドレスの長さが32ビットであることを前提としています。ただし、バージョン6のインターネットプロトコル[DH96]の導入により、アドレスは32ビット長ではなくなります。 RFC 1639 [Pis94]は、さまざまなネットワークプロトコルでFTPを使用できるようにするFTPの拡張を指定しています。残念ながら、このメカニズムはマルチプロトコル環境では失敗する可能性があります。 IPv4とIPv6の間の移行中に、FTPはデータ転送に使用されるネットワークプロトコルをネゴシエートする機能を必要とします。
This document provides a specification for a way that FTP can communicate data connection endpoint information for network protocols other than IPv4. In this specification, the FTP commands PORT and PASV are replaced with EPRT and EPSV, respectively. This document is organized as follows. Section 2 outlines the EPRT command and Section 3 outlines the EPSV command. Section 4 defines the utilization of these two new FTP commands. Section 5 briefly presents security considerations. Finally, Section 6 provides conclusions.
このドキュメントは、FTPがIPv4以外のネットワークプロトコルのデータ接続エンドポイント情報を通信する方法の仕様を提供します。この仕様では、FTPコマンドPORTおよびPASVは、それぞれEPRTおよびEPSVに置き換えられています。このドキュメントは次のように構成されています。セクション2ではEPRTコマンドの概要を説明し、セクション3ではEPSVコマンドの概要を説明します。セクション4では、これら2つの新しいFTPコマンドの使用方法を定義します。セクション5では、セキュリティに関する考慮事項について簡単に説明します。最後に、セクション6では結論を示します。
The EPRT command allows for the specification of an extended address for the data connection. The extended address MUST consist of the network protocol as well as the network and transport addresses. The format of EPRT is:
EPRTコマンドを使用すると、データ接続の拡張アドレスを指定できます。拡張アドレスは、ネットワークプロトコルと、ネットワークおよびトランスポートアドレスで構成する必要があります。 EPRTの形式は次のとおりです。
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
The EPRT command keyword MUST be followed by a single space (ASCII 32). Following the space, a delimiter character (<d>) MUST be specified. The delimiter character MUST be one of the ASCII characters in range 33-126 inclusive. The character "|" (ASCII 124) is recommended unless it coincides with a character needed to encode the network address.
EPRTコマンドキーワードの後には、単一のスペース（ASCII 32）が続く必要があります。スペースに続いて、区切り文字（<d>）を指定する必要があります。区切り文字は、33〜126の範囲のASCII文字の1つでなければなりません。文字「|」 （ASCII 124）は、ネットワークアドレスのエンコードに必要な文字と一致しない限り推奨されます。
The <net-prt> argument MUST be an address family number defined by IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the writing of this document). This number indicates the protocol to be used (and, implicitly, the address length). This document will use two of address family numbers from [RP94] as examples, according to the following table:
<net-prt>引数は、最新の割り当て番号RFC（このドキュメントの執筆時点でのRFC 1700 [RP94]）でIANAによって定義されたアドレスファミリ番号である必要があります。この番号は、使用するプロトコル（および暗黙的にアドレス長）を示します。このドキュメントでは、次の表に従って、[RP94]の2つのアドレスファミリ番号を例として使用します。
AF Number Protocol
--------- --------
1 Internet Protocol, Version 4 [Pos81a]
2 Internet Protocol, Version 6 [DH96]
The <net-addr> is a protocol specific string representation of the network address. For the two address families specified above (AF Number 1 and 2), addresses MUST be in the following format:
<net-addr>は、ネットワークアドレスのプロトコル固有の文字列表現です。上記で指定された2つのアドレスファミリ（AF番号1および2）の場合、アドレスは次の形式である必要があります。
AF Number Address Format Example
--------- -------------- -------
1 dotted decimal 132.235.1.2
2 IPv6 string 1080::8:800:200C:417A
representations
defined in [HD96]
The <tcp-port> argument must be the string representation of the number of the TCP port on which the host is listening for the data connection.
<tcp-port>引数は、ホストがデータ接続をリッスンしているTCPポートの番号の文字列表現である必要があります。
The following are sample EPRT commands:
以下は、EPRTコマンドのサンプルです。
EPRT |1|132.235.1.2|6275|
EPRT | 1 | 132.235.1.2 | 6275 |
EPRT |2|1080::8:800:200C:417A|5282|
The first command specifies that the server should use IPv4 to open a data connection to the host "132.235.1.2" on TCP port 6275. The second command specifies that the server should use the IPv6 network protocol and the network address "1080::8:800:200C:417A" to open a TCP data connection on port 5282.
最初のコマンドは、サーバーがIPv4を使用してTCPポート6275のホスト「132.235.1.2」へのデータ接続を開くことを指定します。2番目のコマンドは、サーバーがIPv6ネットワークプロトコルとネットワークアドレス「1080 :: 8」を使用することを指定します：800：200C：417A」は、ポート5282でTCPデータ接続を開きます。
Upon receipt of a valid EPRT command, the server MUST return a code of 200 (Command OK). The standard negative error code 500 and 501 [PR85] are sufficient to handle most errors (e.g., syntax errors) involving the EPRT command. However, an additional error code is needed. The response code 522 indicates that the server does not support the requested network protocol. The interpretation of this new error code is:
有効なEPRTコマンドを受信すると、サーバーはコード200（コマンドOK）を返す必要があります。標準の負のエラーコード500および501 [PR85]は、EPRTコマンドに関連するほとんどのエラー（構文エラーなど）を処理するのに十分です。ただし、追加のエラーコードが必要です。応答コード522は、サーバーが要求されたネットワークプロトコルをサポートしていないことを示します。この新しいエラーコードの解釈は次のとおりです。
5yz Negative Completion x2z Connections xy2 Extended Port Failure - unknown network protocol
5yz否定完了x2z接続xy2拡張ポート障害-不明なネットワークプロトコル
The text portion of the response MUST indicate which network protocols the server does support. If the network protocol is unsupported, the format of the response string MUST be:
応答のテキスト部分は、サーバーがサポートするネットワークプロトコルを示す必要があります。ネットワークプロトコルがサポートされていない場合、応答文字列の形式は次のようにする必要があります。
<text stating that the network protocol is unsupported> \ (prot1,prot2,...,protn)
<ネットワークプロトコルがサポートされていないことを示すテキスト> \（prot1、prot2、...、protn）
Both the numeric code specified above and the protocol information between the characters '(' and ')' are intended for the software automata receiving the response; the textual message between the numeric code and the '(' is intended for the human user and can be any arbitrary text, but MUST NOT include the characters '(' and ')'. In the above case, the text SHOULD indicate that the network protocol in the EPRT command is not supported by the server. The list of protocols inside the parenthesis MUST be a comma separated list of address family numbers. Two example response strings follow:
上記で指定した数値コードと文字「（」と「）」の間のプロトコル情報は、応答を受信するソフトウェアオートマトンを対象としています。数値コードと「（」の間のテキストメッセージは人間のユーザーを対象としており、任意のテキストにすることができますが、文字「（」と「）」を含めることはできません。上記の場合、テキストは、 EPRTコマンドのネットワークプロトコルはサーバーでサポートされていません。括弧内のプロトコルのリストは、アドレスファミリー番号のコンマ区切りのリストである必要があります。2つの応答文字列の例を次に示します。
Network protocol not supported, use (1)
ネットワークプロトコルはサポートされていません。（1）を使用してください
Network protocol not supported, use (1,2)
ネットワークプロトコルはサポートされていません。（1,2）を使用してください
The EPSV command requests that a server listen on a data port and wait for a connection. The EPSV command takes an optional argument. The response to this command includes only the TCP port number of the listening connection. The format of the response, however, is similar to the argument of the EPRT command. This allows the same parsing routines to be used for both commands. In addition, the format leaves a place holder for the network protocol and/or network address, which may be needed in the EPSV response in the future. The response code for entering passive mode using an extended address MUST be 229. The interpretation of this code, according to [PR85] is:
EPSVコマンドは、サーバーがデータポートをリッスンし、接続を待つことを要求します。 EPSVコマンドはオプションの引数を取ります。このコマンドへの応答には、リスニング接続のTCPポート番号のみが含まれます。ただし、応答の形式は、EPRTコマンドの引数に似ています。これにより、両方のコマンドで同じ解析ルーチンを使用できます。さらに、このフォーマットは、ネットワークプロトコルやネットワークアドレスのプレースホルダーを残します。これは、将来EPSV応答で必要になる可能性があります。拡張アドレスを使用してパッシブモードに入る場合の応答コードは229である必要があります。[PR85]によると、このコードの解釈は次のとおりです。
2yz Positive Completion x2z Connections xy9 Extended Passive Mode Entered
2yz肯定完了x2z接続xy9拡張パッシブモードに入りました
The text returned in response to the EPSV command MUST be:
EPSVコマンドへの応答として返されるテキストは次のとおりです。
<text indicating server is entering extended passive mode> \
(<d><d><d><tcp-port><d>)
The portion of the string enclosed in parentheses MUST be the exact string needed by the EPRT command to open the data connection, as specified above.
括弧で囲まれた文字列の部分は、上で指定したように、EPRTコマンドがデータ接続を開くために必要な正確な文字列である必要があります。
The first two fields contained in the parenthesis MUST be blank. The third field MUST be the string representation of the TCP port number on which the server is listening for a data connection. The network protocol used by the data connection will be the same network protocol used by the control connection. In addition, the network address used to establish the data connection will be the same network address used for the control connection. An example response string follows:
括弧に含まれる最初の2つのフィールドは空白でなければなりません。 3番目のフィールドは、サーバーがデータ接続をリッスンしているTCPポート番号の文字列表現である必要があります。データ接続で使用されるネットワークプロトコルは、制御接続で使用されるネットワークプロトコルと同じです。また、データ接続の確立に使用されるネットワークアドレスは、制御接続に使用されるネットワークアドレスと同じになります。次に、応答文字列の例を示します。
Entering Extended Passive Mode (|||6446|)
拡張パッシブモードの開始（||| 6446 |）
The standard negative error codes 500 and 501 are sufficient to handle all errors involving the EPSV command (e.g., syntax errors).
標準の負のエラーコード500および501は、EPSVコマンドに関連するすべてのエラー（構文エラーなど）を処理するのに十分です。
When the EPSV command is issued with no argument, the server will choose the network protocol for the data connection based on the protocol used for the control connection. However, in the case of proxy FTP, this protocol might not be appropriate for communication between the two servers. Therefore, the client needs to be able to request a specific protocol. If the server returns a protocol that is not supported by the host that will be connecting to the port, the client MUST issue an ABOR (abort) command to allow the server to close down the listening connection. The client can then send an EPSV command requesting the use of a specific network protocol, as follows:
引数なしでEPSVコマンドが発行されると、サーバーは、制御接続に使用されるプロトコルに基づいて、データ接続用のネットワークプロトコルを選択します。ただし、プロキシFTPの場合、このプロトコルは2つのサーバー間の通信には適さない場合があります。したがって、クライアントは特定のプロトコルを要求できる必要があります。サーバーが、ポートに接続するホストでサポートされていないプロトコルを返す場合、クライアントはABOR（中止）コマンドを発行して、サーバーが待機中の接続を閉じることを許可する必要があります。次に、クライアントは、次のように、特定のネットワークプロトコルの使用を要求するEPSVコマンドを送信できます。
EPSV<space><net-prt>
If the requested protocol is supported by the server, it SHOULD use the protocol. If not, the server MUST return the 522 error messages as outlined in section 2.
要求されたプロトコルがサーバーでサポートされている場合、プロトコルを使用する必要があります。そうでない場合、セクション2で概説されているように、サーバーは522エラーメッセージを返す必要があります。
Finally, the EPSV command can be used with the argument "ALL" to inform Network Address Translators that the EPRT command (as well as other data commands) will no longer be used. An example of this command follows:
最後に、EPSVコマンドを引数「ALL」とともに使用して、EPRTコマンド（および他のデータコマンド）が使用されなくなることをネットワークアドレストランスレータに通知できます。このコマンドの例は次のとおりです。
EPSV<space>ALL
EPSV <スペース>すべて
Upon receipt of an EPSV ALL command, the server MUST reject all data connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et al.). This use of the EPSV command is further explained in section 4.
EPSV ALLコマンドを受信すると、サーバーはEPSV以外のすべてのデータ接続セットアップコマンドを拒否する必要があります（EPRT、PORT、PASVなど）。 EPSVコマンドのこの使用については、セクション4でさらに説明します。
For all FTP transfers where the control and data connection(s) are being established between the same two machines, the EPSV command MUST be used. Using the EPSV command benefits performance of transfers that traverse firewalls or Network Address Translators (NATs). RFC 1579 [Bel94] recommends using the passive command when behind firewalls since firewalls do not generally allow incoming connections (which are required when using the PORT (EPRT) command). In addition, using EPSV as defined in this document does not require NATs to change the network address in the traffic as it is forwarded. The NAT would have to change the address if the EPRT command was used. Finally, if the client issues an "EPSV ALL" command, NATs may be able to put the connection on a "fast path" through the translator, as the EPRT command will never be used and therefore, translation of the data portion of the segments will never be needed. When a client only expects to do two-way FTP transfers, it SHOULD issue this command as soon as possible. If a client later finds that it must do a three-way FTP transfer after issuing an EPSV ALL command, a new FTP session MUST be started.
同じ2台のマシン間で制御およびデータ接続が確立されているすべてのFTP転送では、EPSVコマンドを使用する必要があります。 EPSVコマンドを使用すると、ファイアウォールまたはネットワークアドレス変換（NAT）を通過する転送のパフォーマンスが向上します。ファイアウォールは一般に着信接続を許可しないため、RFC 1579 [Bel94]はファイアウォールの背後でパッシブコマンドを使用することを推奨しています（PORT（EPRT）コマンドを使用するときに必要です）。さらに、このドキュメントで定義されているEPSVを使用する場合、NATがトラフィックを転送するときに、トラフィックのネットワークアドレスを変更する必要はありません。 EPRTコマンドが使用された場合、NATはアドレスを変更する必要があります。最後に、クライアントが「EPSV ALL」コマンドを発行すると、EPRTコマンドが使用されないため、NATがトランスレータを介して「高速パス」に接続を確立できるため、セグメントのデータ部分の変換が可能になります。必要になることはありません。クライアントが双方向FTP転送のみを行うことを期待している場合、クライアントはできるだけ早くこのコマンドを発行する必要があります。クライアントが後でEPSV ALLコマンドを発行した後に3方向FTP転送を実行する必要があることを検出した場合、新しいFTPセッションを開始する必要があります。
The authors do not believe that these changes to FTP introduce new security problems. A companion Work in Progress [AO98] is a more general discussion of FTP security issues and techniques to reduce these security problems.
著者は、FTPに対するこれらの変更が新しいセキュリティ問題をもたらすとは考えていません。進行中の関連作業[AO98]は、FTPのセキュリティの問題と、これらのセキュリティの問題を軽減するための手法のより一般的な説明です。
The extensions specified in this paper will enable FTP to operate over a variety of network protocols.
このホワイトペーパーで指定されている拡張機能により、FTPはさまざまなネットワークプロトコルで動作できるようになります。
References
参考文献
[AO98] Allman, M., and S. Ostermann, "FTP Security Considerations", Work in Progress.
[AO98] Allman、M。、およびS. Ostermann、「FTPのセキュリティに関する考慮事項」、進行中の作業。
[Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February 1994.
[Bel94] Bellovin、S。、「Firewall-Friendly FTP」、RFC 1579、1994年2月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[DH96] Deering、S。、およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 1883、1995年12月。
[HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[HD96] Hinden、R。、およびS. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
[Pis94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[Pis94] Piscitello、D。、「FTP Address Over Big Address Records（FOOBAR）」、RFC 1639、1994年6月。
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81a] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81b] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[PR85] Postel、J。、およびJ. Reynolds、「File Transfer Protocol（FTP）」、STD 9、RFC 959、1985年10月。
[RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html Authors' Addresses
[RP94] Reynolds、J。、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。以下も参照してください。http：//www.iana.org/numbers.html著者のアドレス
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
マークオールマンNASAルイスリサーチセンター/スターリングソフトウェア21000 Brookpark Rd。 MS 54-2クリーブランド、オハイオ州44135
Phone: (216) 433-6586
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701
Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens、OH 45701
Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu
電話：（740）593-1234メール：ostermann@cs.ohiou.edu
Craig Metz The Inner Net Box 10314-1954 Blacksburg, VA 24062-0314
クレイグ・メッツインナーネットボックス10314-1954ブラックスバーグ、バージニア24062-0314
Phone: (DSN) 754-8590 EMail: cmetz@inner.net
電話：（DSN）754-8590メール：cmetz@inner.net
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。