diff options
| -rw-r--r-- | networking/ftp_ipv6_rfc2428.txt | 451 |
1 files changed, 0 insertions, 451 deletions
diff --git a/networking/ftp_ipv6_rfc2428.txt b/networking/ftp_ipv6_rfc2428.txt deleted file mode 100644 index a6ec353..0000000 --- a/networking/ftp_ipv6_rfc2428.txt +++ /dev/null @@ -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: mallman@lerc.nasa.gov - 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: ostermann@cs.ohiou.edu - - - Craig Metz - The Inner Net - Box 10314-1954 - Blacksburg, VA 24062-0314 - - Phone: (DSN) 754-8590 - EMail: cmetz@inner.net - - - - - - - - - - - - - - - - - - - - - - -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] - |