Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Internet Layer (OSI Network Layer) Protocols            9  Internet Control Message Protocol (ICMP/ICMPv4 and ICMPv6)                 9  ICMP Message Types and Formats                      9  ICMP Version 4 (ICMPv4) Error Message Types and Formats

ICMP Version 4 (ICMPv4) Error Message Types and Formats 1 2 3 4 ICMPv4 Source Quench Messages

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.

ICMP Version 4 (ICMPv4) Error Message Types and Formats 1 2 3 4 ICMPv4 Source Quench Messages