]> Univ. of Rome Tor Vergata / CNIT

stefano.salsano@uniroma2.it

Univ. of Rome Tor Vergata / CNIT / Common Net

andrea.mayer@uniroma2.it

AREA SIG on EIP IPv6 Extension Headers This document discusses the format of EIP protocol elements and the transport of EIP in different IPv6-based protocol headers. In particular, this document defines the standalone EIP formats for the IPv6 Hop-by-Hop Options Header and for the Segment Routing Header, and it defines the generic format of EIP Information Elements. Other approaches to transport EIP, including integration with the IOAM framework through the Global Opaque Block (GOB), are described in separate documents. Caveat: this document is still in brainstorming stage, it is distributed to stimulate discussion. 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 EIP header is used to carry information that IPv6 nodes (hosts and routers) can read and write to support different use cases. The use cases for EIP are discussed in . EIP provides a common architecture and framework which can be extended/tailored for the different use cases. The EIP architecture is discussed in . The present document focuses on the standalone EIP formats and on the generic definition of EIP Information Elements, while other documents describe additional approaches to transport EIP. The design of the EIP header takes into account the requirement to be efficient and "hardware friendly" (i.e. the effort and cost to implement EIP in hardware achieving line rate forwarding needs to be reasonable). The benefits of having EIP as a common header and framework to support multiple use cases are discussed in . EIP can be transported in different ways within IPv6. This document defines two standalone approaches: 1) an EIP Option for the Hop-by-Hop Options Header; and 2) an EIP TLV for the Segment Routing Header. Additional approaches to transport EIP are also possible. In particular, EIP Information Elements can be carried within the IOAM framework through the Global Opaque Block (GOB) of the IOAM Pre-allocated Trace Option, as described in .

Standalone EIP Transport in the Hop-by-Hop Options Header The EIP header can be carried as an Option in the Hop by Hop Extension Header, as shown in the following figure. Option type First 3 bits in Option type field:

• 0 0 Skip if not implemented
• 1 Content might change at every hop

(eventually) EIP code needs to be allocated by IANA for the time being we use 11110, so overall the Option Type for EIP is 0x3E (001 11110) RFC3692-style Experiment Opt Data Len is the length in bytes of the rest of the EIP Option Within the EIP Option, we have a LTV structure:

Standalone EIP Transport in the Segment Routing Header The EIP header can be carried as a TLV in the Segment Routing Header. A generic TLV in the SRH is defined as follows. First bit in type field: 1 - Content might change at every hop type code needs (eventually) to be allocated by IANA for the time being we use 252 for the EIP TLV. This is part of the experimental range 252-254 Experimentation and Test NB current IANA allocation for Types starting with 1 is (see https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segment-routing-header-tlvs) 128-251 Unassigned 252-254 Experimentation and Test 255 Reserved The EIP TLV for SRH will carry a set of EIP Information Elements as shown hereafter.

Other Approaches to Transport EIP The standalone formats defined in this document are not the only possible ways to transport EIP Information Elements. As discussed in , EIP is an architectural framework for structured in-band metadata and processing, and it can be mapped onto different IPv6-based protocol containers. In addition to the standalone EIP Option for the Hop-by-Hop Options Header and the standalone EIP TLV for the Segment Routing Header, another important approach is to carry EIP Information Elements within the IOAM framework through the Global Opaque Block (GOB) of the IOAM Pre-allocated Trace Option, as described in . For this reason, this document should be read as defining the generic EIP Information Elements and two standalone transport formats, rather than as restricting EIP to a single protocol representation.

