]> Univ. of Rome Tor Vergata / CNIT / Common Net

andrea.mayer@uniroma2.it

Univ. of Rome Tor Vergata / CNIT

stefano.salsano@uniroma2.it

AREA WG Working Group IOAM IPv6 In-band telemetry Metadata Extensible metadata carried within the IOAM Pre-allocated Trace Option (PTO) can support packet-level, flow-level, or path-level processing beyond per-node trace data. This document defines the Global Opaque Block (GOB), an extension to the IOAM PTO that introduces a single pre-allocated global metadata region placed between the PTO fixed header and the node data list. The GOB carries an explicit length and schema identifier, preserves the pre-allocated PTO processing model, and can be used to transport Extensible In-band Processing (EIP) Information Elements or other structured metadata formats. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the EIP SIG mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The IOAM Pre-allocated Trace Option (PTO) defined in and provides a structured way to carry in-band operational and telemetry information along a packet path. In the PTO model, the encapsulating node pre-allocates space for node data that can be filled by IOAM-capable nodes along the path. This document defines an extension to the IOAM PTO called the Global Opaque Block (GOB). The GOB is a global metadata region that appears once in the PTO, immediately after the PTO fixed header and before the per-node node data list. The GOB is identified by a presence bit in the PTO header and includes its own length and schema fields. The GOB enables the carriage of structured global metadata within the IOAM PTO, while preserving the existing PTO processing model for per-node trace data. In particular, the GOB can carry Extensible In-band Processing (EIP) Information Elements or other schema-driven metadata formats, without modifying the semantics of the node data list. The GOB is pre-allocated by the encapsulating node. Transit nodes MAY read or update the GOB payload, subject to the bounds established at encapsulation time, but they MUST NOT alter the overall GOB size or the layout of the enclosing PTO option. This document specifies the GOB format, length and alignment rules, and processing behavior for encapsulating, transit, and egress or collector nodes. An implementation and experimental evaluation of the proposed GOB approach within the Linux IOAM framework are described in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document:

GOB:

Global Opaque Block. A structured global metadata region inserted into the IOAM PTO.

GOB Header:

The 4-octet fixed header of the GOB, containing the GOB Len and Schema fields.

GOB Payload:

The payload that follows the GOB Header. Its size is determined by the GOB Len field.

PTO:

The IOAM Pre-allocated Trace Option defined in and .

Node Data List:

The sequence of pre-allocated per-node data slots defined by the PTO format.

Ingress Node:

The encapsulating node that inserts the IOAM PTO and, when present, allocates and initializes the GOB.

Transit Node:

An IOAM-capable node along the path that may process the PTO and may read or update the GOB payload.

Egress or Collector Node:

A node that removes, terminates, exports, or otherwise interprets the IOAM information carried in the packet.

Schema:

A 24-bit identifier that specifies how the GOB Payload is to be interpreted.

Design Overview The GOB extends the IOAM PTO with a global metadata area that is logically distinct from the per-node node data list. It is intended for metadata that applies to the packet, flow, or path as a whole, rather than to a specific transit node. The GOB appears at most once in a PTO option. When present, it is placed immediately after the PTO fixed header and before the start of the node data list. The GOB consists of a fixed 4-octet header followed by a variable-length payload. The GOB preserves the pre-allocated nature of the PTO model. The ingress node allocates the GOB space at encapsulation time and determines its size, its schema, and the overall PTO layout. Transit nodes MAY modify the contents of the GOB payload, but MUST NOT modify the GOB Len field, the Schema field, or any PTO fixed-header fields that precede the GOB. The GOB is intended to support structured metadata formats. One relevant use case is the carriage of Extensible In-band Processing (EIP) Information Elements, but the mechanism is not restricted to EIP and may be used with other schema-driven payload formats. The addition of the GOB does not change the semantics of the per-node node data list. The GOB complements the PTO by adding a global opaque area while leaving the existing per-node trace structure intact.

GOB Format

PTO Layout with GOB When the Global Opaque Block (GOB) is present, the IOAM Pre-allocated Trace Option (PTO) is extended by inserting a single GOB between the PTO fixed header and the Node Data List. The resulting layout is:

1. PTO fixed header
2. GOB Header
3. GOB Payload
4. Node Data List
5. Tail padding, if required to satisfy alignment of the enclosing Hop-by-Hop Options header

The GOB is indicated by the G bit in the PTO fixed header. If the G bit is clear, no GOB is present and PTO processing follows the base PTO format. The GOB appears at most once in a PTO option.

GOB Header Fields The GOB Header is 4 octets long and contains the following fields:

