Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see 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 athttps://www.rfc-editor.org/info/rfc9789.¶

Copyright Notice

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

This document describes an architectural framework for MPLSNetwork Action (MNA) technologies. MNA technologies are used toindicate actions for Label Switched Paths (LSPs) and/or MPLS packetsand to transfer data needed for these actions.¶

This document provides the foundation for the development of a commonset of network actions and information elements supporting additionaloperational models and capabilities of MPLS networks. MNA solutionsderived from this framework are intended to address the requirementsfound in[RFC9613]. In addition, MNA maysupport actions that overlap existing MPLS functionality. This may bebeneficial for numerous reasons, such as making it more efficient tocombine existing functionality and new functions in the same MPLSpacket.¶

MPLS forwarding actions are instructions to MPLS routers to applyadditional actions when forwarding a packet. These might includeload-balancing a packet given its entropy, indicating whether or notto perform Fast Reroute on a failure, and indicating whether or not a packet has metadatarelevant to the forwarding actions along the path.¶

This document generalizes the concept of MPLS "forwarding actions" to"network actions" that include any action that an MPLS router isrequested to take on the packet. Network actions include any MPLS forwardingactions but may also include other operations (such as security functions,Operations, Administration, and Maintenance (OAM) procedures, etc.) that are not directly related to forwarding ofthe packet. MPLS network actions are always triggered by an MNApacket but may have implications for subsequent traffic, includingnon-MNA packets, as discussed inSection 2.4.¶

MNA technologies may redefine the semantics of the Label, TrafficClass (TC), and Time to Live (TTL) fields in an MPLS Label Stack Entry(LSE) within a Network Action Sub-Stack (NAS).¶

2.Structure

An MNA solution specifies one or more network actions to apply to anMPLS packet. These network actions and their ancillary data may be carried insub-stacks within the MPLS label stack and/or post-stackdata. A solution must specify where the networkaction sub-stacks occur in the label stack, if and how frequently they should bereplicated within the label stack, and how the network actionsub-stack and post-stack data are encoded.¶

It seems highly likely that some ancillary data will be needed at manypoints along an LSP. Replication of ancillary data throughout thelabel stack would be highly inefficient, as would a full rewrite ofthe label stack at each hop; thus, MNA allows encoding of network actionsand ancillary data deeper in the label stack, requiringimplementations to look past the first LSE. Processing of the labelstack past the top-of-stack LSE was first introduced with the EntropyLabel (EL)[RFC6790].¶

A network action sub-stack contains:¶

• Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS, whichcontains a special-purpose label, called the MNA label, thatis used to indicate the start of a network action sub-stack.¶

• Network Action Indicators (NAIs): Optionally, a set of indicators thatdescribes the set of network actions. If the set of indicators is notin the sub-stack, a solution could encode them in post-stack data. Anetwork action is said to be present if there is an indicator in thepacket that invokes the action.¶

• In-Stack Data (ISD): A set of zero or more LSEs that carry ancillary datafor the network actions that are present. Network action indicatorsare not considered ancillary data.¶

Each network action present in the network action sub-stack may havezero or more LSEs of in-stack data. The ordering of the in-stack dataLSEs corresponds to the ordering of the network action indicators. Theencoding of the in-stack data, if any, for a network action must bespecified in the document that defines the network action. In-stackdata may be referenced by multiple network actions.¶

As an example, in-stack data might look like the following label stack with anembedded NAS:¶

    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |0|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |0|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |0|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                Network Action Sub-Stack     |0|               |   ~                                                               ~   |         Network Action Sub-Stack continued  |0|               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |0|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |1|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                           Payload                             |

Certain network actions may also specify that data is carried afterthe label stack. This is called post-stack data. The encoding of thepost-stack data, if any, for a network action must be specified in thedocument that defines the network action. If multiple network actionsare present and have post-stack data, the ordering of their post-stackdata corresponds to the ordering of the network action indicators.¶

As an example, a packet containing post-stack data might contain a label stack followed by post-stack data, followed by the payload:¶

    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |0|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |1|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                       Post-Stack Data                         |   ~                                                               ~   |                  Post-Stack Data continued                    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                           Payload                             |

A solution must specify the order for network actions to beapplied to the packet for the actions to have consistentsemantics. Since there are many possible orderings, especially withbit catalogs (Section 3.5.1), the solution must provide an unambiguousspecification. The precise semantics of an action are dependent on thecontents of the packet, including any ancillary data, and the state ofthe router.¶

This document assumes that the MPLS WG will select a singlesolution for the encoding of ISD and not more than one solution forthe encoding of PSD.¶

3.Encoding

Several possible ways to encode NAIs have been proposed. Thissection summarizes the proposals and some considerations forthe various alternatives.¶

When network actions are carried in the MPLS label stack, thenregardless of their type, they are represented by a set of LSEs termeda Network Action Sub-Stack (NAS). A NAS consists of a special-purpose label,optionally followed by LSEs that specify which network actions are tobe performed on the packet and the in-stack ancillary data for eachindicated network action. Different network actions may be placedtogether in one NAS or may be carried in different sub-stacks.¶

[RFC9613] requires that a solution not add unnecessary LSEs to the sub-stack (see requirement 9 inSection 3.1 of [RFC9613]). Accordingly, solutions should also make efficient use of the bits within the sub-stack (except the S-bit), as inefficient use of the bits could result in the addition of unnecessary LSEs.¶

    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |               Label                   | TC  |S|      TTL      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                Label                  |x x x|S|x x x x x x x x|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.Semantics