Generic Format of EIP Information Elements EIP Information Elements are used to carry the information needed by the different use cases. The same Information Element can be reused across multiple use cases. The same EIP Information Elements can also be used across different approaches to transport EIP, including the standalone formats defined in this document and other mappings such as the IOAM/GOB-based approach. A fundamental requirement for EIP is to be "Extensible", therefore we need to have a potentially large number of different Information Elements. On the other hand, we may need to be efficient, limiting the overhead in bytes for carrying a given information. In order to have the possibility to find the optimal trade-off between these contrasting requirements, the Codes or "Tags" for the Information Elements can have different sizes. In particular, we select a solution in which the Codes can have three different lengths (respectively one byte, two bytes or three bytes). In order to support the variability in the size of the Code of the Information Element, we use an LTV (Length-Tag-Value) approach instead of TLVs (Tag-Length-Value). We have considered two approaches for the structure of the EIP Information Elements or EIP LTVs.

Proposed approach #1 for EIP LTVs. In this approach, we have one byte LTV Data Length field. The LTV Data Len is in octets (up to 255 bytes for the LTV Data Length). In this approach, we can have 128 codes of one byte and 32768 codes of 2 bytes.

Proposed approach #2 for EIP LTVs. In this second approach, the first two bits of the Len field can differentiate the code length, and the remaining 6 bits will specify the length of the optional part of the LTV content in 32 bits units (4-octets units). The LTV Data length can be up to 63x4=252 bytes (covering the optional part). Note that when the Data Len is 0, the optional part of the LTV content is not present, and the Information Element is made only of 4 bytes (i.e. one row in the figures below). In this approach, we can have 256 codes of one byte, 65536 codes of 2 bytes and 2^24 codes of 3 bytes. The codes of one byte will be referred to as "Short codes", the codes of two bytes will be referred to as "Extended codes", the codes of three bytes will be referred to as "Double extended codes".

Decision on the approach for EIP LTVs The selected approach is the #2, because it is more flexible and it supports a much higher number of Information Elements Codes.

Definition of EIP Information Elements (a.k.a. EIP LTVs)

HMAC LTV Alignment requirement: 8n (TODO: maybe it will be 4n) The keyed Hashed Message Authentication Code (HMAC) LTV is OPTIONAL and has the following format: EIP extended LTV code: HMAC (see in ) Data Len: the length of HMAC LTV in 4-bytes units, excluding the first row: the counting starts from the second row (HMAC Key ID). RESERVED: 8 bits. MUST be 0 on transmission. HMAC Key ID: A 4-octet opaque number that uniquely identifies the pre-shared key and algorithm used to generate the HMAC. HMAC: Keyed HMAC, in multiples of 8 octets, at most 32 octets. The details of the use of the HMAC LTV (HMAC Generation and Verification and HMAC Algorithms) are borrowed from section 2.1.2 of RFC 8754 .

EIP Identifiers LTVs EIP identifiers can be used for different use-cases. For example, they can be used to identify a "slice", or a Customer, or they can be used to carry a "Contract Identifier". Two classes of EIP Identifies are defined, Short and Long Identifiers. Short Identifiers are 16 bits Identifiers. Long Identifiers are Nx32 bits long (N>=1). Long Identifiers can be further structured according to the specific use case. EIP Long Identifiers can also be used to carry sequence numbers or transaction identifiers to identify a specific packet or a specific transaction.

EIP Short Identifier LTV EIP-LTV code: Short Identifier (see in ) Data Len: The length of the variable-length data in 4-bytes units is zero in this case. Short Identifier: it is a 16 bits identifier, useful when up to 65536 different Identifiers are needed.

