RFC 768

RFC 768: User Datagram Protocol ✨

okay bestie, let's get into it 💖 This is the spec for UDP, and it was written by J. Postel of ISI back on 28 August 1980 🎀. It's a standards-track-era document that stands on its own, so it doesn't obsolete or update anything else 🌸. Honestly, that's iconic for a protocol that's still everywhere 👑.

---

Introduction

Okay so UDP is defined to give you a datagram mode of packet-switched computer communication across a bunch of interconnected networks 🦋. It assumes IP [1] sits underneath it as the underlying protocol 🧚.

It gives applications a way to send messages to other programs with a minimum of protocol mechanism ✨. It's transaction oriented, and it does not guarantee delivery or duplicate protection 💀. No cap, that's the whole vibe 🫶. If you need ordered, reliable delivery of streams of data, you should use TCP [2] instead 💅.

Format

Here's what the header looks like 🍓:

                  0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |     Source      |   Destination   |
                 |      Port       |      Port       |
                 +--------+--------+--------+--------+
                 |                 |                 |
                 |     Length      |    Checksum     |
                 +--------+--------+--------+--------+
                 |
                 |          data octets ...
                 +---------------- ...

                      User Datagram Header Format

Fields

Source Port is optional 🙈. When it's meaningful, it tells you the port of the sending process, and you can assume it's where a reply should go if you don't have any other info. If it's not used, you just stick a value of zero in there 🌈.

Destination Port only makes sense within the context of a particular internet destination address 🎀.

Length is the total number of octets in this user datagram, counting both the header and the data 📏. (So the minimum length is eight, since that's just the header 😭.)

Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header made from the IP header, the UDP header, and the data. The data gets padded with zero octets at the end (if needed) so it's a multiple of two octets 🔥.

The pseudo header is conceptually stuck in front of the UDP header, and it holds the source address, the destination address, the protocol, and the UDP length 🧁. It's there to protect you against misrouted datagrams 🛡️. This checksum procedure is the same one TCP uses 💜.

                  0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |          source address           |
                 +--------+--------+--------+--------+
                 |        destination address        |
                 +--------+--------+--------+--------+
                 |  zero  |protocol|   UDP length    |
                 +--------+--------+--------+--------+

If the computed checksum comes out to zero, it gets transmitted as all ones (which is the equivalent in one's complement arithmetic) ✨. An all-zero transmitted checksum value means the transmitter didn't generate a checksum at all 🙈. That's a thing you do for debugging, or for higher-level protocols that don't care 🧚.

User Interface

A user interface should allow 💅

• the creation of new receive ports,
• receive operations on the receive ports that return the data octets and an indication of source port and source address,
• and an operation that allows a datagram to be sent, specifying the data, source and destination ports and addresses to be sent.

IP Interface

The UDP module must be able to figure out the source and destination internet addresses and the protocol field from the internet header 🔍. One possible UDP/IP interface would return the whole internet datagram, including all of the internet header, in response to a receive operation 📦. That same interface would let UDP pass a full internet datagram, header and all, down to IP to send 🚀. IP would check certain fields for consistency and compute the internet header checksum 🧮.

Protocol Application

The major uses of this protocol are the Internet Name Server [3] and the Trivial File Transfer [4] 🎀.

Protocol Number

This is protocol 17 (that's 21 in octal) when it's used in the Internet Protocol 🔢. Other protocol numbers are listed in [5] 📚.

References

[1] Postel, J., "Internet Protocol," RFC 760, USC/Information Sciences Institute, January 1980.

[2] Postel, J., "Transmission Control Protocol," RFC 761, USC/Information Sciences Institute, January 1980.

[3] Postel, J., "Internet Name Server," USC/Information Sciences Institute, IEN 116, August 1979.

[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of Technology, IEN 133, January 1980.

[5] Postel, J., "Assigned Numbers," USC/Information Sciences Institute, RFC 762, January 1980.

---

that's the whole thing bestie 🌈💖 UDP really is the chill, no-drama transport that just sends and goes 🦋✨