Skip to main content

RFC 768: User Datagram Protocol

Overview
The User Datagram Protocol (UDP) defines a simple, connectionless transport layer service that runs on top of the Internet Protocol (IP). UDP provides a lightweight, minimal-overhead mechanism to send independent datagrams between applications without establishing or maintaining end-to-end state. It is designed for situations where low latency, low processing cost, or simple query/response semantics are more important than guaranteed delivery, ordering, or congestion control.

Service Model
UDP offers a best-effort, datagram-oriented service: each UDP message is an independent unit that is either delivered intact or lost; there are no retransmissions, acknowledgments, or built-in sequencing. Multiplexing and demultiplexing are performed by 16-bit port numbers carried in the UDP header, enabling multiple applications on a host to share a single IP address. Applications are responsible for reliability, flow control, and ordering when those properties are required.

Packet Format
The UDP header is deliberately small and fixed in size: eight bytes containing four 16-bit fields. These fields are source port, destination port, length, and checksum. The length field covers header plus data, allowing the receiver to determine the size of the UDP datagram. The payload follows immediately after the header and is treated as opaque data by UDP; the protocol imposes no structure beyond the header fields.

Checksum and Integrity
A checksum field provides optional integrity checking for the header and data, and includes a pseudo-header derived from the IP layer (source and destination IP addresses, protocol, and UDP length) so that misdelivered or misrouted datagrams are likely to be detected. In the original specification for the IPv4 environment, a checksum value of zero can be used to indicate that no checksum is present, making the checksum optional for performance-sensitive uses. The RFC specifies that receivers should discard datagrams that fail validation checks such as header length or checksum mismatches.

Interaction with IP and Fragmentation
UDP relies on IP for addressing, routing, and fragmentation. When a UDP datagram exceeds the network's maximum transmission unit, IP fragmentation and reassembly handle splitting and reconstituting the packet; UDP itself places no additional constraints on fragmentation. Because UDP is stateless, it receives whatever fragment reassembly IP provides and then processes the reassembled datagram or drops it if reassembly fails.

Error Handling and Robustness
UDP intentionally avoids complex error recovery mechanisms. If delivery fails, no automatic retransmission occurs. The protocol recommends that applications implement their own error detection, retransmission policies, or application-level acknowledgments when needed. Certain ICMP messages from the network may be delivered to the sender to indicate unreachable destinations or other network errors, but these are external to UDP's core behavior and optional for applications to interpret.

Use Cases and Design Rationale
UDP's simplicity makes it well suited for time-sensitive or lightweight transactions such as DNS queries, streaming media, real-time interactive applications, and simple request/response protocols. The modest header size reduces processing and bandwidth overhead, and the lack of connection state simplifies server design and scalability. The specification emphasizes that UDP is a tool for application designers: when guaranteed delivery or ordering is essential, higher-level protocols or application logic must add those features atop UDP or use alternative transport services.
RFC 768: User Datagram Protocol

This work outlines the User Datagram Protocol (UDP), a connectionless data transfer protocol that sits atop the Internet Protocol (IP) and is commonly used in client-server communication and in situations where low-latency is a priority.


Author: Jon Postel

Jon Postel, a key figure in Internet history, known for his role in developing TCP/IP and managing DNS.
More about Jon Postel