Skip to main content

Extensible In-band Processing (EIP) Architecture and Framework

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Stefano Salsano , Hesham ElBakoury , Diego Lopez
Last updated 2022-06-15
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
WG Working Group                                              S. Salsano
Internet-Draft                          Univ. of Rome Tor Vergata / CNIT
Intended status: Informational                              H. ElBakoury
Expires: 17 December 2022                                     Consultant
                                                                D. Lopez
                                                         Telefonica, I+D
                                                            15 June 2022

     Extensible In-band Processing (EIP) Architecture and Framework


   Extensible In-band Processing (EIP) extends the functionality of the
   IPv6 protocol considering the needs of future Internet services / 6G
   networks.  This document discusses the architecture and framework of
   EIP.  Two separate documents respectively analyze a number of use
   cases for EIP and provide the protocol specifications of EIP.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://eip-  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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

Salsano, et al.         Expires 17 December 2022                [Page 1]
Internet-Draft              EIP Architecture                   June 2022

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 17 December 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Basic principles for EIP  . . . . . . . . . . . . . . . . . .   3
   3.  Benefits of a common EIP header for multiple use cases. . . .   4
   4.  Review of standardized and proposed evolutions of IPv6  . . .   5
     4.1.  Consideration on Hop-by-hop Options allocation  . . . . .   7
   5.  Conventions and Definitions . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  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

   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).

Salsano, et al.         Expires 17 December 2022                [Page 2]
Internet-Draft              EIP Architecture                   June 2022

   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 [id-eip-use-cases].  The
   specification of the EIP header format is provided in

2.  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 Section 4.

   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.

   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

Salsano, et al.         Expires 17 December 2022                [Page 3]
Internet-Draft              EIP Architecture                   June 2022

   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 [RFC8799]) 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 Figure 1.  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".

                                                          LEG domain

    +---+             +---+      +---+                +---+
    |EIP|_           _|EIP|______|EIP|             ___|LEG|
    | H | \__+---+__/ | R |      | R |__   +---+__/   | R | ...
    +---+    |EIP|    +---+      +---+  \__|EIP|      +---+
           __|ER |__    |          |     __|ER |__
    +---+_/  +---+  \_+---+      +---+__/  +---+  \___+---+
    |LEG|             |LEG|______|LEG|                |EIP|
    | H |             | R |      | R |                |ER | ...
    +---+             +---+      +---+                +---+

               +-----------------------------+          +------------+
                         EIP domain                       EIP domain

                           Figure 1: EIP framwork

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

3.  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 common EIP header that supports multiple
   use cases.

Salsano, et al.         Expires 17 December 2022                [Page 4]
Internet-Draft              EIP Architecture                   June 2022

   1.  The number of available Option Types in HBH header is limited,
       likewise the number of available TLVs in the Segment Routing
       Header (SRH) is limited.  Defining multiple Option Types or SRH
       TLVs for multiple use case is not scalable and puts pressure on
       the allocation of such codepoints.  This aspect is further
       discussed in Section 4.

   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.

   3.  Different use cases may share a subset of common EIP Information

   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.

4.  Review of 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) [RFC8754] and of the SRv6 "Network Programming model"
   [RFC8986].  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).

