<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.0.2) -->


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

<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.ietf-ipsecme-diet-esp SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-diet-esp.xml">
<!ENTITY RFC7296 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC4301 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
]>


<rfc ipr="trust200902" docName="draft-ietf-ipsecme-ikev2-diet-esp-extension-03" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="EHC extension">Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP)</title>

    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>
    <author initials="T." surname="Guggemos" fullname="Tobias Guggemos">
      <organization>LMU</organization>
      <address>
        <email>guggemos@nm.ifi.lmu.de</email>
      </address>
    </author>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="W." surname="Atwood" fullname="J. William Atwood">
      <organization>Concordia University</organization>
      <address>
        <email>william.atwood@concordia.ca</email>
      </address>
    </author>
    <author initials="D." surname="Liu" fullname="Daiying Liu">
      <organization>Ericsson</organization>
      <address>
        <email>harold.liu@ericsson.com</email>
      </address>
    </author>
    <author initials="S." surname="Preda" fullname="Stere Preda">
      <organization>Ericsson</organization>
      <address>
        <email>stere.preda@ericsson.com</email>
      </address>
    </author>
    <author initials="M." surname="Hatami" fullname="Maryam Hatami">
      <organization>Concordia University</organization>
      <address>
        <email>maryam.hatami@mail.concordia.ca</email>
      </address>
    </author>
    <author initials="S." surname="Céspedes" fullname="Sandra Céspedes">
      <organization>Concordia University</organization>
      <address>
        <email>sandra.cespedes@concordia.ca</email>
      </address>
    </author>

    <date year="2025" month="January" day="26"/>

    <area>Security</area>
    <workgroup>IPsecme</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 61?>

<t>This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rules Generation. 
This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP.</t>



    </abstract>



  </front>

  <middle>


<?line 66?>

<section anchor="requirements-notation"><name>Requirements notation</name>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
<?line -6?></t>

</section>
<section anchor="introduction"><name>Introduction</name>

<t>The ESP Header Compression Profile (EHCP) <xref target="I-D.ietf-ipsecme-diet-esp"/> minimizes the overhead associated with ESP by compressing both the ESP header and additional fields within the secured packet. EHCP utilizes Attributes for Rules Generation (AfRG) that are specified for each Security Association (SA). Certain AfRG have already been established during the SA negotiation process through IKEv2. This extension facilitates the agreement on the remaining AfRG through IKEv2.</t>

</section>
<section anchor="protocol-overview"><name>Protocol Overview</name>

<t>As illustrated in <xref target="fig-overview"/>, an initiator intending to utilize the Header Compression Profile (HCP) informs its peer by sending a HCP_PROPOSAL Notify Payload during the IKE_AUTH and CREATE_CHILD_SA exchanges. The HCP_PROPOSAL includes a list of Proposals, each comprising an EHCP Name along with a set of Attributes for Rules Generation (AfRG)<xref target="I-D.ietf-ipsecme-diet-esp"/>. Any AfRG for which the initiator wishes to specify no limitations SHOULD be excluded, i.e., an AfRG is only sent if the sending peer wants the receiving peer to select a subset of the available values. A given AfRG MAY be repeated with different values in order to provide a list of acceptable values. A range of possible AfRG values MAY be indicated as well.</t>

<t>If a Proposal contains an unknown HCP Name, or any AfRG in a Proposal is unknown, then the entire Proposal must be discarded by the responder. If none of the received Proposals are deemed acceptable, the responder MAY choose to discard the HCP_PROPOSAL Notify Payload. Nevertheless, it is anticipated that the responder will provide an explanation for rejecting all HCP Proposals. If the reason pertains to an AfRG with an unacceptable value, the responder SHOULD reply with a
NO_PROPOSAL_CHOSEN Notify Payload.</t>

<t>Conversely, if the receiver identifies a suitable Proposal, it will respond with an HCP_PROPOSAL Notify Payload that includes the chosen Proposal. In cases where the AfRG was not explicitly stated, the responder will provide the AfRG unless it defaults to a standard value. Each AfRG MUST NOT be mentioned more than one time. When multiple values are provided for a specific AfRG (either multiple values being provided or via a range of acceptable values), the responder MUST NOT provide more than one value. The Proposal MUST NOT contain any range of AfRG.</t>

<t>Upon receipt of an NO_PROPOSAL_CHOSEN Notify Payload, the initiator has the option to restart the CREATE_CHILD_SA exchange.</t>

<t>When the initiator receives the HCP_PROPOSAL_CHOSEN Notify Payload, it will evaluate the Proposal to ensure that it aligns with the initial proposal and adheres to its policies prior to executing the HCP.</t>

