RFC 2347 - TFTP Option Extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2347
タイトル : RFC 2347 - TFTPオプション拡張
翻訳編集 : 自動生成

[要約] RFC 2347は、TFTP（Trivial File Transfer Protocol）のオプション拡張に関する仕様です。このRFCの目的は、TFTPプロトコルに新しいオプションを追加するためのフレームワークを提供することです。

Network Working Group                                          G. Malkin
Request for Commments: 2347                                 Bay Networks
Updates: 1350                                                  A. Harkin
Obsoletes: 1782                                      Hewlett Packard Co.
Category: Standards Track                                       May 1998

TFTP Option Extension

TFTPオプション拡張

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.

Trivial File Transfer Protocol [1]は、クライアントがリモートホストにファイルを取得または配置できるようにする、シンプルなロックステップのファイル転送プロトコルです。このドキュメントでは、ファイル転送前のオプションネゴシエーションを可能にするTFTPの簡単な拡張について説明します。

Introduction

はじめに

The option negotiation mechanism proposed in this document is a backward-compatible extension to the TFTP protocol. It allows file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's Request Packet format. The mechanism is kept simple by enforcing a request-respond-acknowledge sequence, similar to the lock-step approach taken by TFTP itself.

このドキュメントで提案されているオプションネゴシエーションメカニズムは、TFTPプロトコルに対する下位互換性のある拡張です。 TFTPの要求パケット形式と一致するメカニズムを使用して、転送前にファイル転送オプションをネゴシエートできます。このメカニズムは、TFTP自体が採用するロックステップアプローチと同様に、要求/応答/確認シーケンスを実施することでシンプルに保たれています。

While the option negotiation mechanism is general purpose, in that many types of options may be negotiated, it was created to support the Blocksize option defined in [2]. Additional options are defined in [3].

オプションネゴシエーションメカニズムは汎用的なものですが、多くのタイプのオプションがネゴシエートされる可能性があるため、[2]で定義されているBlocksizeオプションをサポートするために作成されました。追加のオプションは[3]で定義されています。

Packet Formats

パケットフォーマット

TFTP options are appended to the Read Request and Write Request packets. A new type of TFTP packet, the Option Acknowledgment (OACK), is used to acknowledge a client's option negotiation request. A new error code, 8, is hereby defined to indicate that a transfer should be terminated due to option negotiation.

TFTPオプションは、読み取り要求パケットと書き込み要求パケットに追加されます。新しいタイプのTFTPパケットであるOption Acknowledgment（OACK）は、クライアントのオプションネゴシエーション要求を確認するために使用されます。これにより、オプションのネゴシエーションのために転送を終了する必要があることを示すために、新しいエラーコード8が定義されます。

Options are appended to a TFTP Read Request or Write Request packet as follows:

オプションは、TFTP読み取り要求または書き込み要求パケットに次のように追加されます。

      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
      |  opc  |filename| 0 |  mode  | 0 |  opt1  | 0 | value1 | 0 | <
      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->

       >-------+---+---~~---+---+
      <  optN  | 0 | valueN | 0 |
       >-------+---+---~~---+---+

opc The opcode field contains either a 1, for Read Requests, or 2, for Write Requests, as defined in [1].

opc opcodeフィールドには、[1]で定義されているように、読み取り要求の場合は1、書き込み要求の場合は2が含まれます。

filename The name of the file to be read or written, as defined in [1]. This is a NULL-terminated field.

filename [1]で定義されている、読み書きするファイルの名前。これは、NULLで終了するフィールドです。

mode The mode of the file transfer: "netascii", "octet", or "mail", as defined in [1]. This is a NULL-terminated field.

mode [1]で定義されているように、ファイル転送のモード： "netascii"、 "octet"、または "mail"。これは、NULLで終了するフィールドです。

opt1 The first option, in case-insensitive ASCII (e.g., blksize). This is a NULL-terminated field.

opt1大文字と小文字を区別しないASCII（blksizeなど）の最初のオプション。これは、NULLで終了するフィールドです。

value1 The value associated with the first option, in case-insensitive ASCII. This is a NULL-terminated field.

value1最初のオプションに関連付けられた値（大文字と小文字を区別しないASCII）。これは、NULLで終了するフィールドです。

optN, valueN The final option/value pair. Each NULL-terminated field is specified in case-insensitive ASCII.

optN、valueN最後のオプションと値のペア。 NULLで終了する各フィールドは、大文字と小文字を区別しないASCIIで指定されます。

The options and values are all NULL-terminated, in keeping with the original request format. If multiple options are to be negotiated, they are appended to each other. The order in which options are specified is not significant. The maximum size of a request packet is 512 octets.

オプションと値はすべて、元のリクエスト形式に従って、NULLで終了します。複数のオプションが交渉される場合、それらは互いに追加されます。オプションが指定される順序は重要ではありません。要求パケットの最大サイズは512オクテットです。

