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.
|
|
|
|
ICMPv4 Parameter Problem Messages
(Page 1 of 2)
The previous topics in this section
describe four specific ICMPv4 message types that allow a device to report
various error conditions to the original sender of a datagram. However,
other error situations may arise also that don't correspond to any of
these four specific message types. Typically, the problem results when
a device attempts to process the header fields of an IP datagram and
finds something in it that doesn't make sense.
If a device finds a problem with
any of the parameters in an IP datagram header that is serious enough
that it cannot complete processing the header, it must discard the datagram.
Like other cases where a datagram must be tossed out, this is serious
enough to warrant communication of the problem back to the device that
sent the original datagram. This is accomplished in ICMPv4 using the
Parameter Problem message type.
This is a catch all type
of message that can be used to indicate an error in any header field
of an IP datagram. The message type does not contain any specific fields
or coding to indicate what the problem is. This was done intentionally
to keep the Parameter Problem message generic and
ensure that it could indicate any sort of error. Instead of special
error codes, most Parameter Problem messages tell the original
source which parameter caused the problem by including a special pointer
that indicates which field in the original datagram header caused the
problem.
ICMPv4 Parameter Problem Message Format
Table 94
and Figure 145
show the format for ICMPv4 Parameter Problem messages.
Table 94: ICMPv4 Parameter Problem Message Format
Field
Name
|
Size (bytes)
|
Description
|
Type
|
1
|
Type: Identifies
the ICMP message type; for Parameter Problem messages this value
is 12.
|
Code
|
1
|
Code:
Identifies the subtype of problem being communicated. See
Table 95
for more information on this field for Parameter Problem messages.
|
Checksum
|
2
|
Checksum: 16-bit
checksum field for the ICMP header, as described in the
topic on the ICMP common message format.
|
Pointer
|
1
|
Pointer:
An offset that points to the byte location in the datagram that caused
the Parameter Problem message to be generated. The device receiving
the ICMP message can use this value to get an idea of which field in
the original message had the problem.
This field is used only when the Code value is 0.
|
Unused
|
3
|
Unused: 3 bytes
that are left blank and not used.
|
Original
Datagram Portion
|
Variable
|
Original
Datagram Portion: The full IP header and the first 8 bytes of
the payload of the datagram that prompted this error message to be sent.
|
|