<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="IETF" docName="draft-ietf-ipsecme-ikev2-rename-esn-05" number="9827" consensus="true" ipr="trust200902" updates="7296" > obsoletes="" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3" xml:lang="en">

  <front>
    <title abbrev="Renaming ESN in IKEv2">Renaming the Extended Sequence Number
    (ESN) Transform Type in the Internet Key Exchange Protocol Version 2
    (IKEv2)</title>
    <seriesInfo name="RFC" value="9827"/>
    <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
      <organization>ELVIS-PLUS</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <region></region>
          <country>Russian Federation</country>
        </postal>
        <phone></phone>
        <email>svan@elvis.ru</email>
      </address>
    </author>
    <date />

    <area>Security Area</area> month="July" year="2025"/>

    <area>SEC</area>
    <workgroup>ipsecme</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>

    <abstract>
      <t> This document clarifies and extends the meaning of transform type Transform Type 5 in IKEv2. Internet Key Exchange Protocol Version 2 (IKEv2).
      It updates RFC 7296 by renaming the transform type Transform Type 5 from "Extended Sequence Numbers (ESN)"
      to "Sequence Numbers (SN)". It also renames two currently defined values for this transform type: Transform Type:
      value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from
      "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers".
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
    <section>
      <name>Introduction</name>
      <t>The IP Security (IPsec) Architecture <xref target="RFC4301" /> target="RFC4301"/> defines a set of security services provided by IPsec protocols the
      Authentication Header (AH) <xref target="RFC4302" /> target="RFC4302"/> and Encapsulating Security Payload (ESP) <xref target="RFC4303" />. target="RFC4303"/>.
      One of these services is replay protection, which is referred to as "anti-replay" in these documents. In IPsec IPsec, the anti-replay service is optional, optional;
      each receiver of AH and/or ESP packets can choose whether to enable it on a per Security Association (SA) basis.
      The replay protection in AH and ESP is achieved by means of a monotonically increasing counter that never wraps around,
      which around and
      is sent in each AH or ESP packet in the Sequence Number field. The receiver maintains a sliding window that allows
      to detect
      duplicate packets. packets to be detected.
      </t>
      <t> Both AH and ESP allow using use of either a 32-bit counter or a 64-bit counter.
      The latter case is referred to as Extended Sequence Numbers (ESN) in AH and ESP specifications.
      Since the Sequence Number field in both AH and ESP headers is only 32 bits in size,
      in case of ESN the high-order 32 bits of the counter are not transmitted and are determined by the receiver
      based on previously received packets.
      </t>

      <t> Since the decision
      <t>The receiver decides whether to enable the anti-replay service is taken by the receiver based only on the receiver's local policy, so
      the sender sender, in accordance with the specifications for AH (<xref target="RFC4302" /> Section 3.3.2) sectionFormat="comma" section="3.3.2"/>) and ESP (<xref target="RFC4303" /> Section 3.3.3) sectionFormat="comma" section="3.3.3"/>),
      should always assume that the replay protection is enabled on the receiving side. Thus, the sender should always send the increasing counter values
      and should take care that the counter never wraps around. AH and ESP specifications also discuss situations when in which
      replay protection is not possible to achieve achieve, even if senders do all as prescribed -- like in multicast
      Security Associations with multiple unsynchronized senders. Both AH and ESP specifications allow the sender to
      avoid maintaining the counter if the sender has been notified somehow that the anti-replay service
      is disabled by the receiver or is not possible to achieve.
      </t>
      <t> AH and ESP Security Associations are usually established using the Internet Key Exchange protocol version 2 (IKEv2)  IKEv2 <xref target="RFC7296" />. target="RFC7296"/>.
      The process of SA establishment includes calculation of a shared key and negotiation of various SA parameters,
      such as cryptographic algorithms. This negotiation in IKEv2 is performed via transforms (see Section 3.3.2 of <xref target="RFC7296" />). sectionFormat="of" section="3.3.2"/>).
      The type of transform  determines what parameter is being negotiated. Each transform type Transform Type has an associated list of possible values
      (called Transform IDs), IDs) that determine the possible options for negotiation. See <xref target="IKEV2-IANA" /> target="IKEV2-IANA"/> for the list of transform types Transform Types
      and associated transform Transform IDs.
      </t>
      <t> Transform type Type 5 "Extended ("Extended Sequence Numbers (ESN)" (ESN)") is used in IKEv2 to negotiate the way sequence numbers
      for replay protection are generated, transmitted transmitted, and processed in the context of an SA. For this transform type There are
      two values are defined for this Transform Type -- "No Extended Sequence Numbers" and "Extended Sequence Numbers".
      </t>
      <t> This document updates the IKEv2 specification <xref target="RFC7296" /> target="RFC7296"/> by renaming transform type Transform Type 5 and the
      two associated transform Transform IDs.
      </t>
    </section>
    <section anchor="problem" title="Problem Description"> anchor="problem">
      <name>Problem Description</name>
      <t> IKEv2 currently has no means to negotiate the case when both peers agree that replay protection is not needed.
        Even when both peers locally disable anti-replay service as receivers, they still need to maintain increasing sequence numbers
        as senders, taking care that they never wrap around (see <xref target="I-D.pan-ipsecme-anti-replay-notification" />). target="I-D.pan-ipsecme-anti-replay-notification"/>).
      </t>
      <t> There is also no way to inform receivers that replay protection is not possible for a particular SA
        (for example in case of a multicast SA with several unsynchronized senders).
      </t>

        <t> Future
      <t>Future IPsec security protocols may provide more options for the handling of anti-replay counters,
        like sending full 64-bit sequence numbers or completely omitting them in packets (see <xref target="I-D.klassert-ipsecme-eesp" />). target="I-D.klassert-ipsecme-eesp"/>).
        These options will require means to be negotiated in IKEv2.
      </t>
      <t> Transform type Type 5 is the best candidate for addressing these issues:
        it is already used for negotiation of how sequence numbers are handled in AH and ESP ESP, and
        it is possible to define additional transform Transform IDs that could be used in the corresponding situations.
        However, the current definition of transform type Transform Type 5 is too narrow -- its name implies that
        this transform can only be used for negotiation of using ESN.
      </t>
    </section>
    <section anchor="clarification" title="Extending anchor="clarification">
      <name>Extending the Semantics of Transform Type 5">
        <t> 5</name>
