Summary

  • An ordinary ICMP quotation could preserve the IP datagram while losing the MPLS stack that had determined forwarding. RFC 4950 added the stack as it arrived at the reporting router.
  • The addition retained the IP quotation and used a separately framed object. Its registered format did not turn locally significant label values into global identities.
  • More detail in an error did not guarantee more visible hops. Legacy parsing, TTL treatment, the error’s return journey and selective disclosure remained separate constraints.

The evidence was outside the quotation

There is a revealing sequence at the start of RFC 4950. A label-switching router receives an MPLS-encapsulated datagram it cannot deliver. It removes the entire label stack, exposing the IP datagram, and submits that datagram to error processing.

An ICMP message can then state why delivery failed. It can also include the IP header and the leading bytes of the original payload. Yet it contains no account of the stack that surrounded the packet when it entered the router.

The omission matters because that was the stack the router would have consulted to forward the packet. The quotation could be accurate while leaving out the relevant forwarding context. It was not necessarily a corrupted record. It was a record drawn around the wrong boundary for this particular diagnostic question.

Published in August 2007, RFC 4950 supplied an extension object for that missing context. Selected error messages should carry the incoming MPLS stack. They must still carry the original IP header and leading payload. The new evidence supplements the quotation; it does not replace it.

The important change was not simply that an error could be longer. It was that the report could preserve something the transition into IP error processing would otherwise leave behind.

A quotation originally meant to find the conversation

The earlier purpose is visible in RFC 792, published in September 1981. Its Time Exceeded format included the Internet header and the first 64 bits of the original datagram’s data. Those eight data bytes helped the receiving host associate the error with the appropriate process. Where the higher-level protocol used ports, the specification expected those numbers near the beginning.

This was a way to connect a failure to the communication that caused it. It was not a promise to reproduce all the state used by intermediate systems. Nor should the historical format be mistaken for a claim that every later ICMP message always quoted exactly eight payload bytes.

MPLS introduced a particularly clear mismatch between the quoted layer and the forwarding layer. Its stack sits before the network-layer header, after the data-link headers. Extending the quotation farther into the IP payload does not automatically recover the stack that has already been stripped off.

RFC 3032, from January 2001, describes each label-stack entry as four octets. The top entry comes first. The S bit identifies the bottom entry. Looking up the top label yields a next hop and an operation on the stack: replacing a label, popping an entry, or replacing the top and pushing further entries.

These are not decorative annotations on an otherwise complete IP account. They can be the state through which the router decides what to do next.

Arrival is a specific moment

RFC 4950’s object has a narrow temporal claim. One instance represents the entire MPLS stack, in the format and order in which it arrived at the router generating the error.

It does not claim to show the outgoing stack after successful processing. It is not a dump of the router’s configuration at the time somebody later reads the report. It does not say which labels would have applied to a different packet.

The object can be appended to Time Exceeded and Destination Unreachable messages, for both ICMPv4 and ICMPv6. That is not a general invitation to attach it to every ICMP message type.

Its object header uses Class-Num 1 and C-Type 1. The object’s length is four octets for that header plus four for every stack entry. A three-entry stack therefore produces a sixteen-octet object. This is a constructed size example, not a packet capture. The separate extension header that precedes the object is not included in that sixteen.

Each entry carries a twenty-bit label, three bits then called EXP, one S bit and eight TTL bits. In February 2009, RFC 5462 renamed EXP to Traffic Class, or TC, and clarified its intended use. The change did not enlarge the stack entry.

A historical display can therefore use an old field name without giving a present-day operator permission to treat the bits as an unrestricted experimental space. The date and meaning of a format matter as much as the numbers a tool prints.

A shared object type is not a shared label identity

The common object class makes independently written readers agree about the structure of the report. It does not make every number inside that structure globally meaningful.

RFC 3031 defines an MPLS label as a locally significant identifier for a forwarding equivalence class. It is not an encoding of the network-layer destination address. The applicable binding and label space determine what it means.

If two routers print the same value, that alone does not establish one permanent object crossing both routers. A path can use different values as packets move between forwarding contexts. A repeated value can belong to different contexts.

The distinction limits what can be reconstructed from a tidy traceroute display. A sequence of numbers looks easy to join into a map. But their interpretation requires the reporting location and the relevant local state, not just arithmetic equality.

IANA’s assignment of the extension class and subtype, recorded in RFC 4950, coordinates the vocabulary of the report. It does not allocate the individual labels the report describes. Standardizing how evidence is carried is a smaller act than governing the network that produces it.

