Anatomy of an IPv4 Packet

When beginning a career in computer networking, it is vital that the person entering the field is ready to learn and has a very open mind when it comes to new technologies and concepts. One of the first subjects that a new networking student must learn is TCP/IP, as it is used to connect together almost all modern devices. This article takes a look at the IPv4 packet, the fields that are defined within it and how they are used to transport the traffic from source to destination.

TCP/IP Version 4 Packet Structure

The TCP/IP Version 4 packet is composed of a number of different fields that can be used by the source and intermediary devices to determine the way a specific packet is treated when being transported. Figure 1 below shows the structure of the packet and the different fields that are contained within:

As can be seen from the figure, there are a number of fields which have rather obvious names and some that do not. The following sections will explain the purpose of each of these fields and how they can be used to change forwarding behavior.

Version Field

The version field is one of the fields with a more obvious name and uses 4 bits. There are currently two versions of TCP/IP used in modern networks, Version 4 and Version 6. This article takes a look at the structure of the Version 4 header; when sending a Version 4 packet the value of the Version field will be 4 which is represented in binary as‘0100’.

Internet Header Length (IHL)

The IHL field is used to specify the total length of the header and is represented in 32 bit words. The minimum valid value for the IHL field is 5 (5 x 32 = 160 bits) which accounts for the Version, IHL, TOS, Length, Identification, Flags, Fragment Offset, TTL, Protocol, Checksum, and the Source and Destination Addresses, which are all mandatory.

Type of Service (TOS)/Differentiated Services Code Point (DSCP)[md]Explicit Congestion Notification (ECN)

When the Internet Protocol (IP) was initially designed this part of the packet header was called the Type of Service field that used 8 bits; this field was used to define a precedence value along with other quality of service (QoS) parameters for the packet. The modern implementation has changed from using this part of the packet from a single 8-bit TOS field to a 6-bit DSCP and 2-bit ECN fields. The DSCP field extends on the way that QoS is placed upon a specific packet; the specifics of the DSCP field could run the length of this entire article and is outside the scope of this article. The ECN field is used to provide end-to-end congestion notification between supporting ECN equipment.

Length

Unlike the IHL field, the Length field is used to indicate the total length of the IP packet including the data. This field is represented in octets (also referenced as bytes or 8 bits) and is provided a total of 16 bits in the header.

Identification

The Identification field uses 16 bits and is uniquely set by the sender to help identify specific packets when they are being reassembled from fragments. If there is only one packet and it is not fragmented then it will be the only packet with that specific identification value. For fragmented packets, the value is the same across all of the fragments and is used by the destination device to reassemble the data.

Flags

The Flags field is used to control how a specific IP packet is treated by a device. The field is 3 bits and is formatted as follows:

• The first bit is always set to 0
• The second bit represents whether a packet is allowed to be fragmented (Don’t Fragment[md]DF) or split into multiple pieces.
  • A value of 0 means that the packet is allowed to be fragmented
  • A value of 1 means that the packet is NOT allowed to be fragmented
• The third bit represents the ‘location’ of a packet in a series of fragmented packets
  • A value of 0 means that the packet is the last fragment in a series OR a packet that is not fragmented at all
  • A value of 1 means that the packet is not the last fragment in a series and more fragments should be expected

Fragment Offset

The Fragment Offset field uses 13 bits and is represented in units of 8 octets (or bytes). This field is used to indicate to the destination device where a received fragment should be placed when all of the data from the packet is being reassembled. The Fragment Offset, along with the Identification field, is used to identify packets that have been fragmented and reassemble them in the correct order. Packets that are not fragmented AND the first packet in a series of fragmented packets will always have a fragment offset set to 0.

Time to Live (TTL)

The TTL field is used to limit the amount of time that a packet is allowed to exist on the “network”. The field uses 8 bits and is represented in seconds. Each device that receives a packet is required to decrement the TTL value by at least 1 regardless of whether the processing took less than a second; any device that decrements the value of the TTL field to 0 is required to drop the packet. Since almost all packets are processed in less than a second it is common for the value of the TTL field to be interpreted as maximum hops; for example, if a packet has a TTL of 3 and each device is required to decrement the TTL by at least 1 then the maximum number of devices that can process the packet is 3 before the packet must be dropped.

Protocol

The Protocol field uses 8 bits and indicates the next level protocol that is contained within the data portion of the packet. The most common values include the Transmission Control Protocol (TCP) with a value of 0x06 (hex) or 00000110 (binary), User Datagram Protocol (UDP) with a value of 0x11 (hex) or 00010001 (binary) and the Internet Control Message Protocol (ICMP) with a value of 0x01 (hex) or 00000001 (binary).

Checksum

The Checksum field uses 16 bits and is computed for only the packet header. Checksum provides a method of verifying that the header has not been corrupted when being transmitted from one device to another. To explain its function without going into the math, a checksum value is derived from the contents of the header at the source and is recomputed at the destination; if these values do not match, the packet will be discarded. Because the contents of the TTL field change from device to device, the checksum is recomputed at each device and reset in the header.

Source and Destination Address

Both the Source and Destination Address fields are 32 bits and indicate the source and destination IP addresses, respectively.

Options

The Options field is variable in length depending on the specific options that are being set; this field is optional. Most modern network traffic does not utilize the options field at all and because it is an optional field is not typically used.

Padding

The padding field is variable in length and is used when the Options field is used to ensure that the packet header ends at a 32 bit boundary.

Data

The data field inside a packet is variable in length and can contain any number of different protocols as defined by the developer. Common network traffic uses the TCP, UDP and ICMP protocols which will be contained within this part of the packet.

Summary

The processing of traffic from source to destination can be very confusing for those entering into the networking field. While most traffic uses basic parameters (no QoS, fragmentation or Options) it is possible for traffic to utilize a number of different complex features. The purpose of this article is to make the reader familiar with the fields contained within the IP packet and give a general overview as to how they are used. Hopefully the content of this article can give the reader a starting point when learning about IP and how it is used.