IPsec is one of those protocols that "works everywhere" in the sense that every router and OS ships it — and "works almost nowhere" in the sense that hotel Wi-Fi, corporate proxies, and mobile carriers routinely eat it alive. RFC 8229 is the pragmatic surrender document: if you can't beat the middleboxes, tunnel through them by pretending to be TCP.

The problem. IPsec normally rides directly on IP protocol 50 (ESP) or 51 (AH), with IKE negotiation over UDP/500. NAT devices don't know how to rewrite ESP because there are no ports to translate, so RFC 3948 added UDP/4500 encapsulation. That fixed home routers but left three ugly failure modes:

• Captive portals and corporate firewalls that only permit TCP/80 and TCP/443 outbound.
• Middleboxes that drop non-TCP/UDP or mangle unknown UDP flows.
• Cellular NATs that aggressively time out UDP mappings, killing long-lived tunnels.

The design. RFC 8229 defines a very thin framing on top of TCP. Each IKE or ESP message is prefixed with a 16-bit length field, then sent as-is over a TCP connection — typically to port 4500. The initiator opens the connection; both IKE_SA_INIT and subsequent ESP-in-TCP packets share the same stream. To distinguish IKE from ESP inside the stream, the spec reuses the same "non-ESP marker" trick from UDP encapsulation: four zero bytes prepended to IKE messages (ESP's SPI is never zero).

Key design decisions worth noting:

• TCP is a fallback, not the default. The RFC explicitly recommends trying UDP first and only falling back to TCP when UDP fails, because TCP-over-TCP is a known performance disaster (the inner TCP retransmits fight the outer TCP retransmits — "TCP meltdown").
• No TLS required. The framing is bare TCP. IPsec already provides confidentiality and integrity; wrapping it in TLS would be redundant. But some deployments do run it inside TLS on port 443 anyway, because middleboxes doing SNI inspection expect a handshake.
• Length-prefixed framing. Because TCP is a byte stream, receivers need to know where one IKE/ESP message ends and the next begins. The 16-bit length caps individual messages at 64KB, which is more than enough.
• Connection is bidirectional and long-lived. Either peer can send IKE informational exchanges (like DPD keepalives) over the same connection at any time.

Why it matters today. If you use Apple's iCloud Private Relay, or a modern enterprise VPN like Cisco AnyConnect's IKEv2 profile, or WireGuard-over-TCP shims, you are using this pattern (WireGuard's own tcp fallback isn't 8229, but shares the same rationale). Apple was an early mover here — Tommy Pauly, one of the authors, is the Apple network stack engineer behind much of the modern Network.framework — and iOS's built-in IKEv2 client will silently switch to TCP encapsulation when UDP fails, which is why "VPN just works" on hotel Wi-Fi where OpenVPN-UDP would die.

Interesting quirks. The spec warns about the TCP meltdown problem but doesn't solve it. It also notes that TCP encapsulation defeats ECN and PMTU discovery in weird ways — the outer TCP absorbs congestion signals that the inner protocol never sees. And because both endpoints keep the TCP connection open, load balancers that expect short-lived HTTPS connections will happily kill your VPN mid-session unless carefully configured.