<!-- [rfced] Is the second paragraph the current definition?  The first paragraph makes us think the definition is current.  However, the third paragraph (indicating it needs clarification) makes us think it is the old definition.  Please consider adding text to indicate whether it is the old or new definition.

Original:
3.  Extending the Semantics of Transform Type 5

   This document extends the semantics of transform type 5 in IKEv2 to
   the following definition.

   Transform type 5 defines the set of properties of sequence numbers of
   IPsec packets of a given SA when these packets enter the network.

   This definition requires some clarifications.

Perhaps:
3.  Extending the Semantics of Transform Type 5

   This document extends the semantics of Transform Type 5 in IKEv2 to
   be defined as follows:

      Transform Type 5 defines the set of properties of sequence numbers
      of IPsec packets of a given SA when these packets enter the network.

   The updated definition is clarified as follows:
-->

      <t> This document extends the semantics of Transform Type 5 in IKEv2 to the following definition.
      </t>
      <t> Transform type Type 5 defines the set of properties of sequence numbers of IPsec packets of a given SA when these packets enter the network.
      </t>
      <t> This definition requires some clarifications.
      </t>
      <ul>
        <li>
                <t>
<!-- [rfced] We are having trouble parsing this sentence.  Please provide an update if our suggested text is incorrect.

Original:
   *  By "sequence numbers" here we assume logical entities (like
      counters) that can be used for replay protection on receiving
      sides.  In particular, these entities are not necessarily the
      content of the Sequence Number field in the IPsec packets, but may
      be constructed using some information, that is not necessaryly
      transmitted.

Perhaps:
   *  The use of "sequence numbers" implies that logical entities (like
      counters) can be used for replay protection on receiving
      sides.  In particular, these entities are not necessarily the
      content of the Sequence Number field in the IPsec packets, as they
      may be constructed using some information that is not transmitted.
-->

          <t> By "sequence numbers" here we assume logical entities (like
          counters) that can be used for replay protection on receiving
          sides. In particular, these entities are not necessarily the content
          of the Sequence Number field in the IPsec packets, but may be
          constructed using some information, that is not necessarily
          transmitted.
          </t>
        </li>
        <li>
                <t>
<!-- [rfced] We have updated this sentence as described below.  Please let us know if any corrections are needed.

Original:
   *  The properties are interpreted as a characteristic of IPsec SA
      packets, and not as a result of a sender actions.

Current:
   *  The properties are interpreted as characteristics of IPsec SA
      packets rather than the results of sender actions.
