Internet Engineering Task Force (IETF) I. van Beijnum
Request for Comments: 6384 Institute IMDEA Networks
Category: Standards Track October 2011
ISSN: 2070-1721
An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
用のFTPアプリケーション層ゲートウェイ（ALG）は、IPv6からIPv4翻訳
Abstract
抽象
The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.
ファイル転送プロトコル（FTP）は、非常に長い歴史を持っており、今日の他のオプションは、ファイル転送を実行するために存在するという事実にもかかわらず、FTPは一般的な使用のままです。そのため、いくつかのクライアントコンピュータにのみIPv6接続を持っている状況では、多くのサーバーがまだIPv4のみとIPv6からIPv4トランスレータは、そのギャップを埋めるために使用されている間、FTPが最高にこれらのトランスレータを介して動作させることが重要です可能な限り。
FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch.
FTPは、IPv4固有のもの元のコマンドとして、拡張、IPバージョン依存しないコマンドの両方、アクティブおよびパッシブモードを有しています。 IPv6のツーのIPv4トランスレーターによる変更なしで動作のみFTPモードをパッシブに拡張されます。しかし、多くの既存のFTPサーバーでは、このモードをサポートしていない、といくつかのクライアントがそれを要求しません。この文書では、この不一致を解決することがミドルを指定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、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/rfc6384.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6384で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. ALG Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Control Channel Translation . . . . . . . . . . . . . . . . . 5
5.1. Language Negotiation . . . . . . . . . . . . . . . . . . . 7
6. EPSV to PASV Translation . . . . . . . . . . . . . . . . . . . 8
7. EPRT to PORT Translation . . . . . . . . . . . . . . . . . . . 9
7.1. Stateless EPRT Translation . . . . . . . . . . . . . . . . 9
7.2. Stateful EPRT Translation . . . . . . . . . . . . . . . . 10
8. Default Port 20 Translation . . . . . . . . . . . . . . . . . 10
9. Both PORT and PASV . . . . . . . . . . . . . . . . . . . . . . 11
10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
11. The ALGS Command . . . . . . . . . . . . . . . . . . . . . . . 12
12. Timeouts and Translating to NOOP . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
17.1. Normative References . . . . . . . . . . . . . . . . . . . 15
17.2. Informative References . . . . . . . . . . . . . . . . . . 15
[RFC0959] specifies two modes of operation for FTP: active mode, in which the server connects back to the client, and passive mode, in which the server opens a port for the client to connect to. Without additional measures, active mode with a client-supplied port does not work through NATs or firewalls. With active mode, the PORT command has an IPv4 address as its argument, and with passive mode, the server responds to the PASV command with an IPv4 address. This makes both the passive and active modes, as originally specified in [RFC0959], incompatible with IPv6. These issues were solved in [RFC2428], which introduces the EPSV (extended passive) command, where the server only responds with a port number and the EPRT (extended port) command, which allows the client to supply either an IPv4 or an IPv6 address (and a port) to the server.
サーバがクライアントに戻って接続しているアクティブモード、パッシブモード、サーバは、クライアント接続するためのポートを開放する：[RFC0959]はFTP用の2つの動作モードを指定します。追加措置がなければ、クライアントが提供するポートを備えたアクティブモードは、NATのか、ファイアウォール経由で動作しません。アクティブモードでは、PORTコマンドは、引数としてIPv4アドレスを持ち、パッシブモードでは、サーバは、IPv4アドレスとPASVコマンドに応答します。本来のIPv6と互換性がない、[RFC0959]で指定されるように、これは、両方の受動及び能動モードとなります。これらの問題は、クライアントがIPv4またはIPv6アドレスのいずれかを供給することを可能にする、サーバのみポート番号とEPRT（拡張ポート）コマンドで応答EPSV（拡張パッシブ）コマンドを導入する、[RFC2428]に溶解しました。 （およびポート）サーバへ。
A survey done in April 2009 of 25 randomly picked and/or well-known FTP sites reachable over IPv4 showed that only 12 of them supported EPSV over IPv4. Additionally, only 2 of those 12 indicated that they supported EPSV in response to the FEAT command introduced in [RFC2389] that asks the server to list its supported features. One supported EPSV but not FEAT. In 5 cases, issuing the EPSV command to the server led to a significant delay; in 3 of these cases, a control channel reset followed the delay. Due to lack of additional information, it is impossible to determine conclusively why certain FTP servers reset the control channel connection some time after issuing an EPSV command. However, a reasonable explanation would be that these FTP servers are located behind application-aware firewalls that monitor the control channel session and only allow the creation of data channel sessions to the ports listed in the responses to PASV (and maybe PORT) commands. As the response to an EPSV command is different (a 229 code rather than a 227 code), a firewall that is unaware of the EPSV command would block the subsequent data channel setup attempt. If no data channel connection has been established after some time, the FTP server may decide to terminate the control channel session in an attempt to leave this ambiguous state.
2009年4月に行われる調査では、25のランダムに選択および/またはIPv4オーバー到達可能な、よく知られているFTPサイトは、それらの唯一の12は、IPv4上でEPSVをサポートすることを示しました。さらに、これらの12のわずか2は、それらがサポートされている機能をリストにサーバに要求する[RFC2389]に導入FEATコマンドに応答してEPSVをサポートすることを示しました。一つはEPSVではなく、FEATを支持しました。 5例では、大幅な遅延につながったサーバにEPSVコマンドを発行します。これらの場合の3で、制御チャネルリセットは、遅延に従いました。追加的な情報の不足のために、特定のFTPサーバがいくつかの時間EPSVコマンドを発行した後、制御チャネル接続をリセット理由を決定的に決定することは不可能です。しかし、合理的な説明は、これらのFTPサーバが制御チャネルセッションを監視し、のみPASV（多分PORT）コマンドに応答に記載されているポートにデータチャネルセッションの作成を許可するアプリケーションアウェアファイアウォールの背後に配置されているということでしょう。 EPSVコマンドに対する応答が異なるように（229コードではなく、227コード）、次のデータチャネル設定の試みをブロックするEPSVコマンドを認識しないファイアウォール。何のデータチャネル接続はいくつかの時間後に確立されていない場合、FTPサーバは、このあいまいな状態のままにしようとする試みで制御チャネルセッションを終了することを決定することができます。
All 25 tested servers were able to successfully complete a transfer in traditional PASV passive mode as required by [RFC1123]. More testing showed that the use of an address family argument with the EPSV command is widely misimplemented or unimplemented in servers. Additional tests with more servers showed that approximately 65% of FTP servers support EPSV successfully and around 96% support PASV successfully. Clients were not extensively tested, but the author's previous experience suggests that most clients support PASV, with the notable exception of the command line client included with Windows, which only supports active mode. This FTP client uses the original PORT command when running over IPv4 and EPRT when running over IPv6.
[RFC1123]で必要とされるすべての25台のテストサーバーでは成功し、従来のPASVパッシブモードで転送を完了することができました。より多くのテストがEPSVコマンドとアドレスファミリ引数の使用は、サーバで広くmisimplementedまたは未実装であることを示しました。複数のサーバーで追加のテストでは、FTPサーバの約65％が正常にEPSVに成功し、周りの96％サポートPASVをサポートすることを示しました。クライアントは、広範囲にテストされていないが、筆者の経験では、ほとんどのクライアントが唯一のアクティブモードをサポートするWindowsに付属のコマンドラインクライアントの顕著な例外を除いて、PASVをサポートすることを示唆しています。 IPv6の上で実行している場合、IPv4とEPRT上で実行している場合は、このFTPクライアントは元PORTコマンドを使用しています。
Although these issues can and should be addressed by modifying clients and servers to support EPSV successfully, such modifications may not appear widely in a timely fashion. Also, network operators who may want to deploy IPv6-to-IPv4 translation generally do not have control over client or server implementations. As such, this document standardizes an FTP Application Layer Gateway (ALG) that will allow unmodified IPv6 FTP clients to interact with unmodified IPv4 FTP servers successfully when using FTP for simple file transfers between a single client and a single server.
これらの問題は、正常にEPSVをサポートするために、クライアントとサーバを変更することで対処すべきことができますが、そのような変更はタイムリーに広く表示されない場合があります。また、IPv6のツーIPv4の変換を展開することをお勧めしますネットワークオペレータは、一般的に、クライアントまたはサーバの実装を制御できません。そのため、このドキュメントは、単一のクライアントと単一のサーバ間の簡単なファイル転送にFTPを使用するときに変更されていないIPv6のFTPクライアントが正常に変更されていないIPv4のFTPサーバと対話することができますFTPのアプリケーションレイヤゲートウェイ（ALG）を標準化しています。
Clients that want to engage in more complex behavior, such as server-to-server transfers, may make an FTP Application Layer Gateway (ALG) go into transparent mode by issuing the ALGS command as explained in Section 5.
ようなサーバからサーバへの転送など、より複雑な挙動を、に従事したいクライアントは、FTPアプリケーションレイヤゲートウェイ（ALG）は第5節で説明したようにのALGコマンドを発行することにより、透過モードに入ることがあります。
The recommendations and specifications in this document apply to all forms of IPv6-to-IPv4 translation, including stateless translation such as [RFC6145] as well as stateful translation such as [RFC6146].
この文書に記載されている推奨および仕様は、[RFC6145]としてステートレス翻訳ならびに[RFC6146]などのステートフルな翻訳などのIPv6からIPv4翻訳の全ての形態に適用されます。
This documentation does not deal with the LPRT and LPSV commands specified in [RFC1639] as these commands do not appear to be in significant use.
これらのコマンドのように[RFC1639]で指定LPRTとLPSVコマンドを扱っていないこのドキュメントでは、重要な用途であることを表示されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Within the context of this document, the words "client" and "server" refer to FTP client and server implementations, respectively. An FTP server is understood to be an implementation of the FTP protocol running on a server system with a stable address, waiting for clients to connect and issue commands that eventually start data transfers. Clients interact with servers using the FTP protocol; they store (upload) files to and retrieve (download) files from one or more servers. This either happens interactively under control of a user or is done as an unattended background process. Most operating systems provide a web browser that implements a basic FTP client as well as a command line client. Third-party FTP clients are also widely available.
この文書の文脈の中で、言葉「クライアント」と「サーバー」は、それぞれ、FTPクライアントとサーバーの実装を参照してください。 FTPサーバは、クライアントが最終的にデータ転送を開始するコマンドを接続して、問題のを待って、安定したアドレスを使用してサーバ・システム上で実行されているFTPプロトコルの実装であると理解されます。クライアントは、FTPプロトコルを使用してサーバーと対話します。彼らがに（アップロード）ファイルを保存し、1つまたは複数のサーバーから（ダウンロード）ファイルを取得します。これは、どちらかの対話的にユーザーの制御下で起こるか、無人のバックグラウンド・プロセスとして実行されます。ほとんどのオペレーティングシステムは、基本的なFTPクライアントを実装し、Webブラウザだけでなく、コマンドラインクライアントを提供しています。サードパーティ製のFTPクライアントも広く入手可能です。
Other terminology is derived from the documents listed in the References section. Note that this document cannot be fully understood on its own; it depends on background and terminology outlined in the references.
他の用語は、参照のセクションに記載された文書から導出されます。この文書は、完全に自分自身で理解することができないことに注意してください。それは参考文献に概説された背景や用語に依存します。
The most robust way to solve an IP version mismatch between FTP clients and FTP servers would be by changing clients and servers rather than using an IPv6-to-IPv4 translator for the data channel and using an Application Layer Gateway on the control channel. As such, it is recommended to update FTP clients and servers as required for IPv6-to-IPv4 translation support where possible to allow proper operation of the FTP protocol without the need for ALGs.
FTPクライアントとFTPサーバ間のIPバージョンの不一致を解決するための最も強力な方法は、クライアントとサーバーを変更するのではなく、データチャネルのためのIPv6からIPv4トランスレータを使用し、制御チャネル上のアプリケーションレイヤゲートウェイを使用することによりだろう。このように、のALGを必要とせずにFTPプロトコルの適切な動作を可能にする可能性のIPv6からIPv4翻訳支援のために必要とされるFTPクライアントとサーバーを更新することをお勧めします。
On the other hand, network operators or even network administrators within an organization often have little influence over the FTP client and server implementations used over the network. For those operators and administrators, deploying an ALG may be the only way to provide a satisfactory customer experience. So, even though not the preferred solution, this document standardizes the functionality of such an ALG in order to promote consistent behavior between ALGs in an effort to minimize their harmful effects.
一方、組織内のネットワークオペレータあるいはネットワーク管理者は、多くの場合、ネットワーク上で使用するFTPクライアントとサーバ実装の上にほとんど影響を与えません。 ALGを展開し、それらの事業者や管理者については、十分な顧客体験を提供する唯一の方法かもしれません。だから、さえない好ましい解決策が、この文書では、彼らの有害な影響を最小限に抑えるためにのALGの間で一貫性のある行動を促進するために、このようなALGの機能を標準化しています。
Operators and administrators are encouraged to only deploy an FTP ALG for IPv6-to-IPv4 translation when the FTP ALG is clearly needed. In the presence of the ALG, EPSV commands that could be handled directly by conforming servers are translated into PASV commands, introducing additional complexity and reducing robustness. As such, a "set and forget" policy on ALGs is not recommended.
オペレータや管理者は、FTP ALGが明らかに必要とされている場合のみのIPv6からIPv4変換のためのFTP ALGを展開することをお勧めします。 ALGの存在下で、サーバーを適合することによって直接処理することができるEPSVコマンドは、付加的な複雑さを導入し、堅牢性を低下させる、PASVコマンドに翻訳されます。そのため、のALG on「に設定し、忘れる」ポリシーが推奨されていません。
Note that the translation of EPSV through all translators and EPRT through a stateless translator is relatively simple, but supporting translation of EPRT through a stateful translator is relatively difficult, because in the latter case, a translation mapping must be set up for each data transfer using parameters that must be learned from the client/server interaction over the control channel. This needs to happen before the EPRT command can be translated into a PORT command and passed on to the server. As such, an ALG used with a stateful translator MUST support EPSV translation and MAY support EPRT translation. However, an ALG used with a stateless translator MUST support EPSV translation and SHOULD also support EPRT translation.
ステートレス翻訳を介してすべての翻訳とEPRTスルーEPSVの翻訳が比較的簡単であるが、後者の場合には、変換マッピングを使用して、各データ転送用に設定されなければならないので、ステートフルなトランスレータを通じてEPRTの翻訳をサポートする、比較的困難であることに注意してください制御チャネルを介してクライアント/サーバの対話から学ばなければなりませんパラメーター。これはEPRTコマンドはPORTコマンドに変換してサーバーに渡すことができる前に発生する必要があります。そのため、ステートフルな翻訳者と一緒に使用ALGはEPSV変換をサポートしなければならないとEPRTの変換をサポートするかもしれません。しかし、ALGはEPSV翻訳をサポートしなければならないステートレス翻訳者と一緒に使用してもEPRTの翻訳をサポートする必要があります。
The ALG functionality is described as a function separate from the IPv6-to-IPv4 translation function. However, in the case of EPRT translation, the ALG and translator functions need to be tightly coupled, so if EPRT translation is supported, it is assumed that the ALG and IPv6-to-IPv4 translation functions are integrated within a single device.
ALG機能は、IPv6からIPv4変換機能とは別の関数として記述されます。しかし、EPRT翻訳の場合には、ALGと翻訳機能は、EPRT変換がサポートされているので、もし、ALGおよびIPv6からIPv4変換機能を単一の装置内に一体化されているものと、密結合される必要があります。
The IPv6-to-IPv4 FTP ALG intercepts all TCP sessions towards port 21 for IPv6 destination addresses that map to IPv4 destinations reachable through an IPv6-to-IPv4 translator. The FTP ALG implements the Telnet protocol ([RFC0854]), used for control channel interactions, to the degree necessary to interpret commands and responses and re-issue those commands and responses, modifying them as outlined below. Telnet option negotiation attempts by either the client or the server, except for those allowed by [RFC1123], MUST be refused by the FTP ALG without relaying those attempts. For the purpose of Telnet option negotiation, an FTP ALG MUST follow the behavior of an FTP server as specified in [RFC1123], Section 4.1.2.12. This avoids the situation where the client and the server negotiate Telnet options that are unimplemented by the FTP ALG.
IPv6のツーのIPv4 FTP ALGは、IPv6からIPv4トランスレーターを介して到達可能なIPv4の宛先にマップIPv6宛先アドレスに対してポート21に向けて、すべてのTCPセッションをインターセプトします。 FTP ALGは、Telnetプロトコルを実装する（[RFC0854]）、以下に概説するように、それらを変更、コマンドおよび応答と再発行それらのコマンドと応答を解釈するために必要な程度に、制御チャネルの相互作用のために使用されます。クライアントまたはサーバーのいずれかによるTelnetオプション交渉の試みは、[RFC1123]で許可されているものを除き、これらの試みを中継せずにFTP ALGによって拒否されなければなりません。 [RFC1123]で指定されたTelnetオプション交渉の目的のために、FTP ALGは、セクション4.1.2.12をFTPサーバの動作に従わなければなりません。これは、クライアントとサーバがFTP ALGによって実装されていないTelnetのオプションを交渉状況を避けることができます。
There are two ways to implement the control channel ALG:
制御チャネルALGを実装する方法は2つあります。
1. The ALG terminates the IPv6 TCP session, sets up a new IPv4 TCP session towards the IPv4 FTP server, and relays commands and responses back and forth between the two sessions.
1. ALGは、IPv6のTCPセッションを終了IPv4のFTPサーバーへの新しいIPv4のTCPセッションを設定し、前後に二つのセッションの間のコマンドと応答を中継します。
2. Packets that are part of the control channel are translated individually.
制御チャネルの一部である2パケットは個別に翻訳されます。
As they ultimately provide the same result, either implementation strategy, or any other that is functionally equivalent, can be used.
彼らは最終的に同じ結果を提供するように、機能的に等価な実装戦略、または他の任意のいずれかを使用することができます。
In the second case, an implementation MUST have the ability to track and update TCP sequence numbers when translating packets as well as the ability to break up packets into smaller packets after translation, as the control channel translation could modify the length of the payload portion of the packets in question. Also, FTP commands/responses or Telnet negotiations could straddle packet boundaries, so in order to be able to perform the ALG function, it can prove necessary to reconstitute Telnet negotiations and FTP commands and responses from multiple packets.
制御チャネル翻訳のペイロード部分の長さを修正することができるように、第2のケースでは、実装は、パケットを変換するときにTCPシーケンス番号を追跡し、更新する能力、ならびに翻訳後より小さいパケットにパケットを破壊する能力を持たなければなりません問題のパケット。 ALG機能を実行できるようにするために、それは複数のパケットからのTelnet交渉やFTPコマンドと応答を再構成するために必要な証明することができますので、また、FTPコマンド/応答またはTelnet交渉は、パケット境界をまたぐことができます。
Some FTP clients use the TCP urgent data feature when interrupting transfers. An ALG MUST either maintain the semantics of the urgent pointer when translating control channel interactions, even when crossing packet boundaries, or clear the URG bit in the TCP header.
転送を中断すると、一部のFTPクライアントは、TCP緊急データ機能を使用します。 ALGは、制御チャネルの相互作用を変換するとき、パケット境界に交差する場合であっても、緊急ポインタのセマンティクスを維持する、またはTCPヘッダにURGビットをクリアする必要があります。
If the client issues the AUTH command, then the client is attempting to negotiate [RFC2228] security mechanisms that are likely to be incompatible with the FTP ALG function. For instance, if the client attempts to negotiate Transport Layer Security (TLS) protection of the control channel ([RFC4217]), an ALG can do one of three things:
クライアントがAUTHコマンドを発行した場合、クライアントはFTP ALG機能と互換性がない可能性がある[RFC2228]のセキュリティメカニズムを交渉しようとしています。クライアントは、制御チャネル（[RFC4217]）のトランスポート層セキュリティ（TLS）の保護を交渉しようとした場合例えば、ALGは、3つのいずれかを行うことができます。
1. Transparently copy data transmitted over the control channel back and forth, so the TLS session works as expected but the client commands and server responses are now hidden from the ALG.
予想されるが、クライアントコマンドとサーバー応答は今ALGから隠されているとTLSセッションが動作しますので、1は透過的に、前後に制御チャネルを介して送信されるデータをコピーします。
2. Block the negotiation of additional security, which will likely make the client and/or the server break off the session, or if not, perform actions in the clear that were supposed to be encrypted.
2.ブロック可能性が高いクライアントおよび/またはサーバがセッションを断つ、またはそうでない場合は、暗号化されることになった明確でアクションを実行するようになります追加のセキュリティの交渉。
3. Negotiate with both the client and the server so two separate protected sessions are set up and the ALG is still able to modify client commands and server responses. Again, clients and servers are likely to reject the session because this will be perceived as a man-in-the-middle attack.
3.クライアント2つの別々の保護されたセッションが設定されているとALGはまだクライアントコマンドとサーバー応答を変更することができますので、サーバーの両方と交渉。これは、man-in-the-middle攻撃として認識されますので、ここでも、クライアントとサーバはセッションを拒否する可能性があります。
An ALG MUST adopt the first option and allow a client and a server to negotiate security mechanisms. To ensure consistent behavior, as soon as the initial AUTH command is issued by the client, an ALG MUST stop translating commands and responses, and start transparently copying TCP data sent by the server to the client and vice versa. The ALG SHOULD ignore the AUTH command and not go into transparent mode if the server response is in the 4xx or 5xx ranges.
ALGは、最初のオプションを採用し、クライアントとサーバは、セキュリティ・メカニズムを交渉することを可能にしなければなりません。動作の一貫性を確保するために、できるだけ早く初期のAUTHコマンドがクライアントによって発行されたとして、ALGはコマンドと応答を翻訳するのを止めなければなりません、そして、クライアントとその逆にサーバから送信されたTCPデータのコピーを透過的に開始します。 ALGは、AUTHコマンドを無視して、サーバーの応答が4XXまたは5xxの範囲内であれば透過モードに入るべきではありません。
It is possible that commands or responses that were sent through the ALG before the AUTH command was issued were changed in length so TCP sequence numbers in packets entering the ALG and packets exiting the ALG no longer match. In transparent mode, the ALG MUST continue to adjust sequence numbers if it was doing so before entering transparent mode as the result of the AUTH command. The ALGS command (Section 11) can also be used to disable the ALG functionality, but the control channel MUST then still be monitored for subsequent ALGS commands that re-enable the ALG functionality.
コマンドやALGに入るパケットとパケット内のTCPシーケンス番号がALGもはや試合を終了するので、AUTHコマンドが発行される前ALGを介して送信された応答は、長さが変更された可能性があります。透過モードでは、ALGは、AUTHコマンドの結果として、透過モードに入る前にそうされた場合のシーケンス番号を調整し続けなければなりません。 ALGコマンド（セクション11）は、ALG機能を無効にするために使用することができるが、制御チャネルが依然として後続のALGのために監視されなければならないALG機能を再度有効にすることを指示します。
[RFC2640] specifies the ability for clients and servers to negotiate the language used between the two of them in the descriptive text that accompanies server response codes. Ideally, IPv6-to-IPv4 FTP ALGs would support this feature, so that if a non-default language is negotiated by a client and a server, the ALG also transmits its text messages for translated responses in the negotiated language. However, even if the ALG supports negotiation of the feature, there is no way to make sure that the ALG has text strings for all possible languages. Thus, the situation where the client and server try to negotiate a language not supported by the ALG is unavoidable. The proper behavior for an FTP ALG in this situation may be addressed in a future specification, as the same issue is present in IPv4-to-IPv4 FTP ALGs. For the time being, ALG implementations MAY employ one of the following strategies regarding LANG negotiation:
[RFC2640]は、サーバの応答コードに付随する説明テキストでそれらのうちの2つの間に使用される言語を交渉するために、クライアントとサーバーのための能力を指定します。デフォルト以外の言語は、クライアントとサーバによって交渉されている場合、ALGはまた交渉した言語で翻訳された応答のためのテキストメッセージを送信するように理想的には、IPv6のツーのIPv4 FTPのALGは、この機能をサポートしています。しかし、ALGは、機能のネゴシエーションをサポートしている場合でも、ALGはすべての可能な言語のテキスト文字列を持っていることを確認する方法はありません。このように、クライアントとサーバはALGによってサポートされていない言語を交渉しようとする状況は避けられません。同じ問題は、IPv4からIPv4 FTPのALGに存在しているとして、このような状況でFTP ALGのための適切な行動は、将来の仕様で対処することができます。当分の間、ALG実装はLANGの交渉については、次の方法のいずれかを採用することができます。
1. Monitor LANG negotiation and send text in the negotiated language if text in that language is available. If not, text is sent in the default language.
1.モニターLANG交渉とその言語のテキストが利用可能な場合に交渉言語のテキストを送信します。ない場合は、テキストはデフォルトの言語で送信されます。
2. Not monitor LANG negotiation. Text is sent in the default language.
2. LANGネゴシエーションを監視していません。テキストはデフォルトの言語で送信されます。
3. Block LANG negotiation by translating the LANG command to a NOOP command and translating the resulting 200 response into a 502 response, which is appropriate for unsupported commands. Text is sent in the default language.
NOOPコマンドにLANGコマンドを変換し、サポートされていないコマンドに適した502応答、に得られた200応答を翻訳することにより、3ブロックLANGネゴシエーション。テキストはデフォルトの言語で送信されます。
In the first two cases, if a language is negotiated, text transmitted by the client or the server MUST be assumed to be encoded in UTF-8 [RFC3629] rather than be limited to 7-bit ASCII. An ALG that implements the first or second option MUST translate and/or forward commands and responses containing UTF-8-encoded text when those occur. The ALG itself MUST NOT generate characters outside the 7-bit ASCII range unless it implements the first option and a language was negotiated.
最初の2つの場合に言語がネゴシエートされている場合、クライアントまたはサーバによって送信されたテキストは、UTF-8でエンコードされると仮定しなければなりません[RFC3629]はなく7ビットASCIIに限定されます。最初または2番目のオプションを実装しALGは、翻訳および/またはそれらが発生したときUTF-8でエンコードされたテキストを含むコマンドと応答を転送する必要があります。それは最初のオプションを実装し、言語がネゴシエートされた場合を除きALG自体は7ビットASCII範囲外の文字を生成してはなりません。
Note that Section 3.1 of [RFC2640] specifies new handling for spaces and the carriage return (CR) character in pathnames. ALGs that do not block LANG negotiation SHOULD comply with the specified rules for path handling. Implementers should especially note that the NUL (%x00) character is used as an escape whenever a CR character occurs in a pathname.
[RFC2640]は新しいスペースの取り扱いやパス名にキャリッジリターン（CR）文字を指定することセクション3.1に注意してください。 LANGネゴシエーションをブロックしないのALGは、パスの処理のための指定されたルールに従うべき。実装は、特にCRキャラクタがパス名で発生するたびにNUL（％のX00）文字はエスケープとして使用されていることに注意すべきです。
In the sections that follow, a number of well-known response numbers are shown, along with the descriptive text that is associated with that response number. However, this text is not part of the specification of the response. As such, implementations MAY use the response text shown, or they MAY show a different response text for a given response number. Requirements language only applies to the response number.
以下のセクションでは、よく知られた応答番号の数は、その応答番号に関連付けられている説明文と共に、示されています。しかし、このテキストは、応答の仕様の一部ではありません。このように、実装が示さ応答テキストを使用してもよく、またはそれらは、与えられた応答数の異なる応答テキストを示すことができます。要件の言語は、応答番号に適用されます。
Although many IPv4 FTP servers support the EPSV command, some servers react adversely to this command (see Section 1 for examples), and there is no reliable way to detect in advance that this will happen. As such, an FTP ALG SHOULD translate all occurrences of the EPSV command issued by the client to the PASV command and reformat a 227 response as a corresponding 229 response. However, an ALG MAY forego EPSV to PASV translation if it has positive knowledge, either gained through administrative configuration or learned dynamically, that EPSV will be successful without translation to PASV.
多くのIPv4のFTPサーバがEPSVコマンドをサポートしていますが、一部のサーバーでは、このコマンド（例については、セクション1を参照）に不利に反応し、この現象が発生することを事前に検知する信頼できる方法はありません。そのため、FTP ALGはPASVコマンドにクライアントから発行されたEPSVコマンドのすべてのオカレンスを翻訳し、対応する229レスポンスとして227応答を再フォーマットする必要があります。 EPSVがPASVへの変換せずに成功すること、それが正の知識を持っている場合は、ALGはPASV翻訳にEPSVを放棄するかもしれ、いずれかの動的管理構成を通じて得られたかを学びました。
For instance, if the client issues EPSV (or EPSV 2 to indicate IPv6 as the network protocol), this is translated to the PASV command. If the server with address 192.0.2.31 then responds with:
クライアントは、（ネットワークプロトコルとしてIPv6を示すために、またはEPSV 2）EPSVを発行した場合、例えば、これは、PASVコマンドに変換されます。アドレス192.0.2.31を持つサーバは、その後で応答した場合：
227 Entering Passive Mode (192,0,2,31,237,19)
パッシブモードに入る227（192,0,2,31,237,19）
The FTP ALG reformats this as:
FTP ALGは、これを再フォーマット：
229 Entering Extended Passive Mode (|||60691|)
229はパッシブモードを拡張入力（||| 60691 |）
The ALG SHOULD ignore the IPv4 address in the server's 227 response. This is the behavior that is exhibited by most clients and is needed to work with servers that include [RFC1918] addresses in their 227 responses. However, if the 227 response contains an IPv4 address that does not match the destination of the control channel, the FTP ALG MAY send a 425 response to the client instead of the 229 response, for example:
ALGは、サーバーの227応答でIPv4アドレスを無視します。これは、ほとんどのクライアントで展示されており、その227の応答で[RFC1918]アドレスを含むサーバで動作するために必要とされる動作です。 227応答は、制御チャネルの送信先と一致していないIPv4アドレスが含まれている場合は、FTP ALGは、たとえば、代わりに229応答をクライアントに425応答を送ることがあります。
425 Can't open data connection
425データ接続を開くことができません。
It is important that the response is in the 4xx range to indicate a temporary condition.
応答が一時的な状態を示すために、4xxの範囲であることが重要です。
If the client issues an EPSV command with a numeric argument other than 2, the ALG MUST NOT pass the command on to the server but rather respond with a 522 error, for example:
クライアントが2以外の数値引数でEPSVコマンドを発行すると、ALGは、サーバーにコマンドを渡してはならないのではなく、たとえば、522エラーで応答します。
522 Network protocol not supported
522ネットワーク・プロトコルがサポートされていません
If the client issues EPSV ALL, the FTP ALG MUST NOT pass this command to the server, but respond with a 504 error, for example:
クライアントの問題がALL EPSV場合は、FTP ALGは、サーバには、このコマンドを渡してはならないが、例えば、504エラーで応答します。
504 Command not implemented for that parameter
504コマンドはそのパラメータに実装されていません
This avoids the situation where an FTP server reacts adversely to receiving a PASV command after the client used the EPSV ALL command to indicate that it will only use EPSV during this session.
これは、FTPサーバ、クライアントはそれだけでこのセッション中にEPSVを使用することを示すためにEPSV ALLコマンドを使用した後にPASVコマンドを受信したことに不利に反応する事態を回避することができます。
Should the IPv6 client issue an EPRT command, the FTP ALG MAY translate this EPRT command to a PORT command. The translation is different depending on whether the translator is a stateless one-to-one translator or a stateful one-to-many translator.
IPv6クライアントの問題EPRTコマンドは、FTP ALGは、PORTコマンドにこのEPRTコマンドを翻訳することができるはずです。翻訳は翻訳者がステートレス一対一の翻訳者またはステートフル1対多の翻訳者であるかどうかに応じて異なります。
If the address specified in the EPRT command is the IPv6 address used by the client for the control channel session, then the FTP ALG reformats the EPRT command into a PORT command with the IPv4 address that maps to the client's IPv6 address. The port number MUST be preserved for compatibility with stateless translators. For instance, if the client with IPv6 address 2001:db8:2::31 issues the following EPRT command:
EPRTコマンドで指定されたアドレスは、制御チャネルセッションのためにクライアントによって使用されるIPv6アドレスの場合は、FTP ALGは、クライアントのIPv6アドレスにマップIPv4アドレスとPORTコマンドにEPRTコマンドを再フォーマットします。ポート番号は、ステートレス翻訳者との互換性のために保存されなければなりません。たとえば、IPv6アドレス2001とクライアントの場合：DB8：2 :: 31の問題次EPRTコマンド：
EPRT |2|2001:db8:2::31|5282|
EPRT | 2 | 2001：DB8：2 :: 31 | 5282 |
Assuming the IPv4 address that goes with 2001:db8:2::31 is 192.0.2.31, the FTP ALG reformats this as:
2001年に行くIPv4アドレスと仮定すると：DB8：2 :: 31は192.0.2.31で、FTP ALGは、これを再フォーマット：
PORT 192,0,2,31,20,162
PORT 192,0,2,31,20,162
If the address specified in the EPRT command is an IPv4 address or an IPv6 address that is not the IPv6 address used by the client for the control session, the ALG SHOULD NOT attempt any translation but pass along the command unchanged.
EPRTコマンドで指定されたアドレスがIPv4アドレスまたはコントロールセッションのためにクライアントが使用するIPv6アドレスではないIPv6アドレスの場合、ALGは、任意の翻訳を試みたが変わらず命令に沿って渡さないでください。
If the address in the EPRT command is the IPv6 address used by the client for the control channel, the stateful translator selects an unused port number in combination with the IPv4 address used for the control channel towards the FTP server and sets up a mapping from that transport address to the one specified by the client in the EPRT command. The PORT command with the IPv4 address and port used on the IPv4 side of the mapping is only issued towards the server once the mapping is created. Initially, the mapping is such that either any transport address or the FTP server's IPv4 address with any port number is accepted as a source, but once the three-way handshake is complete, the mapping SHOULD be narrowed to only match the negotiated TCP session.
EPRTコマンド内のアドレスは、制御チャネルのためにクライアントによって使用されるIPv6アドレスがある場合は、ステートフルな翻訳者は、FTPサーバーへの制御チャネルに使用するIPv4アドレスとの組み合わせで未使用のポート番号を選択し、そこからマッピングを設定しますEPRTコマンドでクライアントによって指定されたものへのトランスポートアドレス。マッピングが作成されると、マッピングのIPv4の側で使用されるIPv4アドレスとポートPORTコマンドは、サーバだけに向けて発行されます。最初に、マッピングは、任意のトランスポート・アドレスまたは任意のポート番号を使用してFTPサーバーのIPv4アドレスのどちらかをソースとして受け入れられているが、3ウェイハンドシェイクが完了すると、マッピングは唯一の一致で交渉TCPセッションに狭くする必要があることなどです。
If the address specified in the EPRT command is an IPv4 address or an IPv6 address that is not the IPv6 address used by the client for the control session, the ALG SHOULD NOT attempt any translation but pass along the command unchanged.
EPRTコマンドで指定されたアドレスがIPv4アドレスまたはコントロールセッションのためにクライアントが使用するIPv6アドレスではないIPv6アドレスの場合、ALGは、任意の翻訳を試みたが変わらず命令に沿って渡さないでください。
If the client with IPv6 address 2001:db8:2::31 issues the EPRT command:
DB8：：2 :: 31の問題EPRTコマンドIPv6アドレス2001とクライアントの場合：
EPRT |2|2001:db8:2::31|5282|
EPRT | 2 | 2001：DB8：2 :: 31 | 5282 |
And the stateful translator uses the address 192.0.2.31 on its IPv4 interface, a mapping with destination address 192.0.2.31 and destination port 60192 towards 2001:db8:2::31 port 5282 may be created, after which the FTP ALG reformats the EPRT command as:
そして、ステートフル翻訳者は、2001年に向けて、そのIPv4インタフェース上で宛先アドレス192.0.2.31および宛先ポート60192とのマッピングをアドレス192.0.2.31を使用しています：DB8：2 :: 31ポート5282を作成することができ、FTP ALGはEPRTを再フォーマットした後コマンドとして：
PORT 192,0,2,31,235,32
PORT 192,0,2,31,235,32
If the client does not issue an EPSV/PASV or EPRT/PORT command prior to initiating a file transfer, it is invoking the default active FTP behavior where the server sets up a TCP session towards the client.
クライアントは、前のファイル転送を開始するEPSV / PASVまたはEPRT / PORTコマンドを発行していない場合は、サーバーがクライアントへのTCPセッションを設定し、デフォルトのアクティブFTPの行動を呼び出しています。
In this situation, the source port number is the default FTP data port (port 20), and the destination port is the port the client uses as the source port for the control channel session.
この状況では、送信元ポート番号は、デフォルトのFTPデータポート（ポート20）であり、および宛先ポートは、クライアントが制御チャネルセッションの送信元ポートとして使用するポートです。
In the case of a stateless translator, this does not pose any problems. In the case of a stateful translator, the translator MAY accept incoming connection requests from the server on the IPv4 side if the transport addresses match that of an existing FTP control channel session, with the exception that the control channel session uses port 21 and the new session port 20. In this case, a mapping is set up towards the same transport address on the IPv6 side that is used for the matching FTP control channel session.
ステートレス翻訳者の場合、これはすべての問題をもたらすことはありません。トランスポートアドレスは、制御チャネルセッションがポート21を使用して、新しいことを除いて、既存のFTP制御チャネルセッションのものと一致した場合、ステートフル翻訳の場合、翻訳者は、IPv4側のサーバからの着信接続要求を受け入れるかもしれこの場合、セッションポート20は、マッピングは、整合FTP制御チャネルセッションのために使用されたIPv6側に同じトランスポートアドレスに向けて設定されています。
An ALG/translator MAY monitor the progress of FTP control channels and only attempt to perform a mapping when an FTP client has started a file transfer without issuing the EPSV, PASV, EPRT, or PORT commands.
ALG /翻訳者は、FTP制御チャネルの進行状況を監視し、FTPクライアントがEPSV、PASV、EPRT、またはPORTコマンドを発行せずにファイル転送を開始したときにのみマッピングを実行しようとすることができます。
[RFC0959] allows a client to issue both PORT and PASV to use non-default ports on both sides of the connection. However, this is incompatible with the notion that with PASV, the data connection is made from the client to the server, while PORT reaffirms the default behavior where the server connects to the client. As such, the behavior of an ALG is undefined when a client issues both PASV and PORT. Implementations SHOULD NOT try to detect the situation where both PASV and PORT commands are issued prior to a command that initiates a transfer, but rather, translate commands as they occur. So, if a client issues PASV, PASV is then translated to EPSV. If after that, but before any transfers have occurred, the client issues PORT and the ALG supports PORT translation for this session, the ALG translates PORT to EPRT.
[RFC0959]は、クライアントが接続の両側でデフォルト以外のポートを使用するPORTおよびPASVの両方を発行することができます。しかし、これは、PORTは、サーバーがクライアントに接続するデフォルトの動作を再確認しながら、PASVで、データ接続は、クライアントからサーバへなされるという概念と互換性がありません。そのため、ALGの動作は未定義であるときに、クライアントの問題PASVとポートの両方。実装は、両方のPASVとPORTコマンドが前に転送を開始し、コマンドを発行している状況を検出ではなく、彼らが発生すると、コマンドを翻訳しようとしないでください。クライアントがPASVを発行したのであれば、PASVは、EPSVに変換されます。任意の転送が発生している前にした後、しかし、クライアントはPORTを発行し、ALGがこのセッションのためにポート変換をサポートしている場合、ALGはEPRTにPORTを変換します。
Whenever the client issues a command that the ALG is not set up to translate (because the command is not specified in this document, the command is not part of any FTP specification, the ALG functionality is disabled administratively for the command in question, or translation does not apply for any other reason), the command MUST be passed on to the server without modification, and the server response MUST be passed on to the client without modification. For example, if the client issues the PASV command, this command is passed on to the server transparently, and the server's response is passed on to the client transparently.
クライアントは、ALGはコマンドは、この文書で指定されていないため、コマンドは任意のFTP仕様の一部ではありません（変換するように設定されていない、ALG機能が問題のコマンド、または翻訳のための管理上無効になっているというコマンドを発行するたびにその他の理由）には適用されません、コマンドをそのままサーバーに渡さなければならない、サーバの応答をそのままクライアントに渡さなければなりません。クライアントがPASVコマンドを発行した場合、このコマンドは、透過的にサーバに渡され、サーバの応答を透過的にクライアントに渡されます。
ALGs MUST support the new ALGS (ALG status) command that allows clients to query and set the ALG's status. FTP servers (as opposed to ALGs) MUST NOT perform any actions upon receiving the ALGS command. However, FTP servers MUST still send a response. If FTP servers recognize the ALGS command, the best course of action would be to return a 202 response:
ALGは、クライアントが照会しALGのステータスを設定することを可能にする新しいのALG（ALGステータス）コマンドをサポートしなければなりません。 FTPサーバは、（のALGではなく）のALGコマンドを受信すると、任意のアクションを実行してはなりません。しかし、FTPサーバは、まだ応答を送らなければなりません。 FTPサーバはのALGコマンドを認識した場合、最善の行動は、202応答を返すために、次のようになります。
202 Command not implemented, superfluous at this site
202コマンドこのサイトで余分、実装されていません
However, there is no reason for FTP servers to specifically recognize this command; returning any 50x response that is normally returned when commands are not recognized is appropriate.
しかし、FTPサーバは、特にこのコマンドを認識するための理由はありません。コマンドが認識されないときに通常返される任意の50倍の応答を返すことは適切です。
A client can use the ALGS command to request the ALG's status and to enable and disable EPSV to PASV translation and, if implemented, EPRT to PORT translation. There are three possible arguments to the ALGS command:
クライアントは、ALGの状態を要求すると、EPRT PORT翻訳に実装されている場合、有効とPASVへの変換EPSVを無効とするためのALGコマンドを使用することができます。 ALGコマンドには3つの可能な引数があります。
ALGS STATUS64 The ALG is requested to return the EPSV and EPRT translation status.
ALG STATUS64ザ・ALGはEPSVとEPRT翻訳ステータスを返すように要求されています。
ALGS ENABLE64 The ALG is requested to enable translation.
ALG ENABLE64ザ・ALGは、翻訳を可能にするために要求されています。
ALGS DISABLE64 The ALG is requested to disable translation.
ALG DISABLE64ザ・ALGは、翻訳を無効にすることが要求されます。
The ALG MUST enable or disable EPSV to PASV translation as requested. If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable it, and ALGS DISABLE64 MUST disable it along with enabling or disabling EPSV to PASV translation, respectively. If EPRT to PORT translation is not supported, ALGS ENABLE64 only enables EPSV to PASV translation. After an ALGS command with any of the three supported arguments, the ALG MUST return a 216 response indicating the type of translation that will be performed.
要求されたようALGはPASV翻訳にEPSVを有効または無効にする必要があります。 PORTへの変換EPRTがサポートされている場合、のALG ENABLE64はそれを有効にする必要があり、かつのALG DISABLE64は、それぞれ、PASV翻訳にEPSVを有効または無効に伴い、それを無効にする必要があります。 PORTへの変換EPRTがサポートされていない場合、のALG ENABLE64はPASV翻訳にEPSVを可能にします。サポートされている3つの引数のいずれかとのALGコマンドの後、ALGが実行されます翻訳のタイプを示す216応答を返さなければなりません。
216 NONE Neither EPSV nor EPRT translation is performed.
216 NONEどちらEPSVもEPRT変換は行われません。
216 EPSV EPSV is translated to PASV; no EPRT translation is performed.
216 EPSV EPSVはPASVに変換されます。何EPRT変換は行われません。
216 EPSVEPRT EPSV is translated to PASV; EPRT is translated to PORT.
216 EPSVEPRT EPSVはPASVに変換されます。 EPRTはPORTに変換されます。
The translation type MAY be followed by a space and additional descriptive text until end-of-line. If the ALG is unable to set the requested translation mode, for instance, because of lack of certain resources, this is not considered an error condition. In those cases, the ALG returns a 216 response followed by the keyword that indicates the current translation status of the ALG.
翻訳の種類は、行末までのスペースと追加の説明文を続けてもよいです。 ALGがあるため、特定のリソースの不足のため、例えば、要求された変換モードを設定することができない場合、これはエラー条件とは見なされません。これらのケースでは、ALGは、ALGの現在の翻訳ステータスを示すキーワードに続いて216応答を返します。
If there is no argument to the ALGS command, or the argument is not one of STATUS64, ENABLE64, or DISABLE64 (or an argument specified by a supported newer document), a 504 or 502 error SHOULD be returned.
そこのALGコマンドの引数ではない、または引数がSTATUS64、ENABLE64、またはDISABLE64（またはサポートされている新しいドキュメントで指定された引数）のいずれでもない場合は、504または502エラーが返されるべきです。
The Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) of the ALGS command and its response are as follows:
次のように増補バッカス - ナウアフォーム（ABNF）のALGコマンドの表記（[RFC5234]を参照）、その応答は次のとおりです。
algs-command = "ALGS" SP algs-token CRLF algs-token = "STATUS64" / "ENABLE64" / "DISABLE64"
ALG-コマンドは= "のALG" SPのALG-トークンCRLFののALG-トークンは= "STATUS64" / "ENABLE64" / "DISABLE64"
algs-response = (ok-response / error-response) CRLF ok-response = "216" SP response-token [ freetext ] response-token = "NONE" / "EPSV" / "EPSVEPRT" error-response = not-implemented / invalid-parameter not-implemented = "502" [ freetext ] invalid-parameter = "504" [ freetext ] freetext = (SP *VCHAR)
ALG応答=（OK応答/エラー応答）CRLF OKレスポンス= "216" SP応答トークン[フリーテキスト]応答トークン= "NONE" / "EPSV" / "EPSVEPRT" エラー応答=-実装されていません/無効パラメータ実装されていない= "502" [フリーテキスト]無効なパラメータ= "504" [フリーテキスト] FREETEXT =（SP用*のVCHAR）
Wherever possible, control channels SHOULD NOT time out while there is an active data channel. A timeout of at least 30 seconds is RECOMMENDED for data channel mappings created by the FTP ALG that are waiting for initial packets.
アクティブデータチャネルが存在する間、可能な限り、制御チャネルがタイムアウトすべきではありません。少なくとも30秒のタイムアウトが最初のパケットを待っているFTP ALGによって作成されたデータチャネルのマッピングをお勧めします。
Whenever a command from the client is not propagated to the server, the FTP ALG instead issues a NOOP command in order to keep the keepalive state between the client and the server synchronized. The response to the NOOP command MUST NOT be relayed back to the client. An implementation MAY wait for the server to return the 200 response to the NOOP command and translate that 200 response into the response the ALG is required to return to the client. This way, the ALG never has to create new packets to send to the client, but it can limit itself to modifying packets transmitted by the server. If the server responds with something other than a 200 response to the NOOP command, the ALG SHOULD tear down the control channel session and log an error.
クライアントからのコマンドがサーバに伝播されていないときはいつでも、FTP ALGではなく、クライアントと同期サーバの間でキープアライブ状態を維持するためにNOOPコマンドを発行します。 NOOPコマンドへの応答がクライアントに中継してはなりません。実装は、NOOPコマンドへの200応答を返し、ALGがクライアントに返す必要があり、応答にその200応答を翻訳するためにサーバーを待つことができます。この方法では、ALGがクライアントに送信する新しいパケットを作成する必要がありませんが、それは、サーバによって送信されたパケットを変更するに自分自身を制限することができます。サーバがNOOPコマンドに200応答以外で応答した場合、ALGは、制御チャネルセッションを切断し、エラーをログに記録すべきです。
IANA has added the following entry to the "FTP Commands and Extensions" registry:
IANAは、「FTPコマンドと拡張」のレジストリに次のエントリを追加しました：
Command Name ALGS
コマンド名のALG
FEAT Code -N/A-
FEATコード-N / A-
Description FTP64 ALG status
説明FTP64 ALGのステータス
Command Type -N/A-
コマンドタイプ-N / A-
Conformance Requirements o
適合性要件O
Reference RFC 6384 Section 11
参考RFC 6384のセクション11
In the majority of cases, FTP is used without further security mechanisms. This allows an attacker with passive interception capabilities to obtain the login credentials and an attacker that can modify packets to change the data transferred. However, FTP can be used with TLS in order to solve these issues. IPv6-to-IPv4 translation and the FTP ALG do not impact the security issues in the former case nor the use of TLS in the latter case. However, if FTP is used with TLS as per [RFC4217], or another authentication mechanism that the ALG is aware of, the ALG function is not performed so only passive transfers from a server that implements EPSV or a client that supports PASV will succeed.
ほとんどの場合、FTPは、さらにセキュリティメカニズムなしで使用されています。これは、ログイン資格情報を取得するために、受動迎撃能力を持つ攻撃者と転送されたデータを変更するには、パケットを変更することができ、攻撃者が可能になります。しかし、FTPは、これらの問題を解決するためにTLSを使用することができます。 IPv6のツーIPv4の翻訳およびFTP ALGは、前者の場合も後者の場合はTLSを使用してセキュリティ上の問題に影響を与えません。 FTPは、[RFC4217]、またはALGが認識している別の認証メカニズムごとにTLSで使用されている場合は、ALG機能はそれほどEPSVあるいはPASVが成功するサポートするクライアントを実装し、サーバからのみの受動転送を行いません。
For general FTP security considerations, see [RFC2577].
一般的なFTPのセキュリティの考慮事項については、[RFC2577]を参照してください。
Dan Wing, Kentaro Ebisawa, Remi Denis-Courmont, Mayuresh Bakshi, Sarat Kamisetty, Reinaldo Penno, Alun Jones, Dave Thaler, Mohammed Boucadair, Mikael Abrahamsson, Dapeng Liu, Michael Liu, Andrew Sullivan, Anthony Bryan, Ed Jankiewicz Pekka Savola, Fernando Gont, Rockson Li, and Donald Eastlake contributed ideas and comments. Dan Wing's experiments with a large number of FTP servers were very illuminating; many of the choices underlying this document are based on his results.
ダン・ウィング、健太郎海老沢、レミデニス・Courmont、Mayureshバクシ、Sarat Kamisetty、レイナルドPenno、アラン・ジョーンズ、デイブ・ターラー、モハメッドBoucadair、ミカエルAbrahamsson、大鵬劉、マイケル・リュー、アンドリュー・サリバン、アンソニー・ブライアン、エドJankiewiczペッカSavola、フェルナンドGont、Rocksonリー、そしてドナルドイーストレイクは、アイデアやコメントを貢献しました。 FTPサーバの数が多いとダン・ウィングの実験は非常に照明されました。このドキュメントの基礎となる選択肢の多くは彼の結果に基づいています。
Iljitsch van Beijnum is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
IljitschバンBeijnumの一部トリロジー、その第七次フレームワーク計画の下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されます。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997.
[RFC2228]ホロヴィッツ、M.、 "FTPセキュリティ拡張機能"、RFC 2228、1997年10月。
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[RFC2428]オールマン、M.、Ostermann、S.、およびC.メッツ、 "IPv6とNATsのためのFTP拡張機能"、RFC 2428、1998年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC1639] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[RFC1639] Piscitello、D.、 "FTPオペレーションを超えるビッグアドレスレコード（FOOBAR）"、RFC 1639、1994年6月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC2389] Hethmon、P.とR.エルツ、 "ファイル転送プロトコルの機能ネゴシエーションメカニズム"、RFC 2389、1998年8月。
[RFC2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC2577]オールマン、M.とS. Ostermann、 "FTPセキュリティに関する考慮事項"、RFC 2577、1999年5月。
[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[RFC2640]カーティン、B.、 "ファイル転送プロトコルの国際化"、RFC 2640、1999年7月。
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217]フォード・ハッチンソン、P.、 "TLSでセキュアなFTP"、RFC 4217、2005年10月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、マシューズ、P.、およびI.バンBeijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、RFC 6146、2011年4月。
Author's Address
著者のアドレス
Iljitsch van Beijnum Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
IljitschバンBeijnum研究所IMDEA Networksの星Avda。デルマールメディテラネオ、22のレガネス、マドリード28918スペイン
EMail: iljitsch@muada.com
メールアドレス：iljitsch@muada.com