EIP Long Identifier LTV EIP extended LTV code: Long Identifier (see in ) Data Len: The length of the variable-length part of the data in 4-bytes units. ID type: maybe used to qualify different types of identifiers. By default it is zero. An ID type can be used to specify a structure for the variable length part of the Long Identifier. EIP Long Identifier: an identifier of variable length (in multiple of 4 bytes) The EIP Long Identifier LTV only carrying a Sequence Number is shown hereafter. The EIP Long Identifier LTV carrying a Sequence Number in addition to a generic Long identifier is shown hereafter. 1 | EIP_ext_cod=Long Identifier | ID type = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EIP Long Identifier (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Timestamps LTV: The Timestamp Information Element can used to collect timing information in different nodes along the packet path (source, destination, intermediate nodes), according to different use cases. EIP-LTV code: Timestamps (see in ) The "Timestamps TLV Parameters" is a 16 bits field, it is split into two 8 bits fields as follows: Type : it further characterizes the format and the content of Timestamps Timestamp Type: Basic = 1 LEN: the length of each timestamp Format: indicates the format of the timestamp RES: Reserved, set to 0 0 Example of a Timestamp TLV of type basic, that carries 8 timestamps of length 2 bytes, each one representing a time granularity of 10 us. NB using this granularity (10 us) and timestamp size (2 bytes), assuming that all node clocks are synchronized with a maximum error E [ms] it is possible to correctly evaluate hop-by-hop delays up to (655-E) [ms] The entire timestamp will be reconstructed at last node using system time and subtracting intermediate timestamps.

Node selection and identification LTV This Information Element can be used for two purposes: 1) associate some instruction contained in the EIP header to one or more target nodes in the "downstream" path of the packet example 1.1: ask a specific node to write some information in the EIP header, if this specific node will be crossed by the packet example 1.2: ask one node every N hops to write some information in the EIP header 2) identify the nodes that have inserted some information in the EIP header Scope : If Scope = 0x00 the node selection applies to all the following EIP Information Elements (LTVs) If Scope = N > 0x00 only to the first N LTVs following the Scope are affected by the selection.

Processing Accelerator LTV The purpose of this LTV is to identify a portion of the EIP Header that has a fixed pre-known format so that it can be processed in a more efficient way, rather than proceeding with a "sequential" parsing. This is can be used for parallel hardware processing, but also software processing can be optimized. For example, a pre-known sequence of LTVs following the Processing Accelerator LTV can be processed in parallel. The Processing Accelerator LTV can be used to know in advance the size and type of some fields of the following LTVs in order to speed up the processing. Proc. Accel. : EIP Short code (see in ) The Processing Acceleration ID is an opaque identifier, its definition is domain-specific.

Compact Path Tracing (CPT) LTV This LTV is a porting of the Internet Draft "draft-filsfils-spring-path-tracing" into the EIP framework. It contains a stack of "MCD" (Midpoint Compressed Data) representing information inserted by every transit router for path tracing purposes. Compact PT: EIP extended code (see in ) Type: 3 bits, specifies the content of the CPT LTV including the format of the MCD element. A: Authenticated, set to 1 in Authenticated Mode, 0 otherwise. HML: HMAC Length, set to 00 in unauthenticated mode. In authenticated mode, it stores the length of the HMAC field in 8 octets.\ MAC length = (HML + 1) * 8 bytes.\ Max length of the HMAC will be 32 octets. RES: Reserved, set to 00. The MCD Stack has variable size. recommends 36 octets for a MCD of 3 bytes (12 MCDs). In our case, taking into account the alignment requirements, we have the following recommendation. When MCD is 3 bytes, we recommend 13 MCDs for a total of 39 bytes. When MCD is 4 bytes, we recommend an even number of MCD, for example 10 for a total of 40 bytes or 12 for a total of 48 bytes.

Authenticated mode for Compact Path Tracing In the authenticated mode, an HMAC is appended at the end of the MCD Stack. The size of the HMAC is a multiple of 8 octets (maximum 32 octets). Each intermediate node calculates the HMAC for the whole CPT LTV, including the HMAC field. The newly calculated HMAC then overwrites the previous node's HMAC. The first node will just use an HMAC field set to all zeros. An identifier for every single node is not needed, because it can be derived from the MCD Stack. The destination node can reconstruct the different HMAC fields at each hop to check if the final HMAC is consistent.

Geotagged Compact Path Tracing

Geotagging LTV We describe an LTV for Semantic Routing use case. Geotagging for Semantic Routing: EIP extended code (see in ) S: (for Source) the Position includes the Source Location D: (for Destination) the Position includes the Destination Location Format: 3 bits, specifies the encoding used to represent the geographical location(s). RES: Reserved, set to 0. Position(s): Contains the geographical location data. Its length must be a multiple of 4 octets.

