ICMPv4 Destination Unreachable Messages
(Page 1 of 4)
Since the Internet Protocol is an unreliable protocol, there are no guarantees that a datagram sent by one device to another will ever actually get there. The internetwork of hosts and routers will make a best effort to deliver the datagram but it may not get where it needs to for any number of reasons. Of course, devices on an IP network understand that and are designed accordingly. IP software never assumes its datagrams will always be received, and higher layer protocols like TCP take care of providing reliability and acknowledgements of received data for applications that need these features.
This setup, with higher layers handling failed deliveries, is sufficient in some cases. For example, suppose device A tries to send to device B, but a router near B is overloaded, so it drops the datagram. In this case the problem is likely intermittent, so A can retransmit and eventually reach B. But what about a situation where a device is trying to send to an IP address that doesn't exist, or a problem with routing that isn't easily corrected? Having the source just continually retry while it remains in the dark about the problem would be inefficient, to say the least.
So in general, while IP is designed to allow IP datagram deliveries to fail, we should take any such failures seriously. What we really need is a feedback mechanism that can tell a source device that something improper is happening, and why. In IPv4, this service is provided through the transmission of Destination Unreachable ICMP messages. When a source node receives one of these messages it knows there was a problem sending a datagram, and can then decide what action, if any, it wants to take. Like all ICMP error messages, Destination Unreachable messages include a portion of the datagram that could not be delivered, which helps the recipient of the error figure out what the problem is.
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.