rfc2428.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页


RFC 2428            FTP Extensions for IPv6 and NATs      September 1998


   client MUST issue an ABOR (abort) command to allow the server to
   close down the listening connection.  The client can then send an
   EPSV command requesting the use of a specific network protocol, as
   follows:

        EPSV<space><net-prt>

   If the requested protocol is supported by the server, it SHOULD use
   the protocol.  If not, the server MUST return the 522 error messages
   as outlined in section 2.

   Finally, the EPSV command can be used with the argument "ALL" to
   inform Network Address Translators that the EPRT command (as well as
   other data commands) will no longer be used.  An example of this
   command follows:

        EPSV<space>ALL

   Upon receipt of an EPSV ALL command, the server MUST reject all data
   connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et
   al.).  This use of the EPSV command is further explained in section
   4.

4.  Command Usage

   For all FTP transfers where the control and data connection(s) are
   being established between the same two machines, the EPSV command
   MUST be used.  Using the EPSV command benefits performance of
   transfers that traverse firewalls or Network Address Translators
   (NATs).  RFC 1579 [Bel94] recommends using the passive command when
   behind firewalls since firewalls do not generally allow incoming
   connections (which are required when using the PORT (EPRT) command).
   In addition, using EPSV as defined in this document does not require
   NATs to change the network address in the traffic as it is forwarded.
   The NAT would have to change the address if the EPRT command was
   used.  Finally, if the client issues an "EPSV ALL" command, NATs may
   be able to put the connection on a "fast path" through the
   translator, as the EPRT command will never be used and therefore,
   translation of the data portion of the segments will never be needed.
   When a client only expects to do two-way FTP transfers, it SHOULD
   issue this command as soon as possible.  If a client later finds that
   it must do a three-way FTP transfer after issuing an EPSV ALL
   command, a new FTP session MUST be started.








Allman, et. al.             Standards Track                     [Page 5]

RFC 2428            FTP Extensions for IPv6 and NATs      September 1998


5.  Security Issues

   The authors do not believe that these changes to FTP introduce new
   security problems.  A companion Work in Progress [AO98] is a more
   general discussion of FTP security issues and techniques to reduce
   these security problems.

6.  Conclusions

   The extensions specified in this paper will enable FTP to operate
   over a variety of network protocols.

References

   [AO98]   Allman, M., and S. Ostermann, "FTP Security
            Considerations", Work in Progress.

   [Bel94]  Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
            1994.

   [Bra97]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

   [DH96]   Deering, S., and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 1883, December 1995.

   [HD96]   Hinden, R., and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 2373, July 1998.

   [Pis94]  Piscitello, D., "FTP Operation Over Big Address Records
            (FOOBAR)", RFC 1639, June 1994.

   [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
            1981.

   [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
            September 1981.

   [PR85]   Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
            STD 9, RFC 959, October 1985.

   [RP94]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
            1700, October 1994.  See also:
            http://www.iana.org/numbers.html







Allman, et. al.             Standards Track                     [Page 6]

RFC 2428            FTP Extensions for IPv6 and NATs      September 1998


Authors' Addresses

   Mark Allman
   NASA Lewis Research Center/Sterling Software
   21000 Brookpark Rd.  MS 54-2
   Cleveland, OH  44135

   Phone: [phone]
   EMail: [e-mail]
   http://gigahertz.lerc.nasa.gov/~mallman/


   Shawn Ostermann
   School of Electrical Engineering and Computer Science
   Ohio University
   416 Morton Hall
   Athens, OH  45701

   Phone: [phone]
   EMail: [e-mail]


   Craig Metz
   The Inner Net
   Box 10314-1954
   Blacksburg, VA  24062-0314

   Phone:  (DSN) 754-8590
   EMail: [e-mail]






















Allman, et. al.             Standards Track                     [Page 7]

RFC 2428            FTP Extensions for IPv6 and NATs      September 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Allman, et. al.             Standards Track                     [Page 8]