<figure title="The parameters for Diet-ESP have been established through the HCP_PROPOSAL_CHOSEN Notify exchange. In this instance, the responder has opted for the second Proposal, which includes the specified Attributes for Rules Generation (AfRG). Any absent AfRG will default to its predetermined values." anchor="fig-overview"><artwork align="center"><![CDATA[
Initiator                         Responder
-------------------------------------------------------------------
HDR, SA, KEi, Ni -->
                           <-- HDR, SA, KEr, Nr
HDR, SK {IDi, AUTH,
     SA, TSi, TSr,
     N(HCP_PROPOSAL
         Proposal_ID=1, HCP Name="Diet-ESP"
           AfRG_a
           ...
           AfRG_i
         ...
         Proposal_ID=2, HCP Name="Diet-ESP"
           AfRG_a
           ...
           AfRG_j)
                           <-- HDR, SK {IDr, AUTH,
                                    SA, TSi, TSr,
                                    N(HCP_PROPOSAL
                                      Proposal_ID=2, HCP Name="Diet-ESP"
                                        AfRG_a      
                                        ...
                                        AfRG_j, 
                                        AfRG_k, 
                                        ...
                                        AfRG_u)
]]></artwork></figure>

</section>
<section anchor="hcpproposal-notify-payload"><name>HCP_PROPOSAL Notify Payload</name>

<t><xref target="fig-notify"/> describes the HCP_PROPOSAL Notify Payload.</t>

<figure title="Notify Payload" anchor="fig-notify"><artwork align="center"><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol ID  |   SPI Size    |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The fields Next Payload, Critical Bit, RESERVED, and Payload Length are defined in section 3.10 of <xref target="RFC7296"/>.</t>

<dl>
  <dt>Protocol ID (1 octet):</dt>
  <dd>
    <t>set to zero.</t>
  </dd>
  <dt>SPI Size (1 octet):</dt>
  <dd>
    <t>set to zero.</t>
  </dd>
  <dt>Notify Message Type (2 octets):</dt>
  <dd>
    <t>Specifies the type of notification message. It is set to TBA1 for HCP_PROPOSAL_CHOSEN.</t>
  </dd>
</dl>

<t>When sent by the Initiator, the HCP_PROPOSAL Notify Payload contains a list of Proposals described in <xref target="fig-proposal"/>. When sent by the responder the HCP_PROPOSAL Notify Payload contains a single Payload described in <xref target="fig-proposal"/>.</t>

<figure title="Proposal" anchor="fig-proposal"><artwork align="center"><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Proposal ID  |   HCP Name   |      Proposal Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                          Proposal Data                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<dl>
  <dt>Proposal ID (1 octet):</dt>
  <dd>
    <t>The number identifying the Proposal.</t>
  </dd>
  <dt>EHCP Name (1 octet):</dt>
  <dd>
    <t>The identifier of the EHCP Name. (see <xref target="tab:hcp-name"/>)</t>
  </dd>
  <dt>Proposal Length (2 octets):</dt>
  <dd>
    <t>The length in octets  of the Proposal Data</t>
  </dd>
  <dt>Proposal Data:</dt>
  <dd>
    <t>A Proposal contains a set of parameters that are represented via Transform Attribute format <xref section="3.3.5" sectionFormat="comma" target="RFC7296"/> and detailed further as described in <xref target="sec-parameters"/>.</t>
  </dd>
</dl>

</section>
<section anchor="sec-parameters"><name>Attributes for Rules Generation</name>

<t>Attributes for Rules Generation (AfRG) follow the same format as the Transform Attribute <xref section="3.3.5" sectionFormat="comma" target="RFC7296"/> copied for convenience in <xref target="fig-attribute"/>.</t>

<figure title="Transform Attribute Payload" anchor="fig-attribute"><artwork align="center"><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|       Attribute Type        |    AF=0  Attribute Length     |
|F|                             |    AF=1  Attribute Value      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   AF=0  Attribute Data                        |
|                   AF=1  Not Transmitted                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>There exist two categories of attributes: 1) generic attributes, which are applicable across all HCPs and serve to enhance the representation of a combination of AfRGs, and 2) AfRGs that are tailored to a particular HCP and possess a distinct value.</t>

<section anchor="generic-attributes"><name>Generic Attributes</name>

<t>This specification defines range_afrg_proposal as a Generic Attribute for Rules Generation to specify that a given AfRG can be selected within a range of values.</t>

<t><list style="symbols">
  <t>Designation: range_afrg_proposal</t>
  <t>Attribute Format: 0</t>
  <t>Attribute Data: Let AfRG_min and AfRG_max be the minimum and maximum values of the proposed range, expressed following the Transform Attribute Payload format. The corresponding Attribute Data is the concatenation of AfRG_min and AfRG_max.</t>
</list></t>

<t>To avoid ambiguity, it is explicitly required that both AfRG_min and AfRG_max refer to the same type of parameter and that they are processed as attributes with values defining the minimum and maximum of the range. This ensures consistent interpretation during negotiation and compression.</t>

