Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities
Extracted elements (25)
Container and object type registries (for the IOAM Capabilities Query/Response Container Types and Object Types) are intentionally deferred to subsequent per-data-plane documents, as these containers will be embedded in different echo request/reply message formats (e.g., ICMPv6, LSP Ping) defined by different working groups.
Echo request/reply is chosen over NETCONF/YANG or IGP for IOAM capability discovery because NETCONF requires each node to implement a client/server and maintain connections (scalability issue), and IGP domain coverage does not always align with the IOAM-Domain (availability issue when hosts are IOAM nodes). Echo request/reply avoids these limitations and supports policy-based capability advertisement per encapsulating node identity.
Fate sharing requires that echo request packets traverse the same path as the IOAM data packet. This can be achieved by applying the same explicit path or ECMP processing to both, including populating the same values in ECMP-affecting header fields.
The generic IOAM Capabilities Query/Response format is data-plane-independent and is intended for use with IPv6 (including SRv6), MPLS (including SR-MPLS), Service Function Chain (SFC), and BIER. Per-data-plane instantiation RFCs are expected to be developed jointly by the relevant working group and the IETF IPPM Working Group.
A list of IOAM Capabilities Objects MUST be included in the IOAM Capabilities Response Container of the echo reply unless the sender encounters an error (e.g., no matched Namespace-ID). The same type of object MAY appear more than once, only if listed with a different Namespace-ID.
A list of IOAM Namespace-IDs (one or more) MUST be included in the IOAM Capabilities Query Container; if present, the Default-Namespace-ID 0x0000 MUST be placed at the beginning of the list, and any duplicate occurrences of 0x0000 MUST be disregarded.
For all capability objects, the Namespace-ID field MUST be one of the Namespace-IDs listed in the IOAM Capabilities Query Container of the echo request, and Reserved fields MUST be zeroed on transmission and ignored on receipt.
If a receiving node has no IOAM capability to report, it MUST ignore the IOAM Capabilities Query Container. The node MUST then send an echo reply without IOAM capabilities or no echo reply, depending on whether the echo request includes other containers.
The IOAM End-of-Domain Object MUST be present in the IOAM Capabilities Response Container sent by an IOAM decapsulating node, unless the IOAM Edge-to-Edge Capabilities Object is also present. When E2E is enabled, including only the IOAM Edge-to-Edge Capabilities Object (without End-of-Domain) is RECOMMENDED.
The IOAM Capabilities Query Container is carried in echo requests sent by the IOAM encapsulating node. It contains a container header (type and optional length) and a list of one or more IOAM Namespace-IDs, zero-padded to a 4-octet boundary, requesting that the receiving node reply with its enabled IOAM capabilities matching those Namespace-IDs.
The IOAM Capabilities Response Container is carried in echo replies from IOAM transit or decapsulating nodes. It contains a container header (which MUST fall on a 4-octet boundary) and a list of one or more IOAM Capabilities Objects representing the enabled IOAM capabilities of the sender.
The TTL-incrementing discovery procedure has the encapsulating node send echo requests starting with TTL=1, then TTL=2, incrementing by 1 each time until an echo reply is received from the IOAM decapsulating node (identified by the Edge-to-Edge Capabilities Object or End-of-Domain Object). This progressively reaches all nodes along the transport path.
IANA created the 'In Situ OAM (IOAM) Capabilities' registry with two subregistries: 'IOAM SoP Capability' (2-bit field for Size of POT, initial value 0b00 = 64-bit PktID and 64-bit Cumulative; 0b01-0b11 via IETF Review) and 'IOAM TSF Capability' (2-bit timestamp format field, initial values PTP/NTP/POSIX; 0b11 via IETF Review).
The IOAM SoP Capability registry defines the 2-bit SoP field in the IOAM Proof of Transit Capabilities Object. Initial entry: 0b00 = '64-bit PktID and 64-bit Cumulative data'. Values 0b01-0b11 are available for assignment via IETF Review (RFC 8126).
The IOAM TSF Capability registry defines the 2-bit TSF field in the IOAM Edge-to-Edge Capabilities Object. Initial entries: 0b00=PTP Truncated Timestamp Format, 0b01=NTP 64-bit Timestamp Format, 0b10=POSIX-based Timestamp Format. Value 0b11 is available for assignment via IETF Review.
A deployment MUST ensure that border filtering drops inbound echo requests with an IOAM Capabilities Container Header from outside the domain, and drops outbound echo requests or replies with IOAM Capabilities Headers leaving the domain, to prevent capability information leakage.
A deployment MUST support configuration to enable or disable the IOAM Capabilities Discovery feature, and MUST disable it by default, limiting exposure when the feature is not intentionally deployed.
Integrity protection of IOAM Capabilities information in echo replies can be achieved via the underlying transport (e.g., IPv6 Authentication Header per RFC 4302). Confidentiality of the collected IOAM capabilities can be provided using the IP Encapsulating Security Payload Header (RFC 4303) or other secure transport.
To prevent DoS attacks, implementations SHOULD apply rate-limiting to incoming echo requests and replies. Implementations MUST provide a means of checking source addresses of echo request messages against an access list before accepting them.
The IOAM DEX (Direct Export) Capabilities Object contains: 24-bit IOAM-Trace-Type (per RFC 9326 Section 3.2), 8-bit Reserved, 16-bit Namespace-ID, and 16-bit Reserved. Its presence indicates the IOAM direct exporting function is enabled at the transit node.
The IOAM Edge-to-Edge Capabilities Object contains: 16-bit Namespace-ID, 16-bit IOAM-E2E-Type, 2-bit TSF (TimeStamp Format: 0b00=PTP truncated, 0b01=NTP 64-bit, 0b10=POSIX-based, 0b11=reserved), and 30-bit Reserved. Its presence indicates E2E function is enabled at the IOAM decapsulating node.
The IOAM End-of-Domain Object contains: 16-bit Namespace-ID and 16-bit Reserved field. Its presence in the response indicates the sending node is an IOAM decapsulating node.
The IOAM Incremental Tracing Capabilities Object has the same wire format as the Pre-allocated Tracing object: 24-bit IOAM-Trace-Type, 7-bit Reserved, 1-bit W flag, 16-bit Namespace-ID, 16-bit Ingress_MTU, and 16- or 32-bit Ingress_if_id. Its presence indicates incremental (rather than pre-allocated) tracing is enabled.
The IOAM Pre-allocated Tracing Capabilities Object contains: a 24-bit IOAM-Trace-Type field, a 7-bit Reserved field, a 1-bit W flag (wide format indicator), a 16-bit Namespace-ID, a 16-bit Ingress_MTU (in octets), and a 16- or 32-bit Ingress_if_id (short or wide format depending on W-bit).
The IOAM Proof of Transit Capabilities Object is a single 32-bit payload: 16-bit Namespace-ID, 8-bit IOAM-POT-Type, 2-bit SoP (Size of POT), and 6-bit Reserved. SoP value 0b00 indicates 64-bit PktID and 64-bit Cumulative data; values 0b01–0b11 are reserved.