Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)
|The information below is for an old version of the document that is already published as an RFC
RFC Internet-Draft (app)
(latest revision 2003-06-09)
No shepherd assigned
RFC 3617 (Informational)
||Send notices to
Network Working Group Eliot Lear
INTERNET-DRAFT Cisco Systems
May 23, 2003
URI Scheme for the TFTP Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
The list of current Internet-Drafts can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at
Copyright (C) The Internet Society (2003). All Rights Reserved.
TFTP is a very simple TRIVIAL file transfer protocol that has been
in use on the Internet for quite a long time. While this document
discourages it continued use, largely due to security concerns, we
do define a URI scheme, as well as discuss the protocol's
TFTP (trival file transfer protocol) has been around for quite some
time. Its common uses are to initially configure devices or to
load new versions of operating system code. As devices begin to
adopt use of URIs and 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.
Lear Expires November 23, 2003 [Page 1]
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 universal resource identifier (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
2. Syntax of a TFTP URI
A TFTP URI has the following ABNF syntax:
tftpURI = "tftp://" host "/" file [ mode ]
mode = ";" "mode=" ( "netascii" / "octet" )
file = *( unreserved / escaped )
host = // as specified by RFC 2732
unreserved = // as specified in RFC 2396
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 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.
3.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 existance
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 Expires November 23, 2003 [Page 2]
This example references file "myconfigurationfile" on server
"example.com" and requests that the transfer occur in netascii
This file references file "mystartupfile" on server "example.com".
The transfer should occur in octet mode, since no other mode was
5. Security Considerations & 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 than TFTP, only a
few of which are listed below.
TFTP has no mechanisms 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
There are no caching semantics within TFTP. There is no safe way
to cache information using the TFTP protocol.
In summary, use of TFTP is strongly discouraged except in the most
limited of circumstances where memory and CPU are at the highest
Lear Expires November 23, 2003 [Page 3]
6. IANA Considerations
The IANA is asked to register the URL registration template found in
Appendix A in accordance with RFC 2717.
 Sollins, K., "The TFTP Protocol (Revision 2)", RFC 1350,
 Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
 Hinden, B., Carpenter, B., Masinter, L., "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December, 1999.
 Berners-Lee, T., Fielding R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
 Fielding, R., et. al, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
 Postel, J., Reynolds, J.K., "File Transfer Protocol", RFC
959, October 1985.
 Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999.
8. Author's Address:
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134-1706
Phone: +1 (408) 527 4020
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: 
Interoperability considerations: None
Security considerations: Section 5
Relevant publications: 
Contact: The author, Section 8
Author/Change Controller: IESG
Lear Expires November 23, 2003 [Page 4]
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
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 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
Lear Expires November 23, 2003 [Page 5]
This memo is filed as <draft-lear-tftp-uri-05.txt>, and expires
November 23, 2003.
Lear Expires November 23, 2003 [Page 6]