<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7799 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml">
  <!ENTITY RFC5475 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5475.xml"> nbsp    "&#160;">
  <!ENTITY RFC7014 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7014.xml"> zwsp   "&#8203;">
  <!ENTITY RFC6291 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"> nbhy   "&#8209;">
  <!ENTITY RFC9197 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml">
<!ENTITY RFC6724 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml">
<!ENTITY I-D.spiegel-ippm-ioam-rawexport SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.spiegel-ippm-ioam-rawexport.xml">
<!ENTITY I-D.ietf-sfc-ioam-nsh SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-sfc-ioam-nsh.xml">
<!ENTITY I-D.ietf-ippm-ioam-ipv6-options SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-ippm-ioam-ipv6-options.xml">
<!ENTITY AFI SYSTEM "http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xml"> wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-ippm-ioam-flags-10" ipr="trust200902"> number="9322" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.14.2 -->
  <front>
    <title abbrev="IOAM Flags">In-situ OAM Flags">In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags</title>
    <seriesInfo name="RFC" value="9322"/>
    <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
      <organization abbrev="">Huawei</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>Israel</country>
        </postal>
        <email>tal.mizrahi.phd@gmail.com</email>
      </address>
    </author>
    <author fullname="Frank Brockners" initials="F." surname="Brockners">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <postal>
      <extaddr>3rd Floor</extaddr>
      <street>Hansaallee 249, 3rd Floor</street>

          <!-- Reorder these if your country does things differently -->

          <city>DUESSELDORF</city>

          <region>NORDRHEIN-WESTFALEN</region> 249</street>
          <city>Duesseldorf</city>
  	      <code>40549</code>
          <country>Germany</country>
        </postal>
        <email>fbrockne@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
      <organization abbrev="Thoughtspot">Thoughtspot</organization>
      <address>
        <postal>
          <street>3rd Floor, Indiqube Orion, 24th
	  <extaddr>3rd Floor</extaddr>
	  <extaddr>Indiqube Orion</extaddr>
	  <extaddr>Garden Layout</extaddr>
	  <extaddr>HSR Layout</extaddr>
          <street>24th Main Rd, Garden Layout, HSR
          Layout</street>

          <city>Bangalore, KARNATAKA 560 102</city> Rd</street>
          <city>Bangalore</city>
	  <region>Karnataka</region>
	  <code>560 102</code>
          <country>India</country>
        </postal>
        <email>shwetha.bhandari@thoughtspot.com</email>
      </address>
    </author>
    <author fullname="Barak Gafni" initials="B." surname="Gafni">
      <organization abbrev="">Nvidia</organization>
      <address>
        <postal>
	  <extaddr>Suite 100</extaddr>
          <street>350 Oakmead Parkway, Suite 100</street>

          <city>Sunnyvale, CA</city> Parkway</street>
          <city>Sunnyvale</city>
	  <region>CA</region>
          <code>94085</code>

          <country>U.S.A.</country>
          <country>United States of America</country>
        </postal>
        <email>gbarak@nvidia.com</email>
      </address>
    </author>