Format	Encoding
0	Quantized Long: Latitude 32 bits, Longitude 32 bits
1	Quantized Short: Latitude 16 bits, Longitude 16 bits
2	Geohash Long 60 bits (padded to 64 bits)
3	Geohash Short 30 bits (padded to 32 bits)

Quantized format as described in https://mmcloughlin.com/posts/geohash-assembly. Latitude and longitude are quantized by mapping to the unit interval [0, 1] and multiplying by 2^32 for Long format (32+32=64 bits) and by 2^16 for Short format (16+16=32 bits), as illustrated in the following formulas: Geohash format is an open source format specified in https://en.wikipedia.org/wiki/Geohash

Simple Two-Way Active Measurement Protocol (STAMP) LTV This is a porting to EIP of the STAMP implementation from RFC8972. The original implementation writes the STAMP data in the UDP payload, if the data is carried by EIP instead, the delay measurement can be performed in-band. This is true when the delay introduced by the reflector is not relevant for the purpose of the measurement. Indeed, the reflected STAMP data will be returned to the sender when another packet is available for piggy-backing the STAMP data. When the entire round-trip delay is relevant, at least the reflected packet should be sent out-of-band to achieve the smallest possible delay when the Reflector processes the packet. D: Direction, set to 0 if it carries Sender data, 1 for Reflector data. A: Authenticated, set to 1 for Authenticated Mode. RES: Reserved, 6 bits set to 0. The STAMP content is variable. It changes depending on the Direction and Authenticated values. Following is an example of a Session-Sender STAMP Information Element in Unauthenticated Mode: The detailed description of the remaining fields and of the other formats, for the Reflector and Authenticated mode, can be found in RFC8972.

Code assignment for EIP Information Elements (a.k.a. EIP LTVs)

LTV Short Codes Short Codes (1 bytes) for EIP LTVs

Information Element	Code
Short Identifier	0x01
Processing Accelerator	0x02
Timestamps	TBA

LTV Extended Codes Extended Codes (2 bytes) for EIP LTVs

Information Element	Code
HMAC	0x0001
Compact Path Tracing (CPT)	0x0002
Long Identifier	0x0003
Geotagging	0x0004

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 EIP introduces in-band information that may be inspected, inserted, or updated by nodes along the packet path. As a consequence, unauthorized access to, or modification of, EIP information can affect telemetry, service behavior, or policy enforcement. For this reason, EIP is primarily intended for deployment in controlled or limited domains, where the operator can manage protocol support and trust relationships among participating nodes. The specific security implications may depend on the protocol container used to transport EIP and on the semantics of the EIP Information Elements carried in the packet.

IANA Considerations This version of the document does not request IANA actions. Future versions may request IANA actions related to standalone EIP transport codepoints or to EIP Information Element code assignments. Other approaches to transport EIP, such as IOAM/GOB-based transport, are handled by their corresponding specifications.

References Normative 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. 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 Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Broadcom Swisscom 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. Univ. of Rome Tor Vergata / CNIT / Common Net Univ. of Rome Tor Vergata / CNIT 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. Univ. of Rome Tor Vergata / CNIT Consultant Telefonica, I+D 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. Univ. of Rome Tor Vergata / CNIT Consultant

Acknowledgments and Contributors The authors would like to thank the following people who contributed to this work. Giulio Sidoretti has contributed to the section on Compact Path Tracing and to a prototype eBPF-based implementation of EIP. Carmine Scarpitta has contributed to an early prototype implementation of EIP encoding in Linux. Hesham ElBakoury has contributed to the design of the EIP framework. Contributors' Addresses Hesham ElBakoury Consultant EMail: helbakoury@gmail.com Giulio Sidoretti Univ. of Rome Tor Vergata / CNIT EMail: giulio.sidoretti@uniroma2.it Carmine Scarpitta Univ. of Rome Tor Vergata / CNIT (at the time of contribution) Current affiliation: Cisco Systems EMail: cscarpit@cisco.com