| Internet-Draft | TCP SRO | August 2026 |
| Luo | Expires 12 February 2027 | [Page] |
This document defines the Session Recovery Option (SRO) for TCP. SRO improves the reliability of SNAT and LB services and simplifies the implementation of elastically scaling SNAT/LB clusters. SRO enables a client and a server to exchange their identifiers during connection establishment. When a session needs to be recovered, an endpoint conveys the identifier of the peer to the network node, which uses it to locate the endpoint holding the session backup and recover the session. SRO is optional: endpoints that do not support it behave as if the option did not exist.¶
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 12 February 2027.¶
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.¶
SNAT and LB are stateful services: session state resides on the serving node, and a single node cannot recover its sessions after a failure. To provide reliable service, operators deploy high-availability (HA) pairs or clusters. Existing elastically scaling SNAT/LB cluster designs are complex to implement, and the most complex part is session recovery and session migration. Moreover, these services are unfriendly to long-lived connections: an idle connection is typically cleaned up by the serving node after a timeout [RFC5382], breaking the connection.¶
A novel approach to reliable service is to back up the session state to the client or server side, so that even a single serving node can recover a session after a failure. This approach is embodied in the Available Session Recovery Protocol (ASRP) [draft-cmcc-asrp], to which readers may refer for the details of session backup and recovery. A key challenge of this approach is locating the endpoint that holds the session backup. Other mechanisms exist, but the Session Recovery Option (SRO) defined in this document addresses this challenge in the most direct way: it locates the backup endpoint in a single step. Moreover, SRO is not limited to session recovery: any mechanism that needs to locate a client or a server can use it.¶
SRO is a TCP option [RFC9293]. During the TCP handshake, the client and the server exchange their identifiers; when a session must be recovered, an endpoint carries the identifier of the peer, and the network node uses it to locate the endpoint holding the session backup. SRO is lightweight: it is carried only in the SYN, the SYN-ACK, and segments sent on timeout retransmission, adding no overhead to normal data segments. Despite this small cost, SRO is important for the reliability of SNAT and LB services: it simplifies session recovery and session migration in elastically scaling SNAT/LB clusters, and makes them friendly to long-lived connections. With SRO, a session that has been cleaned up after an idle timeout is recovered as soon as a segment carrying the identifier arrives.¶
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.¶
"SRO" refers to the Session Recovery Option defined in this document. "Client" refers to TCP's active open side, and "server" refers to TCP's passive open side. "Network node" refers to a device (e.g., a load balancer or a NAT gateway) that forwards packets and participates in session backup and recovery. "Client identifier" refers to a value, carried in the SRO-Client-Identifier option, that identifies a client within a cluster. Its length is configurable and defaults to 4 octets. "Server identifier" refers to a value, carried in the SRO-Server-Identifier option, that identifies a server within a cluster. Its length is configurable and defaults to 4 octets. "Session backup" refers to session state information stored on an endpoint for the purpose of session recovery.¶
SRO is negotiated during the TCP handshake, similar to other TCP options, e.g., the Window Scale option [RFC7323] and TCP Fast Open [RFC7413]. During the handshake, each endpoint carries its own identifier: a client includes the SRO-Client-Identifier option in the SYN segment, and a server that supports SRO includes the SRO-Server-Identifier option in the SYN-ACK segment. SRO is only in effect if both options are present. After the handshake, an endpoint carries the identifier of the peer, which it stored during the handshake: a client carries the server identifier, and a server carries the client identifier.¶
The SRO-Client-Identifier option carries the identifier of the client. The identifier length is configurable, from 2 to 8 octets, with a default of 4 octets. The option is 2 + N octets long: 1 octet for the Kind, 1 octet for the Length (Length = N + 2), and N octets for the identifier.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Client Identifier (N octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SRO-Server-Identifier option has the same format as the SRO-Client-Identifier option, except that it carries the identifier of the server.¶
A client MAY include the SRO-Client-Identifier option in a SYN segment; the client decides whether to use SRO.¶
A server that supports SRO and receives a SYN segment with the SRO-Client-Identifier option MUST include the SRO-Server-Identifier option in the SYN-ACK segment.¶
A server that does not support SRO MUST NOT include the SRO-Server-Identifier option in the SYN-ACK segment.¶
The length of an identifier is configurable, from 2 to 8 octets, with a default of 4 octets; each endpoint determines the length of its own identifier. The Length field MUST equal the identifier length plus 2.¶
A client that receives the SRO-Server-Identifier option SHOULD store the server identifier for the lifetime of the connection.¶
A server that receives the SRO-Client-Identifier option SHOULD store the client identifier for the lifetime of the connection.¶
During the TCP handshake, the client and the server exchange the SRO options according to the rules in Section 3.2. After the handshake, each endpoint has stored the identifier of the peer and conveys it for session recovery as described in Section 4.2.¶
By default, an endpoint conveys the identifier on timeout retransmission.¶
In a load-balancing cluster, where the session state is backed up to the server, a client conveys the server identifier on timeout retransmission. The network node uses the identifier to locate the server holding the backup and recover the session.¶
load-balancing
client network node server
| | |
| ------ SYN + Client-ID -----> | ----- SYN + Client-ID ------> |
| <---- SYN-ACK + Server-ID --- | <--- SYN-ACK + Server-ID ---- |
| | |
| <---------- data -----------> | <---------- data -----------> |
| | |
| - - - (session lost) - - - x|x - - - (session lost) - - - |
| | |
| | |
| retransmission | |
| ------------ + -------------> | |
| Server-ID | |
| | |
| | ------ recovery query ------> |
| | <----- session state -------- |
| | (session recovered) |
| | |
| <---------- data -----------> | <---------- data -----------> |
Figure 2 shows the recovery flow in a load-balancing cluster, where the client conveys the server identifier. The flow in a SNAT cluster is symmetric: the server conveys the client identifier, and the network node locates the client holding the backup. The detailed recovery procedures are described in the Available Session Recovery Protocol (ASRP) [draft-cmcc-asrp].¶
In a SNAT cluster, where the session state is backed up to the client, a server conveys the client identifier on timeout retransmission. The network node uses the identifier to locate the client holding the backup and recover the session.¶
How the network node recovers a session is out of the scope of this document. It is suggested that the node use the Available Session Recovery Protocol (ASRP) [draft-cmcc-asrp] to recover the session; however, SRO does not depend on ASRP.¶
The endpoint includes the identifier of the peer stored during the handshake:¶
in the retransmitted segment, if the resulting segment length does not exceed the MTU, taking the TCP option length into account as described in [RFC6691]; or¶
in a separate ACK segment, otherwise.¶
The ACK segment is used only to convey the identifier and MAY be discarded by the network node after the identifier is extracted.¶
In the per-segment mode, an endpoint MAY be configured to include the identifier of the peer in every segment of a connection, instead of only on timeout retransmission. The network node can then recover the session at any time, without depending on retransmission timing. This mode is intended only for services with extremely high requirements on both reliability and recovery speed; for most deployments, the default mode is sufficient and the per-segment mode is not needed. It is disabled by default, as it adds 2 + N octets to every segment.¶
Clients that do not support SRO do not include the SRO-Client-Identifier option in the SYN segment, and servers that do not support SRO do not include the SRO-Server-Identifier option in the SYN-ACK segment. Such connections behave exactly as connections without SRO, and session recovery falls back to the mechanisms implemented by the network node. Similarly, if the SRO options are removed by an intermediate device, the endpoints operate without identifiers. SRO is designed for the common deployment where a single tier of SNAT or LB nodes sits between the client and the server; in multi-tier deployments, only the tier closest to the client or the server can use SRO.¶
A forged identifier cannot recover a non-existent session, because recovery succeeds only if the session backup actually exists on the identified endpoint. A segment carrying an identifier triggers at most one recovery query, which is no more than the number of queries triggered by other recovery mechanisms.¶
How a network node maps an identifier to an endpoint address is an implementation matter. A node SHOULD ignore an identifier that it cannot map to a known endpoint, and SHOULD rate-limit recovery queries (e.g., per session or per source) to mitigate flooding.¶
An identifier SHOULD be randomly assigned or derived with a secret key, rather than being derived directly from the endpoint IP address, so that internal addressing information is not exposed to third parties.¶
IANA is requested to allocate two TCP option Kind numbers from the TCP option kind registry for the Session Recovery Option:¶
| Kind | Length | Meaning | Reference |
|---|---|---|---|
| TBD-A | variable | SRO-Client-Identifier | This document |
| TBD-B | variable | SRO-Server-Identifier | This document |
The authors would like to thank all individuals who have provided valuable feedback and contributions during the development of this document.¶