Summary

  • RFC 4950 defines an MPLS Label Stack Object for selected multi-part ICMP messages. It supports ICMPv4 and ICMPv6 and uses the extension structure and object headers defined by RFC 4884.
  • An LSR may append the label stack as it arrived at the reporting router while preserving the original IP header and leading payload octets. The object may accompany Time Exceeded and Destination Unreachable messages.
  • Enhanced traceroute can show both responding nodes and the original datagram’s MPLS encapsulation state at each responding node, subject to implementation, policy, filtering and TTL behavior.

The operational mechanism is narrow but useful. When an MPLS-encapsulated datagram becomes undeliverable and an LSR generates a qualifying error, ordinary ICMP can expose the IP datagram while omitting the labels that informed forwarding. RFC 4950 closes that diagnostic gap by carrying the complete incoming stack in an RFC 4884 extension object. It does not replace the original ICMP evidence: the original IP header and the leading payload octets remain part of the message.

The stack is encoded as four octets per entry. In the RFC 4950 description, an entry contains a 20-bit label, three experimental-use bits as named by the 2007 text, a one-bit bottom-of-stack flag, and an eight-bit TTL. Those fields describe what arrived at the reporting router. They are not a command, a route, an LSP authorization, an authentication result, an access grant or cryptographic proof. A disclosed label is not permission to alter forwarding and does not prove ownership, intent or policy compliance.

The practical fixture is a packet capture containing the ICMP type and code, the RFC 4884 extension header, the MPLS Label Stack Object and its object header. Decode every four-octet entry, record the label, experimental-use bits, bottom-of-stack bit and TTL, and separately preserve the quoted IP header and leading payload. Compare that capture with a classic ICMP response and with traceroute observations at the same test point. The comparison should establish what was observed, not claim a complete end-to-end path or a root cause.

A second fixture is a controlled matrix: vary the destination, the requested path or probe lifetime, and the depth of the arriving stack where policy permits. Record whether the response is Time Exceeded or Destination Unreachable, whether an object is present, how many entries are returned, and whether filtering or an intermediate device changes the result. Treat each result as local evidence from a reporting router. Do not infer that every hop returned equivalent information.

RFC 4950 does not define the general MPLS/ICMP relationship or an encapsulation-specific TTL manipulation model. RFC 3032 and related TTL behavior therefore matter to what a traceroute consumer can see, but this extension does not choose the TTL model. Procedures capable of defeating basic traceroute can also defeat the enhanced form. The RFC’s statement that the extension was widely deployed is historical context from the document, not evidence of current universal coverage, uniform vendor behavior or current disclosure defaults.

Operators may disclose the additional MPLS information selectively under policy, for example by destination address, global configuration or incoming label-stack depth. That policy is a governance choice, not a protocol guarantee. Absence of the object is not proof that the packet was not MPLS-encapsulated: unsupported implementations, selective disclosure, filtering, compatibility limits and TTL behavior can all suppress the observation.

Sources