-->

          <t> The properties are interpreted as characteristics of IPsec SA
          packets rather than the results of sender actions.  For example, in
          multicast SA with multiple unsynchronized senders, even if each
          sender ensures the uniqueness of sequence numbers it generates, the
          uniqueness of sequence numbers for all IPsec packets is not
          guaranteed.
          </t>
        </li>
        <li>
          <t> The properties are defined for the packets just entering the
          network and not for the packets that receivers get.  This is because
          network behavior may break some of these properties (e.g., packet duplication would break sequence numbers uniqueness by packet duplication). number uniqueness).
          </t>
        </li>
        <li>
          <t> The properties of sequence numbers are interpreted in a broad
          sense, that which includes the case when sequence numbers are absent.
          </t>
        </li>
      </ul>

        <t>

<!-- [rfced] For readability, we have updated the sentence as shown below.  Please let us know if any corrections are needed.  In addition, please consider whether the abbreviated form of "SN" should be plural (i.e., Sequence Numbers (SNs) - we recognize that ESN was singular even though "Numbers" was plural).

Original:
   Given this definition, transform type 5 in the IANA registries for
   IKEv2 <xref target="IKEV2-IANA" /> [IKEV2-IANA] is renamed from "Extended Sequence Numbers (ESN)"
   to "Sequence Numbers (SN)" with the meaning, that it defines the
   properties the sequence numbers would have.

Current:
   Given this updated definition, Transform Type 5 in the "Transform Type
   Values" registry [IKEV2-IANA] has been renamed from "Extended Sequence
   Numbers (ESN)" to "Sequence Numbers (SN)".
-->

      <t> Given this updated definition, Transform Type 5 in the "Transform Type Values" registry <xref target="IKEV2-IANA"/> has been renamed from
        "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)".
      </t>
      <t> It is expected that new transform Transform IDs will be defined for this transform type Transform Type in the future
        (like in G-IKEv2 <xref target="I-D.ietf-ipsecme-g-ikev2" /> target="I-D.ietf-ipsecme-g-ikev2"/> for the case of multicast SAs).
        Documents defining new transform Transform IDs should include description descriptions of the properties the sequence numbers
        would have if the new transform Transform ID is was selected. In particular, this description the descriptions should include discussion of whether these properties
        allow achieving replay protection. protection to be achieved.
      </t>
      <t> Some existing protocols (like Implicit IV in ESP <xref target="RFC8750" /> target="RFC8750"/> or
        Aggregation and Fragmentation for ESP <xref target="RFC9347" />) target="RFC9347"/>) rely on properties that are guaranteed
        for the currently defined transform IDs, but Transform IDs; however, this might not be true for future transform Transform IDs.
        When a new transform Transform ID is defined, its description should include a  discussion about the possibility
        of using this transform the Transform ID in protocols, protocols that rely on some particular properties of sequence numbers.
      </t>

        <t> The
      <t>The two currently defined transform Transform IDs for this transform type Transform Type 5 define the following properties of sequence numbers.
      </t>

      <ul>
        <li>
<!-- [rfced] "their monotonic increase" is not easily parsed. May we update as follows for readability?
Note that this text appears in the definitions for values 0 and 1.

Original:
      They can also be used with protocols that rely
      on sequence numbers uniqueness (like [RFC8750]) or their monotonic
      increase (like [RFC9347]).

Perhaps:
      They can also be used with protocols that rely
      on sequence numbers uniqueness (e.g., [RFC8750]) or monotonically
      increasing sequence numbers (e.g., [RFC9347]).
