As per Relevance of the word standard, we have this rfc below:
Network Working Group M.
Request for Comments: 2428 NASA Lewis/Sterling
Category: Standards Track S.
Ohio
C.
The Inner
September 1998
FTP Extensions for IPv6 and
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
The specification for the File Transfer Protocol assumes that
underlying network protocol uses a 32-bit network
(specifically IP version 4). With the deployment of version 6 of
Internet Protocol, network addresses will no longer be 32-bits.
paper specifies extensions to FTP that will allow the protocol
work over IPv4 and IPv6. In addition, the framework defined
support additional network protocols in the future
1.
The keywords, such as MUST and SHOULD, found in this document
used as defined in RFC 2119 [Bra97].
The File Transfer Protocol [PR85] only provides the ability
communicate information about IPv4 data connections. FTP
network addresses will be 32 bits in length. However, with
deployment of version 6 of the Internet Protocol [DH96]
will no longer be 32 bits long. RFC 1639 [Pis94]
extensions to FTP to enable its use over various network protocols
Unfortunately, the mechanism can fail in a multi-
environment. During the transition between IPv4 and IPv6, FTP
the ability to negotiate the network protocol that will be used
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
communicate data connection endpoint information for
protocols other than IPv4. In this specification, the FTP
PORT and PASV are replaced with EPRT and EPSV, respectively.
document is organized as follows. Section 2 outlines the
command and Section 3 outlines the EPSV command. Section 4
the utilization of these two new FTP commands. Section 5
presents security considerations. Finally, Section 6
conclusions
2. The EPRT
The EPRT command allows for the specification of an extended
for the data connection. The extended address MUST consist of
network protocol as well as the network and transport addresses.
format of EPRT is
EPRT
The EPRT command keyword MUST be followed by a single space (
32). Following the space, a delimiter character () MUST
specified. The delimiter character MUST be one of the
characters in range 33-126 inclusive. The character "|" (ASCII 124)
is recommended unless it coincides with a character needed to
the network address
The argument MUST be an address family number defined
IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of
writing of this document). This number indicates the protocol to
used (and, implicitly, the address length). This document will
two of address family numbers from [RP94] as examples, according
the following table
AF Number
--------- --------
1 Internet Protocol, Version 4 [Pos81a
2 Internet Protocol, Version 6 [DH96]
The is a protocol specific string representation of
network address. For the two address families specified above (
Number 1 and 2), addresses MUST be in the following format
AF Number Address Format
--------- -------------- -------
1 dotted decimal 132.235.1.2
2 IPv6 string 1080::8:800:200C:417
defined in [HD96]
Allman, et. al. Standards Track [Page 2]
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
The argument must be the string representation of
number of the TCP port on which the host is listening for the
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
data connection to the host "132.235.1.2" on TCP port 6275.
second command specifies that the server should use the IPv6
protocol and the network address "1080::8:800:200C:417A" to open
TCP data connection on port 5282.
Upon receipt of a valid EPRT command, the server MUST return a
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
needed. The response code 522 indicates that the server does
support the requested network protocol. The interpretation of
new error code is
5yz Negative
x2z
xy2 Extended Port Failure - unknown network
The text portion of the response MUST indicate which
protocols the server does support. If the network protocol
unsupported, the format of the response string MUST be
protocol is unsupported> \
(prot1,prot2,...,protn
Both the numeric code specified above and the protocol
between the characters '(' and ')' are intended for the
automata receiving the response; the textual message between
numeric code and the '(' is intended for the human user and can
any arbitrary text, but MUST NOT include the characters '(' and ')'.
In the above case, the text SHOULD indicate that the network
in the EPRT command is not supported by the server. The list
protocols inside the parenthesis MUST be a comma separated list
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
The EPSV command requests that a server listen on a data port
wait for a connection. The EPSV command takes an optional argument
The response to this command includes only the TCP port number of
listening connection. The format of the response, however,
similar to the argument of the EPRT command. This allows the
parsing routines to be used for both commands. In addition,
format leaves a place holder for the network protocol and/or
address, which may be needed in the EPSV response in the future.
response code for entering passive mode using an extended
MUST be 229. The interpretation of this code, according to [PR85]
is
2yz Positive
x2z
xy9 Extended Passive Mode
The text returned in response to the EPSV command MUST be
indicating server is entering extended passive mode> \
()
The portion of the string enclosed in parentheses MUST be the
string needed by the EPRT command to open the data connection,
specified above
The first two fields contained in the parenthesis MUST be blank.
third field MUST be the string representation of the TCP port
on which the server is listening for a data connection. The
protocol used by the data connection will be the same
protocol used by the control connection. In addition, the
address used to establish the data connection will be the
network address used for the control connection. An example
string follows
Entering Extended Passive Mode (|||6446|)
The standard negative error codes 500 and 501 are sufficient
handle all errors involving the EPSV command (e.g., syntax errors).
When the EPSV command is issued with no argument, the server
choose the network protocol for the data connection based on
protocol used for the control connection. However, in the case
proxy FTP, this protocol might not be appropriate for
between the two servers. Therefore, the client needs to be able
request a specific protocol. If the server returns a protocol
is not supported by the host that will be connecting to the port,
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
close down the listening connection. The client can then send
EPSV command requesting the use of a specific network protocol,
follows
EPSV
If the requested protocol is supported by the server, it SHOULD
the protocol. If not, the server MUST return the 522 error
as outlined in section 2.
Finally, the EPSV command can be used with the argument "ALL"
inform Network Address Translators that the EPRT command (as well
other data commands) will no longer be used. An example of
command follows
EPSV
Upon receipt of an EPSV ALL command, the server MUST reject all
connection setup commands other than EPSV (i.e., EPRT, PORT, PASV,
al.). This use of the EPSV command is further explained in
4.
4. Command
For all FTP transfers where the control and data connection(s)
being established between the same two machines, the EPSV
MUST be used. Using the EPSV command benefits performance
transfers that traverse firewalls or Network Address
(NATs). RFC 1579 [Bel94] recommends using the passive command
behind firewalls since firewalls do not generally allow
connections (which are required when using the PORT (EPRT) command).
In addition, using EPSV as defined in this document does not
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
used. Finally, if the client issues an "EPSV ALL" command, NATs
be able to put the connection on a "fast path" through
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
issue this command as soon as possible. If a client later finds
it must do a three-way FTP transfer after issuing an EPSV
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
The authors do not believe that these changes to FTP introduce
security problems. A companion Work in Progress [AO98] is a
general discussion of FTP security issues and techniques to
these security problems
6.
The extensions specified in this paper will enable FTP to
over a variety of network protocols
[AO98] Allman, M., and S. Ostermann, "FTP
Considerations", Work in Progress
[Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579,
1994.
[Bra97] Bradner, S., "Key words for use in RFCs to
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
Architecture", RFC 2373, July 1998.
[Pis94] Piscitello, D., "FTP Operation Over Big Address
(FOOBAR)", RFC 1639, June 1994.
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791,
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,
1700, October 1994. See also
http://www.iana.org/numbers.
Allman, et. al. Standards Track [Page 6]
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
Authors'
Mark
NASA Lewis Research Center/Sterling
21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135
Phone: (216) 433-6586
EMail: mallman@lerc.nasa.
http://gigahertz.lerc.nasa.gov/~mallman
Shawn
School of Electrical Engineering and Computer
Ohio
416 Morton
Athens, OH 45701
Phone: (740) 593-1234
EMail: ostermann@cs.ohiou.
Craig
The Inner
Box 10314-1954
Blacksburg, VA 24062-0314
Phone: (DSN) 754-8590
EMail: cmetz@inner.
Allman, et. al. Standards Track [Page 7]
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Allman, et. al. Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
