Update of /cvsroot/curl/curl-www/rfc
In directory labb:/tmp/cvs-serv18663
Modified Files:
filedesc
Added Files:
rfc1350.txt rfc3617.txt
Log Message:
TFTP-related specs added
Index: filedesc
===================================================================
RCS file: /cvsroot/curl/curl-www/rfc/filedesc,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- filedesc 27 Aug 2005 05:26:38 -0000 1.9
+++ filedesc 2 Sep 2005 07:02:16 -0000 1.10
@@ -1,15 +1,17 @@
cookie_spec.html Netscape's cookie specification
rfc0822.txt Arpa Internet Text Messages (mostly for the date format)
rfc0850.txt Interchange of USENET Messages (mostly for the date format)
+rfc0959.txt File Transfer Protocol (FTP)
rfc1036.txt Interchange of USENET Messages (mostly for the date format)
rfc1123.txt Requirements for Internet Hosts
-rfc0959.txt File Transfer Protocol (FTP)
+rfc1350.txt The TFTP Protocol (Revision 2)
rfc1635.txt How to Use Anonymous FTP
rfc1639.txt FTP Operation Over Big Address Records (FOOBAR)
rfc1738.txt Uniform Resource Locators (obsoleted by RFC 2396)
rfc1777.txt Lightweight Directory Access Protocol
rfc1808.txt Relative Uniform Resource Locators
rfc1867.txt Form-based File Upload in HTML
+rfc1884.txt IP Version 6 Addressing Architecture (obsolete)
rfc1928.txt SOCKS Protocol Version 5
rfc1945.txt Hypertext Transfer Protocol -- HTTP/1.0
rfc1950.txt ZLIB Compressed Data Format Specification
@@ -27,10 +29,11 @@
rfc2184.txt MIME Parameter Value and Encoded Word Extensions
rfc2228.txt FTP Security Extensions
rfc2229.txt A Dictionary Server Protocol
+rfc2231.txt MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
rfc2246.txt The TLS Protocol
rfc2255.txt Newer LDAP URL syntax document.
-rfc2231.txt MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
rfc2326.txt Real Time Streaming Protocol (RTSP)
+rfc2373.txt IP Version 6 Addressing Architecture (obsolete)
rfc2388.txt Returning Values from Forms: multipart/form-data
rfc2389.txt Feature negotiation mechanism for FTP
rfc2396.txt Uniform Resource Identifiers: Generic Syntax and Semantics
@@ -49,9 +52,8 @@
rfc2964.txt Use of HTTP State Management
rfc2965.txt HTTP State Management Mechanism. Cookies. (Obsoletes RFC2109)
rfc3280.txt Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
-rfc1884.txt IP Version 6 Addressing Architecture (obsolete)
-rfc2373.txt IP Version 6 Addressing Architecture (obsolete)
rfc3513.txt IP Version 6 Addressing Architecture
+rfc3617.txt Uniform Resource Identifier (URI) Scheme for TFTP
draft-murray-auth-ftp-ssl-15.txt Securing FTP with TLS
draft-murray-auth-ftp-ssl-16.txt Securing FTP with TLS
ntlm.html Eric Glass' NTLM Authentication Protocol specification
--- NEW FILE: rfc3617.txt ---
Network Working Group E. Lear
Request for Comments: 3617 Cisco Systems
Category: Informational October 2003
Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the
Trivial File Transfer Protocol (TFTP)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL
protocol that has been in use on the Internet for quite a long time.
While this document discourages its continued use, largely due to
security concerns, we do define a Uniform Resource Identifier (URI)
scheme, as well as discuss the protocol's applicability.
1. Introduction
The Trivial File Transfer Protocol (TFTP) has been around for quite
some time. Its common uses are to initially configure devices or to
load new versions of operating system code [1]. As devices begin to
adopt use of Uniform Resource Identifiers (URIs) and Uniform Resource
Locators (URLs), for completeness we specify a way to reference files
that is still quite common. Use of a URI is a convenient way to
indicate underlying mechanism, server name or address, and file name.
WHILE WE DEFINE THE TFTP URI TYPE, WE STRONGLY RECOMMEND AGAINST THE
CONTINUED USE OF TFTP, FOR REASONS LISTED IN SECTION 5 (amongst
others). The definition of a URI merely allows tools that currently
use protocols such as TFTP to have a standard name space and
structure where one can understand the process used to resolve that
name. Indeed it is hoped that the definition of this URI will ease
transition to modern file transfer mechanisms.
Lear Informational [Page 1]
RFC 3617 URI Scheme for TFTP October 2003
2. Syntax of a TFTP URI
A TFTP URI has the following ABNF syntax [2]:
tftpURI = "tftp://" host "/" file [ mode ]
mode = ";" "mode=" ( "netascii" / "octet" )
file = *( unreserved / escaped )
host = <as specified by RFC 2732 [3]>
unreserved = <as specified in RFC 2396 [4]>
escaped = <as specified in RFC 2396>
A TFTP URI specifies a file that is to be found or placed on a TFTP
server. The "mode" option is an option indicating how the file is to
be transferred. If left unspecified, the mode is assumed to be
"octet". A third "mail" mode was deprecated at the time RFC 1350 was
adopted, and is not specified.
2.1. Encoding Rules
Aside from syntax as described above, the TFTP protocol does not
specify length limits to either file names or file sizes. In the
case of file names, they may contain any character so long as those
characters are properly escaped as described above.
3. Semantics and Operations
As previously stated the TFTP URI is a reference to a file. The
allowed operations on a TFTP URI are read and write. When a TFTP URI
is read the underlying mechanisms retrieve the named file via the
TFTP protocol from the specified host with the optionally specified
mode. When a TFTP URI is written the underlying mechanisms transmit
a file via TFTP to a specified server to either the specified file
using the optionally specified mode. No other operations are
supported.
Note that it is not possible to retrieve file size information prior
to retrieval, nor is it possible to determine file existence or
permissions prior to transfer. Files transferred may or may not
arrive intact, as there is no guarantee of reliability or even
completeness. See the TFTP standard for more details. For more
robust file transfer, consider using either FTP or HTTP [5, 6].
Lear Informational [Page 2]
RFC 3617 URI Scheme for TFTP October 2003
4. Examples
tftp://example.com/myconfigurationfile;mode=netascii
This example references file "myconfigurationfile" on server
"example.com" and requests that the transfer occur in netascii mode.
tftp://example.com/mystartupfile
This file references file "mystartupfile" on server "example.com".
The transfer should occur in octet mode, since no other mode was
specified.
5. Security Considerations and Concerns about TFTP's use
Use of TFTP has been historically limited to those devices where a
more full protocol stack is impractical due to either memory or CPU
constraints. While this still may be the case with a toaster, it is
unlikely to be the case for even the simplest piece of network
support hardware, such as simple routers or switches. There are a
myriad of reasons to use some protocol other than TFTP, only a few of
which are listed below.
TFTP has no mechanism for access control within the protocol, and
there is no protection from a man in the middle attack.
Implementations are left to their own devices in this area. Because
TFTP has no way to determine file sizes in advance, implementations
should be prepared to properly check the bounds of transfers so that
neither memory nor disk limitations are exceeded.
TFTP is not well suited to large files for the following reasons.
TFTP has no inherent integrity check. There is no way to determine
what one side sent is what the other received. There is no way to
restart TFTP transfers from anywhere other than the beginning. TFTP
is a lock step protocol. Only one packet may be in flight at any one
time. There is no slow start or smart backoff mechanism in TFTP, but
very simple timeouts.
TFTP is not well suited to file transfers across administrative
domains. For one thing, TFTP utilizes UDP, and many NATs will not
either support or allow TFTP transfers. More likely firewalls will
prohibit transfers.
There are no caching semantics within TFTP. There is no safe way to
cache information using the TFTP protocol.
Lear Informational [Page 3]
RFC 3617 URI Scheme for TFTP October 2003
In summary, use of TFTP is strongly discouraged except in the most
limited of circumstances where memory and CPU are at the highest
premium.
6. IANA Considerations
The IANA has registered the URL registration template found in
Appendix A in accordance with RFC 2717 [7].
7. Acknowledgments
The author thanks Larry Masinter, Randy Presuhn, Phil Schafer, and
Bill Fenner for their help in developing this document.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Lear Informational [Page 4]
RFC 3617 URI Scheme for TFTP October 2003
Appendix A. Registration Template
URL scheme name: tftp
URL scheme syntax: Section 2
Character encoding considerations: Section 2
Intended usage: Section 1
Applications and/or protocols which use this scheme: [1]
Interoperability considerations: None
Security considerations: Section 5
Relevant publications: [1]
Contact: The author, Section 8
Author/Change Controller: IESG
Lear Informational [Page 5]
RFC 3617 URI Scheme for TFTP October 2003
References
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
July 1992.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[6] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[7] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999.
Author's Address
Eliot Lear
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134-1706
Phone: +1 (408) 527 4020
EMail: [email protected]
Lear Informational [Page 6]
RFC 3617 URI Scheme for TFTP October 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lear Informational [Page 7]
--- NEW FILE: rfc1350.txt ---
Network Working Group K. Sollins
Request For Comments: 1350 MIT
STD: 33 July 1992
Obsoletes: RFC 783
THE TFTP PROTOCOL (REVISION 2)
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Summary
TFTP is a very simple protocol used to transfer files. It is from
this that its name comes, Trivial File Transfer Protocol or TFTP.
Each nonterminal packet is acknowledged separately. This document
describes the protocol and its types of packets. The document also
explains the reasons behind some of the design decisions.
Acknowlegements
The protocol was originally designed by Noel Chiappa, and was
redesigned by him, Bob Baldwin and Dave Clark, with comments from
Steve Szymanski. The current revision of the document includes
modifications stemming from discussions with and suggestions from
Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,
Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy
Yellick, and the author. The acknowledgement and retransmission
scheme was inspired by TCP, and the error mechanism was suggested by
PARC's EFTP abort message.
The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol
bug [4] and other minor document problems was done by Noel Chiappa.
This research was supported by the Advanced Research Projects Agency
of the Department of Defense and was monitored by the Office of Naval
Research under contract number N00014-75-C-0661.
1. Purpose
TFTP is a simple protocol to transfer files, and therefore was named
the Trivial File Transfer Protocol or TFTP. It has been implemented
on top of the Internet User Datagram protocol (UDP or Datagram) [2]
Sollins [Page 1]
RFC 1350 TFTP Revision 2 July 1992
so it may be used to move files between machines on different
networks implementing UDP. (This should not exclude the possibility
of implementing TFTP on top of other datagram protocols.) It is
designed to be small and easy to implement. Therefore, it lacks most
of the features of a regular FTP. The only thing it can do is read
and write files (or mail) from/to a remote server. It cannot list
directories, and currently has no provisions for user authentication.
In common with other Internet protocols, it passes 8 bit bytes of
data.
Three modes of transfer are currently supported: netascii (This is
ascii as defined in "USA Standard Code for Information Interchange"
[1] with the modifications specified in "Telnet Protocol
Specification" [3].) Note that it is 8 bit ascii. The term
"netascii" will be used throughout this document to mean this
particular version of ascii.); octet (This replaces the "binary" mode
of previous versions of this document.) raw 8 bit bytes; mail,
netascii characters sent to a user rather than a file. (The mail
mode is obsolete and should not be implemented or used.) Additional
modes can be defined by pairs of cooperating hosts.
Reference [4] (section 4.2) should be consulted for further valuable
directives and suggestions on TFTP.
2. Overview of the Protocol
Any transfer begins with a request to read or write a file, which
also serves to request a connection. If the server grants the
request, the connection is opened and the file is sent in fixed
length blocks of 512 bytes. Each data packet contains one block of
data, and must be acknowledged by an acknowledgment packet before the
next packet can be sent. A data packet of less than 512 bytes
signals termination of a transfer. If a packet gets lost in the
network, the intended recipient will timeout and may retransmit his
last packet (which may be data or an acknowledgment), thus causing
the sender of the lost packet to retransmit that lost packet. The
sender has to keep just one packet on hand for retransmission, since
the lock step acknowledgment guarantees that all older packets have
been received. Notice that both machines involved in a transfer are
considered senders and receivers. One sends data and receives
acknowledgments, the other sends acknowledgments and receives data.
Most errors cause termination of the connection. An error is
signalled by sending an error packet. This packet is not
acknowledged, and not retransmitted (i.e., a TFTP server or user may
terminate after sending an error message), so the other end of the
connection may not get it. Therefore timeouts are used to detect
such a termination when the error packet has been lost. Errors are
Sollins [Page 2]
RFC 1350 TFTP Revision 2 July 1992
caused by three types of events: not being able to satisfy the
request (e.g., file not found, access violation, or no such user),
receiving a packet which cannot be explained by a delay or
duplication in the network (e.g., an incorrectly formed packet), and
losing access to a necessary resource (e.g., disk full or access
denied during a transfer).
TFTP recognizes only one error condition that does not cause
termination, the source port of a received packet being incorrect.
In this case, an error packet is sent to the originating host.
This protocol is very restrictive, in order to simplify
implementation. For example, the fixed length blocks make allocation
straight forward, and the lock step acknowledgement provides flow
control and eliminates the need to reorder incoming data packets.
3. Relation to other Protocols
As mentioned TFTP is designed to be implemented on top of the
Datagram protocol (UDP). Since Datagram is implemented on the
Internet protocol, packets will have an Internet header, a Datagram
header, and a TFTP header. Additionally, the packets may have a
header (LNI, ARPA header, etc.) to allow them through the local
transport medium. As shown in Figure 3-1, the order of the contents
of a packet will be: local medium header, if used, Internet header,
Datagram header, TFTP header, followed by the remainder of the TFTP
packet. (This may or may not be data depending on the type of packet
as specified in the TFTP header.) TFTP does not specify any of the
values in the Internet header. On the other hand, the source and
destination port fields of the Datagram header (its format is given
in the appendix) are used by TFTP and the length field reflects the
size of the TFTP packet. The transfer identifiers (TID's) used by
TFTP are passed to the Datagram layer to be used as ports; therefore
they must be between 0 and 65,535. The initialization of TID's is
discussed in the section on initial connection protocol.
The TFTP header consists of a 2 byte opcode field which indicates
the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the
formats of the various types of packets are discussed further in the
section on TFTP packets.
Sollins [Page 3]
RFC 1350 TFTP Revision 2 July 1992
---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------
Figure 3-1: Order of Headers
4. Initial Connection Protocol
A transfer is established by sending a request (WRQ to write onto a
foreign file system, or RRQ to read from it), and receiving a
positive reply, an acknowledgment packet for write, or the first data
packet for read. In general an acknowledgment packet will contain
the block number of the data packet being acknowledged. Each data
packet has associated with it a block number; block numbers are
consecutive and begin with one. Since the positive response to a
write request is an acknowledgment packet, in this special case the
block number will be zero. (Normally, since an acknowledgment packet
is acknowledging a data packet, the acknowledgment packet will
contain the block number of the data packet being acknowledged.) If
the reply is an error packet, then the request has been denied.
In order to create a connection, each end of the connection chooses a
TID for itself, to be used for the duration of that connection. The
TID's chosen for a connection should be randomly chosen, so that the
probability that the same number is chosen twice in immediate
succession is very low. Every packet has associated with it the two
TID's of the ends of the connection, the source TID and the
destination TID. These TID's are handed to the supporting UDP (or
other datagram protocol) as the source and destination ports. A
requesting host chooses its source TID as described above, and sends
its initial request to the known TID 69 decimal (105 octal) on the
serving host. The response to the request, under normal operation,
uses a TID chosen by the server as its source TID and the TID chosen
for the previous message by the requestor as its destination TID.
The two chosen TID's are then used for the remainder of the transfer.
As an example, the following shows the steps used to establish a
connection to write a file. Note that WRQ, ACK, and DATA are the
names of the write request, acknowledgment, and data types of packets
respectively. The appendix contains a similar example for reading a
file.
Sollins [Page 4]
RFC 1350 TFTP Revision 2 July 1992
1. Host A sends a "WRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "ACK" (with block number= 0) to host A with
source= B's TID, destination= A's TID.
At this point the connection has been established and the first data
packet can be sent by Host A with a sequence number of 1. In the
next step, and in all succeeding steps, the hosts should make sure
that the source TID matches the value that was agreed on in steps 1
and 2. If a source TID does not match, the packet should be
discarded as erroneously sent from somewhere else. An error packet
should be sent to the source of the incorrect packet, while not
disturbing the transfer. This can be done only if the TFTP in fact
receives a packet with an incorrect TID. If the supporting protocols
do not allow it, this particular error condition will not arise.
The following example demonstrates a correct operation of the
protocol in which the above situation can occur. Host A sends a
request to host B. Somewhere in the network, the request packet is
duplicated, and as a result two acknowledgments are returned to host
A, with different TID's chosen on host B in response to the two
requests. When the first response arrives, host A continues the
connection. When the second response to the request arrives, it
should be rejected, but there is no reason to terminate the first
connection. Therefore, if different TID's are chosen for the two
connections on host B and host A checks the source TID's of the
messages it receives, the first connection can be maintained while
the second is rejected by returning an error packet.
5. TFTP Packets
TFTP supports five types of packets, all of which have been mentioned
above:
opcode operation
1 Read request (RRQ)
2 Write request (WRQ)
3 Data (DATA)
4 Acknowledgment (ACK)
5 Error (ERROR)
The TFTP header of a packet contains the opcode associated with
that packet.
Sollins [Page 5]
RFC 1350 TFTP Revision 2 July 1992
2 bytes string 1 byte string 1 byte
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------
Figure 5-1: RRQ/WRQ packet
RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
shown in Figure 5-1. The file name is a sequence of bytes in
netascii terminated by a zero byte. The mode field contains the
string "netascii", "octet", or "mail" (or any combination of upper
and lower case, such as "NETASCII", NetAscii", etc.) in netascii
indicating the three modes defined in the protocol. A host which
receives netascii mode data must translate the data to its own
format. Octet mode is used to transfer a file that is in the 8-bit
format of the machine from which the file is being transferred. It
is assumed that each type of machine has a single 8-bit format that
is more common, and that that format is chosen. For example, on a
DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with
four bits of breakage. If a host receives a octet file and then
returns it, the returned file must be identical to the original.
Mail mode uses the name of a mail recipient in place of a file and
must begin with a WRQ. Otherwise it is identical to netascii mode.
The mail recipient string should be of the form "username" or
"username@hostname". If the second form is used, it allows the
option of mail forwarding by a relay computer.
The discussion above assumes that both the sender and recipient are
operating in the same mode, but there is no reason that this has to
be the case. For example, one might build a storage server. There
is no reason that such a machine needs to translate netascii into its
own form of text. Rather, the sender might send files in netascii,
but the storage server might simply store them without translation in
8-bit format. Another such situation is a problem that currently
exists on DEC-20 systems. Neither netascii nor octet accesses all
the bits in a word. One might create a special mode for such a
machine which read all the bits in a word, but in which the receiver
stored the information in 8-bit format. When such a file is
retrieved from the storage site, it must be restored to its original
form to be useful, so the reverse mode must also be implemented. The
user site will have to remember some information to achieve this. In
both of these examples, the request packets would specify octet mode
to the foreign host, but the local host would be in some other mode.
No such machine or application specific modes have been specified in
TFTP, but one would be compatible with this specification.
It is also possible to define other modes for cooperating pairs of
Sollins [Page 6]
RFC 1350 TFTP Revision 2 July 1992
hosts, although this must be done with care. There is no requirement
that any other hosts implement these. There is no central authority
that will define these modes or assign them names.
2 bytes 2 bytes n bytes
----------------------------------
| Opcode | Block # | Data |
----------------------------------
Figure 5-2: DATA packet
Data is actually transferred in DATA packets depicted in Figure 5-2.
DATA packets (opcode = 3) have a block number and data field. The
block numbers on data packets begin with one and increase by one for
each new block of data. This restriction allows the program to use a
single number to discriminate between new packets and duplicates.
The data field is from zero to 512 bytes long. If it is 512 bytes
long, the block is not the last block of data; if it is from zero to
511 bytes long, it signals the end of the transfer. (See the section
on Normal Termination for details.)
All packets other than duplicate ACK's and those used for
termination are acknowledged unless a timeout occurs [4]. Sending a
DATA packet is an acknowledgment for the first ACK packet of the
previous DATA packet. The WRQ and DATA packets are acknowledged by
ACK or ERROR packets, while RRQ
2 bytes 2 bytes
---------------------
| Opcode | Block # |
---------------------
Figure 5-3: ACK packet
and ACK packets are acknowledged by DATA or ERROR packets. Figure
5-3 depicts an ACK packet; the opcode is 4. The block number in
an ACK echoes the block number of the DATA packet being
acknowledged. A WRQ is acknowledged with an ACK packet having a
block number of zero.
Sollins [Page 7]
RFC 1350 TFTP Revision 2 July 1992
2 bytes 2 bytes string 1 byte
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------
Figure 5-4: ERROR packet
An ERROR packet (opcode 5) takes the form depicted in Figure 5-4. An
ERROR packet can be the acknowledgment of any other type of packet.
The error code is an integer indicating the nature of the error. A
table of values and meanings is given in the appendix. (Note that
several error codes have been added to this version of this
document.) The error message is intended for human consumption, and
should be in netascii. Like all other strings, it is terminated with
a zero byte.
6. Normal Termination
The end of a transfer is marked by a DATA packet that contains
between 0 and 511 bytes of data (i.e., Datagram length < 516). This
packet is acknowledged by an ACK packet like all other DATA packets.
The host acknowledging the final DATA packet may terminate its side
of the connection on sending the final ACK. On the other hand,
dallying is encouraged. This means that the host sending the final
ACK will wait for a while before terminating in order to retransmit
the final ACK if it has been lost. The acknowledger will know that
the ACK has been lost if it receives the final DATA packet again.
The host sending the last DATA must retransmit it until the packet is
acknowledged or the sending host times out. If the response is an
ACK, the transmission was completed successfully. If the sender of
the data times out and is not prepared to retransmit any more, the
transfer may still have been completed successfully, after which the
acknowledger or network may have experienced a problem. It is also
possible in this case that the transfer was unsuccessful. In any
case, the connection has been closed.
7. Premature Termination
If a request can not be granted, or some error occurs during the
transfer, then an ERROR packet (opcode 5) is sent. This is only a
courtesy since it will not be retransmitted or acknowledged, so it
may never be received. Timeouts must also be used to detect errors.
Sollins [Page 8]
RFC 1350 TFTP Revision 2 July 1992
I. Appendix
Order of Headers
2 bytes
----------------------------------------------------------
| Local Medium | Internet | Datagram | TFTP Opcode |
----------------------------------------------------------
TFTP Formats
Type Op # Format without header
2 bytes string 1 byte string 1 byte
-----------------------------------------------
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ -----------------------------------------------
2 bytes 2 bytes n bytes
---------------------------------
DATA | 03 | Block # | Data |
---------------------------------
2 bytes 2 bytes
-------------------
ACK | 04 | Block # |
--------------------
2 bytes 2 bytes string 1 byte
----------------------------------------
ERROR | 05 | ErrorCode | ErrMsg | 0 |
----------------------------------------
Initial Connection Protocol for reading a file
1. Host A sends a "RRQ" to host B with source= A's TID,
destination= 69.
2. Host B sends a "DATA" (with block number= 1) to host A with
source= B's TID, destination= A's TID.
Sollins [Page 9]
RFC 1350 TFTP Revision 2 July 1992
Error Codes
Value Meaning
0 Not defined, see error message (if any).
1 File not found.
2 Access violation.
3 Disk full or allocation exceeded.
4 Illegal TFTP operation.
5 Unknown transfer ID.
6 File already exists.
7 No such user.
Internet User Datagram Header [2]
(This has been included only for convenience. TFTP need not be
implemented on top of the Internet User Datagram Protocol.)
Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Values of Fields
Source Port Picked by originator of packet.
Dest. Port Picked by destination machine (69 for RRQ or WRQ).
Length Number of bytes in UDP packet, including UDP header.
Checksum Reference 2 describes rules for computing checksum.
(The implementor of this should be sure that the
correct algorithm is used here.)
Field contains zero if unused.
Note: TFTP passes transfer identifiers (TID's) to the Internet User
Datagram protocol to be used as the source and destination ports.
Sollins [Page 10]
RFC 1350 TFTP Revision 2 July 1992
References
[1] USA Standard Code for Information Interchange, USASI X3.4-1968.
[2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information
Sciences Institute, 28 August 1980.
[3] Postel, J., "Telnet Protocol Specification," RFC 764,
USC/Information Sciences Institute, June, 1980.
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, USC/Information Sciences
Institute, October 1989.
Security Considerations
Since TFTP includes no login or access control mechanisms, care must
be taken in the rights granted to a TFTP server process so as not to
violate the security of the server hosts file system. TFTP is often
installed with controls such that only files that have public read
access are available via TFTP and writing files via TFTP is
disallowed.
Author's Address
Karen R. Sollins
Massachusetts Institute of Technology
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
Phone: (617) 253-6006
EMail: [email protected]
Sollins [Page 11]
_______________________________________________
http://cool.haxx.se/mailman/listinfo/curl-www-commits
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.