Nmap online course

Understanding the IPv4 Header

Learn the IPv4 header fields, fragmentation, TTL, protocol values, checksums, options, packet captures, and their relationship to Nmap diagnostics.

An IPv4 datagram is a network-layer packet made of an IPv4 header followed by a payload. The header tells routers and receiving hosts how to forward, limit, fragment, validate, and deliver the packet.

The payload may contain a TCP segment, a UDP datagram, an ICMP message, a GRE packet, or data for another protocol. TCP and UDP ports, HTTP data, and similar upper-layer information are not IPv4-header fields; they appear inside the IPv4 payload after the appropriate transport or encapsulated protocol header.

Every IPv4 datagram has a fixed 20-byte base header. Optional IPv4 options can extend the header to a maximum of 60 bytes. The Internet Header Length (IHL) field tells the receiver where the payload begins.

IPv4 Header Layout

IPv4 fields appear in the following wire order. The first 32-bit row contains the 4-bit Version field, the 4-bit IHL field, and the 8-bit Differentiated Services field, followed by the 16-bit Total Length field.

Version and Internet Header Length

Version is a 4-bit field. Its value is 4 in an IPv4 datagram.

IHL is also 4 bits, but it does not count bytes directly. It counts 32-bit words, with each word equal to 4 bytes. The base header is 5 words:

Header length = IHL × 4 bytes

• IHL = 5 means 5 × 4 = 20 bytes, so no options are present.
• IHL = 7 means 7 × 4 = 28 bytes, so 8 bytes are occupied by options and padding.
• IHL = 15 means 15 × 4 = 60 bytes, the largest IPv4 header.

An IHL value greater than 5 means that the receiver must inspect the options area before interpreting the payload.

Differentiated Services

The 8-bit field after IHL was historically called Type of Service (ToS). Modern IPv4 uses it as the Differentiated Services field, often displayed as DS or DSCP/ECN.

• DSCP occupies the first 6 bits. The Differentiated Services Code Point marks traffic classes and can influence forwarding behavior, such as queue selection.
• ECN occupies the final 2 bits. Explicit Congestion Notification allows congestion to be signaled without necessarily dropping the packet.

Older documentation and some capture tools may show priority or precedence terminology. That terminology describes historical ToS interpretations and should not be confused with the complete modern DSCP/ECN interpretation.

Total Length and Payload Size

Total Length is a 16-bit value containing the complete IPv4 datagram length in bytes. It includes the IPv4 header and its payload. Valid IPv4 values range from 20 bytes to 65,535 bytes.

IPv4 payload length = Total Length − IPv4 header length

For example, if Total Length is 60 and IHL is 5, the header is 20 bytes and the payload is 40 bytes. If the payload is TCP, a 20-byte TCP header would leave 20 bytes for application data.

Total Length is not the same as the maximum packet size supported by a link. That link limit is its Maximum Transmission Unit (MTU). A path may contain links with different MTUs, so a datagram that is valid under the IPv4 maximum can still be too large for the next hop.

Fragmentation and Reassembly

IPv4 fragmentation can occur when a datagram is larger than the next-hop MTU. A router may divide the datagram into fragments, each with its own IPv4 header. The receiving host later reassembles the fragments into the original datagram.

The 16-bit Identification value associates fragments from one original datagram. Reassembly also uses the source address, destination address, and Protocol field, along with each fragment's offset, length, and flags. The first fragment has offset 0. Later fragments have positive offsets.

The Flags field has three bits:

• The first bit is reserved and must remain zero.
• DF, or Don't Fragment, requests that routers not fragment the datagram.
• MF, or More Fragments, indicates that more fragments follow. The final fragment has MF clear.

Fragment Offset identifies the position of a fragment's payload within the original payload. Its units are 8 bytes, so an offset value of 100 represents a position of 800 bytes.

