TL;DR;

quicwgのML/issueを発掘して現在の仕様が何を考慮しているのかを探るよ
事前準備として自分の言葉で説明を書いたよ
それはそれとして、QUIC硬直化の説明の正しさで言えば↓のエントリのがクオリティ高いからこちらを読むことをおすすめするよ。
強い人教えてください

Chromeが6週間毎にTLSバージョン番号を変更していくかもしれない - ASnoKaze blog

QUIC Ossification

Ossification

Ossification(硬直化)とは、インターネット上にプロトコルの更新に耐えられない不適切な実装が数多く存在し、プロトコルの更新が困難になる問題をいいます。

代表的な例はTLSの更新です。 TLS1.1 -> TLS1.2やTLS1.2 -> TLS1.3において新しいClientHelloのフォーマットの変更を受け付けない、新しいversionに対して問題のある挙動を示すmiddleboxが無視できない程度に存在し、追加で長い議論が必要になりました。 IETF標準化の過程においてはちゃめちゃ苦労した経験から、 IETFのメンバーは硬直化と題し積極的に議論が前もって行われるようになった（そうです）。それより過去の議論については若輩ゆえ存じ上げません。（詳しい人教えてください)

QUICにおいて

QUICは2020~においてエンドユーザーとサーバ終端の通信を担うプロトコル²となることが予想されます。またTCPの反省から、比較して細やかにVersionを刻んで行けることが期待されています。そのためQUICにおいてもOssificationの議論がなされています。 IETF draftとして関係しそうなのは

です。

Invariant

invariantとは将来に渡ってフォーマットが変化しないフィールドを定義し、 middleboxがそのフィールドにのみ依存することを明示します。よって、Versionごとにそれ以外のフィールドを変更してもmiddleboxがペイロードを少なくともQUIC Payloadであることを理解することができます。

GREASE

GREASEはペイロードにランダムな値を入れてフォーマットの変更に対する耐性を保つ試みです。プロトコルには”予約されているけれど現行の仕様では使われないフィールド"が存在します。しかし、不完全な実装ではこれらが一定の値であることを期待して振る舞うことがあります。

Googleはこれに対して対策を試みています。現行の実装から"使用していないけれど実装が受け入れるべき値"をランダムに送信することで、広域インターネットにおけるプロトコルの透過性を保とうとしています。これらをGREASEと呼びます。

錆びついたTLSを滑らかに、GoogleによるGREASE試験 - ぼちぼち日記

QUICはTLS1.3の構成要素であるTLS Handshake Protocolを使用するため、TLS Handshakeにおいて起こる問題は同様に起こります。そのため同様の対策をQUIC向けに策定し直す必要があります。

つづく

ここまでの理解を前提としてquicwg mailing listを漁っていきます。

https://tools.ietf.org/html/draft-ietf-quic-transport-18 ↩
言い換えるとインターネットバックボーン/DCネットワークにおいては使われなさそう↩

keizo042 tech blog

QUIC硬直化の議論を発掘する日記