ESP Header Compression Profile

2.1. The Three compressors described in this specification

The document outlines the three compressors utilized in Diet-ESP, which are detailed as follows:¶

1. Inner IP Compression (IIPC): This process pertains to the compression and decompression of the IP packet protected by ESP. For outbound packets, the ESP incorporates the compressed Inner IP (IIP) into the ESP Data Payload (refer to Figure 1). In the case of inbound packets, decompression occurs after the compressed IIP is retrieved from the Data Payload within the Clear Text ESP packet.¶

2. Clear Text ESP Compression (CTEC): This process pertains to the compression and decompression of the ESP segment that is destined for encryption. This encompasses the Payload Data and the ESP Trailer, which includes the Padding, Pad Length, and Next Header fields, as illustrated in Figure 1. At this stage, only the latter fields are eligible for compression. For outbound packets, the ESP subsequently encrypts the compressed Clear Text ESP. For inbound packets, decompression takes place following the decryption process of the ESP.¶

3. Encrypted ESP Compression (EEC): This process pertains to the compression and decompression of the Encrypted ESP packet (EE), which consists of the ESP Header, the encrypted payload, and the Integrity Check Value (ICV). Since neither the encrypted payload nor the ICV can be compressed, only the ESP Header, specifically the SPI and SN fields, are subject to compression.¶

2.2. The scope of SCHC in this specification

SCHC [RFC8724] offers a mechanism for header compression as well as an optional fragmentation feature. This document utilizes SCHC as a practical means to illustrate the capability to compress and decompress a structured payload. It is important to note that any elements of SCHC that pertain to aspects other than compression or decompression, such as fragmentation, fall outside the purview of this document. The reference to SCHC herein is solely for descriptive purposes related to compression and decompression, and it is not anticipated that the general SCHC framework will be integrated into the ESP implementation. The structured payloads addressed in this specification pertain to internal structures managed by ESP for the processing of an IP packet. Consequently, the compression and decompression processes outlined in this document represent supplementary steps for the ESP stack in handling the ESP packet.¶

2.3. SCHC Rules and SCHC static context in this specification

SCHC facilitates the compression and decompression of headers by utilizing a common context that may encompass multiple Rules. Each Rule is designed to correspond with specific values or ranges of values within the header fields. When a Rule is successfully matched, the corresponding header fields are substituted with the Rule ID and the Compression Residue, which contains the remaining bits after compression.¶

In the context of IPsec, the process of encryption or decryption between IPsec peers necessitates a common context known as a Security Association (SA). More broadly, the SA encompasses all essential parameters required by the Encapsulating Security Payload (ESP) to handle both inbound and outbound packets. It is important to note that SAs are unidirectional. Furthermore, IPsec can link both outbound and inbound IP packets to the SA through Traffic Selectors (TS) or Security Parameters Index (SPI). This capability allows IPsec to uniquely associate outbound and inbound packets with a specific context (SA), which contains all pertinent information for IPsec processing.¶

This document adopts a comparable methodology for compression and decompression, ensuring that the SA includes all necessary parameters to create the unique Rule applicable for compressing or decompressing each structured payload. This guarantees that each SA is linked to a single Rule, thereby allowing the Rule ID to be omitted. The Rule associated with each structured payload is generated based on specific parameters referred to in this document as Attributes for Rule Generation (AfRG) (see Section 4.2 for a more detailed description). These AfRGs are negotiated through IKEv2 [RFC7296], and in such cases, they are likely already included in the SA. Any additional missing AfRGs are negotiated via [I-D.ietf-ipsecme-ikev2-diet-esp-extension].¶

4.1. SCHC Parameters for Diet-ESP

The SCHC Payload [RFC8724] is always in the form:¶

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+---------...----------+~~~~~~~~~+---------------+
|   RuleID    | Compression Residue  | Payload | SCHC padding  |
+-+-+-+-+-+-+-+---------...----------+~~~~~~~~~+---------------+
|-------- Compressed Header ---------|         |-- as needed --|