GOB Len:

An 8-bit field that specifies the size of the GOB Payload in units of 4 octets.

Schema:

A 24-bit field that identifies the format of the GOB Payload.

The total size of the GOB is therefore: where the first 4 octets correspond to the GOB Header itself. The Schema field allows the GOB Payload to be interpreted according to a structured format. One important use case is the carriage of Extensible In-band Processing (EIP) Information Elements, but the GOB is not limited to EIP and may carry other schema-driven metadata formats.

Byte-Level Layout The following figure shows the byte-level layout of the IOAM PTO with the GOB present.

IOAM PTO with Global Opaque Block (GOB)

More explicitly, the internal structure is:

Detailed PTO layout with GOB, Node Data List, and tail padding

The GOB Header is placed immediately after the PTO fixed header. The GOB Payload immediately follows the GOB Header. The Node Data List begins immediately after the GOB Payload. Any final tail padding is added only to satisfy alignment requirements of the enclosing Hop-by-Hop Options header.

Length and Alignment Rules This section defines the length relations used when the GOB is present in the IOAM PTO.

GOB Length The GOB Payload length is determined by the GOB Len field: The total GOB size, including the fixed 4-octet GOB Header, is: The GOB Len field is set by the ingress node at encapsulation time. Transit nodes MAY modify the content of the GOB Payload, but MUST NOT modify the GOB Len field and therefore MUST NOT alter the total GOB size.

Internal PTO Offsets Let:

• Y be the offset immediately following the GOB Payload;
• Y' be the offset immediately following the Node Data List;
• Y'' be the IOAM option length rounded up to the next multiple of 8 octets.

Then: In these expressions:

• sizeof(IOAM_TLV) - 2 excludes the Option Type and Option Length octets already accounted for in the option layout;
• sizeof(IOAM_PTO_HDR) is the fixed PTO header size;
• RemainingLen retains its PTO meaning and determines the amount of pre-allocated space associated with the Node Data List.

The Node Data List therefore starts immediately after the GOB and spans RemainingLen * 4 octets.

IOAM Option Length and Hop-by-Hop Header Length The IOAM Option Length field MUST be set to Y'', that is, to the total internal length of the IOAM option after rounding up to the required alignment. The enclosing Hop-by-Hop Options header length is derived from the total size of the header, including:

• the 2-octet Next Header and Hdr Ext Len fields;
• any PadN option used to align the start of the IOAM option;
• the IOAM option itself, including any final tail padding.

Let HBH_LEN denote the total Hop-by-Hop Options header size in octets. Then: where the leading 4 octets account for:

• 2 octets for Next Header and Hdr Ext Len;
• 2 octets for the PadN option that aligns the IOAM option start.

The IPv6 Hdr Ext Len field is encoded as:

Alignment Semantics As specified in , the Hop-by-Hop Options header is encoded so that its total length is a multiple of 8 octets, and the Hdr Ext Len field carries that length in 8-octet units, not including the first 8 octets. The final tail padding used to align the enclosing Hop-by-Hop Options header to an 8-octet boundary is not part of the GOB and is not part of the Node Data List. More specifically:

• Y identifies the end of the GOB;
• Y' identifies the end of the Node Data List;
• Y'' identifies the aligned end of the IOAM option.

The difference between Y' and Y'' is due only to final alignment padding and does not carry GOB or node-data semantics.

Preservation of PTO Semantics The presence of the GOB does not alter the semantics of RemainingLen or the pre-allocated nature of the PTO. The ingress node determines, at encapsulation time:

• the GOB size;
• the start of the Node Data List;
• the size of the Node Data List;
• the final aligned IOAM option length.

Transit nodes operate only within the pre-allocated bounds of the GOB Payload and the Node Data List, and MUST NOT change the overall layout of the PTO option. In this way, the pre-allocated model of the PTO is preserved while extending the option with a structured global metadata region.

Processing Semantics

Ingress Node Behavior An ingress node that inserts a GOB into the PTO:

• MUST set the G bit to 1;
• MUST allocate the full GOB space at encapsulation time;
• MUST set the GOB Len field;
• MUST set the Schema field;
• MUST determine the final PTO layout, including the GOB, the Node Data List, and any required tail padding.

The ingress node MAY initialize the GOB Payload with structured metadata, zero values, or other schema-defined initial content.

Transit Node Behavior A transit node that processes a PTO containing a GOB:

