RFC 3617

RFC 3617: TFTP URI Scheme and Applicability Statement 🎀

Network Working Group, Request for Comments 3617, filed under the category Informational (no standard, just info for the Internet community 🧚). The author is Eliot Lear of Cisco Systems, and it's dated October 2003. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched by this one ✨.

The full title is Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) 💖

Status of this Memo 📝

This memo gives info to the Internet community. It is not an Internet standard of any kind. Distribution is unlimited 🌸

Copyright Notice ©️

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🦋

TFTP is a super simple, very basic protocol that has been floating around the Internet for ages 🥹. This doc says you should basically stop using it, mostly because of security concerns 💀. BUT we still define a URI scheme for it and talk about where the protocol still makes sense.

1. Introduction ✨

TFTP has been around forever 🕰️. People mostly use it to set up devices at first or to load new operating system code [1]. Devices are starting to use URIs and URLs now, so for completeness we're writing down a way to point at files with TFTP, since that's still super common 💅. A URI is a neat way to show the underlying mechanism, the server name or address, and the file name all in one place 🎀.

WHILE WE DEFINE THE TFTP URI TYPE, WE STRONGLY RECOMMEND AGAINST THE CONTINUED USE OF TFTP, for the reasons in Section 5 (among others) 🙈. Defining the URI just lets tools that already use protocols like TFTP have a standard naming system where you can tell how a name gets resolved. Honestly the hope is that this URI makes it easier to move over to modern file transfer methods 🚀.

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 points to a file that's either going to be found on a TFTP server or placed on one 📂. The mode part says how the file gets transferred. If you leave it out, the mode is assumed to be octet 🫶. There used to be a third "mail" mode, but it was deprecated when RFC 1350 came out, so it's not specified here 💀.

2.1. Encoding Rules 🔐

Apart from the syntax above, TFTP doesn't set any length limits on file names or file sizes ✨. File names can hold any character at all, as long as those characters are escaped the way described above 🌈.

3. Semantics and Operations 🎬

Like we said, a TFTP URI is a reference to a file 🗂️. The only operations allowed on it are read and write. Reading a TFTP URI means the underlying mechanisms grab the named file over TFTP from the given host, using the mode if one was specified. Writing a TFTP URI means the underlying mechanisms send a file over TFTP to a given server, to the specified file, using the mode if one was given. Nothing else is supported 🙅‍♀️.

Here's the tea ☕: you can't get the file size before you grab it, and you can't tell if the file exists or what its permissions are before transfer either 😭. Files might arrive intact or they might not, because there's no guarantee of reliability or even completeness. Check the TFTP standard for the details 📖. If you want something more robust, go with FTP or HTTP [5, 6] 💜.

4. Examples 🍓

tftp://example.com/myconfigurationfile;mode=netascii

This one points at the file "myconfigurationfile" on the server "example.com" and asks for the transfer to happen in netascii mode 🌸.

tftp://example.com/mystartupfile

This one points at the file "mystartupfile" on the server "example.com". The transfer should happen in octet mode, since no other mode was specified 💫.

5. Security Considerations and Concerns about TFTP's use 🚨

TFTP has historically been limited to devices where a fuller protocol stack is impractical because of memory or CPU limits 🧠. A toaster might still be in that category, but it's pretty unlikely for even the simplest network hardware, like basic routers or switches 🍞. There are a myriad of reasons to pick a protocol other than TFTP, and we list a few of them below 🌟.

TFTP has no access control mechanism inside the protocol, and there's no protection against a man in the middle attack 😱. Implementations are left to fend for themselves on this one. Since TFTP has no way to know file sizes in advance, implementations should be ready to properly check the bounds of transfers, so neither memory nor disk limits get blown past 💥.

TFTP isn't a great fit for large files, and here's why 🐘. It has no built-in integrity check, so there's no way to tell whether what one side sent is what the other side got 🙃. You can only restart a TFTP transfer from the very beginning. TFTP is a lock step protocol, which means only one packet can be in flight at any moment. There's no slow start or smart backoff in TFTP either, just very simple timeouts ⏱️.

TFTP also isn't well suited to transfers across administrative domains 🏢. For one thing, TFTP uses UDP, and lots of NATs won't support or allow TFTP transfers at all 🚧. Even more likely, firewalls will block the transfers 🔥.

There are no caching semantics in TFTP. There's no safe way to cache information using the TFTP protocol 🙅‍♀️.

To sum up: TFTP use is strongly discouraged, except in the most limited situations where memory and CPU are at a massive premium 🫠.

6. IANA Considerations 📋

IANA has registered the URL registration template found in Appendix A, following RFC 2717 [7] 🎉.

7. Acknowledgments 🫶

The author thanks Larry Masinter, Randy Presuhn, Phil Schafer, and Bill Fenner for helping develop this doc 💜.

8. Intellectual Property Statement ⚖️

The IETF doesn't take a position on whether any intellectual property or other rights that might be claimed to cover the technology in this document are valid or in scope, or on whether any license under those rights might be available. It also doesn't claim it has tried to find any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documents 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 results of an attempt to get a general license or permission for implementors or users to use those proprietary rights, 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 that might cover technology needed to practice this standard. Please send that info to the IETF Executive Director 💌.

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

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: lear@cisco.com

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 💖