IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack
updates
- rfc-4928 — Avoiding Equal Cost Multipath Treatment in MPLS Networks
Extracted elements (16)
A consequence of the legacy heuristic is that values 0x4 and 0x6 are permanently associated with IPv4 and IPv6 identification by legacy devices, regardless of future IP version assignments. This means no new IP version number other than 0x4 or 0x6 will trigger heuristic load balancing on legacy routers, making concerns about future IP versions with numbers 0x0 or 0x1 irrelevant.
A registry is needed because the MPLS Network Actions (MNA) framework (RFC 9789) may place Post-Stack Data with values in the PFN position, potentially conflicting with other PSH uses. The ambiguity of PFN value 0x0 (used by both pseudowire control words and DetNet control words with different formats) further illustrates why formal tracking is required.
Because the PFN space is limited to 16 values and the PFN cannot be interpreted correctly without control/management plane context from the preceding label stack, reuse of PFN values across different protocols is explicitly encouraged when possible. The PFN value 0x0, for instance, is already shared by PW, DetNet, and NSH.
The heuristic for ECMP load balancing reads the PFN: 0x4 is treated as IPv4, 0x6 as IPv6, and anything else falls back to label-stack-based balancing. However, this fails badly for non-IP payloads such as Ethernet frames, where the first nibble of the destination MAC OUI can be 0x4 or 0x6, causing the frame to be misidentified as IP and resulting in unpredictable load balancing.
The 'Post-Stack First Nibble' registry and the 'IP Version Numbers' registry (RFC 2780) serve entirely different purposes: the former tracks PSH types, the latter tracks IP version numbers in IP headers. Their only intersection is values 0x4 and 0x6, which are reserved in the PFN registry for backward compatibility with legacy routers that heuristically identify IPv4 and IPv6.
Using a dedicated label for load balancing (Entropy Label or FAT PW Label) is identified as the best of four load-balancing approaches because it provides reliable and deterministic entropy without requiring payload-type guessing. The heuristic approach led to the workaround of inserting PSHs with non-IP PFNs purely to prevent misidentification, which this document aims to eventually make unnecessary.
This document updates RFC 4928 by replacing its heuristic-based first-nibble snooping guidance with a positive requirement to use a PSH with PFN not equal to 0x4 or 0x6 for all non-IP payloads, and by deprecating the payload-type guessing heuristic entirely. The intent is that legacy routers continue operating unchanged while new implementations follow the updated rules.
Network equipment MUST use a PSH (Post-Stack Header) with a PFN value that is neither 0x4 nor 0x6 in all cases where the MPLS payload is neither an IPv4 nor an IPv6 packet. This requirement replaces the older RFC 4928 text restricting PFN values to 0x0 and 0x1 for in-order delivery.
The heuristic of guessing the type of the MPLS-embedded packet from the PFN for ECMP load balancing SHOULD NOT be used in any implementation.
The practice of deducing the MPLS payload type based on the PFN value is deprecated; this MUST NOT be part of new implementations or deployments. This supersedes the heuristic method described in RFC 4928.
Where load balancing of MPLS packets is desired, it is RECOMMENDED that the load-balancing mechanism use the value of a dedicated label, for example an Entropy Label (RFC 6790) or a FAT Pseudowire Label (RFC 6391), rather than inspecting the PFN.
A Post-Stack Header (PSH) is a field between the label stack and the embedded packet containing information of interest to egress or transit LSRs. Examples include pseudowire control words (RFC 4385), DetNet control words (RFC 8964), associated channel headers (RFC 5586, RFC 9546), BIER headers (RFC 8296), and NSH (RFC 8300). Any MPLS packet not carrying plain IPv4 or IPv6 contains a PSH.
The Post-stack First Nibble (PFN) is defined as the most significant four bits of the first octet immediately following the MPLS label stack. Its correct interpretation can be made only in the context established through the control or management plane by the Label Stack Entry (or group of LSEs) that characterizes the PSH type; it cannot be used alone to deduce the PSH type.
IANA has created a 'Post-Stack First Nibble' registry group containing a single registry covering all 16 possible 4-bit PFN values (0x0–0xF) immediately following an MPLS label stack. The assignment policy is Standards Action. Initial entries include 0x0 (PW/DetNet/NSH control words), 0x1 (associated channel headers), 0x2 (NSH OAM header), 0x4 and 0x6 (reserved for IPv4/IPv6 backward compatibility), and 0x5 (BIER header); 0x3 and 0x7–0xF are unassigned.
Errors in determining whether an MPLS-encapsulated packet is IP have primarily caused unbalanced multipathing, but carry the potential for more severe security problems. Creating the PFN registry and deprecating the heuristic payload-identification approach aims to reduce or eliminate these errors. General MPLS label stack security considerations are addressed in RFC 3032.
An MPLS label stack consists of consecutive 4-octet Label Stack Entries, each encoding a 20-bit label, a 3-bit TC (Traffic Class) field, a 1-bit Bottom-of-Stack flag (S), and an 8-bit TTL. The Bottom-of-Stack flag is set in the final entry. The PFN is the top 4 bits of the first byte immediately after the last label stack entry.