An Entropy Header for Load Balancing of IPsec ESP Traffic
draft-yang-ipsecme-esp-entropy-header-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jin Yang , Yuchi Tian , Weiqiang Cheng , Junjie Wang , Guoying Zhang | ||
| Last updated | 2026-06-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yang-ipsecme-esp-entropy-header-00
IPSECME J. Yang
Internet-Draft Y. Tian
Intended status: Standards Track W. Cheng
Expires: 24 December 2026 China Mobile
J. Wang
G. Zhang
Centec
22 June 2026
An Entropy Header for Load Balancing of IPsec ESP Traffic
draft-yang-ipsecme-esp-entropy-header-00
Abstract
When IPsec Encapsulating Security Payload (ESP) is used in tunnel
mode, an intermediate node cannot inspect the encrypted inner headers
to derive entropy for Equal-Cost Multipath (ECMP) or Link Aggregation
Group (LAG) path selection. Path selection is then driven by outer
header fields that are identical for every packet of a given tunnel,
so all packets of the tunnel are placed on a single path regardless
of the number of inner flows.
This document defines the ESP Entropy Header, an IP protocol header
that is placed immediately ahead of ESP and carries an entropy value
in a fixed position that transit nodes can use for path selection.
It also defines an Internet Key Exchange Protocol Version 2 (IKEv2)
extension with which peers negotiate the use of the header on a per-
Child-SA basis. The mechanism applies to both IPv4 and IPv6.
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 24 December 2026.
Yang, et al. Expires 24 December 2026 [Page 1]
Internet-Draft ESP Entropy Header June 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Design Considerations . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. ESP Entropy Header Format . . . . . . . . . . . . . . . . . . 5
3. Header Placement . . . . . . . . . . . . . . . . . . . . . . 6
4. Processing Requirements . . . . . . . . . . . . . . . . . . . 7
4.1. IPsec Sender . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 8
4.3. IPsec Receiver . . . . . . . . . . . . . . . . . . . . . 8
5. IKEv2 Negotiation . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Negotiation Procedure . . . . . . . . . . . . . . . . . . 9
5.2. Notify Payload Format . . . . . . . . . . . . . . . . . . 9
6. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. Information Exposure . . . . . . . . . . . . . . . . . . 10
7.2. Header Integrity . . . . . . . . . . . . . . . . . . . . 11
7.3. Entropy Collisions . . . . . . . . . . . . . . . . . . . 11
8. Operational Considerations . . . . . . . . . . . . . . . . . 11
8.1. Incremental Deployment . . . . . . . . . . . . . . . . . 11
8.2. Coexistence with UDP Encapsulation . . . . . . . . . . . 11
8.3. Relationship to Load-Aware Path Selection . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. IP Protocol Number . . . . . . . . . . . . . . . . . . . 12
9.2. IKEv2 Notify Message Type . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Yang, et al. Expires 24 December 2026 [Page 2]
Internet-Draft ESP Entropy Header June 2026
1. Introduction
1.1. Problem Statement
IPsec [RFC4301] provides security services for IP traffic at the
network layer. ESP [RFC4303] is the most widely deployed IPsec
protocol and provides confidentiality, integrity, and anti-replay
protection. In tunnel mode the original packet is encrypted and
encapsulated in a new outer IP header.
Intermediate nodes along the tunnel path perform ECMP and LAG path
selection by computing a hash over selected packet header fields.
For an ESP tunnel-mode packet, only the outer IP header is available
to such a node. When a single tunnel carries multiple inner flows,
the outer source and destination addresses are the same for every
packet, so the hash yields the same result at each hop and all
packets of the tunnel are assigned to the same path. The available
paths are therefore not used evenly. This behavior is a recognized
operational limitation of IPsec deployments.
Comparable problems have been addressed in other encapsulations.
MPLS uses entropy labels [RFC6790]. IPv6 tunnels can use the flow
label for the same purpose [RFC6438]. For IPsec there is at present
no header within the IP protocol stack, common to IPv4 and IPv6, that
carries entropy in a fixed location for a transit node to use.
1.2. Overview
This document defines an IP protocol header, the ESP Entropy Header,
that immediately precedes the ESP header. The header carries a
16-bit Entropy field that is set by the IPsec sender and is available
for inspection by transit nodes. A transit node that recognizes the
assigned protocol number MAY include the Entropy field in its ECMP
and LAG path-selection input.
Use of the ESP Entropy Header is negotiated between IPsec peers using
an IKEv2 [RFC7296] Notify exchange, so that a peer includes the
header only when its peer is prepared to process packets that carry
it.
Improving the entropy available for path selection, as this document
does, is complementary to making the path-selection decision itself
load-aware. The latter approach is described in
[I-D.yang-rtgwg-ecmp-adaptive-load-balance]; the two mechanisms
operate at different points and may be combined. The relationship is
discussed in Section 1.3.
Yang, et al. Expires 24 December 2026 [Page 3]
Internet-Draft ESP Entropy Header June 2026
1.3. Design Considerations
Entropy for encrypted tunnel traffic can be provided in more than one
way. This section records the trade-offs that apply to the
alternatives, so that the choice made in this document is documented
rather than assumed.
UDP encapsulation: [I-D.xu-ipsecme-esp-in-udp-lb] and
[I-D.acharya-ipsecme-esp-ecmp] encapsulate ESP in UDP and use the UDP
source port to carry entropy. This suits environments in which
transit nodes already hash on the UDP five-tuple. It adds an 8-octet
UDP header, requires a UDP checksum in IPv6 [RFC8200], and shares the
UDP port space with NAT traversal [RFC3948], which can interact with
the use of the source port for entropy.
IPv6 flow label: [RFC6438] uses the IPv6 flow label for ECMP and LAG
in tunnels. It is native to IPv6 and adds no header, but is not
available in IPv4 and provides a 20-bit field whose use for load
balancing depends on transit support.
Multiple Security Associations: distinct SPI values across several
SAs can provide differentiation at the ESP layer. This increases IKE
signaling and keying state and requires a transit node to inspect
fields beyond the IP header.
The ESP Entropy Header is defined as an IP protocol type and so
applies to both IPv4 and IPv6. The Entropy field is at a fixed octet
offset from the start of the header, which allows a transit node to
locate it without parsing variable-length structures. This approach
follows the precedent of Wrapped ESP [RFC5840], which defined an IP-
protocol-numbered header that wraps ESP for a different purpose
(traffic visibility); that precedent shows that an IP-protocol-
numbered header adjacent to ESP is an established mechanism in the
IPsec architecture.
1.4. Requirements Language
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.
1.5. Terminology
This document uses the following terms.
IPsec Sender: The IPsec peer that performs outbound ESP processing.
Yang, et al. Expires 24 December 2026 [Page 4]
Internet-Draft ESP Entropy Header June 2026
In tunnel mode this is the tunnel ingress.
IPsec Receiver: The IPsec peer that performs inbound ESP processing.
In tunnel mode this is the tunnel egress.
Transit Node: Any router or Layer 3 switch on the path between the
IPsec sender and receiver that makes ECMP or LAG path selection
decisions.
Entropy: A value that, when included in the path-selection hash,
differentiates packets that would otherwise hash to the same
result, consistent with the use of the term in [RFC6790].
2. ESP Entropy Header Format
The ESP Entropy Header is 8 octets in length. It is identified by
its own IP protocol number (see Section 9). In the IP header that
precedes it, the Protocol field (IPv4) or the Next Header field
(IPv6) carries this protocol number.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Len | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ESP Entropy Header
Next Header (8 bits): Identifies the header that immediately follows
the ESP Entropy Header, using a value from the IANA "Assigned
Internet Protocol Numbers" registry. For the typical use with ESP
this field is 50.
Hdr Len (8 bits): Length of the ESP Entropy Header in 4-octet units,
not including the first 4 octets. For the header defined in this
document the value is 1, indicating a total length of 8 octets.
This field allows a future extension to increase the header length
without a new protocol number. A receiver that encounters a Hdr
Len value it does not support MUST skip the indicated number of
octets and continue processing at the Next Header.
Entropy (16 bits): A 16-bit value. A transit node MAY use this
field as input to ECMP and LAG path selection.
Yang, et al. Expires 24 December 2026 [Page 5]
Internet-Draft ESP Entropy Header June 2026
The value is set by the IPsec sender. The means by which the
sender selects the value is a local matter and is outside the
scope of this document. To be useful for load distribution, the
Entropy field has the following properties:
* All packets of the same inner flow MUST carry the same Entropy
value, so that per-flow packet ordering is preserved across
ECMP and LAG paths.
* The Entropy values used across the active flows of a tunnel
SHOULD be approximately uniformly distributed.
Reserved (MBZ) (32 bits): Set to zero on transmission and ignored on
receipt. Reserved for future use.
3. Header Placement
The ESP Entropy Header is placed between the outer IP header (and any
IPv6 extension headers) and the ESP header. The following diagrams
show the resulting packet structure.
+-------------------+
| Outer IPv4 | Protocol = EEH (TBD1)
| Header |
+-------------------+
| ESP Entropy Hdr | Next Header = 50 (ESP)
| (8 octets) |
+-------------------+
| ESP Header | SPI, Sequence Number
+-------------------+
| | Original IP Packet
| Encrypted Payload | (encrypted by ESP)
| |
+-------------------+
| ESP Trailer | Padding, Pad Length, NH
+-------------------+
| ESP ICV |
+-------------------+
Figure 2: IPv4 Tunnel Mode Packet Structure
Yang, et al. Expires 24 December 2026 [Page 6]
Internet-Draft ESP Entropy Header June 2026
+-------------------+
| Outer IPv6 | Next Header = EEH (TBD1)
| Header | or extension header chain
+-------------------+
| (Extension Hdrs) | (if any; last NH = TBD1)
+-------------------+
| ESP Entropy Hdr | Next Header = 50 (ESP)
| (8 octets) |
+-------------------+
| ESP Header | SPI, Sequence Number
+-------------------+
| | Original IP Packet
| Encrypted Payload | (encrypted by ESP)
| |
+-------------------+
| ESP Trailer | Padding, Pad Length, NH
+-------------------+
| ESP ICV |
+-------------------+
Figure 3: IPv6 Tunnel Mode Packet Structure
The ESP Entropy Header is not covered by ESP encryption or integrity
protection. It is visible in the clear to nodes on the path. The
security consequences are discussed in Section 7.
4. Processing Requirements
4.1. IPsec Sender
When the ESP Entropy Header has been negotiated for a Child SA (see
Section 5), the IPsec sender that chooses to include the header in an
outbound packet on that SA does so subject to the following
requirements.
* The outer IP Protocol (IPv4) or Next Header (IPv6) field MUST
carry the protocol number assigned to the ESP Entropy Header.
* The Next Header field of the ESP Entropy Header MUST identify the
following header, typically ESP (value 50).
* The Hdr Len field MUST be set to 1 for the header defined in this
document.
* The Entropy field MUST carry a value that is the same for all
packets of the same inner flow (see Section 2).
* The Reserved field MUST be set to zero.
Yang, et al. Expires 24 December 2026 [Page 7]
Internet-Draft ESP Entropy Header June 2026
* ESP encryption and integrity protection are applied to the payload
that follows the ESP Entropy Header, as in [RFC4303]. The ESP
Entropy Header is not part of the ESP-protected payload.
The IPsec sender MAY omit the ESP Entropy Header on some packets of
an SA for which it has been negotiated, for example when no useful
entropy can be derived for a packet. When the header is omitted, the
outer IP Protocol or Next Header field MUST be set to the ESP value
(50) and no ESP Entropy Header is present. A receiver MUST accept
packets both with and without the header on an SA for which the
header has been negotiated.
4.2. Transit Node
A transit node that recognizes the ESP Entropy Header protocol number
MAY include the Entropy field in the fields it uses for ECMP or LAG
path selection. The Entropy field is at octets 2 and 3 of the
header.
A transit node MUST NOT modify any field of the ESP Entropy Header.
A transit node that does not recognize the protocol number forwards
the packet according to its existing behavior for the outer IP
header; an unrecognized protocol number does not prevent forwarding.
The mechanism is therefore incrementally deployable: a node that
recognizes the header obtains improved path selection, and a node
that does not continues to forward the traffic.
4.3. IPsec Receiver
When the IPsec receiver has negotiated the ESP Entropy Header for a
Child SA, it MUST accept and process an incoming packet whose outer
IP Protocol or Next Header value indicates the ESP Entropy Header.
Because the SPI that identifies the Child SA is carried in the ESP
header, which follows the ESP Entropy Header, a receiver cannot
determine the SA before it has parsed the ESP Entropy Header. A
receiver that implements this specification therefore MUST process
the ESP Entropy Header whenever the outer IP Protocol or Next Header
value indicates it, and then continue to inbound ESP processing where
the SA is resolved. Per-Child-SA negotiation (Section 5) governs
whether a sender is permitted to emit the header; it does not gate
the receiver's ability to parse it. A node that does not implement
this specification does not recognize the protocol number and handles
the packet according to its existing behavior for an unknown IP
protocol number, as described for transit nodes in Section 4.2.
Yang, et al. Expires 24 December 2026 [Page 8]
Internet-Draft ESP Entropy Header June 2026
* The receiver reads the Next Header field of the ESP Entropy Header
to determine the following protocol. If the value is not
recognized, the receiver MUST discard the packet and MAY log the
event.
* The receiver uses the Hdr Len field to determine the length of the
ESP Entropy Header and to locate the next header.
* The receiver does not examine the Entropy or Reserved fields; they
are meaningful only to transit nodes.
* The receiver then processes the following header, typically ESP,
according to normal inbound IPsec processing [RFC4303].
5. IKEv2 Negotiation
Use of the ESP Entropy Header MUST be negotiated between peers before
the header is sent. This document defines an IKEv2 [RFC7296] Notify
Message of type Status, ESP_ENTROPY_HEADER_SUPPORTED, for this
purpose.
5.1. Negotiation Procedure
The initiator includes the ESP_ENTROPY_HEADER_SUPPORTED notification
in the IKE_AUTH or CREATE_CHILD_SA exchange that establishes or
rekeys the Child SA.
If the responder is willing to receive packets that carry the ESP
Entropy Header on the Child SA, it includes the same notification in
its response.
The ESP Entropy Header is negotiated successfully when both the
request and the response carry the ESP_ENTROPY_HEADER_SUPPORTED
notification. If the response does not carry it, the initiator MUST
NOT send packets that carry the ESP Entropy Header on the Child SA.
Successful negotiation means that each peer is prepared to receive
the header. Each peer decides independently whether to include the
header in its own outbound packets; the notification does not require
a peer to include the header in every packet.
5.2. Notify Payload Format
Yang, et al. Expires 24 December 2026 [Page 9]
Internet-Draft ESP Entropy Header June 2026
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ESP_ENTROPY_HEADER_SUPPORTED Notify Payload
Protocol ID: 0 when the notification is sent in the IKE_AUTH
exchange, or 3 (ESP) when it is sent in a CREATE_CHILD_SA
exchange.
SPI Size: 0.
Notify Message Type: ESP_ENTROPY_HEADER_SUPPORTED (value TBD2, see
Section 9.2).
This notification carries no data.
6. Path MTU Considerations
The ESP Entropy Header adds 8 octets to each packet that carries it.
An implementation that uses the header MUST account for the
additional 8 octets when it performs Path MTU Discovery [RFC1191]
[RFC8201] or when it determines the effective MTU for inner packets.
The effective inner MTU when the header is in use is reduced by 8
octets. An implementation SHOULD use PMTUD and adjust the tunnel MTU
accordingly. When PMTUD is not available, the implementation MUST
use a conservative MTU estimate that accounts for the 8-octet header.
7. Security Considerations
7.1. Information Exposure
The ESP Entropy Header is outside the ESP encryption and integrity
boundaries, so the Entropy field is visible to observers on the path.
The Entropy field does not directly carry inner packet content.
Because its value is typically associated with an inner flow, an
observer can infer that packets with the same Entropy value belong to
the same flow, and over time the number of distinct Entropy values in
a tunnel gives an estimate of the number of concurrent flows. This
is a form of traffic analysis.
Yang, et al. Expires 24 December 2026 [Page 10]
Internet-Draft ESP Entropy Header June 2026
An operator whose threat model includes flow-level traffic analysis
by an on-path observer SHOULD weigh the benefit of improved load
distribution against this exposure. Periodically changing the
Entropy value of a long-lived flow reduces the duration over which
packets can be correlated, at the cost of moving the flow between
paths when the value changes.
7.2. Header Integrity
The ESP Entropy Header is not integrity-protected by ESP. An on-path
attacker that can modify packets could alter the Entropy field and
influence transit path selection, for example to concentrate traffic
on a subset of paths or to direct traffic onto a path the attacker
observes.
These risks are the same in kind as those from modification of other
unprotected outer header fields such as the DSCP or the IPv6 flow
label. An operator that requires integrity protection of the outer
header chain MAY apply AH [RFC4302] around the ESP Entropy Header.
7.3. Entropy Collisions
The 16-bit Entropy field provides 65,536 values. When a tunnel
carries many concurrent flows, two or more flows may share an Entropy
value. A collision does not affect correctness; it reduces the
granularity of load distribution for the affected flows.
8. Operational Considerations
8.1. Incremental Deployment
A transit node that does not recognize the assigned protocol number
forwards packets using its existing outer-header path selection, so
the presence of the header on a path with non-supporting nodes does
not cause packet loss. A benefit is obtained at each transit node
that recognizes the header, independently of the other nodes on the
path.
8.2. Coexistence with UDP Encapsulation
When IPsec traffic is already encapsulated in UDP, for example for
NAT traversal [RFC3948], the UDP source port can serve as entropy if
the implementation varies it per flow. In that case the ESP Entropy
Header adds no benefit and SHOULD NOT be negotiated.
Yang, et al. Expires 24 December 2026 [Page 11]
Internet-Draft ESP Entropy Header June 2026
8.3. Relationship to Load-Aware Path Selection
The ESP Entropy Header improves the entropy that a transit node can
use as input to a static path-selection hash. It does not change how
a node reacts to load after a flow has been placed on a path. Load-
aware path selection, such as the procedures of
[I-D.yang-rtgwg-ecmp-adaptive-load-balance], adjusts placement in
response to measured load and is complementary: better entropy
improves the initial distribution, and load-aware selection corrects
skew that develops afterward. The two mechanisms do not conflict.
9. IANA Considerations
9.1. IP Protocol Number
IANA is requested to assign a value from the "Assigned Internet
Protocol Numbers" registry. Allocation of an IP protocol number
requires IESG approval per [RFC5237].
+=========+=========+====================+=================+
| Decimal | Keyword | Protocol | Reference |
+=========+=========+====================+=================+
| TBD1 | EEH | ESP Entropy Header | [This document] |
+---------+---------+--------------------+-----------------+
Table 1: Protocol Number Allocation
9.2. IKEv2 Notify Message Type
IANA is requested to assign a value from the "IKEv2 Notify Message
Types - Status Types" registry.
+=======+==============================+=================+
| Value | Notify Message Type | Reference |
+=======+==============================+=================+
| TBD2 | ESP_ENTROPY_HEADER_SUPPORTED | [This document] |
+-------+------------------------------+-----------------+
Table 2: IKEv2 Notify Message Type Allocation
10. References
10.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
Yang, et al. Expires 24 December 2026 [Page 12]
Internet-Draft ESP Entropy Header June 2026
[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>.
[RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the Protocol Field", BCP 37, RFC 5237,
DOI 10.17487/RFC5237, February 2008,
<https://www.rfc-editor.org/info/rfc5237>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
10.2. Informative References
[I-D.acharya-ipsecme-esp-ecmp]
Acharya, A., "UDP encapsulated ESP for ECMP", Work in
Progress, Internet-Draft, draft-acharya-ipsecme-esp-ecmp-
00, 2023, <https://datatracker.ietf.org/doc/html/draft-
acharya-ipsecme-esp-ecmp-00>.
[I-D.xu-ipsecme-esp-in-udp-lb]
Xu, X., Hegde, S., Pismenny, B., Zhang, D., and L. Xia,
"Encapsulating IPsec ESP in UDP for Load-balancing", Work
Yang, et al. Expires 24 December 2026 [Page 13]
Internet-Draft ESP Entropy Header June 2026
in Progress, Internet-Draft, draft-xu-ipsecme-esp-in-udp-
lb-15, March 2024, <https://datatracker.ietf.org/doc/html/
draft-xu-ipsecme-esp-in-udp-lb-15>.
[I-D.yang-rtgwg-ecmp-adaptive-load-balance]
Yang, J., Cheng, W., Wang, J., and G. Zhang, "Adaptive
Load Balancing for Equal-Cost Multipath (ECMP)", Work in
Progress, Internet-Draft, draft-yang-rtgwg-ecmp-adaptive-
load-balance-00, 2026,
<https://datatracker.ietf.org/doc/html/draft-yang-rtgwg-
ecmp-adaptive-load-balance-00>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped
Encapsulating Security Payload (ESP) for Traffic
Visibility", RFC 5840, DOI 10.17487/RFC5840, April 2010,
<https://www.rfc-editor.org/info/rfc5840>.
[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>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
Acknowledgements
The use of an entropy value to distribute load for encapsulated
traffic is established in the MPLS architecture through entropy
labels [RFC6790] and in IPv6 through the flow label [RFC6438]. This
document applies the same idea within the IPsec protocol stack.
Authors' Addresses
Yang, et al. Expires 24 December 2026 [Page 14]
Internet-Draft ESP Entropy Header June 2026
Jin Yang
China Mobile
Beijing
100053
China
Email: yangjinwl@chinamobile.com
Yuchi Tian
China Mobile
Beijing
100053
China
Email: tianyuchi@chinamobile.com
Weiqiang Cheng
China Mobile
Beijing
100053
China
Email: chengweiqiang@chinamobile.com
Junjie Wang
Centec
Suzhou
215000
China
Email: wangjj@centec.com
Guoying Zhang
Centec
Suzhou
215000
China
Email: zhanggy@centec.com
Yang, et al. Expires 24 December 2026 [Page 15]