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.

Abstract

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.

Introduction

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 TFTPs 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].

This document assumes reader familiarity with the TFTP specification [1] and its terminology.

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 should be terminated due to option negotiation.

---

Page 2

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 "0"s shown in these illustrations and the ones below are all all zero octets, i.e., NULL terminators for the preceeding fields.

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

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

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

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

value1
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.

---

Page 3

The OACK packet has the following format:

      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
      |  opc  |  opt1  | 0 | value1 | 0 |  optN  | 0 | valueN | 0 |
      +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+

opc
The opcode field contains a 6, for Option Acknowledgment.

opt1
The first option acknowledgment, copied from the original request.

value1
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 more of the options specified in the request packet, the server may respond with an Options Acknowledgment (OACK). Each option the server recognizes, and accepts the value for, is included in the OACK. Some options may allow alternate values to be proposed, but this is an option specific feature. The server must not include in the OACK any option which had not been specifically requested by the client; that is, only the client may initiate option negotiation. Options which the server does not support should be omitted from the OACK; they must not cause an ERROR packet to be generated. If the value of a supported option is invalid, the specification for that option will indicate whether the server should simply omit the option from the OACK, respond with an alternate value, or send an ERROR packet, with error code 8, to terminate the transfer.

An option not acknowledged by the server must be ignored by the client and server as if it were never requested. If multiple options were requested, the client must use those options which were acknowledged by the server and must not use those options which were not acknowledged by the server.

---

Page 4

When the client appends options to the end of a Read Request packet, three possible responses may be returned by the server:

OACK - acknowledge of Read Request and the options;

DATA - acknowledge of Read Request, but not the options;

ERROR - the request has been denied.

When the client appends o>

---

Transfer interrupted!