<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site.
     The next line defines an entity named RFC2629, which contains the necessary XML
     for the reference element, and is used much later in the file.  This XML contains an
     anchor (also RFC2629) which can be used to cross-reference this item in the text.
     You can also use local file names instead of a URI.  The environment variable
     XML_LIBRARY provides a search path of directories to look at to locate a
     relative path name for the file. There has to be one entity for each item to be
     referenced. -->
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
  <!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml"> nbsp    "&#160;">
  <!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml"> zwsp   "&#8203;">
  <!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!-- There is also a library of current Internet Draft citations.  It isn't a good idea to
     actually use one for the template because it might have disappeared when you come to test
     this template.  This is the form of the entity definition
     &lt;!ENTITY I-D.mrose-writing-rfcs SYSTEM
     "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfcs.xml">
     corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The citation will be
     to the most recent draft in the sequence, and is updated roughly hourly on the web site.
     For working group drafts, the same principle applies: file name starts draft-ietf-wgname-..
     and entity file is reference.I-D.ietf-wgname-...  The corresponding entity name is
     I-D.ietf-wgname-... (I-D.mrose-writing-rfcs for the other example).  Of course this doesn't
     change when the draft version changes.
     -->
<!-- Fudge for XMLmind which doesn't have this built in --> nbhy   "&#8209;">
  <!ENTITY nbsp    "&#160;"> wj     "&#8288;">
]>

<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!-- Processing Instructions can be placed here but if you are editing
     with XMLmind (and maybe other XML editors) they are better placed
     after the rfc element start tag as shown below. -->