Salsano, et al.         Expires 17 December 2022                [Page 5]
Internet-Draft              EIP Architecture                   June 2022

   Another recent activity that proposed to extend the networking layer
   to support more complex functions, concerns the network monitoring.
   The concept of INT "In-band Network Telemetry" has been proposed
   since 2015 [onf-int] in the context of the definition of use cases
   for P4 based data plane programmability.  The latest version of INT
   specifications dates November 2020 [int-spec]. [int-spec] 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).  The internet draft
   [I-D.ietf-ippm-ioam-data] is about to become an IETF RFC.  Note that
   IOAM is focused on "limited domains" as defined in [RFC8799].  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 draft
   [I-D.ietf-ippm-ioam-ipv6-options], which is also close to becoming an
   RFC.  In particular, IOAM data fields can be encapsulated in IPv6
   using either Hop-by-Hop Options header or Destination options header.

   Another example of extensions to IPv6 for network monitoring is
   specified in [RFC8250], 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 [RFC8321].  The draft
   [I-D.draft-ietf-6man-ipv6-alt-mark] (also close to becoming an RFC)
   defines a new Hop-by-Hop Option to support this approach.

   "Path Tracing" [I-D.draft-filsfils-spring-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

   [RFC8558] 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 trasport protocol.  Among the solutions, [RFC8558]
   considers the use of explicit signals at the network layer, and in
   particular it mentions that IPv6 hop-by-hop headers might suit this

Salsano, et al.         Expires 17 December 2022                [Page 6]
Internet-Draft              EIP Architecture                   June 2022

   The Internet Draft [I-D.draft-ietf-6man-mtu-option] specifies a new
   IPv6 Hop-by-Hop option that is used to record the minimum Path MTU
   between a source and a destination.  This draft is close to become an

4.1.  Consideration on Hop-by-hop Options allocation

   We have listed several proposals or already standardized solutions
   that use the IPv6 Hop-by-Hop Options.  These 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

      32 possible Option Types starting with 001
      2 allocated by RFCs
      2 temporary allocated by Internet Drafts
      1 allocated for RFC3692-style Experiment
      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.

5.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

6.  Security Considerations

   TODO Security

Salsano, et al.         Expires 17 December 2022                [Page 7]
Internet-Draft              EIP Architecture                   June 2022

7.  IANA Considerations

   The definition of the EIP header as an Option for 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 definition of a IANA registry.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

8.2.  Informative References

              Filsfils, C., Abdelsalam, A., Garvia, P. C., Yufit, M.,
              Graf, T., Su, Y., Matsushima, S., and M. Valentine, "Path
              Tracing in SRv6 networks", Work in Progress, Internet-
              Draft, draft-filsfils-spring-path-tracing-01, 30 May 2022,

              Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate Marking Method",
              Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
              alt-mark-14, 28 April 2022,

Salsano, et al.         Expires 17 December 2022                [Page 8]
Internet-Draft              EIP Architecture                   June 2022

              Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU
              Hop-by-Hop Option", Work in Progress, Internet-Draft,
              draft-ietf-6man-mtu-option-15, 10 May 2022,

              Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
              for In Situ Operations, Administration, and Maintenance
              (IOAM)", Work in Progress, Internet-Draft, draft-ietf-
              ippm-ioam-data-17, 13 December 2021,

              Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
              Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
              ipv6-options-07, 6 February 2022,

              Salsano, S. and H. ElBakoury, "Extensible In-band
              Processing (EIP) Headers Definitions", 2022, <https://eip-

              Salsano, S. and H. ElBakoury, "Extensible In-band
              Processing (EIP) Use Cases", 2022, <https://eip-

   [int-spec] Group, T. P. A. W., "In-band Network Telemetry (INT)
              Dataplane Specification, version 2.1", n.d.,
              < v2 1.pdf>.

   [onf-int], "Improving Network Monitoring and Management with
              Programmable Data Planes", 2015,

   [RFC8250]  Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
              Performance and Diagnostic Metrics (PDM) Destination
              Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,

Salsano, et al.         Expires 17 December 2022                [Page 9]
Internet-Draft              EIP Architecture                   June 2022

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <>.

   [RFC8558]  Hardie, T., Ed., "Transport Protocol Path Signals",
              RFC 8558, DOI 10.17487/RFC8558, April 2019,

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,


   TODO acknowledge.

Authors' Addresses

   Stefano Salsano
   Univ. of Rome Tor Vergata / CNIT

   Hesham ElBakoury

   Diego R. Lopez
   Telefonica, I+D

Salsano, et al.         Expires 17 December 2022               [Page 10]