Internet-Draft esp-ping July 2023
Colitti Expires 26 January 2024 [Page]
IP Security Maintenance and Extensions
Intended Status:
Standards Track
L. Colitti

ESP Echo Protocol


This document defines an ESP echo function which can be used to detect whether a given network path supports IPv6 ESP packets.

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

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 26 January 2024.

Table of Contents

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

2. Problem statement

IPsec sessions between hosts that have global connectivity will by default use unencapsulated IPv6 ESP, i.e., IPv6 packets with a Next Header value of 50. ESP packets may have advantages over ESP-in-UDP encapsulation, such as:

However, because ESP packets do not share fate with IKE packets, it is possible for the network to allow IKE packets but not ESP packets. This leads to the IPsec session not being able to exchange any packets even though IKE negotiation succeeded. Because ESP is only used after IKE negotiation, this failure mode is difficult to predict, difficult to detect, and difficult to recover from. In particular, migrating a session using MOBIKE [RFC4555] to a network that doe snot allow ESP could result in the session blackholing all future packets until the problem is detected and a new migration is performed to enable encapsulation.

Operational experience suggests that networks and some home routers that drop ESP packets are common enough to be a problem for general purpose VPN applications desiring to work reliably on the Internet.

3. Protocol Specification

An IPv6 node that desires to determine whether the path to a particular destination can support ESP packets can send an ESP Echo Request packet to that destination. ESP Echo Request packets are ESP packets with an SPI value of [ESP-ECHO-REQUEST], a Next Header value of 59 (No Next Header), and no payload.

If the destination supports ESP, and wishes to reveal to the sender that it does so, it SHOULD reply with an ESP Echo Reply packet. ESP Echo Reply packets are ESP packets with an SPI value of [ESP-ECHO-REPLY], a Next Header value of 59, and no payload.

4. Security Considerations

The security considerations are similar to other unconnected request-reply protocols such as ICMPv6 echo. In particular:

5. IANA Considerations

This memo requests that IANA allocate two new values from the "Security Parameters Index (SPI)" registry. The following entry should be appended:

Table 1
Number Description Reference
7 ESP Echo Request [THIS DOCUMENT]

6. References

6.1. Normative References

Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, , <>.
Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

6.2. Informative References


Thanks to Tero Kivinen, Steffen Klassert, Andrew McGregor, and Paul Wouters for helpful discussion and suggestions.

Author's Address

Lorenzo Colitti
Shibuya 3-21-3,