TFTP Option Extension
RFC 2347

Document Type RFC - Draft Standard (May 1998; Errata)
Obsoletes RFC 1782
Updates RFC 1350
Authors Gary Malkin  , Art Harkin 
Last updated 2020-01-21
Stream Legacy
Formats plain text html pdf htmlized with errata bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2347 (Draft Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          G. Malkin
Request for Commments: 2347                                 Bay Networks
Updates: 1350                                                  A. Harkin
Obsoletes: 1782                                      Hewlett Packard Co.
Category: Standards Track                                       May 1998

                         TFTP Option Extension

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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


   The Trivial File Transfer Protocol [1] is a simple, lock-step, file
   transfer protocol which allows a client to get or put a file onto a
   remote host.  This document describes a simple extension to TFTP to
   allow option negotiation prior to the file transfer.


   The option negotiation mechanism proposed in this document is a
   backward-compatible extension to the TFTP protocol.  It allows file
   transfer options to be negotiated prior to the transfer using a
   mechanism which is consistent with TFTP's Request Packet format.  The
   mechanism is kept simple by enforcing a request-respond-acknowledge
   sequence, similar to the lock-step approach taken by TFTP itself.

   While the option negotiation mechanism is general purpose, in that
   many types of options may be negotiated, it was created to support
   the Blocksize option defined in [2].  Additional options are defined
   in [3].

Packet Formats

   TFTP options are appended to the Read Request and Write Request
   packets.  A new type of TFTP packet, the Option Acknowledgment
   (OACK), is used to acknowledge a client's option negotiation request.
   A new error code, 8, is hereby defined to indicate that a transfer

Malkin & Harkin             Standards Track                     [Page 1]
RFC 2347                 TFTP Option Extension                  May 1998

   should be terminated due to option negotiation.

   Options are appended to a TFTP Read Request or Write Request packet
   as follows:

      |  opc  |filename| 0 |  mode  | 0 |  opt1  | 0 | value1 | 0 | <

      <  optN  | 0 | valueN | 0 |

         The opcode field contains either a 1, for Read Requests, or 2,
         for Write Requests, as defined in [1].

         The name of the file to be read or written, as defined in [1].
         This is a NULL-terminated field.

         The mode of the file transfer: "netascii", "octet", or "mail",
         as defined in [1].  This is a NULL-terminated field.

         The first option, in case-insensitive ASCII (e.g., blksize).
         This is a NULL-terminated field.

         The value associated with the first option, in case-
         insensitive ASCII.  This is a NULL-terminated field.

      optN, valueN
         The final option/value pair.  Each NULL-terminated field is
         specified in case-insensitive ASCII.

   The options and values are all NULL-terminated, in keeping with the
   original request format.  If multiple options are to be negotiated,
   they are appended to each other.  The order in which options are
   specified is not significant.  The maximum size of a request packet
   is 512 octets.

   The OACK packet has the following format:

Malkin & Harkin             Standards Track                     [Page 2]
RFC 2347                 TFTP Option Extension                  May 1998

      |  opc  |  opt1  | 0 | value1 | 0 |  optN  | 0 | valueN | 0 |

         The opcode field contains a 6, for Option Acknowledgment.

         The first option acknowledgment, copied from the original

         The acknowledged value associated with the first option.  If
         and how this value may differ from the original request is
         detailed in the specification for the option.

      optN, valueN
         The final option/value acknowledgment pair.

Negotiation Protocol

   The client appends options at the end of the Read Request or Write
   request packet, as shown above.  Any number of options may be
   specified; however, an option may only be specified once.  The order
   of the options is not significant.

   If the server supports option negotiation, and it recognizes one or
Show full document text