RFC 3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3617
タイトル : RFC 3617 - 些細なファイル転送プロトコル（TFTP）のユニフォームリソース識別子（URI）スキームと適用性ステートメント
翻訳編集 : 自動生成

[要約] RFC 3617は、TFTPのURIスキームと適用性に関する規定です。TFTPを使用してファイルを転送するためのURIスキームを定義し、その適用範囲を明確にします。

Network Working Group                                            E. Lear
Request for Comments: 3617                                 Cisco Systems
Category: Informational                                     October 2003

Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)

些細なファイル転送プロトコル（TFTP）のユニフォームリソース識別子（URI）スキームと適用性ステートメント

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

Abstract

概要

The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.

些細なファイル転送プロトコル（TFTP）は、非常にシンプルな些細なプロトコルであり、かなり長い間インターネットで使用されてきました。この文書は、主にセキュリティの懸念による継続的な使用を妨げていますが、均一なリソース識別子（URI）スキームを定義し、プロトコルの適用性について説明します。

1. Introduction

1. はじめに

The Trivial File Transfer Protocol (TFTP) has been around for quite some time. Its common uses are to initially configure devices or to load new versions of operating system code [1]. As devices begin to adopt use of Uniform Resource Identifiers (URIs) and Uniform Resource Locators (URLs), for completeness we specify a way to reference files that is still quite common. Use of a URI is a convenient way to indicate underlying mechanism, server name or address, and file name.

些細なファイル転送プロトコル（TFTP）はかなり長い間存在しています。その一般的な用途は、最初にデバイスを構成するか、オペレーティングシステムコードの新しいバージョンをロードすることです[1]。デバイスがユニフォームのリソース識別子（URI）と均一なリソースロケーター（URL）の使用を採用し始めると、完全性のために、まだ非常に一般的なファイルを参照する方法を指定します。URIの使用は、基礎となるメカニズム、サーバー名またはアドレス、およびファイル名を示す便利な方法です。

WHILE WE DEFINE THE TFTP URI TYPE, WE STRONGLY RECOMMEND AGAINST THE CONTINUED USE OF TFTP, FOR REASONS LISTED IN SECTION 5 (amongst others). The definition of a URI merely allows tools that currently use protocols such as TFTP to have a standard name space and structure where one can understand the process used to resolve that name. Indeed it is hoped that the definition of this URI will ease transition to modern file transfer mechanisms.

TFTP URIタイプを定義していますが、セクション5にリストされている理由（とりわけ）に記載されているTFTPの継続的な使用に強くお勧めします。URIの定義は、現在TFTPなどのプロトコルを使用しているツールを使用して、その名前を解決するために使用されるプロセスを理解できる標準名のスペースと構造を持つだけです。実際、このURIの定義が最新のファイル転送メカニズムへの移行を容易にすることが期待されています。

2. Syntax of a TFTP URI

2. TFTP URIの構文

A TFTP URI has the following ABNF syntax [2]:

TFTP URIには、次のABNF構文があります[2]：

   tftpURI         = "tftp://" host "/" file [ mode ]
   mode            = ";"  "mode=" ( "netascii" / "octet" )
   file            = *( unreserved / escaped )
   host            = <as specified by RFC 2732 [3]>
   unreserved      = <as specified in RFC 2396 [4]>
   escaped         = <as specified in RFC 2396>

A TFTP URI specifies a file that is to be found or placed on a TFTP server. The "mode" option is an option indicating how the file is to be transferred. If left unspecified, the mode is assumed to be "octet". A third "mail" mode was deprecated at the time RFC 1350 was adopted, and is not specified.

TFTP URIは、TFTPサーバーに見つかったり配置したりするファイルを指定します。「モード」オプションは、ファイルの転送方法を示すオプションです。不特定のままにしておくと、モードは「オクテット」であると想定されます。RFC 1350が採用された時点で3番目の「メール」モードが非推奨であり、指定されていません。

2.1. Encoding Rules

2.1. エンコードルール

