Visual RFC.
ALL RFCs / RFC 2348
Read the RFC ↗
RFC 2348 / TFTP BLOCK NEGOTIATION

Confirm reads and writes differently

03

Read acceptance sends ACK block 0 before the server’s first DATA. Write acceptance instead starts with client DATA block 1. These are separate transfers, not one combined sequence.

RFC 2348 · RFC 2347 · Negotiation Protocol · p.4EXAMPLE
6 / 6
Confirm reads and writes differentlyTFTP Blocksize Option. Client sends DATA1 using the negotiated size; server returns ACK1. No additional client ACK0 is sent in this write acceptance path.Read: ACK0 · Write: DATA1ClientServerSeparate WRITE exampleWRQ · blksize1024OACK · blksize1024DATA1 · up to1024ACK1Client DATA1 confirms the write’s OACKNo extra client ACK0 in this acceptance pathRFC2348 · chapter 3 · state 6 · selected example
06
Write case: DATA block one confirms OACK

Client sends DATA1 using the negotiated size; server returns ACK1. No additional client ACK0 is sent in this write acceptance path.

Source for this drawing: RFC 2348 · Read RFC source: RFC 2347 · Negotiation Protocol · p.4 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

For a Read Request, client ACK0 confirms the OACK values before server DATA1. An ACK is an acknowledgment; zero here confirms options, not a received data block zero.

  • For a Read Request, client ACK0 confirms the OACK values before server DATA1. An ACK is an acknowledgment; zero here confirms options, not a received data block zero.
  • For a Write Request, client DATA1 using the negotiated value confirms OACK. Do not insert an extra client ACK0 into that write sequence; server ACK1 follows the data.
  • The write example is labeled WRQ, as corrected by verified RFC 2347 erratum 1258. Ordinary TFTP remains lock-step here; no window-size extension, retransmission timer, transport-port selection or full state machine is implemented.
  • A server that ignores options can instead send DATA1 for a read or ACK0 for a write under the base rules. An OACK refusal uses ERROR8. The illustrated successful OACK exchanges are not authentication or encryption.
DETAILS

A selected octet-mode example, not a complete TFTP implementation. One octet is an eight-bit byte. Follow the actual RFC source and its companion option-negotiation rules.

Read the RFC section ↗

All chapters in RFC 2348

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