TFTP Option Extension
Extracted elements (17)
The option negotiation mechanism is a backward-compatible extension to TFTP. It uses a request-respond-acknowledge sequence consistent with TFTP's existing Request Packet format, keeping the mechanism simple and aligned with TFTP's lock-step approach.
If a legacy server returns an ERROR for a request carrying options (treating extraneous data as erroneous), the client may retry the request without any options appended.
If a server does not support option negotiation, it will ignore appended options and return a DATA packet for RRQ or an ACK packet for WRQ, establishing normal TFTP data transfer without options. Clients should handle this as a valid server response.
An option may only be specified once in a request packet. The order of options is not significant.
An option not acknowledged by the server must be ignored by both client and server as if it were never requested. If multiple options were requested, the client must use only those acknowledged and must not use those not acknowledged.
If the client receives an OACK containing an option it never requested, it should respond with ERROR code 8 and terminate the transfer.
If the transfer was initiated with a Read Request, the client sends ACK with data block number 0 to confirm the values in the server's OACK. If the client rejects the OACK, it sends ERROR code 8 to terminate the transfer.
Once a client acknowledges an OACK with a non-error response, that client has agreed to use only the options and values returned by the server.
Options that the server does not support should be omitted from the OACK; they must not cause an ERROR packet to be generated. If an option's value is invalid, the option specification determines whether to omit it, propose an alternate value, or send 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 TFTP error code 8 is defined to indicate that a transfer should be terminated due to option negotiation failure. Either side may send ERROR code 8 to abort a transfer during option negotiation.
A new TFTP packet type, Option Acknowledgment (OACK), is defined with opcode 6. It is sent by the server to acknowledge one or more options from the client's RRQ or WRQ, and only includes options the server both recognizes and accepts.
Security issues are not discussed in this memo. No authentication, integrity, or confidentiality mechanisms are defined for the option negotiation extension.
For a Read Request with options, the server may respond with: OACK (acknowledges RRQ and options), DATA (acknowledges RRQ but not options, initiating normal transfer), or ERROR (request denied). The client then ACKs the OACK with block number 0 to confirm option acceptance.
For a Write Request with options, the server may respond with: OACK (acknowledges WRQ and options), ACK (acknowledges WRQ but not options, initiating normal transfer), or ERROR (request denied). The client confirms OACK acceptance by sending the first DATA packet using negotiated values.
Options are appended to RRQ or WRQ packets as null-terminated, case-insensitive ASCII option/value pairs following the mode field. The format is: opcode | filename NUL | mode NUL | opt1 NUL | value1 NUL | ... | optN NUL | valueN NUL. Maximum request packet size is 512 octets.
The OACK (Option Acknowledgment) packet has opcode 6, followed by null-terminated option/value pairs echoing acknowledged options: opc(6) | opt1 NUL | value1 NUL | ... | optN NUL | valueN NUL. Acknowledged values may differ from requested values as permitted by individual option specifications.