[ftpext] draft-ietf-ftpext2-ftp64-00 translation scenario

[Robert Oslin <[e-mail]>]

This draft makes the case for how an IPv6 FTP client should behave when processing an IPv4 FTP Server PASV/PORT reply when going from an IPv6 network through a translation device. 

In general I'm in favor of "client intelligence"*, and I don't see that it explicitly violates RFC959 in terms of handling the PASV response, although it does so implicitly since the client should be using the IP and port provided in the server reply. 

My point of contention is this: Why an RFC at all? Unless I'm mistaken, translation, such as NAT-PT, BIS, BIA, etc. has been moved to experimental status, as translation should be considered a "last resort" when other IPv6 transition options are unavailable (dual stack, tunneling, etc.). 

~~~

*Clients should do this today in an IPv4 world if for example a PASV reply contains network address prefix, e.g. 192.168.0.0/16, which can happen if using encrypted communications and going though NAT and the server hasn't configured the "external" facing IP (And since the session is encrypted, NAT can't see the address to change it). The client should identify this (and similar) wrong IPs and reuse the control connection's IP.

Robert Oslin
Director of Product Management
Tel: [phone]
Fax: [phone]
Send me large files securely

www.globalscape.com

   (NYSE Amex:GSB)
*This communication, including attachments, is for the exclusive use of the addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.