この文書はRFC2428の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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.

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.
   ファイル転送プロトコルの仕様書は下層のネットワークプロトコル(特にI
   Pバージョン4)が32ビットのネットワークアドレスを使うと想定します。
   インターネット・プロトコルバージョン6の実装によりネットワークアドレ
   スがもう32ビットではありません。この文書はプロトコルがIPv4とI
   Pv6の上に働くことを可能にするためFTPへの拡張を指定します。加え
   て定義された機構は将来追加のネットワークプロトコルを支援することがで
   きます。

1.  Introduction
1.  はじめに

   The keywords, such as MUST and SHOULD, found in this document are
   used as defined in RFC 2119 [Bra97].
   この文書で見いだされた、MUSTとSHOULDのような、キーワードは、RFC2119
   [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ビット長ではないでしょう。RFC1639
   [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章が結論を供給しま
   す。

2.  The EPRT Command
2.  EPRTコマンド

   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コマンドはデータ接続の拡張アドレス指定をします。拡張アドレスは、
   ネットワークプロトコルと、ネットワークとトランスポートアドレスとから
   成り立たちます(MUST)。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コマンドキーワードの後には1つのスペース(ASCII32)が続きます
   (MUST)。スペースの後に区切り文字(<d>)を指定します(MUST)。区切り文
   字は33以上126以下のASCII文字の1つです(MUST)。文字"|"(ASCII1
   24)が、ネットワークアドレスをコード化するために必要な文字と一致し
   ない限り、推薦されます。

   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>引数はIANAが最新の番号割当てRFC(この文書の執筆の時点
   でRFC1700[RP94])で定義するアドレスファミリー番号です(MUST)。この番号
   は使われるプロトコルを示します(そして、暗黙のうちにアドレス長を示し
   ます)。この文書は[RP94]から次の表に示すアドレスファミリー番号2つを
   例として用いるでしょう:

        AF Number   Protocol
        AF番号    プロトコル
        ---------   --------
        1           Internet Protocol, Version 4 [Pos81a]
                    インターネットプロトコルバージョン4[Pos81a]
        2           Internet Protocol, Version 6 [DH96]
                    インターネットプロトコルバージョン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)で、アドレスが次
   のフォーマットです(MUST):

        AF Number   Address Format      Example
        AF番号    アドレスフォーマット 例

        ---------   --------------      -------
        1           dotted decimal      132.235.1.2
                    ドット区切り10進

        2           IPv6 string         1080::8:800:200C:417A
                    representations
                    defined in [HD96]
                    [HD96]で定義された
                    表現のIPv6文字列

   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ポート番号の文字列表
   現です(MUST)。

   The following are sample EPRT commands:
   以下はEPRTコマンドの例です:

        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.
   最初のコマンドはホスト「132.235.1.2」のTCPポート6275に
   データ接続をするためサーバーがIPv4を使うべきであることを明示しま
   す。2番目のコマンドはポート5282にTCPデータ接続をするためにサー
   バーがIPv6ネットワークプロトコルとネットワークアドレス
   "1080::8:800:200C:417A"を使うべきことを明示します。

   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(命令了解)のコードを返
   します(MUST)。標準否定エラーコード500と501[PR85]はたいていの
   EPRTコマンドのエラー(例えば、構文エラー)に対処することに十分です。
   しかしながら、追加のエラーコードが必要です。回答コード522はサーバー
   が求められたネットワークプロトコルをサポートしないことを示します。こ
   の新しいエラーコードの解釈は以下です:。

        5yz Negative Completion
            否定的終了
        x2z Connections
            接続
        xy2 Extended Port Failure - unknown network protocol
            拡張ポート失敗−未知のネットワークプロトコル

   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:
   回答のテキスト部はサーバがサポートするネットワークプロトコルを示さな
   くてはなりません(MUST)。もしネットワークプロトコルがサポートされなら、
   回答文字列のフォーマットは以下に違いありません(MUST):

        <text stating that the network protocol is unsupported> \
            (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:
   上で指定した番号コードとキャラクタ'('と')'のプロトコル情報の両方は、
   回答を受け取るソフトウェア自動装置のために意図されます;番号コードと
   キャラクタ'('の間のテキストメッセージは人間ユーザーのために意図され、
   任意のテキストであり得ますが、キャラクタ'('と')'を含んではなりません
   (MUST NOT)。上記の場合、テキストはEPRTコマンドのネットワークプロトコ
   ルをサーバがサポートしないことを示すべきです(SHOULD)。カッコの中のプ
   ロトコルのリストはアドレスファミリー番号をコンマで区切ったリストに違
   いありません。回答文字列例が以下です:

        Network protocol not supported, use (1)

        Network protocol not supported, use (1,2)

3.  The EPSV Command
3.  EPSVコマンド

   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です(MUST)。このコードの解釈は[PR85]によれば以下です:

        2yz Positive Completion
        肯定的終了
        x2z Connections
        接続
        xy9 Extended Passive Mode Entered
        拡張パッシブモードになる

   The text returned in response to the EPSV command MUST be:
   EPSVコマンドに応えて返されたテキストは以下です(MUST):

        <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コマンドに必要とされる正確な文字列であるに違いありません(MUST)。

   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ポート番号の文字列表現です
   (MUST)。データ接続によって使われるネットワークプロトコルは制御接続で
   使われるネットワークプロトコルと同じでしょう。加えて、データ接続のネッ
   トワークアドレスはが制御接続のネットワークアドレスと同じでしょう。回
   答文字列例は以下です:。

        Entering Extended Passive Mode (|||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は全てのEPRTコマンドのエラー(例え
   ば、構文エラー)に対処することに十分です。

   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(中止)コマンドを
   実行しなくてはなりません(MUST)。クライアントはそれから特定ネットワー
   クプロトコルを使う事を要求する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.
   もし求められたプロトコルがサーバーによってサポートされるなら、サーバ
   はそのプロトコルを使うべきです(SHOULD)。もしそうでなければ、サーバー
   は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コマンドはネットワークアドレス翻訳者にEPRTコマンド(他
   のデータコマンドも)がもう使われないということを知らせるため引数
   「ALL」で使うことができます。このコマンドの例が以下です:

        EPSV<space>ALL

   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、その他)を拒否しなくて
   はなりません(MUST)。このEPSVコマンドの使用は4章でさらに説明されます。

4.  Command Usage
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つのマシンの間に設立されているすべてのF
   TP転送でEPSVコマンドが使われなくてはなりません。EPSVコマンドを使う
   ことはファイアウォールやネットワークアドレス翻訳者(NAT)を通過す
   る転送の能力に役立ちますRFC1579[Bel94]は、ファイアウォールが一般に入
   り接続(PORT(EPRT)コマンドを使う時に必要)を許さないので、ファイア
   ウォールの後からはパッシブコマンドを使うことを勧めます。加えてこの文
   書で定義されるEPSVは、NATに転送トラフィックのネットワークアドレス
   を変えるように要求しません。NATはEPRTコマンドが使われたなら、アド
   レスを変えなければならないでしょう。最終的に、もしクライアントが
   「EPSV ALL」コマンドを出すなら、NATはEPRTコマンドが決して使われな
   いだろうから、データ部の翻訳が必要ではないので、接続を翻訳者の「速く
   通過するパス」上に置くことが可能かもしれません。クライアントは両方向
   のFTP転送だけを予期する時、できるだけ早くこのコマンドを出すべきで
   す(SHOULD)。もしクライアントがEPSV ALLコマンドを出した後で三者間のF
   TP転送をしなくてはならないことに気付くなら、新しいFTPセッション
   を始めなくてはなりません(MUST)。

5.  Security Issues
5.  セキュリティ問題

   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に対する変更が新しいセキュリティ問題を起こすと信
   じません。Work in Progress[AO98]はFTPセキュリティ問題とこれらのセ
   キュリティ問題を減らすテクニックのいっそう一般的な論議です。

6.  Conclusions
6.  結論

   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.

   [Bel94]  Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
            1994.

   [Bra97]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

   [DH96]   Deering, S., and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 1883, December 1995.

   [HD96]   Hinden, R., and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 2373, July 1998.

   [Pis94]  Piscitello, D., "FTP Operation Over Big Address Records
            (FOOBAR)", RFC 1639, June 1994.

   [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
            1981.

   [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
            September 1981.

   [PR85]   Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
            STD 9, RFC 959, October 1985.

   [RP94]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
            1700, October 1994.  See also:
            http://www.iana.org/numbers.html

Authors' Addresses
著者のアドレス

   Mark Allman
   NASA Lewis Research Center/Sterling Software
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  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

   Phone: (740) 593-1234
   EMail: ostermann@cs.ohiou.edu


   Craig Metz
   The Inner Net
   Box 10314-1954
   Blacksburg, VA  24062-0314

   Phone:  (DSN) 754-8590
   EMail: cmetz@inner.net



Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.
   著作権(C)インターネット学会(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.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Japanese translation by Ishida So