|
Network Working Group Request for Comments: 1123 |
Internet Engineering Task Force R. Braden, Editor October 1989 |
この RFC は、インターネット社会のための公式の規定である。これは、ホストに関連する基本的なプロトコル標準のドキュメントを参照、改正、修正、補足することによって編入している。このドキュメントの配布は制限されない。
この RFC は、インターネットホストソフトウェアの要件をを定義し議論するペアの一つである。この RFC は、アプリケーションとサポートプロトコルをカバーしている。もう一方の RFC-1123 は、通信プロトコル層: リンク層、IP 層、トランスポート層をカバーしている。
Table of Contents
1. 導入
1.1 インターネット体系
1.2 一般的な考慮
1.2.1 発展し続けるインターネット
1.2.2 頑強さの指針
1.2.3 エラーのログ採取
1.2.4 設定
1.3 このドキュメントを読む
1.3.1 構成
1.3.2 要件
1.3.3 用語
1.4 謝辞
2. 一般的な問題
2.1 ホスト名と番号
2.2 ドメイン名サービスの使用
2.3 マルチホーム化されたホスト上のアプリケーション
2.4 サービスタイプ
2.5 一般的なアプリケーション要件の要約
3. リモートログイン -- TELNET プロトコル
3.1 導入
3.2 プロトコルウォークスルー
3.2.1 オプション折衝
3.2.2 Telnet Go-Ahead 機能
3.2.3 制御機能
3.2.4 Telnet "Synch" Signal
3.2.5 NVT プリンタとキーボード
3.2.6 Telnet コマンド構造
3.2.7 Telnet バイナリオプション
3.2.8 Telnet 端末タイプオプション
3.3 特定の問題
3.3.1 Telnet 行端規定
3.3.2 データ登録端末
3.3.3 オプション要件
3.3.4 オプションの起動
3.3.5 Telnet 行モードオプション
3.4 Telnet/ユーザ間のインタフェース
3.4.1 文字セットの透過性
3.4.2 Telnet コマンド
3.4.3 TCP コネクションエラー
3.4.4 デフォルトでない Telnet 接続ポート
3.4.5 出力のフラッシュ
3.5. Telnet 要件要約
4. ファイル転送
4.1 ファイル転送プロトコル -- FTP
4.1.1 導入
4.1.2 プロトコルウォークスルー
4.1.2.1 ローカルタイプ
4.1.2.2 Telnet フォーマット制御
4.1.2.3 ページ構造
4.1.2.4 データ構造変換
4.1.2.5 データコネクション管理
4.1.2.6 PASV コマンド
4.1.2.7 LIST と NLIST コマンド
4.1.2.8 SITE コマンド
4.1.2.9 STOU コマンド
4.1.2.10 Telnet 行端コード
4.1.2.11 FTP 応答
4.1.2.12 コネクション
4.1.2.13 最小限の実装
4.1.3 特定の問題
4.1.3.1 非標準コマンドの動作
4.1.3.2 アイドルタイムアウト
4.1.3.3 データと制御の協調
4.1.3.4 FTP 再開メカニズム
4.1.4 FTP/ユーザインタフェース
4.1.4.1 パス名の規定
4.1.4.2 "QUOTE" コマンド
4.1.4.3 ユーザへの応答表示
4.1.4.4 同期の維持
4.1.5 FTP 要件要約
4.2 簡易ファイル転送プロトコル -- TFTP
4.2.1 導入
4.2.2 プロトコルウォークスルー
4.2.2.1 転送モード
4.2.2.2 UDP ヘッダ
4.2.3 特定の問題
4.2.3.1 魔法使いの弟子シンドローム
4.2.3.2 タイムアウトアルゴリズム
4.2.3.3 拡張
4.2.3.4 アクセス制御
4.2.3.5 ブロードキャスト要求
4.2.4 TFTP 要件要約
5. 電子メール -- SMTP と RFC-822
5.1 導入
5.2 プロトコルウォークスルー
5.2.1 SMTP モデル
5.2.2 正規化
5.2.3 VRFY と EXPN コマンド
5.2.4 SEND, SOML, SAML コマンド
5.2.5 HELO コマンド
5.2.6 メール中継
5.2.7 RCPT コマンド
5.2.8 DATA コマンド
5.2.9 コマンドシンタックス
5.2.10 SMTP 応答
5.2.11 透過性
5.2.12 MX 処理における WKS の使用
5.2.13 RFC-822 メッセージの規定
5.2.14 RFC-822 日付と時間の規定
5.2.15 RFC-822 シンタックスの変更
5.2.16 RFC-822 ローカル部
5.2.17 ドメインリテラル
5.2.18 一般的なアドレス形式のエラー
5.2.19 明示的な送信元経路
5.3 特定の問題
5.3.1 SMTP キューイング方法
5.3.1.1 送信戦略
5.3.1.2 受信戦略
5.3.2 SMTP のタイムアウト
5.3.3 信頼性のあるメール受信
5.3.4 信頼性のあるメール送信
5.3.5 ドメイン名のサポート
5.3.6 メーリングリストと別名
5.3.7 メールゲートウェイ
5.3.8 最大メッセージ長
5.4 SMTP 要件要約
6. サポートサービス
6.1 ドメイン名変換
6.1.1 導入
6.1.2 プロトコルウォークスルー
6.1.2.1 ゼロの TTL を持つリソースレコード
6.1.2.2 QCLASS 値
6.1.2.3 未使用フィールド
6.1.2.4 圧縮
6.1.2.5 構成情報の誤用
6.1.3 特定の問題
6.1.3.1 リゾルバ実装
6.1.3.2 トランスポートプロトコル
6.1.3.3 効率的な資源利用
6.1.3.4 マルチホームホスト
6.1.3.5 拡張性
6.1.3.6 RR タイプの状態
6.1.3.7 頑強性
6.1.3.8 ローカルホストテーブル
6.1.4 DNS ユーザインタフェース
6.1.4.1 DNS 管理
6.1.4.2 DNS ユーザインタフェース
6.1.4.3 インタフェース省略機能
6.1.5 ドメインネームシステム要件要約
6.2 ホスト起動
6.2.1 導入
6.2.2 要件
6.2.2.1 動的設定
6.2.2.2 ローディングフェーズ
6.3 リモート管理
6.3.1 導入
6.3.2 プロトコルウォークスルー
6.3.3 管理要件要約
7. 参照
セキュリティの考慮
作者のアドレス
このドキュメントは、インターネットプロトコルスイートのホストシステム実装要件を定義し議論するペアドキュメントのうちの一つである。この RFC は、アプリケーション層とサポートプロトコルをカバーしている。もう片方の RFC "インターネットホスト要件 -- 通信層" [INTRO:1] は、下位層プロトコル: トランスポート層、IP 層、リンク層をカバーしている。
これらのドキュメントは、インターネット通信ソフトウェアのベンダ、実装者、ユーザ向けにガイダンスを提供することを意図している。それらは、インターネット研究団体やベンダのコミュニティによって寄与された、大多数の技術上の経験や知識のコンセンサスを表している。
この RFC は、インターネットに接続されたホストが使用しなければならない標準プロトコルを列挙しており、これらのプロトコルの現在の規定を記述している RFC や他のドキュメントを参照することによって編入している。それは、参照しているドキュメント中の誤りを修正し、実装者のために付加的な議論やガイダンスを追加している。
各々のプロトコルに対し、このドキュメントは要件や推奨やオプション等の明示的なセットも含んでいる。このドキュメント中の要件のリストはそれ自身では不完全であることを、読者は理解しなければならない。インターネットホストのための完全な要件は、基本的に標準プロトコルの規定ドキュメントで定義され、この RFC に記述された修正、改正、補足を含む。
注意深く RFC を読み、インターネット技術社会と協調し、適切な通信ソフトウェア技術の実践に従った上で作成されたプロトコルの誠実な実装は、このドキュメントの要件との相違はマイナーなものに限られるはずである。従って、多くの場合この RFC の "要件" は、既に標準プロトコルドキュメントで述べられているか、含まれている。よってここに含めることは、ある意味冗長である。しかし、幾つかの過去の実装は誤った選択をし、相互接続性やパフォーマンス、頑強性に問題を引き起こしたことがあるので、それらを含めている。
このドキュメントは、数多くの要件や推奨についての議論や説明を含んでいる。要件を簡単に一覧化することは危険である。なぜなら、
しかし、このドキュメントの規定は、多種多様で複雑なインターネットシステム全体で、任意のホストの相互運用の一般的な目標に適合するために従わなければならない。現在の大半の実装は、あるものはメジャーな、またあるものはマイナーな様々な点でこれらの要件に適合していないが、この規定は我々が移行する必要のある考え方である。
これらの要件は、インターネット体系の現在のレベルに基づいている。このドキュメントは、追加の説明を提供したり、規定が依然として発展している分野における追加の情報を含めるために、必要に応じて更新されるだろう。
この導入部のセクションは、ホストソフトウェアベンダへの幾つかの一般的なアドバイスから始め、ドキュメントの残りを読むにあたってのガイダンスを示している。セクション 2 は、全てのアプリケーションとサポートプロトコルに適用可能な一般的な要件を含んでいる。セクション 3, 4, 5 は、3 つの主要なアプリケーション: それぞれ Telnet, ファイル転送、電子メール、に関するプロトコルの要件を含んでいる。セクション 6 はサポートアプリケーション: ドメイン名システム、システム初期化、管理、をカバーしている。最後に、全ての参照は、セクション 7 に記載されている。
ホストの観点からのインターネット体系の簡潔な概要については、[INTRO:1] のセクション 1.1 を参照されたい。そのセクションは、インターネット体系の一般的な背景に関して、お薦めの参照も含んでいる。
インターネットホストソフトウェアのベンダが学び、新たなベンダが真剣に考慮すべき二つの重要な教訓がある。
インターネットの膨大な成長は、大きなデータグラムベースのパケット通信システムにおける、管理と規模の問題を暴露した。これらの問題は取り組まれており、結果的にこのドキュメントで示される規定も発展し続けるだろう。こうした計画には、ベンダやネットワークの運用に責任がある組織が広範囲に渡って関係しているので、これらの変更は慎重に計画、管理される。
成長、発展、改訂は今日のコンピュータネットワークプロトコルの特徴であり、この状態は数年は続くであろう。インターネットプロトコルスイート (あるいは他の如何なるプロトコルスイートでも !) のコンピュータ通信ソフトウェアを開発して、その後の規約の変更に対してそのソフトウェアの保守や更新を行なわないベンダは、不幸な消費者の跡を残すだろう。インターネットは大規模な通信ネットワークであり、ユーザは絶えずそれを通じて接触する。経験からすると、ベンダソフトウェアの欠陥に関する知識は、インターネット技術社会を通じて急速に伝達されるようである。
プロトコルの全ての層において、アプリケーションが頑強さと相互接続性に関して、莫大な利益をもたらすことができる一般原則がある。それは、
"受信するものには寛大であれ、送信するものには慎重であれ"
ソフトウェアは、考えられる異常を、たとえそれがあり得そうに無いものであっても処理できるよう書かれるべきである。遅かれ早かれ、パケットはある特定のエラーや属性が組み合わさって入ってくる。もしソフトウェアがそれに備えていなければ、混乱が起こり得る。一般に、ネットワークは最悪の影響を及ぼすことを意図したパケットを送信する、悪意を持ったエンティティが数多く存在するものと想定することが最善である。大半のインターネットの重大な問題は、低い確率で発生するイベントによって引き起こされる、予見できないメカニズムが原因ではあるが、この想定は適切な防御設計につながるだろう。人的悪意だけでは、さほど踏み誤った進路を辿ることはほとんど無い!
修正に対する適応性は、インターネットホストのソフトウェアの全てのレベルにおいて設計しなければならない。簡単な例だが、特定のヘッダフィールド値の列挙、たとえばタイプフィールドやポート番号、エラーコードを含むプロトコル規約を考慮した場合、この列挙値は完全ではないと想定しなければならない。従って、もしプロトコル規約が 4 つのあり得るエラーコードを定義したら、ソフトウェアは 5 つめのコードが現れたときに壊れてはならない。未定義のコードはログに採取してもよいが (後述)、障害の原因になってはならない。
指針の二番目の部分は、次の点において重要である。他のホスト上のソフトウェアは、正しいが不明確なプロトコル機能の開発を浅はかにする欠陥を含むかもしれない。面倒な影響を結果的にどこかに及ぼすのは良くないので、明確さや単純さから離れることは馬鹿げている。この結論は、"誤った動作をするホストに用心せよ" である。ホストソフトウェアは、単に他の誤った動作をするホストがあっても生き残るだけではなく、そうしたホストが原因で起こり得る、共有された通信設備への混乱の量を限定するために協調することを考慮すべきである。
インターネットは非常に多岐に渡るホストやゲートウェイシステムを伴い、その各々は多くのプロトコルやプロトコル層を実装しており、これらの幾つかはインターネットプロトコルソフトウェアの中にバグや機能誤りを含んでいる。複雑さや多様性や機能の分散の結果として、ユーザの問題の診断はしばしば非常に困難である。
もしホスト実装が、異常や "奇妙な" プロトコルイベントをログに採取するために、注意深く設計された機能を含んでいれば、問題の診断に役立つだろう。エラーログを採取する際に、可能な限り多くの診断を含めることは重要である。特に、エラーの原因となったパケットのヘッダを記録することはしばしば効果的である。しかし、エラーのログ採取が極端に大量の資源を消費したり、さもなくばホスト処理の邪魔にならないことを保証するよう、注意しなければならない。
異常だが害は無いプロトコルイベントが、エラーのログファイルを溢れさせる傾向がある。これは "循環" ログを使用するか、あるいは既知の障害を診断する場合にのみログの採取を有効にすることによって回避できる。連続して重複したメッセージをフィルタにかけて、その回数を数えるのは効果的かもしれない。うまくいきそうな戦略は、(1) 常に異常事象をカウントし、その数には管理プロトコル (セクション 6.3 参照) を通じてアクセスさせること。(2) 多様なイベントのログ採取を選択可能にすること。例えば、"全てをログに採る"、あるいは "ホスト X の全てをログに採る" ことができると便利かもしれない。
異なる管理者は、通常時にホストで有効にしたいエラーログの採取量に関して、異なる指針を持つかもしれない。ある者は "もし自分の害にならなければ、それについて知りたくない" と言うかもしれないし、またある者は、より注意深く積極的にプロトコル異常を検出し除去したいと思うかもしれない。
もしインターネットプロトコルスイートのホスト実装が完全に自己設定できれば、理想的である。これによって、スイート全体を ROM に実装したり、シリコンに組み込むことが可能になる。それによってディスクレスワークステーションが単純になり、システムベンダのみならず、苦しんでいる LAN 管理者にも莫大な恩恵をもたらすだろう。我々はまだこの理想には到達していないし、実際近づいてもいない。
このドキュメントの多くの個所に、このパラメタは設定可能なオプションであることという要件が見つかるだろう。そうした要件の背景には、幾つかの異なる理由がある。幾つかのケースでは、最適値について現在確定していないか同意されておらず、将来、推奨値を更新する必要があるかもしれない。別のケースでは、値が実際に外部要因に依存する。例えば、ホストのサイズや通信負荷の分散、隣接するネットワークの速度やトポロジなどである。そして自己調整アルゴリズムが使用できなかったり、不十分であるかもしれない。またあるケースでは、管理要件のために設定可能であることが必要とされる。
最後に、ある設定オプションは、廃止された、あるいはプロトコルの不正な実装体と通信するために必要である。それらはソース無しで配布され、不幸にもインターネットの多くの部分に残っている。正しいシステムをこれらの欠陥システムと共存させるために、管理者はしばしば、正しいシステムに "誤設定" を施す必要がある。この問題は、欠陥システムが退くにつれて次第に改善されていくだろう。しかし、ベンダはそれを無視することができない。
パラメタが設定可能でなければならないと言う場合、その値が毎回ブート時に設定ファイルから明示的に読み込まれる必要があることは意図していない。実装者は各パラメタにデフォルトを設定することが推奨される。よって設定ファイルは、ある特定のインストールにおいて適切でないデフォルトを、上書きする場合にのみ必要である。従って、設定を可能にするという要件は、バイナリのみや ROM ベースの製品でさえも、必要時にデフォルトを上書きすることができることの保証である。
このドキュメントは、幾つかのケースでそうしたデフォルトとして、特定の値を要求している。デフォルトの選択は、設定項目が既存の欠陥システムへの適応を制御する場合は、微妙な問題である。もしインターネットが完全な相互接続性に正常に収束するならば、実装体に組み込まれるデフォルト値は、欠陥システムに便宜を図るための "誤設定" ではなく、公式のプロトコルを実装しなければならない。市場を考慮すると、あるベンダは誤設定のデフォルトを選択するかもしれないが、我々は、この標準に適合したデフォルトをベンダが選択することを強く推奨する。
最後に、ベンダは全ての設定パラメタや、それらの制限や効果に関して、必要十分なドキュメントを提供する必要があることを書き留めておく。
通常は、各主要なセクションは、以下のサブセクションで構成される。
このドキュメント中の多くの個々のトピックの配下に、"DISCUSSION" か "IMPLEMENTATION" というラベルが付いた挿入句的な説明がある。この説明は、この前の要件テキストを明確化したり、説明を加えることを意図している。また、起こり得る将来の方向性や開発に対する幾つかの提案も含んでいる。実装説明は、実装者が考慮する必要のある提案されたアプローチを含む。
要約セクションは、テキストへのガイドとインデクスになることを意図しているが、かなり短く不完全である。要約は、完全な RFC とは切り離して使用したり参照すべきではない。
このドキュメントでは、各々の特定の要件の重要性を定義するために使用される単語は、大文字で記述される。これらの単語とは、
もし実装するプロトコルの一つ以上の MUST 要件を満たさなければ、その実装体は準拠していない。プロトコルの全ての MUST 要件と SHOULD 要件を満たしている実装体は、"無条件に準拠" と呼ばれる。プロトコルの MUST 要件は全て満たしているが、SHOULD 要件は全て満たしているわけではない実装体は、"条件付きで準拠" と呼ばれる。
このドキュメントは、以下の技術用語を使用する。
このドキュメントは、大学や研究機関の代表者、ベンダ、政府機関の代理人を含む、インターネットプロトコルの専門家の大きなグループからの寄与とコメントを反映している。基本的には、インターネット技術作業団体 (IETF) のホスト要件作業グループによって整理された。
編集者は、特に次の人々の多大な貢献に感謝したい。彼らは、多くの長い会議に参加し、このドキュメントの検討で、過去 18 ヶ月に及ぶ 3 百万バイトもの電子メールを作成した。Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software)。
加えて、次の人々は成果に主要な寄与を施した。 Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), and Mike StJohns (DCA)。また次の人々は、特定の分野に重要な寄与をもたらした。Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen (Toronto).
この一覧からたまたま漏れているかもしれない寄与者を含め、皆に感謝したい。
このセクションは、全てのアプリケーション層プロトコルに適用できる一般的な要件を含んでいる。
正しいインターネットホスト名のシンタックスは、RFC-952 [DNS:4] で規定されている。ホスト名のシンタックスの一面について、ここで修正する。一番目の文字に対する制限を緩和し、文字か数字のいずれかを認める。ホストソフトウェアは、このより寛容なシンタックスをサポートしなければならない (MUST)。
ホストソフトウエアは、最大 63 文字のホスト名を扱わなければならず (MUST)、最大 255 文字までのホスト名を扱うべきである (SHOULD)。
ユーザがインターネットホストの身元を入力する場合は常に、次のいずれかの入力を可能にすべきである (SHOULD)。(1) ホストドメイン名、(2) ドット付き 10進数字 ("#.#.#.#") 形式の IP アドレス。ホストは、ドット付き 10進数字番号の文字列をドメイン名システムで検索する前に、シンタックス上のチェックを行うべきである (SHOULD)。
DISCUSSION:
この最後の要件は、ドット付き 10進数字のホスト番号を入力するために、シンタックス上完全な形式で指定することを意図していない。それは、ユーザインタフェースの問題だと見なされる。例えば、ドット付き
10進数字番号は、SMTP メールでは "[ ]" の角括弧で囲まなければならない
(セクション 5.2.17 参照)。この表記方法はホストシステムの中で一般化することができ、ドット付き 10進数字番号のシンタックス上のチェックを簡単にする。
もしドット付き 10進数字番号が、そのような区切り文字を明示せずに入力できるならば、完全なシンタックス上のチェックを行わなければならない。なぜなら、ホストドメイン名の節は現在数字で開始することができ、規定上全て数字にしてもよい (セクション 6.1.2.4 参照)。しかし、少なくとも最上位の要素ラベルはアルファベットになるので、正しいホスト名はドット付き 10進数字形式にはなり得ない。
ホストドメイン名は、セクション 6.1 で規定されているように、IP アドレスに変換しなれけばならない (MUST)。
ドメイン名サービスを使用するアプリケーションは、ソフトエラー状態に対処できなければならない (MUST)。アプリケーションはソフトエラーによって続けて再試行する間、程よい間隔だけ待たなければならず (MUST)、ネットワークの問題によって数時間、あるいは数日の間、サービスが拒否されるかもしれない可能性を考慮しなければならない (MUST)。
アプリケーションは、ある特定のホストアドレスで、全てのサービスの正確なリストを含む WKS レコードを配置する能力に頼るべきではない (SHOULD NOT)。なぜなら WKS RR タイプは、インターネットサイトではしばしば使用されないからである。
リモートホストがマルチホーム化されている場合、名前からアドレスへの変換により、代替 IP アドレスのリストが返却されるだろう。セクション 6.1.3.4 に規定されているように、このリストは優先度の低い順であるべきである。アプリケーションプロトコルの実装は、成功するまでリストからの複数のアドレスを試みる準備をすべきである (SHOULD)。SMTP のためのより固有の要件は、セクション 5.3.4 に記述されている。
ローカルホストがマルチホーム化されている場合、UDP ベースの要求/応答アプリケーションは、UDP 要求データグラムの特定宛先アドレスと同じである IP 送信元アドレスで、応答を送信すべきである (SHOULD)。"特定宛先アドレス" は、もう一組の RFC [INTRO:1] の "IP アドレス付け" のセクションで定義されている。
同様に、同じクライアントに複数の TCP コネクションをオープンするサーバアプリケーションは、全てに対して同じローカル IP アドレスを使用すべきである (SHOULD)。
アプリケーションはトランスポート層サービスを起動する時に、適切な TOS 値を選択しなければならず (MUST)、これらの値は設定可能でなければならない (MUST)。TOS 値は 5 ビットから成り、現在はそのうちの上位 3 ビットしか定義されていないことに注意されたい。他の 2 ビットは 0 でなければならない (MUST)。
DISCUSSION:
サービスタイプを実装するゲートウェイアルゴリズムが開発されたならば、様々なアプリケーションプロトコルで推奨される値が変わるかもしれない。さらに、ユーザとインターネットパスのある特定の組み合わせで、標準でない
TOS 値を使用したいことがあるかもしれない。これらの理由により、TOS 値は設定可能でなければならない。
主要なアプリケーションプロトコルで推奨された TOS 値については、"番号割り当て" RFC [INTRO:5] の最新のバージョンを参照されたい。
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|----------|-|-|-|-|-|--
| | | | | | |
ユーザインタフェース: | | | | | | |
数字で始まるホスト名を認める |2.1 |x| | | | |
63 文字までのホスト名 |2.1 |x| | | | |
255 文字までのホスト名 |2.1 | |x| | | |
ドット付き 10進数字のホスト番号サポート |2.1 | |x| | | |
最初にドット付き形式のシンタックスチェック |2.1 | |x| | | |
| | | | | | |
セクション 6.1 に従ってドメイン名を対応付け |2.2 |x| | | | |
ソフト DNS エラーに対処 |2.2 |x| | | | |
再試行の間に程よい間隔 |2.2 |x| | | | |
長時間の故障を考慮 |2.2 |x| | | | |
WKS レコードが利用できることを期待 |2.2 | | | |x| |
| | | | | | |
マルチホームホストに複数のアドレスをトライ |2.3 | |x| | | |
UDP 応答の送信元 addr が要求の特定宛先 addr |2.3 | |x| | | |
関連した TCP コネクションで同じ IP addr 使用 |2.3 | |x| | | |
適切な TOS 値を指定 |2.4 |x| | | | |
TOS 値を設定可能 |2.4 |x| | | | |
未使用 TOS ビットを 0 |2.4 |x| | | | |
| | | | | | |
| | | | | | |
Telnet は、リモートログインするための標準的なインターネットアプリケーションプロトコルである。これは、クライアント ("ユーザ") システム上のユーザのキーボード/ディスプレイを、リモートサーバシステム上のコマンドインタプリターと結び付けるための符号化規則を提供する。Telnet プロトコルのサブセットは他のアプリケーションプロトコル、例えば FTP や SMTP の中に組み込まれてもいる。
Telnet は単一の TCP コネクションを使用し、通常のデータストリーム ("ネットワーク仮想端末" あるいは "NVT" モード) は、組み込み制御機能へのエスケープシーケンスを持つ 7 ビット ASCII である。Telnet は、数多くのオプションモードや機能の折衝も可能である。
基本的な Telnet の規定は RFC-854 [TELNET:1] にあり、オプションは他の多くの RFC で定義されている。参照は、セクション 7 を参照されたい。
全ての Telnet 実装は、オプションの折衝とサブ折衝 [TELNET:2] を含まなければならない (MUST)。
ホストはオプション折衝のループを避けるために、RFC-854 の規則に注意深く従わなければならない (MUST)。ホストは、未サポートのオプションを拒否 (例えば DO/WILL に対して WONT/DONT で応答) しなければならない (MUST)。オプション折衝は、Telnet コネクションが存続する間はずっと (たとえ全ての要求が拒否されても) 機能し続けるべきである (SHOULD)。
もし全てのオプション折衝が失敗したら、Telnet 実装はデフォルトを NVT にし、これをサポートしなければならない (MUST)。
DISCUSSION:
たとえより洗練された "端末" やサポートしているオプション折衝が標準的になりつつあっても、全ての実装体はユーザ-サーバ通信のために、NVT
をサポートする準備ができていなければならない。
Telnet コマンドの Go Ahead (GA) を送信しないホストの場合、Telnet サーバは Go Ahead の抑制オプションの折衝 (すなわち "WILL Suppress Go Ahead" の送信) を試みなければならない (MUST)。ユーザかサーバ Telnet は、Go Ahead の抑制オプションを常に受諾しなければならない (MUST)。
GA が何の意味も持たない全二重端末を制御する場合、ユーザ Telnet の実装は GA コマンドを無視してもよい (MAY)。
DISCUSSION:
Go-Ahead メカニズムは半二重 ("ロックされたキーボード")
で一度に一行の端末のために設計されたが、それらはほとんど現場から消えつつある。多くのオペレーティングシステムに Go-Ahead
シグナルを実装することは難しいことが判明した。ネイティブな半二重端末をサポートする幾つかのシステムでさえもである。難しさの典型的な例としては、Telnet
サーバコードはユーザプロセスが Telnet コネクションから入力を待って、ブロックされているか否かの情報を得られない、すなわち、いつ GA
コマンドを送信するのか確定できないことである。従って、大半の Telnet サーバホストは GA コマンドを送信しない。
このセクションの規則の効果により、Telnet コネクションのいずれかの終端は、GA コマンドを拒否できる。
依然として商業的に重要な半二重端末のクラスが存在する。それは全画面方式で対話型の "データ登録端末" である。しかし、Telnet プロトコルを使用するデータ登録端末をサポートすることは、Go Ahead シグナルを必要としない。セクション 3.3.2 を参照されたい。
Telnet コマンドのリストは、EOR (End-of-Record)、コード 239 [TELNET:9] を含むよう拡張されている。
ユーザとサーバの両方の Telnet は、制御機能の EOR, EC, EL, Break をサポートしてもよく (MAY)、AO, AYT, DM, IP, NOP, SB, SE をサポートしなければならない (MUST)。
ホストは、サポートしていない如何なる Telnet 制御機能も受信して無視できなければならない (MUST)。
DISCUSSION:
サーバ Telnet は、たとえサーバホストが同等な入力ストリーム機能 (例えば多くのシステムにある Contrl-C) を持っていても、Telnet IP (Interrupt Process)
機能をサポートする必要があることに注意されたい。Telnet IP 機能は TCP 緊急データの帯域外効果を持つので、入力ストリームの中断コマンドよりも強いかもしれない。
EOR 制御機能は、ストリームを区切るために使用してもよい。重要なアプリケーションは、データ登録端末のサポートである (セクション 3.3.2 参照)。EOR は RFC-854 で定義されたので、未知の Telnet コマンドを正しく無視できないホストが、もし EOR を受信したらクラッシュするという懸念があった。そのようなホストを保護するために、End-of-Record オプション [TELNET:9] が導入された。しかし、適切に実装された Telnet プログラムはこの保護を必要としない。
"緊急" TCP データを受信した場合、ユーザかサーバ Telnet は DM (と緊急の終了) が到着するまで、Telnet コマンドを除く全てのデータを破棄しなければならない (MUST)。
Telnet IP (プロセス中断) を送信した場合、ユーザ Telnet は Telnet "Synch" シーケンスを後続させるべきである (SHOULD)。例えば、TCP 緊急データとして "IAC IP IAC DM" を送信する。TCP 緊急ポインタは DM オクテットを指す。
Telnet IP コマンドを受信した場合、サーバ Telnet は出力ストリームをフラッシュするために、Telnet "Synch" シーケンスをユーザに返送してもよい (MAY)。その選択は、ローカルユーザがプロセスを中断した時に、サーバオペレーティングシステムが動作する方法と一貫すべきである。
Telnet AO コマンドを受信した時、サーバ Telnet は出力ストリームをフラッシュするために、Telnet "Synch" シーケンスをユーザに返送しなければならない (MUST)。
Telnet IP を送信した場合、ユーザ Telnet は出力をフラッシュすることが可能であるべきである (SHOULD)。セクション 3.4.5 も参照されたい。
DISCUSSION:
ユーザ Telnet がサーバ出力データのストリームをフラッシュする方法は三つある。
NVT モードでは、Telnet は最上位ビットが 1 の文字を送信すべきではなく (SHOULD NOT)、パリティビットとして送信してはならない (MUST)。最上位ビットをアプリケーションに渡す実装体は、バイナリモードを折衝すべきである (SHOULD) (セクション 3.2.6 参照)。
DISCUSSION:
厳密に RFC-854 を読むと、NVT ASCII を期待するクライアントやサーバは、最上位ビットが設定された文字を無視してもよいことを、実装者は知っておくべきである。一般には、拡張
(7 ビットを超えた) 文字セットを Telnet の転送で使用するには、バイナリモードが期待される。
しかし、現在は定義されていないが、8 ビット NVT モードを実際に必要とするアプリケーションが存在する。これらの既存のアプリケーションは、Telnet コネクションが生きている一部、又は全ての間に、実際に最上位ビットを設定する。バイナリモードは 8 ビット NVT モードとは同じでないことに注意されたい。なぜならば、バイナリモードは行端処理を無効にするからである。この理由により、最上位ビットに関する要件は MUST ではなく SHOULD として規定されている。
RFC-854 は、"ネットワーク仮想端末" あるいは NVT の特性のうち、最小限のセットを定義している。これは、実端末の追加機能を除外することは意味していない。Telnet コネクションは、任意の ASCII 制御文字を含めて全ての 7 ビット ASCII 文字に完全に透過的である。
例えば、端末は ASCII のエスケープシーケンスとしてコード化された、フルスクリーンコマンドをサポートしてもよい。Telnet 実装体は、これらのシーケンスを解釈されないデータとして渡すだろう。従って、NVT は非常に制限されたデバイスの端末タイプとして考えるべきではない。
オプションはデータストリームの如何なるポイントにも現れてよいので、データとして送信する Telnet エスケープ文字 (IAC として知られ、値 255 を持つ) は二重にしなければならない (MUST)。
バイナリオプションが正常に折衝された時、任意の 8 ビット文字が許される。しかし、データストリームは依然として IAC 文字を検索しなければならず (MUST)、如何なる組み込み Telnet コマンドにも従わなければならず (MUST)、IAC と等しいデータバイトは二重にしなければならない (MUST)。他の文字処理 (例えば CR を CR NUL か CR LF に置き換える等) は行ってはならない (MUST NOT)。特に、バイナリモードには行端の規定 (セクション 3.3.1 参照) は存在しない。
DISCUSSION:
Telnet コネクションを NVT モードから "バイナリモード"
に変更するために、バイナリオプションは通常両方向で折衝される。
バイナリモードの Telnet ストリームの中で、データのブロックの範囲を定めるために、IAC EOR シーケンスを使用できる。
端末タイプオプションは、それらが特定の端末で利用できる場合、番号割り当て RFC [INTRO:5] で公式的に定義された端末タイプ名を使用しなければならない (MUST)。しかし、端末タイプオプションの受信側は、如何なる名前も受け入れなければならない (MUST)。
DISCUSSION:
RFC-1091 [TELNET:10] は、RFC-930
で定義された以前のバージョンを更新している。以前のバージョンは、各々の物理端末が固有のタイプを持つものと仮定して、複数の端末タイプをサポートできるサーバホストは、特定のクライアント端末のタイプを知ることを許していた。しかし最近の
"端末" は大抵、実際には PC で動いている端末エミュレータプログラムであり、恐らくある範囲の端末タイプをエミュレートできるだろう。従って
RFC-1091 は、ユーザとサーバ Telnet 間でより一般的な端末タイプの折衝を可能にするために、規定を拡張している。
Telnet プロトコルは、"行端" を意味する CR LF シーケンスを定義している。端末入力では、これはユーザ端末でコマンド完了か "行端" キーを押下することに相当する。ASCII 端末ではこれは CR キーであるが、"Return" あるいは "Enter" というラベルが付いているかもしれない。
サーバ Telnet が、リモート端末からの入力として Telnet 行端シーケンス CR LF を受信した場合、その効果はユーザがローカル端末で "行端" キーを押下したのと同じでなければならない (MUST)。ASCII を使用するサーバホスト上では特に、Telnet シーケンス CR LF の受信は、ローカルユーザがローカル端末で CR キーを押下するのと同じ効果を持たなければならない。従って CR LF と CR NUL は、Telnet コネクション上の入力として受信した場合、ASCII サーバホスト上では同じ効果を持たなければならない (MUST)。
ユーザ Telnet は、CR LF, CR NUL, LF のどの形式も送信できなければならない (MUST)。ASCII ホスト上のユーザ Telnet は、ユーザが "行端" キーを押下した時に CR LF か CR NUL のいずれかを送信するための、ユーザ指定可能なモードを持つべきであり (SHOULD)、CR LF がデフォルトであるべきである (SHOULD)。
Telnet 行端シーケンス CR LF は、端末からコンピューターへのデータではない Telnet データ (例えば、出力を送信するサーバ Telnet や別のアプリケーションプロトコルに組み込まれた Telnet プロトコル等) を送信するために使用しなければならない (MUST)。
DISCUSSION:
任意の Telnet クライアントとサーバとの間の相互運用を可能にするために、Telnet プロトコルは行の終端の標準的な表現方法を定義した。ASCII
文字セットは明示的な行端文字を含んでいないので、システムは例えば CR, LF, CR LF シーケンス等、様々な表現方法を選択した。Telnet
プロトコルは、ネットワーク転送の標準として CR LF シーケンスを選択している。
不幸にも、RFC-854 [TELNET:1] の Telnet プロトコル規定は、"行端" キーに対し何の文字をクライアントからサーバへ送信すべきかについて、幾分曖昧であることが判明した。その結果は大規模であり、相互運用性の面倒な問題が続いている。そして、ユーザとサーバ Telnet の両方の様々な欠陥のある実装体によって、更に悪い状態になっている。
Telnet プロトコルは完全に対称モデルに基づいており、リモートログインセッションでは、端末でのユーザの役割はサーバホストの役割とは異なる。例えば、RFC-854 はサーバからの出力として CR, LF, CR LF の意味を定義しているが、ユーザが端末上で "行端" キーを押下した時に、ユーザ Telnet が何を送信すべきかについては規定していない。これが問題点であることが分かっている。
ユーザが "行端" キーを押下した時に、幾つかのユーザ Telnet 実装体は CR LF を送信し、一方他のものは CR NUL を送信する (RFC-854 の同じ文の解釈が異なることによる)。これらは上記で論じられているように、正しく実装された ASCII サーバホストと同様である。他のサーバに対してはユーザ Telnet にモードが必要である。
CR が押下された時に CR NUL しか送信しないユーザ Telnet が存在することにより、非 ASCII ホストにジレンマが生じている。それは、CR NUL を入力中の CR LF と同等に扱うい、"裸" の CR を入力する可能性を除外するか、さもなくば完全な相互動作を失うかである。
ホスト A 上のユーザがサーバホスト B にログインするために Telnet を使用し、その後 B のユーザ Telnet プログラムがサーバホスト C にログインすると仮定する。B 上のサーバ/ユーザ Telnet の組み合わせは、可能な限り透過的であることが望ましい。すなわち、あたかも A が直接 C に接続しているように見えることである。特に正しい実装体は、CR LF を CR NUL、あるいはその逆に変換されるかもしれないことを除いて、B に Telnet の行端シーケンスを透過的にさせるだろう。
IMPLEMENTATION:
Telnet 行端問題を理解するために、ローカルオペレーティングシステムへの Telnet に関連した、一般的なモデルを少なくとも持たなければならない。サーバ Telnet
プロセスは通常、擬似端末としてのオペレーティングシステムの端末ドライバソフトウエアに結合される。サーバ Telnet が受信した Telnet
行端シーケンスは、ローカルに接続された実端末上で行端キーを押下したのと同じ効果を持たなければならない。
対話型で一度に一文字ずつのアプリケーション (例えばエディタ) をサポートしているオペレーティングシステムは通常、それらの端末 I/O のための内部モードを持たなければならない。整形モードの場合、行端や他の整形規則のためのローカルな規約がデータストリームに適用される。"生の" モードの場合、アプリケーションは入力された通りに全ての文字に直接アクセスする。サーバ Telnet は、これらのモードがローカル端末と同じ効果をリモートに対して持つように実装しなければならない。例えば、ASCII ホスト上のサーバ Telnet が CR LF か CR NUL を受信すると仮定する。生のモードの場合、CR 文字がアプリケーションに渡され、整形モードの場合、ローカルシステムの行端規約が使用される。
DISCUSSION:
Telnet が設計された行型と文字型の ASCII 端末に加えて、"データ登録端末" あるいは DET
として知られているビデオディスプレイ端末の幾つかのファミリが存在する。IBM 3270 ファミリは、一般によく知られている例である。
一般的な DET をサポートするために、二つのインターネットプロトコルが設計されている。それは、SUPDUP [TELNET:16], [TELNET:17] と DET オプション [TELNET:18], [TELNET:19] である。DET オプションは、(サブ) 折衝を使用して Telnet コネクション上でデータ登録端末を制御する。SUPDUP は完全に独立した端末プロトコルであり、折衝によって Telnet から入ることができる。SUPDUP と DET オプションの両方を、ある特定の環境で正常に使用することができるが、一般には受け入れられておらず、広く実装されてもいない。
如何なる DET に対しても同じアプローチが適用可能だが、Telnet を通じて IBM 3270 ファミリをサポートするために、対話型 DET への別のアプローチが開発されている。考え方は "ネイティブ DET" モードに入ることであり、ネイティブ DET 入出力ストリームはバイナリデータとして送信される。バイナリストリームの中で論理レコードの境界 (例えば "画面") を設定するには、Telnet EOR コマンドを使用する。
IMPLEMENTATION:
ネイティブ DET モードに出入りするための規則は以下の通り。
全ての Telnet 実装体は、バイナリオプション [TELNET:3] と Go Ahead の抑制オプション [TELNET:5] をサポートしなければならず (MUST)、エコー [TELNET:4]、状態 [TELNET:6]、レコードの終端 [TELNET:9]、拡張オプションリスト [TELNET:4] オプションをサポートすべきである (SHOULD)。
ユーザかサーバ Telnet は、もしローカルのオペレーティングシステムが対応する能力を提供するならば、ウィンドウサイズオプション [TELNET:12] をサポートすべきである (SHOULD)。
DISCUSSION:
レコードの終端オプションは、Telnet がクラッシュせずに Telnet EOR を 受信できることのみ示すことに注意されたい。従って、全ての Telnet
はレコードの終端オプションの折衝を自発的に受け入れるべきである。セクション 3.2.3 の議論も参照されたい。
Telnet プロトコルをクライアント/サーバ環境で使用する場合、サーバは期待した端末対話型モードの折衝を起動すべきである (SHOULD)。
DISCUSSION:
Telnet プロトコルは完全に対称になるよう定義されたが、そのアプリケーションは通常非対象である。リモートログインはどちら側も必要な非デフォルトの端末モードの折衝を起動しないので、失敗することがよく知られている。一般に望ましいモードを決定するのはサーバなので、サーバが折衝を起動する必要がある。折衝は対称なので、ユーザも起動することができる。
クライアント (ユーザ Telnet) は、ユーザがオプション折衝の起動を有効にしたり無効にするための手段を提供すべきである (SHOULD)。
DISCUSSION:
ユーザは時々、制御ストリームのために Telnet を使用するが、Telnet オプションをサポートしないアプリケーションサービス (FTP や SMTP 等)
に接続する必要がある。もしオプション折衝の起動が無効ならば、この目的でユーザ Telnet を使用してもよい。
DISCUSSION:
重要な新しい Telnet オプション、LINEMODE [TELNET:12]、が提案された。LINEMODE
オプションは、サーバではなくクライアントが端末の文字処理を実行することを、ユーザ Telnet とサーバ Telnet
が合意するための標準的な方法を提供する。クライアントがテキストの行を完結する準備をした時に、1 つの TCP パケットをサーバに (通常) 送信する。このオプションは
Telnet セッションのパケットコストを大幅に減らし、輻輳した、あるいは遅延の長いネットワーク上で、より優れたユーザレスポンスを提供する。
LINEMODE オプションは、ローカルとリモートの文字処理の動的な切替を可能にする。例えば、フルスクリーンエディタが動作している間は、Telnet コネクションは自動的に単一文字モードになるよう折衝し、そしてエディタが終了した時に行モードに戻る。
この RFC がリリースされる時、ホストはこのオプションのクライアント側を実装すべきであり、このオプションのサーバ側を実装してもよいことが期待される。サーバ側を適切に実装するために、サーバは如何なる入力文字の処理も行わないが、現在の端末状態を覚えておき、その状態が変わったら必ずサーバ Telnet プロセスに通知することを、ローカルシステムに通知できる必要がある。これによって、例えばパスワードのエコーやフルスクリーンエディタを適切に扱うことができる。
ユーザ Telnet の実装体は、如何なる 7 ビット ASCII 文字も送受信できるべきである (SHOULD)。可能ならば、ユーザホストのオペレーティングシステムによる如何なる特殊文字の解釈も迂回すべきである (SHOULD)。それにより、これらの文字をコネクション上で都合良く送受信することができる。
幾つかの文字の値は "コマンドモードへのエスケープ" として予約しなければならない (MUST)。慣例的にこの文字を二つ合わせることにより、それをデータとして入力することができる。使用される特殊文字は、ユーザにより選択可能であるべきである (SHOULD)。
バイナリモードコネクションでは、もしホストオペレーティングシステムが、任意の 8 ビット値をキーボードから直接入力できないならば、ユーザ Telnet プログラムがそれらの値を入力するために、エスケープメカニズムを提供してもよい (MAY)。
IMPLEMENTATION:
透過性の問題はサーバにはさほど重いものではないが、NVT ASCII だけを期待したプログラムや
8 ビットのデータストリームを要求する適切に処理するプログラムに届く前に、(古く適合していないクライアントによって送信された)
パリティビットのマスクを外すような問題の扱いに、実装者は注意を払うべきである。
ユーザ Telnet プログラムは、ユーザに Telnet 制御機能 IP, AO, AYT を入力する手段を提供しなければならず (MUST)、EC, EL Break を入力する手段を提供すべきである (SHOULD)。
ユーザ Telnet プログラムは、トランスポート層に通知された ([INTRO:1] の "TCP/アプリケーション層インタフェース" のセクション参照) 如何なる TCP エラーもユーザに通知すべきである (SHOULD)。
ユーザ Telnet プログラムは、ユーザがサーバ Telnet ホストの非標準の接続ポート番号を任意に指定することを可能にすべきである (SHOULD)。
ユーザ Telnet プログラムは、IP が送信されたときに出力をフラッシュすべきか否かを指定する手段を、ユーザに提供すべきである (SHOULD)。セクション 3.2.4 を参照されたい。
サーバから Telnet のシグナルを受信するまで、ユーザ Telnet に出力をローカルにフラッシュさせる如何なる出力フラッシュスキームにおいても、サーバが期待されたシグナルを送信できない場合に、ユーザが手動で通常の出力を復元するための方法が存在すべきである (SHOULD)。
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------------|--------|-|-|-|-|-|--
| | | | | | |
オプション折衝 |3.2.1 |x| | | | |
折衝のループを回避する |3.2.1 |x| | | | |
未サポートのオプションを拒否する |3.2.1 |x| | | | |
コネクション上では常に折衝 OK |3.2.1 | |x| | | |
デフォルトを NVT にする |3.2.1 |x| | | | |
端末タイプオプションで公式な名前を送信する |3.2.8 |x| | | | |
端末タイプオプションで如何なる名前も受諾する |3.2.8 |x| | | | |
バイナリと GA 抑制オプションをサポートする |3.3.3 |x| | | | |
エコー、状態、EOL, Ext-Opt-List オプション |3.3.3 | |x| | | |
適切ならばウィンドウサイズオプションをサポート |3.3.3 | |x| | | |
サーバがモード折衝を起動する |3.3.4 | |x| | | |
ユーザが折衝の起動を有効化/無効化できる |3.3.4 | |x| | | |
| | | | | | |
Go-Aheads | | | | | | |
GA 無しのサーバが GA 抑制オプションを折衝する |3.2.2 |x| | | | |
ユーザかサーバが GA 抑制オプションを受諾する |3.2.2 |x| | | | |
ユーザ Telnet が GA を無視する |3.2.2 | | |x| | |
| | | | | | |
制御機能 | | | | | | |
SE NOP DM IP AO AYT SB をサポート |3.2.3 |x| | | | |
EOR EC EL Break をサポート |3.2.3 | | |x| | |
未サポートの制御機能を無視する |3.2.3 |x| | | | |
ユーザ、サーバが DM まで緊急データを破棄する |3.2.4 |x| | | | |
ユーザ Telnet が IP,AO,AYT 後に "Synch" を送信 |3.2.4 | |x| | | |
サーバ Telnet が IP に対して Synch を返送 |3.2.4 | | |x| | |
サーバ Telnet が AO に対して Synch を返送 |3.2.4 |x| | | | |
ユーザ Telnet が IP 送信時に出力をフラッシュ |3.2.4 | |x| | | |
| | | | | | |
符号化 | | | | | | |
NVT モードで最上位ビットを送信 |3.2.5 | | | |x| |
最上位ビットをパリティビットとして送信 |3.2.5 | | | | |x|
最上ビットをアプリに渡すならばバイナリを折衝 |3.2.5 | |x| | | |
IAC データバイトを常に二重にする |3.2.6 |x| | | | |
バイナリモードで IAC データバイトを二重にする |3.2.7 |x| | | | |
バイナリモードで Telnet コマンドに従う |3.2.7 |x| | | | |
バイナリモードで行端を CR NUL に |3.2.7 | | | | |x|
| | | | | | |
行端 | | | | | | |
サーバでの EOL はローカルの行端と同じ |3.3.1 |x| | | | |
ASCII サーバが EOL として CR LF, CR NUL を受諾 |3.3.1 |x| | | | |
ユーザ Telnet が CR LF, CR NUL, LF を送信可能 |3.3.1 |x| | | | |
ASCII ユーザが CR LF/CR NUL を選択できる |3.3.1 | |x| | | |
ユーザ Telnet のデフォルトモードは CR LF |3.3.1 | |x| | | |
非対話型で EOL として CR LF を使用する |3.3.1 |x| | | | |
| | | | | | |
ユーザ Telnet インタフェース | | | | | | |
7 ビット文字を全て送受信できる |3.4.1 | |x| | | |
ローカルの OS の解釈を迂回する |3.4.1 | |x| | | |
エスケープ文字 |3.4.1 |x| | | | |
エスケープ文字をユーザが設定可能 |3.4.1 | |x| | | |
8 ビット値を入力するためにエスケープする |3.4.1 | | |x| | |
IP, AO, AYT を入力できる |3.4.2 |x| | | | |
EC, EL, Break を入力できる |3.4.2 | |x| | | |
TCP コネクションエラーをユーザに通知する |3.4.3 | |x| | | |
任意の非デフォルトの接続ポート |3.4.4 | |x| | | |
IP 送信時に出力をフラッシュするか指定できる |3.4.5 | |x| | | |
出力モードを手動で復元できる |3.4.5 | |x| | | |
| | | | | | |
ファイル転送プロトコル FTP は、ファイル転送のための基本的な標準である。現在の規定は RFC-959 [FTP:1] に含まれている。
FTP は制御とデータ転送のために、別々の同時に存在する TCP コネクションを使用する。FTP プロトコルは数多くの機能を含み、それらの幾つかは通常は実装されない。しかし、FTP の全ての機能において少なくとも一つの実装が存在する。RFC-959 で定義された最小限の実装は小さすぎるので、若干大きな最小実装をここで定義する。
インターネットユーザは、不十分な FTP 実装のために、数年もの間不要な負担を強いられている。プロトコル実装者は、FTP の実装は小さく平凡な仕事であるべきという誤った意見に苛まれていた。FTP はユーザインタフェースを持ち、通信やオペレーティングシステムの広く多岐に渡る発生するかもしれないエラーを (正しく) 扱わなければならず、世界中の非常に多種多様な実ファイルシステムを扱わなければならないので、これは誤りである。
FTP プログラムは、TYPE L 8 (論理バイト長 8 の "LOCAL" タイプ) だけでなく、TYPE I ("IMAGE" またはバイナリタイプ) もサポートしなければならない (MUST)。メモリが m ビットワードで構成されるマシンで、m が 8 の倍数ではない場合は、TYPE L m もまたサポートしてもよい (MAY)。
DISCUSSION:
コマンド "TYPE L 8" は、メモリが (例えば) 36 ビットワードに構成されるマシンと
8 ビットバイト構成のマシン間で、バイナリデータを転送するためにしばしば必要になる。8 ビットバイトのマシンでは、TYPE L 8 は IMAGE と同等である。
"TYPE L m" は時々、二つの m ビットワードのマシン上で、あるマシンから別のマシンへ、ネイティブモードのバイナリファイルを正しく転送することをを保証するために FTP プログラムに指定される。しかし、このコマンドは、これらのマシンでの "TYPE I" と同じ効果を持つべきである。
TYPE T と TYPE I に相違が無いホストは、TYPE T と TYPE N を同一に実装すべきである (SHOULD)。
DISCUSSION:
この規定により、これを区別するホストとの相互運用が容易になるはずである。
多くのホストは、テキストファイルを内部的に ASCII 文字の列として表し、ファイルを印字する時にフォーマットを制御するために、組み込まれた ASCII フォーマット効果文字 (LF, BS, FF, ...) を使用する。そのようなホストは、"印字" ファイルと他のファイルとを区別しない。しかし、レコード構造のファイルを使用するシステムは、印字可能なファイル (例えば ASA 改行制御) のために、通常特殊なフォーマットが必要である。後者のホストの場合、FTP は TYPE N か TYPE I の選択を可能としている。
ページ構造の実装は、一般には推奨されていない (NOT RECOMMENDED)。しかし、もしホストシステムが、"ランダムアクセス" あるいは "穴明き" ファイルの FTP を本当に実装する必要があるならば、新しい私的な FTP フォーマットを定義せずに、既に定義されたページ構造フォーマットを使用しなければならない (MUST)。
相手ホストで結果を可能な限り有効にするために、レコード構造とファイル構造間の FTP 変換は可逆性を持つべきである (SHOULD)
DISCUSSION:
RFC-959 はレコード構造とファイル構造間の厳密な可逆性を求めているが、実際は効率と便宜により妨げられている。従って、この要件は緩和されつつある。ファイル転送には二つの異なる目的がある。それは相手ホストでファイルを処理するか単に格納することである。格納においては、厳密な可逆性が重要である。処理においては、相手ホストで作成されたファイルは、そのホストのアプリケーションプログラムによって期待されたフォーマットであることを必要とする。
衝突の例として、各レコードが正確に 80 バイトである幾つかのデータファイルを必要とするレコード型オペレーティングシステムを想定する。そのホストにファイルを格納 (STOR) する間、FTP サーバは各々の行かレコードを 80 バイトにパディングできなければならない。そうようなファイルを後で戻すことは、厳密に可逆性があるはずがない。
STREAM モードを使用するユーザ FTP は、各々の転送コマンドを発行する前にデフォルトでないデータポートを割り当てるために、PORT コマンドを送信すべきである (SHOULD)。
DISCUSSION:
これは、単一の FTP セッションの間に複数の転送を可能にする場合、TCP
コネクションがクローズされた後、ソケットのペアが再利用できるまでの遅延が長いために必要である。ポートコマンドの送信は、もしストリーム以外の転送モードが使用されていれば、転送の間、データ転送コネクションをオープンしたままにすることによって回避できる。
サーバ FTP は PASV コマンドを実装しなければならない (MUST)。
もし複数のサードパーティ転送が同一セッション中に実行されたら、ユニークなポートのペアを獲得するために、各々の転送コマンドの前に新たな PASV コマンドを発行しなければならない (MUST)。
IMPLEMENTATION:
PASV コマンドに対する 227 応答のフォーマットは、うまく標準化されていない。特に、FTP クライアントは RFC-959 のページ 40
にある括弧が存在するものとは想定できない (実際、ページ 43 の図 3 では括弧が省略されている)。従って、PASV 応答を解釈するユーザ
FTP プログラムは、ホストとポート番号の一番目の数字について、応答を調べなければならない。
ホスト番号 h1,h2,h3,h4 は、その応答を送信するサーバホストの IP アドレスであり、p1,p2 は PASV が割り当てたデフォルトでないデータ転送ポートであることに注意されたい。
NLST コマンドによって返却されたデータは、規定に合ったパス名の簡単なリストのみ含まなければならない (MUST)。例えば、続いて起こる個々のファイルに対するデータ転送コマンドのアーギュメントとして、サーバが直接使用できるようなものである。
LIST や NLST コマンドによって返却されたデータは、もし現在のタイプが EBCDIC でなければ、暗黙的に TYPE AN を使用すべきである (SHOULD)。タイプが EBCDIC である場合は、暗黙的に TYPE EN を使用すべきである (SHOULD)。
DISCUSSION:
多くの FTP クライアントは、ワイルドカード指定に一致するファイルを送受信するマクロコマンドをサポートし、パス名のリストを取得するために NLST
を使用する。"複数送信" の拡張はクライアントにローカルであるが、"複数受信" はサーバと協同する必要がある。
LIST と NLST の暗黙タイプは、既存のユーザ FTP、特に複数受信コマンドとの互換性を提供するために設計されている。
サーバ FTP は標準でない機能に対し、新たな私用コマンドや既存のコマンドの非標準の拡張を創案せずに、SITE コマンドを使用すべきである (SHOULD)。
STOU コマンドは、ユニークな名前が付けられたファイルに格納する。STOU コマンドを受信した場合、サーバ FTP は転送の前の "125 転送開始" や "150 データコネクションのオープン" メッセージに (RFC-959 で述べられている 250 応答コードは誤りである)、実際のファイル名を返却しなければならない (MUST)。これらのメッセージの正確なフォーマットは、ここでは以下のように定義する。
125 FILE: pppp
150 FILE: pppp
上記の pppp は、書き込まれるファイルのユニークなパス名を表している。
実装者は、制御コネクション上の READ 境界と Telnet EOL シーケンス (CR LF) が一致すると仮定してはならない (MUST NOT)。
DISCUSSION:
従って、サーバ FTP (あるいはユーザ FTP) は、コマンド (あるいは応答) を処理する前に、完全な Telnet EOL
シーケンスが現れるまで制御コネクションからの文字の読み込みを続けなければならない。逆に言えば、一回の READ で制御コネクションから一つ以上の
FTP コマンドが含まれるかもしれない。
サーバ FTP は、制御コネクション上で正しいフォーマットの応答を送信しなければならない (MUST)。RFC-959 は (FTP 規定の以前のバージョンとは異なり)、"自発的な" 応答メッセージに対する準備を含んでいないことに注意されたい。
サーバ FTP は適用される場合は常に、RFC-959 で定義された応答コードを使用すべきである (SHOULD)。しかし、サーバ FTP はセクション 4.2 の一般規則に従う限りにおいて、必要な場合は異なる応答コードを使用してもよい (MAY)。実装者が 4xx と 5xx の応答コードの間を選択した場合、失敗した FTP が数時間後には成功するだろうという理に適った可能性がある時は、サーバ FTP は 4xx (一時的失敗) コードを送信すべきである (SHOULD)。
ユーザ FTP は、処理上の決定を行う場合、サーバ FTP が標準でない応答コードを使う時に問題を避けるために、3 つの数字の応答コードのうち最上位の数字のみを一般に使用すべきである (SHOULD)。
ユーザ FTP は、複数行の応答を扱えなければならない (MUST)。もし実装体が行数に制限を課していて、この制限を越えたならば、ユーザ FTP は例えば複数行応答の最後に達するまで、超えた行を無視すること等によって、復旧しなければならない (MUST)。
ユーザ FTP は特に、421 応答コード ("サービス利用不可、制御コネクションをクローズ") を解釈すべきではない (SHOULD NOT) が、サーバによる制御コネクションのクローズを検出すべきである (SHOULD)。
DISCUSSION:
応答規則に厳密に従っていないサーバ実装は、しばしば FTP ユーザプログラムのハングアップを引き起こす。RFC-959 は、以前の
FTP 規定に見られた応答規則の曖昧さを解消しており、これに従わなければならない。
ファイル転送クライアントデーモンの正常な使用を可能にするために、一時的と永続的の障害を適切に区別する FTP 応答コードを選択することは重要である。これらのプログラムは、失敗した転送を再試行するか否かを決定するのに応答コードに頼っている。一時的エラーで永続的失敗コード (5xx) を使用すると、これらのプログラムは不必要に諦めてしまうだろう。
応答の意味が RFC-959 に示されているテキストに正確に一致する場合、RFC-959 のテキストと全く同じ言葉を使用することによって均一性が高まる。しかし、サーバ FTP 実装者は、特定のシステム依存情報を送る応答テキストを適宜選択することが推奨される。
RFC-959 のこのセクションの二段落目にある "and the port used" という表記は誤り (旧式) であり、無視すべきである。
マルチホーム化されたサーバホストの場合、デフォルトのデータ転送ポート (L-1) は、ポート L への制御コネクションに対応する同じローカル IP アドレスに割り当てなければならない (MUST)。
ユーザ FTP は、FTP 制御コネクションに、SYNCH と IP 以外の如何なる Telnet 制御も送信してはならない (MUST NOT)。特に、制御コネクションで Telnet オプションの折衝を試みてはならない (MUST NOT)。しかし、サーバ FTP は、Telnet 折衝を受諾したり拒否 (すなわち DONT/WONT を送信) できなければならない (MUST)。
DISCUSSION:
RFC は "サーバとユーザの処理は、[制御コネクションでは] Telnet プロトコルの規定に従うべきである"
と述べているが、Telnet オプション折衝が用いられることは意図していない。
以下のコマンドとオプションは、下位のファイルシステムやオペレーティングシステムが特定のコマンドを許していないか、サポートしていない場合を除いて、全てのサーバ FTP とユーザ FTP がサポートしなければならない (MUST)。
タイプ: ASCII Non-print, IMAGE, LOCAL 8
モード: ストリーム
構造: ファイル、レコード(*)
コマンド:
USER, PASS, ACCT,
PORT, PASV,
TYPE, MODE, STRU,
RETR, STOR, APPE,
RNFR, RNTO, DELE,
CWD, CDUP, RMD, MKD, PWD,
LIST, NLST,
SYST, STAT,
HELP, NOOP, QUIT.
(*)レコード構造は、ファイルシステムがレコード構造をサポートしているホストのみ必要とされる (REQUIRED)。
DISCUSSION:
ベンダーは、プロトコルのより大きなサブセットを実装することが推奨される。例えば、このプロトコルには重要な頑強性を持つ機能
(例えば、再開始、ABOR、ブロックモード) が存在し、それらはインターネットユーザを補助するが、広く実装されてはいない。
ファイルシステムにレコード構造を持たないホストでも、STRU R を受け付けて、文字通りバイトスリームをレコード化してもよい。
FTP は、"X" で始まる名前を持つ "実験的な" コマンドを許している。もし、これらのコマンドが後に標準として採用されても、"X" 形式を使用する既存の実装が存在してもよい。現在、ディレクトリコマンドがこれに該当する。
RFC-959 "実験的"
MKD XMKD
RMD XRMD
PWD XPWD
CDUP XCUP
CWD XCWD
全ての FTP 実装体は、コマンド検索テーブルに余分にエントリを設けて単に等しいとみなすことによって、これらのコマンドの両方の形式を認識すべきである (SHOULD)。
IMPLEMENTATION:
ユーザ FTP が "X" 形式しかサポートしていないサーバへのアクセスを可能にするには、モード切り替えを実装するか、次の手続きを自動的に使用する。もし上記コマンドのうちの一つの
RFC-959 形式が 500 か 502 の応答コードで拒否されたら、実験形式を試す。そして、他の如何なる応答もユーザに渡す。
サーバ FTP プロセスは、もしサーバが長い間無活動 (すなわちコマンドやデータ転送が進行しない) ならば、処理を終了して制御コネクションをクローズするアイドルタイムアウトを持つべきである (SHOULD)。アイドルタイムアウト時間は設定可能であるべきであり (SHOULD)、デフォルトは少なくとも 5 分にすべきである。
クライアント FTP プロセス (RFC-959 における "User-PI") は、プログラムから起動された場合に限り、応答に対するタイムアウトを必要とする。
DISCUSSION:
タイムアウトが無ければ、もし対応するクライアントが制御コネクションをクローズせずにクラッシュしたら、サーバ FTP プロセスは永久にペンディングのままかもしれない。
DISCUSSION:
データ転送が進行中にいつでもユーザが STAT コマンドを送信できるべきであることと、サーバ FTP がこれまで転送されたバイト数等の状態を即座に応答することが、FTP
設計者の意図である。同様に、データ転送中はいつでも ABOR コマンドが可能であるべきである。
不幸にも、幾つかの小規模マシンのオペレーティグシステムでは、こうした協調プログラミングが困難であり、他の幾つかの実装者は最低限の解決方法を求めている。従って、幾つかの FTP 実装体はデータと制御コネクションの協調して使用できない。そのような最低限のサーバであっても、データ転送中に到着した STAT や ABOR コマンドを受諾する準備をしなければならない。
RFC-959 のページ 40-41 にある 110 応答の説明は誤りである。正しい説明は次の通り。受信側 FTP からユーザ FTP への制御コネクション上に送信される再開応答メッセージは、以下の形式を持つ。
110 MARK ssss = rrrr
ここでは、
符号化は、あるファイルシステムやネットワーク実装に特定であり、送信側か受信側のいずれかの同じシステムによって、常に生成され解釈される。
再開を実装した FTP がデータストリーム中に再開マーカを受信した場合、対応する位置 rrrr を符号化する前に、そのポイントまでのデータを安定したストレージに強制的に書き込むべきである (SHOULD)。再開マーカを送信する FTP は、110 応答がデータと同期して返却されると仮定してはならない (MUST NOT)。すなわち、さらにデータを送る前に 110 応答を待ってはならない。
転送の再開で発生したエラーのために、二つの新しい応答コードをここで定義する。
554 Requested action not taken: invalid REST parameter.
(要求されたアクションは行われない: 不正な REST パラメタ)
554 応答は、REST コマンドに続く FTP サービスコマンドの結果で返却してもよい。この応答は、サーバ FTP の既存のファイルは REST で指定された通りに位置を変えることができないことを示す。
555 Requested action not taken: type or stru mismatch.
(要求されたアクションは行われない: type か stru が不整合)
555 応答は、REST コマンドに続く APPE コマンドか FTP サービスコマンドの結果で返却してもよい。この応答は、現在の転送パラメタ (type か stru) と既存のファイルの属性との間に、何らかの不整合があることを示す。
DISCUSSION:
FTP 再開メカニズムは、データストリームの中に再開マーカを含めることを可能にするために、データ転送でブロックモードが圧縮モードを使用する必要があることに注意されたい。再開マーカの出現頻度は低くできる。
再開マーカはデータストリーム中の場所をマークするが、受信側はストレージに格納する時に、データに対して何らかの変換を実行してもよい。通常、受信側の符号化は、FTP データストリームの如何なる点においても、この変換を再開するために必要な全ての状態情報を含まなければならない。例えば TYPE A 転送では、ある受信側ホストは CR LF シーケンスを単一の LF 文字にディスク上に変換する。もし再開マーカがたまたま CR と LF の間にあるならば、受信側は "CR を見つけて破棄する" 状態で転送を再開しなければならない rrrr で符号化しなければならない。
再開マーカはデータのタイプに関わらず、印字可能な ASCII 文字の文字列として符号化する必要があることに注意されたい。
RFC-959 は、再開情報は "ユーザに" 返却されると述べている。これは文字通り行うべきではない。通常、ユーザ FTP は再開情報 (ssss,rrrr) を、例えば再開制御ファイルに追加する等、安定したストレージに保存すべきである。最初に転送が始まった時に空の再開制御ファイルを作成し、転送が正常に完了した時に自動的に削除すべきである。このファイルは、転送しようとしているファイル名とリモートのホスト名から、容易に識別できる方法で導き出された名前を付けることが提案されている。これは、テキストエディタの多くが "バックアップ" ファイルの名前をつけるために使用する手段に似ている。
FTP の再開には三つのケースが存在する。
このセクションは、ユーザ FTP プログラムのインタフェースを論じる。
FTP は異種環境で使用されることを意図しているので、ユーザ FTP の実装体はリモートのパス名を任意の文字列でサポートしなければならない (MUST)。よって、それらの形式や内容は、ローカルのオペレーティングシステムの約束事によって制限されない。
DISCUSSION:
特に、リモートのパス名は任意の長さになる可能性があり、空白 (0x20) だけでなく全ての印字 ASCII 文字も許さなければならない。RFC-959 は、CR と LF
を除く如何なる 7 ビット ASCII 文字も含むことを許可している。
ユーザ FTP プログラムは、任意の文字列をサーバに渡し、結果として生じた全ての応答メッセージをユーザに表示する "QUOTE" コマンドを実装しなければならない (MUST)。
"QUOTE" コマンドを有効にするには、ユーザ FTP は全てのコマンドを保持してデータ転送が開始した時にのみサーバに送信するのではなく、ユーザが転送制御コマンドを入力した時に、それらをサーバに送信すべきである (SHOULD)。
DISCUSSION:
"QUOTE" コマンドは、ユーザがシステム特定のコマンド (SITE や ALLO 等) を必要とするサーバへのアクセスを可能としたり、ユーザ FTP
に実装されていない新しいか任意の機能を呼び出すことを可能にするために重要である。例えば "QUOTE" は、たとえユーザ FTP がその TYPE
を認識しなくても、区別を必要とするホストに印刷ファイルを送信するために "TYPE A T" を指定するのに使用してもよい。
ユーザ FTP は、受信した全てのエラーメッセージのテキスト全体をユーザに表示すべきである (SHOULD)。問題の診断のために、送信する全てのコマンドや受信したテキスト全体と応答コードを表示する "冗長" モードを持つべきである (SHOULD)。
ユーザ FTP 中の状態マシンは、サーバとのコマンドの同期を維持するために、応答メッセージの欠落や期待しない応答を許すべきである (SHOULD)。
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------|---------------|-|-|-|-|-|--
TYPE N と同じなら TYPE T を実装する |4.1.2.2 | |x| | | |
可能ならファイル/レコード変換の可逆性 |4.1.2.4 | |x| | | |
ユーザ FTP はストリームモードで PORT 送信 |4.1.2.5 | |x| | | |
サーバ FTP は PASV を実装する |4.1.2.6 |x| | | | |
転送毎に PASV |4.1.2.6 |x| | | | |
NLST の応答が RETR コマンドで使用可能 |4.1.2.7 |x| | | | |
LIST と NLST の暗黙なタイプ |4.1.2.7 | |x| | | |
非標準機能で SITE コマンド |4.1.2.8 | |x| | | |
STOU コマンドは規定通りにパス名を返却する |4.1.2.9 |x| | | | |
制御コネクション上で TCP READ 境界を使う |4.1.2.10 | | | | |x|
| | | | | | |
サーバ FTP は正しい応答形式のみ使う |4.1.2.11 |x| | | | |
サーバ FTP は可能なら定義済みの応答を使う |4.1.2.11 | |x| | | |
新しいコードはセクション 4.2 に従う |4.1.2.11 | | |x| | |
ユーザ FTP は応答の最上位の数字のみ使う |4.1.2.11 | |x| | | |
ユーザ FTP は複数行の応答を処理する |4.1.2.11 |x| | | | |
ユーザ FTP は 421 応答を特別に扱う |4.1.2.11 | | | |x| |
| | | | | | |
デフォルトデータポートは制御 conn と同じIP |4.1.2.12 |x| | | | |
ユーザ FTP がSYNCH,IP以外のTelnet cmd 送信 |4.1.2.12 | | | | |x|
ユーザ FTP が Telnet オプションを折衝する |4.1.2.12 | | | | |x|
サーバ FTP が Telnet オプションを処理する |4.1.2.12 |x| | | | |
"実験的な" ディレクトリコマンドを処理する |4.1.3.1 | |x| | | |
サーバ FTP にアイドルタイムアウト |4.1.3.2 | |x| | | |
アイドルタイムアウトが設定可能 |4.1.3.2 | |x| | | |
再開マーカで受信側チェックポイントデータ |4.1.3.4 | |x| | | |
送信側は 110 応答が同期していると仮定する |4.1.3.4 | | | | |x|
| | | | | | |
サポートするタイプ: | | | | | | |
ASCII - Non-print (AN) |4.1.2.13 |x| | | | |
ASCII - Telnet (AT) - もし AN と同じなら |4.1.2.2 | |x| | | |
ASCII - キャリッジ制御 (AC) |959 3.1.1.5.2 | | |x| | |
EBCDIC - (全形式) |959 3.1.1.2 | | |x| | |
IMAGE |4.1.2.1 |x| | | | |
LOCAL 8 |4.1.2.1 |x| | | | |
LOCAL m |4.1.2.1 | | |x| | |2
| | | | | | |
サポートするモード: | | | | | | |
ストリーム |4.1.2.13 |x| | | | |
ブロック |959 3.4.2 | | |x| | |
| | | | | | |
サポートする構造: | | | | | | |
ファイル |4.1.2.13 |x| | | | |
レコード |4.1.2.13 |x| | | | |3
ページ |4.1.2.3 | | | |x| |
| | | | | | |
サポートするコマンド: | | | | | | |
USER |4.1.2.13 |x| | | | |
PASS |4.1.2.13 |x| | | | |
ACCT |4.1.2.13 |x| | | | |
CWD |4.1.2.13 |x| | | | |
CDUP |4.1.2.13 |x| | | | |
SMNT |959 5.3.1 | | |x| | |
REIN |959 5.3.1 | | |x| | |
QUIT |4.1.2.13 |x| | | | |
| | | | | | |
PORT |4.1.2.13 |x| | | | |
PASV |4.1.2.6 |x| | | | |
TYPE |4.1.2.13 |x| | | | |1
STRU |4.1.2.13 |x| | | | |1
MODE |4.1.2.13 |x| | | | |1
| | | | | | |
RETR |4.1.2.13 |x| | | | |
STOR |4.1.2.13 |x| | | | |
STOU |959 5.3.1 | | |x| | |
APPE |4.1.2.13 |x| | | | |
ALLO |959 5.3.1 | | |x| | |
REST |959 5.3.1 | | |x| | |
RNFR |4.1.2.13 |x| | | | |
RNTO |4.1.2.13 |x| | | | |
ABOR |959 5.3.1 | | |x| | |
DELE |4.1.2.13 |x| | | | |
RMD |4.1.2.13 |x| | | | |
MKD |4.1.2.13 |x| | | | |
PWD |4.1.2.13 |x| | | | |
LIST |4.1.2.13 |x| | | | |
NLST |4.1.2.13 |x| | | | |
SITE |4.1.2.8 | | |x| | |
STAT |4.1.2.13 |x| | | | |
SYST |4.1.2.13 |x| | | | |
HELP |4.1.2.13 |x| | | | |
NOOP |4.1.2.13 |x| | | | |
| | | | | | |
ユーザインタフェース: | | | | | | |
任意のパス名 |4.1.4.1 |x| | | | |
"QUOTE" コマンドを実装する |4.1.4.2 |x| | | | |
即座に転送制御コマンドを送信 |4.1.4.2 | |x| | | |
エラーメッセージをユーザに表示する |4.1.4.3 | |x| | | |
冗長モード |4.1.4.3 | |x| | | |
サーバとの同期を維持する |4.1.4.4 | |x| | | |
脚注:
簡易ファイル転送プロトコル TFTP は、RFC-783 [TFTP:1] で定義されている。
TFTP は簡単な停止/待ちの確認システムを使用し、トランスポートプロトコルとして UDP を用いて信頼性のある送信を提供する。TFTP は実効ウィンドウを 512 オクテットのセグメント一つしか持たないので、遅延や帯域が小さい製品のあるパス上でのみ優れたパフォーマンスを提供できる。TFTP ファイルインタフェースは非常に簡単であり、アクセス制御やセキュリティは提供しない。
TFTP は EPROM に簡単に実装できるほど単純で小さいので、TFTP の最も重要なアプリケーションは、ローカルネットワーク上のホストのブートストラップである [BOOT:1], [BOOT:2]。ベンダは、ブート処理のために TFTP をサポートすることが推奨される。
TFTP 規定 [TFTP:1] はオープンスタイルで記述されており、このプロトコルの大部分を完全には規定していない
転送モード "mail" をサポートすべきではない (SHOULD NOT)。
UDP ヘッダの Length フィールドが誤って定義されている。これは UDP ヘッダ長 (8) を含む。
このプロトコル規定には、"魔法使いの弟子シンドローム" として知られる重大なバグが存在する。これは転送の不正な処理は引き起こさない (もし転送が完了すれば、ファイルは常に正しく転送される) が、このバグにより過度の再送が発生するかもしれず、それによって転送がタイムアウトになるかもしれない。
実装体は、この問題に対して次の修正を含まなければならない (MUST): 送信側 (すなわち DATA パケットを起動する側) は、重複 ACK 受信時に現在の DATA パケットを再送してはならない。
DISCUSSION:
このバグは、古い重複データグラムを受信したら、いずれかの側は現在のデータグラムを再送してもよいというプロトコル規則によって発生する。もしパケットがネットワーク内で遅れたが、いずれかの側でタイムアウトになってパケットを再送した後に正常に送信されたら、重複した応答の複製が生成されるかもしれない。もし、もう一方の側がこの重複に自身の重複で応答したら、残りの転送で全てのデータグラムが重複して送信されるだろう
(もし複製が壊れてデータグラムが消失しなければ)。なお悪いことに、遅延は輻輳によってしばしば発生するので、この重複転送によって更に輻輳になり、更にバケット遅延を招くだろう。
以下の例は、この問題を明確にする助けになるかもしれない。
TFTP A TFTP B
(1) ACK X-1 受信
DATA X 送信
(2) DATA X 受信
ACK X 送信
(ACK X がネットワーク内で遅延し、A がタイムアウト):
(3) DATA X 再送
(4) 再度 DATA X 受信
再度 ACK X 送信
(5) (遅れた) ACK X 受信
DATA X+1 送信
(6) DATA X+1 受信
ACK X+1 送信
(7) 再度 ACK X 受信
再度 DATA X+1 送信
(8) 再度 DATA X+1 受信
再度 ACK X+1 送信
(9) ACK X+1 受信
DATA X+2 送信
(10) DATA X+2 受信
ACK X+3 送信
(11) 再度 ACK X+1 受信
再度 DATA X+2 送信
(12) 再度 DATA X+2 受信
再度 ACK X+3 送信
一旦遅れた ACK が到着すると、このプロトコルは、以降の全てのパケット (シーケンス 5-8 と 9-12) が重複されることに注意されたい。この問題はいずれかの側がタイムアウトすることによって引き起こされるのではなく、両方の側が重複を受信した時に、現在のパケットを再送することにより発生する。
修正は上記で示されているように、再送ループを破ることである。これは、TCP の振る舞いと似通っている。そして、再送された ACK により何の動作も起こらないので、受信側で再送タイマを除くことができる。これは、TFTP がブートストラッププログラムで使われる場合に簡略化できて効果的である。タイマを残すことも OK であり、再送された ACK が本当にネットワークで消失されたものに置き換えられるならば、便利かもしれない。もちろん、送信側は依然として再送タイマが必要である。
TFTP は適応可能なタイムアウトを使用しなければならない (MUST)。
IMPLEMENTATION:
TCP の再送アルゴリズムは、動作の効果的な基礎を提供する。少なくとも、再送タイムアウトの指数関数的な緩和は必要である。
転送モードの追加やセキュリティを確保する操作モード (パスワード付き) を含め、様々な非標準の拡張が TFTP に施されている。これらのどれも標準化されてはいない。
サーバ TFTP 実装体は、何のパス名が TFTP 運用で許可されているかについて、何らかの設定可能なアクセス制御を含むべきである (SHOULD)。
ブロードキャストアドレス宛ての TFTP 要求は、黙って破棄すべきである (SHOULD)。
DISCUSSION:
TFTP はアクセス制御が脆弱であるため、任意のネットワークの TFTP 要求の直接ブロードキャストは、重大なセキュリティホールを生む可能性がある。
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------------|--------|-|-|-|-|-|--
魔法使いの弟子シンドロームの修正 |4.2.3.1 |x| | | | |
転送モード: | | | | | | |
netascii |RFC-783 |x| | | | |
octet |RFC-783 |x| | | | |
mail |4.2.2.1 | | | |x| |
拡張 |4.2.3.3 | | |x| | |
適応可能なタイムアウトを使用する |4.2.3.2 |x| | | | |
設定可能なアクセス制御 |4.2.3.4 | |x| | | |
ブロードキャスト要求を黙って破棄 |4.2.3.5 | |x| | | |
-------------------------------------------------|--------|-|-|-|-|-|--
-------------------------------------------------|--------|-|-|-|-|-|--