IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)
Extracted elements (19)
RFC 8200 prohibits direct insertion of extension headers into in-flight packets by transit nodes, which is why IOAM deployment on transit nodes requires adding an outer IPv6 header. This constraint shapes the two bounded-domain deployment models (host-bounded vs. network-device-bounded).
Two distinct Option-Type values (0x11 and 0x31) are assigned, differing only in the 'chg' bit. The 0x31 value (chg=1) signals that the option data may change en route, which is relevant for Trace and POT options that are modified at each hop, while 0x11 (chg=0) is used for options that are not modified in transit.
IOAM for IPv6 complements but is distinct from the IPv6 Performance and Diagnostic Metrics (PDM) Destination Option (RFC 8250). Both enhance IPv6 diagnostics but serve different purposes and use separate option types.
IPv6 options can have a maximum length of 255 octets; consequently, the total length of IOAM Option-Types including all data fields is limited to 255 octets when encapsulated in IPv6.
All IOAM IPv6 options require alignment on multiples of 4 bytes, ensuring that fields specified in RFC 9197 are aligned at a multiple-of-4 offset from the start of the hop-by-hop and destination options header.
Implementations of IOAM MUST ensure that the addition of IOAM Data-Fields does not alter the way routers forward packets or the forwarding decisions they make, including ECMP behavior, which must be identical for packets with and without IOAM Data-Fields.
IOAM MUST be deployed in an IOAM-Domain — a set of nodes managed by the same administrative entity, bounded by its perimeter or edge.
IOAM MUST be explicitly enabled per interface on every node within the IOAM-Domain. Unless explicitly configured for IOAM, a router MUST ignore IOAM Options.
RFC 8200 precludes insertion of IOAM data directly into the original IPv6 header of in-flight packets. IOAM deployments that encapsulate/decapsulate on transit nodes (not hosts) MUST add an additional IPv6 header to carry IOAM data.
The MTU of transit routers and switches must be configured so that IOAM data addition does not trigger ICMP Packet Too Big errors. The PMTU tolerance range must be identified, and IOAM encapsulation operations must not exceed it.
For IOAM-Domains bounded by hosts, hosts perform IOAM Data-Field encapsulation and decapsulation, placing IOAM Data-Fields directly in the IPv6 header as hop-by-hop or destination options.
For IOAM-Domains bounded by network devices, routers at the domain edge encapsulate IOAM Data-Fields in an additional outer IPv6 header rather than inserting them into the original packet's header.
IOAM Data-Fields are encapsulated in IPv6 using either the hop-by-hop options header or the destination options header. Multiple options with the same option type MAY appear in the same header with distinct content.
The IOAM Pre-allocated Trace Option-Type and Proof of Transit Option-Type are carried in the IPv6 hop-by-hop extension header using Option-Type 0x31. The Edge-to-Edge Option and Direct Export (DEX) Option are carried using Option-Type 0x11.
IANA assigned two IPv6 Option-Types in the 'Destination Options and Hop-by-Hop Options' subregistry: 0x11 (act=00, chg=0) for IOAM Destination Option and IOAM Hop-by-Hop Option, and 0x31 (act=00, chg=1) for IOAM Destination Option and IOAM Hop-by-Hop Option.
IOAM-Domains do not rely on the IP Authentication Header (AH, RFC 4302) to secure IOAM options. The use of IOAM options with AH is not defined in this document and is left for future specifications.
Packets that include IPv6 extension headers with IOAM information MUST NOT be leaked through the boundaries of the IOAM-Domain. IOAM-Domain boundary routers MUST filter incoming traffic containing IOAM extension headers and MUST filter outgoing traffic leaving the domain that contains IOAM extension headers.
The trust model assumes any node that adds, removes, or modifies IOAM Data-Fields is allowed to do so. An IOAM node only processes IOAM extension headers when the directive comes from a trusted source and is validated; security breaches in this model may allow unauthorized IOAM manipulation.
The IPv6 option format for IOAM consists of a 1-byte Option-Type, 1-byte Opt Data Len (length in octets excluding first 2 bytes), 1-byte Reserved (must be zero), 1-byte IOAM Opt-Type, and variable-length Option Data.