| Internet-Draft | SIO | October 2026 |
| Luo & Yan | Expires 24 April 2027 | [Page] |
This document defines the Session Identifier Option (SIO), carried as a TCP option for TCP connections and as a UDP option for UDP datagrams. The option lets the endpoints of a connection or flow publish identifiers at the transport layer, where network functions on the path - load balancers, NAT gateways, firewalls - can read them without per-flow state and without payload inspection. Network functions of all kinds can benefit from it: session recovery in load-balancing and NAT clusters, stateless forwarding, connection-tracking recovery, and telemetry. The option adds only a few octets, and only to the packets that carry it; which packets carry it is a deployment choice. 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 24 April 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.¶
Almost every transport option standardized to date serves the two endpoints of a connection: MSS, Window Scale, SACK [RFC9293], and timestamps [RFC7323] tune the transport between the two stacks. The network between the endpoints has evolved differently. Load balancers, NAT gateways, and firewalls are deployed at scale on virtually every path, and they maintain per-connection state that the endpoints are unaware of; yet no TCP option serves this middle tier, UDP has only recently gained an options mechanism at all [RFC9868], and the session management of this middle tier is implemented privately by every product. The option defined in this document fills this gap: endpoints voluntarily publish, at the transport layer, the identifier of the endpoint a flow belongs to, so that on-path network functions can consume this information without per-flow state and without payload inspection. This follows the direction the IETF set for middleboxes [RFC3234]: middleboxes are a fact of the Internet, and the alternative to standardizing endpoint-middlebox cooperation is not its absence but its proliferation in private forms. The cooperation stays consensual: identifiers are published voluntarily by the endpoints, are read-only on path, and the end-to-end semantics of the transports are unchanged.¶
Identifier-based forwarding has already been standardized for QUIC: QUIC-LB [I-D.draft-ietf-quic-load-balancers] encodes routing information in the connection ID, validating the pattern at working-group level, but only for QUIC. TCP and UDP have no corresponding mechanism. The SIO provides one - a standard channel between the endpoints and on-path network functions, on which richer cooperation can be built.¶
The SIO is carried as a TCP option [RFC9293] and as a UDP option [RFC9868]. On TCP, the client and the server exchange their identifiers during the handshake; afterwards, designated segments carry the identifier of the peer, so that a network function that encounters a connection it does not know can learn, from the segment itself, which endpoint the connection belongs to. On UDP there is no handshake and no retransmission; each endpoint includes the SIO in every datagram, so that a network function that encounters a flow it does not know can learn the same from any datagram. The SIO is lightweight: it adds only a few octets to a packet, whichever carrying mode is used (Section 4.2). Beyond session recovery, the channel serves network functions of every kind: a load balancer can read the backend identifier from every packet and forward without any session table at all; on-path measurement can attribute traffic to individual backends from the identifiers alone; a network element can use an identifier as an opaque anchor so that traffic follows a stable path with no per-flow state (Section 5). For session recovery itself, the option lets elastically scaling clusters keep long-lived connections through session loss, and the Available Session Recovery Protocol (ASRP) [I-D.draft-cmcc-asrp] builds full session backup and recovery on it.¶
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.¶
"SIO" refers to one of the two Session Identifier options defined in this document: the LOCAL-ID option, which carries the identifier of its sender, and the PEER-ID option, which carries the identifier of the sender's peer. "Client" refers to the endpoint that initiates a connection or flow: the active open side of a TCP connection, or the sender of the first datagram of a UDP flow. "Server" refers to the other endpoint. "Network node" refers to an on-path device (e.g., a load balancer, a NAT gateway, or a firewall) that forwards packets; in the session-recovery use, it also participates in session backup and recovery. "Client identifier" and "server identifier" refer to values that identify the client or the server within a cluster. The length of an identifier is configurable, from 0 to 8 octets. "Session backup" refers to session state information stored on an endpoint for the purpose of session recovery.¶
The SIO comes in two kinds, so that each option is self-describing: the LOCAL-ID option carries the identifier of its sender, and the PEER-ID option carries the identifier of the sender's peer. On TCP, the options are negotiated during the handshake, similar to other TCP options, e.g., the Window Scale option [RFC7323], SACK [RFC9293], the Authentication Option (TCP-AO) [RFC5925], and TCP Fast Open [RFC7413]: a client includes the LOCAL-ID option in the SYN segment, a server that supports the SIO includes the LOCAL-ID option in the SYN-ACK segment, and the options are in effect only if both segments carry one. After the handshake, an endpoint includes the PEER-ID option, carrying the identifier of the peer it stored during the handshake: a client carries the server identifier, and a server carries the client identifier. On UDP there is no handshake; each endpoint includes the options in every datagram according to the rules in Section 3.2.¶
Each SIO carries one identifier: the LOCAL-ID option carries the identifier of its sender, and the PEER-ID option carries the identifier of the sender's peer. The identifier length is configurable, from 0 to 8 octets. Each 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. A zero-length identifier indicates that the endpoint supports the SIO but has no identifier. On TCP, the options are TCP options; on UDP, they are carried as UDP options [RFC9868] in the datagram's option area.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identifier (N octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each endpoint decides whether to use the SIO. On TCP, the options are in effect only when both endpoints have offered them; on UDP, there is no negotiation and the UDP rules below apply unilaterally.¶
A client MAY include the LOCAL-ID option in a SYN segment; the client decides whether to use the SIO.¶
A server that supports the SIO and receives a SYN segment with the LOCAL-ID option SHOULD include the LOCAL-ID option in the SYN-ACK segment, carrying its own identifier.¶
A server MUST NOT include the LOCAL-ID option in a SYN-ACK segment if the corresponding SYN segment did not include the LOCAL-ID option.¶
A client that receives a SYN-ACK segment without the LOCAL-ID option MUST NOT include the PEER-ID option in subsequent segments of that connection.¶
The length of an identifier is configurable, from 0 to 8 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 LOCAL-ID option in a SYN-ACK segment SHOULD store the server identifier at least for the lifetime of the connection.¶
A server that receives the LOCAL-ID option in a SYN segment SHOULD store the client identifier at least for the lifetime of the connection.¶
After the handshake, each endpoint conveys the stored identifier of the peer in the PEER-ID option, in the segments designated by its carrying mode (Section 4.2).¶
UDP has no handshake and no retransmission: any datagram may be the one that arrives after a session is lost, so an endpoint includes the SIO in every datagram it sends. The two kinds make each option self-describing, and their use follows three rules:¶
An endpoint includes the LOCAL-ID option, carrying its own identifier, in every datagram it sends.¶
Once an endpoint has learned the peer's identifier from the peer's LOCAL-ID option, it additionally includes the PEER-ID option, carrying the peer's identifier, in every datagram it sends.¶
A PEER-ID option carrying the endpoint's own identifier is an echo: it proves the peer has learned the identifier. An endpoint that has received an echo MAY stop including the LOCAL-ID option; once it stops, its datagrams carry only the PEER-ID option.¶
A datagram MAY carry both options during the transition. An endpoint of a one-way flow never receives anything from the peer: it never learns the peer's identifier and continues to carry the LOCAL-ID option indefinitely, which is the intended behavior - the peer still needs to be taught. Recovery for such flows falls back to the network node's local handling, since the forward path never carries the peer's identifier.¶
An identifier is an opaque octet string carried in the SIO. This document defines how identifiers are carried; it assigns them no meaning and does not standardize how they are generated. Identifiers serve many uses - session recovery, routing, packet marking, measurement - and each use imposes its own requirements on generation. How identifiers are generated, managed, and assigned is decided by the deployment; see the Security Considerations for how the choice of derivation affects exposure.¶
Only a function that interprets identifiers - resolves them to endpoints, routes, or classes - needs to know how they are generated in the deployment it serves; a function that merely uses an identifier as an opaque value, e.g., for hashing, marking, or counting, needs no such knowledge. In a load-balancing deployment, for example, a load balancer that recovers sessions by identifier needs to know how the backends generate their identifiers. When the SIO is used with a mechanism that resolves identifiers to endpoint addresses, e.g., ASRP [I-D.draft-cmcc-asrp], the deployment MUST ensure that the network nodes can perform this resolution.¶
A future specification may standardize the generation of identifiers for a specific use, as QUIC-LB [I-D.draft-ietf-quic-load-balancers] standardizes the encoding of routing information in the QUIC connection ID.¶
Uniqueness: Whether identifiers need to be unique depends on the use. In the session-recovery use, an identifier SHOULD be unique among the endpoints of the cluster it serves, because the network node locates the backup holder by the identifier.¶
Stability: An identifier MUST remain stable for the lifetime of the connections that carry it, and SHOULD remain stable across reboots. Session recovery relies on the identifier of the backup holder: an identifier that changes after a restart leaves the backups associated with the earlier identifier unreachable.¶
On TCP, the client and the server exchange the LOCAL-ID option during the handshake according to the rules in Section 3.2. After the handshake, each endpoint has stored the identifier of the peer and conveys it in the segments designated by its carrying mode (Section 4.2). On UDP, there is no handshake: each endpoint begins including the LOCAL-ID option in the first datagram it sends, and the option use follows the rules in Section 3.2 as the flow progresses.¶
On TCP, the identifier of the peer is conveyed in one of two modes. Which mode applies is a deployment choice:¶
Retransmission mode: The identifier is carried only in segments sent on timeout retransmission; normal data segments carry no overhead at all.¶
Per-segment mode: The identifier is carried in every segment of the connection. This is the enabling mode for stateless forwarding (Section 5): a load balancer that forwards segments without any session table needs the identifier on every segment. It adds 2 + N octets to every segment.¶
Deployments that consume the identifier on the forwarding path, e.g., stateless load balancing, SHOULD use the per-segment mode; for session recovery alone, the retransmission mode suffices.¶
UDP has a single carrying mode: every datagram carries the SIO (Section 3.2). UDP has no retransmission, so any datagram may be the one that arrives after a session is lost, and the identifier must be present on it.¶
The SIO defines how identifiers are exchanged and carried, not what consumes them. The uses below are independent of each other, and none is required by the option itself. Session recovery, the use for which the option was first proposed, is described first.¶
On TCP, 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) [I-D.draft-cmcc-asrp].¶
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) [I-D.draft-cmcc-asrp] to recover the session; however, the SIO does not depend on ASRP.¶
On UDP, every datagram carries the identifier (Section 3.2): a network node that encounters a datagram of a flow it does not hold can recover the flow from that datagram alone, without waiting for a retransmission.¶
In deployments where the load balancer forwards only the client-to-server direction (e.g., DSR and one-way DNAT), the load balancer can read the backend identifier from every packet and forward accordingly, with no session table at all; this greatly simplifies its implementation. It requires the per-segment mode (Section 4.2) on TCP, so that the identifier is present on every segment; on UDP, every datagram carries an option by definition. In deployments that keep a session table for other processing, the table is reduced to a cache that accelerates the common case: on a miss, the packet is still forwarded correctly.¶
A firewall or NAT gateway that loses its connection table normally drops established connections and flows. With the SIO, a packet carrying the identifier lets the middlebox rebuild its entry, or locate the backup as in the recovery flow of Section 5.1.¶
On-path measurement can attribute traffic to individual backends from the identifiers alone, without inspecting the application payload.¶
A network element need not resolve an identifier to an endpoint at all: it can use the identifier as an opaque anchor, e.g., as a hash key that assigns flows to nodes, so that traffic carrying the same identifier follows a stable path without any per-flow state or mapping to maintain.¶
Virtualized middleboxes - load balancers, NAT gateways, firewalls, virtual switches, SD-WAN gateways, service-chain classifiers - are created, rescheduled, and replaced at high frequency, and any per-connection state they must maintain turns instance replacement into a state-migration problem. With the SIO providing the index, instances can obtain the connection context and be replaced freely. These functions can benefit from the option once it is available; the uses above apply to them as they apply to their physical counterparts.¶
Clients that do not support the SIO do not include the LOCAL-ID option in the SYN segment, and servers that do not support it do not include the LOCAL-ID option in the SYN-ACK segment. Such connections behave exactly as connections without the SIO, and session recovery falls back to the mechanisms implemented by the network node. Similarly, if the SIO is removed by an intermediate device, the endpoints operate without identifiers. On UDP, no negotiation is needed: a receiver that does not support UDP options ignores the datagram's option area, and a receiver that supports UDP options but not the SIO ignores them, so an endpoint that includes the options affects no one. The SIO 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 the SIO.¶
The SIO only exchanges endpoint identifiers. It carries no session state and no authentication information; the SIO itself performs no validation and promises none. Connections that require integrity protection can use TCP-AO [RFC5925] alongside the SIO; the two are independent and can coexist on the same connection.¶
The security of mechanisms built on the identifiers relies on the validation performed by the framework that consumes them. When the SIO is used with ASRP [I-D.draft-cmcc-asrp], the message validation described there applies: a network node verifies that a recovery response matches its outstanding request (cookie-based validation) and that the session referenced by the message is legitimate (session-legitimacy validation).¶
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.¶
How an identifier is derived is a deployment choice: it MAY be random, a keyed function of the address, or the address itself. Deriving it directly from the address is simple and functional, but exposes internal addressing information to on-path observers; where that exposure matters, a random or keyed assignment avoids it.¶
IANA is requested to allocate two TCP option Kind numbers from the TCP option kind registry for the Session Identifier options:¶
| Kind | Length | Meaning | Reference |
|---|---|---|---|
| TBD | variable | SIO LOCAL-ID | This document |
| TBD | variable | SIO PEER-ID | This document |
and two UDP option Kind numbers from the "UDP Option Kind Numbers" registry [RFC9868]:¶
| Kind | Length | Meaning | Reference |
|---|---|---|---|
| TBD | variable | SIO LOCAL-ID | This document |
| TBD | variable | SIO PEER-ID | This document |
Prior to IANA assignment of permanent option Kind values, implementations deployed for experimentation or interoperability testing SHOULD use the option Kind values reserved for experimental use, together with an Experiment Identifier (ExID), as described in [RFC6994] for TCP and [RFC9868] for UDP.¶
Note to the RFC Editor: Please remove this section before publication.¶
The SIO has been implemented twice and the implementations have been interoperability tested on a three-node testbed (client, load balancer, server):¶
An eBPF implementation based on traffic-control programs on the endpoints: LOCAL-ID option insertion in the SYN and SYN-ACK, per-connection storage of the peer identifier, and the retransmission mode, where the PEER-ID option is carried in retransmitted segments, verified on the wire; on UDP, per-datagram option insertion with the LOCAL-ID/PEER-ID rules of Section 3.2.¶
A Linux kernel module extending IPVS on the load balancer: extraction of the identifiers from packets and resolution to the backend for session recovery.¶
The testbed exercised session recovery after load-balancer session-table loss and the identifier conveyance described in Section 4.2.¶
The authors would like to thank all individuals who have provided valuable feedback and contributions during the development of this document, especially Mike Heard and Michael Tuexen for their detailed review comments.¶
Added UDP support via UDP options [RFC9868], with per-datagram carrying and no negotiation; split the option into the LOCAL-ID and PEER-ID kinds so that each option is self-describing on both transports; restructured the document around the option as a general channel between endpoints and on-path network functions, with session recovery as the first of several uses; added the QUIC-LB precedent, an implementation status section, and applicability to virtual network functions; reworked the Introduction around the standard-channel positioning and softened the identifier-derivation wording. Renamed the option from the Session Recovery (SR) option to the Session Identifier Option (SIO).¶