2023年7月23日(日) 11:14 Marten Seemann <[email protected]>:
> A server deployed on the public internet never knows what other protocols > the client is demultiplexing with QUIC, so the QUIC bit always needs to be > set to 1. Maybe this should even be a "MUST, unless the server has > out-of-band knowledge that the client is not demultiplexing"? > I think "SHOULD" as we state now might be better than a "MUST." Version Negotiation packets are unique in the sense that "inherently not version specific" (section 17.2.1). Rather, a Version Negotiation packet has to abide by the specifications of all the version numbers that it carries. Considering that, I think it is not incorrect to state that all version 1 packets have the QUIC bit set and at the same time stating that Version Negotiation packets might not have the bit set. > > As Lucas pointed out, the fact the client is offering the Greasing the > QUIC Bit extension can be seen as an indication that the client doesn't > care about demultiplexing, but it's unlikely that the server would be able > to (or willing to) parse the transport parameters for a QUIC version that > it's going to send a Version Negotiation packet for. > > On Sun, 23 Jul 2023 at 11:04, Lucas Pardue <[email protected]> > wrote: > >> Hey, >> >> On Sun, Jul 23, 2023 at 6:40 PM Kazuho Oku <[email protected]> wrote: >> >>> 2023年7月22日(土) 15:24 Marten Seemann <[email protected]>: >>> >>>> 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 actually think that this "where QUIC might be multiplexed other >>> protocols" could be an error in RFC 9000. FWIW, this condition was >>> introduced very late, in https://github.com/quicwg/base-drafts/pull/4744 >>> . >>> >>> I think what we really wanted to mean here is "unless an endpoint knows >>> that the peer is not demultiplexing." >>> >> >> I tend to agree with this. >> >> Interestingly, the Greasing the QUIC Bit RFC claims "The second-most >> significant bit of the first byte in every QUIC packet is defined as having >> a fixed value in QUIC version 1 [QUIC >> <https://www.rfc-editor.org/rfc/rfc9287.html#RFC9000>]." but that is >> clearly not true for the Version Negotiation packet because the requirement >> is only a SHOULD. I don't think the grease setting really applies though, >> because the server wouldn't know to apply it. Therefore if a sever knows >> the client doesn't need the bit for demultiplexing, perhaps it "SHOULD >> set the QUIC Bit to an unpredictable value"? >> >> Cheers >> Lucas >> > -- Kazuho Oku