For MNA to be consistent across implementations and predictable inoperational environments, its semantics need to be entirelypredictable. An MNA solutionMUST specify a deterministic order forprocessing each of the network actions in a packet. Each networkaction must specify how it interacts with all other previously definednetwork actions. Private network actions are network actions that arenot publicly documented. Private network actionsMUST be included inthe ordering of network actions, but the interactions of privateactions with other actions are outside of the scope of this document.¶

5.Definition of a Network Action

A document defining a network action must contain the following:¶

Name:

The name of the network action.¶

Network Action Indicator:

The bit position or opcode that indicates that the network action is active.¶

Scope:

Description of which nodes should perform the network action as described inSection 2.1.¶

State:

Indication of whether the network action can modify state in the network and, if so, the state that may be modified and its side effects.¶

Required/Optional:

Indication of whether a node is required to perform the network action.¶

In-Stack Data:

The number of LSEs of in-stack data, if any, and the encoding of the in-stack data. If the in-stack data is of a variable length, then the solution must specify how an implementation can determine the length without implementing the network action.¶

Post-Stack Data:

The encoding of post-stack data, if any. If the post-stack data is of a variable length, then the solution must specify how an implementation can determine the length without implementing the network action.¶

A solution should create an IANA registry for networkactions.¶

6.Management Considerations

Network operators will need to be cognizant of which network actionsare supported by which nodes and will need to ensure that this issignaled. Some solutions may require network-wideconfiguration to synchronize the use of the labels that indicate thestart of a NAS. Solution documents must clearly state what managementconsiderations apply to the solutions they are describing. Solutiondocuments must describe mechanisms for performing network diagnosticsin the presence of MNAs.¶

7.Security Considerations

An analysis of the security of MPLS systems is provided in[RFC5920], which also notes that the MPLS forwarding plane has nobuilt-in security mechanisms.¶

Central to the security of MPLS networks is operational security ofthe network, something that operators of MPLS networks are well versedin. The deployment of link-level security (e.g.,[MACsec]) preventslink traffic observation covertly acquiring the label stack for anattack. This is particularly important in the case of a networkdeploying MNA, because the MNA information may be sensitive. Thus, theconfidentiality and authentication achieved through the use oflink-level security is particularly advantageous.¶

Some additional proposals to add encryption to the MPLS forwarding plane have been suggested[MPLS-OPP-SEC], but no mechanisms have been agreed upon at the time of publication of this document.[MPLS-OPP-SEC] offers hop-by-hop security that encrypts the label stack and is functionally equivalent to that provided by[MACsec]. Alternatively, it also offers end-to-end encryption of the MPLS payload with no cryptographic integrity protection of the MPLS label stack.¶

Particular care is needed when introducing any end-to-endsecurity mechanism to allow an in-stack MNA solution that needs toemploy on-path modification of the MNA data or where post-stackMNA data needs to be examined on-path.¶

A cornerstone of MPLS security is to protect the network fromprocessing MPLS labels that originated outside the network.¶

Operators have considerable experience in excluding MPLS-encodedpackets at the network boundaries, for example, by excluding all MPLSpackets and all packets that are revealed to be carrying an MPLS packet as the payload of IP tunnels. Where such packets are acceptedinto an MPLS network from an untrusted third party, non-MPLS packets are immediately encapsulated in an MPLS label stack specified by theMPLS network operator, and MPLS packets have additional labelstack entries imported as specified by the MPLS network operator. Thus, it is difficult for an attacker to pass an MPLS-encodedpacket into a network or to present any instructions to the networkforwarding system.¶

Within a single well-managed domain, an adjacent domain may beconsidered to be trusted provided that it is sufficiently shieldedfrom third-party traffic ingress and third-party traffic observation.In such a situation, no new security vulnerabilities are introduced byMNA.¶

In some inter-domain applications (including carrier's carrier) wherea first network's MPLS traffic is encapsulated directly over a secondMPLS network by simply pushing additional MPLS LSEs, the contents ofthe first network's payload and label stack may be visible to theforwarders in the second network. Historically, this has been benignand indeed useful for ECMP. However, if the first network's traffichas MNA information, this may be exposed to MNA-capable forwarders andcause unpredictable behavior or modification of the customer MPLSlabel stack or MPLS payload. This is an increased vulnerabilityintroduced by MNA thatSHOULD be addressed in any MNA solution.¶

Several mitigations are available to an operator:¶

1. Reject all incoming packets containing MNA information that do not come from a trusted network. Note that it may be acceptable to accept and process MNA information from a trusted network.¶
2. Fully encapsulate the inbound packet in a new additional MPLS label stack such that the forwarder finds a Bottom of Stack (BoS) bit imposed by the carrier network and only finds MNA information added by the carrier network.¶

A mitigation that we reject as unsafe is having the ingress Label Switching Router (LSR) pushsufficient additional labels such that any MNA information received inpackets entering the network from a third-party network is madeinaccessible due to it being below the RLD. This is unsafe in thepresence of an overly conservative RLD value and can result in thethird-party MNA information becoming visible to and acted on by anMNA forwarder in the carrier network.¶

8.IANA Considerations

IANA has allocated the following code point in the "IGPMSD-Types" registry[MSD] within the "Interior Gateway Protocol (IGP)Parameters" registry group:¶

Acknowledgements

This document is the result of work started in MPLS Open Design Team, with participation by the MPLS, PALS, and DETNET Working Groups.¶

The authors would like to thankAdrian Farrel for his contributions. The authors would also like to thankJohn Drake,Toerless Eckert, andJie Dong for their comments.¶

Authors' Addresses