<author fullname="Mickey Spiegel" initials="M." surname="Spiegel">
      <organization abbrev="">Barefoot abbrev="Barefoot Networks">Barefoot Networks, an Intel
      company</organization>
      <address>
        <postal>
          <street>4750 Patrick Henry Drive</street>
          <city>Santa Clara, CA</city> Clara</city>
	  <region>CA</region>
          <code>95054</code>

          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>mickey.spiegel@intel.com</email>
      </address>
    </author>
    <date year="2022"/> year="2022" month="November" />
    <area>TSV</area>
    <workgroup>IPPM</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->
    <keyword>IOAM</keyword>
    <keyword>Telemetry</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->
    <abstract>
      <t>In-situ
      <t>In situ Operations, Administration, and Maintenance (IOAM) collects
      operational and telemetry information in packets while they traverse a
      path between two points in the network. This document defines two new
      flags in the IOAM Trace Option headers, specifically the Loopback and
      Active flags.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default"> toc="default" numbered="true">
      <name>Introduction</name>
      <t>IOAM <xref target="RFC9197"/> target="RFC9197" format="default"/> is used for monitoring traffic in the
      network by incorporating IOAM data fields into in-flight data
      packets.</t>
      <t>IOAM data may be represented in one of four possible IOAM options:
      Pre-allocated Trace Option, Trace, Incremental Trace Option, Trace, Proof of Transit
      (POT) Option,
      (POT), and Edge-to-Edge Option. Edge-to-Edge. This document defines two new
      flags in the Pre-allocated and Incremental Trace options: the Loopback
      and Active flags.</t>
      <t>The Loopback flag is used to request that each transit device along
      the path loops back a truncated copy of the data packet to the sender.
      The Active flag indicates that a packet is used for active measurement.
      The term active measurement "active measurement" in the context of this document is as
      defined in <xref target="RFC7799"/>.</t> target="RFC7799" format="default"/>.</t>
    </section>
    <section anchor="Conventions" title="Conventions"> numbered="true" toc="default">
      <name>Conventions</name>
      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>Abbreviations used in this document:</t>

        <t><list hangIndent="11" style="hanging">
            <t hangText="IOAM:">In-situ
        <dl newline="false" spacing="normal" indent="8">
          <dt>IOAM:</dt>
          <dd>In situ Operations, Administration, and
            Maintenance</t>

            <t hangText="OAM:">Operations,
            Maintenance</dd>
          <dt>OAM:</dt>
          <dd>Operations, Administration, and Maintenance
            <xref target="RFC6291"/></t>
          </list></t> target="RFC6291" format="default"/></dd>
        </dl>
      </section>
    </section>
    <section title="New numbered="true" toc="default">
      <name>New IOAM Trace Option Flags"> Flags</name>
      <t anchor="TraceFlags" hangText="Flags">This anchor="TraceFlags">This document defines two new
      flags in the Pre-allocated and Incremental Trace options: <list
          style="hanging">
          <t hangText="Bit 1">"Loopback" (L-bit). When </t>

      <dl newline="false" spacing="normal">
        <dt>Bit 1 "Loopback" (L-bit):</dt>
        <dd>When set, the Loopback flag
          triggers the sending of a copy of a packet back towards the source, as
          further described in <xref target="LoopbackSec"/>.</t>

          <t hangText="Bit 2">"Active" (A-bit). When target="LoopbackSec" format="default"/>.</dd>
        <dt>Bit 2 "Active" (A-bit):</dt>
        <dd>When set, the Active flag
          indicates that a packet is an active measurement packet rather than
          a data packet, where "active" is used in the sense defined in <xref
          target="RFC7799"/>. target="RFC7799" format="default"/>. The packet may be an IOAM probe packet, packet or a
          replicated data packet (the second and third use cases of <xref
          target="UseCaseSec"/>).</t>
        </list></t> target="UseCaseSec" format="default"/>).</dd>
      </dl>
    </section>
    <section anchor="LoopbackSec" title="Loopback numbered="true" toc="default">
      <name>Loopback in IOAM"> IOAM</name>
      <t>The Loopback flag is used to request that each transit device along
      the path loops back a truncated copy of the data packet to the sender.
      Loopback allows an IOAM encapsulating node to trace the path to a given
      destination,
      destination and to receive per-hop data about both the forward and the return path.
      paths. Loopback is intended to provide an accelerated alternative to Traceroute,
      Traceroute that allows the encapsulating node to receive responses from
      multiple transit nodes along the path in less then than one
      round-trip-time, round-trip time (RTT)
      and by sending a single packet.</t>
      <t>As illustrated in <xref target="LoopbackFig"/>, target="LoopbackFig" format="default"/>, an IOAM encapsulating
      node can push an IOAM encapsulation that includes the Loopback flag onto
      some or all of the packets it forwards, forwards using one of the IOAM
      encapsulation types, e.g., <xref target="I-D.ietf-sfc-ioam-nsh"/>, target="I-D.ietf-sfc-ioam-nsh" format="default"/> or
      <xref target="I-D.ietf-ippm-ioam-ipv6-options"/>. target="I-D.ietf-ippm-ioam-ipv6-options" format="default"/>.
	  The IOAM transit node and the
      decapsulating node both creates create copies of the packet and loop them back
      to the encapsulating node. The decapsulating node also terminates the
      IOAM encapsulation, encapsulation and then forwards the packet towards the
      destination. The two IOAM looped back looped-back copies are terminated by the
      encapsulating node.</t>
      <figure align="center" anchor="LoopbackFig" title="Loopback anchor="LoopbackFig">
        <name>Loopback in IOAM."> IOAM</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
