<?xml version="1.0" encoding="utf-8"?> encoding="UTF-8"?>

<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-ietf-nvo3-geneve-oam-16" number="9772" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.7.0 -->
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<front>
    <title>Active
    <title abbrev="Active OAM for Use in Geneve">Active Operations, Administration, and Maintenance (OAM) for Use in Generic Network Virtualization Encapsulation (Geneve)</title>
<!-- [rfced] Please note that the title of the document has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide").

Original:
                      Active OAM for use in Geneve</title> Geneve

Current:
  Active Operations, Administration, and Maintenance (OAM) for Use in
         Generic Network Virtualization Encapsulation (Geneve)
-->

    <seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-geneve-oam-16"/> name="RFC" value="9772"/>
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>

	<author initials="S" initials="S." surname="Boutros" fullname="Sami Boutros">
      <organization>Ciena</organization>
      <address>
        <email>sboutros@ciena.com</email>
      </address>
    </author>

    <author initials="D" initials="D." surname="Black" fullname="David Black">
      <organization>Dell EMC</organization>
      <address>
        <postal>
          <street>176 South Street</street>
          <city>Hopkinton, MA</city>
          <code>01748</code>
          <country>United States of America</country>
        </postal>
        <email>david.black@dell.com</email>
      </address>
    </author>

    <author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti">
      <organization>VMware</organization>
      <address>
        <email>santosh.pallagatti@gmail.com</email>
      </address>
    </author>
    <date year="2025"/>

    <area>Routing</area>
    <workgroup>NVO3  Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2025" month="April"/>

    <area>RTG</area>
    <workgroup>nvo3</workgroup>

    <keyword>OAM</keyword>

    <abstract>
      <t>
Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensible network virtualization overlay protocol
designed to encapsulate network packets for transport across underlying physical networks.
This document specifies the requirements and provides a framework for Operations, Administration, and Maintenance (OAM) in Geneve networks.
It outlines the OAM functions necessary to monitor, diagnose, and troubleshoot Geneve overlay networks to ensure
proper operation and performance. The document aims to guide the implementation of OAM mechanisms within the Geneve protocol
to support network operators in maintaining reliable and efficient virtualized network environments.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
 Geneve <xref target="RFC8926" format="default"/> is designed to support various scenarios of network virtualization.
 It encapsulates multiple protocols, such as Ethernet and IPv4/IPv6, and includes metadata within the Geneve message.
 </t>
 <t>
 Operations, Administration, and Maintenance (OAM) protocols provide fault management and performance monitoring functions
 necessary for comprehensive network operation. Active OAM protocols, as defined in <xref target="RFC7799"/>,
 utilize specially constructed packets injected into the network. OAM protocols such as ICMP/ICMPv6 ICMP and ICMPv6 (<xref target="RFC0792"/> and
 <xref target="RFC4443"/> respectively), Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"/>, and the
 Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> are example examples of active OAM protocols.
 To ensure that performance metrics or detected failures
 are accurately related to a particular Geneve flow, it is critical that these OAM test packets share fate, i.e., are in-band, with the overlay data packets
 of that monitored flow when traversing the underlay network. In this document document, "in-band OAM" is interpreted as follows:
 </t>
         <ul spacing="normal">
         <li>
             In-band OAM is an active or hybrid OAM method, as defined in <xref target="RFC7799"/>,
             that traverses the same set of links and interfaces and receives the same Quality of Service
             treatment as the monitored object. In this context, the monitored object refers to either
             the entire Geneve tunnel as a whole or a specific tenant flow within a given Geneve tunnel.
</li>
      </ul>
 <t>
<xref target="requirements"/> of this document lists the general requirements for active OAM protocols in the Geneve overlay network.
 IP encapsulation meets these requirements and is suitable for encapsulating active OAM protocols within a Geneve overlay network.
<!--[rfced] Please clarify; is it possible that each endpoint (rather than
the two endpoints together) is an interface of an NVE? If so, we suggest
updating this sentence as follows.

Original:
   Active OAM messages in a
   Geneve overlay network are exchanged between two Geneve tunnel
   endpoints, which may be the tenant-facing interface of the Network
   Virtualization Edge (NVE) or another device acting as a Geneve tunnel
   endpoint.

Perhaps:
   Active OAM messages in a
   Geneve overlay network are exchanged between two Geneve tunnel
   endpoints; each endpoint may be the tenant-facing interface of the Network
   Virtualization Edge (NVE) or another device acting as a Geneve tunnel
   endpoint.
