datagram
Click on the red underlined text to get to the source
... extensibility. All of the ICMP messages addressed by this memo
include an "original datagram" field. The "original datagram" field
contains the initial octets ...
... ICMP messages addressed by this memo
include an "original datagram" field. The "original datagram" field
contains the initial octets of the datagram ...
... original datagram" field
contains the initial octets of the datagram that elicited the ICMP
error message. Although the "original datagram" field is of variable
...
... initial octets of the datagram that elicited the ICMP
error message. Although the "original datagram" field is of variable
length, the ICMP message does not include a field that specifies its
...
... length.
Application software infers the length of the "original datagram"
field from the total length of the ICMP message. If an extension
...
... ICMP message. If an extension
structure were appended to the message without adding a length
attribute for the "original datagram" field, the message would become
unparsable. Specifically, application software would not be able to
determine where the "original datagram ...
... original datagram" field, the message would become
unparsable. Specifically, application software would not be able to
determine where the "original datagram" field ends and where the
extension structure begins. Therefore, this document proposes a
length attribute as well as an extension structure that is appended
...
... Time Exceeded messages.
The above mentioned messages include an "original datagram" field,
and the message formats are updated to specify a length attribute
...
... and the message formats are updated to specify a length attribute
for the "original datagram" field.
When the ICMP Extension Structure ...
... ICMP message
and that ICMP message contains an "original datagram" field, the
"original datagram" field MUST contain at least 128 octets.
...
... ICMP message contains an "original datagram" field, the
"original datagram" field MUST contain at least 128 octets.
When the ICMP Extension Structure ...
... ICMPv4 message
and that ICMPv4 message contains an "original datagram" field, the
"original datagram" field MUST be zero padded to the nearest
...
... ICMPv4 message contains an "original datagram" field, the
"original datagram" field MUST be zero padded to the nearest
32-bit boundary.
...
... ICMPv6 message
and that ICMPv6 message contains an "original datagram" field, the
"original datagram" field MUST be zero padded to the nearest
...
... ICMPv6 message contains an "original datagram" field, the
"original datagram" field MUST be zero padded to the nearest
64-bit boundary.
...
... ICMPv6 Parameter Problem (type = 4)
These messages contain an "original datagram" field which represents
the leading octets of the datagram to which the ICMP message ...
... These messages contain an "original datagram" field which represents
the leading octets of the datagram to which the ICMP message is a
response. RFC 792std5 ...
... ICMP message is a
response. RFC 792std5 defines the "original datagram" field for ICMPv4
messages. In RFC 792std5, the "original datagram ...
... original datagram" field for ICMPv4
messages. In RFC 792std5, the "original datagram" field includes the IP
header plus the next eight octets of the original datagram ...
... original datagram" field includes the IP
header plus the next eight octets of the original datagram.
[RFC1812] extends the "original datagram ...
... original datagram.
[RFC1812] extends the "original datagram" field to contain as many
octets as possible without causing the ICMP message to exceed the
...
... buffer size (i.e., 576 octets). RFC 4443draft
defines the "original datagram" field for ICMPv6 messages. In RFC
4443draft ...
... ICMPv6 messages. In RFC
4443draft, the "original datagram" field always contained as many octets
as possible without causing the ICMP message to exceed the minimum
...
... 1280 octets).
Unfortunately, the "original datagram" field lacks a length
attribute. Application software infers the length of this field from
the total length of the ICMP message ...
... ICMP message. If an extension structure were
appended to the message without adding a length attribute for the
"original datagram" field, the message would become unparsable.
Specifically, application software would not be able to determine
where the "original datagram ...
... original datagram" field, the message would become unparsable.
Specifically, application software would not be able to determine
where the "original datagram" field ends and where the extension
structure begins.
...
... ICMP messages.
The length attribute represents the length of the "original datagram"
field. Space for the length attribute is claimed from reserved
octets, whose value was previously required to be zero.
...
... ICMPv4 messages, the length attribute represents 32-bit words.
When the length attribute is specified, the "original datagram" field
MUST be zero padded to the nearest 32-bit boundary. Because the
...
... ICMPv6 messages, the length attribute represents 64-bit words.
When the length attribute is specified, the "original datagram" field
MUST be zero padded to the nearest 64-bit boundary. Because the
...
... ICMP message and that ICMP message
contains an "original datagram" field, the "original datagram" field
MUST contain at least 128 octets. If the original datagram ...
... ICMP message
contains an "original datagram" field, the "original datagram" field
MUST contain at least 128 octets. If the original datagram did not
...
... original datagram" field, the "original datagram" field
MUST contain at least 128 octets. If the original datagram did not
contain 128 octets, the "original datagram" field MUST be zero padded
...
... MUST contain at least 128 octets. If the original datagram did not
contain 128 octets, the "original datagram" field MUST be zero padded
to 128 octets. (See Section 5.1 for rationale.)
...
... 792std5.
However, a length attribute is added to the second word. The length
attribute represents length of the padded "original datagram" field,
measured in 32-bit words.
...
... 792std5,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 32-bit words.
...
... 792std5,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 32-bit words.
...
... 4443draft.
However, a length attribute is added to the second word. The length
attribute represents length of the padded "original datagram" field,
measured in 64-bit words.
...
... 4443draft,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 64-bit words.
...
... Destination Unreachable messages. When they do this, they send
exactly 128 octets representing the original datagram, zero padding
if required. They also calculate checksums as described in this
...
... checksums as described in this
document. However, they do not specify a length attribute to be
associated with the "original datagram" field.
It is assumed that ICMP ...
... Classic applications do not parse extensions defined in this memo.
They are insensitive to the length attribute that is associated with
the "original datagram" field.
Non-compliant implementations parse the extensions defined in this
...
... conjunction with the Time Expired and Destination
Unreachable messages. They require the "original datagram" field to
contain exactly 128 octets and are insensitive to the length
attribute that is associated with the "original datagram ...
... original datagram" field to
contain exactly 128 octets and are insensitive to the length
attribute that is associated with the "original datagram" field.
Non-compliant applications were produced between 1999 and the time of
publication of this memo.
...
... ICMP message that includes
extensions, it will incorrectly interpret those extensions as being
part of the "original datagram" field. Fortunately, the extensions
are guaranteed to begin at least 128 octets beyond the beginning of
the "original datagram ...
... original datagram" field. Fortunately, the extensions
are guaranteed to begin at least 128 octets beyond the beginning of
the "original datagram" field. So, only those ICMP applications that
process the 129th octet of the "original datagram ...
... original datagram" field. So, only those ICMP applications that
process the 129th octet of the "original datagram" field will be
adversely effected. To date, only two applications falling into this
category have been identified, and the degree to which they are
...
... ICMP message for security
reasons. If the trailing octets of the original datagram field are
overwritten by ICMP extensions, the TCP ...
... Another theoretically possible, but highly improbably scenario occurs
when ICMP extensions overwrite the portion of the original datagram
field that represents the TCP header, causing the TCP ...
... unlikely because it occurs only when the TCP header appears at or
beyond the 128th octet of the original datagram field and then only
when the extensions approximate a valid TCP header ...
... the ICMPv4 Time Exceeded message, 128 octets for the "original
datagram" field, 4 octets for the ICMP Extension Header ...
... begins on the 137th octet of the Time Exceeded message, after a
128-octet field representing the padded "original datagram" message.
It is possible that a non-compliant application will parse an ICMPv4 ...
... - the message does not contain extensions
- the original datagram field contains 144 octets or more
- selected octets of the original datagram ...
... original datagram field contains 144 octets or more
- selected octets of the original datagram field represent the
correct values for an extension header version number ...
... compliant ICMP extensions, it will parse those extensions correctly
only if the "original datagram" field contains exactly 128 octets.
This is because non-compliant applications are insensitive to the
length attribute that is associated with the "original datagram ...
... original datagram" field contains exactly 128 octets.
This is because non-compliant applications are insensitive to the
length attribute that is associated with the "original datagram"
field. (They assume its value to be 128.)
...
... 1280 octets for
ICMPv6), there is no upper limit upon the length of the "original
datagram" field. However, each implementation will decide how many
octets to include. Those wishing to be backward compatible with non-
compliant TRACEROUTE ...
... When a compliant application receives an ICMP message, it examines
the length attribute that is associated with the "original datagram"
field. If the length attribute is zero, the compliant application
MUST determine that the message contains no extensions.
...
... When a compliant application receives an ICMP message, it examines
the length attribute that is associated with the "original datagram"
field. If the length attribute is zero, the compliant application
MUST determine that the message contains no extensions. In this
...
... not specify a length attribute, it will parse for a valid extension
header at a fixed location, assuming a 128-octet "original datagram"
field. If the application detects a valid version ...
... devices to modify selected fields within ICMP messages. These fields
include the "original datagram" field mentioned above. However, if a
NAT device modifies the "original datagram ...
... original datagram" field mentioned above. However, if a
NAT device modifies the "original datagram" field, it should modify
only the leading octets of that field, which represent the outermost
IP header ...
... IP header. Because the outermost IP header is guaranteed to be
contained by the first 128 octets of the "original datagram" field,
ICMP extensions and NAT ...