The OACK packet has the following format:

PACKパケットの形式は次のとおりです。

      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
      |  opc  |  opt1  | 0 | value1 | 0 |  optN  | 0 | valueN | 0 |
      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

opc The opcode field contains a 6, for Option Acknowledgment.

opc opcodeフィールドには、オプション確認のための6が含まれます。

opt1 The first option acknowledgment, copied from the original request.

opt1元のリクエストからコピーされた最初のオプション確認。

value1 The acknowledged value associated with the first option. If and how this value may differ from the original request is detailed in the specification for the option.

value1最初のオプションに関連付けられている確認済みの値。この値が元のリクエストと異なる場合とその方法については、オプションの仕様で詳しく説明しています。

optN, valueN The final option/value acknowledgment pair.

optN、valueN最後のオプションと値の確認のペア。

Negotiation Protocol

交渉プロトコル

The client appends options at the end of the Read Request or Write request packet, as shown above. Any number of options may be specified; however, an option may only be specified once. The order of the options is not significant.

上記のように、クライアントは読み取り要求または書き込み要求パケットの最後にオプションを追加します。オプションはいくつでも指定できます。ただし、オプションは1回しか指定できません。オプションの順序は重要ではありません。

If the server supports option negotiation, and it recognizes one or more of the options specified in the request packet, the server may respond with an Options Acknowledgment (OACK). Each option the server recognizes, and accepts the value for, is included in the OACK. Some options may allow alternate values to be proposed, but this is an option specific feature. The server must not include in the OACK any option which had not been specifically requested by the client; that is, only the client may initiate option negotiation. Options which the server does not support should be omitted from the OACK; they should not cause an ERROR packet to be generated. If the value of a supported option is invalid, the specification for that option will indicate whether the server should simply omit the option from the OACK, respond with an alternate value, or send an ERROR packet, with error code 8, to terminate the transfer.

サーバーがオプションネゴシエーションをサポートし、要求パケットで指定された1つ以上のオプションを認識する場合、サーバーはオプション確認応答（OACK）で応答する場合があります。サーバーが認識し、値を受け入れる各オプションは、OACKに含まれています。一部のオプションでは代替値を提案できますが、これはオプション固有の機能です。サーバーは、クライアントから明示的に要求されなかったオプションをOACKに含めてはなりません。つまり、クライアントのみがオプションのネゴシエーションを開始できます。サーバーがサポートしていないオプションはOACKから除外する必要があります。 ERRORパケットが生成されることはありません。サポートされているオプションの値が無効な場合、そのオプションの指定は、サーバーがOACKからオプションを単に省略するか、代替値で応答するか、またはエラーコード8でERRORパケットを送信して転送を終了するかを示します。

An option not acknowledged by the server must be ignored by the client and server as if it were never requested. If multiple options were requested, the client must use those options which were acknowledged by the server and must not use those options which were not acknowledged by the server.

サーバーによって確認されないオプションは、要求されなかったかのように、クライアントとサーバーによって無視される必要があります。複数のオプションが要求された場合、クライアントはサーバーによって確認されたオプションを使用する必要があり、サーバーによって確認されなかったオプションを使用してはなりません。

When the client appends options to the end of a Read Request packet, three possible responses may be returned by the server:

クライアントが読み取り要求パケットの最後にオプションを追加すると、サーバーから次の3つの応答が返される場合があります。

OACK - acknowledge of Read Request and the options;

OACK-読み取り要求とオプションの確認。

DATA - acknowledge of Read Request, but not the options;

DATA-読み取り要求を確認しますが、オプションは確認しません。

ERROR - the request has been denied.

エラー-リクエストは拒否されました。

When the client appends options to the end of a Write Request packet, three possible responses may be returned by the server:

クライアントが書き込み要求パケットの最後にオプションを追加すると、サーバーから次の3つの応答が返される場合があります。

OACK - acknowledge of Write Request and the options;

OACK-書き込み要求とオプションの確認。

ACK - acknowledge of Write Request, but not the options;

ACK-書き込み要求の確認応答ですが、オプションは確認しません。

ERROR - the request has been denied.

エラー-リクエストは拒否されました。

If a server implementation does not support option negotiation, it will likely ignore any options appended to the client's request. In this case, the server will return a DATA packet for a Read Request and an ACK packet for a Write Request establishing normal TFTP data transfer. In the event that a server returns an error for a request which carries an option, the client may attempt to repeat the request without appending any options. This implementation option would handle servers which consider extraneous data in the request packet to be erroneous.

