[bug-inetutils] Remark on EPSV ALL in RFC 2428.

[Mats Andersson]

Dear all,

while extending our FTP server with IPv6 support according
to RFC 2428, I find some queries due to the mandatory command
"EPSV ALL" in said document.

Reading the text literally, this change of state is expressed:

   client sends "EPSV ALL"

   --> server disables PORT, PASV, EPRT.

The question arises as to the inhibition also of LPRT and LPSV,
since the relevant RFC text preceedes the present one. In fact,
the text states verbatim

   MUST reject all data connection setup commands other than EPSV
   (i.e., EPRT, PORT, PASV, et al.)

One could use "et al." to expand into "LPRT, LPSV, and others".

On the other hand, the gist of the text is to prevent active
data callback connections, allowing only passive data exchange.
This would indicate that EPSV, LPSV, and PASV might reasonably
be kept functional.

Thus I pose these alternate solutions for the final coding:

   (1)   server disables PORT, EPRT, LPRT, PASV, and LPSV.

   (2)   server disables PORT, EPRT, and LPRT.

My personal feeling is to go for (2), but I need your blessing.
It is only at a later stage that LPRT and LPSV will be implemented
in our server, but I want to bring them up already now.

Once the ability to act on "EPSV ALL" has been decided, it must also
be settled whether to implement a command line switch that allows
running the server in passive-only mode already from the start.
Would such a setup contradict any RFC standard? I would here suggest
"-P" and "--passive-only" as command line switches.

Unfortunately there is old code in our FTP client, code originating
already in the Netkit code basis, and still present in our code as
well as in the client of OpenBSD and the netkit-ftp client of Debian.
The particular code in question ( in ftp/ftp.c, initconn() ):

     if (result == ERROR && sendport == -1)
       {
         sendport = 0;
         tmpno = 1;
         goto noport;
       }

which is broken for communication with any server that disables
active port assigned communications. I will elaborate on this
once I find a solid solution to suggest against the solution,
but I invite your analysis of the code independently of mine.

Best regards for now,
  Mats