]> Univ. of Rome Tor Vergata / CNIT

stefano.salsano@uniroma2.it

Consultant

helbakoury@gmail.com

Telefonica, I+D

diego.r.lopez@telefonica.com

AREA WG Working Group IPv6 Extension Headers Extensible In-band Processing (EIP) extends the functionality of the IPv6 protocol considering the needs of future Internet services and advanced in-band metadata processing. This document discusses the architecture and framework of EIP. Separate documents respectively analyze a number of use cases for EIP, provide protocol specifications for EIP, and describe the integration of EIP within the IOAM framework through the Global Opaque Block (GOB) of the IOAM Pre-allocated Trace Option. 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 Networking architectures need to evolve to support the needs of future Internet services and 6G networks. The networking research and standardization communities have considered different approaches for this evolution, that can be broadly classified in 3 different categories:

1. Clean slate and "revolutionary" solutions. Throw away the legacy IP networking layer.
2. Solutions above the layer 3. Do not touch the legacy networking layer (IP).
3. Evolutionary solutions. Improve the IP layer (and try to preserve backward compatibility).

The proposed EIP (Extensible In-band Processing) solution belongs to the third category, it extends the current IPv6 architecture without requiring a clean-slate revolution. The use cases for EIP are discussed in . The specification of the EIP header format is provided in .

Basic principles for EIP An ongoing trend is extending the functionality of the IPv6 networking layer, going beyond the plain packet forwarding. An example of this trend is the rise of the SRv6 "network programming" model. With the SRv6 network programming model, the routers can implement "complex" functionalities and they can be controlled by a "network program" that is embedded in IPv6 packet headers. Another example is the INT (IN band Telemetry) solution for monitoring. These (and other) examples are further discussed in . The EIP solution is aligned with this trend, which will ensure a future proof evolution of networking architectures. EIP supports a feature-rich and extensible IPv6 networking layer, in which complex dataplane functions can be executed by end-hosts, routers, virtual functions, servers in datacenters so that services can be implemented in the smartest and more efficient way. The EIP solution foresees the introduction of an EIP header in the IPv6 packet header. The proposed EIP header is extensible and it is meant to support a number of different use cases. In general, both end-hosts and transit routers can read and write the content of this header. Depending of the specific use-case, only specific nodes will be capable and interested in reading or writing the EIP header. The use of the EIP header can be confined to a single domain or to a set of cooperating domains, so there is no need of a global, Internet-wide support of the new header for its introduction. Moreover, there can be usage scenarios in which legacy nodes can simply ignore the EIP header and provide transit to packets containing the EIP header. The EIP header could be carried in different ways inside the IPv6 header: 1) as an EIP Option in the Hop-by-Hop Extension Header; 2) as an EIP TLV in the Segment Routing Header; 3) within the IOAM framework through the Global Opaque Block (GOB) of the IOAM Pre-allocated Trace Option, as specified in and discussed in . An important usage scenario considers the transport of user packets over a provider network. In this scenario, we consider the network portion from the provider ingress edge node to the provider egress edge node. The ingress edge node can encapsulate the user packet coming from an access network into an outer packet. The outer packet travels in the provider network until the egress edge node, which will decapsulate the inner packet and deliver it to the destination access network or to another transit network, depending on the specific topology and service. Assuming that the IPv6/SRv6 dataplane is used in the provider network, the ingress edge node will be the source of an outer IPv6 packet in which it is possible to add the EIP header. The outer IPv6 packet (containing the EIP header) will be processed inside the "limited domain" (see ) of the provider network, so that the operator can make sure that all the transit routers either are EIP aware or at least they can forward packets containing the EIP header. In this usage scenario, the EIP framework operates "edge-to-edge" and the end-user packets are "tunneled" over the EIP domain. The architectural framework for EIP is depicted in . We refer to nodes that are not EIP capable as legacy nodes. An EIP domain is made up by EIP aware routers (EIP R) and can also include legacy routers (LEG R). At the border of the EIP domain, EIP edge nodes (EIP ER) are used to interact with legacy End Hosts / Servers (LEG H) and with other domains. It is also possible that an End Host / Server is EIP aware (EIP H), in this case the EIP framework could operate "edge-to-end" or "end-to-end".