サーバーの実装がオプションのネゴシエーションをサポートしていない場合、クライアントのリクエストに追加されたオプションは無視される可能性があります。この場合、サーバーは通常のTFTPデータ転送を確立するために、読み取り要求のDATAパケットと書き込み要求のACKパケットを返します。サーバーがオプションを含むリクエストに対してエラーを返した場合、クライアントはオプションを追加せずにリクエストを繰り返し試行する場合があります。この実装オプションは、要求パケット内の無関係なデータが誤っていると見なすサーバーを処理します。

Depending on the original transfer request there are two ways for a client to confirm acceptance of a server's OACK. If the transfer was initiated with a Read Request, then an ACK (with the data block number set to 0) is sent by the client to confirm the values in the server's OACK packet. If the transfer was initiated with a Write Request, then the client begins the transfer with the first DATA packet, using the negotiated values. If the client rejects the OACK, then it sends an ERROR packet, with error code 8, to the server and the transfer is terminated.

元の転送要求に応じて、クライアントがサーバーのOACKの受け入れを確認する方法は2つあります。読み取り要求で転送が開始された場合、サーバーからOACKパケットの値を確認するために、ACK（データブロック番号を0に設定）がクライアントから送信されます。転送が書き込み要求で開始された場合、クライアントはネゴシエートされた値を使用して、最初のDATAパケットで転送を開始します。クライアントがOACKを拒否すると、クライアントはエラーコード8のERRORパケットをサーバーに送信し、転送が終了します。

Once a client acknowledges an OACK, with an appropriate non-error response, that client has agreed to use only the options and values returned by the server. Remember that the server cannot request an option; it can only respond to them. If the client receives an OACK containing an unrequested option, it should respond with an ERROR packet, with error code 8, and terminate the transfer.

クライアントがOACKを確認し、適切なエラー以外の応答を返すと、そのクライアントはサーバーから返されたオプションと値のみを使用することに同意したことになります。サーバーはオプションを要求できないことに注意してください。それだけに応答できます。クライアントが要求されていないオプションを含むOACKを受信した場合、クライアントは、エラーコード8のERRORパケットで応答し、転送を終了する必要があります。

Examples

例

Read Request

読み取りリクエスト

      client                                           server
      -------------------------------------------------------
      |1|foofile|0|octet|0|blksize|0|1432|0|  -->               RRQ
                                    <--  |6|blksize|0|1432|0|   OACK
      |4|0|  -->                                                ACK
                             <--  |3|1| 1432 octets of data |   DATA
      |4|1|  -->                                                ACK
                             <--  |3|2| 1432 octets of data |   DATA
      |4|2|  -->                                                ACK
                             <--  |3|3|<1432 octets of data |   DATA
      |4|3|  -->                                                ACK

Write Request

書き込みリクエスト

      client                                           server
      -------------------------------------------------------
      |2|barfile|0|octet|0|blksize|0|2048|0|  -->               RRQ
                                    <--  |6|blksize|0|2048|0|   OACK
      |3|1| 2048 octets of data |  -->                          DATA
                                                   <--  |4|1|   ACK
      |3|2| 2048 octets of data |  -->                          DATA
                                                   <--  |4|2|   ACK
      |3|3|<2048 octets of data |  -->                          DATA
                                                      <--  |4|3|   ACK

Security Considerations

セキュリティに関する考慮事項

The basic TFTP protocol has no security mechanism. This is why it has no rename, delete, or file overwrite capabilities. This document does not add any security to TFTP; however, the specified extensions do not add any additional security risks.

基本的なTFTPプロトコルにはセキュリティメカニズムがありません。これが、名前の変更、削除、またはファイルの上書き機能がない理由です。このドキュメントはTFTPにセキュリティを追加しません。ただし、指定された拡張機能によってセキュリティリスクが増えることはありません。

References

参考文献

[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, October 1992.

[1] Sollins、K。、「The TFTP Protocol（Revision 2）」、STD 33、RFC 1350、1992年10月。

[2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348, May 1998.

[2] Malkin、G。、およびA. Harkin、「TFTP Blocksize Option」、RFC 2348、1998年5月。

[3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size Options", RFC 2349, May 1998.

[3] Malkin、G。、およびA. Harkin、「TFTPタイムアウト間隔および転送サイズオプション」、RFC 2349、1998年5月。

Authors' Addresses

著者のアドレス

Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821

Gary Scott Malkin Bay Networks 8 Federal Street Billerica、MA 01821

Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com

電話：（978）916-4237メール：gmalkin@baynetworks.com

Art Harkin Internet Services Project Information Networks Division 19420 Homestead Road MS 43LN Cupertino, CA 95014

アートハーキンインターネットサービスプロジェクト情報ネットワーク部門19420ホームステッドロードMS 43LNクパチーノ、カリフォルニア95014

Phone: (408) 447-3755 EMail: ash@cup.hp.com

電話：（408）447-3755メール：ash@cup.hp.com

Full Copyright Statement

完全な著作権表示

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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。