<t>The figure below illustrates a Proposal for a compressed SPI between 6 and 8 bit long. SPI are compressed by sending LSB, so in our case AfRG_min is an esp_spi_lsb AfRG set to 6 and AfRG_max is a esp_spi_lsb set to 8.  The esp_spi_lsb AfRG is detailed in the Diet-ESP EHCP <xref target="sec-diet-esp-ehcp"/> and is a 2 byte length Attribute. The resulting range proposal is expressed via the combination of the range_afrg_proposal and AfRG_min and AfRG_max.</t>

<figure title="Illustration of the use of the range_afrg_proposal defining a range of SPI length" anchor="fig-range_afrg_proposal"><artwork align="center"><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|       afrg_range_proposal    | Attribute Length = 4 octets  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|           esp_spi_lsb        | Attribute Value = 6          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|           esp_spi_lsb        | Attribute Value = 8          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

</section>
</section>
<section anchor="sec-reg"><name>Registering a Header Compression Profile</name>

<t>An HCP needs to register an HCP Name taken from <xref target="tab:hcp-name"/> in <xref target="sec:hcp-name"/>, the specification that describes the operations of the EHCP, as well as the different AfRG. For each AfRG, the corresponding Attribute Type, the AF value, the Attribute Data or Attribute Value and the Default Value MUST be specified.</t>

</section>
<section anchor="sec-diet-esp-ehcp"><name>AfRG for the Diet-ESP HCP</name>

<t>This section defines the code points that are needed to agree on the AfRG between two IKEv2 peers as described in <xref target="sec-reg"/>.</t>

<t><list style="symbols">
  <t>HCP Name: "Diet-ESP" as specified in <xref target="tab:hcp-name"/>, <xref target="sec:hcp-name"/>.</t>
  <t>Specification : <xref target="I-D.ietf-ipsecme-diet-esp"/></t>
</list></t>

<t>The following Attributes for Rules Generation are defined:</t>

<t>DSCP Compression/Decompression Action (CDA)</t>

<t><list style="symbols">
  <t>Designation: dscp_cda</t>
  <t>Attribute Format: 1</t>
  <t>Attribute Value: DSCP CDA takes discrete values coded over one byte as described in DSCP CDA Value Registry  (<xref target="tab:dscp_cda"/> in <xref target="sec:dscp_cda"/>)</t>
  <t>Default Value: the default value is set to "uncompress"</t>
</list></t>

<t>ECN Compression/Decompression Action (CDA)</t>

<t><list style="symbols">
  <t>Designation: ecn_cda</t>
  <t>Attribute Format: 1</t>
  <t>Attribute Value: ECN CDA takes discrete values coded over one byte as described in the ECN CDA Value Registry (<xref target="tab:ecn_cda"/> in <xref target="sec:ecn_cda"/>)</t>
  <t>Default Value: the default value is set to "uncompress"</t>
</list></t>

<t>Flow Label  Compression/Decompression Action (CDA)</t>

<t><list style="symbols">
  <t>Designation: flow_label_cda</t>
  <t>Attribute Format: 1</t>
  <t>Attribute Value: Flow Label CDA takes discrete values coded over one byte as described in the Flow Label CDA Value Registry (<xref target="tab:fl_cda"/> in <xref target="sec:fl_cda"/>)</t>
  <t>Default Value: the default value is set to "uncompress"</t>
</list></t>

<t>ESP Byte Alignment</t>

<t><list style="symbols">
  <t>Designation: alignment</t>
  <t>Attribute Format: 1</t>
  <t>Attribute Value: Byte Alignment takes discrete values coded over one byte as described in the Bit Alignment Value Registry (<xref target="tab:align"/> in <xref target="sec:align"/>)</t>
  <t>Default Value: the default value is set to "64 bit", which corresponds to the standard IPv6 bit alignment. The default value of 64 bit in this specification refers to the bit alignment used for Diet-ESP compression operations and does not override or contradict the alignment requirements of RFC 4303. Instead, the alignment specified here ensures compatibility with the SCHC compression framework, which is designed to operate efficiently in constrained networks.</t>
</list></t>

<t>Security Parameter Index (SPI) Least Significant Bits (LSB)</t>

<t><list style="symbols">
  <t>Designation: esp_spi_lsb</t>
  <t>Attribute Format: 1</t>
  <t>Attribute Value: SPI LSB designates the number of bits that are provided to infer the SPI. This number is between 0 and 32.</t>
  <t>Default Value: the default value is 32, which is the size of the standard SPI in the standard ESP</t>
</list></t>

<t>Sequence Number (SN) Least Significant Bits (LSB)</t>

<t><list style="symbols">
  <t>Designation: esp_sn_lsb</t>
  <t>Attribute Format: 1</t>
  <t>Attribute Value: SN LSB designates the number of bits that are provided to infer the SPI. This number is between 0 and 32.</t>
  <t>Default Value: the default value is 32, which is the size of the standard SN in the standard ESP</t>
</list></t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="registration-of-ikev2-notify-message-types"><name>Registration of IKEv2 Notify Message Types</name>

<t>IANA has allocated one value in the "IKEv2 Notify Message Types - Status Types" registry:</t>