The RuleID is a unique identifier for each SCHC rule. It is included in packets to ensure the receiver applies the correct decompression rule, maintaining consistency in packet processing. Note that the Rule ID does not need to be explicitly agreed upon and can be defined independently by each party. The RuleID in Diet-ESP is expressed as 1 byte and is always elided as Rules are uniquely determined for compressors.¶

Other variables required for the C/D in Diet-ESP are the following:¶

Maximum Packet Size:

MAX_PACKET_SIZE is determined by the specific IPsec ESP configuration and the underlying transport, but it is typically aligned with the network’s MTU. The size constraints are optimized based on the available link capacity and negotiated parameters between endpoints.¶

SCHC Padding:

Padding in SCHC is used to align data to a specific boundary (typically byte-aligned or 8-bit aligned) to meet the requirements for encryption which only considers octets instead of bits. The SCHC Padding is only used over the CTE as described in Section 5.3.¶

SCHC padding is used solely to ensure byte alignment for the Compressed Inner IP Packet (IIPC) before the ESP padding is applied. This distinction is necessary because ESP Padding may be compressed or omitted depending on the negotiated alignment. In this document, we refer to this specific use of SCHC padding as Byte Alignment.¶

4.2. Attributes for Rules Generation

The list of attributes for the Rules Generation (AfRG) is shown in Table 1. These attributes are used to express the various compressions that operate at the IIPC, CTEC, and EEC.¶

As outlined in Section 4, this specification does not detail the process by which the AfRG are established between peers. Instead, such negotiations are addressed in [I-D.ietf-ipsecme-ikev2-diet-esp-extension]. However, the AfRG can be classified into two distinct categories. The first category encompasses AfRG that are negotiated through a specific IKEv2 extension tailored for the negotiation of AfRG linked to a particular profile, the Diet-ESP profile in this context. The AfRG referenced in Table 1 in this category are: the DSCP Compression/Decompression Action (CDA) dscp_cda, the ECN CDA ecn_cda, the Flow Label CDA flow_label_cda, the ESP alignment alignment, the ESP SPI Least Significant Bits (LSB) esp_spi_lsb, and the ESP Sequence Number LSB esp_sn_lsb.¶

The second category pertains to AfRG that are negotiated through IKEv2 exchanges or extensions that are not specifically designed for compression purposes. This category includes AfRG associated with TS, as identified in Table 1, which are the TS IP Version ts_ip_version, the TS IP Source Start ts_ip_src_start, the TS IP Source End ts_ip_src_end, the TS IP Destination Start ts_ip_dst_start, the TS IP Destination End ts_ip_dst_end, the TS Protocol ts_proto, the TS Port Source Start ts_port_src_start, the TS Port Source End ts_port_src_end, the TS Port Destination Start ts_port_dst_start, and the TS Port Destination End ts_port_dst_end. These AfRG are derived from the Traffic Selectors established through TSi/TSr payloads during the IKEv2 CREATE_CHILD_SA exchange, as described in [RFC7296], Section 3.13. The AfRG IPsec Mode designated as ipsec_mode in Table 1 is determined by the presence or absence of the USE_TRANSPORT_MODE Notify Payload during the CREATE_CHILD_SA exchange, as detailed in [RFC7296], Section 1.3.1. The AfRG Tunnel IP designated as tunnel_ip in Table 1 is obtained from the IP address of the IKE messages exchanged during the CREATE_CHILD_SA process, as noted in [RFC7296], Section 1.1.3. The AfRGs designated as ESP Encryption Algorithm esp_encr and ESP Security Parameter Index (SPI) esp_spi in Table 1 are established through the SAi2/SAr2 payloads during the CREATE_CHILD_SA exchange, while the AfRG designated as ESP Sequence Number esp_sn in Table 1 is initialized upon the creation of the Child SA and incremented for each subsequent ESP message.¶

The ability to derive the IPPC Rules for the IIPC from the agreed Traffic Selectors is indicated by the variable iipc_profile.¶

