Hello QUIC, I believe it was MT that threatened to do this a long time ago, but to work through compatible version negotiation I wrote up a trivial QUICv2 (below) that just changes the initial salts. This caused me to figure out a couple of things about VN that may have been obvious to others but not to me.
TL;DR we made the right decision to keep both in the draft. 1. One very possible world is one where firewalls ossify on expecting v1 in the first packet, but don't care about subsequent packets. Compatible VN is well-designed for this world, as Client Initials (and 0RTT, sadly) can be v1 essentially forever and subsequent packets can be whatever we want. 2. If all versions are compatible, choice of VN method is essentially up to the client, but not quite deterministically: it can pick either a likely supported version or an unlikely one. If unlikely, the server will either accept it or send a VN. If likely, the server MUST use compatible VN to change the version, since it can't send a VN packet that contains the initial version unless it doesn't have full support for it. Anyway, this v2 draft is available for your consideration if people want to quickly iterate a new version, and/or we need a vehicle for fixes to v1. Thanks Martin ---------- Forwarded message --------- From: <[email protected]> Date: Thu, Apr 22, 2021 at 10:22 AM Subject: New Version Notification for draft-duke-quic-v2-00.txt To: Martin Duke <[email protected]> A new version of I-D, draft-duke-quic-v2-00.txt has been successfully submitted by Martin Duke and posted to the IETF repository. Name: draft-duke-quic-v2 Revision: 00 Title: QUIC Version 2 Document date: 2021-04-22 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/archive/id/draft-duke-quic-v2-00.txt Status: https://datatracker.ietf.org/doc/draft-duke-quic-v2/ Html: https://www.ietf.org/archive/id/draft-duke-quic-v2-00.html Htmlized: https://tools.ietf.org/html/draft-duke-quic-v2-00 Abstract: This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. Over time, it may also serve as a vehicle for needed protocol design changes. Discussion of this work is encouraged to happen on the QUIC IETF mailing list [email protected] or on the GitHub repository which contains the draft: https://github.com/martinduke/draft-duke-quic-v2. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