<figure><artwork><![CDATA[
  Value    Notify Messages - Status Types
-----------------------------------------
  TBA1    HCP_PROPOSAL
]]></artwork></figure>

<t>This specification requests the IANA to create a  Header Compression Profile registry (see <xref target="sec:hcp-name"/>), as well as the necessary registries for the ESP Header Compression Profile Diet-ESP, that is the Attribute for Rules Generations (see <xref target="sec:afrg"/>) as well as, when required, the complementary specific AfRG Values associated with each AfRG (see <xref target="sec:afrg-val"/>).</t>

<t>Note that the term "Header Compression Profile" reflects the purpose of the registry, which is to define profiles for ESP header compression using the Diet-ESP methodology. While the registry is managed and utilized exclusively by IKEv2 for negotiating compression parameters, its scope is limited to ESP header compression and does not extend to IKEv2 itself.</t>

<t>All registries are "Specification Required".</t>

</section>
<section anchor="sec:gen-afrg"><name>Registry for Generic Attributes for Rules Generation</name>

<t>Registry for Generic Attributes for Rules Generation. When Associated Data is set to YES, the AF bit of the corresponding Transform Attribute Payload is set to 0; otherwise it is set to 1. The AfRG Code Point mentioned here MUST NOT be reused by any Registries associated with any Profile and is shared by all profiles.</t>

<texttable anchor="tab:gen-afrg">
      <ttcol align='left'>AfRG Code Point</ttcol>
      <ttcol align='left'>Full Name</ttcol>
      <ttcol align='left'>Designation</ttcol>
      <ttcol align='left'>Attribute Format</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>65535</c>
      <c>RANGE AfRG</c>
      <c>range_afrg_proposal</c>
      <c>0</c>
      <c>ThisRFC</c>
</texttable>

<t>Each entry in the range is represented by two attributes (AfRG_min and AfRG_max), both following the 2-byte Attribute Type format specified in <xref target="RFC7296"/>. This ensures clarity and compatibility in all implementations.</t>

</section>
<section anchor="sec:hcp-name"><name>Registry for IKEv2 Header Compression Profile</name>

<texttable anchor="tab:hcp-name">
      <ttcol align='left'>Value (1 Byte)</ttcol>
      <ttcol align='left'>Designation</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>0</c>
      <c>Diet-ESP</c>
      <c>ThisRFC</c>
      <c>1-255</c>
      <c>unallocated</c>
      <c>-</c>
</texttable>

</section>
<section anchor="sec:afrg"><name>Registry for Diet-ESP Attributes for Rules Generation</name>

<t>Registry for Attributes for Rules Generation for the ESP Header Compression Profile Diet-ESP. When Associated Data is set to YES, the AF bit of the corresponding Transform Attribute Payload is set to 0; otherwise it is set to 1.</t>

<t>The Diet-ESP Attributes for Rules Generation registry specifies six AfRG parameters explicitly defined for Diet-ESP that are not part of the standard IKEv2 negotiation process. These attributes are required for implementing the Diet-ESP Header Compression Profile. The remaining attributes referenced in <xref target="RFC7296"/>, <xref target="RFC4301"/>, and related drafts (e.g., DSCP values) are already defined and negotiated during the creation of the CHILD SA.</t>

<texttable anchor="tab:afrg">
      <ttcol align='left'>AfRG Code Point</ttcol>
      <ttcol align='left'>Full Name</ttcol>
      <ttcol align='left'>Designation</ttcol>
      <ttcol align='left'>Attribute Format</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>0</c>
      <c>DSCP CDA</c>
      <c>dscp_cda</c>
      <c>1</c>
      <c>ThisRFC</c>
      <c>1</c>
      <c>ECN CDA</c>
      <c>ecn_cda</c>
      <c>1</c>
      <c>ThisRFC</c>
      <c>2</c>
      <c>Flow Label CDA</c>
      <c>flow_label_cda</c>
      <c>1</c>
      <c>ThisRFC</c>
      <c>3</c>
      <c>Alignment</c>
      <c>alignment</c>
      <c>1</c>
      <c>ThisRFC</c>
      <c>4</c>
      <c>SPI LSB</c>
      <c>esp_spi_lsb</c>
      <c>1</c>
      <c>ThisRFC</c>
      <c>5</c>
      <c>SN  LSB</c>
      <c>esp_spi_sn</c>
      <c>1</c>
      <c>ThisRFC</c>
      <c>6 - 2^16-2</c>
      <c>unallocated</c>
      <c>-</c>
      <c>-</c>
      <c>-</c>
</texttable>

</section>
<section anchor="sec:afrg-val"><name>Registries for the Values of Diet-ESP Attributes for Rules Generation</name>

<section anchor="sec:dscp_cda"><name>DSCP CDA Value Registry</name>

<texttable anchor="tab:dscp_cda">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Designation</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>0</c>
      <c>uncompress</c>
      <c>ThisRFC</c>
      <c>1</c>
      <c>lower</c>
      <c>ThisRFC</c>
      <c>2</c>
      <c>sa</c>
      <c>ThisRFC</c>
      <c>3-255</c>
      <c>unallocated</c>
      <c>-</c>
