IPv4 Header Fields and Packet Processing
Learn every IPv4 header field, including IHL, DSCP, fragmentation, TTL, protocol, checksum, addressing, encapsulation, and packet-capture analysis.
An IPv4 packet is a Layer 3 network unit made of an IPv4 header followed by a payload. The header carries information needed for addressing, forwarding, lifetime control, fragmentation, traffic classification, integrity checking, and identification of the encapsulated protocol.
The payload may be a TCP segment, UDP datagram, ICMP message, GRE packet, or another protocol carried by IP. The IPv4 header is not the same as the Layer 4 header or application data: a TCP segment, for example, contains a TCP header and application data, and that entire segment can become the IPv4 payload.
An IPv4 header is at least 20 bytes long. Options can extend it to a maximum of 60 bytes. The payload begins immediately after the header, so a receiver uses the Internet Header Length (IHL) field to find that boundary.
IPv4 Header Layout
IPv4 fields are arranged in a defined bit-level format. The first 32 bits contain Version, IHL, the Differentiated Services field, and part of Total Length. The following fields describe packet size, fragmentation, lifetime, protocol identification, integrity, and addresses.
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 | DS | Total Length |
+------------------+-------------------+---+-----------------------+
| Identification |Flg| Fragment Offset |
+-----------------------------------+---+-----------------------+
| TTL | Protocol | Header Checksum |
+---------------------------------------------------------------+
| Source Address |
+---------------------------------------------------------------+
| Destination Address |
+---------------------------------------------------------------+
| Options and Padding, if present ... |
+---------------------------------------------------------------+
| Payload |
+---------------------------------------------------------------+Options are variable-length extensions. Padding adds enough zero-value alignment bytes, when needed, to make the complete header a multiple of 32 bits. With no options, the header is 20 bytes and the payload starts at byte 21.
IPv4 Header Field Reference
Version and Internet Header Length
Version
The 4-bit Version field identifies the IP format. An IPv4 header contains the value 4. An IPv6 base header contains the value 6 and has a different structure. A device uses this field to interpret the remainder of the packet according to the correct IP version.
Internet Header Length
Internet Header Length (IHL) gives the header length in 32-bit words. One word is 4 bytes, so the header length in bytes is IHL × 4.
A normal IPv4 header has IHL 5 because 5 × 4 = 20 bytes. Options increase IHL, and padding may be added so the total remains aligned to a 32-bit boundary.
Differentiated Services Field
The 8-bit field formerly called Type of Service is now commonly called the DS field. It contains a 6-bit Differentiated Services Code Point (DSCP) and a 2-bit Explicit Congestion Notification (ECN) value.
- DSCP: Classifies traffic, such as voice, video, business-critical data, or best-effort traffic.
- ECN: Allows congestion notification without requiring packet loss when the endpoints and network support it.
Routers and switches can use DSCP markings in QoS policies to place packets into queues, assign scheduling treatment, or apply policing. A device may preserve, trust, or rewrite the marking, so inspect both ingress and egress when troubleshooting QoS.
Total Length
Total Length is a 16-bit field containing the complete IPv4 packet size in bytes. It includes the IPv4 header and payload, not just the application or transport data. Its theoretical range is 0 through 65,535, so the largest IPv4 packet is 65,535 bytes.
For example, if IHL is 5 and Total Length is 1500:
Header length = 5 × 4 = 20 bytes
Payload length = 1500 − 20 = 1480 bytesIdentification, Flags, and Fragment Offset
These fields support IPv4 fragmentation. Fragmentation divides one oversized IPv4 packet into smaller packets that fit the next link's Maximum Transmission Unit (MTU). The destination host later performs reassembly.
Identification
The 16-bit Identification value associates fragments that came from one original datagram. During reassembly, the receiving host considers Identification together with the source address, destination address, protocol, and fragmentation information. Packets from unrelated datagrams must not be combined merely because they have similar offsets.
Flags
The 3-bit Flags field is interpreted as follows:
- The first bit is reserved and must be zero.
- DF (Don't Fragment): Prevents fragmentation. If the packet is too large for an outgoing interface and forwarding would require fragmentation, the router discards it and normally sends an ICMP Fragmentation Needed message.
- MF (More Fragments): Indicates that additional fragments follow. The final fragment has MF clear.
Fragment Offset
Fragment Offset identifies where a fragment's payload belongs in the original payload. The value is measured in 8-byte blocks, not individual bytes. Consequently, every nonfinal fragment must contain a payload length that is a multiple of 8 bytes. The final fragment may contain a nonmultiple-of-8 payload because no later offset must be calculated from it.
Fragmentation and Reassembly Example
Consider a 1500-byte IPv4 packet with a 20-byte header crossing an interface whose MTU is 620 bytes. Each fragment needs its own 20-byte header, so each fragment can carry at most 600 payload bytes. Six hundred is divisible by 8.
Original payload = 1500 − 20 = 1480 bytes
Maximum fragment payload = 620 − 20 = 600 bytes
Fragment 1: payload 600, MF set, offset 0
Fragment 2: payload 600, MF set, offset 75 (600 ÷ 8)
Fragment 3: payload 280, MF clear, offset 150 (1200 ÷ 8)Each fragment has the same source, destination, protocol, and Identification value. The destination uses the offsets to reconstruct the 1480-byte payload. Intermediate routers do not reassemble ordinary IPv4 fragments; reassembly occurs at the destination host.
Fragmentation increases overhead and vulnerability to loss. If any required fragment is lost, the destination generally cannot successfully reassemble the original packet. With DF set, a router that cannot forward the packet without fragmentation sends ICMP Fragmentation Needed, when permitted. Path MTU Discovery uses this feedback to determine the smallest usable MTU along a path and avoid sending packets that require fragmentation.
Time To Live
Time To Live (TTL) limits how long an IPv4 packet can circulate. Although its name suggests seconds, routers use it primarily as a hop limit. Each routed hop decrements TTL by at least one before forwarding.
If decrementing causes TTL to reach zero, the router discards the packet and normally sends an ICMP Time Exceeded message to the source. This prevents persistent routing loops. Traceroute deliberately sends probes with increasing TTL values so each successive router that expires a probe can identify itself through an ICMP response.
Protocol Field
The 8-bit Protocol field identifies the next protocol carried in the IPv4 payload. It is delivered to the appropriate component of the receiving IP stack.
The IPv4 Protocol field is different from an Ethernet EtherType, which identifies the network-layer protocol inside an Ethernet frame. It is also different from TCP or UDP port numbers, which identify services or processes at the transport layer.
Header Checksum
The 16-bit Header Checksum validates the IPv4 header only. It does not protect the payload. A router changes TTL at every routed hop, so it must recalculate the IPv4 header checksum before forwarding the packet. NAT devices that change addresses also update relevant checksums.
IPv6 removed the IP header checksum. IPv6 relies on Layer 2 checks, transport checksums, and other mechanisms, reducing per-hop processing. TCP and UDP checksum behavior should not be confused with the IPv4 header checksum.
Source and Destination Addresses
Source and Destination Address fields are each 32 bits. The source identifies where the packet originated, and the destination identifies the intended IP destination. Return traffic normally uses the original destination as its source and the original source as its destination, subject to routing and NAT.
Routers primarily make forwarding decisions using the destination IP address and their routing tables. The Layer 2 address used to reach the next hop is separate. A NAT device may modify a source address, destination address, or both, and must update checksums affected by those changes.
Options and Padding
IPv4 options are optional, variable-length header extensions. Because they increase the header length and may require extra processing, they are uncommon in normal forwarding. Some devices filter, slow-path, or treat option-bearing packets differently.
Padding adds bytes so the header length is a multiple of 32 bits. The IHL value includes both options and padding. The payload begins only after all options and padding.
Encapsulation and Decapsulation
An IPv4 packet is carried inside a Layer 2 frame. A typical transmission can be represented as:
Ethernet frame
└── IPv4 packet
├── IPv4 header
└── TCP segment
├── TCP header
└── Application dataThe IPv4 payload could instead be UDP, ICMP, GRE, or another IP-carried protocol. At each router, the incoming Layer 2 frame is removed, the IPv4 header is examined, and a new Layer 2 frame is built for the next hop. Layer 2 source and destination addresses therefore change hop by hop, while the IPv4 destination typically remains end to end. TTL, fragmentation fields, checksum, and NAT-related fields are possible exceptions to simple end-to-end preservation.
Reading IPv4 Headers in Network Tools
In Wireshark, use the display filter ip to show IPv4 packets. Expand the Internet Protocol Version 4 section to inspect decoded fields such as IHL, DSCP, ECN, Total Length, Identification, flags, fragment offset, TTL, Protocol, checksum, and addresses.
ip.ttlfilters on TTL.ip.protofilters on the Protocol field.ip.flags.dffinds packets with DF set.ip.flags.mffinds packets marked as having more fragments.ip.frag_offsetfilters on fragment offset.
Capture labels may call the DS field “Differentiated Services Field,” DSCP “Differentiated Services Codepoint,” and ECN “Explicit Congestion Notification.” A nonzero fragment offset or MF flag indicates fragmentation. Repeated Identification values combined with matching addresses and protocol can reveal related fragments. Very low TTL values and ICMP Time Exceeded responses can reveal traceroute or a routing-loop symptom. The Protocol value identifies whether the payload is ICMP, TCP, UDP, or GRE.
Useful Commands and Tests
Wireshark
ip
ip.ttl
ip.proto
ip.flags.df
ip.flags.mf
ip.frag_offsetCisco IOS
show interfacesdisplays interface MTU values relevant to fragmentation.show ip interfacedisplays IPv4 interface settings and related operational information.- Use
pingwith a specified size and the Don't Fragment option where supported to test path MTU behavior. - Use
tracerouteto demonstrate TTL-based hop discovery.
General Host Tools
Operating-system-specific ping options can set payload size and request do-not-fragment behavior. traceroute or tracert can reveal hop-by-hop TTL expiration. tcpdump with verbose output can display IPv4 header attributes.
Troubleshooting IPv4 Header Problems
Large Packets Fail but Smaller Packets Work
Compare the packet size with every relevant interface and path MTU. Check whether DF is set and whether ICMP Fragmentation Needed messages are being blocked. A broken Path MTU Discovery process commonly produces this symptom.
Traceroute Stops at One Hop
Review TTL expiration and ICMP Time Exceeded behavior. The router may be filtering or rate-limiting ICMP responses even though it continues forwarding traffic. A routing loop can also cause repeated TTL expiration.
Several Packets Share an Identification Value
Sort candidate fragments by Identification, source and destination addresses, Protocol, MF status, and Fragment Offset. Verify that offsets are sensible, that nonfinal fragment payloads align to 8-byte boundaries, and that the final fragment arrived. Missing one fragment prevents successful reassembly.
Invalid Header Checksum Appears in a Capture
Check whether the capture was taken before a network interface completed checksum offloading. An apparent invalid checksum can be a capture artifact. If offloading is not responsible, investigate packet corruption or incorrect packet generation. A router that changes TTL must update the checksum.
Traffic Receives Unexpected QoS Treatment
Inspect DSCP at ingress and egress. Verify whether each intervening device trusts, preserves, or rewrites the DSCP marking, and check the QoS policy that maps the marking to a queue or treatment class.
IPv4 and IPv6 Comparison
Exam-Relevant Summary
- IHL is measured in 32-bit words: IHL 5 means a 20-byte header.
- Total Length includes the IPv4 header and payload; the maximum is 65,535 bytes.
- DF prevents fragmentation; MF means more fragments follow.
- Fragment Offset uses 8-byte units, so nonfinal fragment payloads must be 8-byte aligned.
- Routers fragment when DF is clear and the packet exceeds the outgoing MTU; the destination performs reassembly.
- Loss of one fragment can prevent reassembly of the entire original packet.
- TTL decreases at every routed hop; expiration produces ICMP Time Exceeded and supports traceroute.
- Protocol 1 is ICMP, 6 is TCP, 17 is UDP, and 47 is GRE.
- The IPv4 checksum covers only the header, and routers recalculate it after changing TTL.
- Routers primarily forward using the destination IP address, while Layer 2 addresses change at each hop.
For related foundations, review the OSI Reference Model, computer network fundamentals, and OSPF configuration and routing.