RFC1545 日本語訳

Network Working Group                                      D. Piscitello
Request for Comments: 1545                                      Bellcore
Category: Experimental                                     November 1993

Piscitelloがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1545年のBellcoreカテゴリ: 実験的な1993年11月

            FTP Operation Over Big Address Records (FOOBAR)

大きいアドレス記録の上のFTP操作(FOOBAR)

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   This paper describes a convention for specifying longer addresses in
   the PORT command.

この論文は、PORTコマンドにおける、より長いアドレスを指定するためにコンベンションについて説明します。

Introduction

序論

   This RFC specifies a method for assigning long addresses in the
   HOST-PORT specification for the data port to be used in establishing
   a data connection for File Transfer Protocol, FTP (STD 9, RFC 959).
   This is a general solution, applicable for all "next generation" IP
   alternatives, and can also be extended to allow FTP operation over
   transport interfaces other than TCP.

このRFCはデータポートがFile Transferプロトコルにデータ接続を確立する際に使用されるためにHOST-PORT仕様で長いアドレスを割り当てるためのメソッドを指定します、FTP(STD9、RFC959)。 これは、すべての「次世代」IP選択肢に、適切な一般解であり、また、TCP以外の輸送インタフェースの上のFTP操作を許すために広げることができます。

Acknowledgments

承認

   Many thanks to all the folks in the IETF who casually mentioned how
   to do this, but who left it to me to write this RFC.  Special thanks
   to Rich Colella, Bob Ullmann, Shawn Ostermann, Steve Lunt, and Brian
   Carpenter who had the time and decency to comment on the initial
   draft.  :-)

何気なくどうこれをするかに言及しましたが、このRFCに書くように私に任せたIETFのすべての人々をありがとうございます。 初期の草稿に関してコメントする時間と礼儀正しさを持っていたリッシュColella、ボブ・ウルマン、ショーン・オステルマン、スティーブ・ラント、およびブライアンCarpenterへの特別な感謝。 :-)

1.  Background

1. バックグラウンド

   The PORT command of File Transfer Protocol allows users to specify an
   address other than the default data port for the transport connection
   over which data are transferred. The PORT command syntax is:

File TransferプロトコルのPORTコマンドで、ユーザはデータがデータがわたっている輸送接続のために移植するデフォルト以外のアドレスを指定できます。 PORTコマンド構文は以下の通りです。

      PORT <SP> <host-port> <CRLF>

ポート<SP><ホストポート><CRLF>。

   The <host-port> argument is the concatenation of a 32-bit internet
   <host-address> and a 16-bit TCP <port-address>.  This address
   information is broken into 8-bit fields and the value of each field
   is transmitted as a decimal number (in character string

ポートを接待している<>議論は32ビットのインターネット<ホスト・アドレス>と16ビットのTCP<ポートアドレス>の連結です。 8ビットの野原がこのアドレス情報に細かく分けられて、それぞれの分野の値が10進数として送られる、(ぴったりした、結びます。

Piscitello                                                      [Page 1]

RFC 1545                  FTP Over Big Address             November 1993

大きいアドレス1993年11月にわたるPiscitello[1ページ]RFC1545FTP

   representation).  The fields are separated by commas.  A port command
   is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where h1 is the
   high order 8 bits of the internet host address.

表現) 野原はコンマによって分離されます。 移植コマンドはそうです、その結果、司令官では、「PORT h1、h2、h3、h4、p1、p2"」を形成してください。(そこでは、h1がインターネットホストの8ビットが扱う高位です)。

   To accommodate larger network addresses anticipated for all IP "next
   generation" alternatives, new commands and reply codes are needed for
   FTP.  This memo addresses these needs.

より大きいネットワーク・アドレスに対応するのは、すべてのIPのために「次世代」代替手段、新しいコマンド、および回答コードがFTPに必要であると予期しました。 このメモはこれらの必要性を扱います。

2.  The LPRT Command

2. LPRTコマンド

   The LPRT command allows users to specify a "long" address for the
   transport connection over which data are transferred. The LPRT
   command syntax is:

LPRTコマンドで、ユーザは「長い」アドレスをデータがわたっている輸送接続に指定できます。 LPRTコマンド構文は以下の通りです。

      LPRT <SP> <long-host-port> <CRLF>

LPRTの<のSPの>の<の長いホストポート><CRLF>。

   The <long-host-port> argument is the concatenation of the following
   fields;

<の長いホストのポートの>議論は以下の分野の連結です。

   o  an 8-bit <address-family> argument (af)

o ファミリー>を扱っている8ビットの<議論(af)

   o  an 8-bit <host-address-length> argument (hal)

o 8ビットの<ホスト長さを扱っている>議論(hal)

   o  a <host-address> of <host-address-length> (h1, h2, ...)

o <ホストアドレス長さの>の<ホスト・アドレス>。(h1、h2)

   o  an 8-bit <port-address-length> (pal)

o アドレス長さを移植している8ビットの<>。(仲間)

   o  a <port-address> of <port-address-length> (p1, p2, ...)

