[要約] RFC 7440は、TFTPプロトコルにおけるWindowsizeオプションの仕様を定義しています。このオプションは、TFTPのパフォーマンスを向上させるために、ウィンドウサイズを調整するために使用されます。
Internet Engineering Task Force (IETF) P. Masotta
Request for Comments: 7440 Serva
Category: Standards Track January 2015
ISSN: 2070-1721
TFTP Windowsize Option
TFTP Windowsizeオプション
Abstract
概要
The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.
"Trivial File Transfer Protocol"（RFC 1350）は、クライアントがリモートホストでファイルを取得または配置できるようにする、単純なロックステップのファイル転送プロトコルです。その主な用途の1つは、ローカルエリアネットワーク（LAN）から起動するノードの初期段階です。 TFTPは、実装が非常に簡単なため、このアプリケーションに使用されています。ロックステップ方式を採用すると、LANで使用した場合のスループットが制限されます。
This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension" (RFC 2347).
このドキュメントでは、単一ブロックのロックステップスキーマを置き換える代わりに、クライアントとサーバーが送信する連続ブロックのウィンドウサイズをネゴシエートできるようにするTFTPオプションについて説明します。採用されているTFTPオプションメカニズムについては、「TFTPオプション拡張」（RFC 2347）で説明しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7440.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7440で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Windowsize Option Specification .................................3
4. Traffic Flow and Error Handling .................................4
5. Proof of Concept and Windowsize Evaluation ......................6
6. Congestion and Error Control ....................................7
7. Security Considerations .........................................8
8. References ......................................................9
8.1. Normative References .......................................9
Author's Address ...................................................9
TFTP is virtually unused for Internet transfers today, TFTP is still massively used in network boot/installation scenarios including EFI (Extensible Firmware Interface). TFTP's inherently low transfer rate has been, so far, partially mitigated by the use of the blocksize negotiated extension [RFC2348]. Using this method, the original limitation of 512-byte blocks are, in practice, replaced in Ethernet environments by blocks no larger than 1468 Bytes to avoid IP block fragmentation. This strategy produces insufficient results when transferring big files, for example, the initial ramdisk of Linux distributions or the PE images used in network installations by Microsoft WDS/MDT/SCCM. Considering TFTP looks far from extinction today, this document presents a negotiated extension, under the terms of the "TFTP Option Extension" [RFC2347], that produces TFTP transfer rates comparable to those achieved by modern file transfer protocols.
TFTPは、今日のインターネット転送では事実上使用されていません。TFTPは、EFI（拡張ファームウェアインターフェイス）を含むネットワークブート/インストールシナリオで今でも広く使用されています。これまでのところ、TFTPの本質的に低い転送速度は、ブロックサイズネゴシエートされた拡張[RFC2348]の使用によって部分的に軽減されています。この方法を使用すると、実際には、512バイトブロックの元の制限は、イーサネット環境では、IPブロックの断片化を回避するために1468バイト以下のブロックに置き換えられます。この戦略では、大きなファイル、たとえばLinuxディストリビューションの初期RAMディスクや、Microsoft WDS / MDT / SCCMによるネットワークインストールで使用されるPEイメージを転送するときに、不十分な結果が生じます。 TFTPが今日の絶滅から遠く離れていることを考えると、このドキュメントは、「TFTPオプション拡張」[RFC2347]の条件に基づいて交渉された拡張を示し、最新のファイル転送プロトコルによって達成されるものに匹敵するTFTP転送速度を生成します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying the significance given in RFC 2119.
このドキュメントでは、これらの単語はすべて大文字の場合にのみその解釈で表示されます。これらの単語の小文字の使用は、RFC 2119で指定された重要性を持つと解釈されるべきではありません。
The TFTP Read Request or Write Request packet is modified to include the windowsize option as follows. Note that all fields except "opc" MUST be ASCII strings followed by a single-byte NULL character.
TFTP読み取り要求または書き込み要求パケットは、次のようにwindowsizeオプションを含むように変更されています。 「opc」以外のすべてのフィールドは、ASCII文字列で、その後に1バイトのNULL文字が続く必要があることに注意してください。
2B string 1B string 1B string 1B string 1B
+-------+---~~---+----+---~~---+----+-----~~-----+----+---~~---+----+
| opc |filename| 0 | mode | 0 | windowsize | 0 | #blocks| 0 |
+-------+---~~---+----+---~~---+----+-----~~-----+----+---~~---+----+
opc The opcode field contains either a 1 for Read Requests or a 2 for Write Requests, as defined in [RFC1350].
opc opcodeフィールドには、[RFC1350]で定義されているように、読み取り要求の場合は1、書き込み要求の場合は2が含まれます。
filename The name of the file to be read or written, as defined in [RFC1350].
filename [RFC1350]で定義されている、読み書きされるファイルの名前。
mode The mode of the file transfer: "netascii", "octet", or "mail", as defined in [RFC1350].
mode [RFC1350]で定義されているように、ファイル転送のモード： "netascii"、 "octet"、または "mail"。
windowsize The windowsize option, "windowsize" (case insensitive).
windowsize windowsizeオプション、 "windowsize"（大文字と小文字は区別されません）。
#blocks The base-10 ASCII string representation of the number of blocks in a window. The valid values range MUST be between 1 and 65535 blocks, inclusive. The windowsize refers to the number of consecutive blocks transmitted before stopping and waiting for the reception of the acknowledgment of the last block transmitted.
#blocksウィンドウ内のブロック数の10進数のASCII文字列表現。有効な値の範囲は、1〜65535ブロックである必要があります。 windowsizeは、最後に送信されたブロックの確認応答の受信を停止して待機する前に送信される連続ブロックの数を指します。
For example:
例えば：
+------+--------+----+-------+----+------------+----+----+----+
|0x0001| foobar |0x00| octet |0x00| windowsize |0x00| 16 |0x00|
+------+--------+----+-------+----+------------+----+----+----+
is a Read Request for the file named "foobar" in octet transfer mode with a windowsize of 16 blocks (option blocksize is not negotiated in this example, the default of 512 Bytes per block applies).
ウィンドウサイズが16ブロックのオクテット転送モードの「foobar」という名前のファイルの読み取り要求です（この例ではオプションのブロックサイズはネゴシエートされていません。ブロックごとにデフォルトの512バイトが適用されます）。
If the server is willing to accept the windowsize option, it sends an Option Acknowledgment (OACK) to the client. The specified value MUST be less than or equal to the value specified by the client. The client MUST then either use the size specified in the OACK or send an ERROR packet, with error code 8, to terminate the transfer.
サーバーがwindowsizeオプションを受け入れる用意がある場合、サーバーはOption Acknowledgement（OACK）をクライアントに送信します。指定された値は、クライアントによって指定された値以下でなければなりません。次に、クライアントはOACKで指定されたサイズを使用するか、エラーコード8のERRORパケットを送信して、転送を終了する必要があります。
The rules for determining the final packet are unchanged from [RFC1350] and [RFC2348].
最終パケットを決定するためのルールは、[RFC1350]と[RFC2348]から変更されていません。
The reception of a data window with a number of blocks less than the negotiated windowsize is the final window. If the windowsize is greater than the amount of data to be transferred, the first window is the final window.
最終的なウィンドウは、ネゴシエートされたウィンドウサイズよりも少ないブロック数のデータウィンドウの受信です。 windowsizeが転送されるデータの量より大きい場合、最初のウィンドウが最後のウィンドウです。
The next diagram depicts a section of the traffic flow between the Data Sender (DSND) and the Data Receiver (DRCV) parties on a generic windowsize TFTP file transfer.
次の図は、一般的なウィンドウサイズのTFTPファイル転送における、データ送信側（DSND）とデータ受信側（DRCV）の間のトラフィックフローのセクションを示しています。
The DSND MUST cyclically send to the DRCV the agreed windowsize consecutive data blocks before normally stopping and waiting for the ACK of the transferred window. The DRCV MUST send to the DSND the ACK of the last data block of the window in order to confirm a successful data block window reception.
DSNDは、転送されたウィンドウのACKを通常停止して待機する前に、合意されたウィンドウサイズの連続したデータブロックをDRCVに周期的に送信する必要があります。 DRCVは、データブロックウィンドウが正常に受信されたことを確認するために、ウィンドウの最後のデータブロックのACKをDSNDに送信する必要があります。
In the case of an expected ACK not timely reaching the DSND (timeout), the last received ACK SHALL set the beginning of the next windowsize data block window to be sent.
予期されたACKがDSND（タイムアウト）にタイムリーに到達しない場合、最後に受信されたACKは、送信される次のwindowsizeデータブロックウィンドウの開始を設定する必要があります（SHALL）。
In the case of a data block sequence error, the DRCV SHOULD notify the DSND by sending an ACK corresponding to the last data block correctly received. The notified DSND SHOULD send a new data block window whose beginning MUST be set based on the ACK received out of sequence.
データブロックシーケンスエラーの場合、DRCVは、正しく受信された最後のデータブロックに対応するACKを送信することにより、DSNDに通知する必要があります（SHOULD）。通知されたDSNDは、シーケンスから受信したACKに基づいて開始を設定する必要がある新しいデータブロックウィンドウを送信する必要があります（SHOULD）。
Traffic with windowsize = 1 MUST be equivalent to traffic specified by [RFC1350].
windowsize = 1のトラフィックは、[RFC1350]で指定されたトラフィックと同等でなければなりません。
For normative traffic not specifically addressed in this section, please refer to [RFC1350] and its updates.
このセクションで特に取り上げられていない規範的なトラフィックについては、[RFC1350]とその更新を参照してください。
[ DRCV ] <---traffic---> [ DSND ]
ACK# -> <- Data Block# window block#
...
<- |DB n+01| 1
<- |DB n+02| 2
<- |DB n+03| 3
<- |DB n+04| 4
|ACK n+04| ->
<- |DB n+05| 1
Error |<- |DB n+06| 2
<- |DB n+07| 3
|ACK n+05| ->
<- |DB n+06| 1
<- |DB n+07| 2
<- |DB n+08| 3
<- |DB n+09| 4
|ACK n+09| ->
<- |DB n+10| 1
Error |<- |DB n+11| 2
<- |DB n+12| 3
|ACK n+10| ->| Error
<- |DB n+13| 4
- timeout -
<- |DB n+10| 1
<- |DB n+11| 2
<- |DB n+12| 3
<- |DB n+13| 4
|ACK n+13| ->
...
Section of a Windowsize = 4 TFTP Transfer Including Errors and Error Recovery
Windowsizeのセクション=エラーとエラー回復を含む4 TFTP転送
Performance tests were run on the prototype implementation using a variety of windowsizes and a fixed blocksize of 1456 bytes. The tests were run on a lightly loaded Gigabit Ethernet, between two Toshiba Tecra Core 2 Duo 2.2 Ghz laptops, in "octet" mode, transferring a 180 MByte file.
さまざまなウィンドウサイズと1456バイトの固定ブロックサイズを使用して、プロトタイプ実装でパフォーマンステストを実行しました。テストは、2つのToshiba Tecra Core 2 Duo 2.2 Ghzラップトップの間の負荷の軽いギガビットイーサネット上で「オクテット」モードで実行され、180 MByteファイルを転送しました。
^
|
300 +
Seconds | windowsize | time (s)
| ---------- ------
| x 1 257
250 + 2 131
| 4 76
| 8 54
| 16 42
200 + 32 38
| 64 35
|
|
150 +
|
| x
|
100 +
|
| x
|
50 + x
| x
| x x
|
0 +-//--+-----+-----+-----+-----+-----+-----+-->
1 2 4 8 16 32 64
Windowsize (in Blocks of 1456 Bytes)
ウィンドウサイズ（1456バイトのブロック）
Comparatively, the same 180 MB transfer performed over a drive mapped on Server Message Block (SMB) / Common Internet File System (CIFS) on the same scenario took 23 seconds.
比較すると、同じシナリオでサーバーメッセージブロック（SMB）/共通インターネットファイルシステム（CIFS）にマップされたドライブ上で実行された同じ180 MBの転送には23秒かかりました。
The comparison of transfer times (without a gateway) between the standard lockstep schema and the negotiated windowsizes are:
標準ロックステップスキーマとネゴシエートされたウィンドウサイズの間の転送時間（ゲートウェイなし）の比較は次のとおりです。
Windowsize | Time Reduction (%)
---------- -----------------
1 -0%
2 -49%
4 -70%
8 -79%
16 -84%
32 -85%
64 -86%
The transfer time decreases with the use of a windowed schema. The reason for the reduction in time is the reduction in the number of the required synchronous acknowledgements exchanged.
ウィンドウ化されたスキーマを使用すると、転送時間が短縮されます。時間を短縮する理由は、必要な同期確認応答の交換数が減少するためです。
The choice of appropriate windowsize values on a particular scenario depends on the underlying networking technology and topology, and likely other factors as well. Operators SHOULD test various values and SHOULD be conservative when selecting a windowsize value because as the former table and chart shows, there is a point where the benefit of continuing to increase the windowsize is subject to diminishing returns.
特定のシナリオでの適切なウィンドウサイズ値の選択は、基盤となるネットワーキングテクノロジーとトポロジー、および他の可能性のある要因にも依存します。演算子はさまざまな値をテストする必要があります。また、前の表とグラフが示すように、ウィンドウサイズを増やし続けると利益が減少する場合があるため、ウィンドウサイズの値を選択する際は慎重に行う必要があります。
From a congestion control (CC) standpoint, the number of blocks in a window does not pose an intrinsic threat to the ability of intermediate devices to signal congestion through drops. The rate at which TFTP UDP datagrams are sent SHOULD follow the CC guidelines in Section 3.1 of [RFC5405].
輻輳制御（CC）の観点からは、ウィンドウ内のブロック数は、中間デバイスがドロップを介して輻輳を通知する能力に本質的な脅威をもたらすものではありません。 TFTP UDPデータグラムが送信される速度は、[RFC5405]のセクション3.1のCCガイドラインに従う必要があります。
From an error control standpoint, while [RFC1350] and subsequent updates do not specify a circuit breaker (CB), existing implementations have always chosen to fail under certain circumstances. Implementations SHOULD always set a maximum number of retries for datagram retransmissions, imposing an appropriate threshold on error recovery attempts, after which a transfer SHOULD always be aborted to prevent pathological retransmission conditions.
エラー制御の観点から、[RFC1350]以降の更新ではサーキットブレーカー（CB）が指定されていませんが、既存の実装では、特定の状況で常に失敗するように選択されています。実装は常に、データグラム再送信の最大再試行回数を設定し、エラー回復の試行に適切なしきい値を課します。その後、病理学的再送信状態を防ぐために転送を常に中止する必要があります（SHOULD）。
An implementation example scaled for an Ethernet environment (1 Gbit/s, MTU=1500) would be to set:
イーサネット環境（1 Gbit / s、MTU = 1500）に合わせて調整された実装例は、次のように設定します。
windowsize = 8 blksize = 1456 maximum retransmission attempts per block/window = 6 timeout between retransmissions = 1 S minimum inter-packet delay = 80 uS
windowsize = 8 blksize = 1456ブロックあたりの最大再送信試行回数=ウィンドウ= 6再送信間のタイムアウト= 1 S最小パケット間遅延= 80 uS
Implementations might well choose other values based on expected and/or tested operating conditions.
実装は、予想される、またはテストされた動作条件に基づいて、他の値を選択することもできます。
TFTP includes no login or access control mechanisms. Care must be taken when using TFTP for file transfers where authentication, access control, confidentiality, or integrity checking are needed. Note that those security services could be supplied above or below the layer at which TFTP runs. Care must also be taken in the rights granted to a TFTP server process so as not to violate the security of the server's file system. TFTP is often installed with controls such that only files that have public read access are available via TFTP. Also listing, deleting, renaming, and writing files via TFTP are typically disallowed. TFTP file transfers are NOT RECOMMENDED where the inherent protocol limitations could raise insurmountable liability concerns.
TFTPには、ログインまたはアクセス制御メカニズムは含まれていません。認証、アクセス制御、機密性、または整合性チェックが必要なファイル転送にTFTPを使用する場合は注意が必要です。これらのセキュリティサービスは、TFTPが実行される層の上または下に提供できることに注意してください。また、サーバーのファイルシステムのセキュリティを侵害しないように、TFTPサーバープロセスに付与される権利にも注意を払う必要があります。 TFTPは多くの場合、TFTPを介して公開読み取りアクセスを持つファイルのみが利用できるように制御されてインストールされます。また、TFTPを介したファイルの一覧表示、削除、名前変更、および書き込みも、通常は許可されていません。 TFTPファイル転送は、固有のプロトコル制限が乗り越えられない責任の懸念を引き起こす可能性がある場合は推奨されません。
TFTP includes no protection against an on-path attacker; care must be taken in controlling windowsize values according to data sender, data receiver, and network environment capabilities. TFTP service is frequently associated with bootstrap and initial provisioning activities; servers in such an environment are in a position to impose device or network specific throughput limitations as appropriate.
TFTPには、パス上の攻撃者に対する保護は含まれていません。データ送信者、データ受信者、およびネットワーク環境の機能に応じてウィンドウサイズの値を制御する際には注意が必要です。 TFTPサービスは、ブートストラップおよび初期プロビジョニングアクティビティに頻繁に関連付けられています。このような環境のサーバーは、デバイスまたはネットワーク固有のスループット制限を適切に課すことができます。
This document does not add any security controls to TFTP; however, the specified extension does not pose additional security risks either.
このドキュメントでは、TFTPにセキュリティ制御を追加していません。ただし、指定された拡張子は、追加のセキュリティリスクももたらしません。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992, <http://www.rfc-editor.org/info/rfc1350>.
[RFC1350] Sollins、K。、「The TFTP Protocol（Revision 2）」、STD 33、RFC 1350、1992年7月、<http://www.rfc-editor.org/info/rfc1350>。
[RFC2347] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC 2347, May 1998, <http://www.rfc-editor.org/info/rfc2347>.
[RFC2347] Malkin、G。およびA. Harkin、「TFTP Option Extension」、RFC 2347、1998年5月、<http://www.rfc-editor.org/info/rfc2347>。
[RFC2348] Malkin, G. and A. Harkin, "TFTP Blocksize Option", RFC 2348, May 1998, <http://www.rfc-editor.org/info/rfc2348>.
[RFC2348] Malkin、G。およびA. Harkin、「TFTP Blocksize Option」、RFC 2348、1998年5月、<http://www.rfc-editor.org/info/rfc2348>。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月、<http://www.rfc-editor.org/info/rfc5405>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
Author's Address
著者のアドレス
Patrick Masotta Serva
パトリック・マソッタ・サーヴァント
EMail: patrick.masotta.ietf@vercot.com
URI: http://www.vercot.com/~serva/