Any variable starting with "ts_" is associated with the Traffic Selectors (TSi/TSr) of the SA. The notation is introduced by this specification but the definitions of the variables are in [RFC4301] and [RFC7296].¶

The Traffic Selectors may result in a quite complex expression, and this specification restricts that complexity. This specification restricts the resulting TSi/TSr to a single type of IP address (IPv4 or IPv6), a single protocol (e.g., UDP, TCP, or ANY), a single port range for source and destination. This specification presumes that the Traffic Selectors can be articulated as a result of CREATE_CHILD_SA with only one Traffic Selector [RFC7296], Section 3.13.1 in both TSi and TSr payloads (as described in [RFC7296], Section 3.13). The TS Type MUST be either TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE.¶

Let the resulting Traffic Selectors TSi/TSr be expressed via the Traffic Selector structure defined in [RFC7296], Section 3.13.1. We designate the local TS the TS - either TSi or TSr - sent by the local peer. Conversely we designate as remote TS the TS - either TSi or TSr - sent by the remote peer.¶

The details of each parameter are the following:¶

iipc_profile:

designates the behavior of the IIPC layer. When set to "iipc_uncompress" IIPC is not performed. This specification describes IIPC that corresponds to the "iipc_diet-esp" profile.¶

flow_label_cda:

indicates the Flow Label CDA, that is how the Flow Label field of the inner IPv6 packet or the Identification field of the inner IPv4 packet is compressed / decompressed - See Section 4.2.1 for more information. In a nutshell, "uncompress" indicates that Flow Label (resp. Identification) are not compressed. "lower" indicates the value is read from the outer IP header - eventually with some adaptations when inner IP packet and outer IP packets have different versions. "generated" indicates that the field is generated by the receiving party. In that case, the decompressed value may take a different value compared to its original value. "zero" indicates the field is set to zero.¶

dscp_cda:

indicates the DSCP CDA, that is how the DSCP values of the inner IP packet are compressed / decompressed - See Section 4.2.1 for more information. In a nutshell, "uncompress" indicates that DSCP are not compressed. "lower" indicates the value is read from the outer IP header - eventually with some adaptations when inner IP packet and outer IP packets have different versions. "sa" indicates, compression is performed according to the DSCP values agreed by the SA (dscp_list).¶

ecn_cda:

indicates ECN CDA, that is how the ECN values of the inner IP packet are compressed / decompressed - See Section 4.2.1 for more information. In a nutshell, "uncompress" indicates that DSCP are not compressed. "lower" indicates the value is read from the outer IP header - eventually with some adaptations when inner IP packet and outer IP packets have different versions.¶

ts_ip_version:

designates the TS IP version. Its value is set to "IPv4-only" when only IPv4 IP addresses are considered and to "IPv6-only" when only IPv6 addresses are considered. Practically, when IKEv2 is used, it means that the agreed TSi or TSr results only in a mutually exclusive combination of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE payloads. If TS Type of the resulting TSi/TSr is set to TS_IPV4_ADDR_RANGE, ts_ip_version takes the value "IPv4-only". Respectively, if TS Type is set to TS_IPV6_ADDR_RANGE, ts_ip_version is set to "IPv6-only".¶

ts_ip_src_start:

designates the TS IP Source Start, that is the starting value range of source IP addresses of the inner packet and has the same meaning as the Starting Address field of the local TS.¶

ts_ip_src_end:

designates TS IP Source End that is the high end value range of source IP addresses of the inner packet and has the same meaning as the Ending Address field of the local TS.¶

ts_ip_dst_start:

designates the TS IP Destination Start, that is the starting value range of destination IP addresses of the inner packet and has the same meaning as the Starting Address field of the remote TS.¶

ts_ip_dst_end:

designates the TS IP Destination End, that is the high end value range of destination IP addresses of the inner packet and has the same meaning as the Ending Address field of the remote TS.¶

ts_proto:

designates the TS Protocol, that is the Protocol ID of the resulting TSi/TSr. This profile considers the specific protocol values "TCP", "UDP", "UDP-Lite", "SCTP" and "ANY". The representation of "ANY" is given in [RFC4301], Section 4.4.4.2.¶

