VMware ESXi and vSphere Cluster Management
IPv4 Header: Fields, Packet Structure, and Fragmentation
Learn every IPv4 header field, calculate header and payload length, interpret TTL and protocol values, understand checksums, and analyze fragmentation in Wireshark.
An IPv4 datagram is a network-layer packet made of an IPv4 header followed by payload data. The header contains information needed for routing, delivery, lifetime control, fragmentation, and identification of the protocol carried in the payload.
The IPv4 header belongs to the network layer. A TCP or UDP header, when present, is inside the IPv4 payload and belongs to the transport layer. Ethernet headers and trailers are outside the IPv4 datagram.
IPv4 headers are conventionally drawn as a sequence of 32-bit rows. The fixed portion is 20 bytes, and optional fields can extend the complete header to 60 bytes.
IPv4 Header Layout and Size
The Internet Header Length (IHL) field is 4 bits wide and records the header length in 32-bit words, not bytes. Multiply IHL by 4 to obtain the header size in bytes.
- IHL 5: 5 × 4 = 20 bytes, the minimum header size.
- IHL 7: 7 × 4 = 28 bytes, meaning options and possibly padding are present.
- IHL 15: 15 × 4 = 60 bytes, the maximum IPv4 header size.
IPv4 options must end on a 32-bit boundary. If an option does not naturally fill the final word, padding bytes are added. Padding is part of the header but does not convey a separate routing or transport instruction.
IPv4 Header Field Reference
Version, Service, and Length Fields
Version
The 4-bit Version field contains the value 4 in an IPv4 packet. It allows a receiving device to distinguish IPv4 from other IP versions before interpreting the remaining fields.
Differentiated Services and ECN
The 8-bit field was historically called Type of Service. Modern IPv4 uses it as two logical fields: DSCP, or Differentiated Services Code Point, and ECN, or Explicit Congestion Notification.
DSCP can classify traffic and indicate desired forwarding treatment, such as a class intended for low delay. Older documentation and analyzer displays may use terms such as priority or precedence. ECN allows endpoints and routers to indicate congestion without necessarily dropping a packet.
Total Length
Total Length is the size in bytes of the entire IPv4 packet, including the IPv4 header and payload. Its valid range is 20 through 65,535 bytes. The payload length is calculated as:
payload length = Total Length - (IHL × 4)For example, a packet with Total Length 1500 and IHL 5 has a 20-byte header and a 1480-byte IPv4 payload. Total Length must also fit the maximum transmission unit, or MTU, of the outgoing link unless fragmentation is permitted.
Addresses and Upper-Layer Protocol
Source and Destination Addresses
Source Address and Destination Address are each 32-bit IPv4 fields. They identify the apparent sender and intended recipient. Normal forwarding decisions use the destination address; routers do not normally forward based on the source address.
Network Address Translation (NAT) can modify source or destination addresses as a packet crosses a translation device. Because the IPv4 header changes, the header checksum must also be updated. NAT commonly updates related transport checksums as well.
Protocol
The Protocol field identifies the next protocol inside the IPv4 payload. It directs the receiving host to the appropriate upper-layer handler.
The Protocol field is not an Ethernet EtherType and is not a TCP or UDP port number. EtherType identifies the network-layer payload in an Ethernet frame. Protocol identifies the payload carried by IPv4. TCP or UDP port numbers are found only after the corresponding TCP or UDP header is decoded.
TTL and Header Checksum
Time To Live
Time To Live (TTL) is an 8-bit hop limit. Each router forwarding an IPv4 packet decreases TTL, normally by one. If the value reaches zero, the router discards the packet and typically sends an ICMP Time Exceeded message to the source.
This prevents a routing loop from allowing packets to circulate indefinitely. Traceroute and tracert exploit this behavior by sending packets with progressively larger TTL values and observing the ICMP responses from successive routers.
Initial TTL values such as 32, 64, 128, or 255 are commonly observed, but they are examples rather than reliable operating-system fingerprints. A captured TTL has already been reduced by every router between the sender and the capture point.
Header Checksum
The IPv4 Header Checksum protects only the IPv4 header. It does not protect TCP, UDP, ICMP, or other payload data. Routers and hosts can verify it when receiving a packet; a failed check can cause the packet to be discarded.
Because forwarding routers decrement TTL, they must recalculate the IPv4 header checksum after changing TTL. Other devices that modify mutable header fields, including NAT devices changing addresses, must also update it.
IPv6 does not have an IP header checksum. Its design relies on link-layer checks and transport-layer checksums, with other mechanisms used for error detection.
Fragmentation Fields
Identification
Identification is a value used to associate fragments with the same original IPv4 datagram. At the destination, fragments with matching identification, source address, destination address, and Protocol value can be grouped for reassembly. It is principally meaningful when fragmentation occurs.
Flags
The Flags field contains three bits:
- Reserved bit: Must be zero in normal IPv4 use.
- DF, Don't Fragment: When set, routers must not fragment the datagram.
- MF, More Fragments: When set, additional fragments follow. The final fragment has MF clear.
DF is central to Path MTU Discovery. If a packet is too large for the next link and DF is set, the router cannot fragment it. Instead, it should discard the packet and send an ICMP Destination Unreachable message with the Fragmentation Needed code, commonly called ICMP type 3, code 4.
Fragment Offset
Fragment Offset identifies where a fragment's payload belongs within the original datagram. The value is measured in units of 8 bytes, so an offset of 100 represents byte position 800.
Identification, source and destination addresses, Protocol, Flags, and Fragment Offset together support reassembly. Every nonfinal fragment normally has a payload length divisible by 8 bytes because later offsets use 8-byte units. The final fragment may have a payload length that is not divisible by 8.
Reassembly takes place at the final destination, not at each intermediate router. If a fragment is lost, arrives too late, overlaps unexpectedly, or is filtered by a firewall, the destination may be unable to reconstruct the datagram. The application may then see a timeout or missing data rather than a partial successful packet.
IPv4 Options and Padding
IPv4 options are optional, variable-length extensions placed after the fixed fields. Possible purposes include diagnostics, recording route-related information, timestamps, and security-related controls. They are uncommon in ordinary traffic.
Options increase IHL and therefore reduce the space available for payload at a given Total Length. They can also require slower processing and may be rejected or filtered by firewalls and other middleboxes. Padding aligns the complete header to a 32-bit boundary.
IPv4 Fragmentation Workflow
- A host or router prepares an IPv4 datagram for an outgoing link.
- If the datagram exceeds that link's MTU and fragmentation is allowed, the datagram is divided into smaller fragments.
- Each fragment receives the same Identification, source, destination, and Protocol values. Each fragment has its own Total Length, checksum, Flags, and Fragment Offset.
- The first fragment normally has offset 0 and MF set. Middle fragments have nonzero offsets and MF set. The final fragment has MF clear.
- Intermediate routers forward fragments independently and do not normally reassemble them.
- The final destination uses the fragment fields to reassemble the original datagram.
When DF is set and the packet is larger than the next-link MTU, the router sends ICMP Fragmentation Needed instead of fragmenting. The sender can use that information to reduce packet size, which is the basis of Path MTU Discovery. Tunnels and VPNs are frequent causes of reduced effective MTU.
Reading an IPv4 Header in Wireshark
Open a capture and expand the packet's IPv4 or Internet Protocol Version 4 layer. The analyzer maps decoded values to the on-wire fields. Useful display filters include:
ip
ip.proto == 6
ip.proto == 17
ip.flags.mf == 1 or ip.frag_offset > 0A typical IPv4/TCP packet might show Version 4, Header Length 20 bytes, Total Length 1500 bytes, TTL 64 or a nearby value, Protocol TCP, source and destination IPv4 addresses, and a checksum status. If IHL is 5, calculate the payload as 1500 − 20 = 1480 bytes. The IPv4 payload then begins with a TCP header, whose ports are separate from the IPv4 Protocol field.
To identify fragmentation, inspect the DF and MF flags and the Fragment Offset. A packet with MF set has more fragments following it. A packet with a nonzero offset is not the first fragment. Group candidate fragments by Identification, source, destination, and Protocol, then check whether their offsets cover the expected ranges.
Practical Investigations
Testing Path MTU and DF
On many Linux systems, use a DF-enabled ping with a selected payload size:
ping -M do -s <payload-size> <destination>On Windows, a commonly used form is:
ping -f -l <payload-size> <destination>Syntax and permissions vary by platform. Increase or decrease the payload size while inspecting the capture for ICMP type 3, code 4 responses. Remember that the ping payload is not the complete IPv4 packet: IP, ICMP, and possibly link-layer overhead also contribute to the transmission size.
Observing TTL
traceroute <destination>
tracert <destination>Unix-like systems commonly use traceroute, while Windows uses tracert. These tools vary in probe protocol and output, but both use limited TTL values to reveal forwarding hops.
Troubleshooting IPv4 Header Problems
Checksum Errors or Malformed Packets
- Compare captures from another point in the path to distinguish corruption from a capture artifact.
- Check whether interface checksum offloading makes locally captured outgoing checksums appear invalid.
- Confirm that the packet is decoded as IPv4 and that its IHL matches the displayed header length.
Small Transfers Work but Large Transfers Fail
- Investigate a path MTU problem or an MTU reduction caused by a tunnel or VPN.
- Look for ICMP type 3, code 4 messages.
- Check whether DF is preventing fragmentation and whether ICMP errors are being filtered.
- Test progressively larger ping payloads with DF behavior enabled.
Fragments Appear but the Application Receives Nothing
- Group fragments by Identification, source, destination, and Protocol.
- Check offsets and MF values for missing ranges or a missing final fragment.
- Consider fragment loss, late arrival, reassembly timeout, or firewall filtering of noninitial fragments.
Packets Expire or Follow an Unexpected Route
- Look for ICMP Time Exceeded responses.
- Run traceroute or tracert to reveal the observed path.
- Compare TTL values at multiple capture points and consider routing loops or an unusually low initial TTL.
Exam- and Analysis-Relevant Notes
- IHL is measured in 32-bit words; multiply it by 4 to get bytes.
- Total Length includes both the IPv4 header and payload.
- The IPv4 checksum covers the header only.
- Routers decrement TTL and recalculate the header checksum.
- Protocol 6 means TCP, 17 means UDP, and 1 means ICMP.
- DF prevents router fragmentation; MF indicates that more fragments follow.
- Fragment Offset is measured in 8-byte units.
- Reassembly occurs at the destination, not at every router.
- TCP and UDP port numbers are not IPv4 header fields.
For continued study, review IPv4 header fields and fragmentation alongside IPv4 addressing, ICMP errors, MTU behavior, and packet analysis.