RFC 9790

IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack

📅 published July 2025, from ietf

RFC 9790: IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack 🎀

okay bestie, here's the deets 💅

  • RFC number: 9790 ✨
  • Authors: K. Kompella (Juniper Networks), S. Bryant (University of Surrey 5GIC), M. Bocci (Nokia), G. Mirsky, Ed. (Ericsson), L. Andersson, and J. Dong (Huawei Technologies)
  • Category: Standards Track
  • Date: July 2025
  • ISSN: 2070-1721
  • Updates: RFC 4928 (the only one listed, and there's no obsoletes line in the header)
  • Published by: the Internet Engineering Task Force (IETF) 🌈

Abstract

okay so this doc makes a brand new IANA registry (we're calling it the "Post-Stack First Nibble" registry 🦋) for the first nibble, which is that 4-bit field sitting right after an MPLS label stack. It also lays out some requirements for registering new values, plus ways to make MPLS packet processing easier and more robust 💖

The relationship between that new registry and the IANA "IP Version Numbers" registry (RFC 2780) gets explained here too 🧚

And ngl, this doc also updates RFC 4928 by deprecating the heuristic method for figuring out what kind of packet is encapsulated in MPLS. Iconic move 👑

Status of This Memo

This is an Internet Standards Track document 🔥

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 For more on Internet Standards, check Section 2 of RFC 7841.

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9790 🌸

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these carefully, because they spell out your rights and restrictions for this document. Code components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License ⚠️

Table of Contents 🗂️

1.  Introduction
  1.1.  Requirements Language
  1.2.  Definitions
  1.3.  Abbreviations
  1.4.  Reference Figures
2.  Rationale
  2.1.  Why Look at the First Nibble
    2.1.1.  ECMP Load Balancing
  2.2.  Updates to RFC 4928
  2.3.  Why Create a Registry
  2.4.  IP Version Numbers Versus Post-Stack First Nibble Values
  2.5.  Next Step to More Deterministic Load Balancing in MPLS
        Networks
3.  IANA Considerations
4.  Security Considerations
5.  References
  5.1.  Normative References
  5.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

okay so an MPLS packet is made of a label stack, then an optional Post-Stack Header (PSH), then an optional embedded packet, in that order 🍓 Examples of PSHs are existing headers like control words [RFC4385] and BIER (Bit Index Explicit Replication) headers [RFC8296], plus new PSH types the MPLS Working Group is talking about. The catch is that in the data plane there are very few clues about the PSH and no clue at all about what type of embedded packet you've got 🙈 That info comes through other means, like the routing protocols that signal the labels in the stack.

Still, to handle MPLS packets better in the data plane, it's common practice for network gear to "guess" the type of embedded packet 🤭 That gear may also need to process the PSH. Both of those mean parsing the data after the label stack. The usual move is to look at the "first nibble" (the top four bits of the first octet following the label stack) 💅 Some existing devices do this, but it has to be stressed that the PFN in a PSH can only be correctly interpreted in the context set up through the control or management plane, using the Label Stack Entry (LSE) or group of LSEs in the preceding label stack that characterizes the PSH type. Trying to rely on the value in any other context is unreliable 💀

The PFN value should not be used to deduce the PSH type by itself, and since the space of PFN values is limited, reusing PFN values is encouraged when possible 🫶

The semantics and usage of the first nibble aren't well documented, and neither are the value assignments. This document has four goals:

  • To document the values already in use.
  • To provide a mechanism for documenting future assignments through a new IANA "Post-Stack First Nibble" registry, and to describe how it relates to the IANA "IP Version Numbers" registry [RFC2780].
  • To provide a method for tracking usage by requiring more detailed documentation.
  • To stress that any MPLS packet not carrying plain IPv4 or IPv6 packets contains a PSH. This also applies to packets of any new version of IP (see Section 2.4). 🌈

Section 2.1.1 of this document has an analysis of load-balancing techniques. Based on that, Section 2.1.1.1 introduces a requirement that deprecates the heuristic method for identifying the type of packet encapsulated in MPLS, and recommends using a dedicated label value for load balancing ⭐ The intent is for legacy routers to keep operating as they always have, with no new problems introduced by this document. New implementations that follow this document, though, get more robust network operation 👑

Furthermore, this document updates [RFC4928] by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS. It also clearly states that the type of encapsulated packet cannot be determined from the PFN alone 🔥

1.1. Requirements Language

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, as shown here 📚

1.2. Definitions

Here's the glossary, bestie 🧚

  • Deprecation: Regardless of how deprecation is understood in other IETF documents, here it means 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) [RFC4761] [RFC4762] or EVPN [RFC7432]), or some other type of Layer 2 frame [RFC4446] 🌸
  • Label Stack: A label stack is 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. 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., [MNA-PS-HDR] 🍓
  • 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 [RFC4385] [RFC8964] or an associated channel header [RFC4385] [RFC5586] [RFC9546] ✨

