Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP)
draft-ietf-ipsecme-ikev2-diet-esp-extension-07

IPsecme                                                       D. Migault
Internet-Draft                                                  Ericsson
Intended status: Standards Track                               M. Hatami
Expires: 19 August 2026                             Concordia University
                                                                  D. Liu
                                                                S. Preda
                                                                Ericsson
                                                               W. Atwood
                                                             S. Céspedes
                                                    Concordia University
                                                             T. Guggemos
                                                                     LMU
                                                             D. Schinazi
                                                              Google LLC
                                                        15 February 2026

Internet Key Exchange version 2 (IKEv2) extension for Header Compression
                             Profile (HCP)
             draft-ietf-ipsecme-ikev2-diet-esp-extension-07

Abstract

   This document describes an IKEv2 extension for Header Compression to
   agree on Attributes for Rule Derivation.  This extension defines the
   necessary registries for the ESP Header Compression Profile (EHCP)
   Diet-ESP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 August 2026.

Migault, et al.          Expires 19 August 2026                 [Page 1]
Internet-Draft                EHC extension                February 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
   4.  HCP_PROPOSAL Notify Payload . . . . . . . . . . . . . . . . .   4
   5.  Attributes for Rule Derivation  . . . . . . . . . . . . . . .   5
     5.1.  Generic Attributes  . . . . . . . . . . . . . . . . . . .   6
   6.  Registering a Header Compression Profile  . . . . . . . . . .   7
   7.  AfRD for the Diet-ESP HCP . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Registration of IKEv2 Notify Message Types  . . . . . . .   9
     8.2.  Registry for Generic Attributes for Rule Derivation . . .  10
     8.3.  Registry for IKEv2 Header Compression Profile . . . . . .  10
     8.4.  Registry for Diet-ESP Attributes for Rule Derivation  . .  10
     8.5.  Registries for the Values of Diet-ESP Attributes for Rule
           Derivation  . . . . . . . . . . . . . . . . . . . . . . .  11
       8.5.1.  DSCP Action Value Registry  . . . . . . . . . . . . .  11
       8.5.2.  ECN Action Value Registry . . . . . . . . . . . . . .  12
       8.5.3.  Flow Label Action Value Registry  . . . . . . . . . .  12
       8.5.4.  ESP Byte Alignment  . . . . . . . . . . . . . . . . .  12
     8.6.  ESP Trailer . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Requirements notation

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Migault, et al.          Expires 19 August 2026                 [Page 2]
Internet-Draft                EHC extension                February 2026