+--------+     +--------+     +--------+     +--------+     +--------+
|        |     |  IOAM  |.....|  IOAM  |.....|  IOAM  |     |        |
+--------+     +--------+     +--------+     +--------+     +--------+
| L2/L3  |<===>| L2/L3  |<===>| L2/L3  |<===>| L2/L3  |<===>| L2/L3  |
+--------+     +--------+     +--------+     +--------+     +--------+
  Source      Encapsulating    Transit      Decapsulating   Destination
                   Node           Node           Node

               <------------  IOAM domain  IOAM-Domain  ----------->

                    IOAM encap. with Loopback flag
Data packet  ------->============================>----------->
                                  |             |
                 IOAM looped back |             |
                    <=============+             |
                                IOAM looped back|
                    <===========================+
]]></artwork>
      </figure>
      <t>Loopback can be used only if a return path from transit nodes and
      destination nodes towards the source (encapsulating node) exists.
      Specifically, loopback is only applicable in encapsulations in which the
      identity of the encapsulating node is available in the encapsulation
      header. If an encapsulating node receives a looped back looped-back packet that was
      not originated from the current encapsulating node, the packet is
      dropped.</t>
      <section title="Loopback: numbered="true" toc="default">
        <name>Loopback: Encapsulating Node Functionality"> Functionality</name>
        <t>The encapsulating node either generates synthetic packets with an
        IOAM trace option that has the Loopback flag set, set or sets the loopack Loopback
        flag in a subset of the in-transit data packets. Loopback is used
        either proactively or on-demand, i.e., when a failure is detected. The
        encapsulating node also needs to ensure that sufficient space is
        available in the IOAM header for loopback operation, which includes
        transit nodes adding trace data on the original path and then again on
        the return path.</t>
        <t>An IOAM trace option that has the Loopback flag set MUST <bcp14>MUST</bcp14> have the
        value '1' in the most significant bit of IOAM-Trace-Type, IOAM-Trace-Type and '0' in
        the rest of the bits of IOAM-Trace-Type. Thus, every transit node that
        processes this trace option only adds a single data field, which is
        the Hop_Lim and node_id data field. A transit node that receives a
        packet with an IOAM trace option that has the Loopback flag set and
        the IOAM-Trace-Type is not equal to '1' in the most significant bit
        and '0' in the rest of the bits, MUST NOT bits <bcp14>MUST NOT</bcp14> loop back a copy of the
        packet. The reason for allowing only a single data field per hop is to
        minimize the impact of amplification attacks.</t>
        <t>IOAM encapsulating nodes MUST NOT <bcp14>MUST NOT</bcp14> push an IOAM encapsulation with
        the Loopback flag onto data packets that already include an IOAM
        encapsulation. This requirement is intended to prevent IOAM Loopback
        nesting,
        nesting where looped back looped-back packets may be subject to loopback in a
        nested IOAM domain.</t> IOAM-Domain.</t>
        <section anchor="SelectSec" title="Loopback numbered="true" toc="default">
          <name>Loopback Packet Selection"> Selection</name>
          <t>If an IOAM encapsulating node incorporates the Loopback flag into
          all the traffic it forwards forwards, it may lead to an excessive amount of
          looped back packets, which may overload the network and the
          encapsulating node. Therefore, an IOAM encapsulating node that
          supports the Loopback flag MUST <bcp14>MUST</bcp14> support the ability to incorporate
          the Loopback flag selectively into a subset of the packets that are
          forwarded by it.</t>
          <t>Various methods of packet selection and sampling have been
          previously defined, such as <xref target="RFC7014"/> target="RFC7014" format="default"/> and <xref
          target="RFC5475"/>. target="RFC5475" format="default"/>.
	  Similar techniques can be applied by an IOAM
          encapsulating node to apply Loopback loopback to a subset of the forwarded
          traffic.</t>
          <t>The subset of traffic that is forwarded or transmitted with a
          Loopback flag SHOULD NOT <bcp14>SHOULD NOT</bcp14> exceed 1/N of the interface capacity on any
          of the IOAM encapsulating node's interfaces. This requirement
          applies to the total traffic that incorporates a Loopback flag,
          including traffic that is forwarded by the IOAM encapsulating node
          and probe packets that are generated by the IOAM encapsulating node.
          In this context context, N is a parameter that can be configurable by network
          operators. If there is an upper bound, M, on the number of IOAM
          transit nodes in any path in the network, then configuring N such that
          N &gt;&gt; M (i.e., N is much greater than M) is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
		  The rationale is that a packet that
          includes the Loopback flag triggers a looped back looped-back packet from each
          IOAM transit node along the path for a total of M looped back looped-back
          packets. Thus, if N &gt;&gt; M M, then the number of looped back looped-back
          packets is significantly lower than the number of data packets
          forwarded by the IOAM encapsulating node. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
		  that the default value of N satisfies N&gt;100, N&gt;100 to be used
		  in the absence of explicit operator configuration or
		  if there is no prior knowledge about the network topology or size.</t>
          <t>An IOAM domain IOAM-Domain in which the Loopback flag is used MUST <bcp14>MUST</bcp14> be
		  configured such that there is expected to be a return path from each
		  of the IOAM transit and IOAM decapsulating nodes; if this expectation
		  does not apply, or if the encapsulating node's identity is not
          available in the encapsulation header, then configuration MUST NOT <bcp14>MUST NOT</bcp14>
		  enable the Loopback flag to be set.</t>
        </section>
      </section>
      <section anchor="ReceiveSec" title="Receiving numbered="true" toc="default">
        <name>Receiving and Processing Loopback"> Loopback</name>
        <t>A Loopback flag that is set indicates to the transit nodes
        processing this option that they are to create a copy of the received
        packet and send the copy back to the source of the packet. In this
        context
        context, the source is the IOAM encapsulating node, node and it is assumed
        that the source address is available in the encapsulation header.
        Thus, the source address of the original packet is used as the
        destination address in the copied packet. If IOAM is used over an
		encapsulation that does not include the address of the encapsulating
		node, then
        the transit/decapsulating node does not loop back a copy of the
        original packet. The address of the node performing the copy operation
        is used as the source address; the specific method of source address
		assignment is encapsulation specific, e.g., if an IPv6
		encapsulation is used, then the source address can be assigned as
		specified in <xref target="RFC6724"/>. target="RFC6724" format="default"/>.
		The copy is also truncated, i.e., any
        payload that resides after the IOAM option(s) is removed before
        transmitting the looped back looped-back packet back towards the encapsulating
        node. Creating the copy that is looped back, and specifically the
		truncation, may require some encapsulation-specific updates
		in the encapsulation header.
		The original packet continues towards its destination. The L-bit
        MUST
        <bcp14>MUST</bcp14> be cleared in the copy of the packet that a node sends back
        towards the source.</t>
        <t>An IOAM node that supports the reception and processing of the
        Loopback flag MUST <bcp14>MUST</bcp14> support the ability to limit the
        rate of the looped
        back looped-back packets. The rate of looped back looped-back packets SHOULD
        <bcp14>SHOULD</bcp14> be limited so that the number of looped back looped-back
        packets is significantly lower than the number of packets that are
        forwarded by the device. The looped back looped-back data rate SHOULD NOT <bcp14>SHOULD
        NOT</bcp14> exceed 1/N of the interface capacity on any of the IOAM
        node's interfaces. Using N&gt;100 is RECOMMENDED.
        <bcp14>RECOMMENDED</bcp14>. Depending on the IOAM node's architecture
        considerations, the loopback response rate may be limited to a lower
        number in order to avoid overloading the IOAM node.</t>
      </section>
      <section title="Loopback numbered="true" toc="default">
        <name>Loopback on the Return Path"> Path</name>
        <t>On its way back towards the source, the copied packet is processed
        like any other packet with IOAM information, including adding
        requested data at each transit node (assuming there is sufficient
        space).</t>
      </section>
      <section title="Terminating numbered="true" toc="default">
        <name>Terminating a Looped Back Packet"> Looped-Back Packet</name>
        <t>Once the return packet reaches the IOAM domain IOAM-Domain boundary, IOAM
        decapsulation occurs as with any other packet containing IOAM
        information. Note that the looped back looped-back packet does not have the L-bit
        set. The IOAM encapsulating node that initiated the original loopback
        packet recognizes a received packet as an IOAM looped-back packet by
        checking the Node ID in the Hop_Lim/node_id field that corresponds to
        the first hop. If the Node ID and IOAM-Namespace match the current
        IOAM node, it indicates that this is a looped back looped-back packet that was
        initiated by the current IOAM node, node and processed accordingly. If
        there is no match in the Node ID, the packet is processed like a
        conventional IOAM-encapsulated packet.</t>
        <t>Note that an IOAM encapsulating node may either be either an endpoint
        (such as an IPv6 host), host) or a switch/router that pushes a tunnel
        encapsulation onto data packets. In both cases, the functionality that
        was described above avoids IOAM data leaks from the IOAM domain. IOAM-Domain.
        Specifically, if an IOAM looped-back packet reaches an IOAM boundary
        node that is not the IOAM node that initiated the loopback, the node
        does not process the packet as a loopback; the IOAM encapsulation is
        removed, preventing IOAM information from
        leaking out from the IOAM domain, and since IOAM-Domain. Since the packet does not have any payload payload, it is
        terminated.</t>
      </section>
    </section>
    <section anchor="UseCaseSec" title="Active numbered="true" toc="default">
      <name>Active Measurement with IOAM"> IOAM</name>
      <t>Active measurement methods <xref target="RFC7799"/> target="RFC7799" format="default"/> make use of
      synthetically generated packets in order to facilitate measurement. This
      section presents use cases of active measurement using the IOAM Active
      flag.</t>
      <t>The Active flag indicates that a packet is used for active
      measurement. An IOAM decapsulating node that receives a packet with the
      Active flag set in one of its Trace options must terminate the packet.
      The Active flag is intended to simplify the implementation of
      decapsulating nodes by indicating that the packet should not be
      forwarded further. It is not intended as a replacement for existing
      active OAM protocols, which may run in higher layers and make use of the
      Active flag.</t>
      <t>An example of an IOAM deployment scenario is illustrated in <xref
      target="NetworkFig"/>. target="NetworkFig" format="default"/>. The figure depicts two endpoints, endpoints: a source and a
      destination. The data traffic from the source to the destination is
      forwarded through a set of network devices, including an IOAM
      encapsulating node, which node (which incorporates one or more IOAM options, options), a
      decapsulating node, which node (which removes the IOAM options, options), and optionally one or
      more transit nodes. The IOAM options are encapsulated in one of the IOAM
      encapsulation types, e.g., <xref target="I-D.ietf-sfc-ioam-nsh"/>, target="I-D.ietf-sfc-ioam-nsh" format="default"/> or
      <xref target="I-D.ietf-ippm-ioam-ipv6-options"/>.</t> target="I-D.ietf-ippm-ioam-ipv6-options" format="default"/>.</t>
      <figure align="center" anchor="NetworkFig" title="Network using IOAM."> anchor="NetworkFig">
        <name>Network Using IOAM</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[

+--------+     +--------+     +--------+     +--------+     +--------+
|        |     |  IOAM  |.....|  IOAM  |.....|  IOAM  |     |        |
+--------+     +--------+     +--------+     +--------+     +--------+
| L2/L3  |<===>| L2/L3  |<===>| L2/L3  |<===>| L2/L3  |<===>| L2/L3  |
+--------+     +--------+     +--------+     +--------+     +--------+
  Source      Encapsulating    Transit      Decapsulating   Destination
                  Node           Node           Node

               <------------  IOAM domain  IOAM-Domain  ----------->
]]></artwork>
      </figure>
      <t>This document focuses on three possible use cases of active measurement
      using IOAM. These use cases are described using the example of <xref
      target="NetworkFig"/>.</t>

      <t><list style="symbols">
          <t>Endpoint target="NetworkFig" format="default"/>.</t>
