VMware ESXi and vSphere Cluster Management

IPv4 Header Fields Explained

Learn every IPv4 header field, including IHL, total length, fragmentation, TTL, protocol numbers, checksum behavior, addresses, options, and Wireshark interpretation.

IPv4 header overview

An IPv4 packet, also called an IPv4 datagram, consists of an IPv4 header followed by payload data. The payload may contain an upper-layer message such as a TCP segment, UDP datagram, ICMP message, or GRE packet.

The header carries control and delivery information used by hosts and routers. It tells a receiver how to interpret the packet, identifies its source and destination, limits how long it may remain in the network, and describes how to process fragmentation and the payload protocol.

The normal header fields are read from left to right and then from top to bottom in a diagram. The base IPv4 header is 20 bytes. IPv4 options can extend it to a maximum of 60 bytes.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+----+----+--------+-----------------------------------------------+
|Ver | IHL| DSCP/  |                 Total Length                  |
|    |    | ECN    |                                               |
+------------------+-------------------+---+-----------------------+
|            Identification            |Flg|     Fragment Offset   |
+--------------------------------------+---+-----------------------+
|                TTL                   |Protocol| Header Checksum |
+------------------------------------------------+-----------------+
|                       Source Address                            |
+------------------------------------------------+-----------------+
|                    Destination Address                          |
+------------------------------------------------+-----------------+
|                    Options and Padding                          |
+------------------------------------------------+-----------------+
|                         Payload ...                              |
+------------------------------------------------+-----------------+

Each horizontal row in this layout represents 32 bits, or 4 bytes. The options and padding row is present only when the header is longer than the 20-byte base header.

IPv4 header format and field sizes

Most fields have a fixed size. Options are the exception: they are variable-length extensions. The Internet Header Length (IHL) field tells the receiver where the header ends and the upper-layer payload begins.

Version

The Version field is 4 bits long and identifies the IP version used by the packet. An IPv4 packet has the decimal value 4 in this field. IPv6 packets use the value 6. The version value must be interpreted before the remaining header layout because IPv4 and IPv6 have different header formats.

Internet Header Length (IHL)

IHL specifies the IPv4 header size in 32-bit words, not directly in bytes. A 32-bit word is 4 bytes, so convert IHL to bytes by multiplying by 4:

Header length in bytes = IHL value × 4

For example, an IHL value of 5 means:

5 × 4 = 20 bytes

Five is the minimum valid IHL value because the base IPv4 header is 20 bytes. The permitted range is 5 through 15:

An IHL value above 5 indicates that IPv4 options and padding occupy some space before the payload. A receiver uses IHL to find the first byte of the upper-layer payload. It must not assume that every IPv4 header is exactly 20 bytes.

Differentiated Services and the legacy Type of Service field

The 8-bit field after IHL has had more than one interpretation. Historically, it was called Type of Service (ToS) and was associated with priority, delay, throughput, and reliability preferences. Older descriptions may also discuss IP precedence, a priority interpretation of the high-order bits.

Modern IPv4 uses this byte as the Differentiated Services field. Its six most significant bits form the Differentiated Services Code Point (DSCP). DSCP values classify traffic so that routers and switches can apply quality-of-service policies such as queuing or preferential treatment.

The remaining two bits form Explicit Congestion Notification (ECN). ECN can signal congestion between endpoints without necessarily requiring a router to drop the packet. The field should therefore be read using its current DSCP and ECN interpretation rather than treating legacy precedence bits as the only meaning.

Total Length

Total Length is a 16-bit field containing the size of the complete IPv4 packet in bytes. It includes both the IPv4 header and the payload.

IPv4 payload size = Total Length − (IHL × 4)

The minimum valid total length is 20 bytes, representing a packet with a base header and no payload. The theoretical maximum is 65,535 bytes because the field has 16 bits.

For example, if IHL is 5 and Total Length is 1,500:

Header = 5 × 4 = 20 bytes
Payload = 1,500 − 20 = 1,480 bytes

Total Length is not the same as IHL. IHL describes only the header. It is also not necessarily the same as the link-layer frame length: an Ethernet frame adds a frame header and trailer, while padding or other link-layer details may affect the captured frame size.

Identification, Flags, and Fragment Offset

These fields work together to support IPv4 fragmentation. Fragmentation occurs when a datagram is too large for the maximum transmission unit, or MTU, of an outgoing interface and fragmentation is permitted.

Identification

The 16-bit Identification field helps associate fragments with the same original IPv4 datagram. A destination uses it with the source address, destination address, and Protocol value to distinguish fragments that belong together.

Fragments from different datagrams must remain distinguishable even when they have similar source and destination addresses and carry the same upper-layer protocol. The destination uses the Identification value and the fragment-position information to reconstruct the original datagram.