EIP framwork

As shown in , an EIP domain can communicate with other domains, which can be legacy domains or EIP capable domains.

Benefits of a common EIP header for multiple use cases. The EIP header will carry different EIP Information Elements that are defined to support the different use cases. There are reasons why it is beneficial to define a single common EIP header that supports multiple use cases using the EIP Information Elements.

1. The number of available Option Types in HBH header is limited (see ). Likewise the number of available TLVs in the Segment Routing Header (SRH) and the number of IOAM-Data-Field-Type are limited. Defining multiple Option Types (or SRH TLVs or IOAM-Data-Field-Type) for multiple use case is not scalable and puts pressure on the allocation of such codepoints.
2. The definition and standardization of specific EIP Information Elements for the different use cases will be simplified, compared to the need of requiring the definition of a new Option Type or SRH TLVs or IOAM-Data-Field-Type.
3. Different use cases may share a subset of common EIP Information Elements.
4. Efficient mechanism for the processing of the EIP header (both in software and in hardware) can be defined when the different EIP Information Elements are carried inside the same EIP header.

Considerations on Hop-by-hop Options allocation Several proposals and already standardized solutions use the IPv6 Hop-by-Hop Options, as discussed below in . The Hop-by-Hop Options are represented with a 8 bits code. The first two bits represent the action to be taken if the Options is unknown to a node that receives it, the third bit is used to specify if the content of the Options can be changed in flight. In particular the Option Types that start with 001 should be ignored if unknown and can be changed in flight, which is the most common combination. The current IANA allocation for Option Types starting with 001 is (see https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml) 32 possible Option Types starting with 001 5 allocated by RFCs (including IOAM and AltMark) 27 not allocated We observe that there is a potential scarcity of the code points, as there are many scenarios that could require the definition of a new Hop-by-Hop option. We also observe that having only 1 code point allocated for experiments is a very restrictive limitation.

Review of recent activities that propose to extend the IP networking layer

Standardized and proposed evolutions of IPv6 In the last few years, we have witnessed important innovations in IPv6 networking, centered around the emergence of Segment Routing for IPv6 (SRv6) and of the SRv6 "Network Programming model" . With SRv6 it is possible to insert a Network program, i.e. a sequence of instructions (called segments), in a header of the IPv6 protocol, called Segment Routing Header (SRH). Recent updates (see ) introduced compression mechanisms for segment lists, improving scalability for long segment chains. Another recent activity that proposed to extend the networking layer to support more complex functions concerns network monitoring. The concept of INT "In-band Network Telemetry" has been proposed since 2015 in the context of the definition of use cases for P4 based data plane programmability. The latest version of INT specifications dates November 2020 . specifies the format of headers that carry monitoring instructions and monitoring information along with data plane packets. The specific location for INT Headers is intentionally not specified: an INT Header can be inserted as an option or payload of any encapsulation type. The In-band Telemetry concept has been adopted by the IPPM IETF Working Group, renaming it "In-situ Operations, Administration, and Maintenance" (IOAM). discusses the data fields and associated data types for IOAM. The in-situ OAM data fields can be encapsulated in a variety of protocols, including IPv6. The specification details for carrying IOAM data inside IPv6 headers are provided in . In particular, IOAM data fields can be encapsulated in IPv6 using either Hop-by-Hop Options header or Destination options header. A Direct Export variant has been defined in , enabling nodes to export telemetry data directly without per-hop accumulation. Another example of extensions to IPv6 for network monitoring is specified in , which defines an IPv6 Destination Options header called Performance and Diagnostic Metrics (PDM). The PDM option header provides sequence numbers and timing information as a basis for measurements. The "Alternate Marking Method" is a recently proposed performance measurement approach described in . defines a new Hop-by-Hop Option to support this approach. "Path Tracing" proposes an efficient solution for recording the route taken by a packet (including timestamps and load information taken at each hop along the route). This solution needs a new Hop-by-Hop Option to be defined. A new lightweight telemetry mechanism has been proposed in , which accumulates end-to-end delay and congestion flags in a fixed-size structure. analyses the evolution of transport protocols. It recommends that explicit signals should be used when the endpoints desire that network elements along the path become aware of events related to transport protocol. Among the solutions, considers the use of explicit signals at the network layer, and in particular it mentions that IPv6 hop-by-hop headers might suit this purpose. specifies a new IPv6 Hop-by-Hop option that is used to record the minimum Path MTU between a source and a destination. describes an experiment in which VPN service information for both Layer 2 and Layer 3 VPNs is encoded in an IPv6 Destination Option. This experimental IPv6 Destination Option is called the VPN Service Option. The Internet Draft proposes a new Hop-by-Hop option of IPv6 extension header to carry the Network Resource Partition (NRP) information, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. The Internet-Draft proposes an IPv6 based address label terminal identity authentication mechanism, which uses a new Hop-by-Hop option, called Address Label Extension (ALE). The Internet-Draft (currently expired) proposed the Firewalls and Service Tickets (FAST) protocol. This is a generic and extensible protocol for hosts to signal network nodes to request services or to gain admission into a network. Tickets are sent in IPv6 Hop-by-Hop options. The Internet-Draft (currently expired) provided considerations for common QoS IPv6 extension header, in the context of the functionality under definition in the Deterministic Networking (detnet) IETF Working Group . The Internet-Draft (currently expired) proposed a new Hop-by-Hop option of IPv6 extension header to carry the topology identifier, which is used to identify the forwarding table instance created by the Multi Topology Routing or Flexible Algorithm. The Internet-Draft (currently expired) discussed the need of having a generic approach for carrying identifiers in IPv6 Destination Options and Hop-by-Hop Options. The EIP proposal can be seen as a superset and a further generalization of the proposal of .