-->
 Active OAM messages in a Geneve overlay network are exchanged between two Geneve tunnel endpoints,
 which may be the tenant-facing interface
of the Network Virtualization Edge (NVE) or another device acting as a Geneve tunnel endpoint.
Testing end-to-end between tenants is out of scope.
 For simplicity, this document uses an NVE to represent the Geneve tunnel endpoint.
 Refer to <xref target="RFC7365"/> and <xref target="RFC8014"/> for detailed definitions and descriptions of an NVE.
 </t>
 <t>
 The IP encapsulation of Geneve OAM defined in this document applies to an overlay service by introducing
 a Management Virtual Network Identifier (VNI), which can be used in combination with various values
 of the Protocol Type field in the Geneve header, such as Ethertypes for IPv4 or IPv6.
 The analysis and definition of other types of OAM encapsulation in Geneve are outside the scope of this document.
 </t>

      <section numbered="true" toc="default">
        <name>Conventions used Used in this document</name> This Document</name>

        <section numbered="true" toc="default">
          <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
	</t>
        </section>

        <section numbered="true" toc="default">
          <name>Acronyms</name>
          <t>Geneve:        Generic

	  <dl spacing="normal" newline="false">
            <dt>Geneve:</dt><dd>Generic Network Virtualization Encapsulation </t>
          <t>NVO3:            Network Encapsulation</dd>
            <dt>NVO3:</dt><dd>Network Virtualization over Layer 3</t>
          <t>OAM:                Operations, 3</dd>
            <dt>OAM:</dt><dd>Operations, Administration, and Maintenance</t>
          <t>VNI:                 Virtual Maintenance</dd>
            <dt>VNI:</dt><dd>Virtual Network Identifier</t>
          <t>BFD:                Bidirectional Identifier</dd>
            <dt>BFD:</dt><dd>Bidirectional Forwarding Detection</t>
          <t>STAMP:           Simple Detection</dd>
            <dt>STAMP:</dt><dd>Simple Two-way Active Measurement Protocol</t>
          <t>NVE:                Network Protocol</dd>
            <dt>NVE:</dt><dd>Network Virtualization Edge</t> Edge</dd>
	  </dl>
	</section>

      </section>
    </section>

        <section anchor="active-oam-sec" numbered="true" toc="default">
      <name>The Applicability of Active OAM Protocols in Geneve Networks</name>

    <section anchor="requirements" numbered="true" toc="default">
      <name>Requirements for Active OAM Protocols in Geneve Networks</name>
      <t>
OAM protocols, whether part of fault management or performance monitoring, are intended to provide
reliable information that can be used to detect a failure,
identify the defect defect, and localize it, thus helping to identify and apply corrective actions to minimize the negative impact on service.
Several OAM protocols are used to perform these functions;
these protocols require demultiplexing at the receiving instance of Geneve.
To improve the accuracy of
the correlation between the condition experienced by the monitored Geneve tunnel and
the state of the OAM protocol protocol, the OAM encapsulation is required
to comply with the following requirements:
</t>
      <ul empty="true" spacing="normal">
        <li>
   Requirement 1: Geneve
      <ol type="Requirement %d:" group="reqs">
        <li anchor="req-1">Geneve OAM test packets MUST <bcp14>MUST</bcp14>
        share the same fate as the data traffic of the monitored Geneve
        tunnel.
<!--[rfced] Should "follow the same overlay and transport path" be plural
"paths"?

Original:
      Specifically,
      the OAM test packets MUST be in-band with the monitored traffic
      and follow the same overlay and transport path as packets carrying
      data payloads in the forward direction, i.e., from the ingress
      toward the egress endpoint(s) of the OAM test.

Perhaps:
      Specifically,
      the OAM test packets MUST be in-band with the monitored traffic
      and follow the same overlay and transport paths as packets carrying
      data payloads in the forward direction, i.e., from the ingress
      toward the egress endpoint(s) of the OAM test.
-->
Specifically, the OAM test packets <bcp14>MUST</bcp14> be
        in-band with the monitored traffic and follow the same overlay and
        transport path as packets carrying data payloads in the forward
        direction, i.e., from the ingress toward the egress endpoint(s) of the
        OAM test.
	</li>
      </ul>
      <t>
An
      </ol>
	<t>An OAM protocol MAY <bcp14>MAY</bcp14> be employed to monitor an entire
	Geneve tunnel. In this case, test packets could be in-band relative to
	a subset of tenant flows transported over the Geneve tunnel. If the
	goal is to monitor the conditions experienced by the flow of a
	particular tenant, the test packets MUST <bcp14>MUST</bcp14> be in-band
	with that specific flow within the Geneve tunnel. Both scenarios are
	discussed in detail in <xref target="control-channel-sec"/>.