<!-- Information about the document.
     category values: std, bcp, info, exp, and historic
     For Internet-Drafts, specify attribute "ipr".
     (ipr values are: full3667, noModification3667, noDerivatives3667),
     Also for Internet-Drafts, can specify values for
     attributes "docName" and, if relevant, "iprExtract".  Note
     that the value for iprExtract is the anchor attribute
     value of a section (such as a MIB specification) that can be
     extracted for separate publication, and is only
     useful whenhe value of "ipr" is not "full3667". -->
    <!-- TODO: verify which attributes are specified only
               by the RFC editor.  It appears that attributes
               "number", "obsoletes", "updates", and "seriesNo"
               are specified by the RFC editor (and not by
               the document author). -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-ietf-6man-ipv6-alt-mark-17" >
    <!-- Processing Instructions- PIs (for a complete list and description,
          see file http://xml.resource.org/authoring/README.html and below... -->

    <!-- Some of the more generally applicable PIs that most I-Ds might want to use -->

    <!-- Try to enforce the ID-nits conventions and DTD validity -->
    <?rfc strict="yes" ?>

    <!-- Items used when reviewing the document -->
    <?rfc comments="no" ?>  <!-- Controls display of <cref> elements -->
    <?rfc inline="no" ?>    <!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
    <?rfc editing="no" ?>   <!-- When yes, insert editing marks: editing marks consist of a
                                 string such as <29> printed in the blank line at the
                                 beginning of each paragraph of text. -->

    <!-- Create Table of Contents (ToC) and set some options for it.
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC
         if the document has more than 15 pages. -->
   <?rfc toc="yes"?>
   <?rfc tocompact="yes"?> <!-- If "yes" eliminates blank lines before main section entries. -->
   <?rfc tocdepth="3"?>    <!-- Sets the number of levels of sections/subsections... in ToC -->

    <!-- Choose the options for the references.
         Some like symbolic tags in the references (and citations) and others prefer
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
    <?rfc symrefs="yes"?>
    <?rfc sortrefs="yes" ?> <!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->

    <!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
         main section on a new page but does not omit the blank lines between list items.
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
    <?rfc compact="yes" ?>
    <?rfc subcompact="no" ?>
    <!-- end of list of popular I-D processing instructions -->

    <!-- ***** FRONT MATTER ***** --> number="9343" obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

<front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 42 characters -->

    <title abbrev="IPv6 AMM">IPv6 Application of the Alternate Marking Method</title>

    <!-- add 'role="editor"' below for Alternate-Marking Method">IPv6 Application of the editors if appropriate --> Alternate-Marking Method</title>
    <seriesInfo name="RFC" value="9343"/>

    <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Riesstrasse, 25</street>
          <city>Munich</city>
          <code>80992</code>
          <region/>
          <country>Germany</country>
        </postal>
        <email>giuseppe.fioccola@huawei.com</email>
      </address>
    </author>
    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <region/>
          <country>China</country>
        </postal>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
      <organization>Telecom Italia</organization>
      <address>
        <postal>
          <street></street>

          <city></city>
          <street/>
          <city/>
          <region/>

          <code></code>

          <country></country>
          <code/>
          <country/>
        </postal>
        <email>mauro.cociglio@outlook.com</email>
      </address>
    </author>
    <author fullname="Fengwei Qin" initials="F." surname="Qin">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>32 Xuanwumenxi Ave.</street>
          <city>Beijing</city>
          <region/>
          <code>100032</code>
          <country>China</country>
        </postal>
        <email>qinfengwei@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Ran Pang" initials="R." surname="Pang">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <street>9 Shouti South Rd.</street>
          <city>Beijing</city>
          <region/>
          <code>100089</code>
          <country>China</country>
        </postal>
        <email>pangran@chinaunicom.cn</email>
      </address>
    </author>
    <date month="December" year="2022"/> <!-- month="March" is no longer necessary
                                           note also, day="30" is optional -->
    <!-- WARNING: If the month and year are the current ones, xml2rfc will fill in the day for
         you. If only the year is specified, xml2rfc will fill in the current day and month
         irrespective of the day.  This silliness should be fixed in v1.31. -->

    <!-- Meta-data Declarations -->

    <!-- Notice the use of &amp; as an escape for & which would otherwise
         start an entity declaration, whereas we want a literal &. -->

	<area>Internet</area>

    <!-- WG name at the upperleft corner of the doc,
         IETF fine for individual submissions.  You can also
         omit this element in which case in defaults to "Network Working Group" -
         a hangover from the ancient history of the IETF! -->

    <workgroup>6MAN Working Group</workgroup>

    <!-- The DTD allows multiple area and workgroup elements but only the first one has any
         effect on output.  -->
    <!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff output. -->
	<workgroup>6MAN</workgroup>
	<keyword>Extension</keyword>
	<keyword>Header</keyword>
	<keyword>Option</keyword>
	<keyword>Destination</keyword>
	<keyword>Hop-By-Hop</keyword>
	<keyword>Performance</keyword>
	<keyword>Measurement</keyword>
	<keyword>Monitoring</keyword>
	<keyword>Passive</keyword>
	<keyword>Hybrid</keyword>
	<keyword>Loss</keyword>
	<keyword>Delay</keyword>
	<keyword>Delay Variation</keyword>
	<keyword>Multipoint</keyword>
	<keyword>Cluster</keyword>
	<keyword>Closed-Loop</keyword>

    <abstract>
      <t>This document describes how the Alternate Marking Alternate-Marking Method can be used
    as a passive performance measurement tool in an IPv6 domain. It defines an
    Extension Header Option to encode Alternate Marking Alternate-Marking information in
    both the Hop-by-Hop Options Header and Destination Options Header.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="I-D.ietf-ippm-rfc8321bis"/> target="RFC9341" format="default"/> and <xref target="I-D.ietf-ippm-rfc8889bis"/> target="RFC9342" format="default"/>
		describe a passive performance measurement method, which can be used to measure packet loss,
		latency
		latency, and jitter on live traffic. Since this method is based on marking consecutive
		batches of packets, the method is often referred to as the Alternate Marking Alternate-Marking Method.</t>
      <t>This document defines how the Alternate Marking Alternate-Marking Method can be used to measure
		performance metrics in IPv6. The rationale is to apply the Alternate Marking Alternate-Marking methodology to IPv6 and
		therefore allow detailed packet loss, delay delay, and delay variation measurements both hop-by-hop hop by hop and end-to-end end to end
		to exactly locate the issues in an IPv6 network.</t>

		<t>The Alternate

		<t>Alternate Marking is an on-path telemetry technique and consists of synchronizing the measurements
		in different points of a network by switching the value of a marking bit and therefore dividing the packet flow
		into batches. Each batch represents a measurable entity recognizable by all network nodes along the path.
		By counting the number of packets in each batch and comparing the values measured by different nodes,
		it is possible to precisely measure the packet loss. Similarly, the alternation of the values
		of the marking bits can be used as a time reference to calculate the delay and delay variation.
		The Alternate Marking Alternate-Marking operation is further described in <xref target="operation"/>.</t> target="operation" format="default"/>.</t>

		<t>This document introduces a TLV (type-length-value) that can be encoded in the Options Headers
		(Hop-by-Hop or Destination), according to <xref target="RFC8200"></xref>, target="RFC8200" format="default"/>, for the purpose of the
		Alternate Marking
		Alternate-Marking Method application in an IPv6 domain.</t>
      <t>The Alternate Marking Alternate-Marking Method MUST <bcp14>MUST</bcp14> be applied to IPv6 only in a controlled environment, as further described
		in <xref target="ctrldmn"/>. target="ctrldmn" format="default"/>. <xref target="RFC8799"></xref> target="RFC8799" format="default"/> provides further discussion of network behaviors
		that can be applied only within limited domains.</t>
      <t>The threat model for the application of the Alternate Marking Alternate-Marking Method in an IPv6 domain is reported in
		<xref target="security"/>.</t> target="security" format="default"/>.</t>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>This document uses the terms related to the Alternate Marking Alternate-Marking Method
		as defined in <xref target="I-D.ietf-ippm-rfc8321bis"/> target="RFC9341" format="default"/> and <xref target="I-D.ietf-ippm-rfc8889bis"/>.</t> target="RFC9342" format="default"/>.</t>
      </section>
      <section title="Requirements Language">

        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>

        <t>
    The key words &quot;MUST&quot;, &quot;MUST NOT&quot;,
        &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
        &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,
		&quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, "<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 &quot;OPTIONAL&quot; "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
    </section>
    <section title="Alternate Marking application numbered="true" toc="default">
      <name>Alternate-Marking Application to IPv6"> IPv6</name>

      <t>The Alternate Marking Alternate-Marking Method requires a marking field. Several alternatives
		could be considered such as IPv6 Extension Headers, IPv6 Address Address, and Flow Label.
		But, it is necessary to analyze the drawbacks for all the available possibilities,
		more specifically:<list>

		  <t>Reusing specifically:</t>
      <ul empty="false" spacing="normal">
        <li>reusing an existing Extension Header for Alternate Marking leads to a
		  non-optimized implementation;</t>

	      <t>Using implementation;</li>
        <li>using the IPv6 destination address to encode the Alternate Marking Alternate-Marking processing
		  is very expensive;</t>

		  <t>Using expensive; and</li>
        <li>using the IPv6 Flow Label for Alternate Marking conflicts with the utilization
	of the Flow Label for load distribution purpose (<xref target="RFC6438"></xref>).</t>
		</list></t> purposes <xref target="RFC6438" format="default"/>.</li>

      </ul>
      <t>In the end, a Hop-by-Hop or a Destination Option is the best choice.</t>
      <t>The approach for the Alternate Marking Alternate-Marking application to IPv6 specified in this memo
		is compliant with <xref target="RFC8200"></xref>. target="RFC8200" format="default"/>. It involves the following operations:<list style="symbols">

		  <t>The operations:</t>
      <ul spacing="normal">
        <li>The source node is the only one that writes the Option Options Header to mark alternately
		  the flow (for both the Hop-by-Hop and Destination Option). The intermediate nodes and destination node
		  MUST
	<bcp14>MUST</bcp14> only read the marking values of the option Option without modifying the Option Header.</t>

		  <t>In Options Header.</li>

        <li>In case of a Hop-by-Hop Option Options Header carrying Alternate Marking Alternate-Marking bits, it the Options Header is not
		  inserted or deleted, deleted on the path, but it can be read by any node along the path. The intermediate nodes
		  may be configured to support this Option or not not, and the measurement can be done only for
		  the nodes configured to read the Option. As further discussed in <xref target="use"/>, target="use" format="default"/>,
		  the presence of the hop-by-hop option Hop-by-Hop Option should not affect the traffic throughput both on nodes
		  that do not recognize this option Option and on the nodes that support it. However, it is worth
		  mentioning that there is a difference between theory and practice. Indeed, in a real implementation implementation,
		  it can happen that is possible for packets with hop-by-hop option could also a Hop-by-Hop Option to be skipped or processed in the slow path.
		  While some proposals are trying to address this problem and make Hop-by-Hop Options more practical
		  (<xref target="I-D.ietf-v6ops-hbh"/>,
		  (see <xref target="I-D.ietf-v6ops-hbh" format="default"/> and <xref target="I-D.ietf-6man-hbh-processing"/>), target="I-D.ietf-6man-hbh-processing" format="default"/>), these aspects
		  are out of the scope for this document.</t>

		  <t>In document.</li>
        <li>In case of a Destination Option Options Header carrying Alternate Marking Alternate-Marking bits, it is not
		  processed, inserted, or deleted by any node along the path until the packet reaches
		  the destination node. Note that, if there is also a Routing Header (RH), any visited
		  destination in the route list can process the Option Header.</t>
		</list></t>

		<t>Hop-by-Hop Option Options Header.</li>
      </ul>
      <t>A Hop-by-Hop Options Header is also useful to signal to routers on the path to process the
      Alternate Marking. However, as said, routers will only examine this option Option if properly configured.</t>

      <t>The optimization of both implementation and the scaling of the Alternate Marking Alternate-Marking Method is
		also considered considered, and a way to identify flows is required. The Flow Monitoring Identification field
		(FlowMonID),
		(FlowMonID) field, as introduced in <xref target="flowmonid"/>, target="flowmonid" format="default"/>, goes in this direction direction, and it is used to identify
		a monitored flow.</t>
      <t>The FlowMonID is different from the Flow Label field of the IPv6 Header (<xref target="RFC6437"></xref>). header <xref target="RFC6437" format="default"/>.
		The Flow Label field in the IPv6 header is used by a source to label sequences of packets to be treated
		in the network as a single flow and, as reported in <xref target="RFC6438"></xref>, target="RFC6438" format="default"/>, it can be used
		for load-balancing/equal cost multi-path (LB/ECMP). load balancing (LB) and equal-cost multipath (ECMP). The reuse of the Flow Label field for identifying monitored flows
		is not considered because it may change the application intent and forwarding behavior. Also, the Flow Label
		may be changed en route route, and this may also invalidate the integrity of the measurement. Those reasons make the definition
		of the FlowMonID necessary for IPv6. Indeed, the FlowMonID is designed and only used to identify the monitored flow.
		Flow Label and FlowMonID within the same packet are totally disjoint, have different scope, scopes,
		are used to identify flows based on different criteria, and are intended for different use cases.</t>
      <t>The rationale for the FlowMonID is further discussed in <xref target="flowmonid"/>. target="flowmonid" format="default"/>. This 20 bit 20-bit field
		allows easy and flexible identification of the monitored flow and enables improved measurement correlation
		and finer granularity since it can be used in combination with the traditional conventional TCP/IP 5-tuple to identify a flow.
		An important point that will be discussed in <xref target="flowmonid"/> target="flowmonid" format="default"/> is the uniqueness of the FlowMonID
		and how to allow disambiguation of the FlowMonID in case of collision.</t>
      <t>The following section highlights an important requirement for the application of the Alternate Marking to IPv6.
        The concept of the controlled domain is explained and it is considered an essential precondition, as also highlighted
		in <xref target="security"/>.</t> target="security" format="default"/>.</t>
      <section anchor="ctrldmn" title="Controlled Domain"> numbered="true" toc="default">
        <name>Controlled Domain</name>

	<t>IPv6 has much more flexibility than IPv4 and innovative applications have been proposed, but
        for security and compatibility reasons, some of these applications are limited to a controlled environment.
		This is also the case of the Alternate Marking Alternate-Marking application to IPv6 as assumed hereinafter.
		In this regard, <xref target="RFC8799"></xref> target="RFC8799" format="default"/> reports further examples of specific limited domain solutions.</t>
        <t>The IPv6 application of the Alternate Marking Alternate-Marking Method MUST <bcp14>MUST</bcp14> be deployed in a controlled domain.
		It is not common that the user traffic originates and terminates within the controlled domain, as also noted in
		<xref target="altmarkmeasdmn"/>. target="altmarkmeasdmn" format="default"/>. For this reason, it will typically only be applicable in an overlay network,
		where user traffic is encapsulated at one domain border, border and decapsulated at the other domain border border, and the encapsulation
		incorporates the relevant extension header for Alternate Marking.
		This requirement also implies that an implementation MUST <bcp14>MUST</bcp14> filter packets that carry Alternate Marking Alternate-Marking
		data and are entering or leaving the controlled domain.</t>
        <t>A controlled domain is a managed network where it is required to select, monitor monitor, and control the access to the network
		by enforcing policies at the domain boundaries in order to discard undesired external packets entering the domain
		and check the internal packets leaving the domain. It does not necessarily mean that a controlled domain is a single administrative domain
		or a single organization. A controlled domain can correspond to a single administrative domain or can be composed by
		multiple administrative domains under a defined network management. Indeed, some scenarios may imply that the Alternate Marking Alternate-Marking Method
		involves more than one domain, but in these cases, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the multiple domains create a whole controlled domain
		while traversing the external domain by employing IPsec <xref target="RFC4301"></xref> target="RFC4301" format="default"/> authentication and encryption or
		other VPN technology that provides full packet confidentiality and integrity protection. In a few words, it must be possible
		to control the domain boundaries and eventually use specific precautions if the traffic traverse traverses the Internet.</t>
        <t>The security considerations reported in <xref target="security"/> target="security" format="default"/> also highlight this requirement.</t>
        <section anchor="altmarkmeasdmn" title="Alternate Marking numbered="true" toc="default">
          <name>Alternate-Marking Measurement Domain"> Domain</name>
          <t>The Alternate Marking Alternate-Marking measurement domain can overlap with the controlled domain or may be a subset
		of the controlled domain. The typical scenarios for the application of the Alternate Marking Alternate-Marking Method
		depend on the controlled domain boundaries, boundaries; in particular:<list>

		  <t>the particular:</t>

<ul empty="false" spacing="normal">

	    <li>The user equipment can be the starting or ending node, node only in case when/if it is fully managed and if it belongs
		  to the controlled domain. In this case case, the user generated user-generated IPv6 packets contain the Alternate Marking Alternate-Marking data.
		  But, in practice, this is not common due to the fact that the user equipment cannot be totally secured in the majority of cases.</t>

	      <t>the CPE (Customer cases.</li>
            <li>The Customer Premises Equipment) Equipment (CPE) or the PE (Provider Edge) Provider Edge (PE) routers are most likely to be the starting or
		  ending nodes since they can be border routers of the controlled domain. For instance, the CPE, which connects the user's premises
		  with the service provider's network, belongs to a controlled domain only if it is managed by the service provider and
		  if additional security measures are taken to keep it trustworthy.
		  Typically
		  Typically, the CPE or the PE can encapsulate a received packet in an outer IPv6 header header, which contains the Alternate Marking Alternate-Marking data.
		  They can are also be able to filter and drop packets from outside of the domain with inconsistent fields
		  to make effective the relevant security rules at the domain boundaries, boundaries; for example example, a simple security check
		  can be to insert the Alternate Marking Alternate-Marking data if and only if the destination is within the controlled domain.</t>

		</list></t> domain.</li>
          </ul>
        </section>
      </section>
    </section>

    <section title="Definition numbered="true" toc="default">
      <name>Definition of the AltMark Option"> Option</name>
      <t>The definition of a TLV for the Options Extension Headers, Header Option,
	   carrying the data fields dedicated to the Alternate Marking method, Alternate-Marking Method,
	   is reported below.</t>
      <section title="Data numbered="true" toc="default">
        <name>Data Fields Format"> Format</name>
        <t>The following figure shows the data fields format for enhanced
      Alternate Marking
      Alternate-Marking TLV (AltMark). This AltMark data can be encapsulated in the IPv6 Options Headers
	  (Hop-by-Hop or Destination Option).

	  <figure>

        </t>
        <artwork name="AltMark: TLV for Alternate Marking"><![CDATA[ Marking" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  Option Type  |  Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              FlowMonID                |L|D|     Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

		where:</t>

      <t><list style="symbols">
	      <t>Option
        <t>

		Where:</t>

		<dl>
		  <dt>Option Type: 8-bit
		  </dt>
		  <dd>8-bit identifier of the type of Option that needs to be
		  allocated. Unrecognized Types MUST <bcp14>MUST</bcp14> be ignored
		  on processing.  For the Hop-by-Hop Options Header or Destination
		  Options Header, <xref target="RFC8200"></xref> target="RFC8200" format="default"/>
		  defines how to encode the three high-order bits of the
		  Option Type field. The two high-order bits specify the
		  action that must be taken if the processing IPv6 node does
		  not recognize the Option Type; for AltMark AltMark, these two bits MUST
		  <bcp14>MUST</bcp14> be set to 00 (skip over this Option and
		  continue processing the header).  The third-highest-order
		  bit specifies whether the Option Data can change en route to
		  the packet's final destination; for AltMark AltMark, the value of
		  this bit MUST <bcp14>MUST</bcp14> be set to 0 (Option Data does
		  not change en route). In this way, since the three
		  high-order bits of the AltMark Option are set to 000, it
		  means that nodes can simply skip this Option if they do not
		  recognize it and that the data of this Option do does not change en route,
		  route; indeed the source is the only one that can write it.</t>

		  <t>Opt it.
		  </dd>

		  <dt>Opt Data Len: 4.
		  </dt>
		  <dd>4. It is the length of the Option Data Fields of this
		  Option in bytes.</t>

          <t>FlowMonID: 20-bit bytes.
		  </dd>

		  <dt>FlowMonID:
		  </dt>
		  <dd>20-bit unsigned integer. The FlowMon identifier is
		  described in <xref target="flowmonid"/>. target="flowmonid" format="default"/>.
		  As further discussed below, it has been picked as 20 bits
		  since it is a reasonable value and a good compromise in
		  relation to the chance of collision. It MUST <bcp14>MUST</bcp14>
		  be set pseudo randomly pseudo-randomly by the source node or by a
		  centralized controller.</t>

          <t>L: Loss controller.
		  </dd>

		  <dt>L:
		  </dt>
		  <dd>Loss flag for Packet Loss Measurement as described in
		  <xref target="loss"/>;</t>

          <t>D: Delay target="loss" format="default"/>.
		  </dd>

		  <dt>D:
		  </dt>
		  <dd>Delay flag for Single Packet Delay Measurement as
		  described in <xref target="delay"/>;</t>

          <t>Reserved: is reserved target="delay" format="default"/>.
		  </dd>

		  <dt>Reserved:
		  </dt>
		  <dd>Reserved for future use. These bits MUST
		  <bcp14>MUST</bcp14> be set to zero on transmission and
		  ignored on receipt.</t>
        </list></t> receipt.
		  </dd>
</dl>

</section>
    </section>

    <section anchor="use" title="Use numbered="true" toc="default">
      <name>Use of the AltMark Option"> Option</name>
      <t>The AltMark Option is the best way to implement the Alternate Marking method Alternate-Marking Method, and it is carried
	  by the Hop-by-Hop Options header Header and the Destination Options header. Header.
	  In case of Destination Option, it is processed only by the source and destination nodes: the source node inserts it
	  and the destination node processes it.
	  While, in
	  In case of the Hop-by-Hop Option, it may be examined by any node along the path, path if explicitly configured to do so.</t>

	  <t>It is important to highlight that the Option Layout can be used both as the Destination Option and as the
	  Hop-by-Hop Option depending on the Use Cases use cases, and it is based on the chosen type of performance measurement.
	  In general, it is needed to perform both end to end end-to-end and hop by hop hop-by-hop measurements, and the Alternate Marking Alternate-Marking
	  methodology allows, by definition, both performance measurements.
	  In many cases cases, the end-to-end measurement
	  is
	  may not enough be enough, and it is required the hop-by-hop measurement, so measurement is required. To meet this need, the most complete choice can be is the
	  Hop-by-Hop Options Header.</t>

      <t>IPv6, as specified in <xref target="RFC8200"></xref>, target="RFC8200" format="default"/>, allows nodes to optionally process
	  Hop-by-Hop headers. Specifically Specifically, the Hop-by-Hop Options header Header is not inserted or deleted, but it may
      be examined or processed by any node along a packet's delivery path, until the packet reaches the node
	  (or each of the set of nodes, nodes in the case of multicast) identified in the Destination
      Address field of the IPv6 header. Also, it is expected that nodes along a packet's delivery path
	  only examine and process the Hop-by-Hop Options header Header if explicitly configured to do so.</t>
      <t>Another scenario that can be mentioned is the presence of a Routing Header.
	  Both Hop-by-Hop Options and Destination Options headers Headers can be used when a Routing Header is present.
	  Depending on where the Destination Options are situated in the header chain (before or after the Routing Header if any),
	  Destination Options headers Headers can be processed by either intermediate routers specified in the Routing Header, Header or by the destination node.
	  As an example, a type of Routing Header, referred to as a Segment Routing Header (SRH), has been defined in <xref target="RFC8754"></xref> target="RFC8754" format="default"/>
	  for the Segment Routing over IPv6 dataplane (SRv6), (SRv6) data place, and more details about the SRv6 application can be found in
	  <xref target="I-D.fz-spring-srv6-alt-mark"/>.</t> target="I-D.fz-spring-srv6-alt-mark" format="default"/>.</t>
      <t>In summary, using these tools, it is possible to control on which nodes measurement occurs:<list style="symbols">

	  <t>Destination occurs:</t>
      <ul spacing="normal">
        <li>Destination Option not preceding a Routing Header => =&gt; measurement
      only by node in Destination Address.</t>

	  <t>Hop-by-Hop Address</li>
        <li>Hop-by-Hop Option => =&gt; every router on the path with feature
      enabled.</t>

	  <t>Destination
      enabled</li>
        <li>Destination Option preceding a Routing Header => =&gt; every destination
      node in the route list.</t>
	  </list></t> list</li>
      </ul>
      <t>In general, Hop-by-Hop and Destination Options are the most suitable ways
	  to implement Alternate Marking.</t>

	  <t>It is worth mentioning that Hop-by-Hop Options are not strongly recommended in <xref target="RFC7045"></xref> target="RFC7045" format="default"/>
	  and <xref target="RFC8200"></xref>, target="RFC8200" format="default"/>, unless there is a clear justification to standardize it, because nodes may be
	  configured to ignore the Options Header, Header or drop or assign packets containing an Options Header to a slow processing path.
	  In case of the AltMark data fields Data Fields described in this document, the motivation to standardize a Hop-by-Hop Option
	  is that it is needed for OAM (Operations, Operations, Administration, and Maintenance). Maintenance (OAM). An intermediate node can read it or not, but
	  this does not affect the packet behavior. The source node is the only one that writes the Hop-by-Hop Option to mark alternately mark
	  the flow, so, flow; therefore, the performance measurement can be done for those nodes configured to read this Option,
	  while the others are simply not considered for the metrics.</t>

	  <t>The Hop-by-Hop Option defined in this document is designed to take advantage of the property of how Hop-by-Hop
	  options
	  Options are processed. Nodes that do not support this Option would be expected to ignore it if encountered,
	  according to the procedures of <xref target="RFC8200"></xref>. target="RFC8200" format="default"/>. This can mean that, in this case, the performance measurement
	  does not account for all links and nodes along a path. The definition of the Hop-by-Hop Options in this document is also
	  designed to minimize throughput impact both on nodes that do not recognize the Option and on node nodes that support it.
	  Indeed, the three high-order bits of the Options Header defined in this draft document are 000 and, in theory, as per
	  <xref target="RFC8200"></xref> target="RFC8200" format="default"/> and <xref target="I-D.ietf-6man-hbh-processing"/>, target="I-D.ietf-6man-hbh-processing" format="default"/>, this means "skip if do not recognize recognized and data do does not change en route". <xref target="RFC8200"></xref> target="RFC8200" format="default"/> also mentions that the nodes only examine and process the Hop-by-Hop Options header Header if explicitly configured to do so. For these reasons, this Hop-by-Hop Option should not affect the throughput.
	  However, in practice, it is important to be aware that the things may be different in the implementation implementation, and it can happen that packets
	  with Hop-by-Hop Hop by Hop are forced onto the slow path, but this is a general issue, as also explained in <xref target="I-D.ietf-6man-hbh-processing"/>. target="I-D.ietf-6man-hbh-processing" format="default"/>.
	  It is also worth mentioning that the application to a controlled domain should avoid the risk of arbitrary nodes dropping packets
	  with Hop-by-Hop Options.</t>
	</section>

    <section anchor="operation" title="Alternate Marking numbered="true" toc="default">
      <name>Alternate-Marking Method Operation"> Operation</name>
      <t>This section describes how the method operates. <xref target="I-D.ietf-ippm-rfc8321bis"/> target="RFC9341" format="default"/>
		introduces several applicable methods methods, which are reported below, and an additional field is introduced
		to facilitate the deployment and improve the scalability.</t>
      <section anchor="loss" title="Packet numbered="true" toc="default">
        <name>Packet Loss Measurement"> Measurement</name>
        <t>The measurement of the packet loss is really straightforward in comparison to the existing mechanisms,
		as detailed in <xref target="I-D.ietf-ippm-rfc8321bis"/>. target="RFC9341" format="default"/>.
		The packets of the flow are grouped into batches, and all the packets within a batch are marked by setting
		the L bit (Loss flag) to a same value. The source node can switch the value of the L bit between 0 and 1
		after a fixed number of packets or according to a fixed timer, and this depends on the
		implementation. The source node is the only one that marks the packets to create the batches, while
		the intermediate nodes only read the marking values and identify the packet batches.
		By counting the number of packets in each batch and comparing the values measured by
		different network nodes along the path, it is possible to measure the packet loss that occurred
		in any single batch between any two nodes. Each batch represents a measurable entity
		recognizable by all network nodes along the path.</t>
        <t>Both fixed number of packets and a fixed timer can be used by the source node to create packet batches.
		But, as also explained in <xref target="I-D.ietf-ippm-rfc8321bis"/>, target="RFC9341" format="default"/>, the timer-based batches are preferable because
		they are more deterministic than the counter-based batches. There

Unlike the timer-based batches, there is no definitive rule
for counter-based batches, differently from timer-based batches. which are not considered in <xref target="RFC9341"/>.

	 Using a fixed timer for the switching offers
		better control over the method, indeed method; indeed, the length of the batches can be chosen large enough to simplify
		the collection and the comparison of the measures taken by different network nodes. In the implementation implementation,
		the counters can be sent out by each node to the controller that is responsible for the calculation.
		It is also possible to exchange this information by using other on-path techniques. But techniques, but this is out of scope
	for this document.</t>

        <t>Packets with different L values may get swapped at batch boundaries, and in this case,
		it is required that each marked packet can be assigned to the right batch by each router.
		It is important to mention that for the application of this method method, there are two elements
		to consider: the clock error between network nodes and the network delay.
		These can create
		offsets between the batches and out-of-order of the packets.
		The mathematical formula
		on timing aspects, explained in section 5 of <xref target="I-D.ietf-ippm-rfc8321bis"/>,  sectionFormat="of" section="5" target="RFC9341" format="default"/>, must be satisfied satisfied,
		and it takes into considerations consideration the different causes of reordering such as clock error and network delay.
		The assumption is to define the available counting interval where to get stable counters and to avoid these issues.
		Specifically, if the effects of network delay are ignored, the condition to implement the methodology is that
		the clocks in different nodes MUST <bcp14>MUST</bcp14> be synchronized to the same clock reference with an accuracy of +/- B/2 time units,
		where B is the fixed time duration of the batch. In this way way, each marked packet can be assigned to the right batch by each node.
		Usually
		Usually, the counters can be taken in the middle of the batch period to be sure to read quiescent counters.
		In a few words words, this implies that the length of the batches MUST <bcp14>MUST</bcp14> be chosen large enough so that the method
		is not affected by those factors. The length of the batches can be determined based on the specific deployment scenario.</t>
        <figure anchor="Lbit" title="Packet anchor="Lbit">
          <name>Packet Loss Measurement and Single-Marking Methodology using Using L bit">
        <artwork><![CDATA[ Bit</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
L bit=1   ----------+           +-----------+           +----------
                    |           |           |           |
L bit=0             +-----------+           +-----------+
           Batch n        ...      Batch 3     Batch 2     Batch 1
         <---------> <---------> <---------> <---------> <--------->

                             Traffic Flow
         ===========================================================>
L bit   ...1111111111 0000000000 11111111111 00000000000 111111111...
         ===========================================================>
]]></artwork>
        </figure>
        <t>It is worth mentioning that the duration of the batches is considered stable over time in the previous figure.
	   In theory, it is possible to change the length of batches over time and among different flows for more flexibility.
	   But, in practice, it could complicate the correlation of the information.</t>
	 </section>
      <section anchor="delay" title="Packet numbered="true" toc="default">
        <name>Packet Delay Measurement"> Measurement</name>
        <t>The same principle used to measure packet loss can also be applied also to
		one-way delay measurement. Delay metrics MAY <bcp14>MAY</bcp14> be calculated using the following two
		possibilities:<list style="numbers">

		<t>Single-Marking Methodology: This
		possibilities:</t>
		<dl>
		  <dt>Single-Marking Methodology:</dt> <dd>This approach uses only the L bit to calculate both packet loss
		and delay. In this case, the D flag MUST <bcp14>MUST</bcp14> be set to zero on transmit and ignored by the
		monitoring points. The alternation of the values of the L bit can be used as a time reference to calculate
		the delay. Whenever the L bit changes and a new batch starts, a network node can store the timestamp
		of the first packet of the new batch, batch; that timestamp can be compared with the timestamp of the
		first packet of the same batch on a second node to compute packet delay. But But, this measurement
		is accurate only if no packet loss occurs and if there is no packet reordering at the edges
		of the batches. A different approach can also be considered considered, and it is based on the concept of the
		mean delay.  The mean delay for each batch is calculated by considering the average arrival time
		of the packets for the relative batch. There are limitations also in this case indeed, indeed; each node needs
		to collect all the timestamps and calculate the average timestamp for each batch. In addition, the
		information is limited to a mean value.</t>

		<t>Double-Marking Methodology: This value.</dd>

          <dt>Double-Marking Methodology:</dt> <dd>This approach is more complete and uses the L bit only to calculate
		packet loss loss, and the D bit (Delay flag) is fully dedicated to delay measurements. The idea is to use
		the first marking with the L bit to create the alternate flow and, within the batches identified by the L bit,
		a second marking is used to select the packets for measuring delay. The D bit creates a new set of marked packets
		that are fully identified over the network, network so that a network node can store the timestamps of these packets;
		these timestamps can be compared with the timestamps of the same packets on a second node to compute packet
		delay values for each packet. The most efficient and robust mode is to select a single double-marked packet
		for each batch, batch; in this way way, there is no time gap to consider between the double-marked packets to avoid their reorder.
		Regarding the rule for the selection of the packet to be double-marked, the same considerations in <xref target="loss"/>
		apply target="loss" format="default"/>
		also here apply here, and the double-marked packet can be chosen within the available counting interval that
        is not affected by factors such as clock errors.
		If a double-marked packet is lost, the delay measurement for the considered batch is simply discarded,
		but this is not a big problem because it is easy to recognize the problematic batch and skip the measurement
		just for that one. So in order to have more information about the delay and to overcome out-of-order issues issues,
		this method is preferred.</t>

		</list></t> preferred.</dd>
        </dl>
        <t>In summary summary, the approach with double marking Double Marking is better than the approach with single marking. Single Marking. Moreover,
		the two approaches provide slightly different pieces of information information, and the data consumer can combine them
		to have a more robust data set.</t>
        <t>Similar to what is said in <xref target="loss"/> target="loss" format="default"/> for the packet counters, in the implementation implementation, the timestamps can be
		sent out to the controller that is responsible for the calculation or could also be exchanged using other on-path techniques.
		But
		But, this is out of scope for this document.</t>
        <figure anchor="Dbit" title="Double-Marking anchor="Dbit">
          <name>Double-Marking Methodology using Using L bit Bit and D bit">
        <artwork><![CDATA[ Bit</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
L bit=1   ----------+           +-----------+           +----------
                    |           |           |           |
L bit=0             +-----------+           +-----------+

D bit=1         +          +          +          +            +
                |          |          |          |            |
D bit=0   ------+----------+----------+----------+------------+-----

                             Traffic Flow
         ===========================================================>
L bit   ...1111111111 0000000000 11111111111 00000000000 111111111...

D bit   ...0000010000 0000010000 00000100000 00001000000 000001000...
         ===========================================================>
]]></artwork>
        </figure>

		<t>Likewise
        <t>Likewise, to packet delay measurement (both for Single Marking and Double Marking), the method can also be used
		to measure the inter-arrival jitter.</t>
      </section>
      <section anchor="flowmonid" title="Flow numbered="true" toc="default">
        <name>Flow Monitoring Identification"> Identification</name>
        <t>The Flow Monitoring Identification (FlowMonID) identifies the flow to be measured and
		is required for some general reasons:<list>

		<t>First, reasons:</t>
        <ul spacing="normal">
          <li>First, it helps to reduce the per node per-node configuration. Otherwise, each node needs to
	    configure an access-control access control list (ACL) for each of the monitored flows.
		Moreover, using a flow identifier allows a flexible granularity for the flow definition, definition;
		indeed, it can be used together with other identifiers (e.g. 5-tuple).</t>

	    <t>Second, (e.g., 5-tuple).</li>
          <li>Second, it simplifies the counters handling. Hardware processing of flow tuples (and ACL matching)
		is challenging and often incurs into performance issues, especially in tunnel interfaces.</t>

		<t>Third, interfaces.</li>
          <li>Third, it eases the data export encapsulation and correlation for the collectors.</t>
	    </list></t> collectors.</li>
        </ul>
        <t>The FlowMonID MUST <bcp14>MUST</bcp14> only be used as a monitored flow identifier in order to determine a monitored flow
		within the measurement domain. This entails not only an easy identification but improved correlation as well.</t>
        <t>The FlowMonID allocation procedure can be stateful or stateless. In case of a stateful approach, it is required that
		the FlowMonID historic information can be stored and tracked in order to assign unique values within the domain.
		This may imply a complex procedure procedure, and it is considered out of scope for this document.
		The stateless approach is described hereinafter where FlowMonID values are pseudo randomly pseudo-randomly generated.</t>
        <t>The value of 20 bits has been selected for the FlowMonID since it is a good compromise and implies a low rate
		of ambiguous FlowMonIDs that can be considered acceptable in most of the applications. The disambiguation issue
		can be solved by tagging the pseudo randomly pseudo-randomly generated FlowMonID with additional flow information.
		In particular, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to consider the 3-tuple FlowMonID, source source, and destination addresses:<list style="symbols">

		  <t>If addresses:</t>
        <ul spacing="normal">

	  <li>If the 20 bit 20-bit FlowMonID is set independently and pseudo randomly pseudo-randomly in a distributed way way, there is a chance of collision.
		  Indeed, by using the well-known birthday problem in probability theory, if the 20 bit 20-bit FlowMonID
		  is set independently and pseudo randomly pseudo-randomly without any additional input entropy, there is a 50% chance of collision
		  for 1206 flows. So, for more entropy, FlowMonID is combined with source and destination addresses.
		  Since there is a 1% chance of collision for 145 flows, it is possible to monitor 145 concurrent flows per host pairs
		  with a 1% chance of collision.</t>

		  <t>If collision.</li>
          <li>If the 20 bits 20-bit FlowMonID is set pseudo randomly pseudo-randomly but in a centralized way, the controller can instruct the nodes properly
		  in order to guarantee the uniqueness of the FlowMonID. With 20 bits, the number of combinations is 1048576, and the controller
		  should ensure that all the FlowMonID values are used without any collision. Therefore, by considering source and destination addresses
		  together with the FlowMonID, it can be is possible to monitor 1048576 concurrent flows per host pairs.</t>
        </list></t> pairs.</li>
        </ul>
        <t>A consistent approach MUST <bcp14>MUST</bcp14> be used in the Alternate Marking Alternate-Marking deployment to avoid the mixture of different ways of identifying.
		All the nodes along the path and involved into in the measurement SHOULD <bcp14>SHOULD</bcp14> use the same mode for identification.
		As mentioned, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use the FlowMonID for identification purpose purposes in combination with source and destination addresses
		to identify a flow. By considering source and destination addresses together with the FlowMonID FlowMonID, it can be is possible to monitor
		145 concurrent flows per host pairs with a 1% chance of collision in case of pseudo randomly pseudo-randomly generated FlowMonID, or
		1048576 concurrent flows per host pairs in case of a centralized controller. It is worth mentioning that
		the solution with the centralized control allows finer granularity and therefore adds even more flexibility to the flow identification.</t>
        <t>The FlowMonID field is set at the source node, which is the ingress point of the measurement domain, and
		can be set in two ways:<list style="letters">

		<t>It ways:</t>
        <ul spacing="normal"><li>It can be algorithmically generated by the source node, that which can set it pseudo-randomly with some
		chance of collision. This approach cannot guarantee the uniqueness of FlowMonID since conflicts and collisions are possible.
		But, considering the recommendation to use FlowMonID with source and destination addresses addresses, the conflict probability is reduced due to
		the FlowMonID space available for each endpoint pair (i.e. (i.e., 145 flows with 1% chance of collision).</t>

		<t>It collision).</li>
          <li>It can be assigned by the central controller. Since the controller knows the network topology,
		it can allocate the value properly to avoid or minimize ambiguity and guarantee the uniqueness. In this regard,
		the controller can verify that there is no ambiguity between different pseudo-randomly generated FlowMonIDs on the same path.
		The conflict probability is really small given that the FlowMonID is coupled with source and destination addresses addresses,
        and up to 1048576 flows can be monitored for each endpoint pair. When all values in the FlowMonID space are consumed,
		the centralized controller can keep track and reassign the values that are not used any more by old flows.</t>

		</list></t> flows.</li>
        </ul>
        <t>If the FlowMonID is set by the source node, the intermediate nodes can read the FlowMonIDs from the packets in flight
		and act accordingly. While, if If the FlowMonID is set by the controller, both possibilities are feasible for the intermediate nodes nodes,
        which can learn by reading the packets or can be instructed by the controller.</t>
        <t>The FlowMonID setting by the source node may seem faster and more scalable than the FlowMonID setting by the controller. But,
		it is supposed that the controller does not slow the process since it can enable Alternate Marking method the Alternate-Marking Method and its parameters (like FlowMonID)
		together with the flow instantiation, as further described in <xref target="I-D.ietf-idr-sr-policy-ifit"/> target="I-D.ietf-idr-sr-policy-ifit" format="default"/> and <xref target="I-D.chen-pce-pcep-ifit"/>.</t> target="I-D.ietf-pce-pcep-ifit" format="default"/>.</t>
      </section>

      <section title="Multipoint numbered="true" toc="default">
        <name>Multipoint and Clustered Alternate Marking"> Marking</name>
        <t>The Alternate Marking method Alternate-Marking Method can be extended to any kind of multipoint to multipoint multipoint-to-multipoint paths.
		<xref target="I-D.ietf-ippm-rfc8321bis"/> target="RFC9341" format="default"/> only applies to point-to-point unicast flows,
		while the Multipoint Alternate Marking Clustered method, Alternate-Marking Method, introduced in <xref target="I-D.ietf-ippm-rfc8889bis"/>, target="RFC9342" format="default"/>,
		is valid for multipoint-to-multipoint unicast flows, anycast anycast, and ECMP flows.</t>

		<t><xref target="I-D.ietf-ippm-rfc8889bis"/> target="RFC9342" format="default"/> describes the network clustering approach approach, which
		allows a flexible and optimized performance measurement.
		A Cluster cluster is the smallest identifiable non-trivial subnetwork of the entire Network network graph
		that still satisfies the condition that the number of packets that goes in is the same number that goes out.
		With network clustering, it is possible to use the partition of the network into clusters
		at different levels in order to perform the needed degree of detail.</t>
        <t>For Multipoint Alternate Marking, FlowMonID can identify in general
		a multipoint-to-multipoint flow and not only a point-to-point flow.</t>
      </section>
      <section title="Data numbered="true" toc="default">
        <name>Data Collection and Calculation"> Calculation</name>

        <t>The nodes enabled to perform performance monitoring collect the value
		of the packet counters and timestamps. There are several alternatives to implement
		Data Collection
		data collection and Calculation, calculation, but this is not specified in this document.</t>
        <t>There are documents on the control plane mechanisms of Alternate Marking, e.g. e.g.,
		<xref target="I-D.ietf-idr-sr-policy-ifit"/>, target="I-D.ietf-idr-sr-policy-ifit" format="default"/> and <xref target="I-D.chen-pce-pcep-ifit"/>.</t> target="I-D.ietf-pce-pcep-ifit" format="default"/>.</t>
      </section>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>This document aims to apply a method to perform the performance measurements that does
		not directly affect Internet security nor applications that run on
		the Internet. However, implementation of this method must be mindful
		of security and privacy concerns.</t>
      <t>There are two types of security concerns:
		potential harm caused by the measurements and potential harm to the measurements.</t>

	    <t>Harm
		<dl>
		  <dt>Harm caused by the measurement: Alternate
		  </dt>
<dd>Alternate Marking implies the insertion of an Option Options Header to the IPv6
packets by the source node, but this must be performed in a way that does not
alter the quality of service experienced by the packets and that preserves
stability and performance of routers doing the measurements. As already
discussed in <xref target="use"/>, target="use" format="default"/>, the design of the AltMark
Option has been chosen with throughput in mind, such that it can be
implemented without affecting the user experience.</t>

		<t>Harm experience.
</dd>

<dt>Harm to the measurement: Alternate Marking
</dt>
<dd>Alternate-Marking measurements could be harmed by routers altering the
fields of the AltMark Option (e.g. (e.g., marking of the packets, packets or FlowMonID) or by a
malicious attacker adding the AltMark Option to the packets in order to consume
the resources of network devices and entities involved. As described above,
the source node is the only one that writes the Option Options Header while the
intermediate nodes and destination node only read it without modifying the
		Option
Options Header. But, for example, an on-path attacker can modify the flags,
whether intentionally or accidentally, or deliberately insert an option Option to the
packet flow or delete the option Option from the packet flow. The consequent effect
could be to give the appearance of loss or delay or to invalidate the measurement
by modifying option Option identifiers, such as FlowMonID. The malicious implication
can be to cause actions from the network administrator where an intervention
is not necessary or to hide real issues in the network.  Since the measurement
itself may be affected by network nodes intentionally altering the bits of the
AltMark Option or injecting Options headers Headers as a means for Denial of Service
(DoS), the Alternate Marking MUST <bcp14>MUST</bcp14> be applied in the context of
a controlled domain, where the network nodes are locally administered and this
type of attack can be avoided. For this reason, the implementation of the
method is not done on the end node if it is not fully managed and does not
belong to the controlled domain. Packets generated outside the controlled
domain may consume router resources by maliciously using the HbH Hop-by-Hop Option, but
this can be mitigated by filtering these packets at the controlled domain
boundary. This can be done because, because if the end node does not belong to the
controlled domain, it is not supposed to add the AltMark HbH Hop-by-Hop Option, and it
can be easily recognized.</t> recognized.
</dd>

</dl>

<t>An attacker that does not belong to the controlled domain can maliciously send packets with the AltMark Option.
		But
		But, if Alternate Marking is not supported in the controlled domain, no problem happens because the AltMark Option is treated
		as any other unrecognized option Option and will not be considered by the nodes since they are not configured to deal with it, so it; so,
		the only effect is the increased packet size (by 48 bits).
		While if
		If Alternate Marking is supported in the controlled domain, it is also necessary to avoid that keep the measurements are affected from being affected,
		and external packets with the AltMark Option MUST <bcp14>MUST</bcp14> be filtered.
		As any other Hop-by-Hop Options or Destination Options, it is possible to filter AltMark Options entering or leaving the domain
		e.g. domain,
		e.g., by using ACL extensions for filtering.</t>
		<t>The flow identifier (FlowMonID), together with the two marking bit bits (L and D), comprises the AltMark Option.

		As explained in <xref target="flowmonid"/>, target="flowmonid" format="default"/>, there is a chance of collision if the FlowMonID
		is set pseudo randomly pseudo-randomly, but that there is a solution for this issue. In general general, this may not be a problem problem, and a low rate of
		ambiguous FlowMonIDs can be acceptable, acceptable since this does not cause significant harm to the operators or
		their clients clients, and this harm may not justify the complications of avoiding it. But, for large scale measurements,
		a big number of flows could be monitored and the probability of a collision is higher, thus higher; thus, the disambiguation
		of the FlowMonID field can be considered.</t>
      <t>The privacy concerns also need to be analyzed even if the method only relies on information contained
		in the Option Options Header without any release of user data. Indeed, from a confidentiality perspective,
		although the AltMark Option does not contain user data, the metadata can be used for network reconnaissance
		to compromise the privacy of users by allowing attackers to collect information about network performance and network paths.
		The AltMark Option contains two kinds of metadata: the marking bits (L and D bits) D) and the flow identifier (FlowMonID).<list>

		   <t>The (FlowMonID).</t>

		<ul  spacing="normal">
        <li>The marking bits are the small information that is exchanged between the network nodes. Therefore, due to this intrinsic
		   characteristic, network reconnaissance through passive eavesdropping on data-plane data plane traffic is difficult.
		   Indeed, an attacker cannot gain information about network performance from a single monitoring point. The only way for an attacker
		   can be to eavesdrop on multiple monitoring points at the same time, because they have to do the same kind of calculation
		   and aggregation as Alternate Marking requires.</t>

		   <t>The requires.</li>
        <li>The FlowMonID field is used in the AltMark Option as the identifier of the monitored flow. It represents a more sensitive information
		   for network reconnaissance and may allow a flow tracking type of attack because an attacker could collect information
		   about network paths.</t>

		</list></t> paths.</li>
      </ul>
      <t>Furthermore, in a pervasive surveillance attack, the information that can be derived over time is more.
		But, as further described hereinafter, the application of the Alternate Marking to a controlled domain
		helps to mitigate all the above aspects of privacy concerns.</t>
      <t>At the management plane, attacks can be set up by misconfiguring or by maliciously configuring the AltMark Option.
		Thus, AltMark Option configuration MUST <bcp14>MUST</bcp14> be secured in a way that authenticates authorized users and verifies the
		integrity of configuration procedures. Solutions to ensure the integrity of the AltMark Option are outside the
		scope of this document. Also, attacks on the reporting of the statistics between the monitoring points and the
        network management system (e.g. (e.g., centralized controller) can interfere with the proper functioning of the system.
		Hence, the channels used to report back flow statistics MUST <bcp14>MUST</bcp14> be secured.</t>
      <t>As stated above, the precondition for the application of the Alternate Marking is that it MUST <bcp14>MUST</bcp14> be applied
		in specific controlled domains, thus confining the potential attack vectors within the network domain.
		A limited administrative domain provides the network administrator with the means to select, monitor monitor, and
		control the access to the network, making it a trusted domain. In this regard regard, it is expected to enforce policies
        at the domain boundaries to filter both external packets with the AltMark Option entering the domain and
		internal packets with the AltMark Option leaving the domain. Therefore, the trusted domain is unlikely subject
		to the hijacking of packets since packets with AltMark Option are processed and used only within the controlled domain.</t>
      <t>As stated, the application to a controlled domain ensures the control over the packets entering and leaving the domain,
		but despite that, leakages may happen for different reasons, reasons such as a failure or a fault. In this case, nodes
		outside the domain are expected to ignore packets with the AltMark Option since they are not configured to handle it and
		should not process it.</t>
      <t>Additionally, it is to be noted note that the AltMark Option is carried by the Options Header
		and it will have some impact on the packet sizes for the monitored flow and on the path MTU, MTU
		since some packets might exceed the MTU. However, the relative small size (48 bit bits in total)
		of these Option Options Headers and its application to a controlled domain help to mitigate the problem.</t>
      <t>It is worth mentioning that the security concerns may change based on the specific deployment scenario
        and related threat analysis, which can lead to specific security solutions that are beyond the scope of this document.
		As an example, the AltMark Option can be used as a Hop-by-Hop or Destination Option and, in case of a Destination Option,
		multiple administrative domains may be traversed by the AltMark Option that is not confined to a single administrative domain.
		In this case, the user, who is aware of the kind of risks, may still want to use Alternate Marking for telemetry and test purposes purposes, but
        the controlled domain must be composed by more than one administrative domains. domain. To this end, the inter-domain links need
		to be secured (e.g., by IPsec, IPsec or VPNs) in order to avoid external threats and realize the whole controlled domain.</t>
      <t>It might be theoretically possible to modulate the marking or the other fields of the AltMark Option to serve as a covert channel
		to be used by an on-path observer. This may affect both the data and management plane, but, here too, the application to a
		controlled domain helps to reduce the effects.</t>
      <t>The Alternate Marking Alternate-Marking application described in this document relies on a time synchronization
		protocol. Thus, by attacking the time protocol, an attacker can potentially compromise the integrity
		of the measurement. A detailed discussion about the threats against time protocols and
		how to mitigate them is presented in <xref target="RFC7384"/>. target="RFC7384" format="default"/>. Network Time Security (NTS),
		described in <xref target="RFC8915"/>, target="RFC8915" format="default"/>, is a mechanism that can be employed. Also, the time,
		which is distributed to the network nodes through the time protocol, is centrally taken from an external accurate time source, source
		such as an atomic clock or a GPS clock. By attacking the time source source, it can be is possible to compromise the integrity
		of the measurement as well. There are security measures that can be taken to mitigate the GPS spoofing attacks attacks, and a
		network administrator should certainly employ solutions to secure the network domain.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
        <t>The numbered="true" toc="default">
      <name>IANA Considerations</name>

   <t>IANA has allocated the Option Type should be assigned in IANA's
		the "Destination Options and Hop-by-Hop Options" registry.</t>

		<t>This draft requests the following IPv6 Option Type assignment from
		the Destination Options and Hop-by-Hop Options sub-registry subregistry of
		Internet the
		"Internet Protocol Version 6 (IPv6) Parameters (https://www.iana.org/assignments/ipv6-parameters/).</t>

	  <t><figure>
          <artwork><![CDATA[
   Hex Value    Binary Value      Description           Reference
                act chg rest
   ----------------------------------------------------------------
   TBD          00   0  tbd       AltMark               [This draft]

]]></artwork>
        </figure></t> Parameters" registry (<eref  brackets="angle" target="https://www.iana.org/assignments/ipv6-parameters/"/>) as follows:</t>

		<table anchor="table_1">
  <name>Destination Options and Hop-by-Hop Options Registry</name>
  <thead>
    <tr>
      <th>Hex Value</th>
      <th rowspan="1" colspan="3">Binary Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
      <tr>
      <th></th>
      <th>act</th>
      <th>chg</th>
      <th>rest</th>
      <th></th>
      <th></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x12</td>
      <td>00</td>
      <td>0</td>
      <td>10010</td>
      <td>AltMark</td>
      <td>RFC 9343</td>
    </tr>
  </tbody>
</table>
</section>

</middle>

<back>

  <displayreference target="I-D.ietf-pce-pcep-ifit" to="PCEP-IFIT"/>
  <displayreference target="I-D.fz-spring-srv6-alt-mark" to="SRv6-AMM"/>
  <displayreference target="I-D.ietf-6man-hbh-processing" to="HBH-OPTIONS-PROCESSING"/>
  <displayreference target="I-D.ietf-idr-sr-policy-ifit" to="BGP-SR-POLICY-IFIT"/>
  <displayreference target="I-D.ietf-v6ops-hbh" to="PROC-HBH-OPT-HEADER"/>

    <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.8200.xml"/>

<!-- draft-ietf-ippm-rfc8321bis-03: In AUTH48-DONE; Cluster 446 document.
-->
<reference anchor="RFC9341" target="https://www.rfc-editor.org/info/rfc9341">
<front>
<title>Alternate-Marking Method</title>
<author initials='G' surname='Fioccola' fullname='Giuseppe Fioccola' role="editor">
  <organization/>
</author>

<author initials='M' surname='Cociglio' fullname='Mauro Cociglio'>
  <organization/>
</author>

<author initials='G' surname='Mirsky' fullname='Greg Mirsky'>
  <organization/>
</author>

<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'>
  <organization/>
</author>

<author initials='T' surname='Zhou' fullname='Tianran Zhou'>
  <organization/>
</author>

<date month='December' year='2022'/>
</front>
<seriesInfo name="RFC" value="9341"/>
<seriesInfo name="DOI" value="10.17487/RFC9341"/>
</reference>

<!-- draft-ietf-ippm-rfc8889bis-04: in AUTH48-DONE; Cluster 446 document
-->
<reference anchor="RFC9342" target="https://www.rfc-editor.org/info/rfc9342">
<front>
<title>Clustered Alternate-Marking Method</title>

<author initials='G' surname='Fioccola' fullname='Giuseppe Fioccola' role="editor">
  <organization/>
</author>

<author initials='M' surname='Cociglio' fullname='Mauro Cociglio'>
  <organization/>
</author>

<author initials='A' surname='Sapio' fullname='Amedeo Sapio'>
  <organization/>
</author>

<author initials='R' surname='Sisto' fullname='Riccardo Sisto'>
  <organization/>
</author>

<author initials='T' surname='Zhou' fullname='Tianran Zhou'>
  <organization/>
</author>
<date month='December' year='2022'/>
</front>
<seriesInfo name="RFC" value="9342"/>
<seriesInfo name="DOI" value="10.17487/RFC9342"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>

	<!--draft-fz-spring-srv6-alt-mark; I-D exists as of 12/14/22-->
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-fz-spring-srv6-alt-mark.xml"/>

        <!--draft-ietf-idr-sr-policy-ifit; I-D exists as of 12/14/22 -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-idr-sr-policy-ifit.xml"/>

	<!--draft-chen-pce-pcep-ifit; Expired. Replaced by draft-ietf-pce-pcep-ifit; I-D exists as of 12/14/22-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-pcep-ifit.xml"/>

	<!--draft-ietf-v6ops-hbh; I-D exists as of 12/14/22-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-v6ops-hbh.xml"/>

	<!--draft-ietf-6man-hbh-processing; I-D exists as of 12/14/22-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-6man-hbh-processing.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>

      <t>The authors would like to thank Bob Hinden, Ole Troan, Martin Duke, Lars Eggert, Roman Danyliw,
		Alvaro Retana, Eric Vyncke, Warren Kumari, Benjamin Kaduk, Stewart Bryant, Christopher Wood,
		Yoshifumi Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter, Greg Mirsky, Ron Bonica <contact fullname="Bob Hinden"/>, <contact fullname="Ole Troan"/>, <contact fullname="Martin Duke"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Roman Danyliw"/>,
		<contact fullname="Alvaro Retana"/>, <contact fullname="Eric Vyncke"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Stewart Bryant"/>, <contact fullname="C. A. Wood"/>,
		<contact fullname="Yoshifumi Nishida"/>, <contact fullname="Tom Herbert"/>, <contact fullname="Stefano Previdi"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Greg Mirsky"/>, and <contact fullname="Ron Bonica"/>
		for the precious their valuable comments and suggestions.</t>
    </section>

<!-- Possibly a 'Contributors' section ... -->

</middle>

<!--  *****BACK MATTER ***** -->
<back>
    <!-- References split to informative and normative -->
    <references title="Normative References">

       <?rfc include='reference.RFC.2119'?>

	   <?rfc include='reference.RFC.8174'?>

	   <?rfc include='reference.RFC.8200'?>

	   <?rfc include='reference.I-D.ietf-ippm-rfc8321bis'?>

	   <?rfc include='reference.I-D.ietf-ippm-rfc8889bis'?>

    </references>

    <references title="Informative References">
        <!-- A reference written by by an organization not a persoN. -->

	   <?rfc include='reference.RFC.7045'?>

	   <?rfc include='reference.RFC.8754'?>

	   <?rfc include='reference.RFC.6437'?>

	   <?rfc include='reference.RFC.6438'?>

	   <?rfc include='reference.RFC.7384'?>

	   <?rfc include='reference.RFC.8915'?>

	   <?rfc include='reference.RFC.8799'?>

	   <?rfc include='reference.RFC.4301'?>

	   <?rfc include='reference.I-D.fz-spring-srv6-alt-mark'?>

	   <?rfc include='reference.I-D.ietf-idr-sr-policy-ifit'?>

	   <?rfc include='reference.I-D.chen-pce-pcep-ifit'?>

	   <?rfc include='reference.I-D.ietf-v6ops-hbh'?>

	   <?rfc include='reference.I-D.ietf-6man-hbh-processing'?>

    </references>
  </back>
</rfc>