Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9994.¶

Copyright Notice

Copyright (c) 2026 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 documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[RFC3032] defines the encoding of the MPLS label stack, the basic structure used to define a forwarding path. There are applications that require MPLS packets to perform special network actions and carry optional Ancillary Data (AD) that can affect the packet-forwarding decision or trigger Operations, Administration, and Maintenance (OAM) logging, for example, as described in [RFC9791]. AD can be used to carry additional information, for example, for network slice purposes (see [RFC9791]).¶

The requirements for In-stack network action and In-Stack Data (ISD) are described in [RFC9613].¶

This document defines the syntax and semantics of network actions and AD encoded in an MPLS label stack. In-stack actions and AD are contained in a Network Action Sub-Stack (NAS), which is recognized by a new base Special-Purpose Label (bSPL). This document follows the framework specified in [RFC9789].¶

2. Conventions Used in This Document

3. Overview

The MPLS NAS is a set of Label Stack Entries (LSEs) that appear as part of an MPLS label stack and serve to encode information about the network actions that should be invoked for the packet. Multiple NASes may appear in a label stack and be placed as described in Section 5.¶

This document specifies how network actions and their optional AD are encoded as part of a NAS as a stack of LSEs. Mechanisms that allow sharing of AD between multiple network actions encoded in the same NAS can be described in other documents and do not rely on any explicit provision in the encodings described in this document.¶

This document defines new LSE formats beyond those in [RFC3032] that define behaviors or are processed in different ways than MPLS labels as defined in [RFC3031]. Three new LSE formats are defined to carry 7 bits of network action opcodes and varying amounts of opcode-specific AD. Specifically, Format-B LSE carries up to 13 bits of AD in an LSE. Format-C LSE carries up to 20 bits of AD in an LSE. Format-D LSE is used when additional AD is needed by the opcodes in Format-B or Format-C LSEs.¶

As shown in Figure 1, the first LSE in an MNA Sub-Stack uses Format-A. The second LSE uses Format-B and is followed by a Format-D LSE to carry additional data. Next, there may be a Format-C LSE for an additional network action followed by another Format-D LSE for additional data. Additional Format-C and Format-D LSEs may be added as needed for additional network actions and data.¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|      MNA-Label=bSPL                   | TC  |S|    TTL        |A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|   Opcode    |        13-bit Data      |R|IHS|S|  NASL |U| NAL |B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|1|                    22-bit Data            |S|  8-bit Data   |D*
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|   Opcode    |        16-bit Data            |S|4b Data|U| NAL |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|1|                    22-bit Data            |S|  8-bit Data   |D*
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
|   Opcode    |        16-bit Data            |S|4b Data|U| NAL |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--

* Format-D LSE presence indicated by NAL greater than one

5. The MNA Sub-Stack

The MNA Sub-Stack MUST begin with a Format A LSE (Section 4.1). The label value of the LSE contains the MNA bSPL (4) to indicate the presence of the MNA Sub-Stack.¶

The TC and TTL values of the Format A LSE retain their semantics as defined in [RFC3032] and [RFC5462]. The TTL and TC values in the Format A LSE are copied from the forwarding label at the top of the label stack. The penultimate node on the path copies the TTL and TC values from the preceding LSE to the next LSE on the label stack, overwriting the TTL and TC values of the next LSE, as specified in Section 3.5 of [RFC3443] and Section 2.6.3 of [RFC3270] in the Uniform Mode LSPs. If the node performing this copy is not aware of MNA, this could overwrite the values in the Format-A LSE of the NAS.¶

The second LSE in a NAS MUST be a Format B LSE (Section 4.2). This LSE contains an initial opcode plus additional fields that describe the NAS.¶

The Format B LSE (Section 4.2) could optionally carry additional data in Format D (Section 4.4) LSEs, up to the length encoded in the LSE's NAL value.¶

A NAS MAY contain more Format C (Section 4.3) and Format D (Section 4.4) LSEs, up to the length encoded in the NASL value. All Format D LSEs MUST follow a Format C or Format B LSE and be included in that LSE's NAL value.¶

6. Special Opcodes

Below are the special opcodes defined to build a basic In-stack MNA solution and assigned in the "Network Action Opcodes" IANA registry (see Section 13.2.2). In the future, additional special opcodes may be defined and their code points assigned from this registry.¶

7. NAS Placement in the Label Stack

