MsQuic has released a version with VN+V2 support, but it's marked as "preview" so it can change, as necessary. We weren't planning to make it an official feature until the RFCs.
Thanks, - Nick Sent from Outlook<http://aka.ms/weboutlook> From: QUIC <quic-boun...@ietf.org> On Behalf Of Martin Duke Sent: Thursday, November 17, 2022 8:45 PM To: Christian Huitema <huit...@huitema.net> Cc: Martin Thomson <m...@lowentropy.net>; quic@ietf.org Subject: Re: Transport parameters for version negotiation and v2 In Google's code, the v2 code is exists but is not in production because we haven't done compatible VN yet. So changing the transport parameter at this point would have no impact on Chrome or Google production servers. On Thu, Nov 17, 2022 at 4:28 PM Christian Huitema <huit...@huitema.net<mailto:huit...@huitema.net>> wrote: On 11/17/2022 4:15 PM, Martin Thomson wrote: > How many people have shipped version negotiation and v2 already? > > I assume that implementations are using the codepoints for the transport > parameter in the draft (0xFF73DB), but the drafts says this: > >> When this document is approved, it will request permanent allocation of a >> codepoint in the 0-63 range to replace the provisional codepoint described >> above. > > IANA are about to make that new allocation, but that might not do good things > for interoperability. > > We're not changing the v2 version number and v2 *requires* the use of this > transport parameter: > https://quicwg.org/quic-v2/draft-ietf-quic-v2.html#section-4-2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.org%2Fquic-v2%2Fdraft-ietf-quic-v2.html%23section-4-2&data=05%7C01%7Cnibanks%40microsoft.com%7C0b21307c92c24ee5f18c08dac906a08b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043327575620512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wz2tzGwBJsw7zyflxjdsihvHeZ%2FvFJhb1S48%2Bc9x%2BAY%3D&reserved=0> > > Consequently, an implementation that uses the current transport parameter > codepoint will not interoperate successfully with an implementation that uses > any new transport parameter codepoint. > > So, we either allocate a new codepoint for both, or we keep the existing > ones. Which do people prefer? > > Or, am I wrong about this? The way I read it, QUIC-V2 makes a reference to QUIC-VN, which is documented in the reference section as pointing to draft-ietf-quic-version-negotiation-13. But I fully expect that the next QUIC-V2 draft will refer to the updated version of QUIC-VN, and thus to the final transport parameter. -- Christian Huitema