-->

          <t> Value 0 for transform type 5 defines sequence numbers as
          monotonically increasing 32-bit counters that are transmitted in the
          Sequence Number field of AH and ESP packets. They never wrap around
          and are guaranteed to be unique, thus they are suitable for replay
          protection.  They can also be used with protocols that rely on
          sequence numbers number uniqueness (like (e.g., <xref target="RFC8750" />) target="RFC8750"/>) or their
          monotonic increase (like (e.g., <xref target="RFC9347" />). target="RFC9347"/>). The sender and
          the receiver actions are defined in Sections 3.3.2 <xref target="RFC4302"
          sectionFormat="bare" section="3.3.2"/> and 3.4.3 of <xref target="RFC4302" />
          sectionFormat="bare" section="3.4.3"/> of <xref target="RFC4302"/>
          for AH and in Sections 3.3.3 <xref target="RFC4303" sectionFormat="bare"
          section="3.3.3"/> and 3.4.3 of <xref target="RFC4303" /> sectionFormat="bare"
          section="3.4.3"/> of <xref target="RFC4303"/> for ESP.
          </t>
        </li>
        <li>
          <t> Value 1 for transform type 5 defines sequence numbers as
          monotonically increasing 64-bit counters. The low-order 32 bits are
          transmitted in the Sequence Number field of AH and ESP packets packets, and
          the high-order 32 bits are implicitly determined on receivers based
          on previously received packets. The sequence numbers never wrap
          around and are guaranteed to be unique, thus they are suitable for
          replay protection. They can also be used with protocols that rely on
          sequence numbers number uniqueness
                (like (e.g., <xref target="RFC8750" />) target="RFC8750"/>) or their
          monotonic increase (like (e.g., <xref target="RFC9347" />). target="RFC9347"/>). To be able to
          correctly process the incoming packets on receivers receivers, the packets must
          be authenticated (even when the replay protection is not used).  The
          sender and the receiver actions are defined in Sections 3.3.2 <xref
          target="RFC4302" sectionFormat="bare" section="3.3.2"/> and 3.4.3 of <xref
          target="RFC4302" /> sectionFormat="bare" section="3.4.3"/> of <xref
          target="RFC4302"/> for AH and in Sections 3.3.3 <xref target="RFC4303"
          sectionFormat="bare" section="3.3.3"/> and 3.4.3 of <xref target="RFC4303" />
          sectionFormat="bare" section="3.4.3"/> of <xref target="RFC4303"/>
          for ESP.
          </t>
        </li>
      </ul>
      <t> Given the descriptions above and the new definition of transform type Transform Type 5, the two currently defined transform Transform IDs
        are renamed to better reflect the properties of sequence numbers they assume.
      </t>

      <ul>
            <li><t>
        <li>
          <t> Transform ID 0 is renamed from "No Extended Sequence Numbers" to
          "32-bit Sequential Numbers".</t></li>
            <li><t> Numbers".</t>
        </li>
        <li>
          <t> Transform ID 1 is renamed from "Extended Sequence Numbers" to
          "Partially Transmitted 64-bit Sequential Numbers".</t></li> Numbers".</t>
        </li>
      </ul>
      <t> Note, Note that the above descriptions do not change the existing
      semantics of these transform Transform IDs, they only provide clarification.
        Note also,  Also note that ESP and AH packet processing for these transform Transform IDs is not
      affected, and bits on the wire do not change.
      </t>
    </section>

    <section title="Security Considerations">
    <section>
      <name>Security Considerations</name>
      <t> This document does not affect security of the AH, ESP ESP, and IKEv2 protocols.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
<!-- [rfced] Note that we have updated the IANA Considerations to reduce redundancy throughout.  Please review carefully and let us know if any updates are needed.

You can review the changes by looking through a diff of the IANA Considerations section:
   https://www.rfc-editor.org/authors/rfc9827-diff.html
   https://www.rfc-editor.org/authors/rfc9827-rfcdiff.html (side-by-side view)
-->

      <t> This document makes the following changes in to registries within the "Internet Key Exchange Version 2 (IKEv2) Parameters" IANA registries registry group
      <xref target="IKEV2-IANA" />. It is assumed that RFCXXXX refers to this specification. target="IKEV2-IANA"/>.
      </t>

<t>The "Transform Type Values" registry has been updated as follows: </t>
<ul>
          <li><t>The existing transform type
       <li>
          <t>renamed Transform Type 5 from "Extended Sequence Numbers (ESN)" in the "Transform Type Values" registry
          is renamed
          to "Sequence Numbers (SN)".
          </t></li>

          <li><t>Appended [RFCXXXX]
          </t>
        </li>
        <li>
          <t>added as a reference to the Reference column of this RFC for Transform Type 5 in 5.</t>
        </li>
        <li>
<!-- notify IANA regarding the "Transform Type Values" registry.</t></li>

          <li><t>Added this note changes to the "Transform Type Values" registry:</t>

          <t>"Sequence notes displayed in the registries. -->
          <t>added the following note:</t>
            <blockquote><t>The "Sequence Numbers (SN)" transform type Transform Type was originally named
            "Extended Sequence Numbers (ESN)" and was referenced by that name
            in a number of RFCs published prior to [RFCXXXX], [RFC9827], which gave it
            the current title.
          </t> title.</t></blockquote>
        </li>

          <li><t>The
</ul>
<t>The "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry is renamed to has been updated as follows: </t>

<ul>

        <li>
          <t>renamed the registry from "Transform Type 5 - Extended Sequence Numbers Transform IDs".
          </t>
          </li>

          <li><t>The "Reserved" (2-65535) range of numbers in what was the IDs" to
          "Transform Type 5 -
          Extended Sequence Numbers Transform IDs" registry is split into the
          "Unassigned" (2-1023) and added this document as a reference.
          </t>
        </li>
        <li><t>split the "Reserved for Private Use" (1024-65535) ranges, "Reserved" (2-65535) range of numbers as shown below.
          </t>

          <figure align="center">
            <artwork align="left"><![CDATA[
Number      Name                        Reference
-------------------------------------------------
2-1023	    Unassigned
1024-65535  Reserved below.</t>

<table>
  <thead>
    <tr>
      <th>Number</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>2-1023</td>
      <td colspan="2">Unassigned</td>
    </tr>
    <tr>
      <td>1024-65535</td>
      <td>Reserved for Private Use	[RFCXXXX]
            ]]></artwork>
          </figure> Use</td>
      <td>[RFC9827]</td>
    </tr>
  </tbody>
