skip to content

What does RFC 4884 add to ICMP error messages, and how does a receiver find where the quoted datagram ends?

level: seniorimportance: nice to knowfreq 8%

answer

  1. more than a quote
  2. a length in a reserved octet
  3. padded to 128 octets
  4. version 2 header, then objects
  5. Length, Class-Num, C-Type

basics

~20 s

RFC 4884 lets certain ICMP errors carry an Extension Structure after the quoted datagram. A length attribute in a formerly reserved octet gives the padded quote's length, so receivers know where the extension header and objects begin.

solid answer

~50 s

Before RFC 4884, an ICMP error's quoted datagram ran to the end of the message, so nothing could be appended. RFC 4884 claims a previously reserved octet of the rest-of-header word for a **length attribute** giving the length of the padded original-datagram field: the sixth octet in ICMPv4, counted in 32-bit words, and the fifth octet in ICMPv6, counted in 64-bit words. After that field comes an **ICMP Extension Structure**: a 4-byte extension header (4-bit `Version` = 2, 12 reserved bits, 16-bit `Checksum`, zero meaning none) and one or more objects, each with a 16-bit `Length`, 8-bit `Class-Num` and 8-bit `C-Type`. Extensions may be appended to ICMPv4 Destination Unreachable, Time Exceeded and Parameter Problem, and to ICMPv6 Destination Unreachable and Time Exceeded. When present, the quote must be at least 128 octets, zero-padded, for compatibility with earlier implementations.

go deeper

for a junior

Recall that RFC 4884 lets some ICMP errors carry extra data after the quoted packet, using a length field so receivers know where the quote stops.

for a middle

Explain where the length attribute sits in ICMPv4 and ICMPv6, its units, and which error messages may carry extensions.

for a senior

Explain the 128-octet padding rule and how compliant and older receivers each find the extension header, plus the validation a parser must do first.

for a principal

Weigh retrofitting a structured extension into a format that had none: what backward compatibility cost, and why reserved fields in a header are worth keeping.

## The problem: the quote ran to the end An ICMP error is an 8-byte header followed by a quotation of the datagram that caused it. RFC 792 quoted the IP header plus 8 bytes; RFC 1812 let routers quote up to 576 bytes in total; ICMPv6 quotes up to the 1,280-octet minimum IPv6 MTU. In every case the quote simply **ran to the end of the message**, with no length field, so a receiver could not tell where it stopped. Anything appended after it would have been read as more quote. Routers had useful facts to add, such as the MPLS label stack a probe was carrying or which interface received it, so **RFC 4884** (Standards Track, 2007) defined a way to append structured data without breaking existing parsers. ## The length attribute RFC 4884 takes space for a **length attribute** from octets "whose value was previously required to be zero": | | ICMPv4 | ICMPv6 | |---|---|---| | Location | sixth octet of the message | fifth octet of the message | | Unit | 32-bit words | 64-bit words | | Quote padded to | next 32-bit boundary | next 64-bit boundary | | Overall size limit | 576 octets | 1,280 octets | The attribute gives the length of the **padded original-datagram field**. In an ICMPv4 fragmentation-needed message, RFC 1191's Next-Hop MTU keeps the low-order 16 bits, so the two fields coexist in the same word. ## Which messages may carry extensions - ICMPv4 **Destination Unreachable** (type 3), **Time Exceeded** (type 11), **Parameter Problem** (type 12). - ICMPv6 **Destination Unreachable** and **Time Exceeded**. - **Not** ICMPv6 Packet Too Big or ICMPv6 Parameter Problem: their second word is fully used by the MTU and the pointer, so there is no room for a length attribute. - **Not** queries such as Echo, and not Redirect. ## The extension structure After the padded quote comes exactly one **extension header** followed by one or more **objects**: 1. Extension header, 4 bytes: `Version` (4 bits, value 2), reserved (12 bits, zero), `Checksum` (16 bits, the one's-complement checksum over the extension structure; all zeros means none was sent). 2. Each object: an object header of `Length` (16 bits, octets including the header), `Class-Num` (8 bits, the object class) and `C-Type` (8 bits, the sub-type), followed by its payload. A receiver **may process the objects it understands and ignore the rest**; an unrecognised object does not make the message malformed. The total, extensions included, must still fit the minimum reassembly size: 576 octets for ICMPv4, 1,280 for ICMPv6. ## The 128-octet rule and backwards compatibility Some implementations, produced between 1999 and RFC 4884's publication, sent extensions **without** a length attribute and assumed the quote was **exactly 128 octets**. To interoperate with them, RFC 4884 requires that whenever extensions are appended, the original-datagram field is **at least 128 octets**, zero-padded if the original was shorter. The resulting cases: - **Compliant receiver**: reads the length attribute and jumps straight to the extension header. - **Old receiver, compliant sender using exactly 128 octets**: still finds the extensions at the 137th octet of the ICMPv4 payload, after the 8-byte header and the 128-octet quote. - **Old receiver, plain message**: if the payload is shorter than 144 octets (8 + 128 + 4 + 4), it correctly decides there are no extensions; if longer, it tests the 137th octet for a valid version and checksum. ## Why it matters in practice The main consumer is path tracing: an extended Time Exceeded lets a router report, alongside the quoted probe, the labels it was switching on or the interface the probe arrived on. RFC 4884's security section says a receiver must check the message for syntactic correctness before using it, because an improperly specified length attribute can cause buffer overruns in a careless parser. In practice that means: - confirm the length attribute points inside the received message and that the extension header carries version 2; - verify the extension checksum unless it is all zeros, which means none was sent; - walk the objects by their own `Length` fields, skipping any `Class-Num` it does not understand rather than rejecting the message.

  • Why does RFC 4884 require the quoted datagram to be at least 128 octets whenever extensions are appended?
    For compatibility with implementations deployed from 1999 onward that sent extensions without a length attribute and assumed the quote was exactly 128 octets. Padding to at least 128 octets keeps the old layout possible: a sender wanting compatibility with older traceroute implementations includes exactly 128 octets, so the extension header sits where those parsers look, while compliant receivers simply follow the length attribute.
  • Why can't RFC 4884 extensions be appended to ICMPv6 Packet Too Big messages?
    Because the message has no spare octet for a length attribute: its second 32-bit word is entirely the MTU value. The same applies to ICMPv6 Parameter Problem, whose second word is the pointer. RFC 4884 therefore defines extensions only for ICMPv4 Destination Unreachable, Time Exceeded and Parameter Problem, and ICMPv6 Destination Unreachable and Time Exceeded.

saying these in an interview costs you the question

  • RFC 4884 extensions can be appended to any ICMP message, Echo replies included.
  • The RFC 4884 length attribute counts the quoted datagram in bytes.
  • With extensions an ICMPv4 error may grow past 576 bytes.
  • A receiver that meets an unknown extension object must discard the whole message.
  • RFC 4884 defines a new ICMP type for multipart messages.