2.  Introduction

   The ESP Header Compression Profile (EHCP) [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 Rule Derivation (AfRD) that are specified for
   each Security Association (SA).  Certain AfRD have already been
   established during the SA negotiation process through IKEv2.  This
   extension facilitates the agreement on the remaining AfRD through
   IKEv2.

3.  Protocol Overview

   As illustrated in Figure 1, 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 AfRD
   [I-D.ietf-ipsecme-diet-esp].  Any AfRD for which the initiator wishes
   to specify no limitations SHOULD be excluded, i.e., an AfRD is only
   sent if the sending peer wants the receiving peer to select a subset
   of the available values.  A given AfRD MAY be repeated with different
   values in order to provide a list of acceptable values.  A range of
   possible AfRD values MAY be indicated as well.

   If a Proposal contains an unknown HCP Name, or any AfRD 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 AfRD with an unacceptable value, the responder SHOULD reply
   with a NO_PROPOSAL_CHOSEN Notify Payload.

   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 AfRD was not explicitly stated, the
   responder will provide the AfRD unless it defaults to a standard
   value.  Each AfRD MUST NOT be mentioned more than one time.  When
   multiple values are provided for a specific AfRD (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 AfRD.

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

Migault, et al.          Expires 19 August 2026                 [Page 3]
Internet-Draft                EHC extension                February 2026

   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.

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"
           AfRD_a
           ...
           AfRD_i
         ...
         Proposal_ID=2, HCP Name="Diet-ESP"
           AfRD_a
           ...
           AfRD_j)
                           <-- HDR, SK {IDr, AUTH,
                                    SA, TSi, TSr,
                                    N(HCP_PROPOSAL
                                      Proposal_ID=2, HCP Name="Diet-ESP"
                                        AfRD_a
                                        ...
                                        AfRD_j,
                                        AfRD_k,
                                        ...
                                        AfRD_u)

     Figure 1: 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 AfRD.  Any absent AfRD will default to its
                        predetermined values.

4.  HCP_PROPOSAL Notify Payload

   Figure 2 describes the HCP_PROPOSAL Notify Payload.

      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      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Migault, et al.          Expires 19 August 2026                 [Page 4]
Internet-Draft                EHC extension                February 2026

                          Figure 2: Notify Payload

   The fields Next Payload, Critical Bit, RESERVED, and Payload Length
   are defined in section 3.10 of [RFC7296].

   Protocol ID (1 octet):  set to zero.

   SPI Size (1 octet):  set to zero.

   Notify Message Type (2 octets):  Specifies the type of notification
      message.  It is set to TBA1 for HCP_PROPOSAL_CHOSEN.

   When sent by the Initiator, the HCP_PROPOSAL Notify Payload contains
   a list of Proposals described in Figure 3.  When sent by the
   responder the HCP_PROPOSAL Notify Payload contains a single Payload
   described in Figure 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Proposal ID  |   HCP Name   |      Proposal Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                          Proposal Data                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 3: Proposal

   Proposal ID (1 octet):  The number identifying the Proposal.

   EHCP Name (1 octet):  The identifier of the EHCP Name (see Table 2).

   Proposal Length (2 octets):  The length in octets of the Proposal
      Data.

   Proposal Data:  A Proposal contains a set of parameters that are
      represented via Transform Attribute format [RFC7296],
      Section 3.3.5 and detailed further as described in Section 5.

5.  Attributes for Rule Derivation

   Attributes for Rule Derivation (AfRD) follow the same format as the
   Transform Attribute [RFC7296], Section 3.3.5 copied for convenience
   in Figure 4.

Migault, et al.          Expires 19 August 2026                 [Page 5]
Internet-Draft                EHC extension                February 2026

      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                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: Transform Attribute Payload

   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 AfRDs, and 2) AfRDs that are
   tailored to a particular HCP and possess a distinct value.

5.1.  Generic Attributes

   This specification defines range_afrd_proposal as a Generic Attribute
   for Rule Derivation to specify that a given AfRD can be selected
   within a range of values.

   *  Designation: range_afrd_proposal

   *  Attribute Format: 0

   *  Attribute Data: Let AfRD_min and AfRD_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 AfRD_min and AfRD_max.

   To avoid ambiguity, it is explicitly required that both AfRD_min and
   AfRD_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.

   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
   AfRD_min is an esp_spi_lsb AfRD set to 6 and AfRD_max is a
   esp_spi_lsb set to 8.  The esp_spi_lsb AfRD is detailed in the Diet-
   ESP EHCP Section 7 and is a 2 byte length Attribute.  The resulting
   range proposal is expressed via the combination of the
   range_afrd_proposal and AfRD_min and AfRD_max.

Migault, et al.          Expires 19 August 2026                 [Page 6]
Internet-Draft                EHC extension                February 2026

      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|       range_afrd_proposal    | Attribute Length = 4 octets  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|           esp_spi_lsb        | Attribute Value = 6          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|           esp_spi_lsb        | Attribute Value = 8          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 5: Illustration of the use of the range_afrd_proposal
                       defining a range of SPI length

6.  Registering a Header Compression Profile

   An HCP needs to register an HCP Name taken from Table 2 in
   Section 8.3, the specification that describes the operations of the
   EHCP, as well as the different AfRD.  For each AfRD, the
   corresponding Attribute Type, the AF value, the Attribute Data or
   Attribute Value and the Default Value MUST be specified.

7.  AfRD for the Diet-ESP HCP

   This section defines the code points that are needed to agree on the
   AfRD between two IKEv2 peers as described in Section 6.

   *  HCP Name: "Diet-ESP" as specified in Table 2, Section 8.3.

   *  Specification : [I-D.ietf-ipsecme-diet-esp]

   The following Attributes for Rule Derivation are defined:

   DSCP Action

   *  Designation: dscp_action

   *  Attribute Format: 1

   *  Attribute Value: DSCP Action takes discrete values coded over one
      byte as described in DSCP Action Value Registry (Table 4 in
      Section 8.5.1)

   *  Default Value: the default value is set to "not_compressed"

   ECN Action

   *  Designation: ecn_action

   *  Attribute Format: 1

Migault, et al.          Expires 19 August 2026                 [Page 7]
Internet-Draft                EHC extension                February 2026

   *  Attribute Value: ECN ACTION takes discrete values coded over one
      byte as described in the ECN ACTION Value Registry (Table 5 in
      Section 8.5.2)

   *  Default Value: the default value is set to "not_compressed"

   Flow Label Action

   *  Designation: flow_label_action

   *  Attribute Format: 1

   *  Attribute Value: Flow Label ACTION takes discrete values coded
      over one byte as described in the Flow Label ACTION Value Registry
      (Table 6 in Section 8.5.3)

   *  Default Value: the default value is set to "not_compressed"

   ESP Byte Alignment

   *  Designation: alignment

   *  Attribute Format: 1

   *  Attribute Value: Byte Alignment takes discrete values coded over
      one byte as described in the Bit Alignment Value Registry (Table 7
      in Section 8.5.4)

   *  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.

   ESP Trailer

   *  Designation: esp_trailer

   *  Attribute Format: 1

   *  Attribute Value: ESP Trailer takes discrete values coded over one
      byte as described in the Bit Alignment Value Registry (Table 8 in
      Section 8.6)

Migault, et al.          Expires 19 August 2026                 [Page 8]
Internet-Draft                EHC extension                February 2026

   *  Default Value: the default value is set to "Optional", which
      enables the ESP Trailer to be compressed.

   Security Parameter Index (SPI) Least Significant Bits (LSB)

   *  Designation: esp_spi_lsb

   *  Attribute Format: 1

   *  Attribute Value: SPI LSB designates the number of bits that are
      provided to infer the SPI.  This number is between 0 and 32.

   *  Default Value: the default value is 32, which is the size of the
      standard SPI in the standard ESP.

   Sequence Number (SN) Least Significant Bits (LSB)

   *  Designation: esp_sn_lsb

   *  Attribute Format: 1

   *  Attribute Value: SN LSB designates the number of bits that are
      provided to infer the SPI.  This number is between 0 and 32.

   *  Default Value: the default value is 32, which is the size of the
      standard SN in the standard ESP.

8.  IANA Considerations

8.1.  Registration of IKEv2 Notify Message Types

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

     Value    Notify Messages - Status Types
   -----------------------------------------
     TBA1    HCP_PROPOSAL

   This specification requests the IANA to create a Header Compression
   Profile registry (see Section 8.3), as well as the necessary
   registries for the ESP Header Compression Profile Diet-ESP, that is
   the Attributes for Rule Derivation (see Section 8.4) as well as, when
   required, the complementary specific AfRD Values associated with each
   AfRD (see Section 8.5).

   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

Migault, et al.          Expires 19 August 2026                 [Page 9]
Internet-Draft                EHC extension                February 2026

   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.

   All registries are "Specification Required".

8.2.  Registry for Generic Attributes for Rule Derivation

   Registry for Generic Attributes for Rule Derivation.  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 AfRD
   Code Point mentioned here MUST NOT be reused by any Registries
   associated with any Profile and is shared by all profiles.

    +===========+=======+=====================+===========+===========+
    | AfRD Code | Full  | Designation         | Attribute | Reference |
    | Point     | Name  |                     | Format    |           |
    +===========+=======+=====================+===========+===========+
    | 65535     | RANGE | range_afrd_proposal | 0         | ThisRFC   |
    |           | AfRD  |                     |           |           |
    +-----------+-------+---------------------+-----------+-----------+

                                  Table 1

   Each entry in the range is represented by two attributes (AfRD_min
   and AfRD_max), both following the 2-byte Attribute Type format
   specified in [RFC7296].  This ensures clarity and compatibility in
   all implementations.

8.3.  Registry for IKEv2 Header Compression Profile

               +================+=============+===========+
               | Value (1 Byte) | Designation | Reference |
               +================+=============+===========+
               | 0              | Diet-ESP    | ThisRFC   |
               +----------------+-------------+-----------+
               | 1-255          | unallocated | -         |
               +----------------+-------------+-----------+

                                 Table 2

8.4.  Registry for Diet-ESP Attributes for Rule Derivation

   Registry for Attributes for Rule Derivation 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.

Migault, et al.          Expires 19 August 2026                [Page 10]
Internet-Draft                EHC extension                February 2026

   The Diet-ESP Attributes for Rule Derivation registry specifies six
   AfRD 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 [RFC7296], [RFC4301], and
   related drafts (e.g., DSCP values) are already defined and negotiated
   during the creation of the CHILD SA.

   +========+=============+===================+===========+===========+
   | AfRD   | Full Name   | Designation       | Attribute | Reference |
   | Code   |             |                   | Format    |           |
   | Point  |             |                   |           |           |
   +========+=============+===================+===========+===========+
   | 0      | DSCP Action | dscp_action       | 1         | ThisRFC   |
   +--------+-------------+-------------------+-----------+-----------+
   | 1      | ECN Action  | ecn_action        | 1         | ThisRFC   |
   +--------+-------------+-------------------+-----------+-----------+
   | 2      | Flow Label  | flow_label_action | 1         | ThisRFC   |
   |        | Action      |                   |           |           |
   +--------+-------------+-------------------+-----------+-----------+
   | 3      | Alignment   | alignment         | 1         | ThisRFC   |
   +--------+-------------+-------------------+-----------+-----------+
   | 4      | SPI LSB     | esp_spi_lsb       | 1         | ThisRFC   |
   +--------+-------------+-------------------+-----------+-----------+
   | 5      | SN LSB      | esp_sn_lsb        | 1         | ThisRFC   |
   +--------+-------------+-------------------+-----------+-----------+
   | 6 -    | unallocated | -                 | -         | -         |
   | 2^16-2 |             |                   |           |           |
   +--------+-------------+-------------------+-----------+-----------+

                                 Table 3

8.5.  Registries for the Values of Diet-ESP Attributes for Rule
      Derivation

8.5.1.  DSCP Action Value Registry

                  +=======+================+===========+
                  | Value | Designation    | Reference |
                  +=======+================+===========+
                  | 0     | not_compressed | ThisRFC   |
                  +-------+----------------+-----------+
                  | 1     | lower          | ThisRFC   |
                  +-------+----------------+-----------+
                  | 2     | sa             | ThisRFC   |
                  +-------+----------------+-----------+
                  | 3-255 | unallocated    | -         |
                  +-------+----------------+-----------+

Migault, et al.          Expires 19 August 2026                [Page 11]
Internet-Draft                EHC extension                February 2026

                                 Table 4

8.5.2.  ECN Action Value Registry

                  +=======+================+===========+
                  | Value | Designation    | Reference |
                  +=======+================+===========+
                  | 0     | not_compressed | ThisRFC   |
                  +-------+----------------+-----------+
                  | 1     | lower          | ThisRFC   |
                  +-------+----------------+-----------+
                  | 2-255 | unallocated    | -         |
                  +-------+----------------+-----------+

                                 Table 5

8.5.3.  Flow Label Action Value Registry

                  +=======+================+===========+
                  | Value | Designation    | Reference |
                  +=======+================+===========+
                  | 0     | not_compressed | ThisRFC   |
                  +-------+----------------+-----------+
                  | 1     | lower          | ThisRFC   |
                  +-------+----------------+-----------+
                  | 2     | generated      | ThisRFC   |
                  +-------+----------------+-----------+
                  | 3     | zero           | ThisRFC   |
                  +-------+----------------+-----------+
                  | 4-255 | unallocated    | -         |
                  +-------+----------------+-----------+

                                 Table 6

8.5.4.  ESP Byte Alignment

                    +=======+=============+===========+
                    | Value | Designation | Reference |
                    +=======+=============+===========+
                    | 0     | 8 bit       | ThisRFC   |
                    +-------+-------------+-----------+
                    | 1     | 16 bit      | ThisRFC   |
                    +-------+-------------+-----------+
                    | 2     | 32 bit      | ThisRFC   |
                    +-------+-------------+-----------+
                    | 3     | 64 bit      | ThisRFC   |
                    +-------+-------------+-----------+
                    | 4-255 | unallocated | -         |

Migault, et al.          Expires 19 August 2026                [Page 12]
Internet-Draft                EHC extension                February 2026

                    +-------+-------------+-----------+

                                  Table 7

8.6.  ESP Trailer

                    +=======+=============+===========+
                    | Value | Designation | Reference |
                    +=======+=============+===========+
                    | 0     | Mandatory   | ThisRFC   |
                    +-------+-------------+-----------+
                    | 1     | Optional    | ThisRFC   |
                    +-------+-------------+-----------+
                    | 2-255 | unallocated | -         |
                    +-------+-------------+-----------+

                                  Table 8

9.  Security Considerations

   The protocol defined in this document does not modify IKEv2.

   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.

10.  Acknowledgements

   The authors extend their gratitude to Samita Chakrabart, Tero
   Kivinen, Michael Richardson and Valery Smyslov for their long time
   support.  The authors would like to acknowledge the support from
   Mitacs through the Mitacs Accelerate program.

11.  Normative References

   [I-D.ietf-ipsecme-diet-esp]
              Migault, D., Hatami, M., Cespedes, S., Atwood, J. W., Liu,
              D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP
              Header Compression with Diet-ESP", Work in Progress,
              Internet-Draft, draft-ietf-ipsecme-diet-esp-09, 17 August
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              ipsecme-diet-esp-09>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Migault, et al.          Expires 19 August 2026                [Page 13]
Internet-Draft                EHC extension                February 2026

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Daniel Migault
   Ericsson
   Email: daniel.migault@ericsson.com

   Maryam Hatami
   Concordia University
   Email: maryam.hatami@mail.concordia.ca

   Daiying Liu
   Ericsson
   Email: harold.liu@ericsson.com

   Stere Preda
   Ericsson
   Email: stere.preda@ericsson.com

   J. William Atwood
   Concordia University
   Email: william.atwood@concordia.ca

   Sandra Céspedes
   Concordia University
   Email: sandra.cespedes@concordia.ca

   Tobias Guggemos
   LMU
   Email: guggemos@nm.ifi.lmu.de

Migault, et al.          Expires 19 August 2026                [Page 14]
Internet-Draft                EHC extension                February 2026

   David Schinazi
   Google LLC
   Email: dschinazi.ietf@gmail.com

Migault, et al.          Expires 19 August 2026                [Page 15]