ICMP Overview: The Internet's Feedback Mechanism

While ICMP error messages are generated reactively when problems occur, ICMP also defines a category of messages that work proactively—allowing hosts and routers to actively query the network for information.

These query messages follow a request/reply model: a host sends a specific question, and the target (or intermediate routers) responds with an answer. This enables essential diagnostic capabilities that every network engineer relies upon.

The most famous query message is undoubtedly the Echo Request/Reply pair—better known as ping. But ICMP's query arsenal extends beyond connectivity testing to include time synchronization, network configuration discovery, and router identification. Understanding these messages transforms ICMP from an abstract protocol into a powerful diagnostic toolkit.

Before diving into specific query types, let's clearly distinguish ICMP's two fundamental message categories. This distinction affects how messages are generated, processed, and secured.

Error Messages (Unsolicited)

Error messages are generated automatically when something goes wrong with packet delivery. The sender never "asked" for these messages—they appear unexpectedly when routers or hosts encounter problems. Error messages are unsolicited and reactive.

Query Messages (Solicited)

Query messages follow a request/reply pattern where one host actively sends a query and expects a specific response. The reply is meaningless without the original request, and request/reply pairs share identification fields. Query messages are solicited and proactive.

Matching Requests to Replies

Query messages use two fields to correlate requests with replies:

Identifier (16 bits): Typically the process ID of the application sending the query. This allows multiple simultaneous ping processes on the same host to distinguish their responses.

Sequence Number (16 bits): Incremented for each request sent. This allows the sender to detect lost packets, out-of-order responses, and duplicate replies.

When a host receives an Echo Request, it sends an Echo Reply with the identical Identifier and Sequence Number. The sender uses these to match the reply to the original request, calculate round-trip time, and detect loss.

The Echo Request (Type 8) and Echo Reply (Type 0) messages form the foundation of the ping utility—perhaps the most widely used network diagnostic tool in existence. Their simplicity belies their power: a single ping can reveal host reachability, network latency, packet loss, and routing path stability.

Operational Principle

Echo works on a simple contract:

1. Source sends Echo Request (Type 8, Code 0) to a target IP address
2. Target receives the request and prepares a reply
3. Target sends Echo Reply (Type 0, Code 0) back to the source
4. Source receives reply and calculates round-trip time

The key requirement: any data in the Request must be returned unchanged in the Reply. This allows applications to embed checksums, timestamps, or patterns to verify data integrity and measure precise timing.

Echo Message Structure

Echo Request and Echo Reply share identical structures (differing only in the Type field):

What Ping Reveals

A successful ping exchange provides rich diagnostic information:

1. Reachability: Receiving a reply confirms end-to-end connectivity. The packet traversed all routers and the destination host is alive.

2. Round-Trip Time (RTT): Time from sending request to receiving reply measures network latency. Ping typically shows minimum, average, and maximum RTT.

3. Packet Loss: Unanswered requests indicate loss somewhere in the path. Could be congestion, filtering, or failures.

4. TTL in Response: The TTL value in the reply indicates remaining hops. Original TTL minus reply TTL gives approximate distance. Also reveals OS (Linux=64, Windows=128, Cisco=255).

5. Jitter: Variance in RTT over multiple pings indicates network stability. High jitter suggests congestion or routing instability.

6. Data Integrity: If ping includes meaningful data patterns, matching validates that no corruption occurred in transit.

Beyond basic connectivity testing, Echo Request/Reply enables sophisticated diagnostic techniques. Understanding these transforms ping from a simple yes/no tool into a powerful network analyzer.

Technique 1: MTU Discovery via Ping

By sending Echo Requests with the Don't Fragment (DF) flag and varying sizes, you can discover the Path MTU:

1. Start with large packet (e.g., 1500 bytes)
2. If successful, path supports this MTU
3. If ICMP "Fragmentation Needed" returned, reduce size
4. Binary search to find exact PMTU

This is faster than waiting for TCP's PMTUD and useful for diagnosing "connection works but large transfers fail" problems.

Technique 2: Flood Ping for Stress Testing

Flood ping sends Echo Requests as fast as possible without waiting for replies. This tests:

• Network capacity under sustained load
• Router/host packet processing limits
• Buffering and queuing behavior

Caution: Flood ping can constitute a denial-of-service attack. Only use on networks you own/control with proper authorization.

Technique 3: Record Route and Source Route

Some ping implementations can use IP Options to record the route taken or specify a source route. While deprecated for security reasons, understanding the concept aids protocol comprehension.

Technique 4: Continuous Monitoring