<dl newline="true" spacing="normal">
         <dt>Endpoint active measurement: synthetic measurement:</dt> <dd>synthetic probe packets are sent
          between the source and destination, traversing the IOAM domain. IOAM-Domain.
          Since the probe packets are sent between the endpoints, these
          packets are treated as data packets by the IOAM domain, IOAM-Domain and do not
          require special treatment at the IOAM layer. Specifically, the
          Active flag is not used in this case, case and the IOAM layer does not
		  need to
          be aware that an active measurement mechanism is used at a higher
          layer.</t>

          <t>IOAM
          layer.</dd>
        <dt>IOAM active measurement using probe packets within the IOAM
          domain: probe
        IOAM-Domain:</dt> <dd>probe packets are generated and transmitted by the IOAM
        encapsulating node, node and are expected to be terminated by the
        decapsulating node. IOAM data related to probe packets may be exported
        by one or more nodes along its path, path by an exporting protocol that is
        outside the scope of this document (e.g., <xref
          target="I-D.spiegel-ippm-ioam-rawexport"/>).
        target="I-D.spiegel-ippm-ioam-rawexport" format="default"/>). Probe
        packets include a Trace Option which that has its Active flag set,
        indicating that the decapsulating node must terminate them. The
        specification of these probe packets and the processing of these
        packets by the encapsulating and decapsulating nodes is outside the
        scope of this document.</t>

          <t>IOAM document.</dd>
        <dt>IOAM active measurement using replicated data packets: probe packets:</dt> <dd>probe
          packets are created by the encapsulating node by selecting some or
          all of the en route data packets and replicating them. A selected
          data packet, packet and its (possibly truncated) copy is
          forwarded with one or more IOAM options, options while the original packet
          is forwarded normally, normally without IOAM options. To the extent possible,
          the original data packet and its replica are forwarded through the
          same path. The replica includes a Trace Option that has its Active
          flag set, indicating that the decapsulating node should terminate
          it. The current document defines the role of the Active flag in
          allowing the decapsulating node to terminate the packet, but the
          replication functionality and the functionality of the decapsulating
		  node in this context is outside the scope of this document.</t>
        </list></t> document.</dd>
      </dl>
      <t>If the volume of traffic that incorporates the Active flag is large,
      it may overload the network and the IOAM node(s) that process the active
      measurement packet. Thus, the rate of the traffic that includes the
      Active flag SHOULD NOT <bcp14>SHOULD NOT</bcp14> exceed 1/N of the interface capacity on any
      of the IOAM node's interfaces. Using N&gt;100 is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. Depending
      on the IOAM node's architecture considerations, the rate of
      Active-enabled IOAM packets may be limited to a lower number in order to
      avoid overloading the IOAM node.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to allocate has allocated the following bits in the "IOAM Trace
      Flags Registry" Trace-Flags" registry as follows:</t>

      <t><list style="hanging">
          <t hangText="Bit 1">"Loopback" (L-bit)</t>

          <t hangText="Bit 2">"Active" (A-bit)</t>
        </list></t>

	  <t>The "Reference"
      <dl newline="false" spacing="normal">
        <dt>Bit 1</dt>
        <dd>"Loopback" (L-bit)</dd>
        <dt>Bit 2</dt>
        <dd>"Active" (A-bit)</dd>
      </dl>
      <t>This document is specified as the "Reference" in the registry for both bits should
	  be the current document.</t> bits.</t>
      <t>Note that bit 0 is the most significant bit in the Flags
      Registry. "IOAM Trace-Flags"
      registry. This bit was allocated by <xref target="RFC9197"/> target="RFC9197" format="default"/> as the
	  'Overflow' bit.</t>
    </section>
    <section anchor="Performance" title="Performance Considerations"> numbered="true" toc="default">
      <name>Performance Considerations</name>
      <t>Each of the flags that are defined in this document may have
      performance implications. When using the loopback mechanism mechanism, a copy of
      the data packet is sent back to the sender, thus sender (thus, generating more traffic
      than originally sent by the endpoints. endpoints). Using active measurement with the
      Active flag requires the use of synthetic (overhead) traffic.</t>
      <t>Each of the mechanisms that use the flags above has a cost in terms
      of the network bandwidth, bandwidth and may potentially load the node that
      analyzes the data. Therefore, it MUST <bcp14>MUST</bcp14> be possible to use each of the
      mechanisms on a subset of the data traffic; an encapsulating node needs
      to be able to set the Loopback and Active flag selectively, flags selectively in a way
      that considers the effect on the network performance, as further
      discussed in Sections <xref target="SelectSec"/> target="SelectSec"
   format="counter"/> and <xref
      target="UseCaseSec"/>.</t> target="UseCaseSec" format="counter"/>.</t>
      <t>Transit and decapsulating nodes that support Loopback loopback need to be able
      to limit the looped back looped-back packets (<xref target="ReceiveSec"/>) (as discussed in <xref target="ReceiveSec" format="default"/>) so as to
      ensure that the mechanisms are used at a rate that does not
      significantly affect the network bandwidth, bandwidth and does not overload the
      source node in the case of loopback.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of IOAM in general are discussed in <xref
      target="RFC9197"/>. target="RFC9197" format="default"/>. Specifically, an attacker may try to use the
      functionality that is defined in this document to attack the
      network.</t>
      <t>IOAM is assumed to be deployed in a restricted administrative domain,
      thus limiting the scope of the threats above and their effect. This is a
      fundamental assumption with respect to the security aspects of IOAM, IOAM as
      further discussed in <xref target="RFC9197"/>. target="RFC9197" format="default"/>. However, even given this
      limited scope, security threats should still be considered and
      mitigated. Specifically, an attacker may attempt to overload network
      devices by injecting synthetic packets that include an IOAM Trace Option
      with one or more of the flags defined in this document. Similarly, an
      on-path attacker may maliciously set one or more of the flags of transit
      packets.</t>

      <t><list style="symbols">
          <t>Loopback flag: an

