SubnetLayerProtocols

The Eight-Byte Header

Four fields, and one of them reaches down a layer

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
IP already gets a packet to the right machine. UDP's entire job is to get it to the right PROGRAM on that machine, and to let the receiver notice if the bytes were corrupted on the way. That is two jobs, and they need four numbers: which program sent it, which program should get it, how long it is, and a fingerprint of the contents. Eight bytes, and the protocol is finished. Everything else you might want — knowing it arrived, getting it in order, not overwhelming the receiver — is absent because adding it would mean becoming TCP, and TCP already exists.
Source port
Where a reply should go. A client's is usually ephemeral — picked by the operating system and alive only for this exchange.
Destination port
Which program should receive this. 53 for DNS, 67 and 68 for DHCP, 9 for the discard service these labs send to.
Length
Header plus payload, in bytes. The minimum is 8 — a datagram with no payload at all is legal.
Checksum
A fingerprint over a pseudo-header, the UDP header and the payload. Optional in IPv4, mandatory in IPv6.

✗ Common misunderstanding: UDP must have a sequence number somewhere, or the receiver could not tell datagrams apart.

Why that's wrong: There is no such field. The header is exactly eight bytes and all four of its values are accounted for above.

Correct model: Applications that need to tell datagrams apart put an identifier in the PAYLOAD. DNS does exactly that with its transaction id, which exists precisely because UDP offers nothing.

The packets prove it: Open any UDP packet in this lab and expand the UDP layer. Four fields, eight bytes, and no sequence number anywhere in them.

Watch these fields in the lab: udp.sourcePort · udp.destPort · udp.length · udp.checksum

The checksum covers more than the UDP datagram. Before computing it the sender prepends a pseudo-header — the source and destination IP addresses, the protocol number and the UDP length — computes the fingerprint over all of it, and then throws the pseudo-header away. It is never transmitted. The reason is worth the oddity. Without it, a datagram delivered to the wrong machine entirely would still checksum correctly, because nothing in the UDP header records who it was for.

What the sender actually checksums, for the datagram in this lab:

Pseudo-header  (computed over, never sent)
  source IP          10.0.1.10
  destination IP     10.0.2.30
  zero               0
  protocol           17          (UDP)
  UDP length         22

UDP header  (sent)
  source port        40001
  destination port   9
  length             22
  checksum           0 while computing, then filled in

Payload  (sent)
  14 bytes of application data

Twelve bytes of context that never travel, protecting eight bytes that do. Had either address changed in flight the sum would not match, and the receiver would discard the datagram silently — no error, no notification.

Watch these fields in the lab: udp.checksum · udp.length

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

The UDP length field says 8. What does that mean?

Why does the UDP checksum include the IP addresses, which are not part of UDP?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.