• MAY read the GOB Payload;
• MAY update fields within the GOB Payload, subject to the schema in use;
• MUST NOT modify the GOB Len field;
• MUST NOT modify the Schema field;
• MUST NOT modify PTO fixed-header fields that precede the GOB;
• MUST NOT change the overall size or layout of the PTO option.

A transit node MUST confine any GOB update to the pre-allocated GOB Payload bounds established by the ingress node.

Egress or Collector Behavior An egress or collector node that processes a PTO containing a GOB:

• MAY parse the GOB Payload according to the Schema field;
• MAY export the GOB content as structured metadata or as raw bytes;
• MAY ignore the GOB Payload if the Schema value is unknown or not supported.

If the Schema value is unknown, the node MUST NOT infer semantics beyond the presence and length of the GOB.

Relation to PTO Semantics The GOB preserves the pre-allocated semantics of the IOAM PTO. The ingress node continues to determine the overall PTO allocation at encapsulation time. This includes the size of the node data list and, when present, the size of the GOB. Transit nodes operate only within the pre-allocated space and do not change the overall layout of the PTO. The Node Data List retains its existing semantics and processing model. The GOB does not redefine the per-node trace data structure and does not replace the node data list. Instead, it introduces a distinct global metadata region placed before the node data list. In this sense, the pre-allocated nature of the PTO applies both to the per-node trace space and to the GOB. The GOB extends the PTO with a global opaque area while preserving the original PTO processing model.

Schema Semantics and Extensibility The Schema field identifies the format of the GOB Payload. A Schema value may identify:

• a sequence of EIP Information Elements;
• another structured metadata format defined by a specification;
• a locally defined or domain-specific format.

This document defines the GOB container, but does not define the internal syntax of individual schema-specific payloads. The semantics of the GOB Payload therefore depend on the specification associated with the Schema value in use. Future specifications may define registries, allocation policies, or schema-specific processing rules for GOB Payload formats. A Schema value of 0 indicates a locally defined or domain-specific format. Future specifications that define registries or allocation policies for Schema values MUST preserve this reservation.

Integration with EIP One important use of the GOB is the carriage of Extensible In-band Processing (EIP) Information Elements. The GOB provides a natural container for EIP within the IOAM PTO because it offers a single global metadata region with explicit length and schema identification, distinct from the per-node trace data. This makes it suitable for metadata that is flow-level, packet-level, or path-level rather than node-local. Earlier work explored the integration of EIP into the IOAM framework through a different approach based on IOAM data fields . The GOB-based approach defined in this document provides an alternative integration model based on a pre-allocated global metadata region within the PTO. The GOB is a general container for structured metadata. It can carry EIP Information Elements, but it is not limited to EIP. The GOB-based integration has also been described and experimentally evaluated in .

Security Considerations The GOB introduces a global metadata region that may be read or modified by on-path nodes. Unauthorized access to, or modification of, the GOB Payload can affect telemetry interpretation, service behavior, or policy enforcement. For this reason, deployments of the GOB SHOULD be limited to controlled or trusted domains, consistent with the limited-domain assumptions often applied to IOAM deployments. The security implications of the GOB Payload also depend on the Schema in use. Some schemas may carry purely observational metadata, while others may influence packet treatment or convey more sensitive information. Schema-specific specifications SHOULD describe any additional confidentiality, integrity, or authorization requirements.

IANA Considerations This document defines the Global Opaque Block (GOB) as an extension to the IOAM Pre-allocated Trace Option. Two possible standardization approaches can be considered. A first approach is to reuse the existing codepoint of the IOAM Pre-allocated Trace Option and extend its format by defining the G bit and the associated GOB fields. In general, such an approach would be questionable, because it introduces a format extension that is not backward compatible with implementations that interpret the PTO according to the current specification and do not support the GOB extension. However, IOAM is typically intended for deployment in limited domains, under the operational control of a single administrative entity. In such environments, the operator can control software versions and protocol support across the involved devices. For this reason, a non-backward- compatible extension of the PTO format may still be a viable standardization choice in this specific context, provided that the deployment domain is managed in a coordinated manner. A second approach is to define a new codepoint for a PTO variant that supports the Global Opaque Block. In this case, the presence or absence of the GOB can still be indicated by the G bit, while the use of a distinct codepoint provides explicit protocol separation from the current PTO format and avoids ambiguity for non-updated implementations. This version of the document does not request IANA actions. Future versions may request updates to the relevant IOAM or IPv6 registries, depending on which standardization approach is selected.

References Normative References This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. n.d. n.d. Informative References Internet-Draft draft-eip-arch IEEE CSCN 2025 Conference IEEE/IFIP NOMS 2026

Acknowledgments TBD.