</table>
          </li>

          <li><t>The existing

        <li>
          <t>renamed Transform ID 0 from "No Extended Sequence Numbers" in what was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry
          is renamed
          to "32-bit Sequential Numbers".
          </t></li>

          <li><t>The existing
          </t>
        </li>
        <li>
          <t>renamed Transform ID 1 from "Extended Sequence Numbers" in what was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry
          is renamed
          to "Partially Transmitted 64-bit Sequential Numbers".
          </t></li>

          <li><t>Appended [RFCXXXX]
          </t>
        </li>
        <li>
          <t>added a reference to the Reference column of this RFC for Transform ID 0 and Transform ID 1 in what was 1.</t>
        </li>
        <li>
          <t>added the
          "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry.</t></li>

          <li><t>Added these notes to what was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry:</t>

          <t>This following registry notes:</t>
          <blockquote><t>This registry was originally named "Transform Type 5 - Extended
          Sequence Numbers Transform IDs" and was referenced using that name
          in a number of RFCs published prior to [RFCXXXX], [RFC9827], which gave it the
          current title.
          </t>

          <t>"32-bit
          </t></blockquote>
          <blockquote><t>The "32-bit Sequential Numbers" transform Transform ID was originally named "No
          Extended Sequence Numbers" and was referenced by that name in a
          number of RFCs published prior to [RFCXXXX], [RFC9827], which gave it the
          current title.
          </t>

          <t>"Partially
          </t></blockquote>
          <blockquote><t>The "Partially Transmitted 64-bit Sequential Numbers" transform Transform ID
          was originally named "Extended Sequence Numbers" and was referenced
          by that name in a number of RFCs published prior to [RFCXXXX], [RFC9827], which
          gave it the current title.
          </t>

          <t>Numbers
          </t></blockquote>
          <blockquote><t>Numbers in the range 2-65535 were originally marked
          as "Reserved" and were re-classified reclassified as "Unassigned" and "Reserved
          for Private Use" by [RFCXXXX].
          </t> [RFC9827].
        </t></blockquote>
        </li>
      </ul>
    </section>
  </middle>

  <back>
<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEv2"/>
<displayreference target="I-D.klassert-ipsecme-eesp" to="EESP"/>
<displayreference target="I-D.pan-ipsecme-anti-replay-notification" to="ANTIREPLAY"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <reference anchor="IKEV2-IANA" target="http://www.iana.org/assignments/ikev2-parameters">
          <front>
            <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8750.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9347.xml"/>
<!--  [I-D.ietf-ipsecme-g-ikev2]
draft-ietf-ipsecme-g-ikev2-21
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-g-ikev2.xml"/>
<!-- [I-D.klassert-ipsecme-eesp]
draft-klassert-ipsecme-eesp-02
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.klassert-ipsecme-eesp.xml"/>
<!-- [I-D.pan-ipsecme-anti-replay-notification]
draft-pan-ipsecme-anti-replay-notification-01
expired -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.pan-ipsecme-anti-replay-notification.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false">
      <name>Acknowledgements</name>
      <t>This document was created as a result of discussions with Russ Housley, Tero Kivinen, Paul Wouters and Antony Antony <contact
      fullname="Russ Housley"/>, <contact fullname="Tero Kivinen"/>, <contact
      fullname="Paul Wouters"/>, and <contact fullname="Antony Antony"/> about
      the best way to extend the meaning of the Extended Sequence Numbers
      transform in IKEv2.
      </t>
    </section>

  </middle>

    <back>
    <references title="Normative References">
      <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"?>
      <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"?>
      <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"?>
      <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"?>
      <reference anchor="IKEV2-IANA"
                 target="http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml">
        <front>
          <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date />
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8750.xml"?>
      <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9347.xml"?>
      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-g-ikev2.xml"?>
      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.klassert-ipsecme-eesp.xml"?>
      <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.pan-ipsecme-anti-replay-notification.xml"?>
    </references>

  </back>

<!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. We updated to use the form on the left to align with RFC 7296.  Please let us know any objections.

Transform Type vs transform type
Transform ID vs transform ID
-->

<!-- [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.
-->

</rfc>