ts_port_src_start:

designates the TS Port Source Start, that is the the starting value of the source port range of the inner packet and has the same meaning as the Start Port field of the local TS.¶

ts_port_src_end:

designates the TS Port Source End, that is the high end value range of the source port range of the inner packet and has the same meaning as the End Port field of the local TS.¶

ts_port_dst_start:

designates TS Port Destination Start, that is the starting value of the destination port range of the inner packet and has the same meaning as the Start Port field of the remote TS.¶

ts_port_dst_end:

designates TS Port Destination End, that is the high end value range of the destination port range of the inner packet and has the same meaning as the End Port field of the remote TS.¶

IP addresses and ports are defined as a range and compressed using the Least Significant Bits (LSB). For a range defined by start and end values, msb( start, end ) is defined as the function that returns the Most Significant Bits (MSB) that remains unchanged while the value evolves between start and end. Similarly, lsb( start, end ) is defined as the function that returns the LSB that changes while the value evolves between start and end. Finally, len( x ) is defined as the function that returns the number of bits of the bit array x.¶

dscp_list:

designates the list of DSCP values associated to the inner traffic - see for example [I-D.mglt-ipsecme-dscp-np]. These are not Traffic Selectors, but the compression mandates that the packets take one of these listed DSCP values.¶

alignment:

designates the ESP alignment as defined by [RFC4303].¶

ipsec_mode:

designates the IPsec Mode defined in [RFC4301]. In this document, the possible values are "tunnel" for the Tunnel mode and "transport" for the Transport mode.¶

tunnel_ip:

designates the Tunnel IP address of the tunnel defined in [RFC4301]. This field is only applicable when the Tunnel mode is used. That IP address can be an IPv4 or IPv6 address.¶

esp_encr:

designates the ESP Encryption Algorithm - also designated as Transform 1 in [RFC7296], Section 3.3.2. The algorithm is needed to determine whether the ESP Payload Data needs to be aligned to some predefined block size and if the ESP Pad Length and Padding fields can be compressed. For the purpose of compression it is RECOMMENDED to use algorithms that already compressed their IV [RFC8750].¶

esp_spi:

designates the Security Parameter Index defined in [RFC4301].¶

esp_spi_lsb:

designates the LSB to be considered for the compressed SPI. A value of 32 for esp_spi_lsb will leave the SPI unchanged.¶

esp_sn:

designates the ESP Sequence Number (SN) field defined in [RFC4301].¶

esp_sn_lsb:

designates the LSB to be considered for the compressed SN. It works similarly to ESP SPI LSB (see esp_spi_lsb).¶

5.1. Inner IP Compression (IIPC)

When iipc_profile is set to "iipc_uncompress", the packet is uncompressed. When iipc_profile is set to "iipc_diet-esp", IIPC proceeds to the compression of the inner IP Packet composed of an IP Header and an IP Payload. The compression of the inner IP Payload is described in Section 5.1.1.
The IP Header is compressed when ipsec_mode is set to "Tunnel" and left uncompressed otherwise. ts_ip_version determines how the IPv6 Header (resp. the IPv4 header) is compressed - see Section 5.1.2 (resp. Section 5.1.3).¶

5.2. ESP Payload Data Byte Alignment

Deleted---see subsection below. SCHC operates on bits, and the compression performed by SCHC may result in a bit payload that is not aligned to a byte (8 bits) boundary. Protocols such as ESP expect payloads to be aligned to byte boundaries (8-bit alignment). To ensure this, we apply a padding by appending the SCHC_padding bits and the SCHC_padding_len. SCHC_padding_len is encoded over 3 bits to encode the number of bits that will compose the SCHC_padding field. As a result SCHC_padding field has between 0 and 7 bits coded over the SCHC_padding_len. The two fields are between 3 and 10 bits, so if the complementing bits are less than or equal to 2 bits, the padding will result in adding an extra byte.¶