Aside from syntax as described above, the TFTP protocol does not specify length limits to either file names or file sizes. In the case of file names, they may contain any character so long as those characters are properly escaped as described above.

上記の構文は別として、TFTPプロトコルは、ファイル名またはファイルサイズのいずれにも長さの制限を指定しません。ファイル名の場合、上記のようにそれらの文字が適切に逃げられている限り、それらは任意の文字を含めることができます。

3. Semantics and Operations

3. セマンティクスと操作

As previously stated the TFTP URI is a reference to a file. The allowed operations on a TFTP URI are read and write. When a TFTP URI is read the underlying mechanisms retrieve the named file via the TFTP protocol from the specified host with the optionally specified mode. When a TFTP URI is written the underlying mechanisms transmit a file via TFTP to a specified server to either the specified file using the optionally specified mode. No other operations are supported.

前述のように、TFTP URIはファイルへの参照です。TFTP URIの許可操作は読み取りおよび書き込みです。TFTP URIが読み取られると、オプションの指定モードで指定されたホストからTFTPプロトコルを介して、基礎となるメカニズムが指定されたファイルを取得します。TFTP URIが書かれている場合、基礎となるメカニズムは、オプションの指定されたモードを使用して、指定されたサーバーに指定されたサーバーにファイルを指定されたサーバーに送信します。他の操作はサポートされていません。

Note that it is not possible to retrieve file size information prior to retrieval, nor is it possible to determine file existence or permissions prior to transfer. Files transferred may or may not arrive intact, as there is no guarantee of reliability or even completeness. See the TFTP standard for more details. For more robust file transfer, consider using either FTP or HTTP [5, 6].

検索前にファイルサイズの情報を取得することは不可能であり、転送前にファイルの存在または権限を決定することもできないことに注意してください。転送されたファイルは、信頼性や完全性さえ保証されていないため、無傷で到着する場合があります。詳細については、TFTP標準を参照してください。より堅牢なファイル転送については、FTPまたはHTTPのいずれかの使用を検討してください[5、6]。

4. Examples

4. 例

      tftp://example.com/myconfigurationfile;mode=netascii

This example references file "myconfigurationfile" on server "example.com" and requests that the transfer occur in netascii mode.

この例は、サーバー「example.com」でファイル「myConfigurationFile」を参照し、転送がNETASCIIモードで発生することを要求します。

tftp://example.com/mystartupfile

tftp：//example.com/mystartupfile

This file references file "mystartupfile" on server "example.com". The transfer should occur in octet mode, since no other mode was specified.

このファイルは、サーバー「example.com」でファイル「mystartupfile」を参照しています。他のモードが指定されていないため、転送はオクテットモードで発生するはずです。

5. Security Considerations and Concerns about TFTP's use

5. TFTPの使用に関するセキュリティ上の考慮事項と懸念

Use of TFTP has been historically limited to those devices where a more full protocol stack is impractical due to either memory or CPU constraints. While this still may be the case with a toaster, it is unlikely to be the case for even the simplest piece of network support hardware, such as simple routers or switches. There are a myriad of reasons to use some protocol other than TFTP, only a few of which are listed below.

TFTPの使用は、メモリまたはCPUの制約のいずれかのために、より完全なプロトコルスタックが非現実的であるデバイスに歴史的に限定されてきました。これはまだトースターの場合でもそうかもしれませんが、単純なルーターやスイッチなど、最も単純なネットワークサポートハードウェアの場合でもそうではありません。TFTP以外のプロトコルを使用するには無数の理由がありますが、そのうちのほんの一部しか以下にリストされています。

TFTP has no mechanism for access control within the protocol, and there is no protection from a man in the middle attack. Implementations are left to their own devices in this area. Because TFTP has no way to determine file sizes in advance, implementations should be prepared to properly check the bounds of transfers so that neither memory nor disk limitations are exceeded.