1.3. Abbreviations

the abbreviations, all in one place 💅

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

1.4. Reference Figures

okay so bestie, the figures are where this whole thing clicks 🦋 Figure 1 follows the MPLS packet format from [RFC3032], where TC is the Traffic Class field from [RFC5462] (it replaced the EXP, Experimental Use, field), S is the Bottom of Stack flag, and TTL is the Time to Live field.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   X |                        Layer 2 Header                         | |
     |                                                               | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
                                               TC   S       TTL
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   Y |             Label-1                   | TC  |0|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Label-2                   | TC  |0|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               ...                     | TC  |0|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Label-n                   | TC  |1|      TTL      | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

            Figure 1: Example of an MPLS Packet with Label Stack

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   A | (PFN) |                   IP header                           | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             data                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        end of IP packet                       | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   B | (PFN) |                 non-IP packet                         | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             data                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      end of non-IP packet                     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   C | (PFN) |                      PSH                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              PSH                              | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          end of PSH                           | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        embedded packet                        | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

      Figure 2: Examples of an MPLS Packet Payload With and Without a
                        Preceding Post-Stack Header

Figure 1 shows an MPLS packet with a Layer 2 header X and a label stack Y ending with Label-n. Figure 2 displays three examples of an MPLS payload:

  • 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.

So the complete MPLS packet would consist of [X Y A], [X Y B], or [X Y C]. 💅

2. Rationale

2.1. Why Look at the First Nibble

okay so an MPLS packet can carry one of many kinds of embedded packet 🌈 Three common ones are:

  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.

Many other packet types are possible; in principle, any Layer 2 embedded packet is permissible. Indeed, at some points in time, packets of the Point-to-Point Protocol, Frame Relay, and Asynchronous Transfer Mode were reasonably common and may become so again. 🦋

In addition, there may be a PSH ahead of the embedded packet. The value of PFN is considered to ensure that the PSH can be correctly parsed. ✨

2.1.1. ECMP Load Balancing

there are four common ways to load balance an MPLS packet, and honestly the ranking is very iconic 👑

  1. Use the top label alone.
  2. Use all of the non-SPLs [RFC7274] in the stack. This is better than using the top label alone.
  3. "Divine" the type of embedded packet and use fields from the guessed header. The ramifications of using this load-balancing technique are discussed in detail in Section 2.1.1.1. This way is better than the two ways above.
  4. Use either an Entropy Label [RFC6790] or a Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see Section 2.1.1.1). This is the best way.

Load balancing based on just the top label means that all packets with that top label will go the same way, which is far from ideal 🙈 Load balancing based on the entire label stack (not including SPLs) is better, but it may still be uneven. However, if the embedded packet is an IP packet, then the combination of (<source IP address>, <dest IP address>, <transport protocol>, <source port>, and <dest port>) from the IP header of the embedded packet forms an excellent basis for load balancing. This is what is typically used for load balancing IP packets. 💖

An MPLS packet doesn't, however, carry a payload type identifier. There is a simple (but risky) heuristic that is commonly used to guess the type of the embedded packet. The first nibble of an IP header, i.e., the four most significant bits of the first octet, contains the IP version number. That, in turn, indicates where to find the relevant fields for load balancing. The heuristic goes roughly as described in Section 2.1.1.1. 🎀