When the iipc_profile is set to "iipc_uncompress" there is no ESP Payload Data Byte alignment. When iipc_profile is set to "iipc_diet-esp" ESP Payload Data Byte Alignment is performed over the Compressed Inner IP packet. This ensures that in both transport and tunnel mode, the Payload Data later encrypted by ESP result in an integer number of bytes.¶

5.3. ESP Payload Data Byte Alignment

SCHC operates on bits, and the compression performed by SCHC may result in a bit payload that is not aligned to a byte boundary. Protocols such as ESP expect payloads to be aligned to byte boundaries (8-bit alignment). To ensure this, we apply a padding by appending the Byte Alignment bits and the Byte Alignment Length field. The Byte Alignment Length is encoded over 3 bits to indicate the number of bits that will compose the Byte Alignment field. As a result, the Byte Alignment field has between 0 and 7 bits, depending on the required alignment. The total additional overhead can be up to 10 bits (3-bit length field + 0-7 bits padding). If the complementing bits are less than or equal to 2 bits, the padding will result in adding an extra byte.¶

This Byte Alignment field is distinct from ESP Padding and is required to ensure proper decryption without requiring additional shifting operations in hardware. If the expected length of the compressed residue is statically determinable based on the SA, the padding length can be inferred, and the field may be omitted. Otherwise, when the residue length depends on dynamic fields, the length must be explicitly provided.¶

When the Byte Alignment is applied, it is performed only after the IIPC stage and before the ESP Padding is added. The ESP Padding is only compressed when alignment is explicitly set to 8 bits.¶

This ensures that in both transport and tunnel mode, the Payload Data later encrypted by ESP results in an integer number of bytes.¶

5.4. Clear Text ESP Compression (CTEC)

Once the Inner IP Packet has undergone compression as outlined in Section 5.1, followed by the ESP Byte Alignment detailed in Section 5.3, the resulting compressed inner packet comprises a specific number of bytes. To construct the Clear Text ESP Packet, it is necessary to ascertain the ESP Payload Data, the Next Header, the Pad Length, and the Padding fields.¶

In transport mode, the IP header of the inner packet remains uncompressed during the IIPC phase, and the ESP Payload Data is derived from the inner packet. Conversely, in tunnel mode, the Payload Data encompasses the entirety of the inner packet.¶

In transport mode, the Next Header field is obtained from either the inner IP Header or the Security Association, as specified in Section 5.1.3 or Section 5.1.2. In tunnel mode, the Next Header is elided, as it is determined by ts_ip_version. FL is set to 8 bit, TV is set to IPv4 or IPv6 depending on ts_ip_version, MO is set to "equal" and CDA is set to "not-sent".¶

The ESP Pad Length and Padding fields are omitted only when ESP alignment has been selected to "8bit" and esp_encr does not necessitate a specific block size alignment, or if that block size is one byte. This is represented by setting FL to (Pad Length + 1) * 8 bits, leaving TV unset, configuring MO to "ignore," and designating CDA as padding. The ESP Padding and Pad Length may vary from their decompressed counterparts. However, since the IPsec process removes the padding, these variations do not affect packet processing. When esp_encr requires a specific block size, the ESP Pad Length and Padding fields remain uncompressed.¶

5.5. Encrypted ESP Compression (EEC)

SPI is compressed to its LSB. FL is set to 32 bits, TV is not set, MO is set to "MSB( 4 - esp_spi_lsb)" and CDA is set to "LSB".¶

SN is compressed to their LSB, similarly to the SPI. FL is set to 32 bits, TV is not set, MO is set to "MSB( 4 - esp_sn_lsb)" and CDA is set to "LSB".¶

10.1. Normative References

[I-D.ietf-ipsecme-ikev2-diet-esp-extension]

Migault, D., Guggemos, T., Schinazi, D., Atwood, J. W., Liu, D., Preda, S., Hatami, M., and S. Cespedes, "Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP)", Work in Progress, Internet-Draft, draft-ietf-ipsecme-ikev2-diet-esp-extension-03, 26 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-diet-esp-extension-03>.

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

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

[RFC4303]

Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC6437]

Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.

