[要約] 要約：RFC 6384は、IPv6からIPv4へのトランスレーションのためのFTPアプリケーションレイヤーゲートウェイ（ALG）に関する規格です。 目的：このRFCの目的は、IPv6とIPv4の間でFTPトラフィックを適切にトランスレートするためのゲートウェイの設計と動作を定義することです。
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
IPv6-to-IPV4翻訳用のFTPアプリケーションレイヤーゲートウェイ（ALG）
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-to-IPV4翻訳者はそのギャップを埋めるために使用されます。可能な範囲。
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-to-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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。これらのドキュメントを確認してください
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.
慎重に、彼らはこの文書に関するあなたの権利と制限を説明しています。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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つの操作モード：Active Modeの2つの操作モードを指定します。このモードでは、サーバーがクライアントに戻り、パッシブモードで、サーバーがクライアントが接続できるポートを開きます。追加の測定がなければ、クライアントがサプライされたポートを備えたアクティブモードは、NATやファイアウォールを介して機能しません。アクティブモードでは、ポートコマンドにはIPv4アドレスが引数としてあり、パッシブモードでは、サーバーはIPv4アドレスを使用してPASVコマンドに応答します。これにより、[RFC0959]で最初に指定されたパッシブモードとアクティブモードの両方が、IPv6と互換性がありません。これらの問題は[RFC2428]で解決され、EPSV（拡張パッシブ）コマンドを導入します。ここでは、サーバーはポート番号とEPRT（拡張ポート）コマンドでのみ応答します。（およびポート）サーバーへ。
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月に、IPv4を介して到達可能なランダムに選択した25のランダムに選択されたFTPサイトの調査で行われた調査では、IPv4よりも12個のみがEPSVをサポートしていることが示されました。さらに、これらの12のうち2つだけが、[RFC2389]で導入されたfeatコマンドに応答してEPSVをサポートしていることを示しました。 1つはEPSVをサポートしましたが、偉業ではありませんでした。 5つのケースでは、EPSVコマンドをサーバーに発行すると、大きな遅延が発生しました。これらの3つのケースでは、コントロールチャネルのリセットが遅延に続きました。追加情報が不足しているため、特定のFTPサーバーがEPSVコマンドを発行した後に制御チャネル接続をリセットする理由を最終的に判断することは不可能です。ただし、これらのFTPサーバーは、制御チャネルセッションを監視するアプリケーション認識ファイアウォールの背後にあり、PASV（およびおそらくポート）コマンドへの応答にリストされているポートにデータチャネルセッションを作成することのみを可能にするアプリケーション認識ファイアウォールの背後にあるということです。 EPSVコマンドへの応答は異なるため（227コードではなく229コード）、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.
25のテストされたサーバーはすべて、[RFC1123]で要求されているように、従来のPASVパッシブモードでの転送を正常に完了することができました。より多くのテストにより、EPSVコマンドを使用したアドレスファミリの引数の使用は、サーバーで広く誤って実装または実装されていないことが示されました。より多くのサーバーを使用した追加のテストにより、FTPサーバーの約65％がEPSVを正常にサポートし、約96％がPASVを正常にサポートすることが示されました。クライアントは広範囲にテストされていませんでしたが、著者の以前の経験は、ほとんどのクライアントがPASVをサポートしていることを示唆しています。このFTPクライアントは、IPv4およびEPRTを実行するときにIPv6を介して実行するときに元のポートコマンドを使用します。
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-to-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.
サーバーからサーバーへの転送など、より複雑な動作に従事したいクライアントは、セクション5で説明されているように、ALGSコマンドを発行することにより、FTPアプリケーションレイヤーゲートウェイ（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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-to-IPV4翻訳者を使用し、コントロールチャネルでアプリケーションレイヤーゲートウェイを使用するのではなく、クライアントとサーバーを変更することです。そのため、ALGSを必要とせずに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
一方、組織内のネットワークオペレーターまたはネットワーク管理者でさえ、ネットワークを介して使用されるFTPクライアントとサーバーの実装にほとんど影響を与えません。それらのオペレーターと管理者にとって、アルグを展開することが唯一の方法かもしれません
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.
満足のいく顧客体験を提供します。そのため、優先ソリューションではありませんが、このドキュメントは、有害な効果を最小限に抑えるために、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アルグが明確に必要な場合にのみ、IPv6からIPV4への翻訳にFTPアルグを展開することをお勧めします。ALGの存在下で、適合サーバーによって直接処理できるEPSVコマンドは、PASVコマンドに変換され、追加の複雑さを導入し、堅牢性を低減します。そのため、ALGSに関する「セットと忘却」ポリシーは推奨されません。
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.
すべての翻訳者を介したEPSVのStatelesteless Translatorを介したEPRTの翻訳は比較的単純ですが、EPRTの翻訳をサポートすることは比較的困難であることに注意してください。制御チャネル上のクライアント/サーバーの相互作用から学習する必要があるパラメーター。これは、EPRTコマンドをポートコマンドに翻訳してサーバーに渡す前に行う必要があります。そのため、ステートフルな翻訳者で使用されるアルグは、EPSV翻訳をサポートし、EPRT翻訳をサポートする必要があります。ただし、無国籍翻訳者で使用されるアルグは、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-to-IPV4変換関数とは別の関数として説明されています。ただし、EPRT翻訳の場合、ALGおよび翻訳者機能をしっかりと結合する必要があるため、EPRT翻訳がサポートされている場合、ALGおよびIPv6-to-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-to-IPV4 FTP ALGは、IPv6-to-IPV4翻訳者を介して到達可能なIPv4宛先にマッピングできるIPv6宛先アドレスのポート21に向けてすべてのTCPセッションを傍受します。FTP ALGは、コントロールチャネルの相互作用に使用されるTelnetプロトコル（[RFC0854]）を実装し、コマンドと応答を解釈し、それらのコマンドと応答を再発行するために必要な程度まで実装し、以下に概説したように変更します。[RFC1123]によって許可されているものを除き、クライアントまたはサーバーのいずれかによるTelnetオプションの交渉の試みは、それらの試みを中継することなくFTPアルグによって拒否されなければなりません。Telnetオプションのネゴシエーションの目的のために、FTP ALGは[RFC1123]、セクション4.1.2.12で指定されているように、FTPサーバーの動作に従う必要があります。これにより、クライアントとサーバーがFTPアルグによって実装されていないTelnetオプションを交渉する状況が回避されます。
There are two ways to implement the control channel 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つのセッション間でコマンドと応答を前後にリレーします。
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シーケンス番号を追跡および更新する機能と、翻訳後にパケットを小さなパケットに分割する機能が必要です。問題のパケット。また、FTPコマンド/応答またはTelnet交渉はパケットの境界にまたがる可能性があるため、ALG機能を実行できるようにするためには、複数のパケットからTelnet交渉とFTPコマンドと応答を再構成する必要があることが証明できます。
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緊急データ機能を使用します。アルグは、パケットの境界を越えても、制御チャネルの相互作用を翻訳するときに緊急ポインターのセマンティクスを維持するか、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:
クライアントが認証コマンドを発行した場合、クライアントはFTP ALG関数と互換性がない可能性が高いセキュリティメカニズム[RFC2228]を交渉しようとしています。たとえば、クライアントがコントロールチャネルのトランスポートレイヤーセキュリティ（TLS）保護（[RFC4217]）の交渉を試みた場合、アルグは次の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.
1. コントロールチャネル上に送信されたデータを前後に透過的にコピーするため、TLSセッションは予想どおりに機能しますが、クライアントコマンドとサーバーの応答はアルグから隠されています。
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はクライアントコマンドとサーバーの応答を変更することができます。繰り返しますが、クライアントとサーバーは、これが中間の攻撃として認識されるため、セッションを拒否する可能性があります。
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コマンドが発行されるとすぐに、アルグはコマンドと応答の翻訳を停止し、サーバーから送信されたTCPデータの透過コピーをクライアントに透過的にコピーし、その逆を開始する必要があります。ALGは、サーバーの応答が4xxまたは5xx範囲にある場合、authコマンドを無視し、透過モードに移動しないでください。
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.
認証コマンドが発行される前にアルグを介して送信されたコマンドまたは応答が長さが変更されたため、アルグを入力するパケットにTCPシーケンス番号が変更され、アルグを終了するパケットが一致しなくなりました。透明モードでは、ALGは、認証コマンドの結果として透過モードに入る前に、シーケンス番号を調整し続ける必要があります。ALGSコマンド（セクション11）を使用してALG機能を無効にすることもできますが、コントロールチャネルは、ALG機能を再度に戻す後続のALGSコマンドについて監視する必要があります。
[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つの間で使用される言語をクライアントとサーバーがネゴシエートする機能を指定します。理想的には、IPv6-to-IPV4 FTP ALGSはこの機能をサポートするため、非デフォルト言語がクライアントとサーバーによってネゴシエートされた場合、ALGは翻訳された応答のテキストメッセージを交渉された言語で送信します。ただし、アルグが機能の交渉をサポートしていても、ALGにすべての可能な言語のテキスト文字列があることを確認する方法はありません。したがって、クライアントとサーバーがアルグによってサポートされていない言語を交渉しようとする状況は避けられません。この状況でのFTPアルグの適切な動作は、IPv4-to-IPV4 FTP ALGSに同じ問題が存在するため、将来の仕様で対処できます。とりあえず、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. ラングの交渉を監視し、その言語のテキストが利用可能な場合は交渉された言語でテキストを送信します。そうでない場合、テキストはデフォルト言語で送信されます。
2. Not monitor LANG negotiation. Text is sent in the default language.
2. ラングの交渉を監視しないでください。テキストはデフォルト言語で送信されます。
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.
3. LangコマンドをNOOPコマンドに翻訳し、結果の200の応答をサポートされていないコマンドに適した502応答に翻訳することにより、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つのケースでは、言語が交渉された場合、クライアントまたはサーバーによって送信されるテキストは、7ビットASCIIに制限されるのではなく、UTF-8 [RFC3629]でエンコードされると想定する必要があります。最初または2番目のオプションを実装するアルグは、それらが発生したときに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]のセクション3.1は、パス名のスペースとキャリッジリターン（CR）文字の新しいハンドリングを指定していることに注意してください。ラングの交渉をブロックしないアルグは、パス処理のために指定されたルールに準拠する必要があります。実装者は、PATHNAMEで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アルグは、クライアントが発行したEPSVコマンドのすべての発生をPASVコマンドに変換し、対応する229応答として227の応答を再フォーマットする必要があります。ただし、ALGは、ePSVがPASVへの翻訳なしで成功することを管理するか、動的に学習した場合、肯定的な知識を持っている場合、PASV翻訳からPASV翻訳を控えることができます。
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:
たとえば、クライアントがEPSV（またはEPSV 2をネットワークプロトコルとして示すためにEPSV 2を発行する場合）、これは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アルグはこれを次のように再フォーマットします
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アルグは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コマンドを発行する場合、アルグはコマンドをサーバーに渡さず、たとえば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:
クライアントがEPSVをすべて発行した場合、FTPアルグはこのコマンドをサーバーに渡さないでください。たとえば、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.
これにより、クライアントがEPSV ALLコマンドを使用してこのセッション中にEPSVを使用することを示すために、FTPサーバーが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アルグはこのEPRTコマンドをポートコマンドに翻訳する場合があります。翻訳は、翻訳者が無国籍の1対1の翻訳者であるか、ステートフルな1対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アドレスを持つEPRTコマンドをポートコマンドに再フォーマットします。ポート番号は、ステートレス翻訳者との互換性のために保存する必要があります。たとえば、IPv6アドレス2001を持つクライアントの場合：DB8：2 :: 31は次のEPRTコマンドを発行します。
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です。FTPALGはこれを次のように再生します。
PORT 192,0,2,31,20,162
ポート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コマンドで指定されているアドレスが、クライアントがコントロールセッションに使用するIPv6アドレスではないIPv4アドレスまたは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アドレスとポートを備えたポートコマンドは、マッピングが作成されたらサーバーに向かって発行されます。最初に、マッピングは、任意のトランスポートアドレスまたは任意のポート番号を備えた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コマンドで指定されているアドレスが、クライアントがコントロールセッションに使用するIPv6アドレスではないIPv4アドレスまたはIPv6アドレスである場合、ALGは変換を試みず、変更されていないコマンドを渡す必要があります。
If the client with IPv6 address 2001:db8:2::31 issues the EPRT command:
IPv6アドレス2001を持つクライアントの場合：DB8：2 :: 31はEPRTコマンドを発行します。
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:
ステートフルな翻訳者は、IPv4インターフェイスでアドレス192.0.2.31を使用します。これは、2001年に向けて宛先アドレス192.0.2.31と宛先ポート60192を使用したマッピングです。コマンドとして：
PORT 192,0,2,31,235,32
ポート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/ポートコマンドを発行しない場合、サーバーがクライアントに向かって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.
無国籍の翻訳者の場合、これは問題を引き起こしません。ステートフルな翻訳者の場合、翻訳者は、輸送アドレスが既存の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、またはポートコマンドを発行せずにファイル転送を開始した場合にのみマッピングを実行しようとします。
[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]は、クライアントがポートとPASVの両方を発行して、接続の両側に非デフォルトポートを使用することができます。ただし、これはPASVでは、データ接続がクライアントからサーバーへと行われるという概念と互換性がありませんが、ポートはサーバーがクライアントに接続するデフォルトの動作を再確認します。そのため、クライアントがPASVとポートの両方を発行すると、アルグの動作は未定義です。実装は、転送を開始するコマンドの前にPASVコマンドとポートコマンドの両方が発行される状況を検出しようとするのではなく、コマンドが発生したときにコマンドを翻訳することを試みるべきではありません。したがって、クライアントがPASVを発行すると、PASVがEPSVに翻訳されます。その後、転送が発生する前に、クライアントがポートを発行し、アルグがこのセッションのポート翻訳をサポートしている場合、アルグはポートをEPRTに翻訳します。
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.
クライアントがアルグが翻訳するように設定されていないというコマンドを発行するたび他の理由では申請しません）、コマンドは変更なしでサーバーに渡す必要があり、サーバーの応答を変更せずにクライアントに渡す必要があります。たとえば、クライアントが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:
ALGSは、クライアントがALGのステータスをクエリして設定できるようにする新しいALGS（ALGステータス）コマンドをサポートする必要があります。FTPサーバー（ALGSとは対照的に）は、ALGSコマンドを受信してもアクションを実行してはなりません。ただし、FTPサーバーは引き続き応答を送信する必要があります。FTPサーバーがALGSコマンドを認識している場合、最良のアクションコースは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:
クライアントは、ALGSコマンドを使用して、ALGのステータスを要求し、EPSVをPASV翻訳に有効にして無効にし、実装されている場合はEPRTからポート翻訳を可能にします。ALGSコマンドには3つの可能な引数があります。
ALGS STATUS64 The ALG is requested to return the EPSV and EPRT translation status.
algs status64 ALGは、EPSVおよびEPRT翻訳ステータスを返すように要求されます。
ALGS ENABLE64 The ALG is requested to enable translation.
algs enabable64 ALGは、翻訳を有効にするために要求されます。
ALGS DISABLE64 The ALG is requested to disable translation.
algs disable64アルグは、翻訳を無効にするように要求されます。
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は、要求されているようにEPSVをPASV翻訳に有効または無効にする必要があります。EPRTからポート翻訳がサポートされている場合、ALGS ENABAL64はそれを有効にする必要があり、ALGS Disable64は、それぞれPASV翻訳を有効または無効にすることとともにそれを無効にする必要があります。EPRTからポート翻訳がサポートされていない場合、ALGS ENABAL64はEPSVからPASV翻訳のみを有効にします。サポートされている3つの引数のいずれかを使用したALGSコマンドの後、ALGは実行される翻訳のタイプを示す216応答を返す必要があります。
216 NONE Neither EPSV nor EPRT translation is performed.
216なし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はポートに翻訳されます。
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.
リソース、これはエラー条件とは見なされません。そのような場合、アルグは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.
ALGSコマンドに引数がない場合、または引数がStatus64、enabable64、またはdisable64（またはサポートされている新しいドキュメントで指定された引数）のいずれかではない場合、504または502のエラーを返す必要があります。
The Augmented Backus-Naur Form (ABNF) notation (see [RFC5234]) of the ALGS command and its response are as follows:
ALGSコマンドの拡張されたBackus-NAURフォーム（ABNF）表記（[RFC5234]を参照）とその応答は次のとおりです。
algs-command = "ALGS" SP algs-token CRLF
algs-token = "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)
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.
可能な限り、アクティブなデータチャネルがある間、制御チャネルはタイムアウトしないでください。初期パケットを待っているFTPアルグによって作成されたデータチャネルマッピングには、少なくとも30秒のタイムアウトが推奨されます。
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アルグは代わりに、クライアントとサーバーの間のキープライブ状態を同期させるためにNOOPコマンドを発行します。NOOPコマンドへの応答をクライアントに中継してはなりません。実装は、サーバーがNOOPコマンドへの200の応答を返すのを待って、その200の応答を応答に変換することができます。このようにして、アルグはクライアントに送信するために新しいパケットを作成する必要はありませんが、サーバーが送信するパケットの変更に制限することができます。サーバーがNOOPコマンドに対する200の応答以外の何かで応答した場合、アルグはコントロールチャネルセッションを取り壊し、エラーを記録する必要があります。
IANA has added the following entry to the "FTP Commands and Extensions" registry:
IANAは、「FTPコマンドと拡張機能」レジストリに次のエントリを追加しました。
Command Name ALGS
コマンド名アルグ
FEAT Code -N/A-
feat code -n/a-
Description FTP64 ALG status
説明FTP64アルグステータス
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-to-IPV4翻訳とFTPアルグは、前者の場合のセキュリティ問題にも影響を与えません。また、後者の場合のTLSの使用にも影響しません。ただし、[RFC4217]に従ってTLSでFTPが使用されている場合、またはALGが認識している別の認証メカニズムは、ALG関数が実行されないため、PASVをサポートするEPSVまたはクライアントを実装するサーバーからのパッシブ転送のみが実行されます。
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.
ダン・ウィング、ケンタロ・エビサワ、レミ・デニス・コールモント、メイレシュ・バクシー、サラト・カミゼッティ、レイナルド・ペノ、アルン・ジョーンズ、デイブ・タラー、モハメッド・ブーカデア、ミカエル・アブラハムソン、ダペン・リュー、マイケル・リュー、アンドリュー・サヴァン、エド・ブライアン、エド・ジャーナ・サリバンGont、Rockson Li、およびDonald Eastlakeは、アイデアとコメントを提供しました。多数のFTPサーバーを使用したDan Wingの実験は非常に照らしていました。この文書の根底にある選択の多くは、彼の結果に基づいています。
Iljitsch van Beijnum is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Iljitsch van Beijnumは、第7回フレームワークプログラムの下で欧州委員会がサポートする研究プロジェクトであるTrilogyによって部分的に資金提供されています。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997.
[RFC2228] Horowitz、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] Allman、M.、Ostermann、S。、およびC. Metz、「IPv6およびNATの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] Crocker、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操作上の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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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. Elz、「ファイル転送プロトコルの特徴交渉メカニズム」、RFC 2389、1998年8月。
[RFC2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC2577] Allman、M。およびS. Ostermann、「FTPセキュリティに関する考慮事項」、RFC 2577、1999年5月。
[RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999.
[RFC2640] Curtin、B。、「ファイル転送プロトコルの国際化」、RFC 2640、1999年7月。
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217] Ford-Hutchinson、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.、Bao、C。、およびF. Baker、「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.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、RFC 6146、2011年4月。
Author's Address
著者の連絡先
Iljitsch van Beijnum Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch Van Beijnum Institute IMDEA Networks Avda。Del Mar Mediterraneo、22 Leganes、Madrid 28918スペイン
EMail: iljitsch@muada.com