If DF is set and a router cannot forward the datagram across a smaller-MTU link, the router discards it rather than fragmenting it. In IPv4 Path MTU Discovery, the router commonly sends an ICMP Destination Unreachable message indicating fragmentation is needed. If that ICMP feedback is blocked, large packets may fail while smaller packets continue to work.

Fragmentation is generally undesirable because it adds processing, increases the effect of fragment loss, complicates security inspection, and makes troubleshooting more difficult. Tunnels and misconfigured MTUs are common reasons fragmentation or fragmentation-related failures appear.

Time To Live

Time To Live (TTL) is an 8-bit hop limit. It prevents a routing loop from allowing a packet to circulate indefinitely.

Each forwarding router decreases TTL by at least one. When the value reaches zero, the router discards the packet and commonly sends an ICMP Time Exceeded message to the apparent source.

Traceroute-style tools exploit this behavior. They send probes with increasing TTL values. A probe that expires at the first router reveals that router's address through an ICMP Time Exceeded response; a larger TTL allows the probe to reach a later hop.

An observed initial TTL, such as 64 or 128, can sometimes suggest an operating-system or network-stack convention. It is not definitive fingerprinting evidence because devices can change the value, routes can alter the observed value, and many systems use similar defaults.

Protocol Field and Encapsulation

The 8-bit Protocol field identifies the next protocol carried in the IPv4 payload. This is an example of encapsulation: one protocol places another protocol's data inside its payload.

The Protocol field is not a port number. For example, Protocol 6 tells a decoder to interpret the payload as TCP. The TCP header that follows contains TCP source and destination ports. Similarly, Protocol 17 identifies UDP, whose following header contains UDP ports.

IPv4 Header Checksum

The IPv4 header checksum detects errors in the IPv4 header. It does not protect the payload. Transport protocols have their own checksums, and link layers may have separate frame checksums; these checksums cover different data and are not replacements for understanding the IPv4 checksum.

Conceptually, checksum calculation works as follows:

1. Set the checksum field to zero for calculation.
2. Split the header into 16-bit words.
3. Add the words using one's-complement addition, including end-around carry.
4. Take the one's complement of the result and place it in the checksum field.

Routers change fields such as TTL while forwarding. Because the header has changed, the router must update or recalculate the IPv4 header checksum. A receiver or router that detects a checksum failure discards the packet.

Source and Destination Addresses

Source and destination addresses are each 32-bit IPv4 values, commonly written as four decimal octets such as 192.0.2.10. The source address identifies the apparent sender, while the destination address identifies the intended receiver.

Routers primarily use the destination address and their forwarding tables to select the next hop. The source address is important for replies, filtering, accounting, and diagnostics, but it is not automatically proof of the sender's identity. Source-address spoofing can make a packet appear to come from another address.

Options and Padding

IPv4 options appear after the fixed 20-byte header when IHL is greater than 5. Examples include record route, timestamp, router alert, end of option list, and no operation.

Options have variable length. Padding adds any required bytes so that the complete header ends on a 32-bit boundary. The combined options and padding area can occupy up to 40 bytes.

Options are uncommon in ordinary traffic. Some devices filter them, ignore them, or process them on a slower path. They may be useful for diagnostics, but they can also raise performance, compatibility, and security-inspection concerns.

Reading an IPv4 Header in a Capture

A Wireshark or tshark decode may show values similar to the following:

Internet Protocol Version 4
    Version: 4
    Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00
    Total Length: 60
    Identification: 0x1234
    Flags: 0x2, Don't Fragment
    Fragment Offset: 0
    Time to Live: 128
    Protocol: TCP (6)
    Header Checksum: valid
    Source Address: 192.0.2.10
    Destination Address: 198.51.100.20

Interpret this packet in wire order:

1. Version 4 confirms that the packet is IPv4.
2. Header Length 20 bytes means IHL is 5 and no options are present.
3. Total Length 60 means the IPv4 payload is 60 − 20 = 40 bytes.
4. Protocol 6 means the payload begins with a TCP header. TCP ports must be read from that following header.
5. TTL 128 is the current hop limit, not necessarily the original value if the packet has crossed routers.
6. DF is set and the offset is zero, so this packet is not a fragment and routers are asked not to fragment it.

