Community hub
0 subscribers7 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Internet Control Message Protocol.
Nothing was collected or created yet.
Internet Control Message Protocol
View on Wikipediafrom Wikipedia
| Communication protocol | |
 A general header for ICMPv4 | |
| Purpose | Auxiliary protocol for IPv4[1]: 52 |
|---|---|
| Developer(s) | DARPA |
| Introduction | 1981 |
| OSI layer | Network layer |
| RFC(s) | 792 |
The Internet Control Message Protocol (ICMP) is a supporting protocol[2] in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address. For example, an error is indicated when a requested service is not available or that a host or router could not be reached.[3] ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications (with the exception of some diagnostic tools like ping and traceroute).
A separate Internet Control Message Protocol (called ICMPv6) is used with IPv6.[4]
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
Technical details
[edit]ICMP is part of the Internet protocol suite as defined in RFC 792. ICMP messages are typically used for diagnostic or control purposes or generated in response to errors in IP operations (as specified in RFC 1122). ICMP errors are directed to the source IP address of the originating packet.[3]
For example, every device (such as an intermediate router) forwarding an IP datagram first decrements the time to live (TTL) field in the IP header by one. If the resulting TTL is 0, the packet is discarded and an ICMP time exceeded message is sent to the datagram's source address.
Many commonly used network utilities are based on ICMP messages. The traceroute command can be implemented by transmitting IP datagrams with specially set IP TTL header fields, and looking for ICMP time exceeded in transit and destination unreachable messages generated in response. The related ping utility is implemented using the ICMP echo request and echo reply messages.
ICMP uses the basic support of IP as if it were a higher-level protocol, however, ICMP is actually an integral part of IP. Although ICMP messages are contained within standard IP packets, ICMP messages are usually processed as a special case, distinguished from normal IP processing. In many cases, it is necessary to inspect the contents of the ICMP message and deliver the appropriate error message to the application responsible for transmitting the IP packet that prompted the ICMP message to be sent.
ICMP is a network-layer protocol; this makes it a layer 3 protocol in the seven-layer OSI model. Based on the four-layer TCP/IP model, ICMP is an internet-layer protocol, which makes it a layer 2 protocol in the Internet Standard RFC 1122 TCP/IP four-layer model or a layer 3 protocol in the modern five-layer TCP/IP protocol definitions (by Kozierok, Comer, Tanenbaum, Forouzan, Kurose, Stallings).[citation needed]
There is no port number associated with an ICMP packet, as these numbers are associated with protocols in the transport layer above, such as TCP and UDP.[5]
Datagram structure
[edit]The ICMP packet is encapsulated in an IPv4 packet.[3] The packet consists of header and data sections.
Header
[edit]The ICMP header starts after the IPv4 header and is identified by its protocol number, 1.[6] All ICMP packets have an eight-byte header and variable-sized data section. The first four bytes of the header have fixed format, while the last four bytes depend on the type and code of the ICMP packet.[3]
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Type | Code | Checksum | |||||||||||||||||||||||||||||
| 4 | 32 | Rest of Header | |||||||||||||||||||||||||||||||
- Type: 8 bits
- ICMP type, see § Control messages.
- Code: 8 bits
- ICMP subtype, see § Control messages.
- Checksum: 16 bits
- Internet checksum[7] for error checking, calculated from the ICMP header and data with value 0 substituted for this field.
- Rest of Header: 32 bits
- Four-byte field, contents vary based on the ICMP type and code.
Data
[edit]ICMP error messages contain a data section that includes a copy of the entire IPv4 header, plus at least the first eight bytes of data from the IPv4 packet that caused the error message. The length of ICMP error messages should not exceed 576 bytes.[1] This data is used by the host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first eight bytes of the original datagram's data.[2]
The variable size of the ICMP packet data section has been exploited. In the "Ping of death", large or fragmented ICMP packets are used for denial-of-service attacks. ICMP data can also be used to create covert channels for communication. These channels are known as ICMP tunnels.
Control messages
[edit]Control messages are identified by the value in the type field. The code field gives additional context information for the message. Some control messages have been deprecated since the protocol was first introduced.
| Type | Code | Status | Description |
|---|---|---|---|
| 0 – Echo Reply[2]: 14 | 0 | Echo reply (used to ping) | |
| 1 and 2 | unassigned | Reserved | |
| 3 – Destination Unreachable[2]: 4 [8] | 0 | Destination network unreachable | |
| 1 | Destination host unreachable | ||
| 2 | Destination protocol unreachable | ||
| 3 | Destination port unreachable | ||
| 4 | Fragmentation required, and DF flag set | ||
| 5 | Source route failed | ||
| 6 | Destination network unknown | ||
| 7 | Destination host unknown | ||
| 8 | Source host isolated | ||
| 9 | Network administratively prohibited | ||
| 10 | Host administratively prohibited | ||
| 11 | Network unreachable for ToS | ||
| 12 | Host unreachable for ToS | ||
| 13 | Communication administratively prohibited | ||
| 14 | Host Precedence Violation | ||
| 15 | Precedence cutoff in effect | ||
| 4 – Source Quench | 0 | Source quench (congestion control) | |
| 5 – Redirect Message | 0 | Redirect Datagram for the Network | |
| 1 | Redirect Datagram for the Host | ||
| 2 | Redirect Datagram for the ToS & network | ||
| 3 | Redirect Datagram for the ToS & host | ||
| 6 | Alternate Host Address | ||
| 7 | unassigned | Reserved | |
| 8 – Echo Request | 0 | Echo request (used to ping) | |
| 9 – Router Advertisement | 0 | Router Advertisement | |
| 10 – Router Solicitation | 0 | Router discovery/selection/solicitation | |
| 11 – Time Exceeded[2]: 6 | 0 | Time to live (TTL) expired in transit | |
| 1 | Fragment reassembly time exceeded | ||
| 12 – Parameter Problem: Bad IP header | 0 | Pointer indicates the error | |
| 1 | Missing a required option | ||
| 2 | Bad length | ||
| 13 – Timestamp | 0 | Timestamp | |
| 14 – Timestamp Reply | 0 | Timestamp reply | |
| 15 – Information Request | 0 | Information Request | |
| 16 – Information Reply | 0 | Information Reply | |
| 17 – Address Mask Request | 0 | Address Mask Request | |
| 18 – Address Mask Reply | 0 | Address Mask Reply | |
| 19 | unassigned | Reserved for security | |
| 20 through 29 | unassigned | Reserved for robustness experiment | |
| 30 – Traceroute | 0 | Information Request | |
| 31 | Datagram Conversion Error | ||
| 32 | Mobile Host Redirect | ||
| 33 | Where-Are-You (originally meant for IPv6) | ||
| 34 | Here-I-Am (originally meant for IPv6) | ||
| 35 | Mobile Registration Request | ||
| 36 | Mobile Registration Reply | ||
| 37 | Domain Name Request | ||
| 38 | Domain Name Reply | ||
| 39 | SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol | ||
| 40 | Photuris, Security failures | ||
| 41 | Experimental | ICMP for experimental mobility protocols such as Seamoby.[12] | |
| 42 – Extended Echo Request[13] | 0 | Request Extended Echo | |
| 43 – Extended Echo Reply[13] | 0 | No Error | |
| 1 | Malformed Query | ||
| 2 | No Such Interface | ||
| 3 | No Such Table Entry | ||
| 4 | Multiple Interfaces Satisfy Query | ||
| 44 through 252 | unassigned | Reserved | |
| 253 | Experimental | RFC3692-style Experiment 1[14] | |
| 254 | Experimental | RFC3692-style Experiment 2[14] | |
| 255 | unassigned | Reserved |
Source quench
[edit]Source Quench requests that the sender decrease the rate of messages sent to a router or host. This message may be generated if a router or host does not have sufficient buffer space to process the request, or may occur if the router or host buffer is approaching its limit.
Data is sent at a very high speed from a host or from several hosts at the same time to a particular router on a network. Although a router has buffering capabilities, the buffering is limited to within a specified range. The router cannot queue any more data than the capacity of the limited buffering space. Thus if the queue gets filled up, incoming data is discarded until the queue is no longer full. But as no acknowledgement mechanism is present in the network layer, the client does not know whether the data has reached the destination successfully. Hence some remedial measures should be taken by the network layer to avoid these kind of situations. These measures are referred to as source quench.
In a source quench mechanism, the router sees that the incoming data rate is much faster than the outgoing data rate, and sends an ICMP message to the clients, informing them that they should slow down their data transfer speeds or wait for a certain amount of time before attempting to send more data. When a client receives this message, it automatically slows down the outgoing data rate or waits for a sufficient amount of time, which enables the router to empty the queue. Thus the source quench ICMP message acts as flow control in the network layer.
Since research suggested that "ICMP Source Quench [was] an ineffective (and unfair) antidote for congestion",[10] routers' creation of source quench messages was deprecated in 1995 by RFC 1812. Furthermore, forwarding of and any kind of reaction to (flow control actions) source quench messages was deprecated from 2012 by RFC 6633.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 4 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
| unused | |||||||||||||||||||||||||||||||
| IP header and first 8 bytes of original datagram's data | |||||||||||||||||||||||||||||||
Where:
- Type must be set to 4
- Code must be set to 0
- IP header and additional data is used by the sender to match the reply with the associated request
Redirect
[edit]
Redirect requests data packets be sent on an alternative route. ICMP Redirect is a mechanism for routers to convey routing information to hosts. The message informs a host to update its routing information (to send packets on an alternative route). If a host tries to send data through a router (R1) and R1 sends the data on another router (R2) and a direct path from the host to R2 is available (that is, the host and R2 are on the same subnetwork), then R1 will send a redirect message to inform the host that the best route for the destination is via R2. The host should then change its route information and send packets for that destination directly to R2. The router will still send the original datagram to the intended destination.[15] However, if the datagram contains routing information, this message will not be sent even if a better route is available. RFC 1122 states that redirects should only be sent by gateways and should not be sent by Internet hosts.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 5 | Code | Checksum | |||||||||||||||||||||||||||||
| IP address | |||||||||||||||||||||||||||||||
| IP header and first 8 bytes of original datagram's data | |||||||||||||||||||||||||||||||
Where:
- Type must be set to 5.
- Code specifies the reason for the redirection, and may be one of the following:
Code Description 0 Redirect for Network 1 Redirect for Host 2 Redirect for Type of Service and Network 3 Redirect for Type of Service and Host
- IP address is the 32-bit address of the gateway to which the redirection should be sent.
- IP header and additional data is included to allow the host to match the reply with the request that caused the redirection reply.
Time exceeded
[edit]Time Exceeded is generated by a gateway to inform the source of a discarded datagram due to the time to live field reaching zero. A time exceeded message may also be sent by a host if it fails to reassemble a fragmented datagram within its time limit.
Time exceeded messages are used by the traceroute utility to identify gateways on the path between two hosts.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 11 | Code | Checksum | |||||||||||||||||||||||||||||
| unused | |||||||||||||||||||||||||||||||
| IP header and first 8 bytes of original datagram's data | |||||||||||||||||||||||||||||||
Where:
- Type must be set to 11
- Code specifies the reason for the time exceeded message, include the following:
Code Description 0 Time-to-live exceeded in transit. 1 Fragment reassembly time exceeded.
- IP header and first 64 bits of the original payload are used by the source host to match the time exceeded message to the discarded datagram. For higher-level protocols such as UDP and TCP the 64-bit payload will include the source and destination ports of the discarded packet.
Timestamp
[edit]Timestamp is used for time synchronization. The originating timestamp is set to the time (in milliseconds since midnight) the sender last touched the packet. The receive and transmit timestamps are not used.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 13 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
| Identifier | Sequence number | ||||||||||||||||||||||||||||||
| Originate timestamp | |||||||||||||||||||||||||||||||
| Receive timestamp | |||||||||||||||||||||||||||||||
| Transmit timestamp | |||||||||||||||||||||||||||||||
Where:
- Type must be set to 13
- Code must be set to 0
- Identifier and Sequence Number can be used by the client to match the timestamp reply with the timestamp request.
- Originate timestamp is the number of milliseconds since midnight Universal Time (UT). If a UT reference is not available the most-significant bit can be set to indicate a non-standard time value.
Timestamp reply
[edit]Timestamp Reply replies to a Timestamp message. It consists of the originating timestamp sent by the sender of the Timestamp as well as a receive timestamp indicating when the Timestamp was received and a transmit timestamp indicating when the Timestamp reply was sent.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 14 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
| Identifier | Sequence number | ||||||||||||||||||||||||||||||
| Originate timestamp | |||||||||||||||||||||||||||||||
| Receive timestamp | |||||||||||||||||||||||||||||||
| Transmit timestamp | |||||||||||||||||||||||||||||||
Where:
- Type must be set to 14
- Code must be set to 0
- Identifier and Sequence number can be used by the client to match the reply with the request that caused the reply.
- Originate timestamp is the time the sender last touched the message before sending it.
- Receive timestamp is the time the echoer first touched it on receipt.
- Transmit timestamp is the time the echoer last touched the message on sending it.
- All timestamps are in units of milliseconds since midnight UT. If the time is not available in milliseconds or cannot be provided with respect to midnight UT then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.
The use of Timestamp and Timestamp Reply messages to synchronize the clocks of Internet nodes has largely been replaced by the UDP-based Network Time Protocol and the Precision Time Protocol.[16]
Address mask request
[edit]Address mask request is normally sent by a host to a router in order to obtain an appropriate subnet mask.
Recipients should reply to this message with an Address mask reply message.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 17 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
| Identifier | Sequence number | ||||||||||||||||||||||||||||||
| Address mask | |||||||||||||||||||||||||||||||
Where:
- Type must be set to 17
- Code must be set to 0
- Address mask can be set to 0
ICMP Address Mask Request may be used as a part of reconnaissance attack to gather information on the target network, therefore ICMP Address Mask Reply is disabled by default on Cisco IOS.[17]
Address mask reply
[edit]Address mask reply is used to reply to an address mask request message with an appropriate subnet mask.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 18 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
| Identifier | Sequence number | ||||||||||||||||||||||||||||||
| Address mask | |||||||||||||||||||||||||||||||
Where:
- Type must be set to 18
- Code must be set to 0
- Address mask should be set to the subnet mask
Destination unreachable
[edit]Destination unreachable is generated by the host or its inbound gateway[2] to inform the client that the destination is unreachable for some reason. Reasons for this message may include: the physical connection to the host does not exist (distance is infinite); the indicated protocol or port is not active; the data must be fragmented but the 'don't fragment' flag is on.[18] Unreachable TCP ports notably respond with TCP RST rather than a destination unreachable type 3 as might be expected. Destination unreachable is never reported for IP multicast transmissions.
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Type (3) | Code | Checksum | |||||||||||||||||||||||||||||
| 4 | 32 | Unused | (Length) | (Next-hop MTU) | |||||||||||||||||||||||||||||
| 8 | 64 | IP header and first bytes of original datagram's data | |||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
| 572 | 4576 | ||||||||||||||||||||||||||||||||
With the following field contents:
- Type: 8 bits; Type == 3
- A value of 3 indicates 'Destination unreachable'.
- Code: 8 bits
- This specifies the type of error, and can be any of the following:[8]
Code Description 0 Network unreachable error. 1 Host unreachable error. 2 Protocol unreachable error (the designated transport protocol is not supported). 3 Port unreachable error (the designated protocol is unable to inform the host of the incoming message). 4 The datagram is too big. Packet fragmentation is required but the 'don't fragment' (DF) flag is on. 5 Source route failed error. 6 Destination network unknown error. 7 Destination host unknown error. 8 Source host isolated error. 9 The destination network is administratively prohibited. 10 The destination host is administratively prohibited. 11 The network is unreachable for Type Of Service. 12 The host is unreachable for Type Of Service. 13 Communication administratively prohibited (administrative filtering prevents packet from being forwarded). 14 Host precedence violation (indicates the requested precedence is not permitted for the combination of host or network and port). 15 Precedence cutoff in effect (precedence of datagram is below the level set by the network administrators).
- Unused: 8 - 32 bits; Unused == 0
- Unused, must be set to zero. If Length or Next-hop MTU are not used, they are considered part of this field.
- Length: 8 bits
- Optional. The Length field indicates the length of the original datagram data, in 32-bit words. This allows this ICMP message to be extended with extra information. If used, the original datagram data must be padded with zeroes to the nearest 32-bit boundary.
- Next-hop MTU: 16 bits
- Optional. Contains the MTU of the next-hop network if a code 4 error occurs.
- IP header and data: 20 - 568 bytes
- The IP header (20 bytes) and at most 548 bytes of the start of the original datagram (as not to exceed the minimum IPv4 reassembly buffer size). If this message is extended then this field must contain at least 128 bytes of original datagram data (padded with zeroes if necessary).
These data are included to allow the client to match the reply with the request that caused the Destination unreachable reply.
Extensions
[edit]ICMP messages can be extended with extra information. This information is carried in one or more Extension Objects, which are preceded by an ICMP Extension Header.[19]
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Version | Reserved | Checksum | |||||||||||||||||||||||||||||
| 4 | 32 | Extension Objects | |||||||||||||||||||||||||||||||
| 8 | 64 | ||||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
- Version: 4 bits; Version == 2
- Extension header version.
- Reserved: 12 bits; Reserved == 0
- Reserved.
- Checksum: 16 bits
- Checksum over this header and all extension objects. This field itself is included, so it is set to zero while performing the calculation.
Extension objects have the following general structure:
| Offset | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Length | Class-Num | C-Type | |||||||||||||||||||||||||||||
| 4 | 32 | (Object payload) | |||||||||||||||||||||||||||||||
| 8 | 64 | ||||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
- Length: 16 bits
- The length of the object in octets, including the header.
- Class-Num: 8 bits
- Identifies the object's class.
- C-Type: 8 bits
- Identifies the object's subtype.
- Object payload: Variable
- Optional payload. If nonempty, it contains a data structure, which size is a multiple of 32 bits.
See also
[edit]References
[edit]- ^ a b F. Baker, ed. (June 1995). Requirements for IP Version 4 Routers. Network Working Group. doi:10.17487/RFC1812. RFC 1812. Proposed Standard. Obsoletes RFC 1716 and 1009. Updated by RFC 2644 and 6633.
- ^ a b c d e f g h i j k l J. Postel (September 1981). INTERNET CONTROL MESSAGE PROTOCOL - DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION. Network Working Group. doi:10.17487/RFC0792. STD 5. RFC 792. Internet Standard 5. Updates RFC 760, 777, IENs 109, 128. Updated by RFC 950, 4884, 6633 and 6918.
- ^ a b c d Forouzan, Behrouz A. (2007). Data Communications And Networking (Fourth ed.). Boston: McGraw-Hill. pp. 621–630. ISBN 978-0-07-296775-3.
- ^ A. Conta; S. Deering (March 2006). M. Gupta (ed.). Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. Network Working Group. doi:10.17487/RFC4443. STD 89. RFC 4443. Internet Standard 89. Obsoletes RFC 2463. Updates RFC 2780. Updated by RFC 4884.
- ^ "The OSI Model's Seven Layers Defined and Functions Explained". Microsoft Support. Retrieved 2014-12-28.
- ^ "Protocol Numbers". Internet Assigned Numbers Authority. Retrieved 2011-06-23.
- ^ R. Braden; D. Borman; C. Partridge (September 1988). Computing the Internet Checksum. Network Working Group. doi:10.17487/RFC1071. RFC 1071. Informational. Updated by RFC 1141.
- ^ a b c "Internet Control Message Protocol (ICMP) Parameters". IANA. 2012-09-21. Retrieved 2013-01-07.
- ^ Kurose, J.F; Ross, K.W. (2006). Computer Networking: A Top-Down Approach. World student series. Addison-Wesley. ISBN 9780321418494.
- ^ a b F. Gont (May 2012). Deprecation of ICMP Source Quench Messages. Internet Engineering Task Force. doi:10.17487/RFC6633. ISSN 2070-1721. RFC 6633. Proposed Standard. Updates RFC 792, 1122 and 1812.
- ^ a b c d e f g h i j k l m n o F. Gont; C. Pignataro (April 2013). Formally Deprecating Some ICMPv4 Message Types. Internet Engineering Task Force. doi:10.17487/RFC6918. ISSN 2070-1721. RFC 6918. Proposed Standard. Obsoletes RFC 1788. Updates RFC 792 and 950.
- ^ J. Kempf (July 2005). Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations. doi:10.17487/RFC4065. RFC 4065. Experimental.
- ^ a b R. Bonica; R. Thomas; J. Linkova; C. Lenart; M. Boucadair (February 2018). PROBE: A Utility for Probing Interfaces. Internet Engineering Task Force. doi:10.17487/RFC8335. ISSN 2070-1721. RFC 8335. Proposed Standard. Updates RFC 4884.
- ^ a b B. Fenner (November 2006). Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. IETF Network Working Group. doi:10.17487/RFC4727. RFC 4727. Proposed Standard.
- ^ "When Are ICMP Redirects Sent?". Cisco Systems. 2008-06-28. Retrieved 2013-08-15.
- ^ D.L. Mills (September 1985). Network Time Protocol (NTP). doi:10.17487/RFC0958. RFC 958.
It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both.
- ^ "Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache". Cisco Systems. Archived from the original on 2013-01-02. Retrieved 2013-01-07.
- ^ J. Mogul; S. Deering (November 1990). Path MTU Discovery. Network Working Group. doi:10.17487/RFC1191. RFC 1191. Draft Standard. Obsoletes RFC 1063.
- ^ a b R. Bonica; D. Gan; D. Tappan; C. Pignataro (April 2007). Extended ICMP to Support Multi-Part Messages. Network Working Group. doi:10.17487/RFC4884. RFC 4884. Proposed Standard. Updates RFC 792 and 4443. Updated by RFC 8335.
External links
[edit]
Wikiversity has learning resources about Internet Control Message Protocol
- IANA protocol numbers
- Explanation of ICMP Redirect Behavior at the Wayback Machine (archived 2015-01-10)
Internet Control Message Protocol
View on Grokipediafrom Grokipedia
The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet Protocol (IP) suite that enables hosts and gateways to send error messages and operational information about IP datagram processing, without providing data delivery guarantees, which are handled by higher-layer protocols.[1] Defined in RFC 792 for IPv4, ICMP uses the basic IP header with a protocol number of 1 and includes message types such as Echo Request (type 8) and Echo Reply (type 0) for diagnostics, Destination Unreachable (type 3) for error reporting, and Source Quench (type 4) for congestion control.[1] Every IP module must implement ICMP to facilitate network troubleshooting and feedback on issues like unreachable destinations or time-exceeded datagrams.[1]
For IPv6, an adapted version known as ICMPv6 (defined in RFC 4443) serves similar functions but integrates more deeply with IPv6 features, using a Next Header value of 58 and supporting additional capabilities like Path MTU Discovery and Neighbor Discovery Protocol messaging.[2] ICMPv6 error messages include Destination Unreachable (type 1), Packet Too Big (type 2), and Time Exceeded (type 3), while informational messages comprise Echo Request (type 128) and Echo Reply (type 129).[2] Unlike ICMP for IPv4, ICMPv6 is mandatory in all IPv6 nodes and uses the IPv6 pseudo-header in its checksum calculation to enhance integrity.[2]
ICMP plays a crucial role in network diagnostics, exemplified by tools like ping (which relies on Echo messages) and traceroute (which uses Time Exceeded messages), enabling administrators to detect connectivity issues, measure latency, and identify routing problems across IP networks.[1][2] However, to prevent loops, ICMP does not generate messages in response to other ICMP messages, and implementations must handle potential security risks such as spoofing by rate-limiting or filtering.[1] Over time, extensions to ICMP have addressed evolving needs, including environmental data reporting in ICMPv6 and enhanced authentication mechanisms, but its core remains focused on lightweight control and error signaling rather than reliable transport.[2]
In operation, a sending host generates an Echo Request packet encapsulated in an IPv4 datagram, which the destination host processes upon receipt and responds to directly if it supports ICMP.[1] The reply mirrors the request's data and control fields (except for type and addresses), enabling the sender to confirm one-way path viability by observing the round-trip.[1] This process relies on the underlying IP delivery but offers no delivery guarantees, as ICMP messages can be dropped like any datagram.[1]
The Echo mechanism forms the foundation for the ping utility, a widely used diagnostic tool that sends Echo Requests and measures the round-trip time (RTT) based on the local time of sending the request and receiving the reply to assess latency and packet loss.[11] However, firewalls often block Echo Requests or Replies to mitigate reconnaissance or denial-of-service risks, potentially hindering diagnostics.[12] Additionally, the basic Echo process lacks built-in authentication, making it vulnerable to spoofing where forged replies could mislead reachability tests.[1]
Overview
Purpose and Role
The Internet Control Message Protocol (ICMP) serves as a supporting protocol within the Internet Protocol (IP) suite, designed to convey control and error messages between network devices without involving the transport layer. It enables IP modules in hosts and gateways to report issues encountered during datagram processing, such as transmission failures or suboptimal routing, thereby facilitating the maintenance of the communication environment. Unlike transport protocols, ICMP operates exclusively at the network layer to provide feedback mechanisms that enhance IP's functionality, but it does not guarantee end-to-end reliability or data delivery.[1] ICMP's primary functions include reporting errors in IP datagram handling, querying the status of network connectivity, and supporting diagnostic activities to troubleshoot network issues. For instance, it allows devices to notify senders of problems like datagram fragmentation failures or routing redirects, helping to optimize traffic flow without altering the core IP transmission process. A key diagnostic role is exemplified by reachability testing, where ICMP echo messages are used to verify if a destination host is accessible, forming the basis for tools like ping that measure round-trip times and detect connectivity disruptions. These functions ensure that IP networks can self-diagnose and adapt to anomalies, promoting overall stability.[1] Distinguishing ICMP from transport-layer protocols such as TCP or UDP, it focuses solely on network-layer control and does not establish connections or segment data for reliable delivery; instead, it embeds messages within IP datagrams to alert about processing errors or environmental conditions. Practical use cases include generating "Destination Unreachable" messages when a target host or network cannot be located, which informs the sender to cease transmission attempts, or issuing "Source Quench" messages to signal excessive network load, prompting the source to temporarily reduce its datagram rate and alleviate congestion. By limiting its scope to these ancillary roles, ICMP complements IP's best-effort delivery model without introducing overhead from transport semantics.[1]History and Standards
The Internet Control Message Protocol (ICMP) was developed in 1981 by Jon Postel as a key component of the early TCP/IP protocol suite under the DARPA Internet Program, which facilitated the transition of the ARPANET to a broader internetworking architecture.[1] This effort addressed the need for error reporting and diagnostic mechanisms in IP-based networks, building on prior ARPANET testing and protocol evolution. The initial specification for ICMP in IPv4 was outlined in RFC 792, published in September 1981, which defined its message types and formats for host-to-host datagram error reporting and queries.[1] Subsequent refinements came in RFC 1122 (October 1989), which established requirements for Internet hosts implementing ICMP, emphasizing mandatory support and clarification of behaviors like echo responses.[3] Further updates in RFC 1812 (June 1995) addressed router requirements, mandating specific ICMP handling for forwarding decisions and deprecating the generation of Source Quench messages by routers due to their limited effectiveness in congestion control.[4] In 2012, RFC 6633 formally deprecated the use of ICMP Source Quench messages across transport protocols, citing their ineffectiveness, unfairness in congestion signaling, and obsolescence in favor of modern mechanisms like Explicit Congestion Notification, thereby updating RFC 792, RFC 1122, and RFC 1812.[5] For IPv6, ICMP was extended as ICMPv6 in RFC 4443 (March 2006), providing equivalent functionality tailored to IPv6 while excluding Source Quench and integrating additional features for neighbor discovery.[2] These standards have solidified ICMP's enduring role in internet diagnostics, from early ARPANET validation to contemporary network troubleshooting tools like ping and traceroute.[1]Protocol Fundamentals
Integration with IP
The Internet Control Message Protocol (ICMP) operates as an integral component of the Internet Protocol (IP) suite, with its messages encapsulated directly within IP datagrams to facilitate error reporting and diagnostic functions at the network layer. In IPv4 networks, ICMP messages are transported using IP datagrams where the Protocol field in the IP header is set to 1, as assigned by the Internet Assigned Numbers Authority (IANA). Similarly, for IPv6, this value is 58 for ICMPv6 messages.[6][2] This encapsulation ensures that ICMP leverages the IP layer's routing and delivery mechanisms without requiring a separate transport protocol, allowing ICMP to interact seamlessly with IP processing on hosts and routers.[6] ICMP error messages are generated only in response to issues encountered with IP datagrams carrying higher-layer protocols or non-ICMP payloads, adhering to strict rules to prevent infinite loops or message storms. Specifically, no ICMP error messages are produced for errors in other ICMP messages themselves, as this would lead to an endless regress of error notifications about errors. Additionally, ICMP errors are not generated for broadcast or multicast datagrams to avoid network-wide amplification. These rules ensure stability by limiting error propagation solely to unicast IP traffic that warrants corrective feedback.[6][7] In the typical processing flow, when a router or host receives an IP datagram, it first inspects the IP header for validity, such as checking the Time to Live (TTL) field or destination address. If an error condition is detected—such as an unreachable destination or TTL expiration—the device generates an appropriate ICMP error message, which is then encapsulated in a new IP datagram and sent back to the source IP address extracted from the original datagram's header. Otherwise, the datagram is forwarded toward its destination or passed to upper layers for local delivery. This integration allows IP implementations to provide feedback on delivery failures without disrupting the core forwarding path. To mitigate potential denial-of-service risks from excessive ICMP generation, routers and hosts must implement rate limiting, such as capping the transmission rate of ICMP messages to no more than a configurable threshold (e.g., one per second per destination), as recommended in standards for IP routers.[7][6][7] ICMP also plays a critical role in handling IP fragmentation and reassembly challenges. In IPv4, when a router cannot forward a datagram due to its size exceeding the outgoing link's Maximum Transmission Unit (MTU) and the Don't Fragment (DF) bit is set, it discards the datagram and sends an ICMP Destination Unreachable message (Type 3, Code 4) to inform the source of the MTU limit, enabling Path MTU Discovery; in IPv6, the equivalent is an ICMPv6 Packet Too Big message (Type 2). During reassembly at the destination host, if the timer for fragment collection expires before all pieces arrive, the host generates an ICMP Time Exceeded message—in IPv4, Type 11 Code 1; in IPv6, Type 3 Code 1—to notify the source of the reassembly failure. These mechanisms provide essential signals for optimizing packet sizes and detecting fragmentation-related issues without requiring end-to-end coordination beyond IP.[6]Message Types Classification
ICMP messages are broadly classified into two primary categories: error messages and query (or informational) messages. Error messages report issues encountered during the processing or delivery of IP datagrams, such as a host or network being unreachable, thereby aiding in fault diagnosis by notifying the originating host of the problem.[1] Query messages, in contrast, facilitate network diagnostics by allowing a sender to request specific responses from a target node, enabling tests of reachability, timing, or configuration details.[3] The Type field in the ICMP header, occupying the first octet, identifies the message category, with values ranging from 0 to 255 assigned to specific functions across both classes. The adjacent Code field, in the second octet, specifies subtypes or additional details for a given type, such as distinguishing between network unreachable (Code 0) and host unreachable (Code 1) within the Destination Unreachable message.[1] This structure allows for precise signaling without overlapping interpretations.[4] Error messages adhere to strict constraints to provide actionable context while avoiding amplification or loops. Each must encapsulate the full IP header of the offending datagram along with at least the first 64 bits (8 bytes) of its original data, enabling the recipient to correlate the error with the specific packet.[1] Furthermore, implementations must not generate error messages in response to other ICMP errors, broadcast or multicast datagrams, or fragments beyond the first, ensuring controlled propagation.[3][4] Query messages exhibit symmetry through paired request-response formats, where a request prompts a targeted reply that mirrors key elements like identifiers and data. For example, an Echo Request (Type 8) elicits an Echo Reply (Type 0) that returns the original payload intact, verifying connectivity.[1] This bidirectional design supports diagnostic utilities without requiring asymmetric handling.[3] Among query types, the Information Request (Type 15) and Information Reply (Type 16) are obsolete, as they were intended for determining subnet masks but have been deprecated in favor of more robust mechanisms like Echo messages for similar purposes.[3] Modern implementations should neither generate nor process these types to align with evolved network standards.[4]Message Format
Header Fields
The ICMP header consists of a fixed 8-byte structure that precedes any variable data in the message.[1] The first field is the Type, an 8-bit unsigned integer that identifies the category of the ICMP message, such as 3 for Destination Unreachable.[1] The second field is the Code, also an 8-bit unsigned integer, which provides further specification for the Type, for example, Code 0 indicating a network unreachable condition within Type 3.[1] The third field is the Checksum, a 16-bit field computed using one's complement arithmetic over the entire ICMP message, including the header and any data, with the Checksum field itself set to zero during calculation. If the message length is odd, the data is conceptually padded with a zero octet solely for checksum computation; no padding is added to the transmitted message.[1] Unlike transport-layer protocols such as TCP or UDP, the ICMP checksum does not incorporate a pseudo-header from the IP layer; it solely covers the ICMP message content.[1] The remaining 4 bytes of the header vary depending on the message Type; for instance, in Echo Request or Reply messages, they contain a 16-bit Identifier and a 16-bit Sequence Number to match requests with replies.[1]Payload Structure
The payload of an ICMP message follows the fixed 8-byte header and varies depending on the message type, providing context or diagnostic information without including transport-layer protocol details beyond what may incidentally appear in the original datagram's data.[1] For error messages, such as Destination Unreachable or Time Exceeded, the payload consists of a 32-bit unused field, the original IP header (typically 20 bytes, including any options), plus the first 8 bytes (64 bits) of the original datagram's data; this inclusion allows the recipient to associate the error with the specific network-layer context of the failed transmission, assuming higher-layer port numbers, if present, are captured within those initial data bytes.[1] In contrast, query messages carry type-specific data tailored to their diagnostic purpose. For instance, the Timestamp message includes three 32-bit timestamps: originate (time of transmission), receive (time of processing), and transmit (time of reply generation), enabling round-trip delay measurements at the network layer.[1] The Echo Request and Reply messages append optional data, which is echoed unchanged and can extend up to approximately 1,500 bytes to test path MTU limits, though the exact size is constrained by the encapsulating IP packet's maximum transmission unit (MTU).[1] Other queries, like Information Request, include minimal fields such as a 16-bit identifier and sequence number without additional variable data.[1] To ensure proper alignment and checksum computation, the payload requires no transmitted padding, though conceptual zero-padding is used if the total message length is odd during checksum calculation, as the header checksum covers the entire message in 16-bit words.[1] Overall, the payload length is variable but limited such that the complete ICMP message, when encapsulated in an IP packet, does not exceed the path MTU minus the IP header size, typically allowing payloads up to 1,472 bytes on standard Ethernet links with a 1,500-byte MTU.[1] This structure emphasizes network-layer diagnostics, excluding dedicated transport-layer headers to keep ICMP lightweight and focused on IP-layer error reporting and queries.[1]IPv4 Error Messages
Destination Unreachable
The Destination Unreachable message, designated as ICMP Type 3 in IPv4, notifies the source host that an IP datagram cannot be delivered to its intended destination due to various failure conditions encountered during forwarding or final delivery. This error message is generated by either an intermediate router unable to forward the datagram or the destination host unable to process it, helping the sender diagnose and potentially recover from the issue.[1] The message includes up to 16 specific codes (0-15) that pinpoint the exact reason for unreachability, with original codes defined in RFC 792 and additional ones specified in RFC 1122 to address evolving network requirements.[1][3] Routers generate Destination Unreachable messages when they lack a route to the destination network (Code 0) or host (Code 1), when fragmentation is required but the Don't Fragment (DF) bit is set in the original datagram (Code 4), or when a source route option cannot be followed (Code 5).[1] Hosts produce these messages for protocol-related issues, such as an unsupported upper-layer protocol (Code 2), or when no application is listening on the specified transport-layer port, as commonly seen with UDP packets (Code 3).[1] Additional codes cover scenarios like unknown networks or hosts (Codes 6 and 7), administrative prohibitions on communication (Codes 9, 10, and 13), or Type of Service (TOS)-related unreachability (Codes 11 and 12).[3] Less common codes include source host isolation (Code 8), host precedence violations (Code 14), and precedence cutoffs (Code 15), which were introduced to handle policy-based restrictions and priority handling in early Internet implementations.[3] The full set of codes is maintained by IANA for consistency across implementations.[8] To facilitate troubleshooting, the Destination Unreachable message carries a payload consisting of the original IP header (at least 20 bytes) plus the first 64 bits of the datagram's data portion, allowing the sender to inspect the problematic packet without needing to retransmit the entire contents.[1] This inclusion enables applications to correlate the error with the specific transmission attempt. In practice, receipt of these messages influences application behavior, such as triggering retry mechanisms with alternative routes or endpoints, and informs dynamic routing protocols to update path selections for improved reliability.[1] For instance, Code 4 is used in Path MTU Discovery, where the message includes the MTU of the next-hop network (RFC 1191), though firewalls sometimes filter these to prevent information leakage. Overall, these messages enhance network diagnostics without providing guaranteed delivery, as ICMP itself is unreliable.[1][9]| Code | Description | Reference |
|---|---|---|
| 0 | Net Unreachable | RFC 792 |
| 1 | Host Unreachable | RFC 792 |
| 2 | Protocol Unreachable | RFC 792 |
| 3 | Port Unreachable | RFC 792 |
| 4 | Fragmentation Needed and DF Set | RFC 792 |
| 5 | Source Route Failed | RFC 792 |
| 6 | Destination Network Unknown | RFC 1122 |
| 7 | Destination Host Unknown | RFC 1122 |
| 8 | Source Host Isolated | RFC 1122 |
| 9 | Network Administratively Prohibited | RFC 1122 |
| 10 | Host Administratively Prohibited | RFC 1122 |
| 11 | Network Unreachable for TOS | RFC 1122 |
| 12 | Host Unreachable for TOS | RFC 1122 |
| 13 | Communication Administratively Prohibited | RFC 1122 |
| 14 | Host Precedence Violation | RFC 1122 |
| 15 | Precedence Cutoff in Effect | RFC 1122 |
Time Exceeded
The Time Exceeded message in ICMP, designated as Type 11, is generated to report when an IP datagram's lifetime expires either during transit through the network or at the destination host during reassembly. This message uses two specific codes: Code 0 indicates that the Time to Live (TTL) field in the IP header reached zero while the datagram was in transit, typically at a router; Code 1 signifies that the reassembly timer expired at the host due to incomplete fragment collection.[1] Routers trigger a Code 0 Time Exceeded message by decrementing the TTL field by at least one upon processing a datagram; if it reaches zero, the datagram is discarded to prevent indefinite circulation, and the message is sent back to the original source address. At the host level, a Code 1 message arises when fragments of a datagram fail to arrive within the reassembly timeout period, leading to discard of the incomplete datagram—provided the first fragment (with the original IP header) was received, as its absence prevents message generation. The payload of the Time Exceeded message consists of the unaltered IP header from the discarded datagram plus the first 64 bits (8 bytes) of its data, enabling the sender to identify the affected packet, such as by matching transport-layer port numbers.[1] This mechanism is crucial for network diagnostics and reliability, as it not only averts infinite routing loops by enforcing a datagram lifetime limit but also supports path discovery tools like traceroute, which incrementally increase TTL values in probe packets to elicit sequential Time Exceeded responses revealing intermediate routers. Historically, the TTL field was originally defined as a time-based metric in seconds (up to 255 seconds maximum) to bound datagram existence within the internet, but in practice, it evolved into a hop-count decrement due to uniform reduction at each router regardless of actual processing time.[10][1]IPv4 Query Messages
Echo Request and Reply
The Echo Request and Reply messages in ICMP provide a mechanism for testing the reachability of a host in IPv4 networks.[1] An Echo Request, identified by ICMP type 8 and code 0, is sent from a source host to a destination, prompting the recipient to verify connectivity by responding with an Echo Reply.[1] The Echo Reply, with type 0 and code 0, reverses the source and destination IP addresses from the request, recomputes the checksum, and returns the original data unchanged.[1] The message format for both Echo Request and Reply includes a standard ICMP header followed by specific fields.[1] After the 8-byte ICMP header (type, code, and 16-bit checksum), the next fields are a 16-bit identifier and a 16-bit sequence number, which assist in matching requests with their corresponding replies, particularly in scenarios with multiple concurrent echoes.[1] The identifier can be set to zero if not needed, and the sequence number increments for successive requests from the same source to aid ordering.[1] Following these is an optional variable-length data payload, which is echoed back verbatim in the reply; this data often consists of filler bytes or implementation-specific content.[1]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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | [Checksum](/page/Checksum) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | [Checksum](/page/Checksum) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-
Timestamp Request and Reply
The ICMP Timestamp Request and Timestamp Reply messages provide a mechanism for querying the processing delay at a remote host and estimating network transit times in IPv4 networks. These query messages, defined in the original ICMP specification, allow a sender to obtain timestamps from the receiver to facilitate diagnostics such as round-trip time (RTT) measurements or basic clock synchronization assessments.[1] The Timestamp Request message uses ICMP Type 13, while the Timestamp Reply uses Type 14; both have Code 0. The message format includes a standard 8-byte ICMP header followed by a 20-byte payload consisting of an identifier, sequence number, and three 32-bit timestamps. The identifier and sequence number (each 16 bits) assist in matching requests with replies, though they may be set to zero if not needed. The timestamps represent milliseconds since midnight Universal Time (UT) and include: the originate timestamp (time the sender last handled the message before transmission), the receive timestamp (time the receiver first handled it upon arrival), and the transmit timestamp (time the receiver last handled it before sending the reply). If precise millisecond timing relative to midnight UT is unavailable, implementations may insert arbitrary values with the high-order bit set to indicate non-standard units.[1] In operation, the sender records the local originate timestamp, sets the receive and transmit fields to zero in the Type 13 request, and transmits the message. Upon receipt, the destination host copies the originate timestamp unchanged, records the current time as the receive timestamp, processes the request, records the current time again as the transmit timestamp, reverses the source and destination IP addresses, changes the type to 14, recomputes the checksum, and sends the reply. The sender then locally records the arrival time of the reply (denoted as t4) to complete the timing data. This process enables separation of network transit components from host processing.[1] From the returned timestamps—originate (t1), receive (t2), and transmit (t3)—key metrics can be derived assuming synchronized clocks between hosts. The outbound transit time is approximated as t2 - t1, the inbound transit time as t4 - t3, and the remote host's processing delay as t3 - t2. The overall RTT is then (t2 - t1) + (t4 - t3) + (t3 - t2), or simply t4 - t1 for a direct measurement. These values support network diagnostics, such as identifying excessive processing delays indicative of host load or rudimentary clock offset estimation, as referenced in early time synchronization work.[1][13] Historically intended for performance evaluation and time synchronization, Timestamp Request and Reply messages are rarely used in modern networks due to security concerns (e.g., potential disclosure of system time) and the superiority of dedicated protocols like the Network Time Protocol (NTP) for accurate clock synchronization. Implementations often disable or filter these messages by default to mitigate reconnaissance risks, limiting their role to legacy diagnostics.[1][14]Information Request and Reply
The ICMP Information Request and Reply messages provide a basic mechanism for determining the network number of the sending host in IPv4 networks. Defined in the original ICMP specification, these query messages (Type 15 for Request and Type 16 for Reply, both with Code 0) were intended for bootstrapping network configuration but are now deprecated in favor of more robust protocols.[1] The message format includes the standard 8-byte ICMP header followed by a 4-byte payload consisting of a 16-bit identifier and a 16-bit sequence number to match requests with replies. No additional data fields are present. In operation, the request is sent with the source and destination IP addresses set to zero (or the sender's IP in source), prompting the recipient to reply with the full IP addresses of the request's source and destination to convey the network number. The reply reverses the addresses, changes the type to 16, and recomputes the checksum.[1] Due to security risks, such as exposing network topology, and the availability of DHCP and other auto-configuration methods, Information messages are seldom implemented or enabled in contemporary systems and are considered obsolete.[1]ICMPv6 Specifics
Key Differences from IPv4
ICMPv6, defined as the companion protocol for IPv6, employs the protocol number 58 in the IPv6 header's Next Header field, distinguishing it from ICMPv4's protocol number 1 in IPv4 headers.[2] This integration extends to its role in supporting the IPv6 Neighbor Discovery Protocol (NDP), where ICMPv6 messages facilitate essential functions like address resolution and router discovery, unlike the separate ARP protocol in IPv4 environments.[2] Furthermore, ICMPv6 prohibits the generation of error messages for fragmented packets containing a Fragment Header with a non-zero Offset, as IPv6 fragmentation is managed exclusively through extension headers at the source, shifting away from IPv4's router-level fragmentation and associated error reporting.[2] The ICMPv6 checksum computation incorporates a pseudo-header that includes the IPv6 source and destination addresses, the packet length, and the Next Header value of 58, ensuring integrity verification that aligns with IPv6's header structure and contrasts with ICMPv4's simpler checksum excluding such pseudo-elements.[2] Message types in ICMPv6 are expanded and reorganized into two primary classes: types 0 through 127 for error messages, such as Destination Unreachable (type 1) and Packet Too Big (type 2), and types 128 through 255 for informational messages, including Echo Request (type 128) and Echo Reply (type 129), with mandatory implementation required for all IPv6 nodes to support Echo functionality.[2] This structure provides greater flexibility for future extensions compared to ICMPv4's more limited type assignments. ICMPv6 eliminates certain IPv4-specific messages, notably omitting Address Mask Request and Reply (types 17 and 18 in ICMPv4), as IPv6 address configuration relies on NDP mechanisms rather than such queries.[2] Redirect messages (type 137) in ICMPv6 are restricted to on-link destinations, informing only same-link hosts of better next-hop routers without the broader network scope possible in IPv4 redirects.[2] These protocols were standardized in RFC 4443, published in March 2006, which obsoletes earlier specifications and establishes ICMPv6 as a Proposed Standard; subsequent mobility extensions, such as those for Mobile IPv6 including Home Agent Address Discovery Request and Reply (types 144 and 145), are detailed in RFC 6275 from July 2011.[2][15]Neighbor Discovery Messages
The Neighbor Discovery Protocol (NDP) in IPv6 utilizes specific ICMPv6 messages to enable hosts and routers on the same link to discover each other, resolve addresses, and maintain reachability information. These messages replace several IPv4 ARP and ICMP functions, providing an integrated mechanism for address autoconfiguration, router discovery, and neighbor management. NDP operates primarily through multicast communications on the local link, using ICMPv6 types 133 through 137.[16] The five core NDP messages are as follows:- Router Solicitation (Type 133): Sent by hosts to promptly request Router Advertisements from neighboring routers, facilitating quick network configuration upon attachment. Hosts multicast this message to the all-routers address (FF02::2), typically including their source link-layer address if known, with a hop limit of 255 to ensure link-local delivery.[17]
- Router Advertisement (Type 134): Routers use this message to announce their presence, link parameters, and prefixes periodically or in unicast response to solicitations. It includes critical configuration data such as the router's lifetime (indicating availability duration), current hop limit, reachable time (for neighbor unreachability detection), retransmission timer, and MTU; prefixes carry lifetimes for address autoconfiguration. Sent with a hop limit of 255, it supports stateless address autoconfiguration by specifying on-link and address prefixes.[18]
- Neighbor Solicitation (Type 135): This message enables address resolution by querying the link-layer address of a target IPv6 address and detects duplicate addresses during autoconfiguration. A node sends it as a multicast to the target's solicited-node multicast address (derived from the target's IPv6 address) or unicast if the target is known, including the target address in the ICMPv6 payload and optionally the sender's source link-layer address; the source address may be unspecified for initial probes. The hop limit is set to 255.[19]
- Neighbor Advertisement (Type 136): Sent in response to Neighbor Solicitations or unsolicited to announce link-layer address changes, this message confirms reachability or provides the target's link-layer address. It includes flags such as the Router flag (indicating if the sender is a router), Solicited flag (for responses), and Override flag (to update existing cache entries); the target address is specified, with the target's link-layer address as an option. Responses are unicast to the solicitor or multicast for announcements, with a hop limit of 255.[20]
- Redirect (Type 137): Routers send this to inform a host of a better next-hop address for a specific destination, optimizing routing on the link. It includes the target address (better next-hop), destination address (original target), and optionally the target's link-layer address and a portion of the redirected packet header for verification; sent unicast to the original sender with a hop limit of 255, it updates the host's destination cache.[21]