o <ポートアドレス長さの>の<ポートアドレス>。(p1、p2)

   The <address-family> argument takes the value of the version number
   of IP (see Assigned Numbers, STD 2, RFC 1340), or generally speaking,
   an Internet layer protocol.  Relevant assigned IPng version numbers
   are:

ファミリー>を扱っている<議論はIP(Assigned民数記を見てください、STD2、RFC1340)のバージョン番号の値、または概してインターネット層プロトコルを取ります。 関連割り当てられたIPngバージョン番号は以下の通りです。

     Decimal         Keyword
     ------          -------
     0               reserved
     1-3             unassigned
     4               Internet Protocol (IP)
     5               ST Datagram Mode
     6               SIP
     7               TP/IX
     8               PIP
     9               TUBA
     10-14           unassigned
     15              reserved

10進キーワード------ ------- 0 予約された4インターネットプロトコル(IP)標準時5データグラムMode6SIP7TP/IX8PIP9TUBA10-14が割り当てられなかった1-3は予約された15を割り当てませんでした。

Piscitello                                                      [Page 2]

RFC 1545                  FTP Over Big Address             November 1993

大きいアドレス1993年11月にわたるPiscitello[2ページ]RFC1545FTP

   The value of each field is broken into 8-bit fields and the value of
   each field is transmitted as an unsigned decimal number (in character
   string representation, note that negative numbers are explicitly not
   permitted).  The fields are separated by commas.

8ビットの野原はそれぞれの分野の値に細かく分けられます、そして、それぞれの分野の値は未署名の10進数として送られます(文字列表現で、負数が明らかに受入れられないことに注意してください)。 野原はコンマによって分離されます。

   A LPRT command is thus of the general form

LPRTコマンドはそうです、その結果、司令官では、形成してください。

      LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...

LPRT af、hal、h1、h2、h3、h4…仲間、p1、p2…

   where h1 is the high order 8 bits of the internet host address, and
   p1 is the high order 8 bits of the port number (transport address).

h1がインターネットホストの8ビットが扱う高位であり、p1がポートナンバー(輸送アドレス)の高位8ビットであるところ。

3.  The LPSV Command

3. LPSVコマンド

   The L(ONG) PASSIVE command requests the server-DTP to listen on a
   data port other than its default data port and to wait for a
   connection rather than initiate one upon receipt of a transfer
   command.  The response to this command includes the address family,
   host address length indicator, host address, port address length, and
   port address this server is listening on.  The reply code and text
   for entering the passive mode using a long address is 228
   (Interpretation according to FTP is: positive completion reply 2yz,
   connections x2z, passive mode entered using long address xy8).  The
   suggested textual message to accompany this reply code is:

L(オング)PASSIVEコマンドはデフォルトデータポート以外のデータポートの上で聴いて、転送命令を受け取り次第開始1よりむしろ接続を待つようサーバ-DTPに要求します。 このコマンドへの応答はこのサーバが聴いているアドレスファミリー、ホスト・アドレス長さのインディケータ、ホスト・アドレス、ポートアドレスの長さ、およびポートアドレスを含んでいます。 長いアドレスを使用することで受け身の形態を入れるための回答コードとテキストは228(積極的な完成回答2yz、接続x2z、FTPに従った解釈は以下の通りであり、長いアドレスxy8を使用することで受け身の形態に入った)です。 この回答コードに伴う提案された原文のメッセージは以下の通りです。

      228 Entering Long Passive Mode (af,hal,h1,h2,h3,h4...,pal,p1,p2...)

228 長い受け身の形態を入れること。(af、hal、h1、h2、h3、h4、…仲間、p1、p2)

4.  Permanent Negative Completion Reply Codes

4. 永久的な否定的完成回答コード

   The negative completion reply codes that are associated with syntax
   errors in the PORT and PASV commands are appropriate for the LPRT and
   LPSV commands (500, 501).  An additional negative completion reply
   code is needed to distinguish the case where a host supports the LPRT
   or LPSV command, but does not support the address family specified.
   Of the FTP function groupings currently defined for reply codes
   (syntax, information, connections, authentication and accounting, and
   file system), "connections" seems the most logical choice; thus, an
   additional negative command completion reply code, 521 is added, with
   the following suggested textual message:

LPRTとLPSVコマンド(500、501)に、PORTとPASVコマンドにおける構文エラーに関連している否定的完成回答コードは適切です。 追加否定的完成回答コードが、ホストがLPRTかLPSVがコマンドであるとサポートしますが、指定されたアドレスファミリーを養わないケースを区別するのに必要です。 現在回答コード(構文、情報、接続、認証、会計学、およびファイルシステム)のために定義されているFTP機能組分けでは、「接続」は最も論理的な選択に見えます。 したがって、追加否定的コマンド完成回答コード、521は加えられて、以下で、原文のメッセージは示されていました:

      521 Supported address families are (af1, af2, ..., afn)

521 サポートしているアドレスファミリーはそうです。(af1、af2、…、afn)

   Where (af1, af2, ..., afn) are the values of the version numbers of
   the "next generation" or other protocol families supported.  IP
   address noted earlier.

