Summary

  • RFC 5332 deprecated the original reading of the two MPLS link-layer codepoints. Both 0x8847 and 0x8848 can carry multicast MPLS; in the defined multicast Ethernet case, 0x8848 says that the top label is upstream-assigned.
  • A correct codepoint does not prove that the right context-specific label space was chosen, that the label mapped to the intended replication entry, that a receiver accepted the frame or that service succeeded. Those are later receipts.

The familiar name became the wrong parser

RFC 3032 introduced codepoints commonly described as MPLS unicast and MPLS multicast. RFC 5332 records an awkward but valuable fact: the multicast use had never been deployed, and later MPLS multicast design showed that the old split described the wrong distinction. The specification therefore deprecated the old use without discarding the two wire values.

This is protocol evolution by semantic reassignment. The shared number survives; the proposition attached to it changes. A decoder that consults only a stale label can parse every bit correctly and still report the wrong fact.

RFC 5332 defines a multicast label through its NHLFE in a particular context. The entry carries the intention to replicate to a set of next hops, even when that set currently contains one member. The receiver discovers this through the label lookup. The Ethernet type does not need to repeat it.

That distinction should govern telemetry names. Store ether_type = 0x8848, the applicable standards epoch, outer destination class and interpreted assignment direction. Do not store an irreversible Boolean named is_multicast and discard the bytes that produced it.

Both Ethernet types can carry multicast

On Ethernet, 0x8847 is used for every unicast frame carrying MPLS. It is also used for a multicast Ethernet frame carrying MPLS unless that frame’s top label is upstream-assigned. Only that latter combination uses 0x8848.

The difference is not cosmetic. With downstream assignment, the receiver created and advertised the label-to-FEC binding. With upstream assignment, the sender or a third party created the binding. That provenance changes which label space the receiver must consult. RFC 5331 supplies the context-specific interpretation rules; RFC 5332 supplies the encapsulation signal in the cases where mixed provenance needs one.

Seeing 0x8847 therefore does not prove a unicast MPLS payload. Seeing 0x8848 does not finish the multicast decision. Each value is one element in a compound key that includes the medium, destination address, label stack, assignment contract and context.

Some media carry no assignment-direction bit

PPP illustrates why a universal field model fails. A PPP frame carrying MPLS always uses Protocol field 0x0281. The field does not change when the top label is upstream-assigned rather than downstream-assigned. For a point-to-point direction, the assignment mode is established separately and remains uniform; absent other information, downstream assignment is the required default.

Native IP encapsulation is similarly narrow. IPv4 Protocol Number or IPv6 Next Header 137 is used whether or not the enclosed MPLS packet has multicast semantics. A multicast IP tunnel must use one assignment direction consistently, but the means of selecting that direction lies outside RFC 5332.

An analytics platform that insists every observation contain a wire-derived assignment_direction will fabricate data on these media. The proper state may be “known from tunnel contract,” “defaulted downstream under the RFC,” or “unknown because the contract was not collected.” Unknown is an evidence state, not an ingestion defect.

GRE makes the context explicit—and conditional

For MPLS in GRE with a unicast IP destination, RFC 5332 requires 0x8847 in every case. With a multicast IP destination, 0x8847 indicates a downstream-assigned top label and 0x8848 an upstream-assigned one.

There is a sharper rule when separate procedures establish that a particular multicast GRE tunnel uses upstream assignment. In that setting, receiving 0x8847 is an error and the packet must be discarded. The discard follows from the joined evidence: multicast destination, tunnel contract and mismatching codepoint. The codepoint alone does not create the contract.

This matters for alerts. “Observed 0x8847” is a fact. “Invalid on tunnel T under contract epoch E” is a derived judgment. “Caused customer loss” requires forwarding and service evidence. Putting all three into one alarm sentence hides which premise may be stale.

The multicast MAC is a filter hint, not an audience list

RFC 5332 assigns multicast MPLS Ethernet destinations in the form 01-00-5e-8v-wx-yz. The 20-bit suffix may be zero or may copy one label from the MPLS stack. If the label-derived method is used with two or more labels, the default is the second label, although configuration may choose another. With a one-label stack, that one label supplies the value.

Both zero and label-derived procedures are conforming and must interoperate. A receiver must not filter all zero suffixes, and it must not indiscriminately reject all non-zero suffixes. The suffix can expose LSP-specific information useful to filtering, but RFC 5332 leaves the filtering policy and its uses outside scope.

Consequently, those twenty bits are not twenty bits of receiver identity. They are not a membership list, entitlement token or delivery receipt. A switch may replicate the frame according to its own multicast state; an LSR may then accept or discard it; the NHLFE may replicate it again. Each stage needs its own observation.

A correct field can still meet the wrong label space

Upstream-assigned labels are optional. They must not be used unless downstream support is known, but RFC 5332 does not define how that knowledge is obtained. Local capability proves only that local software can perform the function. It does not prove the peer advertised support, that the support record is current, or that both sides agree on context.

Nor does 0x8848 by itself identify the correct context-specific table. The top label may select or participate in a context described by RFC 5331. Root identity, interface scope or tunnel context remains separate. The adjacent RFC 5331 article addresses that mechanism; this article’s point is that the encapsulation bit cannot substitute for it.

A safe receive record joins codepoint interpretation to the support receipt, tunnel or link contract, context selector, raw label stack and actual lookup result. Otherwise “wire valid” quietly becomes “forwarding valid.”

Security language needs the same restraint

RFC 5332 states that malicious codepoint alteration may produce loss or misrouting. It also says that changing the codepoint without changing the label has no predictable effect. Changing the Ethernet MAC destination can cause a third party to receive the frame.

Those statements define risks, not current attribution. A capture showing a mismatch can establish malformed or contract-inconsistent input. It does not establish malicious intent, the actor, the lookup that followed, or the affected recipient. Predicting a single destination from the changed codepoint contradicts the RFC’s own uncertainty boundary because the outcome depends on label and context state.

Preserve original bytes, capture point, direction, outer addresses, stack, receiver software and decision. The irreversible mistake is to discard the evidence after assigning an incident category that later investigators cannot reproduce.

Build a semantic migration ledger

Codepoint governance should record more than number and current name. For each parser version, retain the authority document, effective semantics, media and address preconditions, deprecated meaning, default behaviour and invalid combinations. Bind decoded observations to that version.

For RFC 5332, a useful receipt chain contains: frame ingress and medium; outer destination class; observed codepoint; raw label stack; assignment-direction contract and epoch; peer-support evidence; context-specific table; NHLFE result; MAC-suffix derivation policy; filter decision; replication actions; receiver observations; and service outcome.

This is a practical expression of running-code primacy. A registry coordinate helps systems meet. It does not govern every conclusion downstream. The shared layer should remain thin enough that implementations can evolve while evidence about their local choices remains inspectable.

Sources