Deprecation:

Regardless of how the deprecation is understood in other IETF documents, the interpretation in this document is that if a practice has been deprecated, that practice should not be included in new implementations or deployed in new deployments.

Embedded Packet:

A packet that follows immediately after the MPLS label stack and an optional PSH. The embedded packet could be an IPv4 or IPv6 packet, an Ethernet packet (for Virtual Private LAN Service (VPLS) or EVPN ), or some other type of Layer 2 frame .

Label Stack:

A label stack is represented as a consecutive sequence of "label stack entries" (four-octet fields) after the Layer 2 header but before any network layer header. The last label stack entry of a label stack has its Bottom of Stack bit set.

MPLS Packet:

A packet whose Layer 2 header declares the type to be MPLS. For example, the Ethertype is 0x8847 or 0x8848 for Ethernet, and the Protocol field is 0x0281 or 0x0283 for PPP.

MPLS Payload:

All data after the label stack and any optional PSHs. It is possible that more than one type of PSH may be present in a packet, and some PSH specifications might allow multiple PSHs of the same type. The presence rules for multiple PSHs are a matter for the documents that define those PSHs, e.g., .

Post-stack First Nibble (PFN):

The most significant four bits of the first octet following the label stack.

Post-Stack Header (PSH):

A field containing information that may be of interest to the egress Label Switching Router (LSR) or transit LSRs. Examples include a control word or an associated channel header .

BIER:

Bit Index Explicit Replication

FAT:

Flow-Aware Transport

LSE:

Label Stack Entry

LSR:

Label Switching Router

MNA:

MPLS Network Action

PFN:

Post-stack First Nibble

PSH:

Post-Stack Header

PW:

Pseudowire

SPL:

Special-Purpose Label

Example A:

The first payload is a bare IP packet, i.e., no PSH. The PFN in this case overlaps with the IP version number.

Example B:

The next payload is a bare non-IP packet; again, no PSH. The PFN here is the first nibble of the payload, whatever it happens to be.

Example C:

This example is an MPLS Payload that follows a PSH. Here, the embedded packet could be IP or non-IP.

1. An IPv4 packet (whose IP header has version number 4).
2. An IPv6 packet (whose IP header has version number 6).
3. A Layer 2 Ethernet frame (i.e., not including the Preamble or the Start frame delimiter), starting with the destination Media Access Control (MAC) address.

It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. This will ensure that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version(s) of IP.

Network equipment MUST use a PSH (Post-Stack Header) with a PFN (Post-stack First Nibble) value that is neither 0x4 nor 0x6 in all cases where the MPLS payload is neither an IPv6 nor an IPv4 packet.

This behavior implies that if in the future an IP version is defined with a version number of 0x0 or 0x1, then equipment complying with this BCP would be unable to look past one or more MPLS headers, and loadsplit traffic from a single LSP across multiple paths based on a hash of specific fields in the IPv0 or IPv1 headers. That is, IP traffic employing these version numbers would be safe from disturbances caused by inappropriate loadsplitting, but would also not be able to get the performance benefits.

The practice of deducing the payload type based on the PFN value is deprecated to avoid inaccurate load balancing. This MUST NOT be part of new implementations or deployments. This also means that concerns about load balancing for future IP versions with a version number of 0x0 or 0x1 are no longer relevant.

PSH:

Post-Stack Header

PFN:

Post-stack First Nibble

1. The explicit purpose of the "IP Version Numbers" registry is to track IP version numbers in an IP header.
2. The purpose of the "Post-Stack First Nibble" registry is to track PSH types.