</t>
      <ul empty="true" spacing="normal">
        <li> target="control-channel-sec"/>.</t>

	<ol type="Requirement %d:" group="reqs">
<!--[rfced] How may "from the underlay network IP forwarding point
of view" be rephrased for clarity?

Original:
      Requirement 2: The encapsulation of OAM control messages and data
      packets in the underlay network MUST be indistinguishable from
      each other from the underlay network IP forwarding point of view.
</li>
        <li>

Perhaps:
      Requirement 3: 2: The encapsulation of OAM control messages and data
      packets in the underlay network MUST be indistinguishable from
      each other from the point of view of the forwarding in the IP
      underlay network.

(We note the phrase "the forwarding in the IP underlay network" is used in
Section 2.2.)
-->
        <li anchor="req-2">The encapsulation of OAM control messages and
        data packets in the underlay network <bcp14>MUST</bcp14> be
        indistinguishable from each other from the underlay network IP
        forwarding point of view.
	</li>
	<li anchor="req-3">The presence of an OAM control message in a
	Geneve packet MUST <bcp14>MUST</bcp14> be unambiguously identifiable to
	Geneve functionality, such as at endpoints of Geneve tunnels.
</li>
        <li>
Requirement 4: OAM tunnels.</li>
        <li anchor="req-4">OAM test packets MUST NOT <bcp14>MUST NOT</bcp14> be
        forwarded to a tenant system.
</li>
      </ul>
      <t>
A system.</li>
	</ol>
	<t>A test packet generated by an active OAM protocol, whether for
	defect detection or performance measurement,
MUST <bcp14>MUST</bcp14> be
	in-band with the tunnel or data flow being monitored, as specified in Requirement 1.
	<xref target="req-1" format="none">Requirement 1</xref>.  In environments where multiple paths through the
	domain are available, underlay transport nodes can be programmed to
	use characteristic information to balance the load across known paths.
	It is essential that test packets follow the same route - -- that is,
	traverse the same set of nodes and links as a data packet of the
	monitored flow. Therefore, the following requirement supports OAM
	packet fate-sharing with the data flow:
</t>
      <ul empty="true" spacing="normal">
        <li>
Requirement 5: There MUST flow.</t>
	<ol type="Requirement %d:" group="reqs">
        <li anchor="req-5">There <bcp14>MUST</bcp14> be a way to encode
        entropy information into the underlay forwarding scheme so that OAM
        packets take the same dataflow data-flow paths as the transit traffic flows.
</li>
      </ul> flows.</li>
      </ol>
      </section>

      <section anchor="control-channel-sec" numbered="true" toc="default">
        <name>Defect Detection and Troubleshooting in Geneve Network with Active OAM</name>
        <t>
This section considers two scenarios where active OAM is used to detect and localize defects in a Geneve network.
<xref target="geneve-model-fig" format="default"/> presents an example of a Geneve domain.
        </t>

        <figure anchor="geneve-model-fig">
          <name>An example Example of a Geneve domain</name> Domain</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+                                             +--------+
| Tenant +--+                                     +----| Tenant |
| VNI 28 |  |                                     |    | VNI 35 |
+--------+  |          ................           |    +--------+
            |  +----+  .              .  +----+   |
            |  | NVE|--.              .--| NVE|   |
            +--| A  |  .              .  | B  |---+
               +----+  .              .  +----+
               /       .              .
              /        .     Geneve   .
+--------+   /         .    Network   .
| Tenant +--+          .              .
| VNI 35 |             .              .
+--------+             ................
                              |
                            +----+
                            | NVE|
                            | C  |
                            +----+
                              |
                              |
                    =====================
                      |               |
                  +--------+      +--------+
                  | Tenant |      | Tenant |
                  | VNI 28 |      | VNI 35 |
                  +--------+      +--------+
]]></artwork>
	</figure>
        <t>
In the first case, consider when a communication problem between
Network Virtualization Edge (NVE) device A and NVE C exists.
Upon the investigation, the operator discovers that the forwarding in the IP underlay network is working accordingly.
Still, the Geneve connection is unstable for all NVE A and NVE C tenants.
Detection, troubleshooting, and localization of the problem can be done regardless of the VNI value.
</t>
        <t>
