ELI (label 7) retains its meaning whether used as a regular special-purpose label or as an ESPL following XL, because deployed hardware looks for ELI without checking whether the preceding label is XL. This backward compatibility exception is explicitly carved out to avoid breaking existing deployments.

mpls

Protocol designers allocating a new special-purpose label SHOULD consider using an ESPL instead, to conserve the scarce 16-value normal special-purpose label space for cases where minimizing label stack depth is critical.

mpls

The Implicit NULL Label (value 3) is not permitted in the data plane for now. Any future reversal would require a Standards Track RFC addressing potential confusion between signaling use and data-plane use, plus mitigations.

mpls

The label retirement process is intentionally strict and multi-stage (deprecation RFC, survey, retirement RFC, minimum 24-month window) to avoid orphaning the value in existing deployments. The document notes the process should be used sparingly.

mpls

The original block of 16 special-purpose labels (values 0-15) is too small for experimental or private use ranges. The Extended Special-Purpose MPLS Label Values registry provides a much larger space (up to ~1M values) that can accommodate both standard allocations and an experimental range (240-255).

mpls

A label with value 0-15 that follows an XL does not retain its regular special-purpose meaning (with the sole exception of ELI/label 7). The XL context overrides normal interpretation, and most such values are illegal in that position.

mpls

Existing implementations that do not recognize XL will treat it as a single special-purpose label and will not expect an ESPL to follow. Consequently, if ESPLs appear in some packets of a flow, those packets may be load-balanced onto different paths and be reordered.

mpls

References to 'reserved labels' in RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790 should all be read as 'special-purpose labels' following the renaming introduced by this document.

mpls

Allocation of special-purpose MPLS labels requires Standards Action. A Standards Track RFC must accompany any request for such allocation, per RFC 5226 policy.

mpls, registry

An LSR SHOULD NOT make forwarding decisions on labels not at the top of the label stack. This applies to load-balancing decisions for XL/ESPL compound labels.

mpls

An LSR that encounters an ESPL at the top of the stack (after XL) that it does not understand MUST drop the packet. In either XL or ESPL drop case, the LSR MAY log the event but such logging MUST be rate-limited.

mpls

An LSR that encounters the XL at the top of the label stack and does not understand extension labels MUST drop the packet, following RFC 3031 procedures for invalid incoming labels.

mpls

ESPLs MUST NOT be used for load balancing, consistent with the same prohibition on regular special-purpose labels in RFC 6790. Existing implementations that do not recognize XL may violate this and reorder packets in a flow.

mpls

Retirement of a special-purpose label value requires IETF consensus with MPLS WG review, an Informational RFC to mark the value deprecated, a survey after 12 months, and a Standards Track RFC to release the value no earlier than 24 months after the deprecation RFC.

mpls, registry

The XL MUST be followed by another label L, and therefore MUST have the bottom-of-stack bit clear. L MUST be interpreted as an ESPL according to the Extended Special-Purpose MPLS Label Values registry.

mpls

Values 0-6 and 8-15 MUST NOT appear in the data plane immediately following an XL. An LSR receiving a packet whose label stack has XL at the top followed by a label with value 0-6 or 8-15 MUST drop the packet.

mpls

When an LSR inserts an Entropy Label, it MUST insert the Entropy Label Indicator (ELI, value 7) as a regular special-purpose label, not as an ESPL, to maintain backward compatibility with deployed hardware.

mpls

An Extended Special-Purpose Label (ESPL) is a label placed in the label stack immediately after the Extension Label (XL). The XL+ESPL pair acts as a compound label, allowing a much larger special-purpose label space beyond the original 16-value block.

mpls

The Extension Label (XL) is assigned value 15 in the Special-Purpose MPLS Label Values registry. It signals that the next label in the stack is an Extended Special-Purpose Label (ESPL), forming a compound two-entry label stack construct.

mpls

A new 'Extended Special-Purpose MPLS Label Values' registry is created with Standards Action allocation policy. Values 0-15 are reserved (never allocatable); 16-239 are unassigned; 240-255 are reserved for experimental use; 256-1048575 are reserved pending a new Standards Track RFC defining an allocation policy.

mpls, registry

The existing 'Multiprotocol Label Switching Architecture (MPLS) Label Values' registry is renamed to 'Special-Purpose MPLS Label Values' with allocation policy changed to Standards Action. Value 15 is assigned as the Extension Label (XL), citing this document.

mpls, registry

LSRs that drop packets due to unrecognized XL or ESPL MAY log the event, but logging MUST be rate-limited. Without rate-limiting, per-packet logging of crafted traffic could exhaust system resources.

mpls, security

The XL/ESPL mechanism provides a protocol-legal way to increase label stack depth by inserting additional {XL, ESPL} pairs. This could be exploited to attack nodes that can only process label stacks up to a certain depth, causing fragmentation or unprocessable packets.

mpls, security

The special-purpose label retirement lifecycle has three states: Active → Deprecated (via IETF consensus + Informational RFC, IANA marks 'deprecated') → Surveyed (12-month survey; repeat after 6 more months if still in use) → Retired (Standards Track RFC releases value ≥24 months after deprecation RFC, only if survey shows no remaining use).

mpls, registry