ICMP Extensions for Multiprotocol Label Switching
Extracted elements (12)
ICMP messages generated by an LSR contain no information about the MPLS label stack that encapsulated the original datagram, yet the LSR forwarded the datagram based on that label stack. This omission motivated the extension object defined in this memo, enabling TRACEROUTE to reflect the MPLS encapsulation status at each hop.
The extension has already been widely deployed prior to standardization, which motivated defining it as a standards-track document to formalize existing practice.
The ICMP extension defined in this document is equally applicable to ICMPv4 (RFC 792) and ICMPv6 (RFC 4443). Throughout the document, ICMP refers to multi-part ICMP messages encompassing both versions.
The MPLS Label Stack Object must be preceded by an ICMP Extension Structure Header and an ICMP Object Header, both defined in RFC 4884. This document's extensions depend on the RFC 4884 multi-part ICMP framework.
When encapsulation-specific TTL manipulation procedures (as defined in RFC 3034 and RFC 3035) defeat the basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE implementations that use the MPLS Label Stack Object extension.
Selected ICMP messages SHOULD include the MPLS label stack as it arrived at the router sending the ICMP message. The ICMP message MUST also include the IP header and leading payload octets of the original datagram.
The MPLS Label Stack Object has Class-Num = 1 (MPLS Label Stack Class) and C-Type = 1 (Incoming MPLS Label Stack). Octets 0-3 depict the first member of the MPLS label stack, with each remaining member represented by another 4 octets in the same format.
The MPLS Label Stack Object is appended to ICMP Time Exceeded and Destination Unreachable messages. A single instance represents the entire MPLS label stack exactly as it arrived at the LSR sending the ICMP message. It must be preceded by an ICMP Extension Structure Header and an ICMP Object Header as defined in RFC 4884.
IANA assigned Class-Num 1 (MPLS Label Stack Class) in the ICMP Extension Object registry. A new registry for the corresponding C-Type subtype space was established: C-Type 0 is Reserved, C-Type 1 is Incoming MPLS Label Stack, 0x02-0xF6 are available for assignment on FCFS basis, and 0xF7-0xFF are reserved for private use.
An operator can use the TTL treatment on MPLS Pipe Model LSPs (RFC 3443) for a TTL-transparent mode of operation that prevents ICMP Time Exceeded messages altogether when tunneling over an MPLS LSP, which also prevents disclosure of MPLS topology information.
Network operators may wish to selectively provide MPLS extension information in ICMP messages based on policy, for example only including MPLS extensions in messages destined to network management address blocks. An implementation could gate inclusion on the destination address of the ICMP message, a global configuration option, or the depth of the incoming label stack.
Each MPLS label stack entry in the object payload is encoded as 4 octets: a 20-bit Label field, a 3-bit Exp (Experimental Use) field, a 1-bit S (Bottom of Stack) field, and an 8-bit TTL field. The total object length is 4 + 4*(number of MPLS LSEs).