Re: [quicwg/base-drafts] Renumber packet types and invert Connection ID Flag (#956)

[Marten Seemann <[e-mail]>]

I recently implemented the [header parsing logic for quic-go](https://github.com/lucas-clemente/quic-go/blob/master/internal/wire/header.go#L34-L72), such that it can handle both gQUIC and IETF QUIC. You might find my summary of the different formats for the type byte useful: https://docs.google.com/document/d/162BtfR84c6xTvAG6AaPK0dXSQXKahMrtJOXxNnpcwDw/edit?usp=sharing.

The current packet header format has the nice property that it is possible to decide if the packet is a gQUIC or an IETF QUIC packet by just looking at the type byte. This is possible due to the following properties:

### for packets sent by the server

For packets sent by the server the client already knows the QUIC version needed for parsing the packet, as soon as version negotiation is completed. Therefore, the only requirement here is that the type byte used for the Version Negotiation Packet in IETF QUIC is not used in gQUIC, and the type byte used for the gQUIC VNP is not used in IETF QUIC.
This property is guaranteed by the first bit of the type byte alone already (0x80 is unset in gQUIC, and set for an IETF QUIC VNP).

### for packets sent by the client

All gQUIC packets have bits 0x80 and 0x40 unset, and currently IETF QUIC packets either have 0x80 set (for long headers) or 0x40 set (for short headers, if connection ID omission is not allowed, which I assume is what server implementations will do).
This property would be changed by this PR (because the connection ID bit is inverted), so a server wouldn't be able to distinguish between gQUIC and short header packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/956#issuecomment-346501729