<dl newline="true" spacing="normal">
        <dt>Loopback flag:</dt> <dd>an attacker that sets this flag, either in
          synthetic packets or transit packet, packets, can potentially cause an
          amplification,
          amplification since each device along the path creates a copy of
          the data packet and sends it back to the source. The attacker can
          potentially leverage the Loopback flag for a Distributed Denial of
          Service (DDoS) attack, DDoS attack as multiple devices send looped-back copies
          of a packet to a single victim.</t>

          <t>Active flag: the victim.</dd>
        <dt>Active flag:</dt> <dd>the impact of synthetic packets with the Active flag
          is no worse than synthetic data packets in which the Active flag is
          not set. By setting the Active flag in en route packets packets, an attacker
          can prevent these packets from reaching their destination, destination since the
          packet is terminated by the decapsulating device; however, device. However, note that
          an on-path attacker may achieve the same goal by changing the
          destination address of a packet. Another potential threat is
          amplification; if an attacker causes transit switches to replicate
          more packets than they are intended to replicate, either replicate (either by setting
          the Active flag or by sending synthetic packets, packets), then traffic is
          amplified, causing bandwidth degredation. degradation. As mentioned in <xref
          target="UseCaseSec"/>, target="UseCaseSec" format="default"/>, the specification of the replication
          mechanism is not within the scope of this document. A specification
          that defines the replication functionality should also address the
          security aspects of this mechanism.</t>
        </list></t> mechanism.</dd>
      </dl>
      <t>Some of the security threats that were discussed in this document may
      be worse in a wide area network in which there are nested IOAM domains. IOAM-Domains.
      For example, if there are two nested IOAM domains IOAM-Domains that use loopback,
      then a looped-back copy in the outer IOAM domain IOAM-Domain may be forwarded
      through another (inner) IOAM domain IOAM-Domain and may be subject to loopback in
      that (inner) IOAM domain, IOAM-Domain, causing the amplification to be worse than in
      the conventional case.</t>
      <t>In order to mitigate the performance-related attacks described above,
      as described in
      <xref target="Performance"/> target="Performance" format="default"/>, it should be possible for
      IOAM-enabled devices to selectively apply the mechanisms that use the
      flags defined in this document to a subset of the traffic, traffic and to limit
      the performance of synthetically generated packets to a configurable
      rate. Specifically, IOAM nodes should be able to:</t>

      <t><list style="symbols">
          <t>Limit
      <ul spacing="normal">
        <li>Limit the rate of IOAM packets with the Loopback flag (IOAM
          encapsulating nodes), nodes) as discussed in <xref
          target="SelectSec"/>.</t>

          <t>Limit target="SelectSec" format="default"/>.</li>
        <li>Limit the rate of looped back packets (IOAM transit and
          decapsulating nodes), nodes) as discussed in <xref
          target="ReceiveSec"/>.</t>

          <t>Limit target="ReceiveSec" format="default"/>.</li>
        <li>Limit the rate of IOAM packets with the Active flag (IOAM
          encapsulating nodes), nodes) as discussed in <xref
          target="UseCaseSec"/>.</t>
        </list></t> target="UseCaseSec" format="default"/>.</li>
      </ul>
      <t>As defined in <xref target="LoopbackSec"/>, target="LoopbackSec" format="default"/>, transit nodes that
      process a packet with the Loopback flag only add a single data field, field
      and truncate any payload that follows the IOAM option(s), thus
      significanly
      significantly limiting the possible impact of an amplification
      attack.</t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.spiegel-ippm-ioam-rawexport" to="IOAM-RAWEXPORT"/>