TFTPには、プロトコル内のアクセス制御のメカニズムがなく、中間攻撃の男性からの保護はありません。実装は、このエリアの独自のデバイスに任されています。TFTPには事前にファイルサイズを決定する方法がないため、メモリもディスクの制限も超えないように、転送の境界を適切に確認するための実装を準備する必要があります。

TFTP is not well suited to large files for the following reasons. TFTP has no inherent integrity check. There is no way to determine what one side sent is what the other received. There is no way to restart TFTP transfers from anywhere other than the beginning. TFTP is a lock step protocol. Only one packet may be in flight at any one time. There is no slow start or smart backoff mechanism in TFTP, but very simple timeouts.

TFTPは、以下の理由で大きなファイルにあまり適していません。TFTPには固有の整合性チェックはありません。一方の側が送信したものを決定する方法はありません。最初の場所からTFTP転送を再起動する方法はありません。TFTPはロックステッププロトコルです。いつでも飛行中のパケットは1つだけです。TFTPではスロースタートまたはスマートバックオフメカニズムはありませんが、非常に簡単なタイムアウトはありません。

TFTP is not well suited to file transfers across administrative domains. For one thing, TFTP utilizes UDP, and many NATs will not either support or allow TFTP transfers. More likely firewalls will prohibit transfers.

TFTPは、管理ドメイン間のファイル転送にあまり適していません。1つには、TFTPはUDPを利用し、多くのNATはTFTP転送をサポートまたは許可しません。ファイアウォールが転送を禁止する可能性が高くなります。

There are no caching semantics within TFTP. There is no safe way to cache information using the TFTP protocol.

TFTP内にキャッシュセマンティクスはありません。TFTPプロトコルを使用して情報をキャッシュする安全な方法はありません。

In summary, use of TFTP is strongly discouraged except in the most limited of circumstances where memory and CPU are at the highest premium.

要約すると、TFTPの使用は、記憶とCPUが最高のプレミアムにある状況の最も限られていることを除いて、強く落胆しています。

6. IANA Considerations

6. IANAの考慮事項

The IANA has registered the URL registration template found in Appendix A in accordance with RFC 2717 [7].

IANAは、RFC 2717 [7]に従って付録AにあるURL登録テンプレートを登録しています。

7. Acknowledgments

7. 謝辞

The author thanks Larry Masinter, Randy Presuhn, Phil Schafer, and Bill Fenner for their help in developing this document.

著者は、このドキュメントの開発に支援してくれたラリー・マシン、ランディ・プレスン、フィル・シェーファー、ビル・フェナーに感謝します。

8. Intellectual Property Statement

8. 知的財産声明

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。

Appendix A. Registration Template

付録A. 登録テンプレート

URL scheme name: tftp URL scheme syntax: Section 2 Character encoding considerations: Section 2 Intended usage: Section 1 Applications and/or protocols which use this scheme: [1] Interoperability considerations: None Security considerations: Section 5 Relevant publications: [1] Contact: The author, Section 8 Author/Change Controller: IESG

URLスキーム名：TFTP URLスキーム構文：セクション2文字エンコード考慮事項：セクション2目的使用法：セクション1アプリケーションおよび/またはプロトコルこのスキームを使用する：[1]相互運用性の考慮事項：セキュリティの考慮事項：セクション5関連出版物：[1]連絡先：著者、セクション8著者/変更コントローラー：IESG

References

参考文献

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

[1] Sollins、K。、「TFTPプロトコル（改訂2）」、STD 33、RFC 1350、1992年7月。

[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[2] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。

[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.

[3] Hinden、R.、Carpenter、B。and L. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。

[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[4] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。

[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[5] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。

[6] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.

[6] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。

[7] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.

[7] Petke、R。およびI. King、「URLスキーム名の登録手順」、BCP 35、RFC 2717、1999年11月。

Author's Address

著者の連絡先

Eliot Lear Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134-1706

Eliot Lear Cisco Systems、Inc。170 W. Tasman Dr. San Jose、CA 95134-1706

   Phone: +1 (408) 527 4020
   EMail: lear@cisco.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 assignees.

上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。

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.

このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。