The boundary had to survive existing software

The stack object relied on RFC 4884, published four months earlier. That document defined a multipart structure for selected ICMP messages: an original-datagram quotation, an extension header and one or more extension objects.

A reader needs to know where the quotation stops. RFC 4884 supplied an eight-bit length attribute using space previously reserved. For ICMPv4 the unit is a 32-bit word; for ICMPv6 it is a 64-bit word. With extensions, the quoted region must contain at least 128 octets, padded with zeros when the original is shorter, and aligned to the appropriate boundary.

The minimum was also a compatibility device. The document describes implementations produced between 1999 and its publication that had already put extensions after exactly 128 quoted octets without specifying the new length attribute.

Some readers consequently looked at a fixed position. They did not follow an explicit length. A new sender could include a longer quotation, but an old extension-aware reader would still look where it expected the extension to begin.

For senders that wanted compatibility with those readers, the practical choice was exactly 128 octets. Senders without that requirement could include more, subject to the message-size limits. What was a minimum in the revised format remained a fixed boundary for deployed software.

This was not costless backward compatibility. Classic applications that knew nothing about extensions could treat the added bytes as part of the quoted original. RFC 4884 examined the known consequences; it did not promise that every older application would be unaffected.

Default interpretation and historical accommodation

A compliant application receiving a zero length attribute must normally determine that there are no extensions. That rule is clear but misses an extension emitted by an older implementation that never set the attribute.

RFC 4884 therefore required compliant traceroute implementations to provide a non-default mode for the older behavior. Given a sufficiently long message without a length, that mode could inspect the fixed location after a 128-octet quotation and look for a valid extension version and checksum.

The exception was explicit. A reader did not have to make every ordinary interpretation depend on an unannounced guess. An operator could select a mode intended to recognize a particular historical practice.

The extension header uses version 2. Its checksum is a structural check, not a cryptographic credential; an all-zero checksum value means none was transmitted. Object lengths are measured in octets, including their own header and payload. An unrecognized object does not by itself make the ICMP message malformed.

That flexibility still requires careful parsing. Incorrect length attributes are not merely an inconvenience for a display; they can create unsafe reads. A receiver needs syntax checks as well as a policy about which objects it understands.

The ability to decode the stack also does not establish who truly sent the report. Format validity, association with a probe and authentication of the reporting source remain different questions.

Two stacks with different jobs

There is another way labels can become involved in an ICMP error. It appears in RFC 3032’s account of returning errors through an MPLS domain.

An interior router may not know how to route directly to the original IP source. One described technique is to put the generated ICMP message into a label-switched envelope and send it initially toward the original destination. It can eventually reach a router that knows how to route back to the source.

The label values can be copied, while their TTLs are set for the new message’s journey. Those labels are active forwarding state around the error report. They are not the RFC 4950 object inside the report, which records the original packet’s arrival state.

The distinction matters even when the values look similar. A report can preserve one packet’s incoming stack while another stack carries the report along a circuitous return route.

A displayed round-trip time includes that return. Adding an incoming-stack object does not let an observer assign all the measured delay to a particular forward link. It enriches the evidence without eliminating the asymmetry of the measurement.

More contents do not guarantee more responses

RFC 4950 expressly declines to redefine the general relationship between ICMP and MPLS or the TTL handling specific to different encapsulations. If that handling defeats ordinary traceroute, it defeats the enhanced form too.

RFC 3443, published in January 2003, distinguishes relevant TTL models. Uniform processing synchronizes inner and outer TTLs at the tunnel’s entry and exit. Pipe and Short Pipe models can use an outer starting value unrelated to the inner one.

An inner probe can therefore fail to provoke the hop-by-hop Time Exceeded responses its sender expects while crossing the label-switched path. This does not mean the outer TTL is unlimited, or that every possible ICMP error is forbidden. It means that the measurement’s trigger is not guaranteed merely because its response format has improved.

Disclosure is another independent choice. RFC 4950 discusses including the stack according to the destination of the ICMP message—for example, management address blocks—or according to a global setting or the depth of the incoming stack.

An observer who receives no label line cannot isolate the cause from that absence alone. The information may not have been emitted, delivered, disclosed or recognized. Absence of the object is not sufficient proof of absence of MPLS.

The document said in 2007 that the mechanism was already widely deployed. That is a historical statement in the specification, not a current census or evidence that every network adopted it on publication day.

The gain was both real and bounded. A report could retain a forwarding context that had once fallen outside its quotation. It could not convert one observer’s partial view into an exhaustive description of the network.