Summary

  • RFC 9790 deprecates identifying an MPLS payload from the first four bits after the label stack. 0x4 and 0x6 can resemble IPv4 and IPv6 while belonging to a non-IP frame or Post-Stack Header.
  • Correct interpretation comes from the preceding label context. For load balancing, an explicit Entropy Label or FAT Pseudowire Label is stronger evidence than fields read from a packet type the transit router merely guessed.
  • A registry assignment, control word or entropy label narrows ambiguity; none proves implementation, path choice, balanced utilization, packet order or customer outcome without a separate running-data-plane receipt.

The transit router sees the bottom of an MPLS label stack. The next four bits are 0100. Its legacy parser calls them an IPv4 version field, skips to the offsets where source and destination addresses and transport ports ought to be, and feeds those bytes into an ECMP hash.

But the packet is not IPv4. It is an Ethernet frame carried by a pseudowire, and 0100 is simply the beginning of the destination MAC address. The router has converted resemblance into identity. It may now split packets using fields that have no meaning under the imagined format, sending one ordered flow across inconsistent paths.

RFC 9790 closes that inference gap for new MPLS implementations and deployments. Its subject is a four-bit registry. Its operational lesson is much larger: visibility is not context, and context is not outcome.

The nibble is an observation

An MPLS packet begins with a Layer 2 header and a stack of four-octet Label Stack Entries. The Bottom-of-Stack bit identifies the final entry. What follows can be a bare IPv4 or IPv6 packet, a non-IP Layer 2 frame, or one or more Post-Stack Headers before an embedded packet.

The Post-stack First Nibble, or PFN, is only the most significant four bits of the first octet after that stack. For a bare IPv4 packet it overlaps the version value 4; for bare IPv6 it overlaps 6. In every other case it belongs to whichever structure actually begins there.

The label stack contains no general payload-type identifier. RFC 9790 therefore says the PFN can be interpreted correctly only in the context established through the control or management plane for the preceding Label Stack Entry or group of entries. A capture can prove which bits were present. It cannot, by those bits alone, prove what structure produced them.

That is the reality-layer boundary. A parser observes four bits. A service or label binding supplies expected semantics. A decoder applies a format. Each statement has a different source of authority.

A useful guess became a hidden forwarding policy

The old heuristic is attractive because IP exposes rich flow keys. When the PFN is 0x4, equipment may treat what follows as IPv4; when it is 0x6, as IPv6. It then reads a presumed five-tuple and uses it for LAG or ECMP selection. Any other value sends the implementation back to a coarser hash over the label stack.

That can distribute real IP flows better than a top-label hash. The cost appears when the premise is false. An Ethernet destination address can begin with 0x4 or 0x6. RFC 8469 notes that assigned addresses do so and that randomized local MAC addresses reach either pattern often enough to make the case operationally real. Without a pseudowire control word, forwarding equipment can mistake the frame for IP.

The resulting harm is not merely an incorrect label in telemetry. The device reads unrelated bytes at IP-header offsets, creates unstable or inappropriate hash keys and may reorder packets. Classification or differential treatment can also go wrong on a single path when a forwarder applies policy to a format it invented.

The heuristic has therefore become policy: it chooses which bytes matter, how flows are defined and which component link carries them. Yet its evidence is four unauthenticated bits detached from the scope that gives them meaning.

Context lives before the bytes being parsed

RFC 9790 reverses the direction of inference. The correct question is not “what do these four bits resemble?” It is “what did the preceding label context say may follow?”

For any MPLS payload that is neither IPv4 nor IPv6, the RFC requires a Post-Stack Header with a PFN other than 0x4 or 0x6. A pseudowire control word is one such separator. The value is deliberately chosen so old forwarding engines do not reach for an IP parser. The header does not make the packet trustworthy; it makes one ambiguity avoidable.

The context can be service-specific. PFN 0x0 is used for DetNet, Network Service Header and pseudowire control-word formats. PFN 0x1 is also reused by several associated-channel formats. Reuse is not a registry defect. The preceding label binding is what disambiguates them. Treating the nibble as globally unique would discard the architecture the registry is documenting.

This is Minimum Initial Specification in a compact form. The common layer records the small set of values and references needed for interoperable parsing. Local nodes still validate the packet against the label and service context they actually hold. The registry coordinates meaning; it does not inspect the packet or command the forwarding result.

Two registries do not create one namespace