Flags

The Flags field contains three bits:

• Reserved bit: Normally zero. It is reserved for future use and should not be set in ordinary IPv4 traffic.
• Don't Fragment (DF): When set, routers must not fragment the packet. If the packet exceeds the outgoing path MTU, the router drops it and can return an ICMP fragmentation-needed message.
• More Fragments (MF): Set on every fragment except the final fragment. A zero MF bit indicates that no more fragments follow, although an unfragmented packet also has MF set to zero.

DF is central to Path MTU Discovery (PMTUD). A sender transmits packets with DF set. If a router finds that a packet is too large for the next link, it cannot fragment the packet; instead, it reports the required condition with ICMP fragmentation-needed feedback when supported and permitted.

Fragment Offset

The 13-bit Fragment Offset identifies a fragment's position within the payload of the original datagram. The value is measured in units of 8 bytes, not individual bytes.

Because the offset uses 8-byte units, the payload carried by every nonfinal fragment generally has a length divisible by 8 bytes. This allows the next fragment's position to be represented as an integer offset value. The final fragment may have a payload length that is not divisible by 8.

For reassembly, the destination combines the source address, destination address, Protocol value, Identification value, MF flag, and Fragment Offset. Fragmentation is an IPv4 function. Intermediate routers may create fragments, but fragments are reassembled at the destination rather than at every intermediate router.

Fragmentation example

Suppose a datagram exceeds an outgoing interface MTU and DF is clear. A router can split the original payload into multiple IPv4 packets. The fragments share an Identification value, but their Fragment Offset values identify different portions of the original payload. Every fragment except the last has MF set to 1. The final fragment has MF set to 0. The destination collects the fragments and reassembles the original datagram.

If DF is set instead, the router cannot perform this split. It drops the oversized packet and can send an ICMP fragmentation-needed message. Firewalls that block fragments, missing fragments, overlapping fragments, and reassembly timeouts can all prevent successful delivery.

Time To Live (TTL)

Time To Live (TTL) is an 8-bit limit that prevents a packet from circulating indefinitely if routing loops exist. Despite its name, TTL is normally treated as a hop limit rather than a precise number of seconds.

Each router decrements TTL before forwarding the packet. If a router receives a packet with TTL 1, it cannot forward it with a valid positive lifetime. The router discards it and normally sends an ICMP Time Exceeded message to the source.

Initial TTL: 128
After router 1: 127
After router 2: 126

Host operating systems can select different initial TTL values, so an observed TTL does not by itself reveal the exact number of hops. Traceroute and tracert deliberately send probes with low TTL values. Each probe expires at a successive router, causing ICMP Time Exceeded responses that reveal the path one hop at a time. A missing response can also result from ICMP filtering or rate limiting.

Protocol field

The 8-bit Protocol field identifies the protocol encapsulated in the IPv4 payload. The value is a protocol number assigned by IANA. The receiver uses it to deliver the payload to the correct upper-layer protocol handler.

Protocol 6 means TCP and Protocol 17 means UDP. These values are not TCP or UDP port numbers. A TCP or UDP port appears inside the payload, after the IPv4 header and any IPv4 options. Encapsulation or tunneling can cause the outer IPv4 Protocol value to identify ICMP, GRE, or another protocol instead of the application traffic expected inside.

Header Checksum

The 16-bit IPv4 Header Checksum validates the IPv4 header only. It does not protect the payload data. Conceptually, the checksum uses one's-complement arithmetic: the header is divided into 16-bit words, those words are added with end-around carry, and the complemented result is stored in the checksum field.

A receiver checks the header checksum. If the IPv4 header checksum is invalid, the packet is discarded. A router must recalculate the checksum after changing TTL because decrementing TTL changes header contents. Other header changes, such as some NAT translations, also require a new checksum.

Transport-layer checksums are different. TCP and UDP checksums can protect transport data and include a pseudo-header containing selected IP addressing information. Therefore, a valid IPv4 Header Checksum does not guarantee that the payload is undamaged.

Source and Destination IPv4 Address fields

The Source Address and Destination Address fields are each 32 bits long. The source address identifies the IPv4 sender, and the destination address identifies the intended IPv4 recipient.

Routers forward packets primarily by examining the destination address and consulting their routing tables. The source address is also important for return traffic, filtering, diagnostics, and error reporting. In a simple routed path, these addresses can remain end-to-end. A NAT device may alter one or both addresses, and it must update affected checksums as needed.

Options and padding

IPv4 options are optional header extensions. Historical uses include diagnostics, testing, route-related functions, timestamps, and security-related controls. Options increase the IHL value and therefore move the payload farther into the packet.

Options are uncommon in normal traffic because they add overhead, can require slower processing, and are often filtered by routers or security devices. Padding adds zero-value alignment data when necessary so that the complete IPv4 header ends on a 32-bit boundary.

Reading an IPv4 header capture with Wireshark

Wireshark decodes captured packets and displays both raw values and human-readable interpretations. To show IPv4 packets, use the display filter:

ip

Consider a representative TCP packet whose IPv4 decode contains:

• Version: 4
• IHL: 5, which Wireshark also displays as a 20-byte header
• DSCP/ECN: a decoded traffic-classification and congestion value
• Total Length: 1,500 bytes, including the 20-byte header and 1,480-byte payload
• Identification: a value used to identify this datagram if fragmentation occurs
• Flags: DF set, MF clear
• Fragment Offset: 0
• TTL: 128
• Protocol: 6, decoded as TCP
• Header Checksum: a displayed checksum and its validation status
• Source and destination IPv4 addresses: the endpoints visible at the capture point

This packet has no IPv4 options because IHL is 5. Its Protocol field identifies TCP, but the TCP source and destination ports must be examined in the TCP header, which follows the IPv4 header. The captured TTL of 128 is the value at the capture point; it does not prove that the packet began with TTL 128 or that no routers were crossed before capture.

Likewise, the source and destination addresses shown by Wireshark describe the packet at the observation point. NAT or tunneling can make addresses and protocol values differ between network segments. A capture shows what happened at one point in the path, not every change made at other routing hops.

Useful Wireshark and tshark filters

To find fragmented IPv4 traffic:

ip.flags.mf == 1 || ip.frag_offset > 0

To display IPv4 packets carrying TCP:

ip.proto == 6

To print selected IPv4 fields with tshark:

tshark -r capture.pcapng -Y ip -T fields -e ip.version -e ip.hdr_len -e ip.len -e ip.ttl -e ip.proto -e ip.src -e ip.dst

The output includes the version, header length, total length, TTL, protocol number, source address, and destination address. Compare IHL with Total Length when calculating how many bytes remain for the IPv4 payload.

Practical packet and troubleshooting examples

Testing packet behavior

A normal IPv4 packet can be generated with:

ping <destination-ip-or-hostname>

Platform-specific options can change the packet size or request behavior, so consult the local operating system's command help when testing MTU and fragmentation.

Large packets fail while small packets succeed

Check the path MTU, the DF flag, fragmentation behavior, and ICMP fragmentation-needed messages. An MTU restriction may prevent an oversized packet from being forwarded when DF is set. This commonly affects Path MTU Discovery when required ICMP feedback is blocked.

Traceroute stops or shows an asterisk

Check TTL expiration, ICMP Time Exceeded responses, and ICMP filtering or rate limiting. The probe may be expiring as expected while an intermediate router declines to return the expected response.

Wireshark reports a bad IPv4 checksum

Check whether checksum offloading is enabled and whether the capture was taken before hardware completed checksum calculation. A locally captured packet can appear invalid in software even though the final transmitted packet has a correct checksum.

Traffic is not recognized as TCP or UDP

Inspect the Protocol field and consider encapsulation or tunneling. The outer IPv4 packet may carry ICMP or GRE, while TCP or UDP exists inside an inner packet. Also verify that the capture is decoding the correct layer.

Fragments cannot be reassembled

Inspect Identification, MF, Fragment Offset, and the source and destination addresses. Missing, blocked, overlapping, or delayed fragments can prevent reassembly. Firewalls may treat fragments specially, and reassembly can fail after a timeout.

Exam-relevant summary

• IPv4 consists of a header followed by payload data.
• The base header is 20 bytes; options can increase it to 60 bytes.
• Version is 4 for IPv4 and occupies 4 bits.
• IHL is measured in 32-bit words. IHL 5 equals 20 bytes.
• Total Length includes the IPv4 header and payload and has a maximum theoretical value of 65,535 bytes.
• DSCP occupies 6 bits and ECN occupies 2 bits in the modern Differentiated Services field.
• Identification, Flags, and Fragment Offset support fragmentation and destination reassembly.
• DF prevents fragmentation; MF is set on all fragments except the last.
• Fragment Offset uses 8-byte units.
• Routers decrement TTL. When TTL expires, the packet is discarded and ICMP Time Exceeded is normally sent.
• Protocol 1 is ICMP, 6 is TCP, 17 is UDP, and 47 is GRE. These are not port numbers.
• The IPv4 Header Checksum protects only the IPv4 header and must change when TTL changes.
• Source and destination addresses are 32 bits each, but NAT can alter addresses in transit.
• IPv4 options are uncommon, and padding aligns the header to a 32-bit boundary.