Demultiplexing QUIC

[Marten Seemann <[e-mail]>]

RFC 9443 defines how to demultiplex QUIC from a whole range of other
protocols. Packets in the range 128..191 (i.e. all packets starting with
0b10xxxxxx) are supposed to be forwarded to RTP/RTCP.

This mostly works, since QUIC v1 packets (both short and long header)
define the "QUIC bit", the second bit (0x40) to be set to 1. On the other
hand, Version Negotiating packets are defined as 0b1xxxxxxx, where the last
7 bits are an arbitrary value. RFC 8999 defines these bits as unused, and
it's up to the server to decide how to set these bits. Specifically, it's a
valid strategy to set them to a fixed value. If that value starts with a 0,
Version Negotiation packets would be consistently mis-classified as RTP
packets.

Section 17.2.1 of RFC 9000 says that servers SHOULD set the first of the
unused bits to 1 "where QUIC might be multiplexed with other protocols".
This advice is fine for some deployments, but in the general case, the
server has no way of knowing what other things the client is demultiplexing
on the same UDP socket.

I see two ways out here:

   1. Change the recommendation in RFC 9000 to always set 0x40 to 1 (e.g.
   by removing the "where QUIC might be multiplexed with other protocols"
   subclause). It might also make sense to add this recommendation to RFC
   8999, too.
   2. Change the classification logic in RFC 9443, such that 128..191 are
   only routed to RTP/RTCP if the next 4 bytes are not equal to 0. I'm not
   sure about the implications for RTP/RTCP though.