Internet Message Messaging Protocol ( ICMP ) is a support protocol in the Internet protocol suite. These are used by network devices, including routers, to send error messages and operational information that indicate, for example, that the requested service is unavailable or that the host or router can not be contacted. ICMP differs from transport protocols such as TCP and UDP because it is not normally used to exchange data between systems, nor is it regularly used by end-user network applications (with the exception of some diagnostic tools such as ping and traceroute).
ICMP for IPv4 is defined in RFC 792.
Video Internet Control Message Protocol
Detail teknis
The Internet Control Message Protocol is part of the Internet Protocol Suite, as defined in RFC 792. ICMP messages are usually used for diagnostic or control purposes or generated in response to errors in IP operations (as specified in RFC 1122). An ICMP error is redirected to the source IP address of the origin package.
For example, every device (such as an intermediate router) that forward IP datagrams first reduces the time to live (TTL) inside an IP header by one. If the resulting TTL is 0, the packet will be discarded and the ICMP time that is exceeded in the transit message is sent to the datagram source address.
ICMP uses basic IP support as if it is a higher level protocol, however, ICMP is actually an integral part of IP. Although ICMP messages are contained in standard IP packets, ICMP messages are usually processed as special cases, differentiated from ordinary IP processing. In many cases, it is necessary to check the contents of ICMP messages and send the appropriate error messages to the applications responsible for sending IP packets that drive ICMP message delivery.
Many commonly used network utilities are based on ICMP messages. The traceroute command can be implemented by transmitting IP datagrams with specially specified TTL IP header fields, and finding ICMP time is exceeded in transit and messages that can not be reached are generated in response. The associated ping utility is implemented using ICMP echo request and echo reply messages.
Maps Internet Control Message Protocol
Datagram structure
ICMP packets are encapsulated in IPv4 packets. Package consists of header and data section.
Header
The ICMP header starts after the IPv4 header and is identified by the IP '1' protocol number. All ICMP packets have 8-byte headers and variable sized data sections. The first 4 bytes of the header have a fixed format, while the last 4 bytes depend on the type/code of the ICMP packet.
- Type
- ICMP type, see Control message.
- Code
- ICMP subtype, see Control message.
- Checksum
- Error checking data, calculated from ICMP headers and data, with value 0 being replaced for this field. Internet checksum used, specified in RFC 1071.
- Time Header
- A four-byte field, content varies based on type and ICMP code.
Data
The ICMP error message contains a section of data that includes a copy of the entire IPv4 header, plus at least the first eight bytes of data from an IPv4 packet that causes an error message. The maximum length of ICMP error messages is 576 bytes. This data is used by the host to match the message to the appropriate process. If higher level protocols use port numbers, they are assumed to be in the first eight bytes of the original datagram data.
The size of the packet data section variable ICMP has been exploited. In the "Ping of death", large or fragmented ping packets are used for denial of service attacks. ICMP data can also be used to create a secret channel for communication. These channels are known as ICMP tunnels.
Control messages
Control messages are identified by a value in the type field. The code field provides additional context information for messages. Some control messages have been out of use since the protocol was first introduced.
Source satisfactory
Quench Resources requests the sender to reduce the rate of messages sent to the router or host. This message can be generated if the router or host does not have enough buffer space to process the request, or may occur if the host router or buffer is close to its limit.
Data is sent at a very high speed from the host or from multiple hosts at the same time to a particular router on the network. Although the router has buffering capability, the buffering is limited within the specified range. The router can not queue up more data than the limited buffering space capacity. So if the queue is filled, the incoming data is discarded until the queue is no longer full. But since there is no recognition mechanism present in the network layer, the client does not know whether the data has reached the destination successfully. Therefore some corrective action must be taken by the network layer to avoid this kind of situation. These steps are referred to as satisfactory sources. In the source quench mechanism, the router sees that the incoming data rate is much faster than the outgoing data rate, and sends ICMP messages to the client, telling them they must slow down their data transfer rate or wait for a certain amount of time before trying to send more data. When the client receives this message, it will automatically slow down the data rate out or wait for enough time, allowing the router to empty the queue. Thus the source squelches the ICMP message acts as a flow control in the network layer.
Because the research suggests that "ICMP Source Quench was an ineffective (and unfair) bidder for congestion", the creation of routers from resource quench messages had been abandoned in 1995 by RFC 1812. Furthermore, forwarding and any kind of reaction to (flow control ) action) message quench source has been abandoned from 2012 by RFC 6633.
Where:
- Type must be set to 4
- The code should be set to 0
- IP headers and additional data is used by the sender to match replies with related queries
Redirect
Divert the request for the data packet is sent on an alternate route. ICMP Redirect is a mechanism for routers to deliver routing information to the host. The message informs the host to update the routing information (to send packets on alternate routes). If the host tries to send data via router (R1) and R1 sends data to another router (R2) and direct path from host to R2 is available (ie, host and R2 are on the same Ethernet segment), R1 will send a redirect message to give know the host that the best route to destination is via R2. The host must then send the packet for direct destination to R2. The router will still send the original datagram to the intended destination. 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 may only be transmitted through gateways and may not be sent by Internet hosts.
Where:
- Type must be set to 5.
- The code specifies the reason for the redirect, possibly one of the following:
- IP Address is the 32-bit gateway address that the redirect will send.
- IP headers and additional data is included to allow the host to match replies to requests that cause a redirect replies.
Time is exceeded
Over Time is generated by the gateway to inform the source of the datagram being removed because the time for the live field reaches zero. Time that exceeds the message can also be sent by the host if it fails to rearrange the fragmented datagram within the time limit.
The time over message is used by the traceroute utility to identify gateways on the path between two hosts.
Where:
- Type must be set to 11
- Code specifies a reason for the time over the message, including the following:
Time Stamp
Timestamp is used for time synchronization. Original timestamp is set to time (in milliseconds since midnight) last sender touches package. The stamp of acceptance and delivery time is not used.
Where:
- Type must be set to 13
- The code should be set to 0 The
- Identifier and Sequence Number can be used by the client to match the timestamp answer with a timestamp request.
- Derived 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 show a non-standard time value.
Reply time
Timestamp Response replied to the Timestamp message. It consists of timestamps sent by the sender Timestamp and the stamp of receipt time indicating when Time Stamp is received and the transmit time stamp indicates when Cap timer sent.
Where:
- Type should be set to 14
- The code should be set to 0 The
- Identifier and Sequence Number may be used by the client to match the reply to the request that caused the reply.
- Derived timestamp is when the last sender touched the message before sending it.
- Accept time stamp is the time the echoer first touched it when received.
- Sending time stamp is the last time an echo touches a message when it is sent.
- All time stamps are in milliseconds since midnight UT. If time is not available in milliseconds or can not be given in connection with UT midnight, it can at any time be inserted in the time stamp as long as the high sequence bit of the timestamp is also set to show this non-standard value.
Request mask address
Address mask requests are usually sent by the host to the router to get the corresponding subnet mask.
The recipient must reply to this message with the Address mask opener message.
Where:
- Type must be set to 17
- The code should be set to 0
- Address mask can be set to 0
ICMP Address Mask Request can be used as part of a reconnaissance attack to collect information on the target network, therefore ICMP Address Mask Reply is disabled by default on Cisco IOS.
Reply mask address
The reply mask address is used to reply to the address mask request message with the corresponding subnet mask.
Where:
- Type must be set to 18
- The code should be set to 0
- Address mask must be set to subnet mask
Destination unreachable
Destination unreachable is generated by the host or its entry gateway to notify the client that the destination is unreachable for some reason. Destination Unreachable messages can be generated as a result of TCP or UDP. Unreachable TCP ports typically respond with TCP RST rather than Destination Unreachable type 3 as expected.
Errors will not be generated if the original datagram has a multicast destination address. Reasons for this message may include: physical connection to non-existent hosts (unlimited distance); the protocol or port shown is inactive; the data must be fragmented but the 'do not fragment' flag is lit.
Where: The
- Type field (bit 0-7) must be set to 3
- The code field (bit 8-15) is used to determine the type of error, and can be one of the following:
- Next-hop MTU field (bit 48-63) contains the next-hop network MTU if code 4 error occurs.
- IP headers and additional data is included to allow clients to match replies to requests that cause unreachable reply destinations.
See also
References
RFCs
- RFC 792, Internet Message Control Protocol
- RFC 950, Standard Internet Subnetting Procedure
- RFC 1016, Something Hosts Can Do With Quench Source: The Quench Approved Introduction (SQuID)
- RFC 1122, Requirements for the Internet Host - Communication Layer
- RFC 1716, Go to Terms for IP Routers
- RFC 1812, Requirements for IP Version 4 Router
External links
- IANA ICMP parameters
- IANA protocol number
- Explanation of ICMP Redirection Behavior
Source of the article : Wikipedia
0 Comments