As per Relevance of the word transport, we have this rfc below:
Network Working Group D.
Request for Comments: 1545
Category: Experimental November 1993
FTP Operation Over Big Address Records (FOOBAR
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This paper describes a convention for specifying longer addresses
the PORT command
This RFC specifies a method for assigning long addresses in
HOST-PORT specification for the data port to be used in
a data connection for File Transfer Protocol, FTP (STD 9, RFC 959).
This is a general solution, applicable for all "next generation"
alternatives, and can also be extended to allow FTP operation
transport interfaces other than TCP
Many thanks to all the folks in the IETF who casually mentioned
to do this, but who left it to me to write this RFC. Special
to Rich Colella, Bob Ullmann, Shawn Ostermann, Steve Lunt, and
Carpenter who had the time and decency to comment on the
draft. :-)
1.
The PORT command of File Transfer Protocol allows users to specify
address other than the default data port for the transport
over which data are transferred. The PORT command syntax is
PORT
The argument is the concatenation of a 32-bit
and a 16-bit TCP . This
information is broken into 8-bit fields and the value of each
is transmitted as a decimal number (in character
Piscitello [Page 1]
RFC 1545 FTP Over Big Address November 1993
representation). The fields are separated by commas. A port
is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where h1 is
high order 8 bits of the internet host address
To accommodate larger network addresses anticipated for all IP "
generation" alternatives, new commands and reply codes are needed
FTP. This memo addresses these needs
2. The LPRT
The LPRT command allows users to specify a "long" address for
transport connection over which data are transferred. The
command syntax is
LPRT
The argument is the concatenation of the
fields
o an 8-bit argument (af
o an 8-bit argument (hal
o a of (h1, h2, ...)
o an 8-bit (pal
o a of (p1, p2, ...)
The argument takes the value of the version
of IP (see Assigned Numbers, STD 2, RFC 1340), or generally speaking
an Internet layer protocol. Relevant assigned IPng version
are
Decimal
------ -------
0
1-3
4 Internet Protocol (IP
5 ST Datagram
6
7 TP/
8
9
10-14
15
Piscitello [Page 2]
RFC 1545 FTP Over Big Address November 1993
The value of each field is broken into 8-bit fields and the value
each field is transmitted as an unsigned decimal number (in
string representation, note that negative numbers are explicitly
permitted). The fields are separated by commas
A LPRT command is thus of the general
LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...
where h1 is the high order 8 bits of the internet host address,
p1 is the high order 8 bits of the port number (transport address).
3. The LPSV
The L(ONG) PASSIVE command requests the server-DTP to listen on
data port other than its default data port and to wait for
connection rather than initiate one upon receipt of a
command. The response to this command includes the address family
host address length indicator, host address, port address length,
port address this server is listening on. The reply code and
for entering the passive mode using a long address is 228
(Interpretation according to FTP is: positive completion reply 2yz
connections x2z, passive mode entered using long address xy8).
suggested textual message to accompany this reply code is
228 Entering Long Passive Mode (af,hal,h1,h2,h3,h4...,pal,p1,p2...)
4. Permanent Negative Completion Reply
The negative completion reply codes that are associated with
errors in the PORT and PASV commands are appropriate for the LPRT
LPSV commands (500, 501). An additional negative completion
code is needed to distinguish the case where a host supports the
or LPSV command, but does not support the address family specified
Of the FTP function groupings currently defined for reply
(syntax, information, connections, authentication and accounting,
file system), "connections" seems the most logical choice; thus,
additional negative command completion reply code, 521 is added,
the following suggested textual message
521 Supported address families are (af1, af2, ..., afn
Where (af1, af2, ..., afn) are the values of the version numbers
the "next generation" or other protocol families supported.
address noted earlier
Piscitello [Page 3]
RFC 1545 FTP Over Big Address November 1993
5.
An explicit address family argument in the LPRT command and
reply allows the Internet community to experiment with a variety
"next generation IP" alternatives within a common FTP
framework. (It also allows the use of a different address family
the command and data connections.) An explicit length indicator
the host address is necessary because some of the IPNG
make use of variable length addresses. An explicit host address
necessary because FTP says it's necessary
The decision to provide a length indicator for the port number is
as obvious, and certainly goes beyond the necessary condition
having to support TCP port numbers. Currently, at least one
alternative (TP/IX) supports longer port addresses. And given
increasingly "multi-protocol" nature of the Internet, it
reasonable that someone, somewhere, might wish to operate FTP
over Appletalk, IPX, and OSI networks as well as TCP/IP networks
(In theory, FTP should operate over *any* transport protocol
offers the same service as TCP.) Since some of these
protocols may offer transport selectors or port numbers that
16 bits, a length indicator may be desirable. If FTP must indeed
changed to accommodate larger network addresses, it may be prudent
determine at this time whether the same flexibility is useful
necessary with respect to transport addresses
6.
The mechanism defined here is simple, extensible, and meets both
and possibly multi-protocol internet needs
7.
STD 9, RFC 959 Postel, J., and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, USC/Information Sciences Institute
October 1985.
STD 2, RFC 1340 Reynolds, J., and J. Postel, "Assigned Numbers",
STD 2, RFC 1340, USC/Information Sciences Institute
July 1992. (Does not include recently assigned IPv
numbers).
STD 3, RFC 1123 Braden, R., Editor, "Requirements for
Hosts - Application and Support", STD 3, RFC 1123,
USC/Information Sciences Institute, October 1989.
Piscitello [Page 4]
RFC 1545 FTP Over Big Address November 1993
8. Security
Security issues are not discussed in this memo
9. Author's
David M.
Bell Communications
NVC 1C322
331 Newman Springs
Red Bank, NJ 07701
EMail: dave@mail.bellcore.
Piscitello [Page 5]
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