2.1.1.1. Heuristic for ECMP Load Balancing

  1. If the PFN is 0x4 (0100b), treat the payload as an IPv4 packet, and find the relevant fields for load balancing on that basis.
  2. If the PFN is 0x6 (0110b), treat the payload as an IPv6 packet, and find the relevant fields for load balancing on that basis.
  3. If the PFN is anything else, the MPLS payload is not an IP packet; fall back to load balancing using the label stack.

This heuristic has been implemented in many (legacy) routers and performs well in the case of example A in Figure 2. However, this heuristic can work very badly for the non-IP packet as shown in example B in Figure 2. For example, if payload B is an Ethernet frame, then the PFN is the first nibble of the Organizationally Unique Identifier of the destination MAC address, which can be 0x4 or 0x6. This would lead to the packet being treated as an IPv4 or IPv6 packet such that data at the offsets of specific relevant fields would be used as input to the load-balancing heuristic, resulting in unpredictable load balancing. This behavior can happen to other types of non-IP payloads as well. 😭

That, in turn, led to the idea of inserting a PSH (e.g., a pseudowire control word [RFC4385], a Deterministic Networking (DetNet) control word [RFC8964], a Network Service Header (NSH) [RFC8300], or a BIER header [RFC8296]) where the PFN is not 0x4 or 0x6; this explicitly prevents forwarding engines from confusing the MPLS payload with an IP packet. [RFC8469] recommends the use of a control word when the embedded packet is an Ethernet frame. [RFC8469] was published at the request of the operator community and the IEEE Registration Authority Committee as a result of operational difficulties with pseudowires that did not contain the control word. 🧚

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, either an Entropy Label [RFC6790] or a FAT Pseudowire Label [RFC6391]. Furthermore, the heuristic of guessing the type of the embedded packet, as discussed above, SHOULD NOT be used. 🫶

A consequence of the heuristic approach is that while legacy routers may look for a PFN of 0x4 [RFC0791] or 0x6 [RFC8200], no legacy router will look for any other PFN for load-balancing purposes, regardless of what future IP version numbers will be. This means that the values 0x4 and 0x6 are used to (sometimes incorrectly) identify IPv4 and IPv6 packets, but no other PFN values will be used to identify IP packets. 🌸

This document creates a new registry for all 16 possible values (see Section 3). 📋

2.2. Updates to RFC 4928

the text in RFC 4928 [RFC4928] about the first nibble after the MPLS label stack has been updated by this document, and the heuristic for snooping this nibble has been deprecated 🥀 Section 3 of [RFC4928] is updated as follows:

OLD TEXT:

|  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.

NEW TEXT:

|  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.

The following requirement (discussed is Section 2.1.1.1) replaces paragraph 4 in Section 3 of [RFC4928] as follows:

OLD TEXT:

|  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.

NEW TEXT:

|  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.

Furthermore, the following text is appended to Section 1.1 of [RFC4928]:

NEW TEXT:

|  PSH:  Post-Stack Header
|
|  PFN:  Post-stack First Nibble

2.3. Why Create a Registry ✨

okay so the framework for MPLS Network Actions (MNAs) is in [RFC9789] and it's basically an upgrade to the MPLS architecture 🦋. Now, using Post-Stack Data (PSD) to encode the MNA indicators and ancillary data (see Section 3.6 of [RFC9789]) might put data in the PFN, and that could clash with other stuff already using that nibble 😬. This is the issue covered in Section 3.6.1 of [RFC9789], and it's lowkey messy: the PFN value of 0x0 has two different formats depending on whether the PSH is a pseudowire control word or a DetNet control word. To tell which one you're looking at, you need the context of the service label 💀.

A registry fixes this. With one, PSHs get way easier to identify and parse 💖. They also don't need any help from outside the data plane to be read correctly, and their semantics and usage are documented and referenced right there in the registry 🎀.

2.4. IP Version Numbers Versus Post-Stack First Nibble Values 🌸

The PFN started out as a way to heuristically spot IP packets for load balancing 🧚. Then people found out that non-IP packets were getting misidentified as IP whenever the heuristic failed, and they were being badly load balanced. That's the scenario described in [RFC4928] 😭. Some folks might be confused about how the "Post-Stack First Nibble" registry relates to the "IP Version Numbers" registry, so let's clear it up. These two registries are actually super different:

  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.

The only overlap between the two is the values 0x4 and 0x6, and that's just for backward compatibility 🫶.

