訳: 岡橋 一輝 最終更新日: 1999/7/4 --- 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 オプション拡張 本書の位置付け(Status of this Memo) 本書は Internet Community のために標準化過程プロトコルについて記して おり、改善に向けての議論や提案を求めるものである。このプロトコルの標準 化の現状については Internet Official Protocol Standards(STD1)の最新 版を参照されたい。本書の配布は無制限に行ってよい。 著作権(Copyright Notice) Copyright (C) The Internet Society (1998). All Rights Reserved. 概要(Abstract) 簡易ファイル転送プロトコルは、クライアントから遠隔ホストのファイルを 読み書き可能にする、簡潔かつ安全だが融通の利かないファイル転送の仕組み である。本書では、ファイル転送に先立ってオプション折衝が可能になるよう に、TFTP を簡単に拡張する。 はじめに(Introduction) 本書で提案するオプション折衝機構は TFTP の下位互換拡張である。この拡 張により、ファイル転送に先立つ転送オプションの折衝が可能となる。折衝に は TFTP の要求フォーマットに共通の仕組みを利用している。この折衝機構は 要求、応答、確認応答の過程を間違いなく経させることによってその簡潔性を 維持している。この点、TFTP 自身も採用している安全確認しながらのやり取 りに似ているとも言える。 本書に定めるのはオプション折衝機構の一般的な形であり、この仕組みに則 って様々な種類のオプション折衝を行ってよい。この拡張は、[RFC2348] のブ ロックサイズオプションを受けて考案された。この他にも、[RFC2349] でオプ ションが追加されている。 パケットフォーマット(Packet Formats) TFTP オプションは読み出し・書き込み要求パケットに付随する。クライア ントのオプション折衝要求に対する確認応答は、OACK という新種のパケット によって行う。これに伴って、オプション折衝が原因となる転送終了を表すた めに、Error Code 8 を新たに追加する。 オプションは、読み出し、書き込み要求パケットに対して以下の様なフォー マットで取り付ける: +--------+----------+---+------+---+--------+---+--------+---+--> | Opcode | Filename | 0 | Mode | 0 | opt1 | 0 | value1 | 0 | < +--------+----------+---+------+---+--------+---+--------+---+--> >-------+---+--------+---+ < optN | 0 | valueN | 0 | >-------+---+--------+---+ Opcode [RFC1350] の定義通り、読み出し要求の場合は 1、書き込み要求の場合 は 2 を入れる。 Filename [RFC1350] の定義通り操作対象のファイル名を入れる。0x00 で文字列 を終端する。 Mode [RFC1350] の定義通りファイル転送モードを入れる。netascii、octet mail のいずれかを用い、0x00 で文字列を終端する。 opt1 先頭のオプション名。大文字と小文字を区別せずに ASCII 文字列を入 れる。たとえば blksize など。0x00 で文字列を終端する。 value1 先頭のオプションに対する値。大文字と小文字を区別せずに ASCII 文 字列を入れる。0x00 で文字列を終端する。 optN、valueN N 番目のオプションとその値を入れる。他と同様に大文字と小文字を区 別しない ASCII 文字列を用い、0x00 で文字列を終端する。 本来の要求フォーマットに倣って、オプションとその値はすべて 0x00 で終 端させる。複数のオプション折衝が必要な場合、各フィールドの終端に 0x00 を付ける。オプションを指定する順序は重要ではないが、要求パケットの最大 サイズは 512octet とする。 OACK パケットのフォーマットは以下の通り: +--------+--------+---+--------+---+--------+---+--------+---+ | Opcode | opt1 | 0 | value1 | 0 | optN | 0 | valueN | 0 | +--------+--------+---+--------+---+--------+---+--------+---+ Opcode OACK のコード番号である6を入れる。 opt1 先頭のオプションに対する応答であり、要求パケットの同フィールドを 複写する。 value1 先頭のオプションに対する応答値を入れる。要求と異なる値を返すかど うかは、各オプションの仕様を参照されたい。 optN、valueN N 番目のオプションとその応答値を入れる。 折衝進行上の約束(Negotiation Protocol) 上で見た通り、クライアントは読み出し、書き込み要求パケットの末尾にオ プションを付け加える。オプションの総数は任意だが、同じオプションを複数 回指定してはならない。また、オプションの順序は重要ではない。 サーバがオプション折衝をサポートしており、かつ要求パケットに理解可能 なオプションが含まれていれば、サーバは OACK を用いて確認応答してよい。 OACK には、サーバが理解かつ許可したオプションが総て含まれる。オプショ ンによっては要求と異なる値を使える場合もあるが、これはそのオプション特 有の機能であると言える。クライアントに要求されていないオプションを OACK パケットに含めてはならず、オプション折衝は常にクライアント主導で ある。サーバがサポートしていないオプションは OACK パケットから取り除く だけとし、ERROR パケットなどを返送すべきではない。サポートしているオプ ションの値が不正である場合、単にそのオプションを取り除くのか、代替値で 応答するのか、それとも ERROR パケット(Error Code 8)を返送して転送を 終了するのか、については各オプションの仕様で定める。 サーバとクライアントの両者とも、確認応答が無いオプションに対しては、 最初からそのオプションが要求されなかったものとして無視しなければならな い。複数のオプションが要求された場合、確認応答があったオプションは利用 し、確認応答が無かったオプションは無視しなければならない。 クライアントがオプション付きの読み出し要求を送信したとすると、サーバ の応答には三通りの可能性がある: OACK - 読み出し要求及びオプションに対する確認応答 DATA - 読み出し要求に対する確認応答及びオプション拒否 ERROR - 要求自体の拒否 クライアントがオプション付きの書き込み要求を送信したとすると、サーバ の応答には三通りの可能性がある: OACK - 書き込み要求及びオプションに対する確認応答 ACK - 書き込み要求に対する確認応答及びオプション拒否 ERROR - 要求自体の拒否 サーバがオプション折衝をサポートしていない場合、いかなるオプションも 無視されてしまうだろう。この場合、要求が読み出しなら DATA パケットを、 要求が書き込みなら ACK パケットを返送し、通常の TFTP データ転送状態が 確立する。オプション付き要求に対してサーバがエラーを返してきた場合、ク ライアントはオプションを取り除いて同じ要求を再送するとよい。そのように 実装しておけば、要求パケット中の余分な情報をエラーとみなすサーバにも適 切に対処できるだろう。 サーバの OACK に対するクライアントからの応答には、元々の要求の種類に よって二通りの可能性がある。まず読み出し要求の場合、クライアントはブロ ック番号ゼロの ACK パケットを返送することで OACK 承諾の旨を伝える。書 き込み要求の場合、折衝で決めた値を用いて DATA パケットの転送を開始する ことにより、OACK 承諾の代わりとする。クライアントが OACK を拒否する場 合、ERROR パケットをサーバに返送して転送を終了する。 クライアントが OACK に対して ACK を返すと、その OACK に含まれていた オプション及び値にのみ同意したものとみなされる。サーバはオプションに応 答するのみで、自分からオプション要求できないことを思い出そう。もしクラ イアントが要求した覚えの無いオプションに対する OACK を受け取った場合、 そのクライアントは ERROR パケットをサーバに返送して転送を終了すべきで ある。 折衝例(Examples) 読み出し要求の場合 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 書き込み要求の場合 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) TFTP 自体にセキュリティの仕組みは存在しない。この事実に起因してか、 TFTP にはファイルのリネームや削除、それに上書きといった悪用され得る機 能を具わっていない。今回の拡張によって TFTP のセキュリティが強化される わけではないが、逆に危険が増加することもない。 参照資料(References) [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, October 1992. [RFC2348] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348, May 1998. [RFC2349] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size Options", RFC 2349, May 1998. 著者の連絡先(Authors' Addresses) Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821 Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com Art Harkin Internet Services Project Information Networks Division 19420 Homestead Road MS 43LN Cupertino, CA 95014 Phone: (408) 447-3755 EMail: ash@cup.hp.com 著作権(Full Copyright Statement) Copyright (C) The Internet Society (1998). All Rights Reserved. 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.