Internet DRAFT - draft-lear-lear-tftp-url
draft-lear-lear-tftp-url
Network Working Group Eliot Lear
INTERNET-DRAFT Cisco Systems
Category: Experimental
<draft-lear-lear-tftp-url-00.txt>
December 7, 2001
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.
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
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
TFTP [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 does not recommend its continued use, largely due to
security concerns, we do define a URI Scheme, as well as provide a
protocol applicability statement.
1. Introduction
The TFTP protocol has been around for quite some time. Its common
use is to initially configure devices or to load new versions of
operatiing 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 June 7, 2002 [Page 1]
WHILE WE DEFINE THE TFTP URI TYPE, WE STRONGLY RECOMMEND AGAINST
THE CONTINUED USE OF TFTP, FOR REASONS LISTED IN SECTION 5. The
definition of a URI merely allows tools that currently use
protocols such as TFTP to have a standard name space and structure
where when can understand the process used to resolve that name.
It is indeed hoped that the definition of this URI will ease
transition to preferable configuration mechanisms.
2. Syntax of a TFTP URI
A TFTP URI has the following syntax:
tftpURI = "tftp://" #domain "/"
( filewmode | addrwmode )
filewmode = file [ mode ]
addrwmode = #addr-spec "?mode=mail"
mode = "?mode=" ( "netascii" | "octet" )
host = #domain
file = *(#unreserved | #escaped)
Note that both #domain and #addr-spec are shamelessly lifted from
the ABNF found in [RFC2822]. #unreserved and #escaped are defined
in [MAILTO].
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 transfered. If left unspecified, the mode is assumed to
be "octet". According to the TFTP standard it is in fact possible
to send EMail when issuing a TFTP write command, and the above
syntax supports this. However, it is unlikely that most TFTP
servers support the functionality, and we recommend that the
"mailto:" URL be used instead, along with either message submission
protocol or SMTP.[SUBMIT,SMTP]
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.
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 or to a
specified mail address. 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
Lear Expires June 7, 2002 [Page 2]
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.[FTP,HTTP]
4. Examples
tftp://example.com/myconfigurationfile?mode=netascii
This example references file "myconfigurationfile" on server
"example.com" and requests nthat 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 & 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 the case for even the simplest piece of network support
hardware, such as simple routers or switches.
TFTP has no mechanisms for access control within the protocol.
Implementations are left to their own devices in this area.
Because TFTP has no way to determine in advance file sizes,
implementations should be prepared to properly check the bounds of
transfers so that neither memory nor disk limitations are not
exceeded.
TFTP is not well suited for 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. Because TFTP relies on UDP, there is no slow start
or smart backoff mechanism, but very simple timeouts.
TFTP is not well suited for file transfers across administrative
domains. For one thing, TFTP utilizes UDP, and many NATs may not
either support or allow TFTP transfers. More likely firewalls may
prohibit transfers.
There are no caching semantics within TFTP. There is no safe way
to cache information using the TFTP protocol.
As previously stated, use of TFTP to transmit EMail messages is
Lear Expires June 7, 2002 [Page 3]
problematic, if for no other reason, that most servers are unlikely
to allow or support it. If they do, there is no mechanism for
authentication of the sender in TFTP, nor is there any way to
verify that the message has been received unmolested.
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 shall register the URI scheme name "tftp" with a
description of "The TFTP Protocol" and a reference to this document.
7. References
[TFTP] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 1350,
July, 1992.
[RFC2822] Resnick, P., ed., "Internet Message Format", RFC 2822,
April, 2001.
[FTP] Postel., J., Reynolds, J.K., "File Transfer Protocol", RFC
959, October, 1985.
[HTTP] Fielding, R., et. al, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June, 1999.
[MAILTO] Hoffman, P., Masinter, L., Zawinski, J., "The mailto URL
scheme", RFC 2368, July, 1998.
[SUBMIT] Gellens, R., Klensin, J., "Message Submission", RFC 2476,
December, 1998.
[SMTP] Klensin, J., ed., "Simple Mail Transfer Protocol", RFC
2821, April, 2001.
8. Author's Address:
Eliot Lear
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134-1706
Email: lear@cisco.com
Phone: +1 (408) 527 4020
9. 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
Lear Expires June 7, 2002 [Page 4]
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.
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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
PARTICULAR PURPOSE."
11. Expiration Date
This memo is filed as <draft-lear-tftp-uri-00.txt>, and expires
June 7, 2002.
Lear Expires June 7, 2002 [Page 5]
