As per Relevance of the word transport, we have this rfc below:
Network Working Group D.
Request for Comments: 1639 Core Competence, Inc
Obsoletes: 1545 June 1994
Category:
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 address
other than the default Internet address family in FTP commands
replies
In the File Transfer Protocol (STD 9, RFC 959), the PORT
argument specifies the data port to be used to
a data connection for FTP (STD 9, RFC 959). This argument is
used in the PASV reply to request the server-DTP to listen on a
port other than its default data port. This RFC specifies a
for assigning addresses other than 32-bit IPv4 addresses to
ports through the specification of a "long Port (LPRT)" command
"Long Passive (LPSV)" reply, each having as its argument a
host-port>, which allows for additional address families,
length network addresses and variable length port numbers
This is a general solution, applicable for all "next generation"
alternatives, as well as for other network protocols than IP.
revision also extends FTP to allow for its operation over
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, Steve Lunt, Jay Israel, Jon Postel
Shawn Ostermann, and Tae Kyong Song, who contributed to this work
Piscitello [Page 1]
RFC 1639 FTP Over Big Address June 1994
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
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
The argument is also used by the PASV reply, and
certain negative completion replies
To accommodate larger network addresses anticipated for all IP "
generation" alternatives, and to accommodate FTP operation
network and transport protocols other than IP, new commands and
codes are needed for FTP
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 initial values assigned to the argument take
value of the version number of IP (see Assigned Numbers, STD 2,
1340); values in the range of 0-15 decimal are thus reserved for
Piscitello [Page 2]
RFC 1639 FTP Over Big Address June 1994
and assigned by IANA. Values in the range 16-255 are available
the IANA to assign to all other network layer protocols over
FTP may be operated
Relevant assigned numbers for FOOBAR are
Decimal
------ -------
0
1-3
4 Internet Protocol (IP
5 ST Datagram
6
7 TP/
8
9
10-14
15
16 Novell
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 of the listener process at the server. The reply
and text 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).
The suggested text message to accompany this reply code is
228 Entering Long Passive
(af, hal, h1, h2, h3,..., pal, p1, p2...)
Piscitello [Page 3]
RFC 1639 FTP Over Big Address June 1994
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 defined for reply codes (syntax
information, connections, authentication and accounting, and
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. (Note:
has been suggested that the families could also be represented
ASCII strings.)
5.
An explicit address family argument in the LPRT command and
reply allows the Internet community to experiment with a variety
"next generation IP" and other network layer protocol
within a common FTP implementation framework. (It also allows the
of a different address family on the command and data connections.)
An explicit length indicator for the host address is
because some of the IPNG alternatives make use of variable
addresses. An explicit host address is necessary because FTP
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 IPng alternative (TP/IX) supports longer
addresses. And given the increasingly "multi-protocol" nature of
Internet, it seems reasonable that someone, somewhere, might wish
operate FTP operate over Appletalk, IPX, and OSI networks as well
TCP/IP networks. (In theory, FTP should operate over *any*
protocol that offers the same service as TCP.) Since some of
transport protocols may offer transport selectors or port
that exceed 16 bits, a length indicator may be desirable. If FTP
indeed be changed to accommodate larger network addresses, it may
prudent to determine at this time whether the same flexibility
useful or necessary with respect to transport addresses
Piscitello [Page 4]
RFC 1639 FTP Over Big Address June 1994
6.
The mechanism defined here is simple, extensible, and meets both
and 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.
8. Security
Security issues are not discussed in this memo
9. Author's
David M.
Core Competence, Inc
1620 Tuckerstown
Dresher, PA 19025
EMail: dave@corecom.
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
