Network Service Header (NSH)
updated by
- rfc-9451 — Operations, Administration, and Maintenance (OAM) Packet and Behavior in the Network Service Header (NSH)
Extracted elements (30)
NSH version 01b is reserved and MUST NOT be used because widespread hardware implementations use the first nibble after an MPLS label stack for ECMP decision processing, requiring this value to be avoided to prevent misinterpretation by existing hardware.
The NSH is scoped to a single administrative domain by design. This deliberate constraint, shared with RFC 7665, ensures clear domain boundaries for security enforcement and avoids the complexity of inter-domain trust models.
The TTL field is the primary loop-prevention mechanism, decrement by each SFF, complementing the Service Index (which is decremented by SFs). Handling of an incoming 0 TTL (resulting in value 63) allows better interoperation with pre-standard implementations that do not support the TTL field.
The NSH does not provide fragmentation support at the service plane; fragmentation must be handled by the transport encapsulation protocol. When NSH is encapsulated in IP, IP-level fragmentation coupled with PMTUD (e.g., RFC 8201) is used, requiring ICMP packets not be blocked.
A Service Classifier MUST insert an NSH at the start of an SFP containing valid Base and Service Path Headers. At the end of an SFP, an SFF MUST remove the NSH before forwarding the un-encapsulated packet. When re-classification results in a new SPI, the Classifier MUST replace the existing NSH with a new one and MUST set the initial SI.
An SF or SFC Proxy that does not know the format or semantics of the Context Header for an NSH with MD Type 1 MUST discard any such packet and MUST log the event at least once per SPI.
Each SFF MUST decrement the TTL by 1 prior to NSH forwarding lookup. The packet MUST NOT be forwarded if TTL is 0 after decrement. The default initial TTL value of 63 MUST be used if no value is explicitly configured.
For MD Type 2 variable-length metadata, the sender MUST pad metadata to a 4-byte boundary; the receiver MUST round the Length up to the nearest 4-byte-word boundary to locate the next field and MUST access only the bytes indicated by the Length field.
If a mandatory-to-process Context Header is missing in an SFP packet, the SFC-aware SF MUST NOT process the packet and MUST log an error at least once per SPI. Multiple Context Headers of the same type where duplicates are not allowed: MUST process only the first instance.
NSH implementations MUST support MD Types 0x1 and 0x2 (where length is 0x2). Packets with MD Type values not supported MUST be silently dropped. MD Type 0x0 and 0xF SHOULD be silently discarded.
NSH Length MUST be 0x6 for MD Type 0x1 and MUST be 0x2 or greater for MD Type 0x2. The NSH length MUST be an integer multiple of 4 bytes; variable-length metadata is always padded to a 4-byte boundary.
Participating nodes MUST use the SPI for SFP selection. The initial Classifier MUST set the appropriate SPI and MUST send the packet to the first SFF in the identified SFP. The Service Index MUST be decremented by 1 by SFs or SFC Proxy nodes after performing required services.
SFFs MUST use the Service Path Header for selecting the next SF or SFF. If an SFF receives a packet with SPI and SI that do not correspond to a valid next hop in a valid SFP, that packet MUST be dropped.
The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets. The O bit MUST NOT be modified along the SFP. Implementations not supporting SFC OAM SHOULD discard packets with O bit set; a configurable parameter to forward them unmodified MUST be disabled by default.
The Version field MUST be set to 0x0 by the sender. If an SFF receives an NSH packet with an unrecognized version, the packet MUST be discarded and the event SHOULD be logged. Version 01b is reserved and MUST NOT be used in future versions.
Unassigned bits in the Base Header MUST be set to zero upon origination, MUST be ignored and preserved unmodified by other NSH-supporting elements, and MUST NOT modify actions at reception.
When an SFC Proxy receives an NSH-encapsulated packet, it MUST remove the NSH before forwarding to an NSH-unaware SF. When receiving the packet back, it MUST re-encapsulate with the correct NSH and MUST decrement the Service Index by one.
NSH metadata may carry privacy-sensitive information. Operators should use indirect identification (obfuscation) for sensitive metadata such as personally identifying information. The NSH itself does not provide privacy functions and relies on the transport encapsulation/overlay for confidentiality.
An IEEE Ethertype 0x894F has been allocated for NSH, enabling identification of NSH-encapsulated frames at the Ethernet layer.
The NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header, and optional Context Headers. It is imposed on the original packet/frame and then encapsulated by an outer transport encapsulation for network forwarding.
IANA created the 'Network Service Header (NSH) Parameters' registry containing sub-registries: NSH Base Header Bits (Standards Action), NSH Version (Standards Action), NSH MD Types (IETF Review), NSH MD Class (IETF Review / Expert Review), NSH IETF-Assigned Optional Variable-Length Metadata Types (Standards Action), and NSH Next Protocol (Expert Review).
The 'NSH MD Class' registry (16-bit values) allocates 0x0000-0x01FF via IETF Review, 0x0200-0xFFF5 via Expert Review, 0xFFF6-0xFFFE for Experimental use, and 0xFFFF as Reserved. IANA Base NSH MD Class is 0x0000.
The 'NSH Next Protocol' registry (8-bit values) defines: 0x01=IPv4, 0x02=IPv6, 0x03=Ethernet, 0x04=NSH, 0x05=MPLS, 0xFE/0xFF=Experiment. New values assigned via Expert Review. If assignments reach 128 values, IANA must alert the IESG for a stricter policy.
Implementers and operators MUST be aware that NSH metadata can have privacy implications. Attached metadata should be limited to what is necessary for correct SFP operation. Subscriber-identifying information SHOULD be obfuscated; for situations where obfuscation is insufficient, transport-layer encryption (e.g., IPsec) MUST be used.
NSH does not mandate protocol-specific integrity protection. If an operator deems cryptographic integrity protection necessary, a transport encapsulation that provides such protection (e.g., IPsec) MUST be used. If connectivity between SFC-enabled devices traverses the public Internet, such connectivity MUST be secured at the transport encapsulation layer.
NSH domain boundary enforcement requires that packets entering the SFC domain MUST be filtered to prevent attackers from injecting NSH packets with arbitrary SPI/SI and metadata. Packets originating outside the SFC domain MUST be dropped if they contain an NSH; packets exiting MUST also be dropped if they contain an NSH.
NSH MD Type 1 includes a mandatory Fixed-Length Context Header of exactly 16 bytes immediately following the Service Path Header. NSH total length MUST be 0x6 (in 4-byte words) for MD Type 0x1.
The NSH Base Header is a 32-bit field containing: Version (2 bits), O bit (OAM flag), U bit (unassigned), TTL (6 bits), Length (6 bits), 4 unassigned U bits, MD Type (4 bits), and Next Protocol (8 bits).
The Service Path Header is a 32-bit field containing the Service Path Identifier (SPI, 24 bits) and the Service Index (SI, 8 bits), uniquely identifying a service function path and position within it.
Variable-Length Context Headers (MD Type 2) consist of a Metadata Class (16 bits), Type (8 bits), one unassigned bit, Length (7 bits), and variable-length metadata payload padded to a 4-byte boundary.