訳: 岡橋 一輝 最終更新日: 1999/12/17 --- Network Working Group K. Sollins Request For Comments: 1350 MIT STD: 33 July 1992 Obsoletes: 783 The TFTP Protocol (Revision 2) 簡易ファイル転送プロトコル(改訂 2 版) 本書の位置付け(Status of this Memo) この RFC はインターネット共同体のために IAB の標準化過程プロトコルに ついて記してあり、改善に向けての議論や提案を求めるものである。このプロ トコルの標準化の現状については、IAB Official Protocol Standards の最新 版を参照されたい。本書の配布は無制限に行ってよい。 要約(Summary) TFTP はファイル転送のための非常に単純なプロトコルである。その特徴を 鑑みて、プロトコルの名称を「簡易ファイル転送プロトコル」略して TFTP と する。非終端の各パケットは別々に確認応答する。本書ではプロトコルとその パケットフォーマットについて記述し、設計に踏み切った背景と理由について も説明する。 謝辞(Acknowlegements) TFTP は元々 Noel Chiappa が設計したものだが、その後 Steve Szymanski のコメントをきっかけとして、彼自身と Bob Baldwin、それに Dave Clark の 3名によって再設計された。本書の最新版には、Larry Allen、Noel Chiappa Dave Clark、Geoff Cooper、Mike Greenwald、Liza Martin、David Reed、 Craig Milo Rogers、Kathy Yellick、それに著者らの提案や議論を受けて修正 が施されている。確認応答及び再送の仕組みは TCP の手法を踏襲し、エラー 処理の仕組みについては PARC による EFTP の abrot メッセージより示唆を 受けた。 [RFC1123] で触れられている「魔術師の弟子」バグや、その他些細な問題点 の修正は、1992/5 の改訂で Noel Chiappa が行った。 この研究は米国防総省の ARPA によって支援され、作業番号 N00014-75-C- 0661 として Office of Naval Research の監督を受けた。 1. 目的(Purpose) TFTP はファイル転送を目的とした単純なプロトコルであり、その特徴から 簡易ファイル転送プロトコル、略して TFTP と命名された。TFTP は今までデ ータグラムプロトコル [UDP] の上位に実装されてきたので、別々のネットワ ークに属しているマシン同士でも、UDP を実装していればファイル転送が可能 になる(とは言っても、UDP 以外のデータグラムプロトコルにおける TFTP の 実装可能性を排除すべきではない)。TFTP は規模が小さく実装が容易な様に 設計されているので、FTP が具えている特徴の多くは利用できない。TFTP で 利用可能なのは、ファイル(やメイル)を遠隔サーバに読み書きする機能だけ である。ディレクトリの一覧取得などはできないし、今のところユーザ認証さ え不可能である。また、他のインターネットプロトコルと同様に、TFTP も 8 ビット単位でデータの受け渡しを行う。 現在、TFTP には三種類の転送モードが存在する: 1. netascii これは [USASI X3.4-1968] に定められている ascii コードのことで、 [RFC764] に記された修正事項を含むものとする。このコードは 8 ビッ ト ascii であることに注意されたい。本文書を通じて、netascii とは この 8 ビット特別版 ascii を指すものとする。 2. octet 過去の版でバイナリと呼ばれていたモードに相当する。無変換の 8 ビ ットコードそのままである。 3. mail netascii 文字を、ファイルとしてではなくユーザに直接送信するモー ド。このモードは廃止するので、実装・使用しないこと。 これ以外にも、ホスト間の合意を経ればモードの追加定義が可能である。 TFTP に関するこれ以上に有益な推奨や提案については、[RFC1123] を一読 されたい。 2. TFTP の概観(Overview of the Protocol) いかなる転送も、ファイルの読み書き要求をもって開始とする。最初の読み 書き要求は、同時にコネクション確立要求の役割も果たす。サーバが要求を認 めるとコネクションが確立し、512 バイトの固定長ブロックでファイル転送が 可能になる。各パケットはひとつのデータブロックを含んでおり、次のパケッ トを送信する前に確認応答しなければならない。512 バイト未満のパケットが 到着すると転送終了である。ネットワークでデータもしくは確認応答パケット を喪失した場合は、受信側がタイムアウトを宣告して直前のパケットを再送す る。これによって送信側に喪失したパケットの再送を促すのである。送信者は 再送に備えて直前のパケットだけを保持しておく必要がある。それ以前のパケ ットは、データと確認応答を交互にやり取りしている限り到着が保証されてい る。ここで、転送に関わる両方のマシンが送信者であり、受信者でもあること に注意すること。一方はデータを送信して確認応答を受信し、他方は確認応答 を送信してデータを受信する、とみなせるのである。 大半のエラーは転送終了を引き起こす。エラー報告のために専用パケットが 用意されており、このパケットは確認応答や再送を行わない(つまり、TFTP サーバやユーザはエラーメッセージ送信後すぐに転送を終了してよい)ので、 受信側がエラー報告を確認できないことがある。この場合、転送終了はタイム アウトにより検出する。 エラーの発生原因は三通り考えられる: 1. 要求を満足できない場合。例えば、要求されたファイルが存在しない、 アクセス違反の発生、(メイル送信先の)ユーザ名が未知である、など の場合。 2. ネットワークの遅延や情報の複製では説明のつかないパケットが到着し た場合。例えば、不正なフォーマットのパケットを受信した時。 3. 必要なリソースがアクセス不能になった場合。たとえば、転送中に記憶 装置の容量が上限に達したり、ディスクアクセスを拒否された場合。 転送終了を引き起こさないエラーのうち、TFTP が認識するのは、受信した パケットの Source Port フィールドが不正な場合だけである。この場合、エ ラー報告パケットを返送する。 実装の容易性を優先した結果、TFTP は非常に制限の多いプロトコルとなっ た。たとえば、固定長ブロックの採用により記憶領域の割り当てが簡単にな った。また、データと確認応答を交互に送信することでフロー制御が可能に なり、到着したデータパケットを並べ直す必要がなくなった。 3. 他のプロトコルとの関係(Relation to other Protocols) 最初に述べた通り、TFTP はデータグラムプロトコル(UDP)上での実装を想 定して設計された。また、データグラム自身は IP 上に実装されるので、パケ ットにはインターネットヘッダ、データグラムヘッダ、TFTP ヘッダという三 種類のヘッダが存在することになる。ローカルな伝送媒体を通過するとなれば 更にローカルネットワーク・インタフェースや ARPA のヘッダが付いたりもす る。この時、パケットは図 3-1 に示す様な順序の構成になる。ローカル媒体 のヘッダを先頭に、インターネットヘッダ、データグラムヘッダ、TFTP ヘッ ダ TFTP データと続く(TFTP データはヘッダが記されたパケットの種類と整 合性を持つとは限らない)。TFTP 側ではインターネットヘッダの中身につい て何の仮定もしないが、データグラムヘッダには Source Port、Destination Port、Length フィールドが存在することを前提にしている(前提とされるフ ォーマットについては附録を参照せよ)。TFTP が用いる転送識別子はデータ グラム層に引き渡され、ポート番号として利用されるので、その値はゼロ以上 65535 以下でなければならない。転送識別子の開始値は四章で述べる。 TFTP ヘッダには、DATA や ERROR といった、パケットの種類を表す 2byte の Opcode フィールドがある。Opcode フィールドの値と、様々なパケットの 種類(とフォーマット)については五章で詳しく述べる。 +---------------------------------------------------+ | Local Medium | Internet | Datagram | TFTP | +---------------------------------------------------+ 図3-1: ヘッダの構成順序 4. コネクション確立時の約束(Initial Connection Protocol) WRQ 書き込み要求や RRQ 読み出し要求の送信後、書き込み許可の確認応答、 もしくは読み出し要求に答える先頭のデータパケットが到着すれば、転送状態 確立である。通常の確認応答パケットには、確認対象となったデータパケット のブロック番号が含まれている。ブロック番号は 1 から始まる連番であるが 書き込み許可の確認応答パケットだけは(確認対象がデータパケットでないの で)特別なブロック番号ゼロを含んでいる。要求が拒否されてしまうと、応答 にはエラー報告パケットが届く。 コネクションを確立するには、その両端が各々自分の転送識別子を選択し、 切断までの間その識別子を使い続ければよい。転送識別子はランダムに選択 し、同じ値を連続して使うべきではない。転送されるすべてのパケットは、転 送識別子のペア(始点用と終点用)によって属しているコネクションとその方 向を識別される。TFTP 自体には識別情報を含ませる余地がないので、転送識 別子は始点・終点ポートとして UDP に任される。 コネクション確立と識別子選択の経過を追ってみよう。まず要求側のホスト が自分の転送識別子を選択し、それを始点ポートとして、サーバの69番ポート (八進数 105)に要求の送信を行う。応答側のホストは、自分が選択した転送 識別子を始点ポートとし、要求に含まれていた相手の転送識別子を終点ポート として応答する。こうして互いに相手の転送識別子が判明すると、以降はその 識別子を用いて転送を続ける。 以下の例は、ファイル書き込み時のコネクション確立手続きである。以下の 文章で、WRQ は「書き込み要求」ACK は「確認応答」DATA は「データ」のパ ケットを表すものとする。附録としてファイル読み出し時の似たような例を付 けておいたので、目を通しておくとよいだろう。 1. A から B に WRQ を送信する。始点ポートは A の転送識別子、終点ポート は 69。 2. B から A に ACK を送信する。ブロック番号はゼロ、始点ポートは B の 転送識別子、終点ポートは B の転送識別子。 この時点でコネクションが確立し、ブロック番号 1 のデータパケットが A から送信される。これから先、ホストに到着する全パケットについて始点転送 識別子の照合を行うべきである。照合に失敗した場合、そのパケットは別の場 所から間違って送信されたものとみなして破棄すべきである。またこの場合、 転送が妨害されるまでは、間違えてパケットを送信してきた場所にエラー報告 パケットを送っておくべきである。ただし、このエラー報告は、TFTP が不正 な始点からのパケットを実際に受信した場合にのみ実行可能であろう。下位層 のプロトコルが前もって不正なパケットを捨ててしまう場合、TFTP でこうい ったエラーは検出されないのである。 以下の例は、実際に上の様なエラー状況になった時の、プロトコルの正確な 動作を示すものである。まず A から B に要求を送信する。その要求がネット ワークのどこかで誤って複製され、B がその両方に別々の転送識別子を選択し てしまう。結果として A にはふたつの確認応答が届く。最初の確認応答を受 け取ってからもコネクションは保たれるが、ふたつ目の確認応答は拒否すべき である。ただし、拒否する時に最初のコネクションまで同時に終了してしまう ことはない。以上をまとめると「A の転送識別子ひとつに対して B がふたつ の転送識別子を対応させ、A が受信したメッセージの始点転送識別子をチェッ クしている場合、最初のコネクションは継続するが、ふたつ目のコネクション は拒否してエラー報告パケットを返信する」となる。 5. TFTP のパケット(TFTP Packets) TFTP には五種類のパケットが存在する。ここまでの文章ですべての種類に 言及した: Opcode 動作 ---------------------------- 1 読み出し要求 (RRQ) 2 書き込み要求 (WRQ) 3 データ (DATA) 4 確認応答 (ACK) 5 エラー報告 (ERROR) TFTP ヘッダには Opcode フィールドがあり、パケットの種類を格納している。 2 bytes string 1 byte string 1 byte +------------------------------------------------+ | Opcode | Filename | 0 | Mode | 0 | +------------------------------------------------+ 図5-1: RRQ/WRQ パケット RRQ 及び WRQ のパケット内部フォーマットは、図 5-1 に示す通りである。 Filename フィールドにはヌル文字で終端する netascii のバイト列が入る。 Mode フィールドは、netascii、octet、mail のうちいずれかを netascii 文 字列として含んでおり、本プロトコルが定める転送モードを示す(文字列は大 文字と小文字が混在してよい)。netascii モードを受信したホストは、デー タを自機のローカルフォーマットに変換しなければならない。octet モードは 送信元マシンでの 8bit フォーマットを維持したまま転送する。ここでは、ど んな機種でも共通 8bit フォーマットを扱えて、そのフォーマットが選択され ることを前提にしている。たとえば、DEC-20 は 36 ビットマシンだが、8 ビ ットバイトが 4 つと breakage 4 ビットを合わせて 1 ワードとして扱うこと になる。octet モードで受信したホストから再び同じファイルを取り出すと、 取り出したファイルは送信前のファイルと完全一致しなければならない。mail モードは、ファイル名の代わりに宛先を格納した WRQ により開始しなければ ならない。その他の点はすべて netascii モードと同じである。宛先を表す文 字列は username もしくは username@hostname という形式にすべきである。 後者の形式では、中継マシンがメイルを転送をしてよい。 前段落では送信者も受信者も同じモードで動作すると仮定しているが、必ず そうなるとは限らない。たとえばファイルを保存しておくだけのサーバがあっ たとすると、このマシンは netascii を自分のテキストフォーマットに変換す る必要はないだろう。むしろ、netascii で送信されたものを 8 ビットすべて 受信し、それを変換せずに保存する方がよい。同じような話に DEC-20 のシス テムに現在も残っている問題がある。このマシンは、1 ワードが 36 ビットで あるために、netascii でも octet でもワードを適切に送信することができな い。こういう機種への対処方法としては、読み出す時はワードの全ビットを読 むが、それを受け取る側は 8 ビットフォーマットで保存するような特別モー ドを作ってもよいだろう。そのようなモードでファイルを取得した場合、その ファイルが使えるように元のフォーマットに復元する方がよいので、逆変換の モードも実装しなければならない。ユーザのサイトはこれを実行するための情 報を覚えておかねばならないだろう。以上に挙げた例に共通するのは、要求パ ケットには octet モードを指定するのに、自分の方は違うモードを使うとい う点である。TFTP では機種やアプリケーションに特有なモードを定めること はしないが、それを補うために独自モードを作って利用しても仕様に違反した ことにはならない。 特定のホスト間で合意すれば独自モードを定義することも可能だが、これを 実行に移すには注意を要する。独自モードを実装するための必要条件も決まっ ていないし、それらを正式に登録したり名前を割り当てる中央管理機構も存在 しないからである。 2 bytes 2 bytes n bytes +---------------------------------+ | Opcode | Block # | Data | +---------------------------------+ 図5-2: DATA パケット データは、図 5-2 に示した DATA パケットに入れて転送する。DATA パケッ ト(Opcode 3)には Block#(ブロック番号)及び Data フィールドがある。 ブロック番号はゼロから順に一ずつ増えていくので、プログラムは、次に受け 取るべき正しいパケットと、誤って複製されたパケットを区別することが可能 である。Data フィールドの長さは 0 バイト以上 512 バイト以下である。デ ータの長さが 512 バイトなら、そのパケットはデータの末尾ではない。逆に データの長さが 0 バイト以上 511 バイト以下ならそれは転送終了の合図であ る。(詳細は六章に述べる。) タイムアウトさえ発生しなければ、誤って複製された ACK パケットと転送 終了を告げるパケットを除く全パケットは必ず確認応答される。各 DATA パケ ット自体が、ひとつ前の DATA パケットに対する最初の確認応答パケットへの そのまた確認応答になっているのである。WRQ パケットと DATA パケットには ACK パケットと ERROR パケットが確認応答し、RRQ パケットと ACK パケット には DATA パケットと ERROR パケットが確認応答する。 2 bytes 2 bytes +---------------------+ | Opcode | Block # | +---------------------+ 図5-3: ACK パケット 図 5-3 に ACK パケットのフォーマット(Opcode 4)を示す。ACK パケット の Block# フィールドは、確認対象となった DATA パケットのブロック番号を 示している。ただし例外として、WRQ に対する確認応答パケットはブロック番 号ゼロで識別される。 2 bytes 2 bytes string 1 byte +-----------------------------------------+ | Opcode | ErrorCode | ErrMsg | 0 | +-----------------------------------------+ 図5-4: ERROR パケット 図 5-4 に ERROR パケットのフォーマット(Opcode 5)を示す。ERROR パケ ットは他のどの種類のパケットに対しても確認応答が可能である。ErrorCode フィールドはエラーの発生源を整数で表しており、その値及び意味については 付録の一覧表を参照されたい(本版でエラーコードがいくつか付け加わったこ とに注意)。ErrMsg フィールドは人間による活用を意図しており、netascii 文字列を入れるべきである。他のあらゆる文字列と同じく、このフィールドも ヌル文字で終端する。 6. 正常終了(Normal Termination) 転送終了の合図としては、0 バイト以上 512 バイト以下の Data フィール ド(つまり 516 バイト未満のパケット長)を持つ DATA パケットを使う。こ の転送終了パケットも他の DATA パケットと同様に確認応答されるのだが、応 答側は ACK パケットを送信した後自分側のコネクションを切断してよい。た だし、この ACK パケット自体が喪失することもあるので、確認応答する側の ホストは再送に備えて少しの間切断を遅らせる必要がある。この場合、最後の DATA パケットを再送することで ACK パケットの喪失が検出される。DATA パ ケットを送信する側は、確認応答を受け取るかタイムアウトになるまで再送を 継続せねばならない。こうして最後の ACK パケットを受け取ることができれ ば無事に転送完了である。もしタイムアウトで DATA パケットを再送できなく なれば、その後転送が無事完了するのか、何か問題が発生するのかは知る由も ない。転送失敗の可能性もある。何にせよ、最終的にコネクションは閉じられ る。 7. 異常終了(Premature Termination) 要求が拒否されたり、転送中にエラーが発生したりすると、ERROR パケット (Opcode 5)が送信される。このエラー報告には「一応報告しておこう」程 度の意味しかないので、再送や確認応答は行われない。したがって ERROR パ ケットが到着しないこともあるので、エラーの検出にはタイムアウトをも活用 する必要がある。 I. 附録(Appendix) ヘッダの構成順序 2 bytes +----------------------------------------------------------+ | Local Medium | Internet | Datagram | TFTP Opcode | +----------------------------------------------------------+ TFTP フォーマット Type Opcode Format without header 2 bytes string 1 byte string 1 byte +-----------------------------------------------+ RRQ/ | 01/02 | Filename | 0 | Mode | 0 | WRQ +-----------------------------------------------+ 2 bytes 2 bytes n bytes +--------------------------------+ DATA | 03 | Block # | Data | +--------------------------------+ 2 bytes 2 bytes +-------------------+ ACK | 04 | Block # | +-------------------+ 2 bytes 2 bytes string 1 byte +---------------------------------------+ ERROR | 05 | ErrorCode | ErrMsg | 0 | +---------------------------------------+ ファイル読み出しコネクションの確立手続き 1. A から B に RRQ を送信する。始点ポートは A の転送識別子、終点ポート は 69。 2. B から A に ACK を送信する。ブロック番号は 1、始点ポートは B の転送 識別子、終点ポートは A の転送識別子。 エラーコード一覧 値 意味 ---------------------------------------------- 0 不定、内容はメッセージで確認する. 1 読み出すファイルは存在しない 2 アクセス違反 3 記憶装置の容量、もしくは割り当て容量の超過 4 不正な TFTP 操作 5 未知の転送識別子 6 書き込むファイルは既に存在する 7 指定されたユーザは存在しない UDP ヘッダ これは便宜上掲示するにすぎない。必ずしも TFTP を UDP 上に実装する必要 はない。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Port パケットの始点ポートを示す。 Dest. Port パケットの終点ポートを示す。(RRQ、WRQ では 69 を入れる) Length UDP パケットのバイト数、UDP ヘッダ込み。 Checksum チェックサムの計算規則については UDP 仕様を参照せよ。チ ェックサムの仕組みを実装する者は正確なアルゴリズムを把握 しておくべきである。利用しない場合はゼロを格納する。 注意: TFTP は転送識別子を UDP に引き渡し、UDP ではそれらを始点及び終点 ポート番号として利用する。 参照資料(References) [USASI] USA Standard Code for Information Interchange, USASI X3.4-1968. [RFC768] Postel, J., "User Datagram Protocol," RFC 768, USC/Information Sciences Institute, 28 August 1980. [RFC764] Postel, J., "Telnet Protocol Specification," RFC 764, USC/Information Sciences Institute, June, 1980. [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989. セキュリティに関する考察(Security Considerations) TFTP にはログイン認証やアクセス制御の機構が存在しないので、サーバホ ストのファイルシステムのセキュリティが侵害されない様に、TFTP サーバプ ロセスに認められる権利には特に注意を払う必要がある。通常は、制限を設 けた上で TFTP を組み込み、公開情報を読み出すためだけの仕組みとして、 書き込み禁止の状態で運用することが多いようである。 著者の連絡先(Author's Address) Karen R. Sollins Massachusetts Institute of Technology Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139-1986 Phone: (617) 253-6006 EMail: SOLLINS@LCS.MIT.EDU