On this page
Protocol Evolution and Compatibility
Once a protocol is deployed, it is hard to change—TCP’s fixed header caused extensions to take ten years, and TLS middleboxes’ buggy behavior toward unknown extensions led to ossification. QUIC has built-in version negotiation and GREASE (random insertion of meaningless extensions) to combat middlebox ossification from the start—this is a required course for all new protocols.
Overview
Protocols are not immutable—once deployed, they are hard to change. The textual flexibility of HTTP/1.1 headers allowed new features (Cache-Control, CORS) to be added painlessly, but TCP’s fixed header made extensions difficult (TCP Fast Open took 10 years to become widespread). QUIC has built-in version negotiation and GREASE (random insertion of meaningless extensions) from the start—to combat protocol ossification caused by middleboxes’ buggy behavior toward unknown fields. All newly designed protocols should implement GREASE and explicit extension points.
Forward vs Backward
Forward compatible (new client, old server):
Unknown fields: skip (protobuf, TLV)
Unknown frame type: ignore (HTTP/2)
→ Implementation: "be liberal in what you accept"
Backward compatible (old client, new server):
Default value filling
Version negotiation
Capability bitmaps (TLS cipher suites)
Negotiation and Fallback
GREASE
Problem: Middleboxes (firewalls, NATs) only recognize byte patterns they know
→ New protocol extension → Dropped (unrecognized) → Protocol cannot evolve
GREASE: Client randomly inserts meaningless extensions/values:
TLS: Random cipher suites in ClientHello
HTTP/2: Random SETTINGS parameters
QUIC: Random transport parameters
Purpose: Middleboxes must correctly handle unknown values (ignore, not reject)
→ Future real extensions will not be blocked by middleboxes
Lessons from QUIC
References
- GREASE: RFC 8701
- QUIC Appendix A: RFC 9000 (design rationale)
Keywords: forward compatibility, backward compatibility, GREASE, ossification, QUIC, Alt-Svc