2.5. Next Step to More Deterministic Load Balancing in MPLS Networks 🔥

Network evolution is impossible to control, but it unfolds over time, shaped by all kinds of factors 🌈.

This document discourages more implementations from multiplying, because that could cause unwanted effects on data flows 🙈. By doing that, it limits the scope of future protocol developments, which helps future network evolution go smoother 👑.

Section 2 of [RFC4385] suggests using a PSH only to stop IP ECMP treatment of non-IP payloads encapsulated in MPLS. Obsoleting this use of a PSH would help move things toward a simpler, more coherent system of MPLS data encapsulation ✨. (Other uses of a PSH may still be valid.) Before that can happen, though, we need enough evidence that there are no marketed or deployed implementations using the heuristic practice to load balance MPLS data flows 💅.

So the next steps toward more deterministic load balancing in MPLS networks are to gradually deprecate non-PSH MPLS encapsulations of non-IP data, to stop using heuristic load balancing, and to survey the available and deployed implementations to figure out when obsoletion can be achieved 🦋.

3. IANA Considerations 📋

Per this document, IANA has created a registry group called "Post-Stack First Nibble" 💖. It holds a single registry, also called the "Post-Stack First Nibble" registry. The initial contents are shown in Table 1. The assignment policy is Standards Action [RFC8126]. Important: the same PFN value can be used in more than one protocol 😬. You can only correctly interpret the PFN in a PSH in the context of the LSE or group of LSEs in the preceding label stack, since that's what characterizes the type of the PSH and, as a result, the PFN 🧠.

 +==========+=======+=================================+===========+
 | Protocol | Value | Description                     | Reference |
 +==========+=======+=================================+===========+
 | DetNet   | 0x0   | DetNet Control Word             | [RFC8964] |
 +----------+-------+---------------------------------+-----------+
 | NSH      | 0x0   | NSH Base Header, payload        | [RFC8300] |
 +----------+-------+---------------------------------+-----------+
 | PW       | 0x0   | PW Control Word                 | [RFC4385] |
 +----------+-------+---------------------------------+-----------+
 | DetNet   | 0x1   | DetNet Associated Channel       | [RFC9546] |
 +----------+-------+---------------------------------+-----------+
 | MPLS     | 0x1   | MPLS Generic Associated Channel | [RFC5586] |
 +----------+-------+---------------------------------+-----------+
 | PW       | 0x1   | PW Associated Channel           | [RFC4385] |
 +----------+-------+---------------------------------+-----------+
 | NSH      | 0x2   | NSH Base Header, OAM            | [RFC8300] |
 +----------+-------+---------------------------------+-----------+
 |          | 0x3   | Unassigned                      |           |
 +----------+-------+---------------------------------+-----------+
 |          | 0x4   | Reserved                        | RFC 9790  |
 +----------+-------+---------------------------------+-----------+
 | BIER     | 0x5   | BIER Header                     | [RFC8296] |
 +----------+-------+---------------------------------+-----------+
 |          | 0x6   | Reserved                        | RFC 9790  |
 +----------+-------+---------------------------------+-----------+
 |          | 0x7 - | Unassigned                      |           |
 |          | 0xF   |                                 |           |
 +----------+-------+---------------------------------+-----------+

             Table 1: Post-Stack First Nibble Registry

4. Security Considerations 🔥

This document creates a new IANA registry for PFNs and specifies changes to how packets get treated in the data plane, based on the first nibble of data beyond the MPLS label stack 🚨. One intent of this is to reduce or eliminate errors when working out whether or not a packet being transported by MPLS is IP. These errors have mostly caused unbalanced, and therefore inefficient, multipathing 😩. They do, however, have the potential to cause much more severe security problems 💀. Please take this one seriously, bestie.

For general security considerations involving the MPLS label stack, see [RFC3032] 🛡️.

5. References 📚

5.1. Normative References

Here's every normative reference, complete and verbatim 🫶:

[RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
           DOI 10.17487/RFC0791, September 1981,
           <https://www.rfc-editor.org/info/rfc791>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2780]  Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
           Values In the Internet Protocol and Related Headers",
           BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
           <https://www.rfc-editor.org/info/rfc2780>.

[RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
           Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
           Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
           <https://www.rfc-editor.org/info/rfc3032>.

[RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
           "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
           Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
           February 2006, <https://www.rfc-editor.org/info/rfc4385>.

[RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
           Cost Multipath Treatment in MPLS Networks", BCP 128,
           RFC 4928, DOI 10.17487/RFC4928, June 2007,
           <https://www.rfc-editor.org/info/rfc4928>.

[RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
           (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
           Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
           2009, <https://www.rfc-editor.org/info/rfc5462>.

[RFC6391]  Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
           Regan, J., and S. Amante, "Flow-Aware Transport of
           Pseudowires over an MPLS Packet Switched Network",
           RFC 6391, DOI 10.17487/RFC6391, November 2011,
           <https://www.rfc-editor.org/info/rfc6391>.

[RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
           L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
           RFC 6790, DOI 10.17487/RFC6790, November 2012,
           <https://www.rfc-editor.org/info/rfc6790>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", STD 86, RFC 8200,
           DOI 10.17487/RFC8200, July 2017,
           <https://www.rfc-editor.org/info/rfc8200>.

[RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
           Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
           for Bit Index Explicit Replication (BIER) in MPLS and Non-
           MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
           2018, <https://www.rfc-editor.org/info/rfc8296>.

[RFC8469]  Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to
           Use the Ethernet Control Word", RFC 8469,
           DOI 10.17487/RFC8469, November 2018,
           <https://www.rfc-editor.org/info/rfc8469>.

[RFC8964]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
           S., and J. Korhonen, "Deterministic Networking (DetNet)
           Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
           2021, <https://www.rfc-editor.org/info/rfc8964>.

[RFC9789]  Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
           Network Actions (MNAs) Framework", RFC 9789,
           DOI 10.17487/RFC9789, July 2025,
           <https://www.rfc-editor.org/info/rfc9789>.

Keep going, we're getting there! 🦋

5.2. Informative References 🧾✨

okay bestie, these are the extra reads that aren't required for the spec but are super useful for context 📚💜

   [MNA-PS-HDR]
              Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Li,
              T., and J. Dong, "Post-Stack MPLS Network Action (MNA)
              Solution", Work in Progress, Internet-Draft, draft-ietf-
              mpls-mna-ps-hdr-01, 30 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              mna-ps-hdr-01>.

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446,
              DOI 10.17487/RFC4446, April 2006,
              <https://www.rfc-editor.org/info/rfc4446>.

   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <https://www.rfc-editor.org/info/rfc4761>.

   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
              <https://www.rfc-editor.org/info/rfc4762>.

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

   [RFC7274]  Kompella, K., Andersson, L., and A. Farrel, "Allocating
              and Retiring Special-Purpose MPLS Labels", RFC 7274,
              DOI 10.17487/RFC7274, June 2014,
              <https://www.rfc-editor.org/info/rfc7274>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC9546]  Mirsky, G., Chen, M., and B. Varga, "Operations,
              Administration, and Maintenance (OAM) for Deterministic
              Networking (DetNet) with the MPLS Data Plane", RFC 9546,
              DOI 10.17487/RFC9546, February 2024,
              <https://www.rfc-editor.org/info/rfc9546>.

Acknowledgements 🙏💖

the authors wanted to give a massive shoutout to Donald E. Eastlake 3rd for the review, the insightful questions, and the helpful comments 🫶 they also thank Amanda Baber for helping organize the IANA registry in a clear and concise way 🎀

Éric Vyncke, John Scudder, Warren Kumari, Murray Kucherawy, and Gunter Van de Velde also gave helpful comments during IESG review 🌸

and the authors thank Adrian Farrel for his patient and careful shepherding and for helping finalize the text 👑✨

Authors' Addresses 💌

   Kireeti Kompella
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA 94089
   United States of America
   Email: kireeti.ietf@gmail.com


   Stewart Bryant
   University of Surrey 5GIC
   Email: sb@stewartbryant.com


   Matthew Bocci
   Nokia
   Email: matthew.bocci@nokia.com


   Greg Mirsky (editor)
   Ericsson
   Email: gregimirsky@gmail.com


   Loa Andersson
   Huawei Technologies
   Email: loa@pi.nu


   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: jie.dong@huawei.com
📦 where this page comes from