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 Book is Here... and Now On Sale!

The whole site in one document for easy reference!
The TCP/IP Guide

Custom Search







Table Of Contents  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 Concepts and General Operation

Previous Topic/Section
ICMP Message Classes, Types and Codes
Previous Page
Pages in Current Topic/Section
1
2
3
Next Page
ICMP Common Message Format and Data Encapsulation
Next Topic/Section

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.


Previous Topic/Section
ICMP Message Classes, Types and Codes
Previous Page
Pages in Current Topic/Section
1
2
3
Next Page
ICMP Common Message Format and Data Encapsulation
Next Topic/Section

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!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.