epsv4再び

Extended Passive Mode for IPV4という事かな。コマンドの名前からすると、RFC2428で規定されてFTP Extsnsion for IPv6 and NATsにあって、その歴史はかなり前からあるようです。1998年のRFCだから。多分2000年頃にはFreeBSDでも実装されていたんだろう。
いつの間に、FreeBSDのftpクライアントがこのモードを始めにトライするようになったのか調べる必要がありそうだ。
さて、問題点をもう一度整理すると。以下IPv4での動作。でサーバ側にNATPルータが入っている事とする。

1. FreeBSD/MacOSのftpクライアントでは始めにepsv4モードでftpサーバが対応しているか確認する
2. FreeBSDのftpd, Macのftpd, proftpdなどのftpサーバーは既に対応済みなので対応を表明する
3. ftpクライアントではコマンドが受理されたので、既にepsv4の状態になっている
4. しかし、natpルータは、このコマンドを解釈が出来なかったり、データ接続時のIP Address, Port Addressの情報を引き出せずにいる
5. 結果として、サーバが側で用意したデータ接続ポートへの接続がNATテーブルに入らず、クライアントからの接続がタイムアウトする
6. FreeBSDのftpクライアントではタイムアウトを検出しpassive offモードに移行し正常に機能する。MacOSはタイムアウトでエラーになる

とりあえず、システム管理者が出来る事は、ftpサーバにepsvをサポートさせないように設定すること。これで利用者のftpクライアントを制限したり、利用者にpassive offにせよとか、epsv4 offコマンドを入れろとか言わずにすむ。
普通解消すればシステム管理てのは終わりなんだが。釈然としない。そもそもftpというプロトコルをこういう形で拡張する必要性があったのだろうか。natにやさしい考え方かもしれないけど、既存のnat実装に全然やさしくない。トラブルの元になっとる。
これなら、接続ポートとデータポートを固定にして、一度接続ポートに接続したら、そこから認証コードを受け渡し、データポートへクライアントから接続をして、クライアントから認証コードを受け取るような新しいftpプロトコルを作成して、標準的なポート番号を決めた方がよかったのではないだろうか。少なくともIPv4の世界でこの拡張をするメリットは無いし。IPv6でNATを使う必要性も無いだろう。
ま、別のプロトコルを作るのは気がすすまなかっただけかもしれないが。
もう１つの見方としては、FreeBSDのftpやMacOSのftpクライアントが何故にepsv接続に挑戦するのかという問題。まあ、このおかげで、epsvというのが世の中にあるのだな。と知る事になるのだが。そんなの私に取っては全然うれしくない。IPv6接続じゃなければ、こんなもの挑戦しなければよいと私は感じます。ルータメーカも大変だな。