ICMP messages can be categorized as follows:
- Messages that do not include any ICMP extensions
- Messages that include non-compliant ICMP extensions
- Messages that includes compliant ICMP extensions
Any ICMP implementation can send a message that does not include
extensions. ICMP implementations produced prior to 1999 are not
known to send ICMP extensions.
Some ICMP implementations, produced between 1999 and the time of this
publication, may send a non-compliant version of ICMP extensions
described in this memo. Specifically, these implementations may
append the ICMP Extension Structure to the Time Exceeded and
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
document. However, they do not specify a length attribute to be
associated with the "original datagram" field.
It is assumed that ICMP implementations produced in the future will
send ICMP extensions that are compliant with this specification.
Likewise, applications that consume ICMP messages can be categorized
as follows:
- Classic applications
- Non-compliant applications
- Compliant applications
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
memo, but only in 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" field.
Non-compliant applications were produced between 1999 and the time of
publication of this memo.
Compliant applications comply fully with the specifications of this
document.
In order to demonstrate backwards compatibility, Table 1 describes
how members of each application category would parse each category of
ICMP message.
+----------------+----------------+----------------+----------------+
| | No Extensions | Non-compliant | Compliant |
| | | Extensions | Extensions |
+----------------+----------------+----------------+----------------+
| Classic | - | Section 5.1 | Section 5.1 |
| Application | | | |
| | | | |
| Non-compliant | Section 5.2 | - | Section 5.3 |
| Application | | | |
| | | | |
| Compliant | Section 5.4 | Section 5.5 | - |
| Application | | | |
+----------------+----------------+----------------+----------------+
Table 1
In the table above, cells that contain a dash represent the nominal
case and require no explanation. In the following sections, we
assume that the ICMP message type is "Time Exceeded".
5.1. Classic Application Receives ICMP Message with Extensions
When a classic application receives an 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" 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
effected is minimal.
Some TCP stacks, when they receive an ICMP message, verify the
checksum in the original datagram field [ATTACKS]. If the checksum
is incorrect, the TCP stack discards the ICMP message for security
reasons. If the trailing octets of the original datagram field are
overwritten by ICMP extensions, the TCP stack will discard an ICMP
message that it would not otherwise have discarded. The impact of
this issue is considered to be minimal because many ICMP messages are
discarded for other reasons (e.g., ICMP filtering, network
congestion, checksum was incorrect because original datagram field
was truncated.)
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 stack to
operate upon the wrong TCP connection. This scenario is highly
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.
5.2. Non-Compliant Application Receives ICMP Message with No Extensions
When a non-compliant ICMPv4 application receives a message that
contains no extensions, the application examines the total length of
the ICMPv4 message. If the total ICMPv4 message length is less than
the length of its IP header plus 144 octets, the application
correctly determines that the message does not contain any
extensions.
The 144-octet sum is derived from 8 octets for the first two words of
the ICMPv4 Time Exceeded message, 128 octets for the "original
datagram" field, 4 octets for the ICMP Extension Header, and 4 octets
for a single ICMP Object header. All of these octets would be
required if extensions were present.
If the ICMPv4 payload contains 144 octets or more, the application
must examine the 137th octet to determine whether it represents a
valid ICMPv4 Extension Header. In order to represent a valid
Extension Header, it must contain a valid version number and
checksum. If it does not contain a valid version number and
checksum, the application correctly determines that the message does
not contain any extensions.
Non-compliant applications assume that the ICMPv4 Extension Structure
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
message incorrectly under the following conditions:
- the message does not contain extensions
- the 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 and
checksum
Although this is possible, it is very unlikely.
A similar analysis can be performed for ICMPv6. However, the numeric
constants would change as appropriate.
5.3. Non-Compliant Application Receives ICMP Message with Compliant
When a non-compliant application receives a message that contains
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"
field. (They assume its value to be 128.)
Provided that the entire ICMP message does not exceed the minimum
reassembly buffer size (576 octets for ICMPv4 or 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 implementations will include exactly 128 octets.
Those not requiring compatibility with non-compliant TRACEROUTE
applications may include more octets.
5.4. Compliant Application Receives ICMP Message with 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.
5.5. Compliant Application Receives ICMP Message with Non-Compliant
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
case, that determination is technically correct, but not backwards
compatible with the non-compliant implementation that originated the
ICMP message.
So, to ease transition yet encourage compliant implementation,
compliant TRACEROUTE implementations MUST include a non-default
operation mode to also interpret non-compliant responses.
Specifically, when a TRACEROUTE application operating in non-
compliant mode receives a sufficiently long ICMP message that does
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 and checksum, it
will treat the octets that follow as an extension structure.