Additional relevant activities The IETF has shown interest in carrying application or service-level metadata in IPv6. The Application-aware Networking (APN) BoF discussed embedding such metadata, leading to proposals like APN6. The recently chartered CATS (Compute-Aware Traffic Steering) WG explores approaches where traffic is steered based on in-packet compute-related information. The GREEN WG (Getting Ready for Energy-Efficient Networking), formed in 2024, investigates telemetry for carbon-aware routing. The COIN IRTF RG has discussed in-network processing requirements that also point to in-band metadata handling. The FANTEL BoF (IETF 123, Madrid, 2025) discussed the Fast Notification for Traffic Engineering and Load Balancing framework . FANTEL proposes in-band mechanisms to signal network conditions such as congestion or link degradation using IPv6 packets. These notifications are inserted by routers to support real-time traffic steering decisions. The goals of FANTEL align with the EIP approach, which provides an extensible container for in-band metadata through EIP Information Elements. The EIP header could encapsulate FANTEL notifications without requiring additional Hop-by-Hop Option codepoints, supporting both domain-specific and broader deployments. Outside the IETF, the P4.org community continues its efforts on programmable dataplanes and has proposed updated INT mechanisms. Recent research includes the use of in-band headers for on-path inference and service-specific packet handling, showing increasing interest in general, extensible frameworks like EIP.

Integration of EIP into the IOAM Framework The IOAM (In-situ Operations, Administration, and Maintenance) framework defines a set of data fields and associated semantics for recording telemetry and operational information within packets as they traverse a network. The IOAM data can be encapsulated in IPv6 via Hop-by-Hop or Destination Options headers, as specified in , and can be processed by IOAM-capable nodes along the path. An earlier integration direction for EIP within IOAM was explored in , where EIP was modeled as a new IOAM Data-Field-Type carried within the existing IOAM data-field structure. That approach showed that EIP Information Elements could be embedded into the IOAM processing pipeline, enabling reuse of the existing IOAM encapsulation and processing model without introducing separate Hop-by-Hop options. The current integration direction adopts a different approach based on the Global Opaque Block (GOB) of the IOAM Pre-allocated Trace Option, as specified in . In this model, EIP Information Elements can be carried inside a reusable, pre-allocated global metadata region that is distinct from the per-node Trace data and can support schema-driven formats and controlled in-band updates. Compared to the earlier Data-Field-Type approach, the GOB-based integration provides a more general and implementation-friendly solution for structured global metadata within IOAM. It preserves compatibility with the IOAM encapsulation model while avoiding the need to map EIP semantics onto the existing per-node data-field abstraction. The IOAM-based integration of EIP is not mutually exclusive with the standalone deployment of EIP as an independent IPv6 extension header. However, for integration with IOAM, the GOB-based approach is considered the preferred solution.

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.