In the second case, traffic on VNI 35 between NVE A and NVE B has no problems,
as on VNI 28 between NVE A and NVE C. But However, traffic on VNI 35 between NVE A
and NVE C experiences problems, for example, excessive packet loss.
</t>
<t>
   The first case can be detected and investigated using any VNI
   value, whether it connects tenant systems or not; however, to
   conform to Requirement#4 (<xref target="requirements"/>) <xref target="req-4" format="none">Requirement 4</xref>, OAM test packets SHOULD <bcp14>SHOULD</bcp14> be transmitted
   on a VNI that doesn't have any tenants.  Such a Geneve tunnel is
   dedicated to carrying only control and management data between the
   tunnel endpoints, hence so it is referred to as a Geneve "Geneve control
   channel
   channel" and that VNI is referred to as the Management VNI. "Management VNI". A
   configured VNI MAY <bcp14>MAY</bcp14> be used to identify the control channel, but it
   is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the default value 1 be used as the Management
   VNI. Encapsulation of test packets using the Management VNI is discussed in <xref target="oam-encap-section"/>.
</t>
<t>
The control channel of a Geneve tunnel MUST NOT <bcp14>MUST NOT</bcp14> carry tenant data.
   As no tenants are connected using the control channel, a system
   that supports this specification MUST NOT <bcp14>MUST NOT</bcp14> forward a packet
   received over the control channel to any tenant. A packet received
   by the system that supports this specification over the control channel MUST <bcp14>MUST</bcp14> be forwarded if and only if it is sent
   onto the control channel of the concatenated Geneve tunnel.
   Else, it MUST <bcp14>MUST</bcp14> be terminated locally. The
   Management VNI SHOULD <bcp14>SHOULD</bcp14> be terminated on the tenant-facing side of
   the Geneve encapsulation/decapsulation functionality, not the DC-network-facing
   side (per definitions in Section 4 of <xref target="RFC8014"/>) target="RFC8014" sectionFormat="of" section="4"/>), so that Geneve
   encap/decap functionality is included in its scope.  This approach
   causes an active OAM packet, e.g., an ICMP echo request, to be
   decapsulated in the same fashion as any other received Geneve
   packet.  In this example, the resulting ICMP packet is handed to
   NVE's local management functionality for the processing which
   generates an ICMP echo reply.  The ICMP echo reply is encapsulated
   in Geneve as (as specified in <xref target="oam-encap-section"/>. target="oam-encap-section"/>) for forwarding it back to the
   NVE that sent the echo request.  One advantage of this approach is
   that a repeated ICMP echo request/reply test could detect an intermittent problem in
   Geneve encap/decap hardware, which would not be tested if the
   Management VNI were handled as a "special case" at the
   DC-network-facing interface.
</t>
        <t>
The second case is when a test packet is transmitted using
the VNI value associated with the monitored service flow. By doing that, the test packet
experiences network treatment as the tenant's packets.
An example of the realization of that scenario is discussed in <xref target="RFC9521"/>.
</t>
    <section anchor="geneve-echo-sec" numbered="true" toc="default">
      <name>Echo Request and Echo Reply in Geneve Tunnel</name>
      <t>
 ICMP and ICMPv6 (<xref target="RFC0792" format="default"/> and <xref target="RFC4443" format="default"/> respectively),
 as noted above, are examples of an active OAM protocol. They
 provide required on-demand defect detection and failure localization. ICMP control messages
 immediately follow the inner IP header encapsulated in Geneve.
 ICMP extensions for Geneve networks use mechanisms defined in <xref target="RFC4884" format="default"/>.
</t>
    </section>
    </section>

      <section anchor="oam-encap-section" numbered="true" toc="default">
        <name>Active OAM Encapsulation in Geneve</name>
        <t>
Active OAM over a Management VNI in the Geneve network uses an IP encapsulation.
Protocols such as BFD <xref target="RFC5880" format="default"/> and STAMP <xref target="RFC8762" format="default"/> use UDP transport.
The destination UDP port number in the inner UDP header (<xref target="oam-geneve-encap-fig" format="default"/>) identifies the OAM protocol.
This approach is well-known and has been used, for example, in MPLS networks <xref target="RFC8029" format="default"/>.
To use IP encapsulation for an active OAM protocol, the Protocol Type field of the Geneve header
MUST
<bcp14>MUST</bcp14> be set to the IPv4 (0x0800) 0x0800 (IPv4) or IPv6 (0x86DD) value. 0x86DD (IPv6). <xref target="RFC9521"/> describes the use of IP encapsulation for BFD.
</t>
        <figure anchor="oam-geneve-encap-fig">
          <name>An Example of Geneve IP/UDP Encapsulation of an Active OAM Packet</name>
          <artwork name="" 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Outer IPvX Header                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Outer UDP Header                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                          Geneve Header                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Inner IPvX Header                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Inner UDP Header                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Active OAM Packet                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>