The confusion around 0x4 and 0x6 also reaches IANA. The IP Version Numbers registry records version values inside an IP header. The Post-Stack First Nibble registry records types of Post-Stack Header. Their purposes differ, and RFC 9790 says their only intersection is 4 and 6 for backward compatibility.

The new PFN registry covers all sixteen possible values. It initially records several uses, reserves 4 and 6, and applies Standards Action to new assignments. That gives implementers a reference and makes collisions visible.

It does not turn a registry lookup into packet identification. A row proves that a standard assigned or documented a value under stated conditions. It does not prove that this packet meets those conditions, that the preceding label carries the expected service, that a line card implements the cited parser, or that a deployment enabled it. A registry is evidence about specification state, not a witness to runtime state.

Put entropy where the context exists

RFC 9790 recommends a dedicated label for MPLS load balancing: an Entropy Label under RFC 6790 or a FAT Pseudowire Label under RFC 6391. The design moves the decision to the ingress, where the packet has not yet been buried under MPLS encapsulation and the service context is available.

The ingress selects legitimate flow fields, runs its load-balancing function and places the result in the label stack. With RFC 6790, reserved label value 7 acts as the Entropy Label Indicator immediately before the Entropy Label. Transit routers can hash the stack without pretending to understand the embedded packet.

This is an allocation of knowledge, not a promise of perfection. The ingress knows more, so it extracts the entropy. The core knows less, so it consumes an explicit token. Capability signaling and stack-depth constraints still matter. A badly chosen ingress hash can remain imbalanced. A correct entropy label can still map large flows onto one member. The label proves what value was carried, not whether capacity, latency or ordering met the service objective.

FAT pseudowires add another scope boundary. Flow-aware operation is optional; one-path forwarding remains the default. Endpoints signal transmit and receive capability or provision it identically for static pseudowires. Seeing a flow label on one packet cannot prove that both endpoints agreed, that every transit node used it, or that the selected path remained stable.

Deprecation is a direction, not disappearance

RFC 9790 updates RFC 4928 and says payload-type deduction from PFN must not be part of new implementations or deployments. It intentionally allows legacy routers to continue their existing behavior. It also says that later obsoletion work needs evidence about marketed and deployed equipment still using the heuristic.

That makes migration a mixed-estate problem. A standards publication changes the normative design boundary. It does not flash new forwarding logic into installed hardware. A network may contain line cards, software trains and service classes with different parsing behavior. Documentation may say the heuristic is retired while a deep packet inspection profile still applies it on one path.

Leadership should resist two symmetric errors. The first is to treat old behavior as legitimate forever because it is deployed. The second is to treat deprecation text as proof that it is gone. Running-code primacy asks for a narrower test: which packet format did this device receive, which context did it hold, which hash inputs did it use, and which path did the flow take?

Build a receipt that stops at every boundary

A defensible operational record should preserve at least nine separate facts:

  1. the captured label stack and exact Bottom-of-Stack position;
  2. the octet and PFN that followed it;
  3. the control or management-plane binding for the preceding labels;
  4. the applicable PSH or embedded-payload specification and registry entry;
  5. the forwarding implementation, software version and enabled parser behavior;
  6. the explicit Entropy Label, FAT label or fallback hash inputs;
  7. the ECMP or LAG member selected for a stable flow;
  8. observed distribution, order, loss, latency and jitter; and
  9. the customer or application result.

A packet capture can support the first two. A control-plane snapshot can support the third. A configuration and capability record can support the fifth and sixth. Forwarding telemetry and repeated probes support the path and performance statements. None can be safely replaced by the sentence “the nibble was 4.”

The enduring value of RFC 9790 is not that it gives four bits more authority. It gives them less. It records their uses, limits their interpretation and moves load-balancing intent into an explicit field produced where context exists. That is how a coordination system becomes more reliable: not by making a symbol sovereign, but by making every inference show its receipt.

Sources

  1. RFC 9790 — IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack
  2. RFC 4928 — Avoiding Equal Cost Multipath Treatment in MPLS Networks
  3. RFC 3032 — MPLS Label Stack Encoding
  4. RFC 4385 — Pseudowire Emulation Edge-to-Edge Control Word
  5. RFC 6790 — The Use of Entropy Labels in MPLS Forwarding
  6. RFC 6391 — Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
  7. RFC 8469 — Recommendation to Use the Ethernet Control Word
  8. IANA — Post-Stack First Nibble
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile