2021/09/12 追記: このとき議論されていた仕様は RFC8999として標準化されています
QUICは現在IETFで標準化が進めれています。
QUIC WG出来、本格的に標準化が開始して1年ほど立ったところで、スケジュールとスコープの議論(QUIC - Our schedule and scope)が出てきており、QUIC Version1としてどの機能を標準化する話が行われてる一方で、Invariantsというトピックが出てきています。
QUIC Version 1と今後のバージョンで、パケットのレイアウト・パラメータを不変な値、将来のバージョンで変更されないものとするかという議論です。
TLS1.3の議論で起こっているように、プロトコルのバージョンアップによってファイアウォールなどの中間装置が誤作動し通信が阻害される事があるというのはおおきな課題になってきています。
実際、Google QUICでもパケットのレイアウトを変更した所一部のファイアウォールでおかしな挙動をしたことが、Googleの論文でも触れられています。
asnokaze.hatenablog.com
そこで、QUICでは将来のバージョンをデプロイしやすくするために、変更されないパラメータというのを事前に決めていく流れに有ります。
Version-Independent Properties of QUIC
上記のとおり、QUICのパラメータと意味と場所を固定にする提案は、「Version-Independent Properties of QUIC」として提出されています。
まだ議論の最中ですが、今のところ、各パケットのコネクションID・バージョン番号の位置及び、バージョンネゴシエーションパケットは将来も変更されないとしています。
これによってそのコネクションのバージョンが何なのか経路上からも確認できるので、何かしらの処理があるにせよ非対応のバージョンでおかしな挙動をするファイアウォールは少なくなるものと思われます
ロングヘッダ
ロングヘッダでは、ロングヘッダを示す先頭1bit、Connection ID、Versionの位置が将来的にも固定されます
ショートヘッダ
ショートヘッダでは、ショートヘッダを示す先頭1bit、Connection IDの位置が将来的にも固定されます
その他
その他にもこのドキュメントでは、現在のQUICではそうなっているが将来変更される可能性もあるので、幾つかの仮定をすべきでない事も列挙しています。
例えば、ロングヘッダがコネクション確立時のみに使用されるという仮定や、パケット番号の出現位置に関する仮定があげれれています。