The node adding a NAS to the label stack places a copy of the NAS where the relevant nodes can read it. Each downstream node along the path has a Readable Label Depth (RLD). If the NAS is to be processed by a downstream MNA-capable node, then the entire NAS MUST be placed so that it is within RLD by the time the packet reaches the downstream MNA-capable node. The RLD of the downstream MNA-capable node MUST be learned as described in Section 2.3.1 of [RFC9789].¶

If the label stack is deep, several copies of the NAS may need to be encoded in the label stack.¶

For a NAS with HbH scope, every node will process the top copy of the NAS. However, the NAS MUST NOT appear at the top of the stack at any MNA-incapable node on the path that is ensured by the encapsulating node using the node capability, as described in Section 8.¶

A NAS MUST NOT appear at the top of the stack after popping the forwarding label on an MNA-incapable node on the path.¶

The behavior of a node where a NAS with I2E and HbH scopes is also removed along with popping the forwarding label on a PHP node is outside the scope of this document.¶

For a NAS with Select scope, it is processed by the node that brings it to the top of the stack (for example, in the case of using MPLS label pop operation in Segment Routing); then, the NAS is removed from the stack. The select-scoped NAS needs to be inserted after the forwarding label and before the next forwarding label. It could be inserted before or after an HbH NAS. Note that the case of a NAS with Select scope with an MPLS label swap operation (for example, with RSVP-TE LSPs) is for future study.¶

For I2E scope, only one copy of the NAS needs to be added at the bottom of the stack.¶

A transit node that is not the penultimate node that pops a forwarding label and exposes a copy of a NAS MUST remove that NAS.¶

An MNA-capable node performing Penultimate Hop Popping (PHP) that pops the forwarding label with only the NAS(es) remaining on the stack MUST NOT remove the NAS(es). Instead, it forwards the packet with the NAS(es) at the top of the stack to the next node. Note that the behavior of the PHP node, as defined in [RFC3270] for TC processing and as defined in [RFC3443] for TTL processing, is not modified regardless of whether the PHP node supports MNA.¶

The node that receives the NAS at the top of the label stack MUST process and remove it.¶

8. Node Capability Signaling

The encapsulating node MUST make sure that the NAS can be processed by the transit and egress nodes. In addition, the encapsulated packet MUST NOT exceed the path MTU as described in [RFC3032].¶

• The node responsible for selecting a path through the MPLS network needs to know and consider the MNA-capabilities and RLD of the transit nodes as well as the MNA-capabilities of the egress node as described in Section 2.3 of [RFC9789].¶
• Information about the capabilities of the nodes may be configured, collected through management protocols, or distributed by control protocols (such as advertising by routing protocols).¶
• The mechanisms by which the capabilities of the nodes are known by the node responsible for selecting a path through the MPLS network are out of scope for this document.¶
• In the case of Segment Routing over MPLS (SR-MPLS), as well as the RLD, the path computation system needs to know the Maximum SID Depth (MSD) [RFC8664] that can be imposed at the ingress node of a given SR path. This ensures that the label stack depth of a computed path does not exceed the maximum number of labels (i.e., MSD) the node is capable of imposing and the maximum number of labels that can be read by the MNA-processing nodes in the path. The MSD MUST include the MNA Sub-Stacks that will be added.¶
• The encapsulating node MUST learn about the RLD of the nodes in the path as described in Section 2.3.1 of [RFC9789].¶

9. Processing the Network Action Sub-Stack

This section defines the specific responsibilities for nodes along an LSP [RFC3031].¶

10. Network Action Indicator Opcode Definition

The following information MUST be defined for a new NAI opcode request in the document that specifies the Network Action.¶

Format:

The definition of the new Network Action MUST specify the LSE formats. The opcode can define Network Action in Format B or C or both Formats B and C. Both Format B and C LSEs MAY optionally carry Format D LSEs.¶

Scope:

The definition of the new Network Action MUST specify at least one scope (I2E, HbH, Select) for the Network Action and MAY specify more than one scope.¶

Ancillary Data:

The definition of the new Network Action MUST specify the quantity, syntax, and semantics of any associated AD. The AD MAY be variable length, but the NAL MUST be computable based on the data added in the NAS.¶

Processing:

The definition of the new Network Action MUST specify the detailed procedure for processing the network action.¶

Interactions:

The definition of the new Network Action MUST specify its interaction including merging with other currently defined Network Action if there is any.¶

An assignment for a NAI MAY make requests from any combination of the "Network Action Opcodes" or "Network Action Flags Without Ancillary Data" assignments (see Section 13). This decision should optimize for eventual encoding efficiency. If the NAI does not require any AD, then a flag is preferred as only one bit is used in the encoding.¶

