How the IETF killed IPv6 extension headers
IPv6 extension headers (EHs) are a feature specific to IPv6 that allows packets to carry IP options more flexibly than in IPv4. Unfortunately, in practice EHs can't really be used.
Back in RFC 2292, when the IETF were first defining the various IPv6 application APIs, they attempted to add support for IPv6 EHs to TCP. However, it didn't work particularly well, so eventually in RFC 3542 they completely yeeted that API, and also provided an explanation of why they removed it. To quote:
It is unclear how a TCP application can use received information (such as extension headers) due to the lack of mapping between received TCP segments and receive operations. In particular, the received information could not be used for access control purposes like on UDP and raw sockets.
Sadly, we believe they failed to consider an important aspect of TCP: the accept() call. More
specifically, while there's no practical way to work with EHs in an established connection, the SYN
packet that initiates a connection is a discretely measurable data unit in a TCP session, and could have EHs attached
to it.
In other words, while the RFC 2292 approach doesn't work for TCP, they could have defined some sort of
"extended accept()" that returns the desired EHs, allowing the application to interact with them. In
fact, it probably wouldn't be too hard to define such, either.
Regrettably, TCP is single-handedly the most widely used transport protocol. By choosing to remove the RFC 2292 APIs and failing to provide appropriate alternatives, the IETF may well have killed IPv6 EHs before they could even be used.
(But maybe it can still be fixed?)