Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)                 9  TCP/IP General File Transfer Protocols (FTP and TFTP)                      9  Trivial File Transfer Protocol (TFTP)

TFTP Detailed Operation and Messaging 1 2 3 4 TFTP Message Formats

TFTP Option Negotiation Process

The client begins the negotiation by sending a modified TFTP Read Request or Write Request message. In addition to the normal information that appears in this message (see the next topic), a list of options may also be included. Each is specified with an Option Code and an Option Value. The names and values are expressed as ASCII strings, terminated by a null character (zero byte). Multiple options may be specified in the request message.

The server receives the request containing the options, and if it supports the option extension, processes them. It then returns a special Option Acknowledgment (OACK) message to the client, where it lists all the options that the client specified that the server recognizes and accepts. Any options that the client requested but the server rejects, it does not include in this option acknowledgment. The client may only use the options that the server accepts. If the client rejects the server's response, it may send back an error message (with error code 8) upon receipt of the unacceptable OACK message.

The server may specify an alternative value in its response for certain options, if it recognizes the option but doesn't like the client’s suggested value. Obviously, if the server doesn't support options at all, it will ignore the client's option requests, and respond back with a data message (for a read) or a regular acknowledgment (for a write) as in normal TFTP.

If the server did send an OACK, the client then proceeds to send messages using the regular messaging exchange described in the previous section. In the case of a write, the option acknowledgment replaces the regular acknowledgment in the message dialog. In the case of a read, the option acknowledgment is the server's first message instead of the first data block that it would normally send. TFTP doesn't allow the same device to send two datagrams in a row, so there needs to be a reply from the client before that first block can be sent. The client does this by sending a regular acknowledgment with a block number of 0 in it — the same form of acknowledgment a server normally sends for a write.

Phew, that's confusing. For review, let's take a look at each of the four possible cases (read and write, with and without options).

TFTP Detailed Operation and Messaging 1 2 3 4 TFTP Message Formats