11. Security Considerations

The security considerations in [RFC3032] and [RFC9789] also apply to this document.¶

In addition, MNA creates a new dimension in security concerns:¶

• The actions of an encapsulating node can affect any or all of the nodes along the path. In the most common and benign situations, a syntactically incorrect packet could result in packet loss or corruption, for example.¶
• The semantics of a network action are unbounded and may be insecure. A network action could be defined that makes arbitrary changes to the memory of the forwarding router, which could then be used by the encapsulating node to compromise every MNA-capable router in the network.¶
• The MNA architecture supports locally defined network actions. For such actions, there will be limited oversight to ensure that the semantics do not create security issues. Implementors and network operators will need to ensure that even the locally defined network actions do not compromise the security of the network by following the security considerations specified in this document.¶
• The MPLS domain border nodes MUST ensure that the MPLS packets with MNA from any domain with a different administrative control can be filtered to prevent entering the provider MPLS domain. The filtering capability MAY be enabled on a per-network-action basis, and it can be based on a local policy. The filtering capability MUST be implemented on those nodes before deploying MNA in the provider MPLS domain. The RLD on the filtering node MUST be higher than the RLD on all other nodes in the provider MPLS domain.¶
• The MNA architecture supports modifying the AD on the intermediate nodes so the critical network functions either should not rely on the data or should be aware of the risks and use other means to verify the security of the whole network.¶
• The "Private Use" opcodes in the "Network Action Opcodes" registry (see Section 13.2.2) and the "Network Action Flags Without Ancillary Data" registry (see Section 13.2.1) are subject to the considerations described in [RFC8126].¶
• System designers must be aware that information included in AD may be transmitted "in the clear". Network actions that require the exchange of sensitive data must be defined in such a way that the data is encrypted in transit. Otherwise, sensitive data MUST NOT be transmitted using these mechanisms.¶
• Mis-delivery of a packet due to malformed forwarding action data could be considered a security risk.¶

12. Operational Considerations

13. IANA Considerations

Appendix A. Examples

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          MNA-Label=bSPL               | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=1   |        13-bit Flags     |R|IHS|S|NASL=0 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MNA-Label=bSPL                   | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=2   |        Data=0           |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=1   |        Flag-Based NAIs        |S| NAIs  |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Additional Flag-Based NAIs                |S|Flag-Based-NAIs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MNA-Label=bSPL                   | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=8   |      Ancillary Data     |R|IHS|S|NASL=0 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          MNA-Label=bSPL               | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=10  |      Ancillary Data     |R|IHS|S|NASL=1 |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|            Ancillary Data                 |S|Ancillary Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          MNA-Label=bSPL               | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=2   |      Data=0             |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Opcode=9   |      Ancillary Data           |S|   AD  |U|NAL=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|            Ancillary Data                 |S|Ancillary Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           MNA-Label=bSPL              | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=8    |      Ancillary Data     |R|IHS|S|NASL=2 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=7    |      Ancillary Data7          |S|  AD7  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1    |      Flag-Based NAIs          |S|  NAI  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              MNA-Label=bSPL           | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=8    |      Ancillary Data     |R|IHS|S|NASL=3 |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1    |        0x01                   |S|  NAI  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=7    |      Ancillary Data7          |S|  AD7  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode=1    |        0x02                   |S|  NAI  |U|NAL=0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Acknowledgments

The authors of this document would like to thank the MPLS Working Group Open Design Team for the discussions and comments on this document. The authors would also like to thank Amanda Baber for reviewing the IANA Considerations and providing many useful suggestions. The authors would like to thank Loa Andersson, Stewart Bryant, Greg Mirsky, Joel M. Halpern, and Adrian Farrel for reviewing this document and providing many useful suggestions. The authors would like to thank Fabian Ihle and Michael Menth, both from the University of Tuebingen, for reviewing and implementing the solution defined in this document in P4 pipeline. Also, thank you to Tarek Saad for the Shepherd's review, Joe Clarke for the OpsDir review, Matthew Bocci for the Rtgdir review, Derrell Piper for the Secdir review, and James Guichard for the AD review, Mohamed Boucadair, Éric Vyncke, Deb Cooley, Ketan Talaulikar, and Mahesh Jethanandani for the IESG review, which helped improve this document.¶

Contributors

The following people have substantially contributed to this document:¶

Authors' Addresses