(af1、af2、…、afn)が「次の世代」か他のプロトコルファミリーの数がサポートしたバージョンの値であるところ。 IPアドレスは、より早いように注意しました。

Piscitello                                                      [Page 3]

RFC 1545                  FTP Over Big Address             November 1993

大きいアドレス1993年11月にわたるPiscitello[3ページ]RFC1545FTP

5.  Rationale

5. 原理

   An explicit address family argument in the LPRT command and LPSV
   reply allows the Internet community to experiment with a variety of
   "next generation IP" alternatives within a common FTP implementation
   framework.  (It also allows the use of a different address family on
   the command and data connections.)  An explicit length indicator for
   the host address is necessary because some of the IPNG alternatives
   make use of variable length addresses.  An explicit host address is
   necessary because FTP says it's necessary.

LPRTコマンドとLPSV回答における明白なアドレスファミリー議論で、インターネットコミュニティは一般的なFTP実装フレームワークの中でさまざまな「次の世代IP」選択肢を実験できます。 (また、それはコマンドとデータにおける異なったアドレスファミリーの使用に接続を許します。) IPNG代替手段のいくつかが可変長アドレスを利用するので、ホスト・アドレスのための明白な長さのインディケータが必要です。 FTPが、それが必要であると言うので、明白なホスト・アドレスが必要です。

   The decision to provide a length indicator for the port number is not
   as obvious, and certainly goes beyond the necessary condition of
   having to support TCP port numbers. Currently, at least one IPng
   alternative (TP/IX) supports longer port addresses.  And given the
   increasingly "multi-protocol" nature of the Internet, it seems
   reasonable that someone, somewhere, might wish to operate FTP operate
   over Appletalk, IPX, and OSI networks as well as TCP/IP networks.
   (In theory, FTP should operate over *any* transport protocol that
   offers the same service as TCP.) Since some of these transport
   protocols may offer transport selectors or port numbers that exceed
   16 bits, a length indicator may be desirable.  If FTP must indeed be
   changed to accommodate larger network addresses, it may be prudent to
   determine at this time whether the same flexibility is useful or
   necessary with respect to transport addresses.

長さのインディケータをポートナンバーに提供するという決定は、明白でなく、確かに、TCPにポートナンバーをサポートしなければならないという必要条件を越えます。 現在、少なくとも1つのIPng選択肢(TP/IX)が、より長いポートアドレスをサポートします。 そして、ますます「マルチプロトコル」インターネットの性質を考えて、だれかが、どこかでFTPを操作するために、TCP/IPネットワークと同様にAppletalk、IPX、およびOSIネットワークの上で作動するように願っているかもしれないのは妥当に思えます。 (理論上、FTPは*の上でTCPと同じサービスを提供するどんな*トランスポート・プロトコルも操作するべきです。) これらのトランスポート・プロトコルのいくつかが16ビットを超えている輸送セレクタかポートナンバーを提供するかもしれないので、長さのインディケータは望ましいかもしれません。 より大きいネットワーク・アドレスに対応するために本当にFTPを変えなければならないなら、このとき同じ柔軟性が輸送アドレスに関して役に立つか、または必要であるかを決定するのは慎重であるかもしれません。

6.  Conclusions

6. 結論

   The mechanism defined here is simple, extensible, and meets both IPNG
   and possibly multi-protocol internet needs.

ここで定義されたメカニズムは、簡単であって、広げることができて、IPNGとことによるとマルチプロトコルインターネットの必要性の両方を満たします。

7.  References

7. 参照

   STD 9, RFC 959  Postel, J., and J. Reynolds, "File Transfer Protocol",
                   STD 9, RFC 959, USC/Information Sciences Institute,
                   October 1985.

STD9、ポステル、J.、およびJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、USC/情報科学が1985年10月に設けるRFC959。

   STD 2, RFC 1340 Reynolds, J., and J. Postel, "Assigned Numbers",
                   STD 2, RFC 1340, USC/Information Sciences Institute,
                   July 1992.  (Does not include recently assigned IPv7
                   numbers).

STD2、レイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340、USC/情報科学が1992年7月に設けるRFC1340。 (最近割り当てられたIPv7番号を含んでいません。)

   STD 3, RFC 1123 Braden, R., Editor, "Requirements for Internet
                   Hosts - Application and Support", STD 3, RFC 1123,
                   USC/Information Sciences Institute, October 1989.

STD3、1123年のRFCブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123(科学が1989年10月に設けるUSC/情報)

Piscitello                                                      [Page 4]

RFC 1545                  FTP Over Big Address             November 1993

大きいアドレス1993年11月にわたるPiscitello[4ページ]RFC1545FTP

8.  Security Considerations

8. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

9.  Author's Address

9. 作者のアドレス

   David M. Piscitello
   Bell Communications Research
   NVC 1C322
   331 Newman Springs Road
   Red Bank, NJ 07701

Piscitelloベルコミュニケーションズ・リサーチNVC 1C322 331ニューマン春の道路赤が盛り土するデヴィッドM.、ニュージャージー 07701

   EMail: dave@mail.bellcore.com

メール: dave@mail.bellcore.com

Piscitello                                                      [Page 5]

Piscitello[5ページ]