<displayreference target="I-D.ietf-ippm-ioam-ipv6-options" to="IOAM-IPV6-OPTIONS"/>
<displayreference target="I-D.ietf-sfc-ioam-nsh" to="IOAM-NSH"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5475.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7014.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml"/>

<!-- draft-spiegel-ippm-ioam-rawexport-06: I-D Exists; expired-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.spiegel-ippm-ioam-rawexport.xml"/>

<reference anchor="I-D.ietf-ippm-ioam-ipv6-options">
<front>
<title>In-situ OAM IPv6 Options</title>
<author fullname="Shwetha Bhandari" role="editor">
<organization>Thoughtspot</organization>
</author>
<author fullname="Frank Brockners" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="October" day="11" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-ioam-ipv6-options-09"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-ipv6-options-09.txt"/>
</reference>

<reference anchor="I-D.ietf-sfc-ioam-nsh">
<front>
<title>
Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data
</title>
<author fullname="Frank Brockners" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Shwetha Bhandari" role="editor">
<organization>Thoughtspot</organization>
</author>
<date month="September" day="30" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sfc-ioam-nsh-11"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-sfc-ioam-nsh-11.txt"/>
</reference>
      </references>
    </references>
<section anchor="Acknowledgments" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors thank Martin Duke, Tommy Pauly, Donald Eastlake, Paul
      Kyzivat, Bernard Aboba, Greg Mirsky, <contact fullname="Martin Duke"/>, <contact
      fullname="Tommy Pauly"/>, <contact fullname="Donald Eastlake"/>,
      <contact fullname="Paul Kyzivat"/>, <contact fullname="Bernard Aboba"/>,
      <contact fullname="Greg Mirsky"/>, and other members of the IPPM working
      group for many helpful comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC8174;

      &RFC9197;
    </references>

    <references title="Informative References">
      &RFC7799;

      &RFC6291;

      &RFC5475;

      &RFC7014;

      &RFC6724;

      &I-D.spiegel-ippm-ioam-rawexport;

      &I-D.ietf-ippm-ioam-ipv6-options;

      &I-D.ietf-sfc-ioam-nsh;
    </references>
    <section numbered="false" title="Contributors" toc="default">
      <name>Contributors</name>
      <t>The Editors would like to recognize the contributions of the
      following individuals to this document.</t>

      <t>
        <figure>
          <artwork><![CDATA[
   Ramesh Sivakolundu
   Cisco

   <contact fullname="Ramesh Sivakolundu">
   <organization>Cisco Systems, Inc.
   170 Inc.</organization>
   <address>
   <postal>
   <street>170 West Tasman Dr.
   SAN JOSE, CA 95134
   U.S.A.

   Email: sramesh@cisco.com

   Carlos Pignataro
   Cisco Dr.</street>
   <city>San Jose</city>
   <region>CA</region><code>95134</code>
   <country>United States of America</country>
   </postal>
   <email>sramesh@cisco.com</email>
   </address>
   </contact>

<contact fullname="Carlos Pignataro">
        <organization>Cisco Systems, Inc.
   7200-11 Inc.</organization>
        <address>
          <postal>
            <street>7200-11 Kit Creek Road
   Research Road</street>
            <city>Research Triangle Park, NC  27709
   United Park</city>
            <region>NC</region><code>27709</code>
            <country>United States

   Email: cpignata@cisco.com

   Aviv Kfir
   Nvidia

   Email: avivk@nvidia.com

   Jennifer Lemon
   Broadcom
   270 of America</country>
          </postal>
          <email>cpignata@cisco.com</email>
        </address>
      </contact>

<contact fullname="Aviv Kfir">
        <organization>Nvidia</organization>
        <address>
          <email>avivk@nvidia.com</email>
        </address>
      </contact>

<contact fullname="Jennifer Lemon">
        <organization>Broadcom</organization>
        <address>
          <postal>
            <street>270 Innovation Drive
   San Jose, CA  95134
   US

   Email: jennifer.lemon@broadcom.com

]]></artwork>
        </figure>
      </t> Drive</street>
            <city>San Jose</city>
            <region>CA</region><code>95134</code>
            <country>United States of America</country>
          </postal>
          <email>jennifer.lemon@broadcom.com</email>
        </address>
      </contact>
    </section>
  </back>
</rfc>