Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)
RFC 3617

Document Type RFC - Informational (October 2003; No errata)
Last updated 2015-10-14
Stream ISE
Formats plain text pdf html bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3617 (Informational)
Telechat date
Responsible AD Ted Hardie
Send notices to (None)
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
Show full document text