For a UDP packet, Protocol would commonly be 17. Its UDP source and destination ports would likewise appear only after decoding the UDP header.

Capture Commands

To capture and decode IPv4 traffic with tshark, use an authorized interface:

tshark -i <interface> -f "ip" -V

To display selected IPv4 fields from an existing capture:

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

Field names can vary slightly by tshark version. If a field is blank, inspect a verbose decode to confirm the analyzer's exact name.

Checksum Offloading Artifacts

A capture made on the sending host can show an apparently invalid IPv4 checksum even when the packet is transmitted correctly. Network-interface checksum offloading may calculate the final checksum in hardware after the operating system capture point sees the packet.

Compare with a capture from another host, a network tap, or the receiving host. Do not conclude that a packet is corrupt solely from a local outbound checksum warning when offloading explains the result.

Troubleshooting IPv4 Behavior

Large Packets Fail but Smaller Packets Work

• Check for a smaller path MTU, especially through tunnels.
• Inspect whether DF prevents fragmentation.
• Look for ICMP fragmentation-needed feedback.
• Test progressively smaller payloads and review interface MTU settings.

Reassembly Warnings or Incomplete Application Data

• Look for missing fragments, out-of-order arrival, or fragment loss.
• Match source, destination, Protocol, and Identification values.
• Check MF and Fragment Offset values.
• Ensure the capture filter did not exclude related fragments.

A Traceroute-Style Probe Stops at One Hop

• Check whether ICMP Time Exceeded responses are filtered or rate-limited.
• Compare authorized probes using different transport protocols.
• Do not treat a missing response as proof that the route ends at that device.

A Service Is Not Identified from Protocol Alone

Protocol 6 identifies TCP and Protocol 17 identifies UDP, but neither identifies a service or port. Decode the subsequent TCP or UDP header and inspect its source and destination ports.

IPv4 Headers and Nmap

Nmap crafts, sends, and interprets IP packets for host discovery, port scanning, operating-system detection, and path analysis. IPv4 header behavior helps explain how Nmap interprets TTL values, Protocol values, fragmentation, DF handling, and ICMP responses.

For example, a scan can report why a port was classified a certain way, trace packet exchanges, or help investigate a path where MTU and ICMP behavior affect results. Use packet crafting, scanning, and capture commands only on systems and networks you own or are explicitly authorized to test.

nmap --reason -Pn -p 80,443 <authorized-target>
nmap --packet-trace -Pn -p 80 <authorized-target>

Related lessons include Nmap packet tracing, the reason flag, operating-system detection, and TCP and UDP ports.

Useful Diagnostic Commands

To observe ICMP traffic during TTL or path testing:

tcpdump -ni <interface> icmp

To observe route hops using increasing TTL values:

traceroute -n <destination>

These commands show symptoms and responses; a complete diagnosis still requires checking MTU, filtering, routing policy, and capture location.

Exam-Relevant Summary

• IPv4 consists of a header followed by a payload; the base header is 20 bytes and the maximum header is 60 bytes.
• IHL counts 32-bit words: IHL 5 is 20 bytes, and IHL 15 is 60 bytes.
• Total Length includes both the IPv4 header and payload.
• Payload length equals Total Length minus the actual IHL-derived header length.
• DSCP uses 6 bits and ECN uses 2 bits in the Differentiated Services field.
• Identification, Flags, and Fragment Offset support fragmentation and reassembly.
• Fragment Offset is measured in 8-byte units.
• TTL limits hops and can produce ICMP Time Exceeded messages used by traceroute.
• Protocol 1 is ICMP, 6 is TCP, 17 is UDP, and 47 is GRE.
• TCP and UDP ports are not in the IPv4 header.
• The IPv4 checksum covers only the IPv4 header, and routers update it after changing TTL.
• Source addresses can be spoofed, so they are not conclusive proof of identity.