29952d79f
Denis Vlasenko
2008-05-17
Subject
fix bug 2704: remove verbatim RFC text from source (this creates problems for Debian).
Binary
No binary (build failed)
Architecture & Compiler Flags
—
Build Log
(log yok)
Commit Diff GitHub →
networking/ftp_ipv6_rfc2428.txt+0 -451
| @@ -1,451 +0,0 @@ | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | Network Working Group M. Allman |
| - | Request for Comments: 2428 NASA Lewis/Sterling Software |
| - | Category: Standards Track S. Ostermann |
| - | Ohio University |
| - | C. Metz |
| - | The Inner Net |
| - | September 1998 |
| - | |
| - | |
| - | FTP Extensions for IPv6 and NATs |
| - | |
| - | Status of this Memo |
| - | |
| - | This document specifies an Internet standards track protocol for the |
| - | Internet community, and requests discussion and suggestions for |
| - | improvements. Please refer to the current edition of the "Internet |
| - | Official Protocol Standards" (STD 1) for the standardization state |
| - | and status of this protocol. Distribution of this memo is unlimited. |
| - | |
| - | Copyright Notice |
| - | |
| - | Copyright (C) The Internet Society (1998). All Rights Reserved. |
| - | |
| - | Abstract |
| - | |
| - | The specification for the File Transfer Protocol assumes that the |
| - | underlying network protocol uses a 32-bit network address |
| - | (specifically IP version 4). With the deployment of version 6 of the |
| - | Internet Protocol, network addresses will no longer be 32-bits. This |
| - | paper specifies extensions to FTP that will allow the protocol to |
| - | work over IPv4 and IPv6. In addition, the framework defined can |
| - | support additional network protocols in the future. |
| - | |
| - | 1. Introduction |
| - | |
| - | The keywords, such as MUST and SHOULD, found in this document are |
| - | used as defined in RFC 2119 [Bra97]. |
| - | |
| - | The File Transfer Protocol [PR85] only provides the ability to |
| - | communicate information about IPv4 data connections. FTP assumes |
| - | network addresses will be 32 bits in length. However, with the |
| - | deployment of version 6 of the Internet Protocol [DH96] addresses |
| - | will no longer be 32 bits long. RFC 1639 [Pis94] specifies |
| - | extensions to FTP to enable its use over various network protocols. |
| - | Unfortunately, the mechanism can fail in a multi-protocol |
| - | environment. During the transition between IPv4 and IPv6, FTP needs |
| - | the ability to negotiate the network protocol that will be used for |
| - | data transfer. |
| - | |
| - | |
| - | |
| - | Allman, et. al. Standards Track [Page 1] |
| - | |
| - | RFC 2428 FTP Extensions for IPv6 and NATs September 1998 |
| - | |
| - | |
| - | This document provides a specification for a way that FTP can |
| - | communicate data connection endpoint information for network |
| - | protocols other than IPv4. In this specification, the FTP commands |
| - | PORT and PASV are replaced with EPRT and EPSV, respectively. This |
| - | document is organized as follows. Section 2 outlines the EPRT |
| - | command and Section 3 outlines the EPSV command. Section 4 defines |
| - | the utilization of these two new FTP commands. Section 5 briefly |
| - | presents security considerations. Finally, Section 6 provides |
| - | conclusions. |
| - | |
| - | 2. The EPRT Command |
| - | |
| - | The EPRT command allows for the specification of an extended address |
| - | for the data connection. The extended address MUST consist of the |
| - | network protocol as well as the network and transport addresses. The |
| - | format of EPRT is: |
| - | |
| - | EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d> |
| - | |
| - | The EPRT command keyword MUST be followed by a single space (ASCII |
| - | 32). Following the space, a delimiter character (<d>) MUST be |
| - | specified. The delimiter character MUST be one of the ASCII |
| - | characters in range 33-126 inclusive. The character "|" (ASCII 124) |
| - | is recommended unless it coincides with a character needed to encode |
| - | the network address. |
| - | |
| - | The <net-prt> argument MUST be an address family number defined by |
| - | IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the |
| - | writing of this document). This number indicates the protocol to be |
| - | used (and, implicitly, the address length). This document will use |
| - | two of address family numbers from [RP94] as examples, according to |
| - | the following table: |
| - | |
| - | AF Number Protocol |
| - | --------- -------- |
| - | 1 Internet Protocol, Version 4 [Pos81a] |
| - | 2 Internet Protocol, Version 6 [DH96] |
| - | |
| - | The <net-addr> is a protocol specific string representation of the |
| - | network address. For the two address families specified above (AF |
| - | Number 1 and 2), addresses MUST be in the following format: |
| - | |
| - | AF Number Address Format Example |
| - | --------- -------------- ------- |
| - | 1 dotted decimal 132.235.1.2 |
| - | 2 IPv6 string 1080::8:800:200C:417A |
| - | representations |
| - | defined in [HD96] |
| - | |
| - | |
| - | |
| - | Allman, et. al. Standards Track [Page 2] |
| - | |
| - | RFC 2428 FTP Extensions for IPv6 and NATs September 1998 |
| - | |
| - | |
| - | The <tcp-port> argument must be the string representation of the |
| - | number of the TCP port on which the host is listening for the data |
| - | connection. |
| - | |
| - | The following are sample EPRT commands: |
| - | |
| - | EPRT |1|132.235.1.2|6275| |
| - | |
| - | EPRT |2|1080::8:800:200C:417A|5282| |
| - | |
| - | The first command specifies that the server should use IPv4 to open a |
| - | data connection to the host "132.235.1.2" on TCP port 6275. The |
| - | second command specifies that the server should use the IPv6 network |
| - | protocol and the network address "1080::8:800:200C:417A" to open a |
| - | TCP data connection on port 5282. |
| - | |
| - | Upon receipt of a valid EPRT command, the server MUST return a code |
| - | of 200 (Command OK). The standard negative error code 500 and 501 |
| - | [PR85] are sufficient to handle most errors (e.g., syntax errors) |
| - | involving the EPRT command. However, an additional error code is |
| - | needed. The response code 522 indicates that the server does not |
| - | support the requested network protocol. The interpretation of this |
| - | new error code is: |
| - | |
| - | 5yz Negative Completion |
| - | x2z Connections |
| - | xy2 Extended Port Failure - unknown network protocol |
| - | |
| - | The text portion of the response MUST indicate which network |
| - | protocols the server does support. If the network protocol is |
| - | unsupported, the format of the response string MUST be: |
| - | |
| - | <text stating that the network protocol is unsupported> \ |
| - | (prot1,prot2,...,protn) |
| - | |
| - | Both the numeric code specified above and the protocol information |
| - | between the characters '(' and ')' are intended for the software |
| - | automata receiving the response; the textual message between the |
| - | numeric code and the '(' is intended for the human user and can be |
| - | any arbitrary text, but MUST NOT include the characters '(' and ')'. |
| - | In the above case, the text SHOULD indicate that the network protocol |
| - | in the EPRT command is not supported by the server. The list of |
| - | protocols inside the parenthesis MUST be a comma separated list of |
| - | address family numbers. Two example response strings follow: |
| - | |
| - | Network protocol not supported, use (1) |
| - | |
| - | Network protocol not supported, use (1,2) |
| - | |
| - | |
| - | |
| - | Allman, et. al. Standards Track [Page 3] |
| - | |
| - | RFC 2428 FTP Extensions for IPv6 and NATs September 1998 |
| - | |
| - | |
| - | 3. The EPSV Command |
| - | |
| - | The EPSV command requests that a server listen on a data port and |
| - | wait for a connection. The EPSV command takes an optional argument. |
| - | The response to this command includes only the TCP port number of the |
| - | listening connection. The format of the response, however, is |
| - | similar to the argument of the EPRT command. This allows the same |
| - | parsing routines to be used for both commands. In addition, the |
| - | format leaves a place holder for the network protocol and/or network |
| - | address, which may be needed in the EPSV response in the future. The |
| - | response code for entering passive mode using an extended address |
| - | MUST be 229. The interpretation of this code, according to [PR85] |
| - | is: |
| - | |
| - | 2yz Positive Completion |
| - | x2z Connections |
| - | xy9 Extended Passive Mode Entered |
| - | |
| - | The text returned in response to the EPSV command MUST be: |
| - | |
| - | <text indicating server is entering extended passive mode> \ |
| - | (<d><d><d><tcp-port><d>) |
| - | |
| - | The portion of the string enclosed in parentheses MUST be the exact |
| - | string needed by the EPRT command to open the data connection, as |
| - | specified above. |
| - | |
| - | The first two fields contained in the parenthesis MUST be blank. The |
| - | third field MUST be the string representation of the TCP port number |
| - | on which the server is listening for a data connection. The network |
| - | protocol used by the data connection will be the same network |
| - | protocol used by the control connection. In addition, the network |
| - | address used to establish the data connection will be the same |
| - | network address used for the control connection. An example response |
| - | string follows: |
| - | |
| - | Entering Extended Passive Mode (|||6446|) |
| - | |
| - | The standard negative error codes 500 and 501 are sufficient to |
| - | handle all errors involving the EPSV command (e.g., syntax errors). |
| - | |
| - | When the EPSV command is issued with no argument, the server will |
| - | choose the network protocol for the data connection based on the |
| - | protocol used for the control connection. However, in the case of |
| - | proxy FTP, this protocol might not be appropriate for communication |
| - | between the two servers. Therefore, the client needs to be able to |
| - | request a specific protocol. If the server returns a protocol that |
| - | is not supported by the host that will be connecting to the port, the |
| - | |
| - | |
| - | |
| - | Allman, et. al. Standards Track [Page 4] |
| - | |
| - | 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: (216) 433-6586 |
| - | EMail: [email protected] |
| - | http://gigahertz.lerc.nasa.gov/~mallman/ |
| - | |
| - | |
| - | Shawn Ostermann |
| - | School of Electrical Engineering and Computer Science |
| - | Ohio University |
| - | 416 Morton Hall |
| - | Athens, OH 45701 |
| - | |
| - | Phone: (740) 593-1234 |
| - | EMail: [email protected] |
| - | |
| - | |
| - | Craig Metz |
| - | The Inner Net |
| - | Box 10314-1954 |
| - | Blacksburg, VA 24062-0314 |
| - | |
| - | Phone: (DSN) 754-8590 |
| - | EMail: [email protected] |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | |
| - | 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] |
| - | |