Encapsulated with sufficient context

This aspect of our definition is actually the real meat of it, and is the real reason we're messing about with Wireshark in the first place. What exactly does it mean to encapsulate a packet with sufficient context? Let's start with the context that a datagram must have. This refers to the information that any device in between the source and destination hosts will need to route the packet accordingly, as well as any information necessary for the destination host to properly read and process the packet once received. For obvious reasons, this information is contained at the very front of a packet (which is to say, it composes the first bits that will be read by a receiving device), and is what constitutes the header of a packet. The context is the information necessary to either forward or process a packet correctly.

So what, then, constitutes sufficient context? Well, that actually depends on the specific protocol under which the packet was constructed. Different protocols have different requirements and expectations, and thus, different requirements to be serviced properly. What constitutes sufficient context for one might be grossly insufficient for another.

The two most commonly used transport layer protocols are TCP and User Datagram Protocol (UDP), and each of them have different service contracts for the application software that leverages them. This means that both of them have very distinct header specifications. TCP seeks to provide sequential, reliable, error-checked transmission service for packets traveling between hosts. Meanwhile, UDP, as a connection-less protocol (we'll discuss specifically what that means later in this book), doesn't explicitly aim to provide the reliability of transmission or a guarantee of the ordering of data. Instead, it seeks to provide light weight communication with a minimal protocol definition to enforce. As such, the sufficient context for UDP is actually substantially less than for that of a TCP packet.

A UDP packet header consists of a mere 8 bytes of data, broken up into 4 individual fields that each are 2 bytes in length; those fields are as follows:

• Source port: The specific port of the socket connection on the source machine generating the request.
• Destination port: The port of the connection on the destination machine.
• Length: The exact length of the packet, including the payload that immediately follows the 8-byte header.
• Checksum: A simple value used to verify the data integrity of the payload.

Using Wireshark, we can see this in action. With a simple UDP packet, the full contents are captured by those few relevant fields, as seen in the Packet Details view in the middle of my Wireshark window:

However, since TCP provides reliable delivery, guaranteed ordering, and leverages a handshake-protocol that UDP forgoes, the specification of a TCP packet header is much longer. Where sufficient context for UDP could be encapsulated in a mere 8 bytes, sufficient context for TCP demands a header of up to 20 bytes. This is including a number of flag-bits indicating the state of the individual packets in the context of the larger session, and a sequence number to provide the protocol-specified ordering of packets. A brief examination of the Packet Details view of a simple TCP packet within Wireshark should illuminate the disparity in the expected context provided by a TCP packet header, as follows:

As you can see here, even though the actual length of the TCP packet in bytes is shorter than the UDP packet that we looked at previously, the header provides substantially more information than was necessary for a valid UDP connection. There was obviously overlap (of the source and destination ports, and a checksum), but there was a wider gap between the two headers than there was common ground.

So, hopefully, it's now clear why what constitutes sufficient context is driven by the protocol under which a packet was constructed. The specifics of what is sufficient can change, but for every protocol, there will always be a minimum amount of context that is sufficient to be forwarded or processed.