[RFC6864]

Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, <https://www.rfc-editor.org/info/rfc6864>.

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

[RFC8221]

Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.

[RFC8724]

Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, <https://www.rfc-editor.org/info/rfc8724>.

[RFC8750]

Migault, D., Guggemos, T., and Y. Nir, "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)", RFC 8750, DOI 10.17487/RFC8750, March 2020, <https://www.rfc-editor.org/info/rfc8750>.

10.2. Informative References

[I-D.ietf-schc-architecture]

Pelov, A., Thubert, P., and A. Minaburo, "Static Context Header Compression (SCHC) Architecture", Work in Progress, Internet-Draft, draft-ietf-schc-architecture-04, 6 February 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-schc-architecture-04>.

[I-D.mglt-ipsecme-dscp-np]

Migault, D., Halpern, J. M., Parkholm, U., and D. Liu, "Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification", Work in Progress, Internet-Draft, draft-mglt-ipsecme-dscp-np-01, 3 July 2024, <https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-dscp-np-01>.

[OpenSCHC]

"OpenSCHC a Python open-source implementation of SCHC (Static Context Header Compression)", n.d., <https://github.com/openschc>.

[RFC4302]

Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.

[RFC6438]

Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.

[RFC8376]

Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, <https://www.rfc-editor.org/info/rfc8376>.

[RFC9333]

Migault, D. and T. Guggemos, "Minimal IP Encapsulating Security Payload (ESP)", RFC 9333, DOI 10.17487/RFC9333, January 2023, <https://www.rfc-editor.org/info/rfc9333>.

A.1. Illustrative Examples of Diet-ESP in Tunnel Mode

This section provides a structured example of how Diet-ESP operates in Tunnel Mode. The example includes Attributes for Rule Generation (AfRG), SCHC rules, the Inner IP packet (IIP), the compression process, and the decompression process.¶

A.2. Illustrative Examples of Diet-ESP in Transport Mode

This section follows the same structure as Tunnel Mode but applies to Transport Mode, where the IP header remains uncompressed.¶

[
  {
  "ipsec_mode": "Transport",
  "ts_ip_version": "IPv6-only",
  "compressed_fields": [
    {
      "FID": "IPv6.SourceAddress",
      "FL": 128,
      "TV": "2001:db8::1001",
      "MO": "equal",
      "CDA": "sent-value"
    },
    {
      "FID": "IPv6.DestinationAddress",
      "FL": 128,
      "TV": "2001:db8::2002",
      "MO": "equal",
      "CDA": "sent-value"
    },
    {
      "FID": "IPv6.NextHeader",
      "FL": 8,
      "TV": 17,
      "MO": "equal",
      "CDA": "not-sent"
    },
    {
      "FID": "UDP.SourcePort",
      "FL": 16,
      "TV": 1234,
      "MO": "MSB",
      "CDA": "LSB"
    },
    {
      "FID": "UDP.DestinationPort",
      "FL": 16,
      "TV": 5678,
      "MO": "MSB",
      "CDA": "LSB"
    },
    {
      "FID": "UDP.Length",
      "FL": 16,
      "TV": null,
      "MO": "ignore",
      "CDA": "compute-length"
    },
    {
      "FID": "UDP.Checksum",
      "FL": 16,
      "TV": null,
      "MO": "ignore",
      "CDA": "checksum"
    },
    {
      "FID": "ESP.SPI",
      "FL": 32,
      "TV": null,
      "MO": "MSB(4 - esp_spi_lsb)",
      "CDA": "LSB"
    },
    {
      "FID": "ESP.SequenceNumber",
      "FL": 32,
      "TV": null,
      "MO": "MSB(4 - esp_sn_lsb)",
      "CDA": "LSB"
    },
    {
      "FID": "ESP.Padding",
      "FL": 8,
      "TV": null,
      "MO": "ignore",
      "CDA": "padding"
    },
    {
      "FID": "ESP.NextHeader",
      "FL": 8,
      "TV": 17,
      "MO": "equal",
      "CDA": "not-sent"
    }

]
  }
    ]