Hi Ryan! The honeypot issue is a real one -- I've made it pretty clear that this draft is not doing functional changes to QUIC unless we discover a vulnerability or a deadlock condition in v1.
But they would still be "compatible" in the sense of the VN draft -- a v1 Initial packet can be translated to a v2 packet with 100% fidelity, and vice versa. I'm not sure what you mean by "wire compatible", but as all the keys are derived differently, we are already well past a v1-only endpoint being able to read v2. On Tue, Jan 11, 2022 at 7:07 AM Ryan Hamilton <r...@google.com> wrote: > To make sure I'm clear on the proposal, the idea is basically to make the > long header packet type values different for different versions > (specifically v2)? This means that v1 and v2 will not be wire compatible, > right? I'm slightly loath to open up v2 to wire changes because I fear > it'll turn into a honeypot for other attractive chances and may bog down > the release of v2. But I don't feel strongly and the idea seems nice in > general! > > On Mon, Jan 10, 2022 at 3:24 PM Martin Duke <martin.h.d...@gmail.com> > wrote: > >> This issue hasn't gotten much attention in QUICv2: >> https://github.com/quicwg/quic-v2/issues/7 >> >> Basically, we could simply reassign the packet type codepoints in v2 to >> so that Initials are a codepoint other than 0b00. >> >> For example: >> Initial = 0b01 >> 0-RTT = 0b10 >> Handshake = 0b11 >> Retry = 0b00 >> >> To the extent the purpose of v2 is grease stuff, this seems like a pretty >> simple and good thing to do. To the extent it's supposed to exercise >> version negotiation, this change is a needless distraction. >> >> Does the WG think this is worthwhile? I hope to issue the next draft with >> the provisional version number allocation, so this is the right time to >> make this sort of change. >> >> Martin >> >
