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 Message Creation and Processing Conventions and Rules
(Page 2 of 3)
Limitations on ICMP Message Responses
Most of the issues related to message
generation have to do with error messages, not informational messages.
The latter class of messages usually don't cause problems because they
are generated based on specific rules already established in the protocols
that use them. For example, Router Advertisement messages are
sent by routers on a regular basis, and the routers make sure this is
infrequent. They are also sent in response to Router Solicitation
messages sent on occasion by hosts, and as long as a host doesn't go
haywire and start sending tons of Solicitations, there won't
be a problem. Even then, a router can be given enough smarts not to
send Router Advertisements too often.
The problem comes up with error messages
specifically because they are sent in response to so many
situations. Potentially, they may even be sent in response to each other.
Without special care, loops or cascading message generation might occur.
For example, consider a situation where device A encounters an
error and sends an error report to device B. Device B
finds an error in device A's message and sends an error report
back to device A. This could result in billions of messages being
sent back and forth clogging the network, until a human figures out
what is wrong and fixes it.
To prevent such problems, an ICMP
error message must not be generated in response to any
of the following:
- An ICMP Error Message: This prevents loops
of the type just mentioned. Note, however, that an ICMP error message
can be generated in response to an ICMP informational
message.
- A Broadcast or Multicast Datagram: What
would happen if a datagram were broadcast to 5,000 hosts and each of
them found an error in it and tried to send a report back to the source?
Something unpleasant.
- IP Datagram Fragments Except The First:
When a datagram is fragmented,
errors may only be sent in response to the first fragment. Often, errors
that are generated due to a problem with one fragment would also be
generated by each successive one, causing unnecessary ICMP traffic.
- Datagrams With Non-Unicast Source Address:
If a datagram's source address doesn't define a unique, unicast device
address, an error message cannot be sent back to that source. This prevents
ICMP messages from being broadcast, unicast, or sent to non-routable
special addresses such as the loopback
address.
Key Concept: In order to prevent excessive numbers of ICMP messages from being sent on a network, a special set of rules is put into place to govern when and how they may be created. Most of these are designed to eliminate situations where very large numbers of ICMP error messages would be generated in response to certain occurrences. |
These rules apply to both ICMPv4
and ICMPv6, but in ICMPv6 there are a couple of special cases. In certain
circumstances an ICMPv6 Packet Too Big message may be sent to
a multicast address, as this is required for Path
MTU Discovery to work. Certain Parameter
Problem messages may also be sent to multicast or broadcast addresses.
Finally, in addition to the rules above, IPv6 implementations are specifically
directed to limit the rate at which they send ICMPv6 messages overall.
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! |
|
|
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.
|