<!--[rfced] Regarding Section 2.3, the IANA actions for
draft-ietf-mpls-p2mp-bfd are not yet complete, i.e., the
Dummy-IPv6-Prefix requested by draft-ietf-mpls-p2mp-bfd has not yet been
assigned, so the text of this document has not been updated.

Should a reference to draft-ietf-mpls-p2mp-bfd be added?

We note that https://www.iana.org/performance/ietf-draft-status lists
draft-ietf-mpls-p2mp-bfd as waiting on authors since 22 Feb 2025.

Unless the text is changed to remove this prefix, this document
will remain in AUTH48 until the Dummy-IPv6-Prefix has been assigned.

ORIGINAL:
   Inner IP header:
        </t>
        <dl newline="false" spacing="normal">
          <dt/>
          <dd>Destination

      Destination IP: The IP address MUST be set to the loopback address
      127.0.0.1/32 for IPv4 version.  For IPv6, the address MUST be
      selected from the Dummy IPv6 Prefix for IPv6 *Dummy-IPv6-Prefix*.
      A source-only IPv6 dummy address is used as the destination to
      generate an exception and a reply message to the request message
      received.
         </dd>
         </dl>
         <t>

   [Note to RFC Editor: Please replace *Dummy-IPv6-Prefix* with the
   actual value allocated (requested in draft-ietf-mpls-p2mp-bfd) in
   IANA IPv6 Special-Purpose Address Registry.]
         </t>
-->

<!--[rfced] Please consider whether "dummy" would be more clear
as "example" or "placeholder" or similar.

Original: the Dummy IPv6 Prefix
Original: A source-only IPv6 dummy address
-->

<dl newline="true" spacing="normal">
  <dt>Inner IP header:</dt>
  <dd><dl newline="false" spacing="normal">
          <dt/>
          <dd>Source IP:
  <dt>Destination IP:</dt><dd><t>The IP address <bcp14>MUST</bcp14> be set to the
  loopback address 127.0.0.1/32 for IPv4 version.  For IPv6, the address
  <bcp14>MUST</bcp14> be selected from the Dummy IPv6 Prefix for IPv6
  *Dummy-IPv6-Prefix*.  A source-only IPv6 dummy address is used as the
  destination to generate an exception and a reply message to the request
  message received.</t>
  <t>[Note to RFC Editor: Please replace
  *Dummy-IPv6-Prefix* with the actual value allocated (requested in
  draft-ietf-mpls-p2mp-bfd) in IANA IPv6 Special-Purpose Address Registry.]</t></dd>
  <dt>Source IP:</dt><dd>IP address of the NVE.</dd>
          <dt/>
          <dd>TTL
  <dt>TTL or Hop Limit: MUST Limit:</dt><dd><bcp14>MUST</bcp14> be set to 255 per <xref
  target="RFC5082" format="default"/>.  The receiver of an active OAM Geneve
  packet with IP/UDP encapsulation MUST <bcp14>MUST</bcp14> drop packets whose
  TTL/Hop Limit is not 255. 255.</dd>
</dl>
  </dd>
</dl>
      </section>

    </section>

    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no requirements for IANA. This section can be removed before the publication.</t> IANA actions.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   As part of a Geneve network, active OAM inherits the security considerations discussed in
   <xref target="RFC8926" format="default"/>. Additionally, a system MUST <bcp14>MUST</bcp14> provide control to limit
   the rate of Geneve OAM packets punted to the Geneve control plane for processing
   in order to avoid overloading that control plane.
      </t>
      <t>
      OAM in Geneve packets uses the General TTL Security Mechanism <xref target="RFC5082"/>,
      and any packet received with an inner TTL / Hop Count other than 255 MUST <bcp14>MUST</bcp14> be discarded.
      </t>
    </section>
    <section anchor="ack" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
  The authors express their appreciation to Donald E. Eastlake 3rd for his suggestions that improved the readability of the document.
      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/>
      </references>

      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
        <!-- href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/> --> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4884.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4884.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8014.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8014.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7365.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7365.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9521.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9521.xml"/>
      </references>
    </references>

    <section anchor="ack" numbered="false">
      <name>Acknowledgments</name>
      <t>
  The authors express their appreciation to <contact fullname="Donald E. Eastlake 3rd"/> for his suggestions that improved the readability of the document.
      </t>
    </section>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

    </back>
</rfc>