Security Considerations TODO Security

IANA Considerations The definition of the EIP header as an Option for the IPv6 Hop-by-Hop Extension header requires the allocation of a codepoint from the "Destination Options and Hop-by-Hop Options" registry in the "Internet Protocol Version 6 (IPv6) Parameters" . The definition of the EIP header as a TLV in the Segment Routing Header requires the allocation of a codepoint from the "Segment Routing Header TLVs" registry in the "Internet Protocol Version 6 (IPv6) Parameters" . The definition of EIP Information Elements in the EIP header will require the creation of a new IANA registry to manage EIP Information Element type values. An earlier integration of EIP into IOAM as a new Data-Field-Type was explored in , which would have required an allocation from the "IOAM Data Field Types" registry . The currently preferred IOAM integration for EIP is instead based on the Global Opaque Block (GOB), whose protocol format and any related codepoint requirements are specified in .

References Normative References 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. Informative References Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document. This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321. This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. 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. This document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the Option. This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header. 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 situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAM Direct Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document. Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option. The experimental IPv6 Destination Option is called the VPN Service Option. One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment. Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Broadcom Alibaba, Inc SoftBank Goldman Sachs Arrcus Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. Huawei Technologies Huawei Technologies China Telecom China Telecom Verizon Inc. Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (which is called NRP Selector) need to be used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information (e.g., identifier) in data packets. The NR Option can be used to carry NRP Selector ID and related information, while it is designed to make the NR option generalized for other network resource semantics and functions. BUPT THU BUPT BUPT BUPT This document proposes an IPv6-based address label terminal identity authentication architecture, which tightly binds identity information to the source address of data packets. This approach enables hop-by- hop identity authentication while ensuring source address verification. The mechanism facilitates user identity verification, ensuring privacy protection, security, and efficient auditing. Additionally, this document details the implementation of address label authentication within the IPv6 extension header. SiPanda This document describes the Firewalls and Service Tickets (FAST) protocol. This is a generic and extensible protocol for hosts to signal network nodes to request services or to gain admission into a network. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network services to be applied (in the latter case the ticket serves as a service profile). Applications request tickets from a local agent in their network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to packets. A single ticket may provide both firewall and service ticket information and semantics. Tickets are sent in IPv6 Hop-by-Hop options. Futurewei Technologies USA Sangmyung University ZTE Corp. Huawei This document is written to start a discussion and collect opinions and ansers to questions raised in this document on the issue of defining IPv6 extension headers for DETNET-WG functionality with IPv6. Huawei Technologies Huawei Technologies Huawei Technologies This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the topology identifier, which is used to identify the forwarding table instance created by the Multi Topology Routing or Flexible Algorithm. ULiege Some recent use cases have a need for carrying an identifier in IPv6 packets. While those drafts might perfectly make sense on their own, each document requires IANA to allocate a new code point for a new option, and so for very similar situations, which could quickly exhaust the allocation space if similar designs are proposed in the future. As an example, one might need an 8-bit ID, while another one might need a 32-bit, 64-bit or 128-bit ID. Or, even worse, one might need a 32-bit ID in a specific context, while someone else might also need a 32-bit ID in another context. Therefore, allocating a new code point for each similar option is probably not the way to go. Huawei Huawei Huawei Huawei This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. n.d. Univ. of Rome Tor Vergata / CNIT Consultant Univ. of Rome Tor Vergata / CNIT Consultant Internet Engineering Task Force n.d.

Acknowledgments TODO acknowledge.