Andrew.S.Hooper@QueensU.CA (04/26/89)
Following is an FTP incompatibility we recently encountered. I'd
appreciate any comments on the correctness of the two implementations.
A user on host A makes an FTP control connection to host B at address
B1. B also has a second network connection with address B2. The user
requests a directory listing. The FTP server on host B then initiates
a data connection back to host A, but uses B2 as the source address.
Host A is prepared to accept a connection from B1, but refuses to
accept one from B2. Hence, no listings or transfers can be done. The
port number supplied by A is used correctly by B.
Host A runs IBM VM TCP/IP Release 1.2, host B runs Wollongong 3.2.
Nowhere in the FTP RFC (959) can I find a specifcation as to the source
address of the data connection, so I cannot point fingers. It does seem
appropriate to me to reject the mismatching address, as it could be
coming from who knows where, but there may be arguments for not doing so.
Two other TCP/IP packages do not check the source address.
Thanks in advance for any advice.
Andy Hooper Queen's Univ. Computing Services Bitnet: HOOPER@QUCDN
Kingston, Ontario, Canada Telephone: +1 613 545 2019barns@GATEWAY.MITRE.ORG (Bill Barns) (04/27/89)
I had always thought it was specified that the server data port was to be associated with the IP address of the control connection, except if PASV came into play. I made remarks in Host Requirements WG recently which implicitly assumed this, and no one complained at the time. It looks like you're right, though, the RFC doesn't come out and say it in so many words. I would suggest that the second paragraph of section 5.2 when interpreted in the context of the first paragraph, takes on a rather odd flavor if it is not assumed that the IP address is the same. The server is supposed to "initiate the data connection from his own default data port (L-1)" and it seems rather tortured to interpret this as "L-1 at any address". But yes, this should be clarified. I'll mention it to the WG (some have undoubtedly seen your message, too). In my opinion, machine B should be deemed broken and machine A is being reasonable, for the reason you indicated. In checking this, I noted an error in the last sentence of paragraph 2 of RFC 959 section 5.2. The words "and the port used" should not appear. This is a mistaken holdover from NCP FTP, RFC 542, top of page 34, mechanically translated into TCP jargon. The approximate counterpart to a TCP port is a pair of NCP sockets, each of which is unidirectional; so the socket used in NCP FTP depended on the direction of transfer. In TCP FTP the issue doesn't arise since TCP connections are full-duplex. The same correction is needed in MIL-STD-1780, last sentence of section 5.9.2. Bill Barns / MITRE-Washington / barns@gateway.mitre.org