Operations, Administration, and Maintenance (OAM) Packet and Behavior in the Network Service Header (NSH)
updates
- rfc-8300 — Network Service Header (NSH)
Extracted elements (15)
Forwarding NSH OAM packets unmodified by SFC data plane elements that do not support SFC OAM procedures may be acceptable for a subset of OAM functions but can result in unexpected outcomes for others. The default-disabled configuration for this forwarding mode reflects a secure-by-default posture requiring explicit operator opt-in.
RFC 8300 defined the O bit as indicating 'an OAM packet' without clarifying that such a packet must exclusively carry OAM data. RFC 9451 updates this to require that an NSH OAM packet contain only SFC OAM data, resolving ambiguity about mixed user-data/OAM packets and preventing non-deterministic behavior at SFC data plane elements.
The setting and processing of the O bit neither assumes nor expects detailed analysis of the content of any inner IP packet carried by the NSH. This design avoids requiring deep packet inspection at every SFC data plane element, preserving performance while still enabling OAM-specific handling.
This document updates RFC 8300 Section 2.2 by replacing the definition of the O bit. Implementations conforming to RFC 8300 that treat any NSH-encapsulated packet carrying OAM data as an OAM packet—regardless of whether user data is also present—are non-conformant with this update and may produce non-deterministic behavior at SFC data plane elements.
SFC-aware implementations of SF, SFF, SFC Proxy, and Classifier that do not support SFC OAM procedures SHOULD discard packets with the O bit set, but MAY support a configurable parameter to enable forwarding received NSH OAM packets unmodified to the next element in the chain.
The configurable parameter enabling forwarding of NSH OAM packets by elements that do not support SFC OAM procedures MUST be disabled by default.
The O bit MUST be set for NSH OAM packets and MUST NOT be set for non-OAM packets.
The O bit MUST NOT be modified along the Service Function Path (SFP).
To prevent non-deterministic behaviors, SFC data plane elements MAY support a configuration parameter to filter valid Next Protocol values in NSH OAM packets. This allows operators to explicitly permit or restrict which Next Protocol values are acceptable in OAM packets.
When an NSH OAM packet includes SFC OAM data in both Context Headers and the inner packet, the processing of the SFC OAM data (including the order) SHOULD be specified in the relevant OAM or Context Header specification.
When SFC OAM data is included in the inner packet, the Next Protocol field is set to reflect the structure of that inner OAM packet. SFFs, SFC-aware SFs, and SFC Proxies SHOULD discard any NSH packets with the O bit set and Next Protocol set to something that is not itself an OAM protocol, including Next Protocol values 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet).
An NSH OAM packet is any NSH-encapsulated packet that exclusively includes SFC OAM data. SFC OAM data can be included in the Fixed-Length Context Header, optional Context Headers, and/or the inner packet. NSH-encapsulated packets that include user data are not considered NSH OAM packets even if some SFC OAM data (e.g., record route) is also supplied.
An NSH OAM packet MAY include optional Context Headers (e.g., a subscriber identifier per RFC 8979 or a flow identifier per RFC 9263) that are used to influence the processing of the packet by SFC data plane elements. An NSH OAM packet MAY also include SFC OAM data in both Context Headers and the inner packet.
The O bit is typically set by an OAM controller or a final destination of an NSH OAM packet that triggers a response (e.g., a specific SFC-aware SF or the last SFF of an SFP). This clarifies the expected originators of OAM-marked packets.
Any data included in an NSH OAM packet SHOULD be integrity protected per RFC 9145. Data plane SFC-related security and privacy considerations are discussed in RFC 7665 Section 6 and RFC 8300 Section 8; additional SFC OAM security considerations are in RFC 8924 Section 9.