The IPv4 packet header is what actually carries a packet across a network: source and destination addressing, fragmentation information, and everything a router needs to make a forwarding decision, all packed into a compact 20-to-60-byte structure. This guide breaks down every field in the header, what each one actually does, and how the whole thing compares to IPv6’s simplified approach.
How the Header Fits Into the Bigger Picture
The network layer takes a transport layer segment, TCP or UDP, and encapsulates it into an IP packet by adding this header in front of it. The header stays attached to the packet for its entire journey across the network, and every router along the way reads it to make forwarding decisions, without ever needing to look at the payload riding inside.
IPv4 Header Fields
| Field | Size | Purpose |
|---|---|---|
| Version | 4 bits | Identifies the IP version; always 0100 for IPv4 |
| Internet Header Length (IHL) | 4 bits | Header length in 32-bit words; minimum 20 bytes, maximum 60 bytes |
| Differentiated Services (DS) | 8 bits | Split into DSCP and ECN, used for QoS and congestion signaling |
| Total Length | 16 bits | Full packet size, header plus payload |
| Identification | 16 bits | Shared value across all fragments of the same original packet |
| Flags | 3 bits | Signals whether a packet is fragmented |
| Fragment Offset | 13 bits | A fragment’s position within the original packet |
| Time to Live (TTL) | 8 bits | Hop limit, decremented at each router |
| Protocol | 8 bits | Identifies the upper-layer protocol carried in the payload |
| Header Checksum | 16 bits | Error-checking value for the header only |
| Source IP Address | 32 bits | Address of the sending device |
| Destination IP Address | 32 bits | Address of the intended recipient |
| Options | Variable | Present only when IHL > 5; used for security, route recording, timestamps |
Version
A 4-bit field always set to 0100 (4 in decimal) in an IPv4 packet, telling receiving devices exactly which IP version’s rules to apply when parsing the rest of the header.
Internet Header Length (IHL)
A 4-bit field specifying header length in 32-bit (4-byte) increments. The minimum value is 5, giving the standard 20-byte header with no options; the maximum value is 15, giving a 60-byte header when the full Options field is used. Most packets you’ll ever see use the minimum 20-byte header, since Options are rarely used in modern IPv4 traffic.
Differentiated Services (DS)
Originally called the Type of Service (ToS) field, this 8-bit field is used to prioritize packets for Quality of Service purposes. It’s split into two sub-fields:
- DSCP (Differentiated Services Code Point): Usually set to 0 by default, but can signal specific QoS requirements, telling routers along the path how to queue and prioritize the packet relative to others.
- ECN (Explicit Congestion Notification): Carries information about congestion detected along the route, letting endpoints respond to developing congestion before packets actually start getting dropped.
Total Length
A 16-bit field giving the complete size of the IP packet, header and payload combined, in bytes. Since it’s 16 bits, the theoretical maximum IPv4 packet size is 65,535 bytes, though in practice, actual packet size is almost always constrained well below that by the MTU of the media the packet needs to cross.
Identification
A 16-bit field that, when a packet gets fragmented during transmission, is shared identically across every fragment of that original packet. This is exactly what lets the destination host correctly regroup fragments belonging to the same original packet, distinguishing them from fragments of any other packet arriving around the same time.
Flags
A 3-bit field indicating whether a packet has been fragmented, or whether it’s permitted to be fragmented at all. The most significant bit is reserved and always set to 0; the remaining two bits are the “Don’t Fragment” (DF) and “More Fragments” (MF) flags, which together tell routers and the destination host how to handle this specific packet’s fragmentation status.
Fragment Offset
A 13-bit field specifying exactly where a given fragment belongs within the original, unfragmented packet. Combined with the Identification field, this is what allows the destination host to reassemble fragments back into the correct order, even if they arrive out of sequence.
Time to Live (TTL)
An 8-bit field limiting how many router hops a packet can traverse before being discarded. Every router that forwards the packet decrements TTL by at least one; if it reaches zero, the packet gets dropped and the router that dropped it typically sends an ICMP “Time Exceeded” message back to the source. This mechanism exists specifically to prevent a packet from circulating indefinitely if a routing loop develops somewhere in the network.
Protocol
An 8-bit field identifying which upper-layer protocol is carried in the packet’s payload, letting the network layer at the destination hand the payload off to the correct protocol handler. Common values include ICMP (1), TCP (6), and UDP (17), assigned and maintained by IANA.
Header Checksum
A 16-bit field storing a checksum computed over the header only, not the payload. The receiving device recalculates this checksum and compares it against the value in the header; a mismatch means the header was corrupted in transit, and the packet gets discarded. Since TTL changes at every hop, every router along the path has to recompute this checksum itself before forwarding, which is part of why header checksum calculation, while simple, adds real per-hop processing overhead.
Source and Destination IP Address
Two 32-bit fields identifying the sending and receiving devices. These are the two fields most people think of first when they picture an IP packet, and under normal routing, they typically remain unchanged for the packet’s entire journey from source to destination. The one significant exception is Network Address Translation (NAT): when a packet crosses a NAT boundary, commonly at the edge between a private network and the public internet, its source or destination address is deliberately rewritten, which is a normal and expected part of how NAT functions rather than an error.
Options
An optional, variable-length field present only when IHL is greater than 5. Historically used for features like security labeling, route recording, and timestamping, Options see limited use in modern IPv4 traffic, and some network security devices even block or strip packets carrying unusual option values by default, since they’ve historically been used in certain scanning and evasion techniques.
IPv4 Header vs. IPv6 Header
It’s worth understanding how significantly IPv6 simplified this structure, since the two headers work quite differently:
| Characteristic | IPv4 Header | IPv6 Header |
|---|---|---|
| Size | Variable, 20-60 bytes | Fixed, always 40 bytes |
| Address length | 32 bits | 128 bits |
| Header checksum | Present | Removed entirely |
| Fragmentation fields | Built into the base header | Moved to an optional extension header |
| Options | Variable-length Options field | Replaced by chained extension headers |
| Per-hop router processing | Recalculates checksum at every hop | No checksum to recalculate |
IPv6’s fixed 40-byte header, with no checksum field and fragmentation handling moved out of the base header entirely, was a deliberate design choice to reduce the processing burden on routers. Removing the header checksum in particular made sense once error-checking at other layers (like the data link layer’s own frame check sequence) was considered sufficient, without needing IP itself to duplicate that work at every single hop.
A Worked Example: Reading a Real Header
Say a packet capture shows an IPv4 header with these values: Version 4, IHL 5, Total Length 60, TTL 64, Protocol 6, Source 192.168.1.10, Destination 93.184.216.34.
From this alone, you can tell quite a bit. IHL of 5 means a standard 20-byte header with no Options. Total Length of 60 means the packet is 60 bytes total, so the payload is 40 bytes (60 minus the 20-byte header). TTL of 64 is a common default starting value on Linux-based systems, and Protocol 6 confirms this packet is carrying TCP, not UDP or ICMP. The source address is a private, RFC 1918 address, while the destination looks like a public internet address, suggesting this packet either crossed a NAT boundary already or is about to.
Troubleshooting Using Header Fields
A connection seems to work for small transfers but stalls on larger ones. Check for MTU-related fragmentation issues; if the Don’t Fragment flag is set and a packet exceeds a link’s MTU somewhere along the path, it gets dropped rather than fragmented, and if the resulting ICMP error is being blocked, the connection just silently stalls.
Unexplained TTL-related connectivity failures. If traceroute shows a connection failing at a consistent, specific hop count, TTL exhaustion due to a routing loop is worth investigating, rather than assuming the destination itself is unreachable.
A firewall or IDS flagging traffic containing IP Options. Since Options are rare in normal modern traffic, many security tools treat their presence as at least worth logging, sometimes worth blocking outright, given their historical association with certain scanning techniques. This is usually expected, security-conscious behavior rather than a misconfiguration to fix.
Why Header Field Sizes Aren’t Arbitrary
It’s easy to treat these field sizes as trivia to memorize, but each one reflects a genuine engineering tradeoff made decades ago. The 32-bit address fields, for instance, seemed enormous when IPv4 was designed, offering over 4 billion possible addresses, but that ceiling became a real constraint as the internet grew far beyond anything its original designers anticipated, which is exactly why NAT became so essential and why IPv6’s 128-bit addresses exist at all. The 16-bit Total Length field caps a single IPv4 packet at 65,535 bytes, a limit that made sense for the network speeds and hardware of IPv4’s era but would be genuinely limiting without jumbo frame extensions and other workarounds on today’s high-speed links.
Even the 8-bit TTL field, capping a packet at 255 hops, reflects an assumption about how large and how deeply nested a network path might realistically get, an assumption that has held up remarkably well across decades of internet growth, even as nearly every other aspect of networking has changed dramatically. Understanding the reasoning behind each field, rather than just memorizing the numbers, makes the whole header far easier to retain and reason about under exam conditions.
Frequently Asked Questions
What is the minimum and maximum size of an IPv4 header?
The minimum size is 20 bytes, used when the IHL field is set to its minimum value of 5 with no Options present. The maximum is 60 bytes, when IHL is set to its maximum value of 15, fully utilizing the variable-length Options field.
What does the TTL field actually prevent?
TTL prevents a packet from circulating indefinitely if a routing loop develops somewhere in the network, since it’s decremented at every hop and the packet gets discarded once it reaches zero. Without TTL, a looping packet could consume bandwidth indefinitely rather than eventually being dropped.
How does the Protocol field differ from the Version field?
The Version field identifies which IP version the header itself follows, always 0100 for IPv4. The Protocol field identifies the upper-layer protocol carried inside the packet’s payload, like TCP or UDP, telling the receiving device’s network layer which protocol handler should receive the data next.
Does the IPv4 header checksum cover the entire packet?
No, the header checksum covers only the header itself, not the payload. Payload-level error checking is handled separately, typically by the transport layer protocol carried inside, like TCP’s own checksum, or by upper-layer application protocols.
Why does IPv6 not have a header checksum field?
IPv6’s designers removed the header checksum specifically to reduce per-hop processing overhead, since every router previously had to recalculate IPv4’s header checksum on every packet due to the TTL field changing at each hop. Error-checking is instead left to the data link layer and transport layer, which already perform their own checks.
Do source and destination IP addresses ever change while a packet is in transit?
Under normal routing, no, they remain the same from source to destination. The significant exception is Network Address Translation, which deliberately rewrites the source or destination address at a NAT boundary, a normal and expected part of how NAT works rather than an anomaly.
