Just as TCP has a datagram, so does UDP,
although it's not as complicated due to the lightweight design of this datagram.
Let's take a closer look at the UDP datagram.
As we can already see, our UDP datagram is way smaller than its TCP brother.
Actually, a UDP datagram is only 8 bytes by default.
And luckily for us, the UDP datagram has quite a bit of overlap with TCP.
Let's review the overlapping sections first within our UDP datagram.
The first portion of the UDP header is the source port.
And just as with TCP, the source port shows the source of the data request,
which can also be used for connection tracking.
The second portion of our UDP header is the 16‑bit destination port.
And as with TCP, the destination port is where the traffic is headed to.
The next section in our UDP header is the checksum.
And just like TCP,
the checksum is used to calculate a mathematical value to determine
if the received data matches what is expected.
This is also known as a hash.
Our final common UDP datagram element is the data section,
and the data section is just as it sounds.
It's our data that resides within the session.
Now this leaves us with one open box before we can declare our bingo.
The final box is the length section.
Let's take a closer look at our final section, the length section.
The length section has a default value of 16 bit.
The length section is determined by adding the headers
total combined value plus the data.
For example, if we had a header with 64 bits of data and a data payload of 10,
out total length field would equal 74.
And with that, we've successfully completed our overview of the UDP datagram.
Now let's take our newfound UDP knowledge and explore an
actual UDP session through Wireshark.
For this decomposition, we'll be dissecting a UDP/DHCP datagram.
Starting with session 17, which is our first session in the DHCP request,
we can see that the computer is using a source port of
68 and a destination port of 67.
Now, this may seem odd, and it kind of is.
Normally with a source port,
you'll see a high random port and then a well‑known destination port.
But DHCP operates differently.
It uses well‑defined ports for DHCP.
Now if we were to examine DNS traffic, which is also UDP,
you'd see the expected high port result.
So just remember that DHCP is a little bit different.
Next, we can see the checksum of 0xfb60 and a length of 308.
And for our data section, well,
there isn't any. Remember earlier when we stated
that DCP is a best effort protocol?
Well, here we can really see what is happening.
Notice how there isn't an ACK until 230. In session 230, this
is where the DHCP lease has been handed out,
but the requesting computer could have grabbed another lease from a
different server. If that would've happened, the server of
192.168.1.254 would have sent its offer and said,
hey, I have the address of 192.168.1.100 available for you,
at which point no response would have been given. So essentially, the requested computer can ghost the server.