OMG: Hop-by-Hop Path MTU Discovery
Straight from the “Bad Ideas Never Die” (see also RFC 1925 Rule 11) department: Geoff Huston described a proposal to use hop-by-hop IPv6 extension headers to implement Path MTU Discovery. In his words:
It is a rare situation when you can create an outcome from two somewhat broken technologies where the outcome is not also broken.
IETF should put rules in place similar to the ones used by the patent office (Thou Shalt Not Patent Perpetual Motion Machine), but unfortunately we’re way past that point. Back to Geoff:
It appears that the IETF has decided that volume is far easier to achieve than quality. These days, what the IETF is generating as RFCs is pretty much what the IETF accused the OSI folk of producing back then: Nothing more than voluminous paperware about vapourware!
The thing Geoff hasn't noticed in that draft is that (a) it is experimental, and (b) it isn't expected to be used across the Internet - the design goal is within a single network, such as a Data Centre network.
Within a single network you have a single administration that control the network infrastructure. Once that level of control exists, the issues with EHs can be made to disappear - the network can choose to buy equipment that supports EH processing they require and can enable it.
The IETF are really designing protocols for two scenarios - over the public, network of networks called the Internet, and within a single administration network (usually one of the networks of networks in the Internet). Some things can't be assumed to work reliably over the Internet (e.g. PMTUD, EHs), yet can be made to work within a single network.