Running ping continuously (no count limit) creates a simple availability monitor:

• Log output to file
• Analyze for patterns (time-of-day issues, periodic drops)
• Trigger alerts on loss threshold

Tools like fping and smokeping build on this for production monitoring.

ICMP Timestamp Request (Type 13) and Timestamp Reply (Type 14) were designed for measuring network transit times with greater precision than Echo. While largely obsoleted by NTP for time synchronization, understanding these messages provides insight into network timing measurement.

Purpose and Operation

Timestamp messages contain three timestamp fields:

1. Originate Timestamp: Set by sender when transmitting the request
2. Receive Timestamp: Set by recipient when receiving the request
3. Transmit Timestamp: Set by recipient when sending the reply

By comparing these values, the source can calculate:

• One-way delay (if clocks are synchronized)
• Processing time at the destination
• Network asymmetry (different send vs. receive paths)

Calculating Delays

Given the three timestamps, the source can compute:

Round-Trip Time = (Arrival of Reply − Originate) − (Transmit − Receive)

Forward Delay = Receive − Originate (requires synchronized clocks)

Backward Delay = Arrival of Reply − Transmit (requires synchronized clocks)

Processing Time = Transmit − Receive (time spent at destination)

Why Timestamp is Rarely Used Today

Timestamp messages have significant limitations:

ICMP Address Mask Request (Type 17) and Address Mask Reply (Type 18) were designed for diskless workstations and similar devices that boot without knowing their subnet mask. A host would broadcast an Address Mask Request, and routers would respond with the appropriate subnet mask.

Historical Context

In early networking, hosts often obtained their IP address via RARP (Reverse ARP) or BOOTP, but these protocols didn't always provide subnet mask information. ICMP Address Mask filled this gap, allowing hosts to learn their subnet configuration after obtaining an IP address.

Message Format

Why Address Mask is Obsolete

This mechanism is rarely used today for several reasons:

ICMP Router Advertisement (Type 9) and Router Solicitation (Type 10) implement ICMP Router Discovery Protocol (IRDP), defined in RFC 1256. This mechanism allows hosts to discover local routers without static configuration.

Operational Model

1. Routers periodically broadcast/multicast Router Advertisement messages announcing their presence and IP addresses
2. Hosts listen for these advertisements and build a list of available routers
3. Hosts can also send Router Solicitation to request immediate advertisements (instead of waiting for periodic broadcast)
4. Hosts select a default gateway from advertised routers, often based on preference level
5. If a router becomes unavailable, hosts detect this through missing advertisements and switch to alternatives

Preference Level

Routers can advertise a preference level to influence which router hosts select as their default gateway. Use cases include:

• Primary/Backup routing: Primary router advertises higher preference
• Load distribution: Equal preferences cause hosts to select randomly
• Temporary maintenance: Lower preference before taking router offline

Preference is a signed 32-bit integer where higher = more preferred. Typical values:

• 0x7FFFFFFF (max): Strongly preferred
• 0: Default/neutral
• 0x80000000 (min): Use only if nothing else available

Why IRDP is Rarely Used

While IRDP provides automatic gateway discovery, it has been largely supplanted:

ICMP Information Request (Type 15) and Information Reply (Type 16) are formally obsolete and included here only for completeness and understanding historical context.

Original Purpose

In the early ARPANET, hosts sometimes knew only their network number but needed to determine their complete IP address. Information Request/Reply was designed for a host to ask "what is my full IP address?"—sending a request with just the network portion, hoping a router would respond with the complete address.

Why This Never Worked Well

The design had fundamental problems:

1. The host already needed some address to send/receive—circular dependency
2. No mechanism to determine which reply was authoritative
3. Security was non-existent—anyone could respond
4. RARP, BOOTP, and eventually DHCP solved this problem properly

Current Status

• Officially obsolete per RFC 6918
• No major OS has generated these since the 1980s
• Firewalls should drop these (but likely never see them)
• Included in curricula only for protocol completeness

Understanding why Information Request failed helps appreciate why DHCP's designed succeeded—it provides all necessary configuration (IP, mask, gateway, DNS) from an authoritative server in a single, authenticated transaction.

ICMP query messages provide proactive diagnostic capabilities, allowing hosts to actively interrogate the network rather than passively waiting for error reports. We've explored all major query types:

What's Next

We've now covered both ICMP error messages and query messages. Next, we'll examine ICMP encapsulation—how ICMP messages are packaged within IP packets, their relationship to the IP header, and how ICMP travels through networks. Understanding this encapsulation is crucial for packet analysis and firewall rule configuration.