</texttable>

</section>
<section anchor="sec:ecn_cda"><name>ECN CDA Value Registry</name>

<texttable anchor="tab:ecn_cda">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Designation</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>0</c>
      <c>uncompress</c>
      <c>ThisRFC</c>
      <c>1</c>
      <c>lower</c>
      <c>ThisRFC</c>
      <c>2-255</c>
      <c>unallocated</c>
      <c>-</c>
</texttable>

</section>
<section anchor="sec:fl_cda"><name>Flow Label CDA Value Registry</name>

<texttable anchor="tab:fl_cda">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Designation</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>0</c>
      <c>uncompress</c>
      <c>ThisRFC</c>
      <c>1</c>
      <c>lower</c>
      <c>ThisRFC</c>
      <c>2</c>
      <c>generated</c>
      <c>ThisRFC</c>
      <c>3</c>
      <c>zero</c>
      <c>ThisRFC</c>
      <c>4-255</c>
      <c>unallocated</c>
      <c>-</c>
</texttable>

</section>
<section anchor="sec:align"><name>ESP Byte Alignment</name>

<texttable anchor="tab:align">
      <ttcol align='left'>Value</ttcol>
      <ttcol align='left'>Designation</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>0</c>
      <c>8 bit</c>
      <c>ThisRFC</c>
      <c>1</c>
      <c>16 bit</c>
      <c>ThisRFC</c>
      <c>2</c>
      <c>32 bit</c>
      <c>ThisRFC</c>
      <c>3</c>
      <c>64 bit</c>
      <c>ThisRFC</c>
      <c>4-255</c>
      <c>unallocated</c>
      <c>-</c>
</texttable>

</section>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>The protocol defined in this document does not modify IKEv2.</t>

<t>Proposals may be expressed in various ways and a proposal may be expressed in a specific way so that its treatment overloads the receiver. The receiver needs to consider aborting the exchange when too much resource is required.</t>

</section>


  </middle>

  <back>


    <references title='Normative References' anchor="sec-normative-references">

&RFC2119;
&RFC8174;
&I-D.ietf-ipsecme-diet-esp;
&RFC7296;
&RFC4301;


    </references>




  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA9U823bbSHLv+IqO/CJtSESkbI2HWe+aFmVLGVlWRHnm7Et0
