Extended ICMP to Support Multi-Part Messages
Extracted elements (22)
Appending additional information to existing ICMP messages (e.g., Time Exceeded) is preferred over defining new message types, avoiding the need to emit two separate ICMP messages whenever a packet is dropped due to TTL expiration.
Extensions were not defined for ICMPv6 'Packet Too Big' and 'Parameter Problem' messages because these messages lack space for a length attribute, making it impossible to delimit the 'original datagram' field from extension data.
The 128-octet minimum for the 'original datagram' field was chosen for backwards compatibility: classic applications that receive an ICMP message with extensions will misinterpret extensions as part of the original datagram, but this only affects applications that process beyond the 128th octet, which are extremely rare.
The length attribute for ICMPv4 and ICMPv6 was placed in previously reserved octets (sixth octet for ICMPv4, fifth octet for ICMPv6) so that the extension structure could be added without changing the positions of existing fields, enabling backwards compatibility.
ICMP extensions do not interfere with NAT as defined in RFC 3022, because the outermost IP header (the only field NAT modifies) is guaranteed to be contained within the first 128 octets of the 'original datagram' field. However, a non-conforming NAT that overwrites the length attribute with zeros produces a packet indistinguishable from a non-compliant ICMP implementation.
Non-compliant applications assume the ICMPv4 Extension Structure begins at the 137th octet (after 8 bytes of fixed header and 128 bytes of original datagram). They will only correctly parse compliant extensions if the 'original datagram' field contains exactly 128 octets.
Non-compliant ICMP implementations (produced 1999 to publication) may append the extension structure to Time Exceeded and Destination Unreachable messages with exactly 128 octets of original datagram and correct checksums, but without specifying the length attribute. Compliant applications receiving such messages will see a zero length attribute and incorrectly determine no extensions are present.
Compliant TRACEROUTE implementations MUST include a non-default operation mode to interpret non-compliant responses by parsing for a valid extension header at a fixed location assuming a 128-octet 'original datagram' field.
ICMP messages defined in the future SHOULD indicate whether or not they support the extension mechanism defined in this specification; it is recommended that all new messages support extensions.
The ICMP Extension Structure MUST NOT be appended to any ICMP messages other than ICMPv4 Destination Unreachable, Time Exceeded, and Parameter Problem, and ICMPv6 Destination Unreachable and Time Exceeded.
The length attribute MUST be specified when the ICMP Extension Structure is appended to the affected ICMPv4 (Destination Unreachable, Time Exceeded, Parameter Problem) and ICMPv6 (Destination Unreachable, Time Exceeded) messages.
The total length of the ICMP message, including extensions, MUST NOT exceed the minimum reassembly buffer size (576 octets for ICMPv4 or 1280 octets for ICMPv6).
When a compliant application receives an ICMP message and the length attribute is zero, it MUST determine that the message contains no extensions.
When the ICMP Extension Structure is appended to an ICMPv6 message with an 'original datagram' field, that field MUST be zero padded to the nearest 64-bit boundary.
The ICMP Extension Structure is an optional structure appended to the end of selected ICMP messages. It consists of exactly one Extension Header followed by one or more extension objects, each containing an object header and payload.
IANA has established a registry of ICMP Extension Object classes and class sub-types. Class-Num values 0xF7–0xFF are reserved for private use. Object class values are assignable on a first-come-first-served basis. Sub-type value assignment policy is defined per class.
This memo does not define conditions under which a router sends ICMP messages and therefore does not expose routers to new denial-of-service attacks, though routers may need to rate-limit ICMP message transmission.
Upon receipt of an ICMP message, application software must verify the extension checksum and check for syntactic correctness. Improperly specified length attributes and other syntax problems may result in buffer overruns.
Each ICMP Extension Object header is a 32-bit structure with a 16-bit Length field (total object length in octets including header), an 8-bit Class-Num field (object class), and an 8-bit C-Type field (object sub-type), followed by the object payload.
For ICMPv4 messages (Destination Unreachable, Time Exceeded, Parameter Problem), an 8-bit Length field is placed in the sixth octet (previously reserved) of the second word, representing the length of the padded 'original datagram' field measured in 32-bit words.
For ICMPv6 messages (Destination Unreachable, Time Exceeded), an 8-bit Length field is placed in the fifth octet (previously reserved) of the second word, representing the length of the padded 'original datagram' field measured in 64-bit words.
The ICMP Extension Header is a 32-bit structure with a 4-bit Version field (value 2), a 12-bit Reserved field (must be zero), and a 16-bit Checksum field containing the one's complement of the one's complement sum of the data structure.