TFTP Option Extension
Extracted elements (15)
The option negotiation mechanism is backward-compatible: options are appended to existing RRQ/WRQ packet formats so legacy servers silently ignore them and fall back to standard TFTP behavior. The request-respond-acknowledge sequence mirrors TFTP's own lock-step design to keep the mechanism simple.
If a server does not support option negotiation, it will likely ignore appended options and return a DATA packet (for RRQ) or ACK packet (for WRQ), establishing normal TFTP data transfer without options. A client may retry a failed request without options to handle servers that treat extra data in the request as an error.
An option may only be specified once in a request. The order of options is not significant.
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 and must not use those which were not acknowledged.
If the client rejects the server's OACK, it must send an ERROR packet with error code 8 to terminate the transfer. Similarly, if the client receives an OACK containing an unrequested option, it should respond with ERROR code 8 and terminate.
If the transfer was initiated with a Read Request and the client accepts the OACK, the client sends an ACK with data block number set to 0 to confirm the negotiated values. If initiated with a Write Request, the client begins the transfer with the first DATA packet using the negotiated values.
Once a client acknowledges an OACK with an appropriate non-error response, that client has agreed to use only the options and values returned by the server; the server cannot request an option, it can only respond to them.
Options which the server does not support should be omitted from the OACK; they should not cause an ERROR packet to be generated. If the value of a supported option is invalid, the option specification determines whether the server omits it, proposes an alternate value, or sends ERROR code 8.
The server must not include in the OACK any option which was not specifically requested by the client; only the client may initiate option negotiation.
A new packet type, Option Acknowledgment (OACK), opcode 6, is defined. The OACK contains the options and values the server accepts, copied from the original request: |6|opt1|0|value1|0|...|optN|0|valueN|0|. Acknowledged values may differ from requested values if the option specification permits.
Error code 8 is newly defined to indicate that a transfer should be terminated due to option negotiation failure. It is used by either the client or server to reject an OACK or an invalid option value.
TFTP option negotiation is initiated by appending option/value pairs to Read Request (opcode 1) or Write Request (opcode 2) packets. Options are NULL-terminated, case-insensitive ASCII strings; the order is not significant. The maximum size of a request packet is 512 octets.
The basic TFTP protocol has no security mechanism, which is why it has no rename, delete, or file overwrite capabilities. This option extension document does not add any security to TFTP, nor does it introduce additional security risks beyond those already present in TFTP.
For a Read Request with options, three server responses are possible: OACK (options accepted), DATA (options ignored, normal transfer begins), or ERROR (request denied). For a Write Request with options, the three responses are: OACK (options accepted), ACK (options ignored, normal transfer begins), or ERROR.
Options are encoded after the mode field in RRQ/WRQ packets as a sequence of NULL-terminated opt/value pairs: |opc|filename|0|mode|0|opt1|0|value1|0|...|optN|0|valueN|0|. Each field is case-insensitive ASCII and NULL-terminated.