mkCT7DEIcNGAZI5lf0te8xvJj6Wq+oIGwYtkKTlezpkZstFdXV33S0Ptdjso
ZJGIHjtNC5GnomC/iAU7/hxNeToR7EbkSmYp67Ld01+Ob7p7THwuREpj4yxn
J4LHImdH2WyeC0XDF3k2lolguydHF3ss4KNRLm567PjkqFobxFmU8hlsG+d8
XLSlKMZtOVcimom2/CRuuu0YxtpCzdtuUXv/IJDzvMeKvFRFd3//5/1uwHPB
e2woojKXxSK4ncBJLghO8Om2OlV7gPsEES96TBVxoApYN4Pnx1dvg2AuewFj
RRb12EIo+KqyHCaMlfu9mFU/A14W0yzHJW34lzGZwpNByN7LCS+Tgsb06QY8
lSKpPchyQPE4l5FSQAccETMuE6AEzQ1neu5rYaaEUTar73QVsnflZCJmmfK2
uspGkqv6E9rr7P1Hf5uJmfA6nYVyLMNkVoaxqO+AhxlGU5nyP6S3BRznRsb1
J7TFuyybAMfPzo5qB1JmYojsfT3B0eZpfgtZv7jNstjb6N9C9ptMEsln/jPa
6ihLoyyPJWcfU0nSCVz3Nr3V60JO615HdnoY8Qa/zmRZ45VcyHTiRtcyasrz
LInDRJYbmDQMQRFEzL0NhiCKwhtdu4HCieEcJ27Y4X3ITnjBZz6H3vN8AUTz
xu9FtBktC6e07LXh0zrCwcmO/ue/1FzEwpe/IU9Bl5ce3Wt3RSvDSOiFdZ7B
p91uMz4CjeVREQRXU6kYmI9yJtKCwfwolyOhGE8ZWajtBqrIGJ/kQjD43i8K
WF4WAABnX5YJfHsnUpHzAuaGTO9XwYzFWKYwp5gKlgrAWQHtWC4mEhCUBgw+
PB5ebLSOx2QeB2jlYCpsROecyThOBBz6GWOX4u+lzAWeU7E0KwgjJIBgn8BG
3wKNFNt5/3F4tdPS/2fnH+j75fG/fzy9PB7g9+FJ/+zMfQnMjOHJh49ng+pb
tfLow/v3x+cDvRhGWW0o2Hnf/xs8AZaxnQ8XV6cfzvtnOyAYcGafL2CWkc4j
AY9AmuH4hYgZV4FlWIxr3hxd/Pd/dp6zL1/+6fLtUbfT+fnrV/PjZeen5/Dj
dipSvVuWJgvzE8i7CPh8LniOUHiSsIjPZcETBXMVU9PsNmVTVKLgz39NgF+s
ffjXvxBVwSHkWVxGFS3vxyjA6rQ9CGuOyroowHMmUzmTfxjByEDKpwASkFFZ
JDme/VYWU9prtGCR3QfMzSiDcSswU40HnpfHsUQkecLG4BeA1QiBCC2YQn8H
QOc8+iSKEJ3rBSsLmRAKW4Sa7fbHl+/2ABDXjAK9i8AVADycLng0dQ6V9c0J
aN2wvwfKL/KCAx4IBGzhjQAGgDONF8BtkTKhCj5KpJoCuBhgwBER42Ef1GWS
FQbUPM9Qd+BRnpWTqVbdkC0p25hHcCQQfENXUluSr0zTIUcTkuIehE0dGrIb
uAhuPUvYB2DJjRS3QdBXDHxEifak0GL45ctYTtqZmfH1KwocjEtENstJgtOY
DpJZItPuW4MfmQJBZ7AfKPBcwFTgvTKwOIMp1xeXHy4+DPtn7BxIM16wC75I
Ml6jHBzmuv/x6oSk4ujyuH91fH10cno2uAaaChOoKaSdqIOUaZSUMZpGBvwA
mo0RvXmmSE+IzSSIkuQQjkxSdA7WHDiawRCJLAeMae39pGqznoCvTxeaVwjj
diojLfwVtW9RdBSSWovlAkwf4D+T2v4pZgwWmBY4PB4wbjEZipC4RqBBhsha
KJQUOTYao8lObLjlaFK1AEVC3rgHuKtIRFTgscuROTmJ3g34KhBsCIl5UiK9
+2wC3sxsCVYRMcoFGCWn7bEcj8EIARJ6DcoaGG29D2gABFPCYw6PIjEvlvbI
KQyHp8A3JfEZ7WcAmm0lnC3i2sKyW5EkIPunANDxGxidotKSmyzTTykaSMvt
FiAF44YvaFCrdUBKM53MrtY6OJGkSMZMmoEyIRqxVBGH88Uo55q6ap6lcOCQ
ATpplgpLTk13mOkkkixRjOode5Ro1eHQgaNplilyL2ZDrYzrtSlk5wKUG2aB
yILoywLPBTIgIzknspEprO+EgWTFJLBrn+cJT7Woo+zm4neQE9IcmIi0dEeh
02poXKGx0xaThNrKqNYtZMYy25ePbOQdRAsdIC0DL+7OCrbgw/D4fPnIQQBh
FwZbIlm0rBIYqoNJi5GHY0nGQZVSb28PQBSi8xssHLabTBbR0Nkc3A4YBWrn
wAJZUnDUCp7eonOmOZoYnAIcojHwpEDdRasfL9OixhS3vEyRr4g0RGeYPGlK
I4w0RvkguoKXRJOn1dUESyi16E+AqSAFs4yQgnOipBZyBmt+Q6GfAUw5d3pJ
omqw0D6TWx8aafi7AggG+C4vHAkyNXYprLyBsJhXWt6wAXsNDbCoWzLUsTZH
RWfg9NMtMVaAlN1tiQiDuHwE+FpA5toapWyrlLWWbPeUm/hnXphAO8dwINe6
tc53wea/WdNSwTKyqhrKvQ4VK7MCSQDCQwsdDQAXCCpKTaoCJ/NETlIdVXlb
k3jpJToKQ0kleSInnqF8wm/wmhmZcfEZIqXC+mrAE07z7du34NQdZN3n0rIU
A//HfoKTwWULgqwW++VYtti5ZO32X4K1ezP2Z0g2vDU5rMkNkF/Yl9MBAMGg
o6Vh4KSrocT/5GbofNdnSrWVpfj16eBVp+WczKsdm+rs+Gih8F1zfyQMw8YE
Gax+7O/VfaK9ft+7H9mISnmNSls+K4i45bOOxhs/DyPKxo+mmP5+70VLRN2+
we+t+wOnBZ8esODB2JR7pL9feuyZnxWAzS8g4/7UJrPxaicSmNfuMKqevtpB
ezvnOdAZRnWAbMmtc6RGbmRzlS3mzRlJdJ6UY0MgAX4tasQJaHzB8BqPZLJE
dN6VW9fxds1HV7nf/eJ7HcHzEcXWJpIBo2scr7OTkJwiJSAtFrGNZne+BpSC
bwgigkDnYimNQl5d1Xe2xXiBtrtsn3VYlx2w5+wFO2Q/sZfs54eMBf/cfuQ/
wR2Em58LFxexu6M7sPbHw+PLX48HIGZ3TuDslDORTsALmc/dk+BQpb6nA73n
8OKUDTF3rXAwNHyPZSyIBq4Wc/F0OPhqpBm6RYnqHEVxQbUy1Q+fpi12lIN7
jcBJv5FFyxFXV4qWqKrzijFJIsQ+SlDthx2EnX2Mc3S56afuz4eQngaBT7Xd
DsuiQhR7vaBHWTBI9x8iz2Cao+WGOauIu9vV0xXNHxrl09Jd4IQM8yQMzSOt
dTO9GtSfkhazw9WbfkeXN5uWw4ZTpKEmEXPRSGubHnmZYrNqwGrVO62qNlzC
5L6xb2WdHrAtliMwG7GlkM17/kBqX0WbVuVcQcVpnJtS1/mnU/tHfe6Cb+sf
OtQHvODrJn17Ahye1vRU8fxG42NPB2aHBT4jaxqOBiktZ6Mqh17Y2L9Kc4Og
qqRVq5lZ7nLv3BZD3OyQ7SohQMghTOhNo3kbWytfv+6xIFiWm7ohQbiJfoA1
JnrALPga3zxI+BMX91eViWzVzwtqXL04F1jvRPLFlL9eQS6psNJZxRBonGYw
vbKuLawpG8t7EL4A3462GqIELhOMWcqcMmbeMDJgsNsVFmSkn20NVr48W1oG
4cE9y+LjLEmyWx0cIQfNSUxqu+qsmw4ZZXNbWI+wIJNKAbFbZcq4hUIH+1FM
Wd8qcXXIKjYwtqz/9tW+P8EzaHfB3dvNZsBC6PgQfsU48emMwCoMlpHeZMru
1kHoUOCkRWEmC1SD/x9T5oRlWzayQkjrUVWO1XN07wCGYel4klH3Egs/Tk16
rLPHJqggMvKGbR6BpoDPsWJH9Soe5ZlSthqqSL0VJE9C116mmLOYoMCYD612
uCU2IkYydQOoiUpHc909/asyP2gxMux+UZEPdBwiwTLhFAzREiyVY0GQY4G4
gHSnsGUxMB3PtMpjpc6dyHSVbQ1Po2E7vVQou+bjfHJduRIE3oCz2qx4nQx9
BL9vEPEUa5C66WD6BlSBd+U5kzwFwZ/YQCjgNkHtrUQL5lTIvCW71WP7tVEy
+qCrOnm7nlE1MDY/+GdEBnlE/cxyRs9gmL6bGqbxKnpTQJkQaWHtFptgZOvQ
gFq3uEEWjWnV1cooy020SO28uoZKU1DOUpTVupw0zoBsvgLRuMlkzDjI1aSU
xcKW/b0ac64b7KZ0TY3Y1UTJxVg3bZxTsLG68zC0wLYRFrZCHGmKoLhUzocq
joaYJGSWVKuIbvslugag+6NUx1RIDQXyTU0u22Q3oqu7h37DFWFGVaMytLnV
BEuiI4Eer+qKKr8FpOvbdi2cBnOfkShusaJxSIBfshEQF3uGIT3F03sLvK7n
2fBNi6mMopQyp25ARXNqyjAQgms1l9eJGmkdMTnPYZ0nOLk210x7GTKSpwYY
vJ5gow3TRnclGorAdKhR3TuDAMxEKbRXF85RuDDLCaiWXjgplvrhhFpx514D
rdIMDJa0HNesnWPwspVx510h4T9KqLBvnSThro/hTkCevhEivAI8bIz6JI6+
4ztqn/Eu2lgOMl4BGZ7UTX8XDi+fFodarLBSoDZGDadW/z2xLJXYJKHOfHkO
Cw2AVhIq+D1jl3Q5SuTm1sP6SxM6aM/FBNb1dX86FSJWupGkgZgupE6uCv4J
bNA4z2aNnMnlDt5Yy694Gi9PJrteZczmxnUrP0Fr2d66zQSq7j510NDf6ksV
+LNl9Hy1T8NYWs/ov/WbvkteDwAuy4z2MvDc1Fv1KDX4Rl4xNyTCu3sWNVtH
pu5Z09QxGwWZDMa/6RZlMdi0TOprEyYOQ96YKMxep3MtWesfMLzU1/LwfoVa
k94hy79SiGNZ22NVu4KudLkyNS2q87rV4HSIodCwxujelitcxiG62GVbtuiV
FSG1DwZDwNwT6n8ZCM/dsr6m6e7RoL/XCOViFc2vo5ivDN86tVHid4/p3QZ9
0gBF9yDwhp2NKpBdMd1Co54w+a1lyjsQWoS0kuYLxnY1eS1SvipVY3t0Bk8G
e1onzBDh4dUrd8rUUmMHyyNH599LKxGlDyMV7fUoSpEFMFCWiGVoZZDySeWG
HkeptxiYnXEI0Nj3UmwMIK4TBPEwwnlbP55+S8BWk3GcLFPRjjxS3MDqvUHM
+uj38L5Hg0jcPbk3feoQH0mfNxA/V7BWk4dw9KljBh5KnMPnGK7v2DS+clLK
pTj24szpxc0hxfaOPjrcrcMGL6lhunvAdR9L6ZMDXgOHAUZcb5f6gu25YqoW
ZkJfFEKC5nj5RZfVIGiJZaRvmVSgc//+NOB4+faIPT/YP8BWKoQS9vpKtaBy
MrpA4vKs2RyQGOFV1EV1X2R4dHJUQ3aMqSDGV67RSowG6NpL6sMA3PEYL5Gk
mIICwTCNgwNQfyoVFKBhuu9u4F64FPM0jcVntgsB1h6E0lwVbAjAic6A/Rts
vO5CgrXCaFbh6P3lG+M4gGaO4O7gmuo30HMk/WjAXWrCFnA6Ni0fAGKyVls1
Vy422CeeHnTJWd9HgA+6HmVJTrEDZ2I0J7OIt70mbcdArpCify+p+HquUdkd
nn8PHdMHkvH8H5OK56uJSHfo++d9fKtDAaZGPQOqrBmL5TIIHfmt6IMqsMoE
BS8tcAi59O1Vd4HN7r2zAUKbDQtelEr/3LHvYCx6Jjeuysn15csr73/9CmBS
45WxWiuTtltVQUQDJJS5aUzHBa6Ce0AjwNmmTCh3pl/3g+rR7V4jF3nMmyjW
8LbMzTi1lIqsin6VjximhNikqnBq0Ysarr5mk6HZPCFrjHjW70v+au5VLr0u
4dKp5e3aN9j83cM6CDBXVPd38c4J21l/WhSTMdZa9SnnZY5FzOpWsia7ryCZ
ifJRNRGCpqv3sobvAkpla3nOnYHpnmZxlmSTBTbIkeL+VrjHjKcglzEpsnm/
INaX25W8EeAlRgujSri1q+rBTv7eVbOrRXdwVAQOB8HT5XltUtagXfOt9PoF
zdZ7AiyRjMEj9elCsBMvNFc79RzLvLEU74SM1SzCgjBvFt43NO96E5G2SbQA
1PeAMdcR+pVM2VKyCYT+djx0STgGJUYI6kn7pvJ1BWr/X1mG7ctbCcIk/Zsa
HR0wkRAfYRZ9gVm0d+mYQg3/PnIuSlM0xWu6lx7Bl7QDH1slNlVKNeW5Wasv
SpPEYjXgjjVwuGNvS5hl7idQicp3d42qlXZzMHQpqPARieCuaSQbQ/eZszyK
6B6+eHHwwm+mscv++btjfQw9sKokZSfvN7tx5EIhCqQaGUbUTsQgR0BTA0zJ
F9b36IIWENVvd+O9ltvMr+bvrqzQgommfkK9F9JtUwKw1FQ1DealEod3K2mp
7J9wigttRb8KTc27cNLZWTLVYVMRtWJvq8RVHofkR7vT3Q4lPntATV9WPKGA
7025uFv7i7qs+0uMctbTZxszLdlOu/vihTe5TKsIAh63q5Kq5bN3kGVSuJ3u
Z5RWGqRtSx/oiH8Uw6UrYvcmkPNoyt1qU/KzVlfvFonXf7O38mp8qMqL4Iuw
udsITbX0rnibkEwtnMPTTn1dxbT5cB+nHA1HvZ4ztsVj3zX04OdW6hta2zK/
IOPs6FcKY5idED/pjx6A6RDhJGzpSpx520M31c37lJY+uNQet/5WJQWTXrme
3q1gw374j2jwly32XVWjtAO2AOnN6Wyw82gsGg9tKc8NmFKdP2cL0G7j4VJ9
626p6nYfoAeNh1VByAzw+sAWoAyhPm88tXl9df7lZtV2qC8aTyFfXA1VpffG
9RBsd/c/Ooftrn3qm3Zm71C26xDMpzlKI84HGD/vOQA/R/rV3W34DodA2YgO
eJ+tr6vr+a6EHgT+dadNzvSebtRTICScje+XHainEncMhFTk7ld9WreapmrK
4U3D9zAOrDtueGLHlMoTe8dHYq0pq2tS2RL6j0+ph1CgOhUSYHNdXNPBFMED
9sPToZo20XpCars87aCahjflVwoWTHv+EKpaGmmpatT7rbJSwfz/Vp70XZjV
R/Lo2Dms5m2g40F3/TSPjqb8/ng6Wgo9q/4CxHKh70pf/tJvSXgvVtT/AIgr
J8yyGItv5g88VNePseyx0G/x2+sxAOQGcpusVOyWL3TJn1dXaVbN9168hSV4
s8i83qkY/oWnQv+xiBuRY9zrv/KP76Rf+a9Eu5sGkTkv46Msd2GifQ9LV7aK
LGOzEjJGwCQr88jkiTrOxHQ7+F8icWsAWksAAA==

-->

</rfc>

