ICMP Types in the IPv4 Packet Header: A Field-by-Field Guide

Posted on by

An IPv4 packet that carries ICMP is read from the outside in: first the IPv4 packet header, then the ICMP message selected by the IPv4 protocol field. The outer header shows how the datagram is identified, routed, fragmented, and checked for integrity; the ICMP header explains whether the message is an echo request, unreachable notice, time exceeded error, or redirect.

ICMP does not use transport-layer ports. Instead, the combination of IPv4 header fields and the ICMP type and code values tells a packet analyst what happened and where the message begins.

IPv4 packet and header layout

Version, IHL, total length, and identification

The first 20 bytes of an IPv4 header contain the fixed fields. The version field is 4 for IPv4. The IHL field, or Internet Header Length, states how many 32-bit words make up the header. A value of 5 means a 20-byte header, which is the minimum size.

Total length gives the size of the entire IPv4 datagram in bytes, including the header and payload. This matters because the ICMP message sits inside that payload. The identification field labels fragments that belong to the same original datagram, so a receiver can put them back together if fragmentation occurs.

A simple packet example looks like this:

  • Version: 4
  • IHL: 5
  • Total length: 84 bytes
  • Identification: 0x3a2f

In that example, the IPv4 header is 20 bytes long, so the next 64 bytes are payload. If the protocol field says ICMP, those 64 bytes begin with an ICMP header and then ICMP data.

Flags, fragment offset, TTL, protocol, checksum, and addresses

The flags field contains three bits. One is reserved, one is DF for “don’t fragment,” and one is MF for “more fragments.” The fragment offset tells where this fragment belongs in the original packet, measured in 8-byte units. A non-fragmented packet has a fragment offset of 0 and MF clear.

TTL, or time to live, limits how long the packet may travel. Each router reduces TTL by one. When TTL reaches zero, the router discards the packet and often sends back an ICMP time exceeded message. The protocol field names the upper-layer payload; a value of 1 means ICMP. The header checksum protects only the IPv4 header, not the payload. It is recomputed whenever a router changes a header field such as TTL.

The source address and destination address identify the sender and intended receiver. Together with the protocol value, they tell a decoder where the packet came from, where it is going, and what parser should read the next bytes.

Header length and variable fields

How IHL sets the header size

IHL is the key to finding the start of the payload. Because it counts 32-bit words, the header size is:

  • IHL 5 = 20 bytes
  • IHL 6 = 24 bytes
  • IHL 7 = 28 bytes

If IHL is greater than 5, the IPv4 header includes options. That means the ICMP message starts after the larger header, not immediately after byte 20. A packet capture tool or manual decode must use IHL rather than assume a fixed boundary.

How options extend the header

Options are variable-length fields that extend the IPv4 header. They are uncommon in routine traffic, but when present they can carry features such as record route, timestamp, or source route information. Options must be padded so the full header still ends on a 32-bit boundary.

For ICMP analysis, options matter because they shift the start of the ICMP message. A packet with IHL 6 begins ICMP at byte 24; a packet with IHL 7 begins ICMP at byte 28. The protocol field still points to ICMP, but the offset is different.

How fragmentation fields work

Fragmentation uses the identification, flags, and fragment offset fields together. The sender or a router may split a large IPv4 datagram into fragments when the path MTU is smaller than the packet size, unless DF is set. All fragments of the same original packet share the same identification value, but each fragment has its own offset and MF setting.

For example, if an original packet is broken into three fragments, the first two fragments usually have MF set, while the last fragment has MF clear. The fragment offsets show where each piece belongs. If a packet is not fragmented, the offset is 0 and the full ICMP payload begins right after the IPv4 header.

How IPv4 identifies ICMP

Protocol field 1 points to ICMP

In the ipv4 header fields, the protocol number is the switch that chooses the next decoder. A value of 1 means the payload is ICMP. That is how IPv4 marks an icmp type message without using ports or transport-layer session data.

When protocol equals 1, the receiver does not look for TCP or UDP headers. It reads the next bytes as ICMP. The first three ICMP fields are usually type, code, and checksum. After that, the rest of the ICMP structure depends on the message class.

Where the ICMP message begins

The ICMP message begins immediately after the IPv4 header, so the start point depends on IHL. In a standard 20-byte IPv4 header, ICMP starts at byte 20. If options extend the IPv4 header, ICMP starts later.

Many ICMP error messages include part of the packet that caused the error: the original IPv4 header and the first 8 bytes of the original payload. That embedded data helps identify the flow that triggered the ICMP message. For example, a destination unreachable packet can point back to the exact datagram that could not be forwarded.

ICMP types in an IPv4 packet header

Echo request and reply: types 8 and 0

Echo messages are the most familiar ICMP packets. Type 8, code 0 is an echo request. Type 0, code 0 is an echo reply. These are the messages used by tools such as ping.

Example interpretation: an IPv4 packet shows version 4, IHL 5, total length 84, TTL 64, protocol 1, and a valid header checksum. The ICMP header begins at byte 20 and says type 8, code 0. That packet is an echo request. If the reply returns with type 0, code 0, the destination answered.

Echo messages often carry an identifier and sequence number after the ICMP header. Those values help match a reply to the request, but they are still ICMP fields, not ports.

Destination unreachable: type 3 and common codes

Type 3 means destination unreachable. The code narrows the reason for failure. Common codes include 0 network unreachable, 1 host unreachable, 3 port unreachable, and 4 fragmentation needed and DF set.

Example interpretation: an IPv4 packet has protocol 1 and an ICMP message with type 3, code 4. The router could not forward the datagram without fragmenting it, but the DF flag was set. In that case, the ICMP message may also include the next-hop MTU value so the sender can reduce packet size.

Another example: type 3, code 1 indicates the destination host could not be reached on the local network or routed path. The embedded original header usually identifies which traffic failed, especially when multiple flows are active.

Time exceeded: type 11 and common codes

Type 11 means time exceeded. The two common codes are 0 for TTL exceeded in transit and 1 for fragment reassembly time exceeded.

Example interpretation: a packet leaves with TTL 1, protocol 1, and an ICMP payload intended for a distant host. The first router decrements TTL to 0, discards the packet, and returns an ICMP type 11, code 0 message. That is the standard packet-level signature behind traceroute-style path discovery.

Fragment reassembly time exceeded is less common. It means fragments arrived, but the receiver waited too long for the full set before reassembling the original datagram.

Redirect: type 5 and common codes

Type 5 is redirect. It tells a host that a better next hop exists for a destination. Common codes are 0 network redirect, 1 host redirect, 2 network redirect for type of service, and 3 host redirect for type of service.

Example interpretation: a router on the local subnet receives a packet from a host and knows a more efficient path to the same destination through another gateway. It sends ICMP type 5, code 1, along with the suggested gateway address. The packet still sits inside an IPv4 datagram with protocol 1, but the ICMP meaning is a routing hint rather than a delivery failure.

When reading any ICMP packet inside the ipv4 packet header structure, the useful sequence is the same: confirm version 4, use IHL to find the ICMP start, read protocol 1, then decode the ICMP type and code to identify the event.