rfc9322xml2.original.xml   rfc9322.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> <!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!-- One method to get references from the online citation libraries. <!ENTITY zwsp "&#8203;">
There has to be one entity for each item to be referenced. <!ENTITY nbhy "&#8209;">
An alternate method (rfc include) is described in the references. --> <!ENTITY wj "&#8288;">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC7799 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7799.xml">
<!ENTITY RFC5475 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5475.xml">
<!ENTITY RFC7014 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7014.xml">
<!ENTITY RFC6291 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6291.xml">
<!ENTITY RFC9197 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9197.xml">
<!ENTITY RFC6724 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6724.xml">
<!ENTITY I-D.spiegel-ippm-ioam-rawexport SYSTEM "http://xml2rfc.tools.ietf.org/p
ublic/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/p
ublic/rfc/bibxml-ids/reference.I-D.ietf-ippm-ioam-ipv6-options.xml">
<!ENTITY AFI SYSTEM "http://www.iana.org/assignments/address-family-numbers/addr
ess-family-numbers.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc strict="yes" ?> std" consensus="true" docName="draft-ietf-ippm-ioam-flags-10" number="9322" ipr=
<?rfc toc="yes"?> "trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="
<?rfc tocdepth="4"?> 4" symRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-ippm-ioam-flags-10" ipr="trust200902">
<front>
<title abbrev="IOAM Flags">In-situ OAM Loopback and Active Flags</title>
<!-- xml2rfc v2v3 conversion 3.14.2 -->
<front>
<title abbrev="IOAM Flags">In Situ Operations, Administration, and Maintenan
ce (IOAM) Loopback and Active Flags</title>
<seriesInfo name="RFC" value="9322"/>
<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi"> <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
<organization abbrev="">Huawei</organization> <organization abbrev="">Huawei</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>tal.mizrahi.phd@gmail.com</email> <email>tal.mizrahi.phd@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Frank Brockners" initials="F." surname="Brockners"> <author fullname="Frank Brockners" initials="F." surname="Brockners">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Hansaallee 249, 3rd Floor</street> <extaddr>3rd Floor</extaddr>
<street>Hansaallee 249</street>
<!-- Reorder these if your country does things differently --> <city>Duesseldorf</city>
<code>40549</code>
<city>DUESSELDORF</city>
<region>NORDRHEIN-WESTFALEN</region>
<code>40549</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>fbrockne@cisco.com</email> <email>fbrockne@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Shwetha Bhandari" initials="S." surname="Bhandari"> <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
<organization abbrev="Thoughtspot">Thoughtspot</organization> <organization abbrev="Thoughtspot">Thoughtspot</organization>
<address> <address>
<postal> <postal>
<street>3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR <extaddr>3rd Floor</extaddr>
Layout</street> <extaddr>Indiqube Orion</extaddr>
<extaddr>Garden Layout</extaddr>
<city>Bangalore, KARNATAKA 560 102</city> <extaddr>HSR Layout</extaddr>
<street>24th Main Rd</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560 102</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>shwetha.bhandari@thoughtspot.com</email> <email>shwetha.bhandari@thoughtspot.com</email>
</address> </address>
</author> </author>
<author fullname="Barak Gafni" initials="B." surname="Gafni"> <author fullname="Barak Gafni" initials="B." surname="Gafni">
<organization abbrev="">Nvidia</organization> <organization abbrev="">Nvidia</organization>
<address> <address>
<postal> <postal>
<street>350 Oakmead Parkway, Suite 100</street> <extaddr>Suite 100</extaddr>
<street>350 Oakmead Parkway</street>
<city>Sunnyvale, CA</city> <city>Sunnyvale</city>
<region>CA</region>
<code>94085</code> <code>94085</code>
<country>United States of America</country>
<country>U.S.A.</country>
</postal> </postal>
<email>gbarak@nvidia.com</email> <email>gbarak@nvidia.com</email>
</address> </address>
</author> </author>
<author fullname="Mickey Spiegel" initials="M." surname="Spiegel"> <author fullname="Mickey Spiegel" initials="M." surname="Spiegel">
<organization abbrev="">Barefoot Networks, an Intel <organization abbrev="Barefoot Networks">Barefoot Networks, an Intel
company</organization> company</organization>
<address> <address>
<postal> <postal>
<street>4750 Patrick Henry Drive</street> <street>4750 Patrick Henry Drive</street>
<city>Santa Clara</city>
<city>Santa Clara, CA</city> <region>CA</region>
<code>95054</code> <code>95054</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>mickey.spiegel@intel.com</email> <email>mickey.spiegel@intel.com</email>
</address> </address>
</author> </author>
<date year="2022" month="November" />
<date year="2022"/>
<area>TSV</area> <area>TSV</area>
<workgroup>IPPM</workgroup> <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>IOAM</keyword>
<keyword>Telemetry</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> <abstract>
<t>In-situ Operations, Administration, and Maintenance (IOAM) collects <t>In situ Operations, Administration, and Maintenance (IOAM) collects
operational and telemetry information in packets while they traverse a operational and telemetry information in packets while they traverse a
path between two points in the network. This document defines two new path between two points in the network. This document defines two new
flags in the IOAM Trace Option headers, specifically the Loopback and flags in the IOAM Trace Option headers, specifically the Loopback and
Active flags.</t> Active flags.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<t>IOAM <xref target="RFC9197"/> is used for monitoring traffic in the <name>Introduction</name>
<t>IOAM <xref target="RFC9197" format="default"/> is used for monitoring t
raffic in the
network by incorporating IOAM data fields into in-flight data network by incorporating IOAM data fields into in-flight data
packets.</t> packets.</t>
<t>IOAM data may be represented in one of four possible IOAM options: <t>IOAM data may be represented in one of four possible IOAM options:
Pre-allocated Trace Option, Incremental Trace Option, Proof of Transit Pre-allocated Trace, Incremental Trace, Proof of Transit
(POT) Option, and Edge-to-Edge Option. This document defines two new (POT), and Edge-to-Edge. This document defines two new
flags in the Pre-allocated and Incremental Trace options: the Loopback flags in the Pre-allocated and Incremental Trace options: the Loopback
and Active flags.</t> and Active flags.</t>
<t>The Loopback flag is used to request that each transit device along <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 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 Active flag indicates that a packet is used for active measurement.
The term active measurement in the context of this document is as The term "active measurement" in the context of this document is as
defined in <xref target="RFC7799"/>.</t> defined in <xref target="RFC7799" format="default"/>.</t>
</section> </section>
<section anchor="Conventions" numbered="true" toc="default">
<section anchor="Conventions" title="Conventions"> <name>Conventions</name>
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Language</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>
"OPTIONAL" in this document are to be interpreted as described in BCP The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
when, they appear in all capitals, as shown here.</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>Abbreviations used in this document:</t> <t>Abbreviations used in this document:</t>
<dl newline="false" spacing="normal" indent="8">
<t><list hangIndent="11" style="hanging"> <dt>IOAM:</dt>
<t hangText="IOAM:">In-situ Operations, Administration, and <dd>In situ Operations, Administration, and
Maintenance</t> Maintenance</dd>
<dt>OAM:</dt>
<t hangText="OAM:">Operations, Administration, and Maintenance <dd>Operations, Administration, and Maintenance
<xref target="RFC6291"/></t> <xref target="RFC6291" format="default"/></dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>New IOAM Trace Option Flags</name>
<t anchor="TraceFlags">This document defines two new
flags in the Pre-allocated and Incremental Trace options: </t>
<section title="New IOAM Trace Option Flags"> <dl newline="false" spacing="normal">
<t anchor="TraceFlags" hangText="Flags">This document defines two new <dt>Bit 1 "Loopback" (L-bit):</dt>
flags in the Pre-allocated and Incremental Trace options: <list <dd>When set, the Loopback flag
style="hanging"> triggers the sending of a copy of a packet back towards the source, as
<t hangText="Bit 1">"Loopback" (L-bit). When set, the Loopback flag further described in <xref target="LoopbackSec" format="default"/>.</d
triggers sending a copy of a packet back towards the source, as d>
further described in <xref target="LoopbackSec"/>.</t> <dt>Bit 2 "Active" (A-bit):</dt>
<dd>When set, the Active flag
<t hangText="Bit 2">"Active" (A-bit). When set, the Active flag
indicates that a packet is an active measurement packet rather than indicates that a packet is an active measurement packet rather than
a data packet, where "active" is used in the sense defined in <xref a data packet, where "active" is used in the sense defined in <xref ta
target="RFC7799"/>. The packet may be an IOAM probe packet, or a rget="RFC7799" format="default"/>. The packet may be an IOAM probe packet or a
replicated data packet (the second and third use cases of <xref replicated data packet (the second and third use cases of <xref target
target="UseCaseSec"/>).</t> ="UseCaseSec" format="default"/>).</dd>
</list></t> </dl>
</section> </section>
<section anchor="LoopbackSec" numbered="true" toc="default">
<section anchor="LoopbackSec" title="Loopback in IOAM"> <name>Loopback in IOAM</name>
<t>The Loopback flag is used to request that each transit device along <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 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 Loopback allows an IOAM encapsulating node to trace the path to a given
destination, and to receive per-hop data about both the forward and the destination and to receive per-hop data about both the forward and return
return path. Loopback is intended to provide an accelerated alternative paths. Loopback is intended to provide an accelerated alternative to
to Traceroute, that allows the encapsulating node to receive responses Traceroute that allows the encapsulating node to receive responses from
from multiple transit nodes along the path in less then one multiple transit nodes along the path in less than one round-trip time (RT
round-trip-time, and by sending a single packet.</t> T)
and by sending a single packet.</t>
<t>As illustrated in <xref target="LoopbackFig"/>, an IOAM encapsulating <t>As illustrated in <xref target="LoopbackFig" format="default"/>, an IOA
M encapsulating
node can push an IOAM encapsulation that includes the Loopback flag onto node can push an IOAM encapsulation that includes the Loopback flag onto
some or all of the packets it forwards, using one of the IOAM some or all of the packets it forwards using one of the IOAM
encapsulation types, e.g., <xref target="I-D.ietf-sfc-ioam-nsh"/>, or encapsulation types, e.g., <xref target="I-D.ietf-sfc-ioam-nsh" format="de
<xref target="I-D.ietf-ippm-ioam-ipv6-options"/>. fault"/> or
<xref target="I-D.ietf-ippm-ioam-ipv6-options" format="default"/>.
The IOAM transit node and the The IOAM transit node and the
decapsulating node both creates copies of the packet and loop them back decapsulating node both create copies of the packet and loop them back
to the encapsulating node. The decapsulating node also terminates the to the encapsulating node. The decapsulating node also terminates the
IOAM encapsulation, and then forwards the packet towards the IOAM encapsulation and then forwards the packet towards the
destination. The two IOAM looped back copies are terminated by the destination. The two IOAM looped-back copies are terminated by the
encapsulating node.</t> encapsulating node.</t>
<figure anchor="LoopbackFig">
<figure align="center" anchor="LoopbackFig" title="Loopback in IOAM."> <name>Loopback in IOAM</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+ +--------+
+--------+ +--------+ +--------+ +--------+ +--------+ | | | IOAM |.....| IOAM |.....| IOAM | | |
| | | IOAM |.....| IOAM |.....| IOAM | | | +--------+ +--------+ +--------+ +--------+ +--------+
+--------+ +--------+ +--------+ +--------+ +--------+ | L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |
| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 | +--------+ +--------+ +--------+ +--------+ +--------+
+--------+ +--------+ +--------+ +--------+ +--------+ Source Encapsulating Transit Decapsulating Destination
Source Encapsulating Transit Decapsulating Destination
Node Node Node Node Node Node
<------------ IOAM domain -----------> <------------ IOAM-Domain ----------->
IOAM encap. with Loopback flag IOAM encap. with Loopback flag
Data packet ------->============================>-----------> Data packet ------->============================>----------->
| | | |
IOAM looped back | | IOAM looped back | |
<=============+ | <=============+ |
IOAM looped back| IOAM looped back|
<===========================+ <===========================+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Loopback can be used only if a return path from transit nodes and <t>Loopback can be used only if a return path from transit nodes and
destination nodes towards the source (encapsulating node) exists. destination nodes towards the source (encapsulating node) exists.
Specifically, loopback is only applicable in encapsulations in which the Specifically, loopback is only applicable in encapsulations in which the
identity of the encapsulating node is available in the encapsulation identity of the encapsulating node is available in the encapsulation
header. If an encapsulating node receives a looped back packet that was header. If an encapsulating node receives a looped-back packet that was
not originated from the current encapsulating node, the packet is not originated from the current encapsulating node, the packet is
dropped.</t> dropped.</t>
<section numbered="true" toc="default">
<section title="Loopback: Encapsulating Node Functionality"> <name>Loopback: Encapsulating Node Functionality</name>
<t>The encapsulating node either generates synthetic packets with an <t>The encapsulating node either generates synthetic packets with an
IOAM trace option that has the Loopback flag set, or sets the loopack IOAM trace option that has the Loopback flag set or sets the Loopback
flag in a subset of the in-transit data packets. Loopback is used 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 either proactively or on-demand, i.e., when a failure is detected. The
encapsulating node also needs to ensure that sufficient space is encapsulating node also needs to ensure that sufficient space is
available in the IOAM header for loopback operation, which includes available in the IOAM header for loopback operation, which includes
transit nodes adding trace data on the original path and then again on transit nodes adding trace data on the original path and again on
the return path.</t> the return path.</t>
<t>An IOAM trace option that has the Loopback flag set <bcp14>MUST</bcp1
<t>An IOAM trace option that has the Loopback flag set MUST have the 4> have the
value '1' in the most significant bit of IOAM-Trace-Type, and '0' in value '1' in the most significant bit of IOAM-Trace-Type and '0' in
the rest of the bits of IOAM-Trace-Type. Thus, every transit node that 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 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 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 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 the IOAM-Trace-Type is not equal to '1' in the most significant bit
and '0' in the rest of the bits, MUST NOT loop back a copy of the and '0' in the rest of the 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 packet. The reason for allowing only a single data field per hop is to
minimize the impact of amplification attacks.</t> minimize the impact of amplification attacks.</t>
<t>IOAM encapsulating nodes <bcp14>MUST NOT</bcp14> push an IOAM encapsu
<t>IOAM encapsulating nodes MUST NOT push an IOAM encapsulation with lation with
the Loopback flag onto data packets that already include an IOAM the Loopback flag onto data packets that already include an IOAM
encapsulation. This requirement is intended to prevent IOAM Loopback encapsulation. This requirement is intended to prevent IOAM Loopback
nesting, where looped back packets may be subject to loopback in a nesting where looped-back packets may be subject to loopback in a
nested IOAM domain.</t> nested IOAM-Domain.</t>
<section anchor="SelectSec" numbered="true" toc="default">
<section anchor="SelectSec" title="Loopback Packet Selection"> <name>Loopback Packet Selection</name>
<t>If an IOAM encapsulating node incorporates the Loopback flag into <t>If an IOAM encapsulating node incorporates the Loopback flag into
all the traffic it forwards it may lead to an excessive amount of all the traffic it forwards, it may lead to an excessive amount of
looped back packets, which may overload the network and the looped back packets, which may overload the network and the
encapsulating node. Therefore, an IOAM encapsulating node that encapsulating node. Therefore, an IOAM encapsulating node that
supports the Loopback flag MUST support the ability to incorporate supports the Loopback flag <bcp14>MUST</bcp14> support the ability to incorporate
the Loopback flag selectively into a subset of the packets that are the Loopback flag selectively into a subset of the packets that are
forwarded by it.</t> forwarded by it.</t>
<t>Various methods of packet selection and sampling have been <t>Various methods of packet selection and sampling have been
previously defined, such as <xref target="RFC7014"/> and <xref previously defined, such as <xref target="RFC7014" format="default"/>
target="RFC5475"/>. Similar techniques can be applied by an IOAM and <xref target="RFC5475" format="default"/>.
encapsulating node to apply Loopback to a subset of the forwarded Similar techniques can be applied by an IOAM
encapsulating node to apply loopback to a subset of the forwarded
traffic.</t> traffic.</t>
<t>The subset of traffic that is forwarded or transmitted with a <t>The subset of traffic that is forwarded or transmitted with a
Loopback flag SHOULD NOT exceed 1/N of the interface capacity on any Loopback flag <bcp14>SHOULD NOT</bcp14> exceed 1/N of the interface ca pacity on any
of the IOAM encapsulating node's interfaces. This requirement of the IOAM encapsulating node's interfaces. This requirement
applies to the total traffic that incorporates a Loopback flag, applies to the total traffic that incorporates a Loopback flag,
including traffic that is forwarded by the IOAM encapsulating node including traffic that is forwarded by the IOAM encapsulating node
and probe packets that are generated by the IOAM encapsulating node. and probe packets that are generated by the IOAM encapsulating node.
In this context N is a parameter that can be configurable by network In this context, N is a parameter that can be configurable by network
operators. If there is an upper bound, M, on the number of IOAM 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 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. N &gt;&gt; M (i.e., N is much greater than M) is <bcp14>RECOMMENDED</b cp14>.
The rationale is that a packet that The rationale is that a packet that
includes the Loopback flag triggers a looped back packet from each includes the Loopback flag triggers a looped-back packet from each
IOAM transit node along the path for a total of M looped back IOAM transit node along the path for a total of M looped-back
packets. Thus, if N &gt;&gt; M then the number of looped back packets. Thus, if N &gt;&gt; M, then the number of looped-back
packets is significantly lower than the number of data packets packets is significantly lower than the number of data packets
forwarded by the IOAM encapsulating node. It is RECOMMENDED forwarded by the IOAM encapsulating node. It is <bcp14>RECOMMENDED</bc
that the default value of N satisfies N&gt;100, to be used p14>
that the default value of N satisfies N&gt;100 to be used
in the absence of explicit operator configuration or in the absence of explicit operator configuration or
if there is no prior knowledge about the network topology or si ze.</t> if there is no prior knowledge about the network topology or si ze.</t>
<t>An IOAM-Domain in which the Loopback flag is used <bcp14>MUST</bcp1
<t>An IOAM domain in which the Loopback flag is used MUST be 4> be
configured such that there is expected to be a return path from each configured such that there is expected to be a return path from each
of the IOAM transit and IOAM decapsulating nodes; if this expec tation of the IOAM transit and IOAM decapsulating nodes; if this expec tation
does not apply, or if the encapsulating node's identity is not does not apply, or if the encapsulating node's identity is not
available in the encapsulation header, then configuration MUST NOT available in the encapsulation header, then configuration <bcp14>MUST NOT</bcp14>
enable the Loopback flag to be set.</t> enable the Loopback flag to be set.</t>
</section> </section>
</section> </section>
<section anchor="ReceiveSec" numbered="true" toc="default">
<section anchor="ReceiveSec" title="Receiving and Processing Loopback"> <name>Receiving and Processing Loopback</name>
<t>A Loopback flag that is set indicates to the transit nodes <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 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 packet and send the copy back to the source of the packet. In this
context the source is the IOAM encapsulating node, and it is assumed context, the source is the IOAM encapsulating node and it is assumed
that the source address is available in the encapsulation header. that the source address is available in the encapsulation header.
Thus, the source address of the original packet is used as the Thus, the source address of the original packet is used as the
destination address in the copied packet. If IOAM is used over an destination address in the copied packet. If IOAM is used over an
encapsulation that does not include the address of the encapsulat ing encapsulation that does not include the address of the encapsulat ing
node, then node, then
the transit/decapsulating node does not loop back a copy of the the transit/decapsulating node does not loop back a copy of the
original packet. The address of the node performing the copy operation original packet. The address of the node performing the copy operation
is used as the source address; the specific method of source address is used as the source address; the specific method of source address
assignment is encapsulation specific, e.g., if an IPv6 assignment is encapsulation specific, e.g., if an IPv6
encapsulation is used, then the source address can be assigned as encapsulation is used, then the source address can be assigned as
specified in <xref target="RFC6724"/>. specified in <xref target="RFC6724" format="default"/>.
The copy is also truncated, i.e., any The copy is also truncated, i.e., any
payload that resides after the IOAM option(s) is removed before payload that resides after the IOAM option(s) is removed before
transmitting the looped back packet back towards the encapsulating transmitting the looped-back packet back towards the encapsulating
node. Creating the copy that is looped back, and specifically the node. Creating the copy that is looped back, and specifically the
truncation, may require some encapsulation-specific updates truncation, may require some encapsulation-specific updates
in the encapsulation header. in the encapsulation header.
The original packet continues towards its destination. The L-bit The original packet continues towards its destination. The L-bit
MUST be cleared in the copy of the packet that a node sends back <bcp14>MUST</bcp14> be cleared in the copy of the packet that a node sen ds back
towards the source.</t> towards the source.</t>
<t>An IOAM node that supports the reception and processing of the <t>An IOAM node that supports the reception and processing of the
Loopback flag MUST support the ability to limit the rate of the looped Loopback flag <bcp14>MUST</bcp14> support the ability to limit the
back packets. The rate of looped back packets SHOULD be limited so rate of the looped-back packets. The rate of looped-back packets
that the number of looped back packets is significantly lower than the <bcp14>SHOULD</bcp14> be limited so that the number of looped-back
number of packets that are forwarded by the device. The looped back packets is significantly lower than the number of packets that are
data rate SHOULD NOT exceed 1/N of the interface capacity on any of forwarded by the device. The looped-back data rate <bcp14>SHOULD
the IOAM node's interfaces. Using N&gt;100 is RECOMMENDED. Depending NOT</bcp14> exceed 1/N of the interface capacity on any of the IOAM
on the IOAM node's architecture considerations, the loopback response node's interfaces. Using N&gt;100 is
rate may be limited to a lower number in order to avoid overloading <bcp14>RECOMMENDED</bcp14>. Depending on the IOAM node's architecture
the IOAM node.</t> considerations, the loopback response rate may be limited to a lower
number in order to avoid overloading the IOAM node.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Loopback on the Return Path"> <name>Loopback on the Return Path</name>
<t>On its way back towards the source, the copied packet is processed <t>On its way back towards the source, the copied packet is processed
like any other packet with IOAM information, including adding like any other packet with IOAM information, including adding
requested data at each transit node (assuming there is sufficient requested data at each transit node (assuming there is sufficient
space).</t> space).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminating a Looped Back Packet"> <name>Terminating a Looped-Back Packet</name>
<t>Once the return packet reaches the IOAM domain boundary, IOAM <t>Once the return packet reaches the IOAM-Domain boundary, IOAM
decapsulation occurs as with any other packet containing IOAM decapsulation occurs as with any other packet containing IOAM
information. Note that the looped back packet does not have the L-bit information. Note that the looped-back packet does not have the L-bit
set. The IOAM encapsulating node that initiated the original loopback set. The IOAM encapsulating node that initiated the original loopback
packet recognizes a received packet as an IOAM looped-back packet by 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 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 the first hop. If the Node ID and IOAM-Namespace match the current
IOAM node, it indicates that this is a looped back packet that was IOAM node, it indicates that this is a looped-back packet that was
initiated by the current IOAM node, and processed accordingly. If initiated by the current IOAM node and processed accordingly. If
there is no match in the Node ID, the packet is processed like a there is no match in the Node ID, the packet is processed like a
conventional IOAM-encapsulated packet.</t> conventional IOAM-encapsulated packet.</t>
<t>Note that an IOAM encapsulating node may be either an endpoint
<t>Note that an IOAM encapsulating node may either be an endpoint (such as an IPv6 host) or a switch/router that pushes a tunnel
(such as an IPv6 host), or a switch/router that pushes a tunnel
encapsulation onto data packets. In both cases, the functionality that encapsulation onto data packets. In both cases, the functionality that
was described above avoids IOAM data leaks from the IOAM domain. was described above avoids IOAM data leaks from the IOAM-Domain.
Specifically, if an IOAM looped-back packet reaches an IOAM boundary Specifically, if an IOAM looped-back packet reaches an IOAM boundary
node that is not the IOAM node that initiated the loopback, the node 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 does not process the packet as a loopback; the IOAM encapsulation is
removed, preventing IOAM information from removed, preventing IOAM information from
leaking out from the IOAM domain, and since the packet does not have any payload it is leaking out from the IOAM-Domain. Since the packet does not have any pay load, it is
terminated.</t> terminated.</t>
</section> </section>
</section> </section>
<section anchor="UseCaseSec" numbered="true" toc="default">
<section anchor="UseCaseSec" title="Active Measurement with IOAM"> <name>Active Measurement with IOAM</name>
<t>Active measurement methods <xref target="RFC7799"/> make use of <t>Active measurement methods <xref target="RFC7799" format="default"/> ma
ke use of
synthetically generated packets in order to facilitate measurement. This synthetically generated packets in order to facilitate measurement. This
section presents use cases of active measurement using the IOAM Active section presents use cases of active measurement using the IOAM Active
flag.</t> flag.</t>
<t>The Active flag indicates that a packet is used for active <t>The Active flag indicates that a packet is used for active
measurement. An IOAM decapsulating node that receives a packet with the measurement. An IOAM decapsulating node that receives a packet with the
Active flag set in one of its Trace options must terminate the packet. Active flag set in one of its Trace options must terminate the packet.
The Active flag is intended to simplify the implementation of The Active flag is intended to simplify the implementation of
decapsulating nodes by indicating that the packet should not be decapsulating nodes by indicating that the packet should not be
forwarded further. It is not intended as a replacement for existing 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 OAM protocols, which may run in higher layers and make use of the
Active flag.</t> Active flag.</t>
<t>An example of an IOAM deployment scenario is illustrated in <xref targe
<t>An example of an IOAM deployment scenario is illustrated in <xref t="NetworkFig" format="default"/>. The figure depicts two endpoints: a source an
target="NetworkFig"/>. The figure depicts two endpoints, a source and a d a
destination. The data traffic from the source to the destination is destination. The data traffic from the source to the destination is
forwarded through a set of network devices, including an IOAM forwarded through a set of network devices, including an IOAM
encapsulating node, which incorporates one or more IOAM options, a encapsulating node (which incorporates one or more IOAM options), a
decapsulating node, which removes the IOAM options, optionally one or decapsulating node (which removes the IOAM options), and optionally one or
more transit nodes. The IOAM options are encapsulated in one of the IOAM 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"/>, or encapsulation types, e.g., <xref target="I-D.ietf-sfc-ioam-nsh" format="de
<xref target="I-D.ietf-ippm-ioam-ipv6-options"/>.</t> fault"/> or
<xref target="I-D.ietf-ippm-ioam-ipv6-options" format="default"/>.</t>
<figure align="center" anchor="NetworkFig" title="Network using IOAM."> <figure anchor="NetworkFig">
<artwork align="left"><![CDATA[ <name>Network Using IOAM</name>
<artwork 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 |.....| IOAM |.....| IOAM | | |
+--------+ +--------+ +--------+ +--------+ +--------+
| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |<===>| L2/L3 |
+--------+ +--------+ +--------+ +--------+ +--------+
Source Encapsulating Transit Decapsulating Destination
Node Node Node
]]></artwork> <------------ IOAM-Domain ----------->
]]></artwork>
</figure> </figure>
<t>This document focuses on three possible use cases of active measurement <t>This document focuses on three possible use cases of active measurement
using IOAM. These use cases are described using the example of <xref using IOAM. These use cases are described using the example of <xref targe
target="NetworkFig"/>.</t> t="NetworkFig" format="default"/>.</t>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>Endpoint active measurement:</dt> <dd>synthetic probe packets are s
<t>Endpoint active measurement: synthetic probe packets are sent ent
between the source and destination, traversing the IOAM domain. between the source and destination, traversing the IOAM-Domain.
Since the probe packets are sent between the endpoints, these Since the probe packets are sent between the endpoints, these
packets are treated as data packets by the IOAM domain, and do not packets are treated as data packets by the IOAM-Domain and do not
require special treatment at the IOAM layer. Specifically, the require special treatment at the IOAM layer. Specifically, the
Active flag is not used in this case, and the IOAM layer does not Active flag is not used in this case and the IOAM layer does not
need to need to
be aware that an active measurement mechanism is used at a higher be aware that an active measurement mechanism is used at a higher
layer.</t> layer.</dd>
<dt>IOAM active measurement using probe packets within the
<t>IOAM active measurement using probe packets within the IOAM IOAM-Domain:</dt> <dd>probe packets are generated and transmitted by the
domain: probe packets are generated and transmitted by the IOAM IOAM
encapsulating node, and are expected to be terminated by the encapsulating node and are expected to be terminated by the
decapsulating node. IOAM data related to probe packets may be decapsulating node. IOAM data related to probe packets may be exported
exported by one or more nodes along its path, by an exporting by one or more nodes along its path by an exporting protocol that is
protocol that is outside the scope of this document (e.g., <xref outside the scope of this document (e.g., <xref
target="I-D.spiegel-ippm-ioam-rawexport"/>). Probe packets include a target="I-D.spiegel-ippm-ioam-rawexport" format="default"/>). Probe
Trace Option which has its Active flag set, indicating that the packets include a Trace Option that has its Active flag set,
decapsulating node must terminate them. The specification of indicating that the decapsulating node must terminate them. The
these probe packets and the processing of these packets by the specification of these probe packets and the processing of these
encapsulating and decapsulating nodes is outside the scope of packets by the encapsulating and decapsulating nodes is outside the
this document.</t> scope of this document.</dd>
<dt>IOAM active measurement using replicated data packets:</dt> <dd>prob
<t>IOAM active measurement using replicated data packets: probe e
packets are created by the encapsulating node by selecting some or packets are created by the encapsulating node by selecting some or
all of the en route data packets and replicating them. A selected all of the en route data packets and replicating them. A selected
data packet, and its (possibly truncated) copy is data packet and its (possibly truncated) copy is
forwarded with one or more IOAM options, while the original packet forwarded with one or more IOAM options while the original packet
is forwarded normally, without IOAM options. To the extent possible, is forwarded normally without IOAM options. To the extent possible,
the original data packet and its replica are forwarded through the the original data packet and its replica are forwarded through the
same path. The replica includes a Trace Option that has its Active same path. The replica includes a Trace Option that has its Active
flag set, indicating that the decapsulating node should terminate flag set, indicating that the decapsulating node should terminate
it. The current document defines the role of the Active flag in it. The current document defines the role of the Active flag in
allowing the decapsulating node to terminate the packet, but the allowing the decapsulating node to terminate the packet, but the
replication functionality and the functionality of the decapsulating replication functionality and the functionality of the decapsulating
node in this context is outside the scope of this document.</t> node in this context is outside the scope of this document.</dd
</list></t> >
</dl>
<t>If the volume of traffic that incorporates the Active flag is large, <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 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 measurement packet. Thus, the rate of the traffic that includes the
Active flag SHOULD NOT exceed 1/N of the interface capacity on any Active flag <bcp14>SHOULD NOT</bcp14> exceed 1/N of the interface capacity
of the IOAM node's interfaces. Using N&gt;100 is RECOMMENDED. Depending on any
of the IOAM node's interfaces. Using N&gt;100 is <bcp14>RECOMMENDED</bcp14
>. Depending
on the IOAM node's architecture considerations, the rate of on the IOAM node's architecture considerations, the rate of
Active-enabled IOAM packets may be limited to a lower number in order to Active-enabled IOAM packets may be limited to a lower number in order to
avoid overloading the IOAM node.</t> avoid overloading the IOAM node.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA is requested to allocate the following bits in the "IOAM Trace <t>IANA has allocated the following bits in the "IOAM Trace-Flags" registr
Flags Registry" as follows:</t> y as follows:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Bit 1</dt>
<t hangText="Bit 1">"Loopback" (L-bit)</t> <dd>"Loopback" (L-bit)</dd>
<dt>Bit 2</dt>
<t hangText="Bit 2">"Active" (A-bit)</t> <dd>"Active" (A-bit)</dd>
</list></t> </dl>
<t>This document is specified as the "Reference" in the registry for both
<t>The "Reference" specified in the registry for both bits should bits.</t>
be the current document.</t> <t>Note that bit 0 is the most significant bit in the "IOAM Trace-Flags"
registry. This bit was allocated by <xref target="RFC9197" format="default
<t>Note that bit 0 is the most significant bit in the Flags "/> as the
Registry. This bit was allocated by <xref target="RFC9197"/> as the
'Overflow' bit.</t> 'Overflow' bit.</t>
</section> </section>
<section anchor="Performance" numbered="true" toc="default">
<section anchor="Performance" title="Performance Considerations"> <name>Performance Considerations</name>
<t>Each of the flags that are defined in this document may have <t>Each of the flags that are defined in this document may have
performance implications. When using the loopback mechanism a copy of performance implications. When using the loopback mechanism, a copy of
the data packet is sent back to the sender, thus generating more traffic the data packet is sent back to the sender (thus, generating more traffic
than originally sent by the endpoints. Using active measurement with the than originally sent by the endpoints). Using active measurement with the
Active flag requires the use of synthetic (overhead) traffic.</t> 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 <t>Each of the mechanisms that use the flags above has a cost in terms
of the network bandwidth, and may potentially load the node that of the network bandwidth and may potentially load the node that
analyzes the data. Therefore, it MUST be possible to use each of the analyzes the data. Therefore, it <bcp14>MUST</bcp14> be possible to use ea
ch of the
mechanisms on a subset of the data traffic; an encapsulating node needs mechanisms on a subset of the data traffic; an encapsulating node needs
to be able to set the Loopback and Active flag selectively, in a way to be able to set the Loopback and Active flags selectively in a way
that considers the effect on the network performance, as further that considers the effect on the network performance, as further
discussed in <xref target="SelectSec"/> and <xref discussed in Sections <xref target="SelectSec"
target="UseCaseSec"/>.</t> format="counter"/> and <xref target="UseCaseSec" format="counter"/>.</t>
<t>Transit and decapsulating nodes that support loopback need to be able
<t>Transit and decapsulating nodes that support Loopback need to be able to limit the looped-back packets (as discussed in <xref target="ReceiveSec
to limit the looped back packets (<xref target="ReceiveSec"/>) so as to " format="default"/>) so as to
ensure that the mechanisms are used at a rate that does not ensure that the mechanisms are used at a rate that does not
significantly affect the network bandwidth, and does not overload the significantly affect the network bandwidth and does not overload the
source node in the case of loopback.</t> source node in the case of loopback.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations of IOAM in general are discussed in <xref <t>The security considerations of IOAM in general are discussed in <xref t
target="RFC9197"/>. Specifically, an attacker may try to use the arget="RFC9197" format="default"/>. Specifically, an attacker may try to use the
functionality that is defined in this document to attack the functionality that is defined in this document to attack the
network.</t> network.</t>
<t>IOAM is assumed to be deployed in a restricted administrative domain, <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 thus limiting the scope of the threats above and their effect. This is a
fundamental assumption with respect to the security aspects of IOAM, as fundamental assumption with respect to the security aspects of IOAM as
further discussed in <xref target="RFC9197"/>. However, even given this further discussed in <xref target="RFC9197" format="default"/>. However, e
ven given this
limited scope, security threats should still be considered and limited scope, security threats should still be considered and
mitigated. Specifically, an attacker may attempt to overload network mitigated. Specifically, an attacker may attempt to overload network
devices by injecting synthetic packets that include an IOAM Trace Option devices by injecting synthetic packets that include an IOAM Trace Option
with one or more of the flags defined in this document. Similarly, an 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 on-path attacker may maliciously set one or more of the flags of transit
packets.</t> packets.</t>
<t><list style="symbols"> <dl newline="true" spacing="normal">
<t>Loopback flag: an attacker that sets this flag, either in <dt>Loopback flag:</dt> <dd>an attacker that sets this flag, either in
synthetic packets or transit packet, can potentially cause an synthetic packets or transit packets, can potentially cause an
amplification, since each device along the path creates a copy of amplification since each device along the path creates a copy of
the data packet and sends it back to the source. The attacker can the data packet and sends it back to the source. The attacker can
potentially leverage the Loopback flag for a Distributed Denial of potentially leverage the Loopback flag for a DDoS attack as multiple d
Service (DDoS) attack, as multiple devices send looped-back copies evices send looped-back copies
of a packet to a single victim.</t> of a packet to a single victim.</dd>
<dt>Active flag:</dt> <dd>the impact of synthetic packets with the Activ
<t>Active flag: the impact of synthetic packets with the Active flag e flag
is no worse than synthetic data packets in which the Active flag is is no worse than synthetic data packets in which the Active flag is
not set. By setting the Active flag in en route packets an attacker not set. By setting the Active flag in en route packets, an attacker
can prevent these packets from reaching their destination, since the can prevent these packets from reaching their destination since the
packet is terminated by the decapsulating device; however, note that packet is terminated by the decapsulating device. However, note that
an on-path attacker may achieve the same goal by changing the an on-path attacker may achieve the same goal by changing the
destination address of a packet. Another potential threat is destination address of a packet. Another potential threat is
amplification; if an attacker causes transit switches to replicate amplification; if an attacker causes transit switches to replicate
more packets than they are intended to replicate, either by setting more packets than they are intended to replicate (either by setting
the Active flag or by sending synthetic packets, then traffic is the Active flag or by sending synthetic packets), then traffic is
amplified, causing bandwidth degredation. As mentioned in <xref amplified, causing bandwidth degradation. As mentioned in <xref target
target="UseCaseSec"/>, the specification of the replication ="UseCaseSec" format="default"/>, the specification of the replication
mechanism is not within the scope of this document. A specification mechanism is not within the scope of this document. A specification
that defines the replication functionality should also address the that defines the replication functionality should also address the
security aspects of this mechanism.</t> security aspects of this mechanism.</dd>
</list></t> </dl>
<t>Some of the security threats that were discussed in this document may <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. be worse in a wide area network in which there are nested IOAM-Domains.
For example, if there are two nested IOAM domains that use loopback, For example, if there are two nested IOAM-Domains that use loopback,
then a looped-back copy in the outer IOAM domain may be forwarded then a looped-back copy in the outer IOAM-Domain may be forwarded
through another (inner) IOAM domain and may be subject to loopback in through another (inner) IOAM-Domain and may be subject to loopback in
that (inner) IOAM domain, causing the amplification to be worse than in that (inner) IOAM-Domain, causing the amplification to be worse than in
the conventional case.</t> the conventional case.</t>
<t>In order to mitigate the performance-related attacks described in
<t>In order to mitigate the performance-related attacks described above, <xref target="Performance" format="default"/>, it should be possible for
as described in <xref target="Performance"/> it should be possible for
IOAM-enabled devices to selectively apply the mechanisms that use the IOAM-enabled devices to selectively apply the mechanisms that use the
flags defined in this document to a subset of the traffic, and to limit flags defined in this document to a subset of the traffic and to limit
the performance of synthetically generated packets to a configurable the performance of synthetically generated packets to a configurable
rate. Specifically, IOAM nodes should be able to:</t> rate. Specifically, IOAM nodes should be able to:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Limit the rate of IOAM packets with the Loopback flag (IOAM
<t>Limit the rate of IOAM packets with the Loopback flag (IOAM encapsulating nodes) as discussed in <xref target="SelectSec" format="
encapsulating nodes), as discussed in <xref default"/>.</li>
target="SelectSec"/>.</t> <li>Limit the rate of looped back packets (IOAM transit and
decapsulating nodes) as discussed in <xref target="ReceiveSec" format=
<t>Limit the rate of looped back packets (IOAM transit and "default"/>.</li>
decapsulating nodes), as discussed in <xref <li>Limit the rate of IOAM packets with the Active flag (IOAM
target="ReceiveSec"/>.</t> encapsulating nodes) as discussed in <xref target="UseCaseSec" format=
"default"/>.</li>
<t>Limit the rate of IOAM packets with the Active flag (IOAM </ul>
encapsulating nodes), as discussed in <xref <t>As defined in <xref target="LoopbackSec" format="default"/>, transit no
target="UseCaseSec"/>.</t> des that
</list></t> process a packet with the Loopback flag only add a single data field
<t>As defined in <xref target="LoopbackSec"/>, transit nodes that
process a packet with the Loopback flag only add a single data field,
and truncate any payload that follows the IOAM option(s), thus and truncate any payload that follows the IOAM option(s), thus
significanly limiting the possible impact of an amplification significantly limiting the possible impact of an amplification
attack.</t> attack.</t>
</section> </section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>The authors thank Martin Duke, Tommy Pauly, Donald Eastlake, Paul
Kyzivat, Bernard Aboba, Greg Mirsky, and other members of the IPPM
working group for many helpful comments.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
&RFC2119;
&RFC8174;
&RFC9197; <displayreference target="I-D.spiegel-ippm-ioam-rawexport" to="IOAM-RAWEXPORT"/>
</references> <displayreference target="I-D.ietf-ippm-ioam-ipv6-options" to="IOAM-IPV6-OPTIONS
"/>
<references title="Informative References"> <displayreference target="I-D.ietf-sfc-ioam-nsh" to="IOAM-NSH"/>
&RFC7799;
&RFC6291;
&RFC5475;
&RFC7014;
&RFC6724; <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
197.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
799.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
291.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
475.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
014.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
724.xml"/>
&I-D.spiegel-ippm-ioam-rawexport; <!-- 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"/>
&I-D.ietf-ippm-ioam-ipv6-options; <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>
&I-D.ietf-sfc-ioam-nsh; <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-n
sh-11.txt"/>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<section numbered="false" title="Contributors" toc="default"> <name>Acknowledgments</name>
<t>The authors thank <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>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>The Editors would like to recognize the contributions of the <t>The Editors would like to recognize the contributions of the
following individuals to this document.</t> following individuals to this document.</t>
<t> <contact fullname="Ramesh Sivakolundu">
<figure> <organization>Cisco Systems, Inc.</organization>
<artwork><![CDATA[ <address>
Ramesh Sivakolundu <postal>
Cisco Systems, Inc. <street>170 West Tasman Dr.</street>
170 West Tasman Dr. <city>San Jose</city>
SAN JOSE, CA 95134 <region>CA</region><code>95134</code>
U.S.A. <country>United States of America</country>
</postal>
Email: sramesh@cisco.com <email>sramesh@cisco.com</email>
</address>
Carlos Pignataro </contact>
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: cpignata@cisco.com
Aviv Kfir
Nvidia
Email: avivk@nvidia.com
Jennifer Lemon <contact fullname="Carlos Pignataro">
Broadcom <organization>Cisco Systems, Inc.</organization>
270 Innovation Drive <address>
San Jose, CA 95134 <postal>
US <street>7200-11 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region><code>27709</code>
<country>United States of America</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</contact>
Email: jennifer.lemon@broadcom.com <contact fullname="Aviv Kfir">
<organization>Nvidia</organization>
<address>
<email>avivk@nvidia.com</email>
</address>
</contact>
]]></artwork> <contact fullname="Jennifer Lemon">
</figure> <organization>Broadcom</organization>
</t> <address>
<postal>
<street>270 Innovation 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> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 137 change blocks. 
446 lines changed or deleted 436 lines changed or added

This html diff was produced by rfcdiff 1.48.