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.
ICMP General Operation
(Page 2 of 2)
ICMP Error-Reporting Limitations
One interesting general characteristic
of ICMP's operation is that when errors are detected, they can be reported
using ICMP, but only back to the original source of a datagram. This
is actually a big drawback in how ICMP works. Refer back to Figure 137
and consider again client host A sending a message to server
host B, with a problem detected in the datagram by router R3.
Even if R3 suspects that the problem was caused by one of the
preceding routers that handled the message, such as R2, it cannot
send a problem report to R2. It can only send an ICMP message
back to host A.
This limitation is an artifact of
how the Internet Protocol works. You may recall from looking at the
IP datagram format that the only address
fields are for the original source and ultimate destination of the datagram.
(The only exception is if the IP Record Route option
is used, but devices cannot count on this.) When R3 receives
a datagram from R2 that R2 in turn received from R1
(and prior to that, from A), it is only A's address in
the datagram. Thus, R3 must send a problem report
back to A, and A must decide what to do with it. Device
A may decide to change the route it uses, or to generate an error
report that an administrator can use to troubleshoot the R2 router.
In addition to this basic limitation,
rules and conventions have been put in
place to govern the circumstances under which ICMP messages are generated,
sent and processed.
Key Concept: ICMP error-reporting messages sent in response to a problem seen in an IP datagram can only be sent back to the originating device. Intermediate devices cannot be the recipient of an ICMP message because their addresses are normally not carried in the IP datagrams header.
|If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!|
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.