RFC 6066 is the unsung hero behind every modern HTTPS connection. It defines the core TLS extensions that make it possible to host thousands of HTTPS sites on a single IP address — most importantly, Server Name Indication (SNI). If you have ever wondered how CloudFlare, Fastly, or AWS CloudFront can serve millions of distinct certificates from the same edge IP, the answer starts here.

The problem. Original SSL/TLS had a chicken-and-egg flaw. The server presents its certificate during the handshake, but at that point it has no idea which hostname the client is asking for — the HTTP Host: header comes later, inside the encrypted tunnel. With IPv4 exhaustion looming and shared hosting ubiquitous, this meant either one cert per IP (expensive, wasteful) or wildcard/SAN certs covering everything on the box (operationally painful and a security blast-radius nightmare). The web could not scale TLS without solving this.

The fix: SNI. RFC 6066 adds a server_name field to the TLS ClientHello. The client tells the server, in cleartext, which hostname it wants before the server picks a certificate. The server then selects the matching cert and proceeds. It is a beautifully small protocol change with enormous infrastructure consequences — it is the reason Let's Encrypt could realistically ship in 2015, the reason virtual hosting works over HTTPS, and the reason CDNs are economically viable.

The other extensions. 6066 is a grab-bag spec; it consolidates several useful additions:

• max_fragment_length — lets constrained clients negotiate smaller record sizes (important for IoT and mobile where the default 16 KB is wasteful).
• status_request — the foundation of OCSP stapling. Instead of every client phoning the CA to check certificate revocation (slow, privacy-leaking), the server fetches an OCSP response itself and "staples" it to the handshake.
• trusted_ca_keys and truncated_hmac — niche, rarely deployed.
• server_certificate_type / client_certificate_type — later extended to support raw public keys and other cert formats.

Key design decisions. SNI is sent unencrypted. This was pragmatic — the server needs it before keys are negotiated — but it became one of TLS's most enduring privacy problems. Censors and middleboxes can see exactly which sites you visit even over HTTPS. This eventually motivated ESNI and then Encrypted Client Hello (ECH), which are still being rolled out in 2026. So 6066 simultaneously enabled the modern web and created the surveillance vector ECH is trying to close.

History. 6066 supersedes RFC 4366, which itself fragmented an earlier omnibus extensions document. Donald Eastlake — a prolific IETF contributor also responsible for DNSSEC work and TRILL — split the registry mechanism from the actual extension definitions, which is why the IANA "TLS ExtensionType Values" registry is governed separately. That split lets new extensions like ALPN (RFC 7301, which gave us HTTP/2 negotiation) slot in cleanly.

Why engineers still care. If you debug TLS in 2026, you read ClientHellos. The first thing you look for is the SNI value — load balancers route on it, WAFs filter on it, and observability tools key on it. Tools like openssl s_client -servername, curl --resolve, and tshark -Y tls.handshake.extensions_server_name all exist because of this RFC. TLS 1.3 kept SNI essentially unchanged precisely because the ecosystem depends on it.